Это перевод поста из блога The Analytics Engineering Roundup (горячо рекомендую!) под названием Becoming Pangea про тенденции в индустрии данных и аналитики, стратегические преимущества и проблемы, с которыми сталкиваются компании в ней, влияние основных облачных провайдеров на её будущее и роль стандартов в формировании в ней технологических экосистем.

Происходит консолидация. Два года назад мы предполагали, что она произойдет, оглядываясь назад, мы теперь можем подтвердить эту гипотезу. Из недавнего поста Бенна:

Крупные поставщики, чувствуя заинтересованность клиентов в консолидации вокруг меньшего количества инструментов и ощущая свою собственную заинтересованность в зарабатывании большего количества денег, стали скупать компании поменьше. Databricks, Lakehouse Platform, купила MosaicML, компанию, занимающуюся генеративным искусственным интеллектом. dbt Labs, создатели dbt, купили Transform, разработчиков семантического слоя. ThoughtSpot, инструмент бизнес-аналитики, купили Mode, другой инструмент бизнес-аналитики. Teradata, поставщик хранилищ данных, купили каталог данных Stemma. Alteryx, старый инструмент подготовки данных, купил Trifacta, новый инструмент подготовки данных.

Далее в этом посте описываются некоторые конкретные сценарии/прогнозы относительно направления, в котором экосистема данных и аналитики будет развиваться в ближайшие годы, и я в основном поддерживаю точку зрения Бенна. Однако я скажу, что есть несколько вопросов, которые, по моему мнению, не затронуты в этом посте и которые будут важны для формирования грядущего десятилетия в экосистеме. Я подумал, что было бы интересно погрузиться в некоторые из них.

Каковы долгосрочные стратегические рвы?

На ранних этапах любой новой отрасли возможностей для получения прибыли предостаточно. Вы знаете эту поговорку «лучше продавать кирки и лопаты»? Что ж, это верно только до тех пор, пока глобальная цепочка поставок не начнет привозить кирки и лопаты из регионов с низкой стоимостью рабочей силы на контейнеровозах. Оказывается, что на достаточно долгом временном горизонте кирки и лопаты становятся просто товаром. Сегодня невозможно добиться стратегического преимущества с помощью кирок и лопат, поэтому цена падает до модели «себестоимость плюс», вся прибыль выжимается, а вся конкуренция происходит за счет цены ¹.

Думаю, фраза «лучше иметь источник устойчивого конкурентного преимущества» просто не звучала так же.

Рвы — качества бизнеса, которые позволяют ему защищать свою способность генерировать устойчивую прибыль — являются сердцем бизнес-стратегии. На самом деле не так уж и сложно построить бизнес, который будет приносить деньги в краткосрочной перспективе. Вот самый распространенный рецепт в нашей отрасли: определите тренд, найдите что-то, что нужно людям, чтобы воспользоваться этим трендом, создайте это, донесите до них, берите деньги. Круто!

Но если вы добьетесь успеха, другие увидят это и скажут: «Хм, держу пари, я мог бы сделать это на X% лучше или на Y% дешевле». Именно тогда происходит второй акт стартапа: как последовательно побеждать в мире, где другие могут видеть, что именно вы делаете?

Лучшая книга на эту тему, по моему мнению, — «7 сил» Гамильтона Хелмера. Чтобы побеждать более десяти лет подряд, с точки зрения этой книги, требуется сила.

Давайте на секунду проиллюстрируем эту мысль, взглянув на загрузку данных в хранилище (data ingestion). Это область, в которой я сделал несколько неверных прогнозов много лет назад, и только недавно я обновил мои предположения.

Я участвовал в запуске Stitch. Этот проект стартовал в 2015 году, а его запуск состоялся в 2016 году. Я решил оставить свою роль в команде руководителей компании, поскольку считал, что загрузка данных должна стать товаром — категорией без стратегического рычага влияния, вся прибыль которой в конечном итоге будет отнята новыми участниками. Я продолжал верить в это в течение многих лет и наблюдал, как в этой сфере зарождалось множество компаний. Казалось, я был прав.

