Как быстро и эффективно обрабатывать данные
Глава 10Инжиниринг данных
Мы с вами уже разобрались, какую пользу приносят данные бизнесу, рассмотрели их жизненный цикл, основополагающие направления работы с ними и знаем, по какому принципу они собираются и где хранятся. Но что делать дальше? Как использовать данные максимально быстро и эффективно?
Чтобы найти ответ, определим основную проблему, с которой вы можете столкнуться на данном этапе. Зачастую код для обработки данных пишется вручную. Он выходит громоздким и влечет за собой дополнительные трудности. И вместо работы с данными команде приходится управлять огромным количеством скриптов. Справиться с таким объемом без нужных знаний и подходящих инструментов практически невозможно, любые попытки ситуацию только ухудшают:
• Программист пишет кучу скриптов.
• Они постоянно ломаются, в них возникают ошибки, а еще – появляются новые запросы, из-за чего нужно писать новые скрипты.
• Они тоже ломаются, поэтому их тоже надо чинить и обновлять.
В итоге вместо того, чтобы развивать аналитику и внедрять новые крутые решения, люди просто вязнут в болоте из круговорота скриптов, которые надо постоянно обновлять и возвращать к жизни.
Что же делать?
С самого начала важно правильно организовать процесс работы с данными. Так мы сможем избежать проблем, описанных выше. Для этого необходимо разработать систему работы с записями, соответствующими вашим бизнес-задачам.
Инжиниринг данных, то есть организованный процесс обработки информации, позволяет оптимально использовать ресурсы.
Он включает:
• Выбор и настройку подходящих инструментов.
• Регулирование сбора, хранения и использования данных.
В идеале необходимо создать собственный пайплайн для обработки данных (мы подробно поговорим о нем чуть позже). А сейчас вспомним, какой специалист аналитического отдела поможет нам с разработкой инфраструктуры для сбора и обработки данных. Мы упоминали его в первой части, и это инженер данных.
В широком смысле инжиниринг данных – это процессы сбора данных и подготовки их для анализа. А инженер данных – специалист, отвечающий за эти процессы. Однако его задачи значительно шире.
Инженер данных организует работу с ними так, чтобы остальные сотрудники занимались своими непосредственными обязанностями, не отвлекаясь на посторонние задачи, связанные со сбором и хранением информации.
Рассмотрим на примере инжиниринга данных приложения по организации здорового питания.
Чтобы понять, насколько эффективно работает продвижение и маркетинг, компания изучает информацию об использовании приложения и данные из рекламных кабинетов.
Рис. 17. Интерфейс рекламного кабинета
Пошагово весь процесс сбора и подготовки информации выглядит так:
1. Данные собираются. Компания регулярно закупает digital-рекламу, чтобы пользователи узнавали о приложении. Собрав всю информацию о рекламных кампаниях в хранилище данных, можно сделать выводы об эффективности рекламы.
Есть несколько способов получить эту информацию: собрать скриптами самостоятельно или воспользоваться специальными коробочными продуктами.
2. Данные готовятся к преобразованию. Скрипты и коробочные продукты, в свою очередь, сохраняют данные в том виде, в каком API рекламного кабинета передает их по умолчанию. Этого может быть недостаточно: потребуется преобразование данных в пригодный для анализа формат.
3. Кроме того, информацию нужно проверить на достоверность, исправить найденные ошибки. Все это можно делать как вручную, так и с использованием специальных инструментов для трансформации данных. Одним из популярных сегодня является dbt (data building tool).
4. Данные объединяются и преобразуются. Чтобы построить, допустим, анализ когорт или сделать выводы об успехах продукта, одних рекламных данных будет недостаточно. А потому на этапе преобразования создают так называемые staging-витрины – промежуточные таблицы для хранения и расчета информации. В них объединяются внутренние и внешние сведения, данные из разных рекламных кабинетов (информация будет в разрозненном виде), результаты биллинга.
5. Строятся финальные аналитические витрины. В итоге для аналитика нужна витрина, содержащая данные о пользователях и сведения о рекламных экспериментах (например, затраты на них и полученные доходы). Построив такую финальную витрину, мы можем обратиться к ней через различные BI-инструменты и построить аналитическую отчетность.
Для чего нужны все эти шаги?
Компании, которая заботится о своих аналитических процессах, важно не только получать данные для анализа, но и преобразовывать их. Данные нужно делать максимально удобными для работы (вспомним о стандартизации и нормализации), лишь тогда можно будет составить корректные отчеты и дашборды. Этим тоже занимается инженер данных. Он создает специальную систему, обрабатывает информацию и помогает настроить хранение данных.
Глава 11Пайплайн и стек данных
Именно пайплайн и стек данных приходят на помощь инженеру, перед которым стоит задача сделать данные всегда доступными для обработки и анализа. Давайте разберем подробнее, что это такое и зачем нужно.
Специалисты называют пайплайном данных (data pipeline) процесс обработки информации и ее перехода из состояния А в состояние Б. Если объяснять на простом примере, то это похоже на процесс приготовления пасты с креветками из отдельных ингредиентов с помощью пошагового рецепта: пайплайн данных разделен на этапы так, что один процесс преобразования информации плавно переходит в другой. А в итоге мы получаем готовый дашборд.
По существующим стандартам обработки данных пайплайн должен охватывать:
• сбор данных;
• их первичную трансформацию и хранение – очередность этих процессов может меняться;
• дальнейшую обработку данных и получение результатов.
Обратимся ненадолго к истории появления пайплайна. Это поможет вам лучше понять его суть.
К началу XXI века сформировались две тенденции, развивающиеся до сих пор:
1. Постоянный прирост данных.
2. Непрерывное усложнение их обработки.
Первыми со взрывным ростом объема данных столкнулись поисковые системы. Их специалистам предстояло решить вопрос масштабирования поискового индекса. При этом серверы физически были разбросаны по всему миру, а ресурсы – ограничены. Гонку выиграл Google. Инженеры корпорации построили высокомасштабируемую архитектуру для работы с информацией.
Пайплайн – это еще и выстроенные в систему стадии изменения данных. Если возвращаться к аналогии с готовкой, то это комплекс ваших действий в ходе выполнения рецепта, процесс преобразования исходных продуктов в задуманное блюдо. Иногда пайплайном называют план трансформации данных. При этом важно понимать, что и зачем изменяется, на каком этапе и где используется. Как это выглядит на практике? Рассмотрим пример.
Наша команда LEFT JOIN работала с французской компанией Aircall, занимающейся виртуальной телефонией. На тот момент я уже отошел от штатной работы и консультировал совершенно разные компании по любым вопросам в сфере аналитики. И однажды руководитель обратился ко мне с просьбой отладить инжиниринг данных в его фирме.
Что у компании было?
Логи – JSON-файлы, которые хранились в Amazon S3. В них была собрана вся возможная информация о звонках (время их начала, длительность, переводы с линии на линию и так далее).
Что мы сделали?
Использовали инструмент AWS Glue, который позволяет писать разные скрипты на языке Python для DAG’ов, преобразующих данные из JSON-файлов в реляционную форму, доступную для анализа современными BI-инструментами.
Из набора таких направленных графов выстроили пайплайн для преобразования и объединения данных.
Мы создали аналитические витрины, позволяющие видеть и анализировать ключевые показатели компании с помощью инструмента Looker. Он уже был внедрен в работу компании до нас.
Весь процесс занял примерно полтора месяца, а порядок в данных мы навели на годы вперед.
Добавим, что пайплайн – это непрерывный процесс, где предыдущий этап плавно переходит к следующему. Обработка информации может подразумевать как линейный переход от одного этапа исключительно к следующему, так и нелинейный. Во втором случае переходы между этапами зависят от особенностей процессов получения данных.
Стек данных – это система программ, которые помогают автоматизировать обработку данных. Иными словами, это большой механизм, работающий с информацией с момента входа и до начала анализа. Если мы опять вспомним пасту с креветками, то стеком будут кастрюли, конфорки, вода, электричество, плита – все то, что поможет нам превратить сырые продукты в ароматное вкусное блюдо.
Задача стека данных – не заменить специалиста, а создать для него комфортные условия работы. Рассмотрим подробнее, как появился стек и как он устроен.
Предшественник современного стека данных – это так называемый традиционный стек. Он появился несколько десятилетий назад, когда применение вычислительной техники стало массовым, а облачных сервисов еще не было.
Компании разрабатывали так называемые коммерческие базы данных. Одной из самых популярных была Oracle. Чтобы использовать эту базу, требовалось регулярное взаимодействие с поставщиком и командой внутренних специалистов, управляющих ее работой.
При этом процессы трансформации данных строились с применением других решений, таких как Teradata. Эти программные компоненты должны были устанавливаться внутри компании: соответственно, необходимо было администрировать оборудование и установленный софт.
Рис. 18. Традиционный пайплайн обработки данных
После 2000-х годов стали популярны так называемые решения MapReduce для повышения эффективности сложных вычислений. Для этого компании внедряли структуру хранения данных, чаще всего Hadoop, и строили кластеры на ее основе. Все эти механизмы позволяли стандартизировать обработку информации, сделать процесс дешевле и уменьшить долю ошибочных решений. Однако они очень быстро устарели. И вот три главных причины, почему от них пришлось отказаться:
• Низкая эффективность. Традиционный стек требует сложной инфраструктуры, и его создание занимает много времени. Попытки его изменить или улучшить вызывают серьезные сбои в работе.
• Медленная адаптация к новой информации. На выполнение рутинных операций тратится слишком много времени, оперативно принимать важные решения при этом невозможно.
• Неоправданно высокие затраты. Установка и поддержка традиционного стека данных требует привлечения огромного количества специалистов. На закупку оборудования нужны деньги, как и на попытки оптимизировать локальную инфраструктуру.
Рис. 19. Кластерная структура хранения данных, которая была призвана повысить эффективность вычислений
Все перечисленное вызывает ряд системных проблем, снижая эффективность работы как стека, так и команды специалистов.
Современный бизнес нуждался в актуальном решении, ориентированном на регулярные аналитические отчеты и требующем минимального написания скриптов.
И главное – это решение должно было быть недорогим и доступным к моментальному запуску. Им оказался современный стек данных.
Современный стек данных – это система инструментов, которая размещается в облачных сервисах и позволяет компаниям:
• максимально эффективно использовать данные,
• оптимизировать затраты на их обработку и использование,
• автоматически получать свежие отчеты и своевременно реагировать на изменения рынка.
По своему значению и влиянию на бизнес современный стек данных сопоставим с автоматизацией в промышленности в середине прошлого века. Как и внедрение инноваций 70 лет назад, он становится движущей силой технологической революции, позволяя компаниям использовать преимущества облачных сервисов и создавать эффективную аналитику для своих подразделений.
Рис. 20. Вариант современного стека данных
Сейчас внедрение современного стека данных на предприятии способно поднять бизнес на новый уровень, как когда-то замена ручного труда машинным. И сегодня бизнес, который развернет современный стек и начнет эффективно использовать накопленную информацию, может занять значимые позиции на рынке.
Что же такое современный стек данных с практической точки зрения?
В минимальном варианте он включает следующие элементы:
• сбор данных (возможно использование инструментов Stitch, Fivetran);
• хранение информации (Redshift, BigQuery, Snowflake);
• трансформацию или преобразование (могут применяться dbt, другие инструменты);
• бизнес-анализ данных (применимы Periscope, Metabase, Looker).
Более сложный вариант современного стека данных с возможными инструментами представлен на схеме (рис. 20).
Безусловно, элементы стека данных могут меняться в зависимости от целей и задач каждой организации. Чем больше подключений и инструментов планируется использовать, тем сложнее становится настройка и установка стека данных. Почему так происходит? Чтобы ответить на этот вопрос, рассмотрим несколько примеров.
Нашу команду LEFT JOIN пригласили помочь выстроить комплексную архитектуру данных со множеством подключений и инструментов для компании, занимающейся беттингом – ставками на спорт. В фирме использовались 12 MySQL-серверов для разных стран, куда стекалась вся информация. И, соответственно, запускалось огромное количество процессов: записывались данные, пополнялись справочники и так далее.
Что мы сделали? Создали аналитические витрины. Для этого данные с серверов направляли в ClickHouse, где они обрабатывались с помощью встроенного в хранилище инструмента «Материализованные представления». Это потребовало огромного труда, но в итоге сейчас компания получает отчеты с актуальной маркетинговой и финансовой информацией.
Всем ли компаниям это нужно? Крупным, с серверами в разных странах, использующим распределенные вычисления – безусловно. А для небольших организаций и стартапов стоит выбрать другие решения.
Например, есть простые и свободно распространяемые инструменты:
• Airbyte позволяет подключаться к рекламным кабинетам и собирать данные.
• Для управления базами данных пригодятся PostgreSQL или ClickHouse.
• Трансформацию данных можно запустить на Python/Go, а оркестрацию настроить в Apache Airflow.
• Dbt используют для обработки и трансформации данных, развернув этот инструмент локально на собственном виртуальном компьютере[4].
• Для визуализации подойдет Redash с открытым исходным кодом.
У всех инструментов, кроме dbt, понятный графический интерфейс, множество удобных настроек и коннекторов. Такой стек можно развернуть самостоятельно на облачном виртуальном инстансе.
Например, для шведского даркстора Vembla мы с командой LEFT JOIN развернули довольно простой стек данных в облаке:
• Написали скрипты на Python для сбора маркетинговых данных через API рекламных аккаунтов (Facebook* и Google), которые управляются через Apache Airflow.
• Компания теперь использует озеро данных на Amazon S3 как хранилище, где собираются новые данные и информация с их старого сайта.
• Для аналитики используется версия BI с открытым кодом Metabase.
А бывает, подходят решения даже более простые, чем с даркстором. Так вышло с онлайн-игрой RightSoft Labs. Мы с командой развернули для них стек данных в облаке, решив тем самым запрос клиента:
• Сбор данных реализовали через исполнение Python-скриптов под управлением Airflow.
• Часть DAG’ов внутри Airflow настроили на отправку данных в облачное хранилище и первичную трансформацию.
И чтобы определиться, какой стек нужен именно вам, ответьте себе на несколько вопросов:
• Какие задачи мой бизнес будет решать с помощью данных? Это может быть улучшение управленческих процессов, повышение прибыли, сокращение издержек.
• Ожидается ли в ближайшем будущем рост объема данных, которые предстоит обрабатывать? В средней перспективе он, безусловно, вырастет. Это связано с развитием технологий. Но вот порядок цифр будет существенно отличаться у разных фирм.
• Что хочется видеть в результате анализа данных? Другими словами, получили отчет или дашборд, а дальше что?
• И главное, что для вас значит быстро развернуть стек? За неделю или за сутки?
Ответы помогут понять, подходят ли вашему бизнесу коробочные продукты или придется выстраивать собранное под вас уникальное решение.
На самом деле это не просто логика, а настоящий творческий процесс: поиск комбинации технологий, идеально решающих ту или иную задачу.
Теперь давайте рассмотрим, какие процессы реализуются в стеке данных.
Процессы в стеке
Подготовка данных к анализу основывается на трех китах:
• Извлечение данные из источника (Extract).
• Приведение их в вид, пригодный для использования (Transform).
• Загрузка в хранилище (Load).
А связываются эти три кита с помощью двух разных последовательностей исполнения: ETL (Extract-Transform-Load) и ELT (Extract-Load-Transform). Почему так важно с ними разобраться? Все дело в том, что дальнейшие способы работы с данными зависят от способа и скорости загрузки информации в базы, а также от выбора правильных инструментов.
ETL-процессы (Extract, Transform, Load)
В последние годы процедуры извлечения (extract) и загрузки (load) отделяют от трансформации (transform) – подготовки данных к анализу. Однако на практике до сих пор можно встретить и объединенные ETL-процессы, поскольку исторически такая последовательность была стандартным методом работы с данными.
ETL-процессы зародились, когда еще не были доступны облачные технологии. На тот момент они были практически единственной возможностью обрабатывать информацию, и реализовались эти процессы в традиционном стеке данных, который упоминался ранее.
Как же работают ETL-процессы?
Простым языком, это можно описать так:
1. Мы берем информацию из источника ее возникновения.
2. Тут же трансформируем для целей аналитики.
3. Загружаем данные в измененном (обычно агрегированном) виде.
Давайте разберем, какие данные куда и как загружать, на примере телеком-компании.
В начале, как правило, ситуация стандартная:
1. В таких организациях клиенты совершают действия каждую миллисекунду. Значит, регистрация и изучение этих действий предполагает работу с действительно большими объемами информации (терабайты и сотни терабайтов данных).
2. Аналитическое подразделение не получает желаемых ресурсов: в нужном объеме компания не может себе их позволить, а потому экономит на оборудовании для аналитиков.
3. Обычно в таком случае компания выделяет специальный кластер данных – отдельный набор машин исключительно для задач аналитики.
4. Выделить несколько машин – слишком дорого. Поэтому работать с исходными или «сырыми» данными нет возможности. В этой ситуации аналитики просят построить витрины данных: массивы, в которых будет храниться обработанная и отсортированная информация.
5. Из-за большого объема сведений данные собираются с определенной периодичностью – обычно раз в сутки, но иногда с интервалом раз в час. То есть каждый час витрина данных обновляется, а аналитик получает агрегированную информацию – по пополнению счета или нажатиям на кнопку. Так намного проще обрабатывать большие массивы информации.
6. Построение витрин данных, начиная с их извлечения и трансформации и заканчивая заполненным хранилищем, происходит в технических командах. Потом команда специалистов работает с этими агрегатами в своем аналитическом хранилище.
В данном случае ETL-процедуры оправданны и выгодны, хотя к оборудованию компании предъявляются высокие требования. Но когда в организацию непрерывно поступает действительно большой объем информации, без них не обойтись. При этом значительная часть маркетинга и стратегической работы с клиентами строится на анализе пользовательских данных, но не запрашивает их в режиме реального времени.
Эти особенности закладывают описанные выше ограничения, и вот почему. С одной стороны, растет количество обрабатываемых данных. С другой – возможности вычислительной техники ограничены. Слабые места проявляются на этапе свертки данных (reduce) – части процесса их трансформации. А быстро увеличить количество оборудования или его ресурсы нет возможности.
Разработчики продуктов по управлению обработкой данных пытались решить проблему, даже достигли некоторых успехов, но окончательно устранить ее не смогли. Так длилось до 2000-х годов. Именно тогда возникло несколько новых решений, и ситуация резко изменилась.
Появились облачные технологии и сервисы. Обработка и хранение данных стали более доступны и переместились на облачные серверы. Необходимость растить собственный парк оборудования для обработки данных отпала. И на смену ETL пришли ELT-процессы. И сейчас самое время изучить их поподробнее.
ELT-процессы (Extract, Load, Transform)
ELT-процессы расшифровываются точно так же, как и ETL, только теперь информация сначала загружается, а потом трансформируется. Второй и третий процесс поменялись местами. И это позволило получать данные в реальном времени. Современный тренд на хранение сырых данных возник во многом благодаря новому формату. Кроме того, ELT-процессы:
• позволяют обрабатывать данные в режиме реального времени, то есть сразу после получения;
• максимально облегчают использование облачных технологий;
• часто оказываются дешевле, чем ETL.
Теперь пошагово разберем ELT-процедуры:
1. Получаем сырые данные из места их появления. Например, для маркетолога это могут быть рекламные кабинеты.
2. Загружаем исходные сырые данные в хранилище.
3. Трансформацию – подготовку данных к анализу – начинаем уже тогда, когда понимаем, какие витрины и агрегаты данных необходимо построить для наших целей. Другими словами, у нас появляется опция хранения и предварительного исследования «сырых» данных.
Из-за этих особенностей использование ELT выгодно:
• стартапам;
• малому бизнесу;
• компаниям, которым важно хранить информацию в необработанном виде или изменять ее значительно позже, чем произошла ее загрузка.
Рассмотрим ELT на практике. В качестве примера возьмем компанию-разработчика игр для смартфонов и планшетов.
На этапе создания в игру встраивается SDK (Software Development Kit) для аналитики (например, Firebase). В Firebase есть интересная опция: запись данных, действий пользователя и прочего во внешнее хранилище Google BigQuery (поскольку Firebase с некоторых пор – одна из компаний, принадлежащих Google). В этот момент мы проходим две составляющие ELT-процесса:
• На первом этапе все данные извлекаются из игры в хранилище.
• На втором происходит трансформация: данные переводятся в вид, пригодный для анализа.
Всю эту работу можно проделать в BigQuery, используя язык запросов SQL.
Для разработчика ELT это удобные инструменты, позволяющие легко и быстро справиться с задачами.
Главная разница между ELT и ETL заключается в подходах к обработке информации. Для наглядности сравним эти процессы в таблице (рис. 21).
Рис. 21. Сравнение параметров ETL и ELT
Как мы видим, понять разницу между ETL и ELT не составляет труда. Но чтобы видеть общую картину процессов организации и хранения данных, нужно знать, с помощью каких инструментов они работают.
Процессы ELT не ограничиваются сбором отдельных данных, зачастую включаются их непрерывные потоки (так называемый стриминг). И для этого требуются специальные программные инструменты.
Среди таких инструментов класса Extract/Load выделяют две большие группы: для стриминга данных и для порционной загрузки.
К актуальным инструментам для стриминга данных в 2024 году относят:
• Jitsu. Это программа с открытым исходным кодом для потоковой загрузки данных.
• Snowplow. Еще один представитель open-source software для сбора данных.
• PostHog. Одна из самых известных open-source платформ для стриминга данных из нескольких источников.
Все эти инструменты позволяют работать с данными в режиме реального времени. Они похожи и конкурируют между собой. Выбор остается за пользователем и зависит от личных предпочтений в работе с софтом, удобства интерфейса и возможности интеграции с другими инструментами.
К инструментам для порционной (батчевой) загрузки данных в 2024 году относят:
• Fivetran. Это коммерческий софт для порционной загрузки данных из большого количества источников с удобным графическим интерфейсом. Инструмент нативно соединяется плагинами с dbt, который используется для трансформации данных.
• Stich. Платформа для загрузки данных из разных источников в облачные хранилища.
• Airbyte. Представитель программ с исходным открытым кодом для данных из сторонних источников.
Продукт может сохранять «сырые» данные, а также работать со сторонними инструментами через ряд коннекторов.
Рассмотрим пример, как эти инструменты используют на практике.
Для компании Buff мы в LEFT JOIN построили архитектуру и стек для работы с данными. Главный запрос: компании важно изучать данные о расходах из кабинетов рекламных платформ, чтобы понимать финансовую эффективность рекламных кампаний.
Что мы сделали:
• Для сбора данных из рекламных кабинетов Bing и Facebook* настроили инструмент Airbyte. В дальнейшем он использовался для подготовки данных к анализу.
• Развернули Airflow. Теперь данные своевременно обновлялись и полноценно трансформировались.
• Для визуализации и анализа данных развернули и настроили Redash.
Таким образом, компания Buff получила систему сбора и анализа информации о своих рекламных кампаниях в режиме реального времени. Руководство освободилось от груза дополнительных задач, перенаправив свое внимание на решение управленческих вопросов.
Подобные решения для бизнеса не «волшебство», а технология со множеством возможностей. А ключевое требование одно – оптимальный выбор инструментов для решения задач вашей компании. Часто желаемого результата можно достигнуть с минимальными, но вполне оправданными усилиями инженера данных.
Так, я с командой настраивал работу с данными для компании Simple. Руководитель хотел понимать, насколько эффективна реклама, оптимальна ли стоимость и какой источник привлечения клиентов дает лучший результат (реклама в поиске, таргетинг в соцсетях и так далее).
Что мы сделали:
• Для сбора информации написали скрипты, направляющие данные в Apache Kafka. Этот инструмент выполняет роль буфера для хранения потока данных.
• Оттуда данные направляются в хранилище ClickHouse. У него, в свою очередь, есть специальная возможность – материализованные представления, то есть механизм внутри базы данных, позволяющий настроить их трансформацию по написанному вручную SQL-коду.
Таким образом, компания получила основу для управленческих решений в режиме 24/7 без особых затрат.