Мои размышления о том, откуда мы пришли и куда можем двигаться.

Недавно я выступал с докладом по этой теме на конференции Sisu Future Data, и, поскольку я мыслю в прозе, а не в Powerpoint, мне пришлось оформить свои измышления на бумаге, прежде чем я смог разбить их слайды. В результате еще некоторого количества усилий на свет появилась эта статья, и я очень надеюсь, что она будет для вас полезной. Если вам интересно посмотреть мой доклад полностью, вы можете найти его запись здесь.

---

За последнее десятилетие дата-продукты привлекли к себе большое внимание, аккумулировали серьезный капитал и все продолжают набирать обороты. Они произвели огромное количество изменений в том, как работает большинство организаций, занимающихся посредничеством данных: Stitch Fix ушел вперед на миллионы миль от традиционных розничных продавцов одежды, а Airbnb совсем не похож на типичного владельца отеля. Дата-продукты также коренным образом изменили карьеру многих из нас, профессионалов в области данных, спровоцировав возникновение совершенно новых должностей и подняв их роль от чернорабочих до стратегически важных карьерных путей.

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

• Cбор: Fivetran, Stitch;

• Хранение: Snowflake, Bigquery, Redshift;

• Преобразование: dbt;

• Бизнес-аналитика: Looker, Mode, Periscope, Chartio, Metabase, Redash.

Более того, несмотря на то, что за это время в каждом из этих продуктов происходили постепенные улучшения, ни один из них принципиально не изменил свой основновной юзер экспириенс. Если бы вы заснули как Рип ван Винкль в 2016 году и проснулись сегодня, вам вообще не пришлось бы обновлять свою когнитивную картину того, как работает современный дата-стек. Больше интеграций, лучшая поддержка оконных функций, больше вариантов конфигурации, повышенная надежность… Все это очень хорошие вещи, они предполагают определенную зрелость, но и определенный застой. Что случилось с масштабными инновациями, которые мы видели в 2012-2016 годах?

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

Это кажется мне чрезвычайно важным. Люди — существа, создающие и использующие инструменты — наши инструменты определяют наши возможности и определяют их на протяжении всей истории нашего вида. Таким образом, прогресс инструментов в этой области не может не быть очень важным для нас, как для практиков. Когда я впервые использовал Redshift в 2015 году, я почувствовал, что мне дарованы сверхспособности. Когда же я наконец получу еще больше?

Моя цель в этой статье — взглянуть на современный стек данных за три разных периода времени:

• Кембрийский взрыв I, с 2012 по 2016;

• Развертывание, с 2016 по 2020;

• Кембрийский взрыв II, с 2020 по 2025.

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

Кембрийский взрыв I, с 2012 по 2016 

Когда Fishtown Analytics переехала в наш новый офис в ноябре 2019 года, первым делом я повесил на стену картину. Это было произведение современного искусства 70-х под названием Redshift, и я купил его на аукционе Everything But The House, потому что мне понравилось это название. На мой взгляд, современный дата-стек стал катализатором выпуска Amazon Redshift в октябре 2012 года, и вывешивание этой массивной картины у входа в наш офис увековечило его историческое значение.

Взгляните на даты основания главных продуктов на других уровнях современного дата-стека:

• Chartio: 2010;

• Looker: 2011;

• Mode: 2012;

• Periscope: 2012;

• Fivetran: 2012;

• Metabase: 2014;

• Stitch: 2015;

• Redash: 2015;

• dbt: 2016.

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

Хотя некоторые из этих продуктов были созданы до запуска Redshift, именно его запуск стал причиной их роста. Использование этих продуктов в сочетании с Redshift значительно повысило производительность пользователей. Looker на Postgres — это хорошо, но Looker на Redshift просто великолепен.

Эта ощутимая разница обусловлена ​​внутренними архитектурными различиями между системами MPP (массовая параллельная обработка)/OLAP, такими как Redshift, и системами OLTP, такими как Postgres. Полное обсуждение их подкапотных тонкостей выходит за рамки этой статьи, но если вы не знакомы с ними, я настоятельно рекомендую узнать о них больше, поскольку сегодня они формируют почти все, что касается современного дата-стека.

Если коротко, Redshift может отвечать на аналитические запросы, обрабатывая множество соединений поверх огромных наборов данных, в 10–1000 раз быстрее, чем OLTP базы данных.

Хотя Redshift — очень мощная MPP база данных, она была не первой. MPP базы данных были популярны еще в предыдущем десятилетии, и многие из этих продуктов имели (и имеют) фантастическую производительность. Но Redshift была первой облачной MPP базой данных, первой MPP базой данных, которую можно было купить за 160 долларов в месяц вместо 100 тысяч долларов + в год. И именно это снижение цены все изменило. В то время Redshift был самым быстрорастущим сервисом AWS.

