Как мы ушли от ETL к CDC: выбираем архитектуру real-time аналитики на PostgreSQL, Kafka и ClickHouse. Часть 1

[ptr128]

На самом деле тут целый ряд опущенных проблем.

1. Сериализация и десериализация в JSON существенно медленней, чем, например, в protobuf. В первую очередь, из-за необходимости преобразования из двоичной системы исчисления в десятичную и обратно.

2. Sink для PostgreSQL очень неэффективен, что заставило нас написать собственное решение, использующее COPY FROM stdin binary. Если удаления и модификации записей не требуется, то сразу в целевую таблицу. В противном случае - в буферную нежурналируемую, что бы потом обновить целевую таблицу MERGE.

3. Самое главное. CH и JOIN плохо совместимы. Исключение составляют справочники, но это не таблицы и у них свои ограничения. Поэтому данные из разных БД всё равно приходится объединять в широкие таблицы, которые куда эффективней для колоночного хранения, чем JOIN в запросах. И подобные трансформации выполняются на PostgreSQL.

4. CH эффективно вставляет записи только крупными пакетами. Всё же каждая вставка для него - создание нового файла. И только потом он будет накопившиеся мелкие файлы объединять в один с дедупликацией. Поэтому в CH заливаем данные периодическим заданием. А отчёты используют данные и из CH, и из PostgreSQL. Из последнего берутся только те данные, которых еще нет в CH.

[fenixberg]

А почему не использовали Greenplum (mpp для postgres)?

[ptr128]

Greenplum больше про MPP, что не всегда возможно.

Например, когда отчеты требуют использования перцентилей при агрегации по независимым аналитикам.

[RaftLeader]

Интересно как на кликхаусе оригинальные таблицы восстанавливали? Как обрабатывали апдейты и удаления строк. Какие движки использовали для таблиц, чтобы избежать дублей обновляемых строк?

самый больной вопрос - как джойнили данные из таблиц в итоговую реалтайм витрину.