Прямо сейчас на моей работе мы с командой ДЕ переносим наш SQL Server в BigQuery. Не буквально конечно :).
Это не просто смена вендора. Это переход на фундаментально другую архитектуру работы с данными с онпрем сервера(ов) на распределенное облако.
Что такого в облаках стоящего? Помимо того что навязывает маркетинг.
🦖 Эпоха HDFS и Data Locality
Раньше был Hadoop и классические СУБД (тот же SQL Server на железе). Архитектура строилась на принципе Shared-Nothing и Data Locality: данные лежат на тех же серверах, которые их обрабатывают.
Проблема очевидная: Вычисления (CPU/RAM) и диски масштабируются неравномерно. У вас копятся петабайты исторических логов? Будьте добры докупить серверы, переплачивая за мощные процессоры, которые будут просто простаивать.
☁️Эпоха Cloud-Native
Современные базы (BigQuery, Snowflake, ClickHouse Cloud) и Data Lakes работают иначе. Данные навсегда отрываются от серверов и уезжают в Объектное хранилище (S3 / GCS).
А серверы вычислений (Compute nodes) живут отдельно и поднимаются по клику.
Но тут возникает главная архитектурная проблема: Физика объектных хранилищ.
S3 — это не файловая система. Это гигантский распределенный Key-Value сторадж, с которым мы общаемся по HTTP-протоколу. И у него есть две важнейшие характеристики, которые дата-инженер обязан понимать:
🔴 Ужасная задержка (Latency): Время до получения первого байта (TTFB) из S3 измеряется десятками миллисекунд. Для базы данных это вечность. Локальный SSD отдал бы данные в тысячи раз быстрее. Если ваша база будет читать из S3 мелкие файлы в один поток — она умрет.
Но!
🟢 Бесконечная пропускная способность (Throughput): В отличие от жесткого диска, который упирается в интерфейс SATA/PCIe, S3 позволяет скачивать тысячи файлов одновременно. Вы можете поднять 1000 серверов, и каждый скачает свой кусок на скорости 10 Гбит/с.
🛠 Как современные движки обходят физику?
Если S3 такой медленный на старт, почему BigQuery или Snowflake отдают аналитику за секунды?
Кэширование на локальных NVMe-дисках.
Вычислительные узлы (Compute) в облаке все равно имеют свои сверхбыстрые диски. Но они больше не используются как Primary Storage. Теперь это просто эфемерный кэш.
Как выглядит жизненный цикл запроса:
Вы пишете
SELECT. - Оптимизатор делит запрос на тысячи мелких тасок.
- Движок смотрит: есть ли нужные колонки в оперативной памяти?
Если нет — лезет на локальный NVMe SSD(горячие данные, которые читали недавно).
Если и там нет — идет в S3 (холодные данные), но делает это агрессивно и параллельно, выкачивая гигантские блоки данных большими кусками, чтобы перекрыть высокую сетевую задержку огромным Throughput'ом.
Что это значит для дата-инженера?
Размер файла имеет значение. Миллион мелких файлов по 10 КБ в S3 убьют любой движок из-за Latency на каждый HTTP-запрос.
Локальные джойны в памяти уходят в прошлое.
Теперь узкое горлышко вашей архитектуры — это пропускная способность сети внутри дата-центра.
Мы уходим от оптимизации индексов на жестких дисках к оптимизации сетевого I/O и колоночных форматов.
Добро пожаловать в Cloud-Native!
Волшебной таблетки нет.
Нужно держать 10,000 транзакций в секунду с миллисекундным откликом (OLTP)? Берем классическую архитектуру с тесной связкой CPU и SSD.
Нужно сканировать терабайты данных, отдавать их разным командам и не разориться (OLAP/Data Lake)? Уходим в Cloud-Native форматы с разделением стораджа и вычислений.
#data_engineering #cloud_native #bigquery #olap #oltp
#dj_architecture