Первый вопрос на собесе дата-инженера часто звучит так: «Почему нельзя строить отчёты прямо по базе приложения?» Ответ раскрывает всю карту хранилищ.
OLTP и OLAP
OLTP (online transaction processing): база приложения. Много коротких запросов, каждый читает или меняет несколько строк по ключу: создать заказ, обновить статус. Важны транзакции, низкая задержка, нормализованная схема. Примеры: PostgreSQL, MySQL.
OLAP (online analytical processing): аналитика. Мало запросов, но каждый сканирует миллионы строк и считает агрегаты по нескольким колонкам: выручка по регионам за год. Важны скорость сканирования и сжатие. Примеры: ClickHouse, Greenplum, Vertica, BigQuery, Snowflake.
Почему аналитику не гоняют по OLTP:
- Тяжёлые сканы мешают приложению: блокируют ресурсы, вытесняют кеш.
- Данные из разных систем (CRM, оплаты, сайт) не соединить в одной базе приложения.
- Нет истории: OLTP хранит текущее состояние, а аналитике нужна динамика.
Строчное и колоночное хранение
Строчное хранение кладёт значения одной строки рядом: удобно прочитать или обновить всю строку. Колоночное кладёт рядом значения одной колонки:
- Запрос читает только нужные колонки: из таблицы на 200 колонок отчёт берёт 5.
- Однотипные значения подряд хорошо сжимаются (словари, RLE, дельта-кодирование), часто в 5-10 раз.
- Агрегаты считаются векторно, пачками значений.
- Платой становятся точечные обновления и удаления: они дорогие, поэтому колоночные системы любят вставки большими пачками.
DWH
Хранилище данных (data warehouse): централизованная аналитическая база с очищенными, согласованными и историзированными данными из многих источников. Классическое определение Инмона: предметно-ориентированное, интегрированное, неизменяемое и хранящее историю.
Типичные слои:
- Staging (raw): данные как в источнике, загруженные без изменений.
- Core (detail, ODS): очищенные, связанные между источниками данные, история изменений.
- Marts (витрины): агрегаты и модели под конкретные отчёты и команды.
Озеро данных
Data lake: дешёвое объектное хранилище (S3 и совместимые, HDFS) с файлами в любых форматах: сырые логи, JSON, Parquet, картинки. Схема применяется при чтении (schema-on-read), а не при записи.
Плюсы: дёшево, любой объём, любые данные, удобно для ML. Минусы классического озера: нет транзакций и обновлений строк, легко превратить в «болото» без каталога и качества, читатели могут увидеть наполовину записанные данные.
Lakehouse
Lakehouse объединяет дешёвое хранение озера с возможностями хранилища. Ключевой элемент: табличный формат поверх файлов Parquet: Apache Iceberg, Delta Lake, Apache Hudi. Он добавляет:
- ACID-транзакции через метаданные и снапшоты: читатель видит либо старую, либо новую версию таблицы.
- UPDATE, DELETE, MERGE на файлах.
- Эволюцию схемы и партиционирования.
- Time travel: запрос к таблице на момент в прошлом.
Одни и те же таблицы читают разные движки: Spark, Trino, Flink, ClickHouse. Хранение отделено от вычислений, и их масштабируют независимо.
Как выбирать
- Небольшие объёмы и SQL-аналитика: аналитическая СУБД или даже реплика PostgreSQL для начала.
- Быстрые дашборды по событиям, высокий RPS аналитических запросов: ClickHouse.
- Большие объёмы, много движков, ML, сырые данные: lakehouse на S3 с Iceberg или Delta.
- Часто комбинация: lakehouse как основное хранилище, ClickHouse как быстрый слой для витрин.
Частые ошибки
- Строить отчёты по боевой базе приложения «пока данных мало».
- Озеро без каталога, владельцев и контроля качества.
- Обновлять строки в колоночной СУБД по одной, как в OLTP.
- Путать DWH (подход и слои данных) и конкретную СУБД.
Что спросят на собесе
- Чем OLTP отличается от OLAP и почему аналитику выносят отдельно.
- Почему колоночное хранение быстрее для аналитики и чем за это платим.
- Слои DWH и зачем каждый.
- Озеро против хранилища, что такое lakehouse и табличные форматы.