Comments 16
Архитектура
Кусок архитектуры на скрине неясен. Верхний Spark — это скорее всего Spark-Streaming, который вычитывает из Kafka и Rabbit, здесь понятно. Но как и зачем к спарк-стримингу подключается Airflow?
Расскажите, пожалуйста, для Spark Streaming у вас выделен отдельный пулл ресурсов в кластере или получается запускать всё в, так скажем, общем?
3 год СВО , а Касперский рассказывает про ms SQL
Спасибо за подробный пост, вы очень интересно все расписали. А еще большее спасибо за описание проблем!
Небольшое дополнение, что улучшит понимание. У вас вьюпоинт на самих инструментах (компонентах, технологиях) поэтому кажется не все логичным, а если добавить вьюпоинт (дополнительную диаграмму) на функциональность (слои трансформации данных), то все будет логичным. У вас приземление в хадуп, потом слой детальных данных(core) в первом мсскл на датавалте, потом презентационный слой с витринами на втором мсскл. Именно поэтому разный подход к моделированию!
Не думали использовать продукты confluent. Понятно что не будет универсальности, т.к. будет поддержка только Kafka. Но работа в тандеме со Schema Registry вроде как решает проблему изменения схемы, а также обеспечивает контроль версий схем. Да и RabbitMQ можно прогнать через Kafka.
Да, мы рассматривали возможность использлования Schema Registry, у него действительно много преимуществ при работе с kafka, но он не очень ложился в уже сложившуюся архитектуру нашего ESB, поэтому пока не применяем его.
Расскажите, пожалуйста, как используете брокеры. Как временный буфер (время жизни сообщения допустим неделя) или с постоянным хранение истории?
Железо пока позволяет хранить всю историю для большинства топиков. Но в целом конечно не предполагается, что данные будут вечно храниться в брокерах, поэтому приземляем их в Datalake, чтобы всегда иметь доступ к истории. Также для отдельных особенно больших топиков срок жизни сообщений сокращенный, как раз в рамках недели.
Озеро для дата-склада: как мы нырнули в новые методы хранения данных и что из этого вышло