Учебный курс Современная архитектура хранилища данных

Модуль 1 - Роль Аналитики и Инженера данных в организации

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

Модуль 2 - Базы Данных и SQL

Рассмотрим пример решения для локальной аналитики. Познакомимся с базами данных и поймем их преимущество для работы с данными по сравнению с Excel/Google Sheets. Потренируемся на SQL, установим базу данных и загрузим в нее данные, потом будем использовать Excel/Google Sheets для визуализации данных.

Доступные решения для России:

Greenplum - бесплатно, но если промышленная - нужна коммерческая поддержка, например Arenadata, учебный курс по GreenPlum
Clickhouse (быстрая колоночная СУБД для витрин данных) - учебный курс по Clickhouse
Postgres - бесплатно, но если промышленная инсталляция - нужна коммерческая поддержка, например Postgres Professional, учебный курс по PostgreSQL

СУБД

Хранилища для больших данных

Использование классических реляционных, колоночных, NoSQL, SMP/MPP хранилищ для построения DWH:

Apache Doris

Учебный курс по Apache Doris

Starrocks

Моделирование данных в DWH

DBeaver

Подробнее в курсе по DWH

Модуль 3 - Визуализация данных, дашборды и отчетность - Business Intelligence.

Познакомимся с BI инструментами, научимся использовать Qlik, Tableau и Power BI. Разберемся с клиентской и серверной частью. А также познакомимся с методологией по созданию метрик - Pirate Metrics.

- учебные курсы по популярным пропиетарным BI-решениям: Looker, Qlik, Tableau и Power BI

- учебные курсы по популярным open-source BI-решениям Open source BI: Superset, Metabase / Учебный курс по Open-source BI

Исследование всех российских BI можно скачать на https://russianbi.ru/

Модуль 4 - Интеграция данных и создание потоков данных (data pipelines)

При росте количества источников данных становится сложно вручную загружать и трансформировать данные. Именно для этих задач используются ETL решения. Так же мы рассмотрим разницу между ETL и ELT. Дополнительно рассмотрим рынок решений и потренируемся на Open Source решении, с помощью которого мы сможем загрузить данные в Redshift и автоматизировать этот процесс.

Конвейеры данных. Карманный справочник 2024 (книга .pdf)

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

Продукты:

Коммерческий ETL - Microsoft Integration Services и Informatica Power Center
Open Source ETL - Pentaho / Airflow/Nifi : учебный курс по Apache Nifi, Apache Airflow / DBT Tool: Учебный курс по dbt (Data Build Tool)
Облачный ETL - Matillion, Fivetran, AWS Glue, Azure Data Factory

Исследование всех российских ETL-продуктов можно скачать на https://russianbi.ru/

Модуль 4.5 - Оркестрация скриптов и задач

Модуль 5 - Облачные вычисления (Cloud Computing)

Узнаем, что кроется за понятием облачных вычислений, как они используются на западе и почему так популярны. Познакомимся с аналитическими решениями Amazon Web Services и Microsoft Azure. Рассмотрим реальные примеры миграции в облака.

Миграция данных в облако / Перевод работы с данными в облака Cloud

Модуль 6 - Облачное Хранилище данных

Центр вселенной в аналитике обычно это хранилище данных или платформа данных. Как правило это аналитическое решение с MPP архитектурой и часто используется облачные решения. Мы познакомимся с одним из самых популярных решений Amazon Redshift и узнаем о других аналогах. Также рассмотрим кейсы миграции традиционных решений в облака.

Amazon S3

Google BigQuery

Azure

Snowflake

Snowflake это хранилище данных это аналитическая платформа, которая позволяет:

создавать хранилище данных
работать с данными в браузере (SnowSight) используя SQL или Python (SnowPark)
возможность создавать веб-приложения на базе Streamlit (open source решение, которое Snowflake купил)
создавать Stored Procedures прям как в PL/SQL в Oracle или T-SQL в SQL Server (можно на SQL, можно и на другом языке). Работает отлично - бесплатная замена dbt для трансформации данных
ставить на расписание ваши запросы (jobs) с использованием Tasks
интеграция с Apache Iceberg, свой Iceberg каталог Polaris
поддержка стриминга через Pipes, Dynamic таблиц
своя кривая LLM Arctic
возможность хостить контейнеры (сам еще не проверял)
создавать Data Apps на любой цвет и вкус (для монетизации своих данных)
Data Sharing, большой маркетплейс различных приложений, вендоров, данных

