Коллеги,

Как нынче строится реалтайм DATALAKE/STAGE/LANDING/ODS ? )
Раньше я, как и многие, делал по старинке - через загрузку раз в день/раз в N минут, но хотелось бы попробовать что-то более современное.

Но нужно, чтобы не дорого.
То есть решения чтения логов типа Информатики и Oracle Golden Gate не то, что не подходят, но имеют низкий приоритет.


Предположу, что должно быть что-то типа лямбда-архитектуры:

(стриминг) источник РСУБД (cdc) -> очередь -> ХД
(пакетный режим) источник РСУБД -> стандартный ETL -> ХД

Глупые вопросы:
1) Правильно ли я понимаю, что пакетный режим лямба-архитектуре ввели из-за того, что сообщения через очередь могут теряться? К примеру тот же RabbitMQ вытолкнет сообщение, а приемник его не примет. Или очередь Kafka очистится раньше, чем обработаются сообщения. Или это для первичного наполнения приемника? В общем, зачем там пакетный режим?
2) Если в качестве источника что-то типа ElasticSearch, то как его обработать? Там есть нечто типа cdc?
3) Если в качестве источника Oracle, то что там нужно применять для отправки сообщений в очередь? Они же cdc отменили у себя и хотят, чтобы все переходили на Oracle Golden Gate (https://docs.oracle.com/cd/E11882_01/server.112/e25554/cdc.htm#DWHSG016)
4) Если в качестве источника MS SQL, то достаточно встроенного cdc или сейчас есть иные варианты?

Было бы интересно почитать про те близкие к реалтайм системы, которые построили форумчане.

a_voronin,

Не-не, якорная модель и DV расчитаны в основном на хранение данных, а не на использование (скажем так, на это сделан акцент, чтобы это исправить - нужно сильно вкладываться в бизнес-слой). Эти модели отлично подойдут госорганам и тому же ЦБ, чтобы он знал "а что эти сволочи из коммерческих банков поменяли задним числом?". Но ритейлу? Я, честно, сомневаюсь.

Пока хочу сделать что-то типа мегазеркала, где будут данные и из 1С, и из SAP, и из кучи других систем. Это зеркало должно содержать 1-в-1 копии таблиц из всяких разных источников. Чтобы его можно было использовать сразу. И только потом использовать это мегазеркало как STAGE/ODS для хранилища (не важно, по какой идеологии оно будет построено/отрефакторено).

Просьба модератору перенести топик сюда https://www.sql.ru/forum/systems-architecture

a_voronin,

Ваше видео - это, насколько я понял, metadata driven etl?

a_voronin,

Продвинутым бизнес-пользователям (тем, кто может залезть в ODS и сам написать adhoc-запрос) будет неудобно. Вот представьте, имеется OLTP в виде, скажем, Аксапты, имеется какой-то аналитик, знакомый с ее моделью данных, но доступа к продуктивной СУБД у него нет (что нормально), мол, пользуйся ХД. Он залезает в ХД и вместо 2х таблиц "клиенты" и "проводки" видит 50-100 таблиц...

Мм, в qvd-слой Qlik Sense мне не нужно )) Проприетарные дорогие штуки тоже не хотелось бы.
Мне нужно лить в MS SQL, но с перспективой перехода на хадуп.

В моем видении этот слой будет являться и stage, и ods, и datalake одновременно. Максимально простой, практически 1-в-1 с источниками, и без какой-либо логики. Единственные допустимые преобразования в нем - это преобразования типов, если из-какой-либо СУБД приходит тип данных, отсутствующий в целевой СУБД. Плюс допустимы расчетные столбцы (если льются данные из сотен торговых точек, то можно сформировать ключи). Всё.


На вопрос "зачем онлайн" - пока в основном это чисто интерес, вдруг уже это можно чем-то опенсорсным делать. Если есть такая штука и она недорога (а лучше бесплатна!), то почему бы и не поднять свои компетенции )


Ivan Durak,

А вы под лямбой понимаете стриминг и батчи в один оконечный приемник или в разные? И почему не каппа-архитектуру использовали?

a_voronin,

Понятно. Просто в моей текущей концепции пользователи (конечно, не все) вполне могут ходить в STAGE/ODS.

Для примера, если есть продвинутый аналитик, знающий модель исходной системы, и нет желание пускать его в продуктивную систему-источник, то он вполне может писать свои запросы в STAGE/ODS или использовать Self service-средства BI .

По сути - только внедрили STAGE/ODS и у вас сразу пошла отдача для компании! Мне думается, это офигительный плюс для тех же интеграторов.

Нарисовал картинку:

Не очень, если честно. Кардинально отличие того же DDS-слоя от STAGE/ODS - в DDS появляются правильные числовые суррогатные ключи. К примеру те же табулярные кубы плохо переваривает составные ключи.

Или вам нужно посчитать, скажем, какой-нибудь отчет о "Прибыли и убытках", а для его расчета вам заранее нужно посчитать 10-20 таблиц. Делать это в STAGE/ODS совсем некомильфо.