Увеличение производительности в 10-1000 раз обычно переворачивает ваше представление о создании продуктов. До запуска Redshift самой сложной проблемой в бизнес-аналитике была скорость: попытка провести относительно простой анализ могла занять невероятно много времени даже при наборах данных среднего размера, и для решения этой проблемы была создана целая экосистема.

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

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

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

Прежде чем завершить этот раздел, я хочу вас предупредить, что мои утверждения об исторической значимости Redshift не должны восприниматься как точка зрения, касательно того, какое хранилище данных является самым лучшим на сегодняшний день. BigQuery не выпускал стандартный SQL до 2016 года и поэтому не получил широкого распространения до этого, а продукт Snowflake не был зрелым до периода 2017-2018 годов (ИМХО). На самом деле, если вы посмотрите на долю использования этих трех продуктов примерно в 2016 году, я думаю, вы увидите, что использование Redshift в 10 раз больше, чем у двух других вместе взятых. Итак, для тех из нас, кто создает продукты в современном дата-стеке, Redshift был океаном, из которого мы эволюционировали.

Развертывание, с 2016 по 2020 

Если Redshift запустил так много инноваций в 2012-2016 годах, почему все стало замедляться? Это то, над чем я размышлял с 2018 года, когда я впервые начал интуитивно ощущать снижение масштаба изменений. Я понял, что набор продуктов, которые мы рекомендовали нашим клиентам, оставался таким же с того дня, как мы запустили Fishtown Analytics, и это меня очень обеспокоило. Не упустили ли мы какие-то важные новаторские продукты? Может быть мы устарели?

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

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

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

То, что мы видели в 2005 году (когда была выпущена Vertica) и в 2012 году (когда была выпущена Redshift), было ранней фазой развития MPP базы данных — началом ее S-образной кривой. И оттуда она пошла по пути “хранение » бизнес-аналитика » сбор » преобразование”. Обратите внимание, что мы все еще находимся в начале этой кривой развертывания!

Когда я проверяю эту теорию как пользователь, она подтверждается. Я могу сказать вам из первых рук, что опыт использования буквально каждого из продуктов, которые я перечислил выше, значительно улучшился за последние четыре года. Да, Fivetran и Stitch по-прежнему перемещают данные из точки А в точку Б, но их надежность значительно улучшилась, как и их покрытие. То же самое верно и для других слоев стека. dbt, чей путь я хорошо знаю, с 2016 года был полностью перестроен, чтобы стать более модульным, более производительным и расширяемым — и все это без изменения фундаментального юзер экспириенса.

Вот как выглядит движение вверх по S-образной кривой. Ранние последователи достаточно непривередливы, но технологии должны совершенствоваться, чтобы быть принятыми все большей и большей аудиторией. С телеграфом произошло то же самое: Томас Эдисон изобрел телеграфный мультиплексор в 1874 году, что позволило Western Union в четыре раза увеличить пропускную способность существующих линий. Тот же телеграф, больше пропускная способность.

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

Кембрийский взрыв II, с 2021 по 2025

Подведем краткие итоги. Сразу после запуска Redshift в 2012 году мы увидели огромное количество инноваций, которые открыли совершенно новые уровни производительности, эффективности и новых моделей поведения. Затем мы стали свидетелями периода созревания, когда эти зарождающиеся продукты были развернуты рынком, усовершенствовали свои технологии и дополнили наборы функций. К настоящему времени эти продукты готовы выступать в качестве фундамента, на котором могут быть построены последующие инновации.

Итак, готовы ли мы к новой волне инноваций, еще одному кембрийскому взрыву. Какие типы инноваций это принесет?

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

Хорошие

Горизонтальность. Нам больше не нужно покупать целую вертикаль специализированных продуктов, чтобы проводить аналитику по конкретным вещам; мы помещаем данные в хранилище, а затем можем анализировать их все вместе с помощью общего набора инструментов. 

Быстрота. Современный стек данных является быстрым как с точки зрения итерации — подключение новых данных и их изучение не составляет труда по сравнению с 2012 годом — так и с точки зрения чистого времени выполнения запроса, поскольку прорывы в производительности MPP базы данных теперь охватывают весь стек. 

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

Низкие накладные расходы. Сложные инфраструктуры данных 2012 года требовали огромных накладных расходов — инженеров по инфраструктуре, дата-инженеров и т. д. Современный стек данных практически ничего из этого не требует. 

