S3 Архипелаг: как мы в Диасофте построили свое объектное хранилище / Хабр

Привет, Хабр!

На связи Илья Шуйков, руководитель продукта «Фабрика данных» компании Диасофт. В этой статье хочу рассказать, зачем мы построили свое объектное хранилище.

Лет десять назад объектное хранилище было экзотикой. Крупные компании обходились NFS‑шарами и надеждой, что RAID не развалится в самый неподходящий момент. Средний бизнес в целом не понимал, зачем это нужно.

Сегодня все изменилось. S3 API стал таким же стандартом, как REST или JSON. Логи летят в S3. Бэкапы — в S3. Датасеты для нейросетей — туда же. Spark читает из S3, Trino пишет в S3, даже бухгалтерия хочет хранить сканы договоров в S3 (правда, они не знают, что это S3, для них это просто «облако»).

Мы в Диасофте построили «Фабрику данных» (Digital Q.DataFactory) в архитектуре Data Lakehouse на основе S3 Архипелаг, которая объединяет гибкость Data Lake с надежностью хранилища данных. И ей нужен слой хранения — надежный, быстрый и желательно не чрезмерно дорогой для покупки серверов.

Почему не Open Source

Долгое время мы, как и многие российские IT‑компании, смотрели в сторону open‑source решений. Логика понятна: бесплатно, исходники открыты, сообщество поддерживает. Ceph, MinIO — все это выглядело привлекательно.

Потом начались сюрпризы. Сначала — изменения лицензий. MinIO перешел на AGPL, что для коммерческого использования создает определенные неудобства. Потом — история с «закладками» в open‑source проектах, когда код начинал вести себя по‑разному в зависимости от геолокации пользователя.

Для enterprise‑компании, работающей с финансовым сектором, такие риски неприемлемы.

Требования регуляторов по КИИ, ИСПДн и ГИС тоже никто не отменял. Данные должны храниться в России, на сертифицированных системах, желательно на Astra Linux или РЕД ОС, желательно без доступа в интернет, потому что «air‑gapped» — это не паранойя, а требование безопасности.

Муки выбора

Мы потратили полгода на анализ, тесты и споры в курилке. Вот что мы выяснили.

Ceph. Легенда. Монстр. Умеет все: блочное хранилище, файловую систему, объекты. Используется в OpenStack, в крупнейших облаках. Но есть проблема: чтобы его развернуть и поддерживать, нужна команда из 3–5 инженеров, которые знают, что такое CRUSH map, и не вздрагивают при слове «PG autoscaling». Таких специалистов на рынке мало. Мы посчитали: только на зарплаты Ceph‑команды уйдет больше, чем на само железо.

MinIO. Противоположность Ceph. Скачал бинарник, запустил — работает. Документация понятная, сообщество активное, производительность на синтетических тестах впечатляет. Мы даже почти влюбились. А потом начали копать глубже и обнаружили нюансы. На больших объемах MinIO начинает вести себя непредсказуемо. Также возникли вопросы с лицензией и ресурсами: на больших кластерах он ест память как не в себя.

SeaweedFS как фундамент

Мы выбрали архитектурно правильную основу — SeaweedFS, которая помогает отделить метаданные от данных и подходит для работы с миллионами файлов. Мы не стали изобретать велосипед с нуля, а взяли этот проверенный «движок» и направили усилия на то, чтобы превратить его в полноценный enterprise‑продукт для российского рынка: добавили встроенную безопасность, инструменты для комплаенс, углубленную интеграцию с отечественными ОС и экосистемой, коммерческую поддержку и гарантии. Дополнительно мы укрепили его для enterprise‑сценариев, в частности, для работы с Iceberg/Hudi. Так появился S3 Архипелаг.

(Почему «Архипелаг»? Потому что распределенное хранилище похоже на архипелаг островов: каждый узел — отдельный остров, но вместе они образуют единую систему).

Большое сравнение

Архитектурные различия

Прежде чем смотреть на цифры, давайте разберемся, чем эти системы отличаются «под капотом».