Получите больше от своих данных с Talend и Snowflake

Databrics

Databricks

Сравнение инструментов пакетной обработки данных: анализ производительности

Модуль 7 - Знакомство с Apache Spark

Apache Spark является одним из самых популярных инструментов для Инженера Данных. Данный модуль мы посвятим знакомству с Apache Spark и рассмотрим его функциональность. Потренируемся создавать RDD и Data Frame, рассмотрим основные операции и кейсы использования.

Spark в действии (книга .pdf)

Анализ корпоративных данных начинается с чтения, фильтрации и объединения файлов и потоков из многих источников. Механизм обработки данных Spark способен обрабатывать эти разнообразные объемы информации как признанный лидер в этой области, обеспечивая в 100 раз большую скорость, чем например Hadoop. Благодаря поддержке SQL, интуитивно понятному интерфейсу и простому и ясному многоязыковому API вы можете использовать Spark без глубокого изучения новой сложной экосистемы. Эта книга научит вас создавать полноценные и завершенные аналитические приложения. В качестве примера используется полный конвейер обработки данных, поступающих со спутников NASA. Для чтения этой книги не требуется какой-либо предварительный опыт работы со Spark, Scala или Hadoop.

Модуль 8 - Создание решения для Big Data с использованием Hadoop и Spark

Hadoop является флагманом решений Big Data. В данном модуле, мы попробуем решить задачу, которая не под силу традиционными инструментам ETL/DW, это поможет вам понять разницу между DW и BigData и вы точно будете знать, почему мы используем Hadoop. В качестве инструмента управления мы воспользуемся Spark который уже будет предустановлен на Amazon Elastic Map Reduce. В качестве упражнения, мы будем использовать PySpark, чтобы читать неструктурированные логи и извлекать из них ценную информацию.

Алгоритмы и структуры для массивных наборов данных [2023] Меджедович Дж., Тахирович Э

Стандартные алгоритмы и структуры при применении к крупным распределенным наборам данных могут становиться медленными — или вообще не работать. Правильный подбор алгоритмов, предназначенных для работы с большими данными, экономит время, повышает точность и снижает стоимость обработки. Книга знакомит с методами обработки и анализа больших распределенных данных. Насыщенное отраслевыми историями и занимательными иллюстрациями, это удобное руководство позволяет легко понять даже сложные концепции. Вы научитесь применять на реальных примерах такие мощные алгоритмы, как фильтры Блума, набросок count-min, HyperLogLog и LSM-деревья, в своих собственных проектах.

Модуль 9 - Data Lake

Знакомство с понятием Озера Данных и его создание с помощью инструментов AWS. Существует много версий про назназначение Озера Данных и про его роль в Аналитической экосистеме. В данном модуле мы познакомимся с понятием Озера данных, его ролью в экосистеме, рассмотрим типовые архитектуры построения решений с использованием Озера Данных и/или Хранилища данных. В качестве решений будем использовать продукты AWS.

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

Если вы строите озеро данных (data lake) или его улучшенную версию lake house (используете формат таблиц Delta, Iceberg), то вы разделяете хранение по уровням хранения данных:

- raw/bronze - может быть просто папка с blob storage, в которую вы грузите/копируете сырые данные и создаете таблицы, то есть абстракции в каталоге (Hive, Unity). В случае dbt, это будет dbt source.

- staging/silver - вы используете уже таблички из bronze, и делаете трансформации, но все еще данные raw (без агрегации), можете еще добавить joins.

- business/fact/dw/gold слой - там где у вас уже таблицы фактов/витрины/метрики, вы агрегируете данные и используете аналитические функции.

Apache Parquet, Hudi, Iceberg и Delta Lake

Delta Lake создан для Spark-heavy workflows , предлагает тесную интеграцию с Databricks и беспрепятственный прием потоковой передачи.

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

