В этом посте представлен перевод статьи на dbt от Tristan Handy. Перевод подготовлен при поддержке сообщества аналитического курса DataLearn и телеграм-канала Инжиниринг Данных.

Мои мысли о том, где мы и куда можем прийти

Недавно с такой темой я выступил на конференции Future Data*, организованной Sisu, и поскольку мыслю я в прозе, а не картинками в PowerPoint, мне пришлось написать пост, прежде чем собрать все слайды вместе. (*Речь о первой ежегодной конференции, которая состоялась осенью 2020 года — прим. переводчика) Немного времени мне потребовалось на то, чтобы всё это отшлифовать и опубликовать, и, надеюсь, для вас материал окажется ценным. Если хотите услышать выступление полностью, вы можете сделать это здесь.

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

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

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

• Сбор: Fivetran, Stitch;

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

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

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

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

Скажу для ясности, что всё это относится к dbt точно так же, как и к любому другому упомянутому выше продукту. Сравнив dbt примерно 2016 года с dbt примерно 2020 года, вы обнаружите, что, хотя современная версия сильно мощнее, основной пользовательский интерфейс очень похож. Цель моего поста — не оклеветать, а постараться понять динамику продуктовой экосистемы, на которой все мы строим свои карьеры.

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

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

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

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

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

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

Кембрийский взрыв, с 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, первой, которую можно было купить за 160 долларов в месяц вместо сотен тысяч долларов в год. И вместе со снижением цены внезапно открылись возможности. Redshift был в то время самым быстрорастущим сервисом AWS (Amazon Web Services).

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

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

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

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

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

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

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

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

Оказывается, это нормальный цикл, через который проходят отрасли. Выпускается передовая технология, она стимулирует множество инноваций, а затем эти продукты проходят стадию развёртывания, пока компании принимают их. Посмотрите, как это происходит  во время самых масштабных технологических сдвигов. На самом деле, я просто поискал «общее количество миль железнодорожных путей» (“cumulative miles of railroad track”), собрал некоторые данные, — и вуаля! — s-образная кривая:

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

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

Что мы увидели в 2005 (когда вышла Vertica) и в 2012 (когда вышел Redshift), так это ранняя фаза развития  массово-параллельной архитектуры (MPP) — начало её s-образной кривой. И с того момента: хранилище >> BI >> приём >> преобразование. Обратите внимание, мы всё ещё остаёмся на ранней стадии кривой развёртывания.

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

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

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

Второй Кембрийский взрыв, с 2020 по 2025

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

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

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

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

Управление

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

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

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

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

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

• У Linkedin — DataHub;

• у Lyft — Amundsen;

• у WeWork — Marquez;

• у Airbnb — Dataportal;

• у Spotify — Lexikon;

• у Netflix — Metacat;

• у Uber — Databook.

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

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

???? Если бы вы хотели глубже погрузиться в эту тему, Дрю проведёт обсуждение метаданныхв Coalesce на следующей неделе.

Режим реального времени

Если вы просто создаёте дашборд, чтобы задавать аналитические вопросы, вы можете не переживать об актуальности данных. В действительности, получение новых данных раз в день может быть достаточно адекватным для ответов на запросы о прибыли, поведении когорты, трендах среди активных пользователей. Но на самом деле существует много потенциальных возможностей использования инфраструктуры данных, которую мы строим как часть современного стека, которые <возможности> могут выходить далеко за рамки того, что мы обычно называем «анализом данных». Вот несколько примеров:

• Внутренняя аналитика продукта

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

• Оперативные сведения

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

  ???? Это было важным фактором для JetBlue, вероятно, вы услышите об этом от Ashley в её выступлении на Coalesce... или спросите её об этом в рабочее время в Слаке.

• Автоматизация процессов

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

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

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

Другое интересное направление здесь — KSQL, потоковый SQL на основе Kafka. Это определённо интересно и многообещающе, но есть некоторые ограничения , связанные с SQL, который может быть выполнен (особенно в отношении объединений), так что для меня он тоже попадает в стопку «не совсем того».

На арене новых продуктов я впечатлён Materialize. Это Postgress-совместимое хранилище данных, которое изначально поддерживает материализованные представления в режиме почти-реального-времени, построенное с нуля на основе идей потоковой обработки.

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

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

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

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

Есть огромное множество потенциальных вариантов использования этого. Я перечислю несколько самых базовых:

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

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

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

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

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

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

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

???? Если вы хотите погрузиться в эту тему, присоединяйтесь к The Future of the Data Warehouseна Coalesce на следующей неделе.

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

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

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

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

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

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

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

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

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

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

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

Опыт вертикального анализа

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

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

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

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

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

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

Полезный материал?

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

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