Характеристика	S3 Архипелаг	Ceph	MinIO
Основная идея	Баланс скорости и простоты	Универсальный комбайн	Минимализм и скорость
Интерфейсы/API	S3, HDFS, gRPC, REST	S3, Block (RBD), CephFS	Только S3
Протоколы доступа/Шлюзы	FUSE, WebDAV	NFS	-
Хранение метаданных	Отдельный слой (Filer)	Распределены по OSD	Вместе с объектами
Erasure Coding	Да, гибкие схемы	Да	Да
Минимальный кластер	3 узла	3 узла (но лучше 5+)	4 узла
Сложность развертывания	Средняя	Высокая	Низкая
Сложность эксплуатации	Низкая	Высокая	Низкая

Главное архитектурное отличие S3 Архипелага — разделение слоев. Данные хранятся на Volume Servers, метаданные — в отдельном Filer. Это позволяет масштабировать их независимо. Нужно больше IOPS на метаданные? Добавьте Filer‑узлов. Нужно больше емкости? Добавьте Volume Servers. У Ceph метаданные распределены по OSD, и на больших кластерах это становится узким местом.

Производительность: синтетика

Использовали warp (стандартный бенчмарк для S3) и собственные скрипты, имитирующие реальные нагрузки.

Тестовый стенд:

3 сервера,
8 ядер,
32 GB RAM,
4× NVMe,
25GbE,
Astra Linux SE 1.7.8

Тест 1: Мелкие объекты (4 KB), 100% запись

Система	Ops/sec	Latency p50	Latency p99	CPU (avg)	RAM (avg)
S3 Архипелаг	45,200	2.1 ms	8.4 ms	34%	12 GB
Ceph RGW	18,700	5.8 ms	24.1 ms	67%	28 GB
MinIO	42,100	2.3 ms	9.1 ms	41%	18 GB

На мелких объектах S3 Архипелаг и MinIO идут ноздря в ноздрю, но S3 Архипелаг потребляет меньше ресурсов. Ceph отстает в 2,4 раза — это плата за универсальность.

Тест 2: Крупные объекты (64 MB), 100% запись

Система	Throughput (GB/s)	Latency p50	Latency p99	CPU (avg)
S3 Архипелаг	8.2	124 ms	312 ms	28%
Ceph RGW	7.1	142 ms	389 ms	52%
MinIO	8.5	118 ms	298 ms	35%

На крупных объектах разница меньше. MinIO чуть быстрее, но разница в пределах погрешности. Ceph снова отстает, но уже не так драматично.

Тест 3: Смешанная нагрузка (70% чтение, 30% запись, объекты 1 KB - 10 MB)

Система	Ops/sec	Latency p50	Latency p99
S3 Архипелаг	38,400	3.2 ms	14.7 ms
Ceph RGW	14,200	7.1 ms	31.2 ms
MinIO	35,100	3.6 ms	16.8 ms

Смешанная нагрузка ближе всего к реальности. S3 Архипелаг лидирует, MinIO близок.

Производительность: большие объемы

Синтетика — это хорошо, но что происходит, когда данных становится много? Мы заполнили кластеры до 80% емкости (около 10 TB) и повторили тесты.

Система	Ops/sec (пустой)	Ops/sec (80% заполнен)	Деградация
S3 Архипелаг	38,400	35,100	-8.6%
Ceph RGW	14,200	12,800	-9.9%
MinIO	35,100	28,400	-19.1%

MinIO на заполненном кластере просел почти на 20%. S3 Архипелаг и Ceph держатся стабильнее. Причина — в архитектуре: MinIO хранит метаданные вместе с объектами, и при большом количестве файлов это начинает тормозить.

Ребалансировка: кто быстрее оправится от добавления узла

Мы добавили по 1 узлу в каждый кластер и замерили, сколько времени займет ребалансировка, как она повлияет на производительность.

Система	Время ребалансировки	Деградация во время ребалансировки
S3 Архипелаг	4.2 часа	-12%
Ceph	8.7 часа	-35%
MinIO	2.1 часа	-8%

MinIO ребалансируется быстро, но агрессивно потребляет ресурсы CPU/IO в процессе, что может влиять на latency бизнес‑приложений. Ceph ребалансируется долго и больно. S3 Архипелаг — золотая середина: ребалансировка идет в фоне и почти не мешает работе.

Потребление ресурсов

