Самую первую можно оставлять с "инвертированной" датой. Вычитать из какого-то таймстемпа в UInt64 в далёком будущем текущий и получится, что у каждой новой записи аргумент будет меньше, чем у самой первой. И она удалится.
ReplacingMergeTree предлагает дедубликацию по ключу сортировки (секция ORDER BY в DLL таблицы), которая в данном случае не применима, так как в рамках задачи нужно не просто удалять дубли по ключу, а выбирать из дублей подходящую строку (исходя из timestamp в имени файла)
timestamp из названия файла нельзя парсером подтащить в виде значения в поле insertTime? или просто использовать MATERIALIZE колонку с таймстемпом вставки и её потом использовать как аргумент. Да и без аргумента replacing движок оставляет только смую последнюю вставленную строку. Пробблема движка в том только, что удаляет он не сразу и при выборке из таблицы дубли могут ещё оставаться и их надо чистить селектом.
Ну или я не так понял задачу))
И одна опечатка -
-- Перемещение партиции из промежуточной в чистовую таблицу:
ALTER TABLE clean MOVE PARTITION {partKey} TO TABLE clean;
Тут всё таки из tmp в clean, а не из clean в clean.
Мы для ad hoc запросов ведём репозиторий в корп гитлабе с ветками, мёрдж реквестами, код ревью и ссылками на соответствующие таски в жире. Менеджер доволен, аналитики ещё больше, потому что менеджер может даже сам переиспользовать код для новых задач, подобных старым. Ну и если типовая задача всплывает очень часто - она превращается в задачу на страничку в дэшборде или на рассылку ксв файла через airflow.
Спасибо, хорошая статья. Имеем такой же стек (кликхаус в виде DWH, Airflow, только в конце используем PBI). Почему думаете в сторону HDFS и какую роль в архитектуре тогда видите для кликхауса? Только витрины для сложной аналитики?
Самую первую можно оставлять с "инвертированной" датой. Вычитать из какого-то таймстемпа в UInt64 в далёком будущем текущий и получится, что у каждой новой записи аргумент будет меньше, чем у самой первой. И она удалится.
А вот это точно правдиво?
ReplacingMergeTree предлагает дедубликацию по ключу сортировки (секция ORDER BY в DLL таблицы), которая в данном случае не применима, так как в рамках задачи нужно не просто удалять дубли по ключу, а выбирать из дублей подходящую строку (исходя из timestamp в имени файла)
timestamp из названия файла нельзя парсером подтащить в виде значения в поле insertTime? или просто использовать MATERIALIZE колонку с таймстемпом вставки и её потом использовать как аргумент. Да и без аргумента replacing движок оставляет только смую последнюю вставленную строку. Пробблема движка в том только, что удаляет он не сразу и при выборке из таблицы дубли могут ещё оставаться и их надо чистить селектом.
Ну или я не так понял задачу))
И одна опечатка -
-- Перемещение партиции из промежуточной в чистовую таблицу:ALTER TABLE clean MOVE PARTITION {partKey} TO TABLE clean;Тут всё таки из tmp в clean, а не из clean в clean.
В остальном очень интересно, спасибо.
Мы для ad hoc запросов ведём репозиторий в корп гитлабе с ветками, мёрдж реквестами, код ревью и ссылками на соответствующие таски в жире. Менеджер доволен, аналитики ещё больше, потому что менеджер может даже сам переиспользовать код для новых задач, подобных старым. Ну и если типовая задача всплывает очень часто - она превращается в задачу на страничку в дэшборде или на рассылку ксв файла через airflow.
Только сейчас увидел, что моё решение из чата стало примером для "типичного выпускника DS курсов"))
Так приходит слава. Спасибо, Илья)
Спасибо, хорошая статья. Имеем такой же стек (кликхаус в виде DWH, Airflow, только в конце используем PBI). Почему думаете в сторону HDFS и какую роль в архитектуре тогда видите для кликхауса? Только витрины для сложной аналитики?
Хочется продолжения)