Data Engineering Руководство для начинающих вдохновленное Формулой 1

Руководство по Data Engineering для начинающих вдохновленное Формулой 1

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

Вы новичок в области инженерии данных и хотите узнать больше о современной инфраструктуре данных? Думаю, да, эту статью и вам он

В этом руководстве Инженерия данных встречается с Формулой 1. Но, мы оставим все просто.

Введение

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

Бизнес-сценарий и архитектура данных

Представьте себе следующее: в следующем году новая команда на сетке, Red Thunder Racing, позвонит нам (да, мне и вам) для настройки своей новой инфраструктуры данных.

• 34% Более быстрый алгоритм преобразования целых чисел в строки
• Прогнозирование изменений оттока навигация по вмешательствам и повторной подготовке
• 9 способов, которыми ИИ улучшает безопасность центров обработки данных

В современной Формуле 1 данные стоят на первом месте, намного больше, чем 20 или 30 лет назад. Гоночные команды улучшают производительность с помощью феноменального подхода, основанного на данных, делая улучшения миллисекунду за миллисекундой.

Не только о круговом времени; Формула 1 – это миллиардный бизнес. Увеличение привлекательности для болельщиков не только для развлечения; сделать спорт привлекательнее – не только для удовольствия гонщика. Эти мероприятия генерируют доходы. Прочная инфраструктура данных – необходимое условие для конкуренции в бизнесе Формулы 1.

Мы построим архитектуру данных, чтобы поддержать нашу гоночную команду, начиная с трех канонических слоев: Data Lake, Data Warehouse и Data Mart.

Data Lake

Озеро данных будет служить хранилищем для обработки неструктурированных данных, сгенерированных из различных источников в экосистеме Формулы 1: телеметрические данные от автомобилей (например, давление в шинах в секунду, скорость, расход топлива), конфигурации водителя, времена кругов, погодные условия, ленты социальных медиа, билеты, зарегистрированные на маркетинговых мероприятиях поклонники, покупки товаров, …

Всевозможные данные могут быть хранены в нашем объединенном озере данных: неструктурированные (аудио, видео, изображения), полуструктурированные (JSON, XML) и структурированные (CSV, Parquet, AVRO).

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

У нас будет длинный список систем для интеграции, и каждая из них будет поддерживать разный протокол или интерфейс: Kafka Streaming, SFTP, MQTT, REST API и другие.

Мы не будем одни в сборе данных; к счастью, на рынке есть инструменты интеграции данных, которые можно использовать для настройки и поддержки потоков в одном месте (например, в алфавитном порядке: Fivetran, Hevo, Informatica, Segment, Stitch, Talend, …). Вместо того, чтобы полагаться на сотни скриптов Python, запланированных в crontab или иметь пользовательские процессы, обрабатывающие потоковые данные из тем Kafka, эти инструменты помогут нам упростить, автоматизировать и оркестрировать все эти процессы.

Хранилище данных

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

Хранилище данных используется для очистки, структурирования и сохранения обработанных данных из озера данных, предоставляя структурированную, высокопроизводительную среду для аналитики и отчетности.

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

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

У нас будет множество конвейеров, посвященных трансформации и нормализации данных. Как и для интеграции данных, на рынке существует множество продуктов, упрощающих и эффективно управляющих конвейерами данных. Эти инструменты могут упростить наши процессы работы с данными, снизить операционные затраты и повысить эффективность разработок (например, в алфавитном порядке: Apache Airflow, Azure Data Factory, DBT, Google DataForm и другие).

Данные по модулям

Между хранилищами данных и данными по модулям существует тонкая грань. Не забывайте, что мы работаем для Red Thunder Racing, крупной компании с тысячами сотрудников, занимающихся различными областями. Данные должны быть доступны и адаптированы к требованиям конкретных бизнес-подразделений. Модели данных строятся вокруг бизнес-потребностей.

Данные по модулям – это специализированные подмножества хранилищ данных, фокусирующиеся на конкретных бизнес-функциях.

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

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

Наша многоуровневая архитектура данных позволит Red Thunder Racing использовать мощь данных для оптимизации производительности автомобиля, стратегического принятия решений, улучшенных маркетинговых кампаний и многого другого!

Это все?

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

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

Но, как говорят: “Рим не был построен за один день”. У нас уже сегодня много дел, включая первый черновик нашей архитектуры данных (ниже).

Выводы

Data Engineering – это волшебное царство, которому посвящено множество книг.

В ходе пути инженеры данных будут использовать безграничные инструменты интеграции, разнообразные платформы данных, нацеленные на охват одного или нескольких вышеупомянутых уровней (например, в алфавитном порядке: AWS Redshift, Azure Synapse, Databricks, Google BigQuery, Snowflake, …), инструменты бизнес-аналитики (например, Looker, PowerBI, Tableau, ThoughtSpot, …) и инструменты управления потоками данных.

Наш путь инженерии данных в Red Thunder Racing только начался, и мы должны оставить достаточно места для гибкости в нашем инструментарии!

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

• Вам всегда нужно иметь озеро данных? Это зависит.
• Вам всегда необходимо иметь данные, хранящиеся как можно скорее (т.е. потоковую и обработку в реальном времени)? Это зависит, от требований к свежести данных, предъявляемых бизнес-пользователями.
• Всегда ли вам нужно полагаться на инструменты сторонних разработчиков для управления данными в потоках? Это зависит!
• <Заполнитель для любого другого вопроса, который у вас может быть>? Это зависит!

Если у вас есть вопросы или предложения, не стесняйтесь обращаться ко мне на LinkedIn. Я обещаю ответить нечто, отличное от: Это зависит!

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

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