Fundamentals of Data Engineering, глава 4: Выбор технологий

Главная мысль: сначала архитектура, потом технологии. Архитектура — это что, зачем и когда. Инструменты — это как. Хороший инструмент добавляет ценность продукту данных и бизнесу.

Критерии выбора

Книга называет одиннадцать факторов:

Фактор	Коротко
Team size and capabilities	Малой команде нужны managed и SaaS. Не копируйте сложные системы больших компаний (cargo-cult engineering)
Speed to market	Быстрее выпускайте ценность. Долгие споры о выборе вредны
Interoperability	Насколько легко технологии соединяются. Стандарты: JDBC, ODBC. REST не стандарт, у каждого API свои особенности
Cost and business value	TCO, TOCO, FinOps
Immutable и transitory	Что стабильно, а что быстро уходит
Location	On-prem, cloud, hybrid, multicloud
Build vs buy	Строить или использовать готовое
Monolith vs modular	Один продукт или набор модулей
Serverless vs servers	Абстракция против контроля
Optimization and benchmarks	Не верьте вендорским тестам без проверки
Undercurrents	Безопасность, data management, DataOps, архитектура, software engineering

Учитывайте навыки команды. Изучение нового инструмента стоит времени. Часто его так и не доводят до production.

Стоимость и ценность

TCO

Total cost of ownership — полная стоимость проекта. Входят прямые затраты (зарплаты, счёт AWS) и косвенные (overhead).

Вид затрат	Что это
Capex	Крупные вложения заранее: железо, ЦОД. Окупаются годами
Opex	Платежи по мере использования. Гибко. Легче отнести к проекту

Книга советует подход opex-first: облако и pay-as-you-go. Железо быстро стареет и не масштабируется.

TOCO

Total opportunity cost of ownership — цена упущенных возможностей. Выбрав стек A, вы отказались от стеков B, C и D. Вопросы:

• Насколько быстро и дёшево можно уйти со стека A?
• Пригодится ли накопленный опыт в следующем поколении технологий?
• Можно ли заменять отдельные компоненты?

Негибкие технологии авторы сравнивают с bear traps: войти легко, выйти трудно.

FinOps

FinOps — это не только экономия. Цель: получить больше бизнес-ценности от расходов на облако. Быстрые эксперименты и динамическое масштабирование — часть этой ценности.

Сегодня и будущее: immutable и transitory

• Immutable технологии живут десятилетиями (эффект Lindy): object storage, сеть, SQL, bash.
• Transitory технологии приходят и уходят. Пример: Hive уступил место Presto и другим.
• Совет: стройте основу на immutable технологиях. Transitory инструменты ставьте вокруг неё.
• Пересматривайте выбор раз в два года.
• Планируйте под текущие нужды и ближайшие планы. Не переусложняйте ради далёкого будущего.

Где запускать

Вариант	Особенности
On-prem	Своё железо. Вы отвечаете за ремонт, обновления и запас под пики. Всё ещё обычен для зрелых компаний
Cloud	Аренда. IaaS (VM), PaaS (управляемые БД, Kubernetes), SaaS (готовые платформы). Быстрый старт, посекундная оплата
Hybrid	Часть нагрузки остаётся у вас. Удобный пример: аналитика в облаке, данные идут в одну сторону, egress минимальный
Multicloud	Несколько облаков. Причины: близость к клиентам, лучшие сервисы. Минусы: egress, сложность сети и безопасности

Serverless — автоматическое масштабирование от нуля, оплата по использованию. Серверы при этом есть, но вы их не видите.

Экономика облака

• Облако не равно on-prem. Перенос серверов один в один (lift and shift) разумен как первый шаг. Но долго работающие VM в облаке дороже, чем свои.
• Чтобы получить выгоду: autoscaling, reserved и spot instances, serverless.
• Облако продаёт не только ресурсы, но и надёжность, долговечность, предсказуемость. Архивное хранение дёшево, но дорого читать.
• Data gravity: загрузка данных дешёвая или бесплатная, вывод (egress fees) дорогой. Это связывает вас с вендором.

Советы авторов

• Выбирайте технологии для настоящего, но имейте escape plan.
• Не берите hybrid или multicloud без веской причины: регуляции, клиенты на разных облаках, особые сервисы. Иначе выбирайте одно облако.
• Любая технология, даже open source, создаёт некоторый lock-in.

Cloud repatriation

Пример Dropbox часто приводят как довод за возврат на свои серверы. Книга предупреждает: вы не Dropbox. Dropbox хранит эксабайты, имеет огромный трафик и специальный продукт. Возврат на своё железо имеет смысл при масштабе порядка эксабайта данных или терабит в секунду трафика, или когда egress — главная статья расходов.

Build vs buy

Правило: стройте своё, только если это даёт конкурентное преимущество. Иначе используйте готовое. Избегайте undifferentiated heavy lifting.

Аналогия книги: вы покупаете шины, а не делаете их из сырья. Команды, написавшие свою БД, зря потратили время.

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

Тип решения	Что проверять
Community OSS	Mindshare, зрелость, поддержка сообщества, скорость ответа на issues, спонсоры, roadmap, ваши ресурсы на хостинг
Commercial OSS (COSS)	Ценность управляемой версии, условия поддержки, цены, финансы компании, вклад в open source. Примеры: Databricks, Confluent, dbt Labs
Независимый proprietary продукт	Interoperability, документация, цены и сценарии нагрузки, срок жизни компании
Proprietary сервис облака	Цена и качество против OSS, скидки на reserved capacity, привязка к облаку