Распределенная модель Iceberg легко масштабируется, а журнал транзакций Delta Lake может создавать узкие места за пределами Spark.
Эволюция схемы? Iceberg позволяет изменять столбцы без перезаписи данных, а Delta требует явных действий по слиянию.
Разделение? Айсберг автоматически адаптируется; Delta нуждается в предварительно определенных разделах, что часто требует дорогостоящей перезаписи.
Преимущество в производительности? Iceberg представляет файлы Puffin для расширенной оптимизации запросов, чего не хватает Delta Lake.

Что выбрать? Если вы ставите олл-ин на Spark и Databricks, выбирайте Delta.

Нужна межплатформенная гибкость? Айсберг побеждает.

Apache Iceberg

Настройка и использование каталогов для Iceberg Lakehouse

Apache Parquet

Apache Hudi

Модуль 10 - Решение задачи по стримингу данных.

Apache Flink

Что такое Apache Flink 2

Debezium

Debezium и Change Data Capture - потоковая репликация данных в реальном времени

Презентация со SmartData 2024 - DebeziumEngine: практическое руководство по использованию

Анастасия Сашина | Java/Kotlin разработчик Т-Банка

kafka

Учебный курс по ZooKeeper

Другое:

Модуль 11 - Задачи Машинного Обучения глазами инженера данных.

Итак, в компании уже есть хранилище данных, и сформирован бизнес-запрос на их использование для достижения измеримой бизнес-цели с помощью ML. Представим, что команда внедрения успешно прошла все этапы до внедрения ML-сервиса в продукционный режим («Прод»). Это можно рассматривать как разовое действие для ИТ: обернули в Docker-контейнер, запустили и забыли — до первого инцидента. Но в случае с ML-сервисом возникает ряд дополнительных требований и ограничений:

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

Нужно создать механизмы по обработке и получению входных данных для моделей в «Прод» и передаче их результатов потребителям. Это организация пайплайнов эксплуатации (инференса) ML-моделей.

Нужно реализовать сам вывод в «Прод» и возможности для обновления пайплайнов эксплуатации (зачастую совмещенные с пайплайнами дополнительного обучения). Это организация CI/CD-процессов для ML-сервисов.

Наконец, нужно настроить мониторинг ML-сервиса в «Прод» — сюда входит как общая доступность и быстродействие сервиса, так и отслеживание ML-метрик инференса при эксплуатации

Все эти задачи объединяются подходом и инструментами MLOps (DevOps для ML-моделей). На первый взгляд, они нужны только Data Science-команде и частично Product Owner'у. Но у MLOps есть и существенные бизнес-эффекты, важные для Спонсора — прежде всего, это кратное снижение Time-to-Market для новых ML-сервисов (недели вместо месяцев), а также существенное снижение расходов на их эксплуатацию.

Модуль 12 - Лучшие практики инженера данных

Модуль 13 - Data Vault

Building a Scalable Data Warehouse with Data Vault 2.0 (книга .pdf)

Data Vault был изобретен Дэном Линстедтом в Министерстве обороны США, и этот стандарт успешно применялся к проектам по хранению данных в организациях разных размеров, от малых до крупных корпораций. Благодаря своей упрощенной конструкции, стандарт Data Vault 2.0 помогает предотвратить типичные сбои в хранении данных. Книга «Building a Scalable Data Warehouse with Data Vault 2.0» охватывает все, что нужно знать для создания масштабируемого хранилища данных от начала до конца, включая презентацию метода моделирования Data Vault, который обеспечивает основу для создания технического уровня хранилища данных. В книге обсуждается, как построить хранилище данных постепенно, используя гибкую методологию Data Vault 2.0. Кроме того, читатели узнают, как создать входной уровень (stage layer) и уровень представления (presentation layer - data mart) архитектуры Data Vault 2.0, включая лучшие практики внедрения. Опираясь на многолетний практический опыт и используя многочисленные примеры и простую для понимания структуру, Дэн Линстедт и Майкл

Презентация со SmartData 2024: Data Vault 2.0

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

Денис Лукьянов, Руководитель направления архитектуры данных

Модуль 14 - Дополнительные структуры

Trino и Presto

Trino - The Definitive Guide 2023 Second Edition (книга .pdf)

SQL at Any Scale, on Any Storage, in Any Environment