Система	CPU на 1 TB данных	RAM на 1 TB данных	Рекомендуемое железо
S3 Архипелаг	0.8 ядра	1.2 GB	Обычные серверы
Ceph	2.1 ядра	3.5 GB	Мощные серверы
MinIO	1.1 ядра	1.8 GB	Обычные серверы

S3 Архипелаг потребляет в 2–3 раза меньше ресурсов, чем Ceph. Это значит, что на том же железе можно хранить больше данных и/или использовать более дешевое железо.

Производительность: аналитические нагрузки

Синтетические тесты — это одно, а реальные сценарии Data Lake — другое. Мы провели тесты, которые имитируют типичную работу Spark и Trino.

Тест 4: Последовательное чтение parquet‑файлов (паттерн Spark)

Читали 50 GB данных из 200 parquet‑файлов (средний размер файла ~250 MB). Spark с 4 executor'ами, каждый читает свой набор файлов параллельно.

Система	Throughput (GB/s)	Время чтения	CPU на storage
S3 Архипелаг	0.95	53 сек	22%
Ceph RGW	0.78	64 сек	41%
MinIO	1.02	49 сек	29%

При последовательном чтении больших файлов все три системы показывают хорошие результаты. MinIO чуть быстрее, но разница в пределах 10%.

Тест 5: LIST-операции на большом бакете (паттерн Iceberg)

Iceberg при каждом запросе сканирует манифесты и делает LIST на директории с данными. Мы создали бакет с 100 000 объектов в плоской структуре и замерили время листинга.

Система	LIST 1000 объектов	LIST 10 000 объектов	LIST 100 000 объектов
S3 Архипелаг	45 ms	380 ms	3.2 сек
Ceph RGW	120 ms	1.1 сек	11.4 сек
MinIO	85 ms	780 ms	7.8 сек

Архитектура с отдельным Filer дает преимущество, S3 Архипелаг выполняет LIST в 2–3 раза быстрее конкурентов. Для Iceberg-таблиц с тысячами файлов это ощутимая разница.

Тест 6: Конкурентная запись (паттерн streaming)

Восемь параллельных writer'ов пишут файлы по 7 MB. Имитация потоковой загрузки данных в Bronze-слой.

Система	Ops/sec	Latency p50	Latency p99
S3 Архипелаг	1,240	16 ms	48 ms
Ceph RGW	680	29 ms	112 ms
MinIO	1,180	17 ms	52 ms

При конкурентной записи S3 Архипелаг и MinIO идут вровень. Ceph отстает почти вдвое — сказывается overhead на консенсус.

Важно: в реальных Spark + Iceberg сценариях производительность определяется не столько S3-хранилищем, сколько overhead самого Spark и Iceberg. Spark сериализует данные, партиционирует, пишет parquet‑файлы. Iceberg добавляет транзакционные коммиты, обновление манифестов, проверку консистентности. Все это занимает 80–90% времени операции. Хранилище влияет на оставшиеся 10–20%. Поэтому при выборе S3-решения для Data Lakehouse важнее смотреть на стабильность latency и корректность работы с Iceberg/Hudi, чем на пиковые ops/sec.

Как это устроено внутри: архитектура Master — Filer — Volume

С точки зрения архитектуры S3 Архипелаг состоит из трех типов компонентов, каждый со своей зоной ответственности.

Master Server

«Мозг» кластера. Отвечает за:

Топологию кластера — знает, какие Volume Servers живы, сколько на них свободного места.
Назначение Volume ID — когда создается новый том, Master решает, на каких узлах его разместить.
Координацию репликации — следит, чтобы данные были скопированы на нужное количество узлов.
Выбор лидера через Raft — в кластере работает несколько Master‑ов, и они между собой выбирают лидера для консистентности.

Master не хранит сами данные и не участвует в их передаче. Он только координирует. Поэтому нагрузка на него относительно небольшая, и трех узлов обычно хватает даже для крупных инсталляций.

Filer

Слой метаданных. Это ключевое архитектурное решение, которое отличает S3 Архипелаг от MinIO.