Но каким-то образом Fivetran продолжал побеждать. Дело не в том, что все эти новые игроки полностью потерпели неудачу, но если сложить всю рыночную стоимость этих компаний, у Fivetran будет безусловно львиная доля. Как это возможно?

Я отдаю должное Джорджу: он постоянно говорил мне одно и то же в течение 7 лет, когда я задавал ему этот вопрос. Создавать качественные коннекторы данных сложно, и их нужно создавать и обслуживать МНОГО. Клиенты высоко ценят качество: все должно просто работать. Итак, вам нужна огромная клиентская база, чтобы окупить затраты на создание и обслуживание этих коннекторов. Если у вас огромная клиентская база, которая хорошо монетизируется, вы можете потратить больше на коннекторы, и, следовательно, они будут более высокого качества.

Это классический пример силы эффекта масштаба. Это похоже на дистрибьюторскую сеть Amazon или способность Netflix тратить больше на создание контента. Новый участник может видеть действие этого эффекта, но не имеет возможности напрямую атаковать его.

Вот почему наиболее интересные конкуренты Fivetran имеют открытый исходный код. Сейчас, когда Fivetran существует, возможно, будет трудно воспроизвести преимущество Fivetran в плане экономии на масштабе, но что, если бы вы могли использовать другую силу — сетевую экономику — чтобы конкурировать с ним? Есть несколько человек, делающих эту ставку прямо сейчас.

Однако моя первоначальная точка зрения заключалась в том, что загрузка данных не может стать товаром! Fivetran, похоже, демонстрирует довольно прочный ров, и экономия от масштаба имеет тенденцию со временем расти.

Ответ на вопрос «у кого есть стратегический ров, а кто просто занимается созданием программного обеспечения?» является, на мой взгляд, единственным наиболее полезным способом рассмотреть вопрос о будущем развитии отрасли.

Если мы обратим взгляд на еще одну категорию, которая сегодня чувствует себя неприступной за своими рвами, позвольте мне просто передать разговор, который у меня недавно был с лидером в области данных. Этот человек руководит разработкой данных в крупной, ориентированной на передачу данных цифровой компании. У них есть сильная склонность к использованию программного обеспечения с открытым исходным кодом. Я спросил: «Как это предпочтение open source соотносится с вашими инвестициями в Snowflake и Databricks?» (они активно используют оба).

Его ответ (перефразированный): «Мы работаем над созданием уровня, который позволит нам легко переносить рабочие нагрузки между платформами данных, чтобы мы могли легко принимать решения на уровне рабочей нагрузки о том, где мы хотим что-то запускать». Переведите эту фразу в структуру «7 сил»: «Мы намеренно сокращаем стоимость переключения между этими платформами, чтобы мы могли относиться к ним больше как к обычным вычислениям».

Чтобы внести ясность: расстояние между наличием этой идеи и реализацией этой идеи огромно. И это не новая мысль для самих платформ: многие из их инвестиций за последние несколько лет можно рассматривать как функциональность, которая усложняет перенос рабочих нагрузок на другую платформу (именно то, что они должны делать!). Но никто не застрахован от необходимости рва, и эта книга еще не полностью написана для слоя платформы данных.

Когда я смотрю на категории в современном стеке данных, я вижу очень мало рвов и множество людей, создающих программное обеспечение. Выживут категории с сильными рвами.

На основе каких стандартов формируется стек?

Каждая технологическая экосистема строится на основе определенных стандартов. Говорите ли вы о Web 1.0 с TCP/IP, HTTP и т. д. или о Web 2.0 с AJAX и REST, или даже о стандартизации размеров контейнеров как ключевом вкладе в современную глобальную экономику. Все начинается со стандартов.

Современный стек данных построен на базе SQL. Примерно в 2020 году SQL был, пожалуй, единственным стандартом, который имел большое значение. Но с тех пор появилось множество других вопросов по стандартам, которые имеют реальные последствия для будущего.

