Комментарии 13
Поясните, каким образом у вас "КХ хорошо работает с сырыми данными", если эти данные находятся в s3, а оптимизатор в КХ оставляет желать лучшего (даже в версии 22.8)?
Данные в S3, которые необходимо было быстро перенести из BigQuery, лежат в паркетах по структуре данных так, как они хранились в Google. В нашей архитектуре ClickHouse их напрямую не читает, они были перенесены из S3 в ClickHouse с помощью отдельного алгоритма на Python. Естественно, была произведена адаптация структуры данных по CH, а новые данные — поступают уже в рамках этой структуры)
По текущим задачам ClickHouse обращается в S3 только при чтении вытесненных данных по TTL (https://cloud.yandex.ru/docs/managed-clickhouse/tutorials/hybrid-storage). Каких-то проблем с этим механизмом не испытываем, всё довольно шустро, но прям тесты не проводили.
Тогда как вы достигаете консистентности сырых данных при загрузке в КХ? Ведь КХ не гарантирует этого...
После записи данных происходят проверки мета-информации: кол-во строк полученных из источника должно совпадать с кол-вом строк записанных в CH. Если происходят какие-то обрывы соединений, то ETL-процедура перезапускается. Мы пользуемся дедупликацией, поведением движка Replication Merge Tree по-умолчанию
Ответ 200 OK не гарантирует от КХ получения этих данных после. Как и сколько вы выжидаете, что все данные доехали? Или же вы не сталкивались в этой проблемой?
Мы используем clickhouse_driver, нативный TCP-интерфейс. В рамках него ни разу не ловили ситуацию, чтобы часть данных не загрузилась — он висит на выполнении пока не закончится запись. Через 15 секунд, после завершения записи, запускается таска проверки.
Вообще мы ее запускаем, чтобы проверить, что данные отреплицировались на другие хосты. Если в течение нескольких минут по ретраям таска не получает успешного статуса, она падает с ошибкой — и это уже алерт. Такое было несколько раз из-за забития очереди репликации в CH.
Каждый раз удивляюсь когда green plum называют быстрым.
Если мы говорим про джойны в ядре хранилища, которых очень много в рамках данного проекта, то Greenplum значительно быстрее, чем тот же ClickHouse. И в целом в рамках opensource MPP-систем выбор не особо велик, а зарубежные вендоры под понятными рисками
CH и GP несравнимые в этом плане системы тк на CH у вас в принципе не особо хорошо JOIN получится сделать как таковой. GP работает на fullscan операциях и это уже на старте не делает его чемпионом.
У вас есть S3. Добавьте metastore к нему и дальше любой SQL движок (напр Impala, Presto\Trino) который умеет читать и писать S3). И это будет гораздо эффективнее с тч cost per performance в облаке чем GP да и еще гибче на порядок.
Спасибо за вариант)
Потестим, насколько хорошо будет работать и насколько в такой парадигме удобно использовать это для организации DDS-слоя. Просто у нас одним из входящих требований были стабильные затраты на инфраструктуру, а в рамках использования S3 это платная опция, зависящая от числа операций.
А можно чуть подробнее про алертинг? Как вы бизнесу сообщаете о проблемах и что отчетами можно пользоваться? На сами даши выводите предупреждения или алерты в тг, слак?
Локализация и рывок вперед: как мы разработали новый подход к облачному хранению данных для Hoff