Filer хранит информацию о файлах и директориях: имена, пути, размеры, timestamps, ACL. Сами данные при этом лежат на Volume Servers. Метаданные хранятся в виде key‑value пар во внешней базе данных — можно использовать PostgreSQL, MySQL, TiKV, etcd или другие поддерживаемые бэкенды.

Такая архитектура дает несколько преимуществ:

Метаданные можно масштабировать отдельно от данных.
Операции с директориями (листинг, переименование) работают быстро даже при миллионах файлов.
Можно использовать проверенные СУБД с понятными инструментами бэкапа и восстановления.

Но есть и обратная сторона: появляется зависимость от внешней БД. Тем не менее, кластеризация Filer и использование паттернов High Availability для БД метаданных гарантирует отсутствие единой точки отказа.

Filer поддерживает различные бэкенды для метаданных: PostgreSQL, MySQL, TiKV, а также Redis и Cassandra. Для большинства задач корпоративного уровня мы рекомендуем использовать готовый управляемый стек на базе Digital Q.DataBase с предустановленными оптимизациями для низкой задержки (low latency), репликацией, автоматическим бэкапированием и мониторингом «из коробки».

Важно: При проектировании сверхкрупных Data Lake (миллиарды объектов и более) следует учитывать особенности выбранного хранилища метаданных. Реляционные СУБД, такие как PostgreSQL, обеспечивают высокую согласованность и удобство администрирования, однако при экстремальных масштабах могут возникать проблемы с разрастанием таблиц (bloat), фоновой очисткой (vacuum) и блокировками при высокой конкурентности записи. Для инсталляций такого масштаба мы рекомендуем рассмотреть использование распределенных систем: TiKV (поддерживается в Filer) или Cassandra, которые обеспечивают линейное масштабирование и высокую производительность при работе с миллиардами файлов.

Размер БД метаданных. Зависит от количества объектов, а не от их размера. По нашим замерам:

1 млн объектов — около 2 GB
10 млн объектов — около 18 GB
100 млн объектов — около 170 GB

Эти цифры — для PostgreSQL с включенным сжатием. MySQL занимает примерно на 20% больше.

Volume Server

«Рабочая лошадка», которая хранит сами данные. Каждый Volume Server управляет набором «томов» (volumes) — это большие файлы (обычно 30 GB), внутри которых упакованы пользовательские объекты.

Такой подход решает проблему «миллиона мелких файлов»: вместо того чтобы создавать отдельный файл на диске для каждого объекта, система упаковывает их в тома. Это снижает нагрузку на файловую систему и уменьшает количество IOPS.

Volume Servers масштабируются горизонтально: нужно больше места — добавляете узлы. Данные автоматически распределяются по новым узлам (с учетом политик репликации или Erasure Coding).

Отказоустойчивость: репликация vs Erasure Coding

Данные в распределенном хранилище должны переживать отказы дисков и узлов. Для этого есть два подхода, и S3 Архипелаг поддерживает оба.

Репликация — классический способ. Каждый блок данных копируется на несколько узлов (обычно 2–3 копии). Если один узел падает, данные читаются с другого.

Когда использовать:

Критически важные данные с требованием минимальной latency на чтение.
Небольшие объемы (до 10–20 TB), где экономия места не критична.
Сценарии с частым чтением и редкой записью.

Накладные расходы: при 3 копиях теряется 66% дискового пространства.

Erasure Coding (EC) — математически более эффективный подход. Данные разбиваются на k блоков, к ним добавляются m блоков четности. Для восстановления достаточно любых k блоков из k+m.

Когда использовать:

Большие объемы данных (десятки и сотни TB).
Архивные данные и бэкапы.
Сценарии, где важнее емкость, чем latency.

Накладные расходы: при схеме 10+4 теряется только 40% пространства, но можно пережить падение 4 узлов.

На практике мы комбинируем оба подхода. «Горячие» данные (Bronze‑слой Data Lakehouse, активные документы) хранятся с репликацией для быстрого доступа. «Холодные» данные (архивы, старые бэкапы) переезжают на Erasure Coding для экономии места.

Интерфейсы: не только S3

Одно из преимуществ S3 Архипелага — богатство интерфейсов.

S3 API — полная совместимость с AWS S3. Все ваши существующие инструменты (aws‑cli, boto3, любые SDK) работают без изменений.

