Аналитики становятся лучшими инженерами по аналитике

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

Итак, у вас есть бизнес-вопрос, у вас есть сырые данные в вашем , и у вас настроен dbt. Вы в идеальной позиции, чтобы быстро завершить создание этого подготовленного набора данных! Или нет?

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

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

"Нам нужно отслеживать использование нашего продукта, и мы хотели бы иметь данные о Активных Пользователях."

Аналитики — эксперты в том, чтобы превращать общие заявления в конкретные задачи.

"Некоторые данные" могут означать:

1. Один KPI с трендом во времени
2. Панель управления, разбитая на различные категории
3. Таблица, доступная для фильтрации и запросов для разовых анализов

"Активные Пользователи" могут означать:

1. Пользователи, которые вошли в систему в течение фиксированного периода времени
2. Пользователи с сессией, длившейся дольше определенного времени
3. Пользователи, взаимодействовавшие с определенной функцией

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

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

Быстро становится очевидным, что это стремление к линейному процессу часто приводит к созданию трех непредвиденных "циклов":

Цикл 1: Реакция на находки в сырых данных

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

Аналитики уже знают, какие данные они хотят.

Если в сырых данных Login ниже содержатся два разных поля даты (Login_Date и Session_Date), инженер по данным застрянет. Они не могут просто угадать, потому что использование неправильного поля даты создаст совершенно другую метрику! Поэтому они должны вернуться к аналитику, чтобы уточнить, какое поле использовать. Мы только что прошли полный цикл с двумя передачами, и инженер по данным даже не начал строить модель.

Login_Date	Session_Date	User_Id
2022-08-01	2022-08-01	123
2022-08-01	2022-08-03	123
2022-08-04	2022-08-04	975
2022-08-04	2022-08-04	NULL

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

Если бизнес-потребность включает просмотр Активных Пользователей по Группам A, B и C, то это добавляет дополнительный уровень сложности. Без инженера по аналитике вы увидите дополнительные циклы и передачи для окончательной настройки всей бизнес-логики, обработки NULL значений и даже просто окончательного формата.

Формат модели, возвращаемый инженерией данных

Date	Active Users Group A	Active Users Group B	Active Users Group C
2022-08-01	34	60	61
2022-08-02	77	86	37
2022-08-03	71	9	6
2022-08-04	63	87	10

Формат модели, необходимый для BI инструмента

Date	Group	Active Users
2022-08-01	Group A	34
2022-08-01	Group B	60
2022-08-01	Group C	61
2022-08-02	Group A	77
2022-08-02	Group B	86
2022-08-02	Group C	37

Цикл 2: Реакция на неожиданные результаты

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

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

Аналитики ставят под сомнение все.

Группа A для Активных Пользователей может быть сосредоточена на ролях Участник. Заинтересованная сторона объяснила аналитику, что они хотят исключить любых Администраторов, которые будут иметь другой опыт работы с продуктом.

User_Id	Location	Role	Level	Zone
123	California	Editor	AAA	1
427	Utah	Participant	ABA	1
864	Georgia	Admin	CCC	3

Инженер по данным, работающий по "списку задач", добавит фильтр WHERE Role = 'Participant'. Во время шага проверки данных аналитик обнаружит, что существует третья роль Editor, о которой никто не знал. Это создаст цикл, в котором инженеру по данным придется изменить модель, заменив ее на WHERE Role != 'Admin'.

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

Как мы все знаем, проверка данных — это искусство, а не наука. Аналитики используют все, от "теста на запах" (просмотр случайной выборки строк) до индивидуальных примеров (точное сопоставление один к одному с другой системой). Аналитик должен использовать свой опыт, чтобы знать, когда набор данных "достаточно хорош" для заинтересованной стороны и ее вопроса, поскольку 100% точность может не быть целью. И если быть честным, иногда достаточно просто быть направленно правильным, чтобы принять бизнес-решение.

Аналитик может определить, какие области не нуждаются в 100% точности, что означает, что они также могут определить, какие области должны быть на 100% точными.

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

Когда проблемы с качеством данных выявляются бизнесом, мы часто видим, что аналитики первыми задаются вопросами:

• Почему более половины User_Ids теперь показываются как NULL?
• Почему этот график показывает Location пользователя, который не находится в США?
• Почему фильтр на панели управления говорит, что все Zones пользователей — это Зона 2?

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

Цикл 3: Реакция на несоответствующую документацию

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

Аналитики понимают боль плохо документированного набора данных.

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

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

Если мы хотим узнать, как определенная логика была построена технически, мы можем обратиться к SQL-коду в dbt docs. Если мы хотим узнать почему определенная логика была встроена в эту конкретную модель, то для этого мы обратимся к документации.

• Пример не очень полезной документации (dbt docs может создать это динамически):
  • Case when Zone = 1 and Level like 'A%' then 'True' else 'False' end as GroupB
• Пример более полезной, описательной документации (добавьте в ваш dbt markdown файл или описания столбцов):
  • Группа B определяется как Пользователи в Зоне 1 с Уровнем, начинающимся с буквы 'A'. Эти пользователи получают доступ к нашему новому дополнительному продукту, который начался в Бета-версии в августе 2022 года. Рекомендуется исключить их из основной метрики Активных Пользователей.

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

Вы убеждены?

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

Вместо того чтобы пытаться определить все различные группы Активных Пользователей сразу, инженер по аналитике может проверять строки Группы A, добавляя Группу B в свою локальную среду, и одновременно работать с заинтересованной стороной над определением Группы C.

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

Как помочь вашим аналитикам повысить их навыки

Вот несколько следующих шагов, чтобы начать преобразование ваших аналитиков в инженеров по аналитике:

1. Многие аналитики уже очень комфортно работают с запросами данных, используя SQL Select операторы. Для тех, кто этого не делает, предложите им начать извлекать данные для разовых запросов, используя SQL. Попросите их сравнить некоторые из общих преобразований в вашем BI инструменте с SQL функциями или воссоздать их, используя CTE. Это подготовит их к изучению SQL моделей dbt.
2. Начните включать взаимную проверку как часть процесса публикации панели управления. Также подумайте о том, как вы настраиваете свои среды панели управления (есть ли у вас локальная область разработки, область проверки и опубликованная область?). Это подготовит их к изучению Git, сред разработки и контроля версий.
3. Поговорите с вашим аналитиком о том, как они решают создавать оповещения в вашем BI инструменте или какие регулярные проверки они проводят для существующих панелей управления на предмет точности данных. И какие текущие практики управления данными следуют каждой панели управления (Словарь данных? Руководство по стилю?). Это подготовит их к изучению файла dbt .yml.

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