Рекомендации книги:

• По умолчанию выбирайте OSS и COSS. Настраивайте свой код только там, где это двигает бизнес.
• Не считайте внутренние операционные затраты бесплатными. Лучше обучить команду работе на managed платформе.
• Заранее выясните, кто утверждает бюджет. Время съедает сделки.

Monolith vs modular

	Monolith	Modular
Плюсы	Просто понять, один инструмент, меньше переключений	Лучший инструмент на каждый шаг, лёгкая замена, Parquet в object storage читают разные движки
Минусы	Хрупкость, долгие релизы, трудная изоляция нагрузок, тяжёлый уход от вендора	Больше систем, сложнее interoperability, нужна orchestration

Пример из книги: монолитный ETL работал 48 часов. При любой ошибке всё запускали заново.

Distributed monolith — распределённая система с общим кодом и зависимостями. Примеры: Hadoop-кластер, Airflow (все executor запускают один код и зависимости). Решения: ephemeral infrastructure (отдельный кластер на задачу, как EMR и Dataproc) и контейнеры.

Совет: проектируйте под interoperability, избегайте bear traps, сохраняйте гибкость.

Serverless vs servers

Serverless (AWS Lambda, BigQuery) даёт быстрый старт и оплату по использованию. Риск: на большом числе событий стоимость быстро растёт, особенно при одном событии на вызов.

Контейнеры (Docker, Kubernetes) — лёгкая изоляция зависимостей. Они частично решают проблему distributed monolith. Но контейнеры изолированы хуже, чем VM. Кластер подходит только для среды взаимного доверия.

Если используете серверы:

• ожидайте отказов, не делайте special snowflake серверов;
• применяйте кластеры и autoscaling;
• управляйте инфраструктурой как кодом (Terraform, CloudFormation);
• для сложных зависимостей берите контейнеры.

Когда serverless подходит:

Критерий	Вопрос
Размер задачи	Простые задачи — да. Много памяти и CPU — нет
Частота и длительность	Есть лимиты платформы
Сеть	Может не поддерживать VPC и firewall
Язык и runtime	Только поддерживаемые
Стоимость	Мало событий — дёшево. Много — дорого

Совет: сначала serverless, потом контейнеры и серверы, когда вы выросли.

Бенчмарки

Книга предупреждает о нечестных сравнениях:

• слишком маленькие наборы данных, которые помещаются в кэш;
• сравнение систем с разной моделью оплаты (постоянный кластер и посекундная оплата);
• асимметричная оптимизация: разные схемы и настройки для разных систем.

Проверяйте на своих данных и своих запросах.

Undercurrents при выборе

• Data management: спросите вендора о защите от утечек, GDPR и CCPA, месте хранения, контроле качества.
• DataOps: для OSS мониторинг и деплой на вас. Для managed смотрите SLA, оповещения и прозрачность инцидентов.
• Data architecture: избегайте лишнего lock-in, обеспечьте interoperability и ROI.
• Software engineering: покупайте решённые задачи, например коннектор БД в облачное хранилище. Свои силы вкладывайте в то, что отличает бизнес.

Пример: Airflow

Apache Airflow создан в Airbnb в 2014 году. Плюсы: активный проект, большое сообщество, много managed вариантов. Минусы: scheduler и backend БД плохо масштабируются, нет схем, lineage и каталога, сложно тестировать. Альтернативы: Prefect и Dagster.

Ключевые термины

Термин (EN)	Что значит
TCO	Полная стоимость владения, прямая и косвенная
TOCO	Цена упущенных возможностей из-за выбора
Capex / Opex	Затраты заранее / затраты по мере использования
FinOps	Управление расходами в облаке вместе с бизнесом
Immutable / transitory	Долгоживущие / быстро устаревающие технологии
Lindy effect	Чем дольше технология живёт, тем дольше проживёт
Data gravity	Данные трудно перенести: egress дорог
Egress fees	Плата за вывод данных из облака
COSS	Коммерческая версия open source (управляемый сервис)
Distributed monolith	Распределённая система с общим кодом и зависимостями
Lift and shift	Перенос серверов в облако без изменений
Serverless	Автомасштабируемые сервисы без управления серверами

Что это значит на практике

• Сначала нарисуйте архитектуру и требования. Потом выбирайте инструменты.
• Перед покупкой оцените TCO и TOCO. Спросите: как мы отсюда выйдем?
• Малая команда выбирает managed сервисы. Своё пишут только для конкурентного преимущества.
• При переносе в облако не оставляйте VM работать 24/7. Включите autoscaling, spot, reserved или serverless.
• Моделируйте стоимость serverless при росте событий и при worst case, например атаке ботов.
• Запускайте бенчмарки на своих объёмах. Не верьте цифрам вендора.
• Раз в два года пересматривайте стек. Держите основу на immutable технологиях.

Вопросы для самопроверки

1. Чем TCO отличается от TOCO? Почему авторы называют TOCO слепым пятном?
2. Когда имеет смысл строить своё решение, а когда покупать?
3. Что такое distributed monolith? Какие два способа его смягчить?
4. Почему пример Dropbox не подходит большинству компаний?

Предыдущая: Хорошая архитектура данных. Следующая: Источники данных.