FUSE — можно смонтировать бакет как обычную папку в Linux. Это спасение для legacy‑приложений, которые умеют работать только с файловой системой. Да, это медленнее, чем нативный S3, но иногда выбора нет.

WebDAV — доступ к файлам прямо из Проводника Windows или Finder на Mac.

HDFS — нативная интеграция с Hadoop‑экосистемой. Если у вас есть старый Hadoop‑кластер, который умеет говорить только по HDFS, S3 Архипелаг может притвориться HDFS. Миграция без переписывания кода.

gRPC — высокопроизводительный бинарный протокол для микросервисов. Минимальные накладные расходы, максимальная скорость.

Функции для бизнеса

Мы не просто сделали очередное объектное хранилище. Мы адаптировали его под нужды enterprise.

Версионирование. Случайно удалили важный файл? Перезаписали отчет? Не беда — предыдущие версии сохранены. Можно откатиться на любую точку.

Lifecycle Policies. Автоматическое управление жизненным циклом данных. Файлы старше 30 дней — на холодное хранилище. Старше года — в архив. Старше 7 лет — удалить (если регулятор разрешает).

Cross‑Region Replication. Асинхронная репликация в резервный ЦОД. Для катастрофоустойчивости.

Bitrot Protection. Система периодически проверяет контрольные суммы и автоматически восстанавливает поврежденные блоки. Потому что диски иногда врут.

Доработки для Data Lakehouse: Iceberg и Hudi

Отдельная история — работа с современными табличными форматами: Apache Iceberg и Apache Hudi. Эти форматы стали стандартом для Data Lakehouse, но они создают специфическую нагрузку на объектное хранилище.

Одна из причин, почему мы не смогли просто взять SeaweedFS «как есть» — это работа с такими форматами.

Apache Iceberg и Apache Hudi активно используются в Data Lakehouse для версионирования таблиц, ACID‑транзакций и time‑travel запросов. Под капотом они генерируют множество временных файлов: манифесты, снапшоты, файлы данных, которые потом нужно удалять или перемещать.

При типичной операции compaction или vacuum Iceberg может создать сотни временных файлов, а потом удалить их в рамках одной транзакции. Hudi при каждом коммите обновляет метаданные и чистит устаревшие версии.

При тестировании с Apache Iceberg и Hudi мы столкнулись с задержкой при массовых операциях удаления файлов, что критично для процессов compaction и vacuum. Мы оптимизировали механизм работы с метаданными в Filer и доработали клиент S3A, что позволило добиться предсказуемой latency и гарантированной консистентности при выполнении транзакционных операций этих форматов.

Развертывание: от одного сервера до кластера

Одна из задач, которую мы ставили при разработке S3 Архипелага — простота развертывания. Ceph научил нас ценить это качество.

Standalone‑режим

Для тестирования, разработки или небольших инсталляций (до 10–20 TB) достаточно одного сервера. Все компоненты (Master, Filer, Volume Server) запускаются на одной машине.

Преимущества:

Развертывание за 15 минут.
Минимальные требования к железу (4 ядра, 8 GB RAM, любые диски).
Идеально для dev/test окружений.
Можно потом масштабировать до кластера без миграции данных.

Ограничения:

Нет отказоустойчивости (один сервер — одна точка отказа).
Производительность ограничена одной машиной.

Kubernetes‑режим

Для production‑окружений мы рекомендуем развертывание в Kubernetes. Helm‑чарты и операторы прилагаются.

Преимущества:

Автоматическое масштабирование Volume Servers.
Self‑healing: упавшие поды перезапускаются автоматически.
Интеграция с существующей инфраструктурой (мониторинг, логирование, секреты).
Rolling updates без даунтайма.
Удобное управление конфигурацией через ConfigMaps.

Особенности:

Требуется Kubernetes 1.24+ (проверено на Deckhouse, vanilla K8s).
Для Volume Servers рекомендуем hostPath или local‑storage PV (не сетевые диски).

Архитектура развертывания в K8s:

Filer (СУБД метаданных) разворачивается на выделенных, изолированных нодах или внешнем кластере БД.
Volume Servers разворачиваются на отдельных нодах с локальными дисками, оптимизированных под IO‑нагрузку.
Master — StatefulSet на отдельных нодах Control Plane.
S3 Gateway — Deployment (stateless‑компонент, который проксирует S3-запросы).

