Что только нам не обещали с появлением Big Data. Мы будем прогнозировать продуктовый спрос и вспышки болезни, научим нейросети рисовать картины и сочинять романы, от которых плакал бы сам Достоевский (воссозданный теми же нейросетями по дневникам, портретам и рассказам современников). Что-то из этого уже в каком-то виде увидело свет — и это круто. Но большинству компаний это неинтересно и не нужно. Вместо суперсовременной архитектуры с плюшками-свистелками мы ищем сермяжные аналоги наших старых хранилищ, но быстрее, дешевле и полегче в настройке. И это наглядно видно на примере кейсов Databricks и Snowflake.

Databricks — это ошибка стоимостью в 38 млрд долларов. 

Восьмая по величине частная технологическая компания в мире с годовым доходом в 800 млн долларов — с одной стороны, любой из нас хотел бы совершить такую ошибку. С другой, сложно не заметить, что Databricks пытаются запрыгнуть в последний вагон. И судя по головокружительным успехам их конкурентов — стоимость Snowflake составляет 70 млрд долларов даже после внушительного пятимесячного снижения ее акций, а доходы BigQuery, по слухам, достигают 3 млрд долларов в год — возможно, пару раз радикально сменив свою стратегию, Databricks имели бы куда больше перспектив, чем сейчас (да, это спекуляция).

Впервые я услышал о Databricks в 2014 году. Они тогда наделали много шума в Кремниевой долине. Основатели Databricks — блестящие ученые-компьютерщики, поневоле ставшие предпринимателями. Они заново открывали большие данные, а это означало заново открыть весь мир. Темпы роста зашкаливали, перегруженные продавцы уже не отвечали на звонки. 

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

А мне была нужна база данных. В то время я как раз разворачивал современный (ну или не очень) стек данных: Segment, Fivetran и Mode, а в центре всего этого — Redshift (славные были времена). И Redshift, хоть и работал довольно неплохо, начал доставлять определенную головную боль. Приходилось постоянно тасовать пару больших таблиц между ним и S3, а страница, отображающая состояние кластера, постепенно забивала мой список быстрого доступа в Chrome. 

В конце концов, после неудачной попытки мигрировать на Athena и Spectrum, мы решили пройтись по всему рынку и поискать варианты. Нашим основным фаворитом стал BigQuery. Он был фантастически быстрым, не требовал никакого управления, и как раз недавно несколько клиентов рассказали нам, как перешли с Impala на BigQuery. На звонок из компании Snowflake мы ответили скорее из чувства долга — просто чтобы убедиться, что мы посмотрели все варианты. 

Презентация Snowflake оказалась одновременно и самой бестолковой, и самой эффективной из всех презентаций продукта, которые я когда-либо видел. Нам рассказали, что это то же самое, что и Redshift, и в общем то же самое, что и Postgres, только больше, быстрее и стабильнее. Там не было прилизанных слайдов со стоковыми фотографиями симпатичных специалистов, толпящихся вокруг компьютера с подозрительно замазанным брендом. Мы не услышали отзывов клиентов из банковских управляющих, как их пятилетние планы были реализованы в срок и с экономией бюджета. Никаких вымученных упоминаний о цифровых трансформациях, распределенных системах или, боже упаси, блокчейне. Они даже не объясняли нам, как именно мы можем использовать Snowflake. Нам предложили и дальше делать то, что мы делали — просто если мы приспособим к этому Snowflake, то они возьмут на себя хостинг всего, будут делать резервные копии в свое бесконечное хранилище, а наши запросы будут выполняться куда быстрее, чем раньше — в общем, сплошные плюсы и никаких минусов, прямо рост эффективности по Парето.
(Что они не сказали, так это то, что тулза будет орать на нас ВСЯКИЙ РАЗ КОГДА МЫ ПИШЕМ ЗАПРОС). 

Эта презентация (и Snowflake) отлично сработали. Мы, как в Snowflake и планировали, начали использовать их продукт так же, как Redshift. Потом быстро привыкли к его скорости и масштабу, и стали находить ему все новые варианты применения. Вместо того, чтобы возиться с точной настройкой инкрементных нагрузок в dbt, мы начали делать больше полных обновлений. Мы перестали тщательно проверять, какие именно журналы ведутся в нашем хранилище. Нашли новые способы предоставлять данные клиентам. Не ради этого мы покупали Snowflake (и будем честны, оно бы того не стоило), но раз уж возможности были, почему бы ими не воспользоваться? 

За все время поисков и выборов мы ни разу не вспомнили о Databricks. 

А стоило бы. Databricks, как и Snowflake, предлагает быструю, размещаемую на хостинге поставщика базу данных с практически бесконечными возможностями масштабирования. Но их база поддерживает больше языков, что могло бы открыть целые классы новых приложений. И если бы они были доступны, мы бы с удовольствием попробовали их в работе. Но на тот момент мы не смогли составить целостного впечатления, потому что коммерческое предложение Databricks звучало как белиберда. Презентация Snowflake была скучной, но на тот момент — по крайней мере, в начале — нам именно это и было нужно.

Данные для среднего класса

Когда про историю современного стека данных будут писать книги (а если нам повезет, то Apple снимет документалку), в основу сюжета лягут два момента. Первый — как компания dbt Labs прошлась по всей экосистеме в 2020 и 2021 гг., второй — первичное размещение акций (IPO) компании Snowflake. 

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

Многие годы о данных говорили так, словно это огромная колода технологических карт Таро. В загадочных специальных отчетах журнала Economist предсказывали, что мы катимся в будущее, управляемое цифровыми мистиками из фильма «Особое мнение». Ключевые мероприятия отрасли, финансируемые первым эшелоном компаний в области Big Data вроде Cloudera, Hortonworks и MapR, продвигали ту же концепцию: «Мы обладаем тоннами данных, и с их помощью мы изменим мир».

