Кратко об остальном Flashcards
(14 cards)
Data lake
Хранилище файлов или объектов. Обычно характеризуется низкой стоимостью хранения и высокой масштабируемостью, но малой гибкостью работы с данными.
Если хранилищем выступает Hadoop (HDFS), на логическом уровне полноценно взаимодействовать с партицией или файлом можно только целиком. Если нужно сделать апдейт, его нельзя сделать точечно. Вставка — в конец. Также могут использоваться S3-совместимые объектные хранилища.
Используется как слой накопления данных, хранения истории. Обработку и собственно анализ данных зачастую проводят в OLAP базах (в которые нужно ETL-процессами данные сначала скопировать) или в SQL-движках поверх HDFS вроде Hive, Impala, Trino. Сами данные часто хранят в Parquet’ах или Avro. В последние годы популярность набирает Delta формат (parquet + метаданные).
Если писать все данные без представления о том, когда, кто и как ими будет пользоваться, озеро может превратиться в болото (data swamp).
Parquet
Колоночный формат хранения больших данных. Эти данные лежат в сжатом виде, поэтому “в блокноте” его не открыть, нужно использовать например Apache Arrow пакет в Python.
Каждую колонку хранит отдельно, где данные часто повторяются, похожи или по крайней мере одного типа. Поэтому значения в ней хорошо сжимаются. Чтобы сжатие работало эффективнее, важно сортировать паркет при записи.
Также сортировка влияет на оптимизацию predicate pushdown. Если кратко, паркет делится на группы строк RowGroup и для каждой из них считает статистику: мин макс для чисел и дат, набор уникальных значений для строк. И если паркет отсортирован по колонке фильтрации, движок может быстро пропустить RowGroups, где искомого значения точно нет.
Помни, что отсортировать можно только по одной колонке ;)
Avro
Редкий сейчас формат, был популярен во времена зарождения хадупа. Он для больших данных и строковый.
ORC
Редкий сейчас формат, был популярен во времена зарождения хадупа. Он для больших данных и колоночный.
Data lakehouse (hybrid)
Data lake + data warehouse. Данные хранятся в озере в виде iceberg, delta или hudi файлов. Эти форматы позволяют работать с файлами как с таблицами, через SQL.
Основная потребность в таких системах возникает, когда хранилище занимает больше 1 Пб (млн гигов), и тот же greenplum уже перестаёт справляться с нагрузкой.
В таком случае не нужно поддерживать отдельный сервис в виде DWH и копировать туда данные для обработки – слои хранятся в разных “директориях” озера. А получать доступ к данным можно через тот же Trino.
Витрины часто всё же копируют в Clickhouse для скорости доступа к данным.
Iceberg
Популярный формат работы с файлами как с таблицами для биг даты. Позволяет строить аналитику поверх Data Lake, получается Data Lakehouse. Выглядит как файлы метаданных рядом с самими данными (напр. json рядом с Parquet) + БД для работы каталога (вроде Hive Metastore, если знакомо).
Добавляет ACID, эволюцию схем, “перемещение во времени” (историчность), SQL-доступ к данным, объединение мелких файлов (compaction).
Hudi и Delta похожи на Iceberg и выполняют по сути те же функции, но чуть лучше оптимизированы под разные сценарии.
Iceberg заточен под батчевую аналитику больших объёмов (Петабайты данных).
Hudi
Тоже формат работы с файлами как с таблицами, лучше всего подходит для стриминга
Delta
Тоже формат работы с файлами как с таблицами, что-то среднее между айсбергом и худи. Является опенсорсной частью платформы Databricks (который по сути спарк + data lakehouse на delta таблицах)
Trino
Федеративный движков запросов, который умеет подключаться к разнородным источникам через коннекторы, забирать данные и объединять их прозрачно для пользователей.
Trino (ранее — Presto) — это распределённый (MPP) SQL движок для аналитики больших данных. Хорошо оптимизирован как под on-premise развёртывание, так и под облачные решения, масштабируется до петабайтов данных и больше. В качестве источников могут быть объектные и файловые хранилища (н. S3, HDFS), транзакционные базы (н. MySQL, PostgreSQL, Oracle), NoSQL (н. MongoDB, Cassandra, HBase), OLAP-базы и много-много чего ещё (https://trino.io/ecosystem/data-source). Позволяет джойнить в одном запросе данные из разных систем и СУБД – например историю из HDFS, текущие метрики из greenplum, справочники из postgres.
DBT
Это инструмент для описания трансформаций средствами СУБД (системой управления баз данных) и упорядочивания объектов, которые создаются в базе.
Буква “Т” в ELT (extract, load, transform). Внешним инструментом (например, Spark, dlt, python скриптами) нужно загрузить данные в сыром виде в staging/landing zone (обычно схема/каталог, первый слой данных), и эстафета передаётся dbt – вплоть до построения витрин данных и даже метрик для BI.
В современных СУБД вроде Greenplum, Clickhouse, (и облачных AWS Redshift, GCP BigQuery, Azure Synapse) вычислительных мощностей хватает для обработки данных без необходимости в Spark и подобных ETL инструментах.
Можно воспринимать dbt как развитие идеи хранимых процедур, применяется обычно для OLAP распределённых баз.
Data quality
Качество данных. Можно реализовать на чём угодно, но хотят чтобы был навык с инструментами вроде Great Expectations (опенсорс пакет для Python и/или dbt) или Monte Carlo (лучше и удобнее, но платный).
Важно, чтобы данным доверяли. Иначе можно кучу ресурсов потратить на разработку и обработку, а таблицами и дашбордами не будут пользоваться, потому что там какая-то каша.
Чем больше проверок близко к точке создания (загрузке из источника, применению бизнес-правил на витринах), тем меньше мусора будет распространяться по другим слоям и продуктам ниже по течению.
Основные проверки:
* количество строк (сколько забрали, столько положили)
* not null поля
* отсутствие дубликатов
* тип данных совпадает с ожидаемым
* формат дат верный
* логически верные данные (дата рождения - в прошлом, зарплаты неотрицательные и пр.)
* колонки правильно смаплены и названы (в Имени - Имя, в дате рождения - дата рождения и тд.)
Debezium(CDC)
Change data capture (CDC) это технология захвата изменений данных с источника, для реляционных СУБД — обычно через лог базы данных. В таком случае таблица не блокируется, нагружается именно компонент, отвечающий за репликацию. В отличие от батч загрузок, которые запускаются по расписанию и теряют промежуточные изменения, CDC подтягивает все операции. Это хорошо, если такая детализация нужна. Это головная боль, если надо схлопывать эти изменения и сохранять только состояние, например, на закрытие операционного дня.
CDC создаёт поток изменений, который можно использовать для стриминговой загрузки.
Debezium это опен-сорс коннектор к различным источникам данных. Выгружает данные из Х в кафку. Из кафки нужно забирать другими инструментами, Debezium делает исключительно Load.
Streaming (Spark streaming, Flink, Kafka)
Требуется меньше чем в 10% проектах, это когда задержка доставки данных стремится к нулю и стараются каждое событие обработать и передать отдельно.
Усложняет разработку и отладку системы, удорожает проект, поэтому не так часто ставится как требование.
Можно пошутить про то, что “риалтайм” во всех компаниях разный, и появление данных в реальном времени невозможно и почти никогда не нужно.
Если компания отслеживает перевозки товаров грузовиками, +-5 минут обычно не критичны. Для системы доставки еды или такси риалтайм это десяток секунд. А для высокочастотной торговли на бирже выигранные миллисекунды могут стать конкурентным преимуществом для всей компании.
S3
Изначально – сервис объектного хранения данных от Amazon Web Services (AWS). Его любят разработчики за дешевизну (2 цента в месяц за 1GB) и интеграции с почти любым сервисом, языком разработки и пр. В общем, стандарт для записи и чтения данных в мире “облаков”.
Сейчас S3 это скорее интерфейс доступа к данным и правила их организации. В общем – протокол взаимодействия, и корректно будет назвать Azure ADLS, GCS, Yandex object storage и прочие – s3-совместимые хранилища.
Локально и на on-premise инфре можно развернуть в виде сервиса MinIO.