Типичный production‑кластер:

Control Plane (3 узла для Master + Filer):

CPU: 8–16 ядер
RAM: 32–64 GB (зависит от количества объектов в Filer)
Диски: 2× SSD 500 GB (RAID1 для БД метаданных)
Сеть: 10GbE

Data Plane (6+ узлов для Volume Servers):

CPU: 8–16 ядер
RAM: 32–64 GB
Диски: 8–12× HDD/SSD (в зависимости от требований к latency)
Сеть: 10GbE (или 25GbE для высоких нагрузок)

Масштабируется горизонтально добавлением Volume Server‑узлов. На каждые 100 TB данных рекомендуем добавлять 1–2 узла.

Экономика

Мы посчитали TCO (Total Cost of Ownership) на горизонте 5 лет. Сравнивали три варианта:

Западное проприетарное решение (не будем называть имен)
Свой Ceph-кластер
S3 Архипелаг

Статья расходов	Западное решение	Ceph	S3 Архипелаг
Лицензии	100%	0%	40%
Железо	80%	120%	70%
Персонал	50%	150%	60%
Поддержка	80%	30%	50%
Итого	310%	300%	220%

База расчета (100%) — совокупные затраты на типовой кластер емкостью 500 TB на горизонте 5 лет.

S3 Архипелаг обходится дешевле западных аналогов и сопоставим с Ceph по общей стоимости, но при этом требует значительно меньше усилий на эксплуатацию. Экономия достигается за счет меньших требований к железу, простоты администрирования и предсказуемой стоимости лицензий без валютных рисков.

Безопасность и контроль доступа

Работа с финансовым сектором накладывает жесткие требования к безопасности. Мы не могли позволить себе подход «потом допилим» — безопасность закладывалась с самого начала.

Шифрование данных

Данные защищены на всех этапах:

At rest (на дисках). Каждый том шифруется AES-256. Ключи хранятся отдельно от данных. Даже если кто‑то физически вынесет диск из ЦОДа, прочитать содержимое не получится.

In transit (при передаче). Весь трафик между клиентами и хранилищем идет по TLS 1.3. Между узлами кластера — тоже. Man‑in‑the‑middle атаки исключены.

Аутентификация и авторизация

S3 Архипелаг интегрируется с корпоративными системами управления доступом:

LDAP/Active Directory. Пользователи и группы синхронизируются из корпоративного каталога. Не нужно заводить отдельные учетки — сотрудник авторизуется так же, как и везде.

Kerberos. Для сред, где требуется SSO и взаимная аутентификация. Особенно актуально для интеграции с Hadoop‑экосистемой.

IAM‑совместимые политики. Bucket policies и ACL работают так же, как в AWS S3. Можно задать: «отдел аналитики читает из Bronze, пишет в Silver, к Gold доступа нет».

Защита от удаления

Отдельная головная боль — защита от случайного или злонамеренного удаления данных.

Object Lock. Можно заблокировать объект на определенный срок. Даже администратор не сможет его удалить до истечения срока. Это требование регуляторов для некоторых типов данных.

Versioning + MFA Delete. Для удаления версии объекта требуется подтверждение вторым фактором.

Soft Delete. Удаленные объекты не исчезают сразу, а перемещаются в «корзину» с настраиваемым сроком хранения.

Аудит

Все операции логируются: кто, когда, что сделал с каким объектом. Логи можно отправлять в SIEM (Splunk, ELK, MaxPatrol) для анализа и расследования инцидентов. Это не опция, а требование для работы с КИИ и ИСПДн.

Совместимость с российской экосистемой

Регуляторы предъявляют конкретные требования, с которыми сталкивается любая компания, работающая с госсектором или финансами. S3 Архипелаг проектировался с учетом этих требований.

Сертификация и комплаенс

Архитектура позволяет строить системы, соответствующие требованиям КИИ, ИСПДн и ГИС. Шифрование, аудит, разграничение доступа — все на месте.

Отечественные ОС

Мы протестировали и гарантируем работу на российских операционных системах:

Astra Linux (включая релиз «Смоленск» с мандатным контролем доступа)
РЕД ОС
Alt Linux

Мониторинг

Интеграция с системами мониторинга — через стандартные метрики Prometheus. Grafana‑дашборды прилагаются. Если у вас уже есть Zabbix или что‑то свое ‑метрики отдаются в стандартном формате.

Вариант поставки

On‑premise — вы получаете дистрибутив и разворачиваете на своем оборудовании. Полный контроль, никаких зависимостей от внешних сервисов.

Как мы используем S3 Архипелаг в Диасофте

Мы внедрили S3 Архипелаг во все ключевые системы компании.

Digital Q.DataFactory (Data Lakehouse)

«Фабрика данных» — это сердце нашей аналитики. Собирает информацию из десятков источников: ERP‑системы, CRM, логи приложений, внешние данные. Все это приземляется в S3 Архипелаг.

Мы используем трехуровневую архитектуру:

Bronze (сырые данные) — как пришло, так и лежит.
Silver (очищенные данные) — дедупликация, валидация, приведение типов.
Gold (витрины) — агрегаты и метрики для бизнеса.

Spark и Trino — это компоненты Digital Q.DataFactory. Spark читает из Bronze, трансформирует, пишет в Silver. Trino строит витрины в Gold. Все это работает поверх S3 Архипелага через стандартные S3A‑коннекторы.

Микросервисы (MSA)

У нас сотни микросервисов. Каждый из них генерирует какие-то файлы: отчеты, выгрузки, временные данные. Долгое время мы использовали Ceph для этих целей. Работало, но требовало постоянного внимания: мониторинг, тюнинг, периодические проблемы с производительностью.

Послеперехода на S3 Архипелаг жизнь стала проще. Меньше накладных расходов на администрирование, стабильнее latency, проще масштабирование. Микросервисы работают через стандартный S3 API — никаких специфических клиентов или библиотек.

CRM и документооборот

Договоры, сканы документов, вложения в задачи — все это теперь в объектном хранилище. Обмен файлами между CRM и ERP идет через S3 API. Интеграция заняла неделю, потому что S3 — это стандарт, и библиотеки есть для любого языка.

CI/CD

Сборки, docker-образы, jar-файлы, npm-пакеты. Артефакты CI/CD занимают терабайты, и их нужно отдавать быстро. S3 Архипелаг справляется: разработчики не жалуются на скорость скачивания.

Бэкапы

Резервные копии баз данных (PostgreSQL, Oracle) и виртуальных машин. Здесь главное — надежность, и S3 Архипелаг ее обеспечивает. Хранилище обеспечивает устойчивость к отказам узлов и дисков. За два года эксплуатации в нашем контуре не было случаев потери данных, обусловленных сбоями в самом S3 Архипелаге. Надежность данных обеспечивается комбинацией репликации/EC, регулярных бэкапов метаданных и механизмов самовосстановления.

Заключение

Мы создали S3 Архипелаг, поскольку open‑source решения перестали быть надежной основой, Ceph оказался слишком сложным, а MinIO — слишком ограниченным.

S3 Архипелаг полезен, если:

Вы строите Data Lake или Data Lakehouse.
У вас микросервисная архитектура, и сервисам нужно быстрое хранилище файлов.
Вы храните датасеты для ML и хотите, чтобы Spark не ждал данные.
Объемы данных — от десятков терабайт и выше.
Есть требования по импортозамещению и безопасности (КИИ, ИСПДн, ГИС).
Хочется сэкономить на железе и администрировании.
Нужно несколько интерфейсов доступа (S3 + FUSE + HDFS).

Минимальные требования к железу. Для Standalone‑режима: 4 ядра, 8 GB RAM, любые диски. Для production‑кластера рекомендуем: 3 узла Control Plane (8 ядер, 16 GB RAM), 6+ узлов данных (зависит от объема, но обычно 8-16 ядер, 32 GB RAM, NVMe или SSD).

Продукт имеет trial-версию, полнофункциональную и ограниченную только объемом хранилища.

Пишите в комментариях, какие объектные хранилища используете вы и почему.

S3 Архипелаг: как мы в Диасофте построили свое объектное хранилище