Одним SQL едины. В 2012 году еще не было до конца ясно, какой язык / какой API будет использоваться в первую очередь для объединения продуктов данных, и, поскольку такие интеграции были неоднородными, мало кто имел навыки взаимодействия с данными. Сегодня все компоненты современного стека данных говорят на языке SQL, что обеспечивает простую интеграцию и открывает доступ к данным для широкого круга практиков.

Плохие

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

Пакетная обработка. Весь современный дата-стек построен на пакетных операциях: поллинге и планировании заданий. Это отлично подходит для аналитики, но переход к потоковой передаче может открыть огромный потенциал для конвейеров данных, которые мы уже создаем… 

Данные не возвращаются обратно в операционные инструменты. Современный стек данных сегодня представляет собой односторонний конвейер: от источников данных к хранилищам к некоторому типу анализа данных, просматриваемых человеком на экране. Но данные предназначены для принятия решений, а решения принимаются в операционных инструментах: обмен сообщениями, CRM, электронная коммерция… Без связи с операционными инструментами огромная ценность, созданная этими конвейерами, теряется. 

Мост к потребителям данных еще не построен. Потребители данных на самом деле были более самостоятельными до появления современного стека данных: навыки работы с Excel широко распространены среди работников умственного труда. Еще не существует аналогичного интерфейса, в котором все работники умственного труда могли бы беспрепятственно взаимодействовать с данными в современном горизонтальном дата-стеке. 

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

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

Управление

Управление (Governance) — это продуктовая область, время наступило как никогда. Эта категория продуктов охватывает широкий спектр вариантов использования, включая обнаружение данных, просмотр информации о происхождении и просто общее предоставление потребителям данных контекста, необходимого для навигации по растущим следам данных внутри организаций, передающих данные. Эта проблема стала еще более актуальной из-за современного состояния дата-стека, поскольку становится все проще получать, моделировать и анализировать больше данных.

Без хорошего управления, больше данных == больше хаоса == меньше доверия.

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

Я много писал об этой теме, так как она очень тесно связана с работой, которую мы делаем с dbt. У dbt есть свой собственный очень легкий интерфейс управления — dbt Docs — и мы планируем проделать большую работу по расширению этой существующей функциональности в ближайшие годы.

Наш интерес к этой области был очень вдохновлен работой, проделанной внутри Big Tech. Многие крупные технологические компании создали довольно хорошие продукты для управления внутренними данными:

• У Linkedin есть DataHub

• У Lyft есть Amundsen

• У WeWork есть Marquez

• У Airbnb есть Dataportal

• У Spotify есть Lexikon

• У Netflix есть Metacat

• У Uber есть Databook

(Я уверен, что здесь чего-то может не хватать, поэтому приношу свои извинения, если вы связаны с проектом, название которого я не упомянул.)

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

Реалтайм

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

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

• Оперативная аналитика. У вас могут быть сотрудники, ответственные за основные операции вашего бизнеса, которым нужно знать состояние дел прямо сейчас. Инвентарь и логистика — очень распространенные потребности в этой области.

• Автоматизация процессов. Вы уже построили сложные конвейеры данных для аналитики, но что, если бы вы могли передавать эти данные обратно в CRM или платформы обмена сообщениями и запускать последующие события поверх них? Это огромная область для новых возможностей, и я расскажу об этом подробнее в следующем разделе.

Таким образом, данные в реальном времени, безусловно, не нужны для основных вариантов использования современного стека данных сегодня, но сокращение задержки всего конвейера до 15–60 секунд может открыть совершенно новые варианты использования этой технологии. В конечном счете, “нервная система”, отвечающая за ваши операционные отчеты, может быть той же системой, которая поддерживает и другие варианты использования.

И мы начинаем получать отчетливые сигналы о том, что эта технология уже находится в пределах досягаемости. Каждое из крупных хранилищ данных имеет первоначальную поддержку конструкций, которые обеспечивают больше потоков в реальном времени: Snowflake в значительной степени опирается на функциональность своих потоков, а Bigquery и Redshift делают упор на свои материализованные представления. Оба подхода двигают нас в правильном направлении, но, насколько я могу судить, ни один из них сегодня не приводит нас к цели. Инновации в этом направлении от всех трех поставщиков еще не исчерпали себя.

Еще одна интересная тема — KSQL, потоковая конструкция SQL поверх Kafka. Это, безусловно, интересно и многообещающе, но есть некоторые ограничения на SQL, который могут встать на пути (особенно в отношении джоинов), так что для меня это тоже попадает в кучу “не совсем готово”.

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