Trino — это распределённый SQL-движок для выполнения аналитических запросов на больших объёмах данных. Он позволяет выполнять запросы к данным, хранящимся в различных источниках, таких как базы данных, хранилища данных и файловые системы, без необходимости перемещать данные. Trino поддерживает стандарты ANSI SQL и широко используется для высокопроизводительной аналитики, позволяя объединять данные из различных систем в одном запросе.

Дата инженерия не для дата инженеров

CI/CD для пайплайнов данных

Data-driven компания:

DataMart
Тестирование

Rust

Как Rust тихо захватывает экосистему Python

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

Вот наиболее интересные проекты:

Ruff: этот линтер работает невероятно быстро по сравнению с традиционными линтерами Python. Почему? Он написан на Rust. Речь идёт об ускорении в 10-100 раз.
UV: ещё один инструмент, написанный на Rust - быстрый и надёжный установщик пакетов Python. UV как более быстрая альтернатива Poetry способная значительно ускорить установку зависимостей.
Polars: эта библиотека DataFrame конкурирует с Pandas по производительности. И угадайте что? Под капотом - Rust.
Maturin: делает создание Python-расширений на Rust предельно простым.

Модуль 15 - Data Mesh

Любая компания собирает и обрабатывает огромное количество данных, стараясь извлечь из них максимальную ценность, используя, в частности «озера данных». Вместе с тем, в классическом подходе к работе с Data Lake имеются принципиальные ограничения при централизованном развитии хранилища – чем больше интегрированных систем и данных, тем больше требуется ресурсов на их поддержку и развитие, а значит, возникает больше кросс-зависимостей, что означает лавинообразный рост ответственности для определенных групп сотрудников компании. В итоге, например команда работы с Data Lake, становится бутылочным горлышком процесса доставки данных от источников к потребителям. Решение – распределенная структура управления данными (Data Mesh), позволяющая разделить ответственность: владение данными (генерация, описание, контроль качества, публикация) сосредоточено в бизнес-функциях, а CDO выступает в роли провайдера инструментария хранения, обработки данных, а также методологии управления ими. Особое внимание уделено процессам Data Governance, обеспечивающим взаимодействие между узлами распределенной структуры: внедрение каталога данных, определение ландшафта данных, роли владельца данных, общие политики для всех узлов.

Что такое Data Mesh?

Архитектура Data Mesh - это революционная парадигма в мире аналитики данных в реальном времени. Концепция была впервые определена Zhamak Dehghani в 2019 году как подход к проектированию архитектуры платформы данных, ориентированной на работу с данными в движении.

По сути, Data Mesh - это набор принципов для создания современной архитектуры данных.

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

Data Mesh - это новый подход, который позволяет компаниям отказаться от монолитных архитектур данных и эффективно масштабировать работу с информацией.

Четыре принципа Data Mesh:

1. Владение данными по доменам - данные управляются командами, которые их создают (например, маркетинг, финансы).

2. Данные как продукт - данные рассматриваются как ценность, которую нужно улучшать и «упаковывать».

3. Доступность везде и самообслуживание - данные доступны всем командам без посредников.

4. Управление данными в любой точке - безопасность и согласованность даже в распределенных системах.

Data Mesh - архитектура, доменная модель и операционализация в корпоративных DWH и Lakehouse

Domain-Driven Design (DDD): проектирование сложных систем через бизнес-домены

Domain-Driven Design: стратегическое проектирование систем

Модуль 16 - Change Data Capture (CDC)

Эти системы позволяют наполнять централизованные хранилища/озера извлекая данные из источников по мере их изменения там. Вот хороший базовый обзор этой концепции и систем:

Модуль 17 - Каталог данных (Data Catalog)

DataHub — это каталог данных — платформа метаданных с открытым исходным кодом для modern data stack, основной задачей которой является помощь сотрудникам в обнаружении нужных данных. Первоначально DataHub был создан в LinkedIn, а затем был открыт с открытым исходным кодом под лицензией Apache 2.0.

Универсальный инструмент поиска и обнаружения метаданных.

Модуль 18 - Мониторинг данных

Prometheus + Grafana. Настраиваем 4 golden signals

Дополнительно

DevOps для Data Platform: CI/CD инфраструктура как код, GitOps

Elasticsearch

Компоненты аналтитического решения сгруппированы по типам и назначению.

