Кратко об остальном (TODO) Flashcards
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.
Parquet
Колоночный формат хранения больших данных. Эти данные лежат в сжатом виде, поэтому “в блокноте” его не открыть, нужно использовать например Apache Arrow пакет в Python.
Каждую колонку хранит отдельно, где данные часто повторяются, похожи или по крайней мере одного типа. Поэтому значения в ней хорошо сжимаются. Чтобы сжатие работало эффективнее, важно сортировать паркет при записи.
Также сортировка влияет на оптимизацию “predicate pushdown”. Если кратко, паркет делится на группы строк RowGroup и для каждой из них считает статистику: мин макс для чисел и дат, набор уникальных значений для строк. И если паркет отсортирован по колонке фильтрации, движок может быстро пропустить RowGroups, где искомого значения точно нет.
Помни, что отсортировать можно только по одной колонке ;)
Avro
Редкий сейчас формат, был популярен во времена зарождения хадупа. Он для больших данных и строковый.
ORC
Редкий сейчас формат, был популярен во времена зарождения хадупа. Он для больших данных и колоночный.
Iceberg
Hudi
Delta
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 lake
Хранилище файлов или объектов. Обычно характеризуется низкой стоимостью хранения и высокой масштабируемостью, но малой гибкостью работы с данными.
Если хранилищем выступает Hadoop (HDFS), на логическом уровне полноценно взаимодействовать с партицией или файлом можно только целиком. Если нужно сделать апдейт, его нельзя сделать точечно. Вставка — в конец. Также могут использоваться S3-совместимые объектные хранилища.
Используется как слой накопления данных, хранения истории. Обработку и собственно анализ данных зачастую проводят в OLAP базах (в которые нужно ETL-процессами данные сначала скопировать) или в SQL-движках поверх HDFS вроде Hive, Impala, Trino. Сами данные часто хранят в Parquet’ах или Avro. В последние годы популярность набирает Delta формат (parquet + метаданные).
Если писать все данные без представления о том, когда, кто и как ими будет пользоваться, озеро может превратиться в болото (data swamp).
Data lakehouse (hybrid)
Data lake + data warehouse. Данные хранятся в озере в виде iceberg, delta или hudi файлов. Эти форматы позволяют работать с файлами как с таблицами, через SQL.
Основная потребность в таких системах возникает, когда хранилище занимает больше 1 Пб (млн гигов), и тот же greenplum уже перестаёт справляться с нагрузкой.
В таком случае не нужно поддерживать отдельный сервис в виде DWH и копировать туда данные для обработки – слои хранятся в разных “директориях” озера. А получать доступ к данным можно через тот же Trino.
Витрины часто всё же выносят в Clickhouse для скорости доступа к данным.
Data quality
Debezium(CDC)
Change data capture (CDC) это технология захвата изменений данных с источника, для реляционных СУБД — обычно через лог базы данных. В таком случае таблица не блокируется, нагружается именно компонент, отвечающий за репликацию. В отличие от батч загрузок, которые запускаются по расписанию и теряют промежуточные изменения, CDC подтягивает все операции. Это хорошо, если такая детализация нужна. Это головная боль, если надо схлопывать эти изменения и сохранять только состояние, например, на закрытие операционного дня.
CDC создаёт поток изменений, который можно использовать для стриминговой загрузки.
Debezium это опен-сорс коннектор к различным источникам данных. Выгружает данные из Х в кафку. Из кафки нужно забирать другими инструментами, Debezium делает исключительно Load.
Streaming (Spark streaming, Flink, Kafka)
Облака(yandex cloud, yandex managed greenplum)
S3
Изначально – сервис объектного хранения данных от Amazon Web Services (AWS). Его любят разработчики за дешевизну (2 цента в месяц за 1GB) и интеграции с почти любым сервисом, языком разработки и пр. В общем, стандарт для записи и чтения данных в мире “облаков”.
Сейчас S3 это скорее интерфейс доступа к данным и правила их организации. В общем – протокол взаимодействия, и корректно будет назвать Azure ADLS, GCS, Yandex object storage и прочие – s3-совместимые хранилища.
Локально и на on-premise инфре можно развернуть в виде сервиса MinIO.