Наконец, даже если сама база данных поддерживает обработку в реальном времени, прием данных также должен осуществляться в реальном времени. Вот почему я в восторге от продукта под названием Meroxa — “plug and play” CDC из реляционных хранилищ данных и веб хуков. Подобные продукты станут важной развязкой, которая приведет нас в мир потокового вещания; добровольцев идти администрировать Debezium много я не наблюдаю.

Мы еще не совсем там, но вы можете начать видеть, как прорисовывается форма. Она окончательно оформится в течение следующих нескольких лет, и это будет потрясающе.

Завершение цикла обратной связи

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

Здесь существует огромное количество потенциальных вариантов использования. Я просто перечислю некоторые самые основные из них:

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

• Точно так же специалисты по продажам проводят все свое время внутри своей CRM. Передавайте данные о действиях пользователей продукта непосредственно в их интерфейс CRM, чтобы они могли вести беседы, наполненные большим контекстом.

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

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

Я пишу хакерские скрипты для облегчения этого типа перемещения данных с 2014 года, но мы, наконец, начинаем видеть, что инструменты в этой области набирают обороты. Census и Tray — это только те, с которыми я больше всего знаком, но я уверен, что есть и другие, о которых я не знаю.

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

Следите за этой областью — это произойдет быстро.

Демократизированное исследование данных

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

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

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

Задача здесь нетривиальная. Без мощного и гибкого инструмента для самообслуживания потребителей данных перспектива современного стека данных навсегда останется для избранных. Это плохой исход.

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

Я видел две многообещающие идеи-кандидата. Сначала занесите данные в электронную таблицу. Почти каждый продукт бизнес-аналитики может делать плохую версию этого: “скачать как Excel”. Но это не очень хорошее решение — оно сразу отрезает вашу электронную таблицу от остальной инфраструктуры данных. Как я упоминал ранее, взаимосвязанные электронные таблицы и оперативное обновление всегда были важным аспектом прежнего статуса-кво по образу и подобию Excel.

Лучшая версия этого больше похожа на процесс “синхронизации с Google Sheets”, при котором электронная таблица поддерживает связь с источником данных, а данные периодически обновляются. Затем пользователь может делать работу поверх исходных данных на дополнительных вкладках. Лучшей реализацией этого подхода, которую я видел, является продукт под названием SeekWell. Очень многообещающий.

Вторая идея-кандидат — использовать электронные таблицы для создания формул, которые компилируются в SQL и выполняются в базе данных. По сути, ваш интерфейс электронной таблицы — это просто еще один пользовательский интерфейс для запроса данных непосредственно в хранилище, но тот, который более широко понимается потребителями данных. Этот подход лучше всего иллюстрируется продуктом под названием Sigma Computing, и вы можете увидеть его в действии здесь. В конечном счете, это не обеспечивает полной совместимости с электронными таблицами, потому что вы вынуждены придерживаться очень ограничивающей парадигмы “одна формула на столбец”, но, тем не менее, я думаю, что это интересный подход к проблеме.

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

Здесь нет никаких технических препятствий — все строительные блоки уже на месте. Самое сложное — разобраться с юзер экспириенсом.

Вертикальный аналитический опыт

В мире веб-аналитики 2012 года существовала огромная и вопиющая проблема, когда Google Analytics, Mixpanel и KissMetrics были единственными игроками в городе: они были исходными базами данных. Единственный способ, которым вы могли получить доступ к данным из этих инструментов, был через их графический интерфейс, и вы не могли соединить их с данными, которые у вас были где-то еще. Если вы действительно хотели включить данные из других систем, вам нужно было отправить их как событие, что приводило к дублированию данных. Любой, кто управлял даже отдаленно зрелой организацией данных, знает, во что это в итоге выливается.

Эта эпоха привела к обилию различных вертикальных хранилищ данных, которые имели свои собственные копии данных, которые были залочены внутри проприетарного интерфейса. Именно это обилие источников данных вызвало огромную долю спроса на хранилища данных. НО! Вместе с водой мы выплеснули из ванны и ребенка.

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

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

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

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

Полезен ли был этот рассказ?

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

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

---

Сегодня в 20:00 пройдет бесплатный онлайн-интенсив «Extract - Load как сервис и как собственное решение. Поиск баланса и дзен», на котором разберем:

• Extract-Load через SaaS решения. Возможности готовых сервисов, их надежность и ограничения.

• Extract-Load через API-вызовы, обращения к СУБД и CDC – оптимальные способы реализации.

• Автоматизация выгрузки, повторные попытки (retries), получение уведомлений в Slack (notifications) с помощью Airflow.

• Накопление истории выгрузок и организация Data Lake в S3 перед DWH.

Регистрация для всех желающих доступна по ссылке.