Статья Learnings after 4 years working with +50 companies on data engineering projects в переводе от Дмитрия Аношина (канал Инжиниринг данных)

В статье Learnings after 4 years working with +50 companies on data engineering projects автор поделился интересными наблюдениями посли 4х лет консалтинга. Chatgpt перевел и я подправил по возможности.

Некоторые практические выводы, без особого порядка:

- Многие думают, что быстро делать ETL невозможно. Большинство считает, что пайплайны, которые обрабатывают большой объём данных, должны занимать часы. На деле в большинстве случаев можно решить задачу в реальном времени (запросы <1 сек) с меньшим количеством железа. Хороший дизайн всегда лучше железа.

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

- Люди сосредотачиваются на изучении инструментов, и это хорошо, но забывают про принципы. Я не могу сосчитать, сколько раз видел, как SQL-запрос мог бы работать в 1000 раз быстрее, если бы данные были правильно отсортированы. Люди отлично знают, как использовать Spark/Snowflake/BigQuery, но никогда не тратят полдня, чтобы понять, как эти инструменты работают «под капотом». Поверьте, есть 3-4 базовые концепции, которые дают 80% необходимых знаний. Я 7 лет управлял огромным кластером Postgres, но так и не уделил достаточно времени его принципам. Сейчас я уже забыл, как работать с Postgres, но уверен, что запомнил бы основы, если бы уделил им больше времени.

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

- Ingestion — это 80% работы, но его обычно даже не мониторят. Есть сотни причин, почему `INSERT` может не сработать или быть медленным. Данные, которые вы не смогли загрузить, ломают весь пайплайн, а ошибки остаются незамеченными. Вы видите проблему в SQL-запросах, когда уже слишком поздно и всё слишком сложно.

- Качество данных — это как unit-тестирование, но в продакшене. Тестировать пайплайны в CI (и только 10% людей это делают) недостаточно, нужен постоянный мониторинг.

- Схема есть всегда. Вы решаете её на этапе записи данных или чтения, но в какой-то момент всё равно нужно определить атрибуты и типы данных. JSON хорош в некоторых случаях, но это не решение. Любой серьёзный пайплайн избавляется от JSON как можно быстрее. JSON делает проекты в 2-10 раз дороже только за счёт железа, не говоря уже о часах, потраченных на угадывание схемы JSON.

- Да, есть проекты, где нужен открытый формат схем, но schemaless в масштабе очень дорого, и вам обычно придётся делить логику работы между типовыми случаями и редкими исключениями. Проще говоря, если вы разрешаете пользователям отправлять что угодно, будьте готовы бороться с 0.0000001% событий, которые содержат 3MB атрибут.

- Быстро, дёшево, гибко. Выберите два.

- Чтобы удерживать низкие значения +p99 задержек, ваше оборудование должно большую часть времени простаивать.

- end-to-end задержки = K / $. Если вы хотите, чтобы данные были доступны как можно быстрее, нужно железо. Это не линейная зависимость: чтобы сократить задержки с 10 сек до единиц секунд, придётся вложить много денег (и при этом ещё держать низкие задержки на чтение, иначе в чём смысл).

- Люди всегда думают, что операции завершатся успешно. Использование неизменяемого workflow и атомарных операций всегда экономит дни на исправление некорректных или частичных данных.

- Большинство людей не имеют интуиции, что современное железо может или не может. Простая формула может помочь: «одна машина может обработать около 500MB за секунду». Да, это не универсальная истина, но эта оценка — хороший инструмент.

- Большинству компаний нужны базовые знания bash / make, SQL-движок для одной машины (DuckDB, CHDB или несколько python-скриптов), распределённая файловая система, git и девелоперский workflow (CI/CD). Меня всё ещё удивляет, как быстро мы забываем хорошие практики, которые изучили за годы в софтверной инженерии (тестирование, деплой, совместная работа, мониторинг и так далее).

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

Презентация со SmartData 2024 - DebeziumEngine: практическое руководство по использованию

Анастасия Сашина | Java/Kotlin разработчик Т-Банка

← Предыдущая статья

Учебный курс для бизнес-аналитиков

Следующая статья →

Учебный курс по MLOps и Data Science (ML, AI)