Формат файла: Delta / Iceberg / Hudi. Будут ли эти форматы продолжать широко применяться, и будет ли архитектура lakehouse по-прежнему востребована клиентами? Возможность естественного обмена данными между платформами данных с помощью общих форматов файлов значительно снижает привязанность и создает возможности для инноваций.

Обмен данными: Apache Arrow. Будем ли мы продолжать стандартизировать Arrow? Если это так, классические ограничения баз данных SQL ODBC/JDBC отпадают. Мы можем переосмыслить то, что происходит внутри и снаружи основного механизма, создавая пространство для новых подходов к обработке данных.

Семантический слой. Появится ли стандарт семантической информации? Если это так, пользователи, наконец, смогут отделить свою бизнес-логику от своих отчетов, что позволит им использовать более широкий набор специализированных аналитических инструментов. Очевидно, это то, что меня очень волнует.

Слой преобразования/формат метаданных. Мы намеренно придерживались агрессивного подхода OSS к dbt с самого начала, чтобы достичь цели стать стандартом в преобразовании данных, и мы добились в этом достаточного успеха. Интересным и неожиданным результатом этого является то, что метаданные dbt стали стандартом того, как инструменты всех типов понимают происхождение данных. Поскольку внутри платформы dbt продолжает создаваться все больше вариантов трансофрмации данных, стандартизированные метаданные упрощают создание новых возможностей на основе метаданных. Используются и другие форматы метаданных, но ни один из них не получил широкого распространения.

Интеграции. Появится ли когда-нибудь «стандарт коннектора данных»? MDS пытается сделать это уже много лет, начиная с протокола Singer в 2016 году. Это было бы круто, но спустя семь лет я не вижу, чтобы это сработало. Возможно, эта проблема еще недостаточно четко определена, чтобы ее можно было решить с помощью подхода, основанного на стандартах. Я все еще верю, что в конечном итоге здесь что-то есть, и это во многом изменит нынешнюю экосистему.

В целом стандартизация — это медленно развивающаяся, но очень мощная сила в отрасли. Как только большие группы объединяются вокруг стандарта, их невероятно трудно свергнуть. И затем они определяют форму будущего, поскольку последующие технологии создаются на основе этого стандарта.

Как развиваются отношения между облачными провайдерами, платформами данных и отдельными продуктами данных?

Возникает вопрос: почему существует Confluent? Или Hashicorp? Elastic? Mongo? Осмелюсь ли я сказать, даже Snowflake и Databricks?

Каждая из этих компаний напрямую конкурирует с одной или несколькими услугами, предоставляемыми каждым из облачных провайдеров. А если сложить всю их рыночную стоимость, то получится довольно скромный процент даже от AWS, не говоря уже о GCP и Azure.

Почему облачные провайдеры просто не раздавят их? Это их большие заинтересованные сообщества? Фантастический опыт разработчика? Отличная технология? Все это, безусловно, правда, и, конечно же, они являются частью ответа. Но я считаю, что их недостаточно. Каждый из облачных провайдеров принадлежит компаниям стоимостью более 1 триллиона долларов. Эти компании печатают наличные и они ищут способы их потратить. Достаточные инвестиции на долгосрочную перспективу могут преодолеть практически любой барьер.

Когда я разговариваю с руководителями этих компаний, я получаю ответ: «Единственное, что у нас есть, что не могут воспроизвести облачные провайдеры, — это то, что они не могут быть мультиоблачными». Когда я впервые услышал это, я был удивлен тем, насколько это банально. Типа… может ли это вообще иметь смысл?

В течение многих лет, прошедших с тех пор, этот ответ овеществлялся для меня снова и снова. И оказывается, что покупатели корпоративных технологий, у которых большая часть денег приходится на данные, очень заботятся об этом. Я пришел к выводу, что они правы, поступая так.