Но потом концепция полностью изменилась. На смену абсолютно непонятным технологиям пришли технологии скучные — например, большая база данных Postgres стоимостью свыше 50 млрд долларов или шаблоны SQL с открытым исходным кодом. Фокус обсуждений сместился с экзотических проблем на обычные. Несмотря на все, что говорилось о конференции Data Council, в одном аспекте она была ближе к реальности, чем практически все предыдущие конференция по теме: на ней обсуждались проблемы из реальной жизни. Например, в 2014 году Strata, на тот момент ведущая конференция по данным, включала доклады на следующие темы: ​«Визуализация информации для крупномасштабных рабочих процессов с данными», «Масштабирование диаграмм с помощью дизайна и графических процессоров», а также «Знакомство с Hadoop и его потенциалом для активизации новой модели информационной архитектуры». Ни в 2014 году, ни когда-либо еще большинство компаний на рынке не сталкивались с этой проблемой. Большая часть тем с конференции Data Council узконаправлена, но при этом знакома любой команде по обработке данных: как отследить происхождение данных, как провести эксперимент, как управлять результатами.

Эти темы отражают базовые приоритеты для таких компаний как Snowflake и dbt: «Наши проблемы не новы, мы не хотим переосмысливать, заново изобретать или радикально менять текущие методы их решения, мы не хотим уходить в тёмный лес новых инноваций. Нам подойдут старые добрые базы данных и SQL – плюс немного современной магии». 

Скучная отрасль

Думаю, что со временем и остальная часть отрасли последует за Snowflake и dbt: от технологического хайпа и вверх по «склону просветления». Для большинства из нас это означает принятие обыденных вещей, разговоры о проблемах, а не технологиях, и учет большего количества мнений профессионалов.

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

Для Databricks — будьте скучными. Где-то существует версия Databricks, построенная на базе отполированной документации по Data Science Platform™. На ее веб-сайте страниц «Решение» больше, чем страниц «Продукт», фокусируется она на том, какие задачи решает, а не что умеет. А описывается она как безмятежный оазис посреди гигантского хаоса энтерпрайзного дата менеджмента (никаких данных, никаких частиц, только позитивные вибрации).

Такой подход десятилетиями продавал ПО компаниям, так что и в этом случае он определенно сработает. Но рискну предположить, что еще лучше будет продавать совсем простой слоган: «Databricks — это большая и быстрая база данных, для которой можно писать на языках SQL и Python».

Databricks не нужно продавать платформу как новую архитектуру для универсальной платформы искусственного интеллекта — продавайте его как централизованное хранилище. Такой подход превратил Oracle в компанию с оборотом в 220 млрд долларов и принес компании Microsoft 5 млрд долларов в 2014 году. Реально быстрое решение, которое размещается у поставщика и обладает неограниченным хранилищем, к которому можно обращаться напрямую на языках Python и R.

Не надо продавать его как что-то новое — продавайте его как замену моего обычного хранилища, просто больше, быстрее и с поддержкой большего количества языков. Не надо продавать мне варианты использования и истории успеха — продайте мне эту схему. И когда я куплю его из-за этого (а я куплю), то дальше я открою все остальные возможности Databricks, как это было со Snowflake.

(я конечно не CIO компании из Fortune-500, так что мое мнение по этому поводу может и вовсе ничего не значить. Как я уже сказал, я просто пользуюсь моментом)

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

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

Но если бы кто-нибудь пришел и предложил мне потоковый Fivetran или реактивную версию dbt, я бы согласился. Если бы стоимость архитектуры реального времени была достаточно низкой вне зависимости от притянутых за уши сценариев использования, не было бы причин отказываться от нее. И я уверен, что так же, как мы оставили Postgres ради более эффективного аналога Snowflake, мы перешли бы и на потоковые конвейеры, если бы они заменили наши текущие пакетные. Мы бы начали проводить больше маркетинговых кампаний или выстраивать успешные рабочие процессы на основе поведения клиентов здесь и сейчас. 

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

То же самое может относиться и к другим инструментам, таким как платформы дополненной аналитики и приложения ИИ типа Continual. Что касается Continual, у большинства из нас нет срочной необходимости обогащать конвейеры данных моделями машинного обучения. Однако если бы барьер для их использования был достаточно низок — если бы мы могли легко классифицировать должности потенциальных клиентов или добавлять показатели здоровья в модели клиентов, не жертвуя ничем из уже работающих конвейеров, — многие из нас начали бы их использовать. 

Эрик Бернхардссон выявил похожую динамику в разработке программного обеспечения. Небольшие предприятия типа зубного кабинета, которые практически не используют в работе ПО, стали делать свои первые веб-сайты не потому, что внезапно почувствовали в этом нужду, а потому, что это стало дешево. Этот первый шаг с мотивацией «а почему бы и нет» вызвал лавину новых запросов: если у вас уже есть веб-сайт, почему бы не использовать его для записи на прием? Почему бы не создать систему информирования пациентов? Почему бы не запустить рекламные объявления, которые будут направлять людей на сайт? Если люди особо не нуждаются в чем-то, но при этом признают, что это что-то неплохо бы иметь, то один из лучших способов вызвать рост рынка — облегчить для них возможность приобрести это. 

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

Любите вы работу с большими данными или с чем-нибудь ещё, Geekfactor.io не принципиально. Если ищете работу, напишите нам — мы подберём для вас что-нибудь подходящее.

• Как мигрировать компанией за неделю и никого не потерять. История Monite

• 9 причин перейти с Python на Go

• Почему технические собеседования — пустая трата времени