Трудно переоценить, насколько трудной задачей является миграция технологических платформ внутри крупного предприятия. Дорого, отнимает много времени, с огромными неисчислимыми альтернативными издержками. Эти типы миграций создают или разрушают карьеру, они определяют, насколько конкурентоспособным может быть бизнес в течение десятилетия или более. Компания со штатом в 500 человек может провести миграцию хранилища данных за 1-2-3 месяца; Компания со штатом более 10 000 человек должна нанять GSI специалистов, потратить более 1 миллиона долларов на гонорары за консультации и исключить все остальное из своей дорожной карты на год или больше.

Поэтому руководители крупных предприятий готовы платить за стратегическую гибкость. И в сегодняшнем мире стратегическая гибкость выглядит как несколько вещей:

1. Открытый исходный код и открытые стандарты. Если мне понадобится, смогу ли я запустить эту штуку самостоятельно? Я, вероятно, не хочу этого, но стратегически важно иметь такой вариант на столе.

2. Кросс-облачность. Что, если я выберу не ту лошадь для участия в скачках? Что, если мой провайдер повысит цены? Что, если…? Чем больше мои продукты не зависят от облачных технологий, тем больше у меня возможностей.

Продукт каждой из упомянутых выше компаний можно запустить на любом из трех облачных провайдеров — не похожую версию продукта, а тот же самый продукт. У Snowflake нет трёх разных диалектов SQL, по одному на каждого облачного провайдера, у них есть один. Обеспечить единое, унифицированное взаимодействие в трех облачных средах — это чрезвычайно тяжелая работа! Но это дает предприятиям именно то, что они хотят: гибкость.

Но дело не только в миграции. Речь также идет об аварийном переключении (снижение рисков), перераспределении рабочей нагрузки (оптимизация затрат) и соблюдении требований. Крупные предприятия сегодня действительно заботятся о том, чтобы быть кросс-облачными, и действительно постоянно принимают решения о покупке на этой основе.

Давайте вернемся к исходному вопросу: как эта динамика повлияет на будущую форму индустрии данных? Вот мои предположения:

1. У всех облачных провайдеров будут комплексные решения. Многие из них уже это делают, хотя эти услуги различаются по качеству и удобству использования. Они будут продолжать становиться лучше. Просто примите это за основу. Если вы сегодня создаете новый продукт обработки данных в существующей категории, вы будете конкурировать с уже существующим типом управляемого облачного сервиса. Это значительно поднимает планку создания новых стартапов.

2. Выживет только один. Наличие облачных провайдеров не предотвратит внешнюю конкуренцию из-за требований кросс-облачности, но окажет на нее давление. Вероятно, за пределами них есть место ровно для одного лучшего в своем классе поставщика данного типа продукта — примерно так обстоят дела в более широком пространстве инфраструктуры программного обеспечения.

3. Маленькие категории не смогут поддерживать себя. Для создания части кросс-облачной инфраструктуры данных требуется огромный объем работы/времени/инвестиций. Мы сами находимся на полпути к этому пути (сегодня dbt Cloud работает на AWS и Azure), и это был гораздо больший прогресс, чем я ожидал. Корпоративным клиентам это необходимо, но если данная категория недостаточно велика, чтобы поддерживать такой уровень инвестиций, в ней просто не будет игроков, готовых к корпоративному использованию. Эта категория будет объединена в другие, более крупные категории.

Итак: меньшее количество более крупных категорий будут поддерживать конкурентов, которые фокусируются исключительно на определенном продукте или услуге, и, скорее всего, в каждой категории будет один явный победитель. Я оставлю вас делать собственные ставки на то, какие категории достаточно велики, чтобы поддерживать себя.

Сложите все эти факторы вместе и что вы получите?

• Предстоит еще большая консолидация/отсеивание. Слишком много компаний не имеют рвов и категорий, которые не могут поддерживать масштабные компании.

• Новые стандарты будут продолжать менять основные силы отрасли и создавать возможности для инноваций.

Примечание

1. Хорошо, может быть, я умалчиваю о некоторых незначительных деталях брендинга или распространения на рынке оборудования и инструментов, но я думаю, что суть в целом остается неизменной.