Комментарии 27
по-скольку скрипты сверки такой же сложности как и исходные скрипты трансформаций - как доверять тому что сами скрипты сверки верные?
Мы пока не преисполнились настолько, чтобы писать тесты на тесты, но всё же сверки это проще, чем целый пайплайн данных. Начиная с того, что проблемы могут возникать в отправке данных из продуктов, а исходной табличке мы верим изначально. В целом по запросам аналитиков и ручным действиям новых проблем, которые бы не показали сверки, найдено не было, поэтому пока нет причин им не доверять.
К тому же за трансформацию и отправку данных в Clickhouse у нас отвечают сервисы, написанные на Benthos (он позволяет в декларативном стиле на yaml-е описать правила трансформации), что совсем не похоже на сервис на Python. Поэтому разница в подходах помогает подсветить все несовпадения.
а что делать с тем что при изменении логики пайплайна - тесты сами автоматически не меняются?
В плане поддержки и мониторинга, конечно, нужен баланс, между количеством сверяемых данных и частотой обновления схем. Пока мы актуализируем схемы вручную, тут ничего хитрого еще не изобретали. Когда сделаем единый дата-каталог, возможно, с его помощью будет легче это автоматизировать, но пока выглядит как overengineering в наших масштабах
Выглядит как очень ресурсоемко и не совсем понятно какой риск вы закрываете.
Что должно случиться для расхождение между столбцами в одной строке?
И выглядит, что можно проще решать такие штуки через сверку распределений в двух датасетах - это будет дешевле, чем такой джойн.
Не более ресурсоемко, чем руками каждый поток данных сверять, учитывая что их со временем все больше становится, а новую сверку на обкатанном подходе добавить достаточно легко.
Причин для расхождений может быть много - например в столбце updated_at/modified_at не всегда актуальная дата приходит - надо разбираться, почему. Либо статусы заказов при отправке в шину маппятся не так как ожидается. Либо с форматом данных накосячили. Тут при желании можно на отдельную статью материала набрать :)
Насчет датасетов не совсем понял идею, привести данные к одному виду все равно придется, но было бы интересно узнать, если у вас есть альтернативное решение
И еще, контрольная сумма или распределения — это тоже далеко не бесплатно с точки зрения ресурсов (особенно когда таблицы большие). И потом, они снова вам не показывают, что именно различается. Ну так, для примера, вот автор пишет: «Базу из миллиардов записей никто не пытается сверить напрямую.». Вообще говоря, на базе из миллиарда даже простой count(*) это далеко не бесплатно может оказаться, и не быстро. Быстро — это только из статистики можно взять, а статистика — она по определению может быть не актуальна.
ну так идеальная проверка будет такой же сложности как и исходный ETL - и работать столько же времени :)
В нашей компании сам ETL на самом деле достаточно ограниченный, это скорее доставка до stage-слоя сырых данных, с адаптированной структурой под хранилище. Основная трансформация происходит на слое витрин, но в этот момент мы уже имеем информацию о качестве этих данных.
так а качество витрин вы чтоли не проверяете??
Сами же пишете: "только десятые доли процента в наших расхождениях приходились на технические проблемы сети. Остальное — логика."
А витрины - это место концентрированной логики - там она прямо гнездится как пчелы в улье. Это самое то место за качеством данных в котором надо следить. Мы все DQ метрики в первую очередь для витрин и создаем
У нас в текущей организационной структуре нет большой боли в этом, витрины создаются и поддерживаются аналитиками, которые погружены в процессы изменения продуктов и специфику данных в них. И за качество витрин отвечают аналитики. То есть, проблемы на слое витрин тоже случаются, но гораздо реже.
Возможно, в будущем доберемся до DQ и в этом слое, но текущие сверки все таки ориентированы на качество данных в самом хранилище, и тут проблем оказалось достаточно
Видимо у вас модель 1:1 аля одна витрина на каждого аналитика. Все таки в более взрослой структуре - уже появляются общие витрины актуальные для многих людей или даже всей компании.И они должны быть 100% релевантными, т.к. на них уже базируется не песочница одного аналитика а отчетность для целых отделов или топов
Это отдельная большая история, впрочем.
Да, сумму можно использовать для предварительной оценки, что с данными все ок. Если не ок, то в дальнейших исследованиях это ничем не поможет.
А еще, я добавил абзац "Логи", чтобы было видно, что мы все проблемы видим сразу с примерами, и все проблемные ID-шники под рукой.
готовых решений не нашёл
Думаю и не найдете. Вот смотрите, я делаю такой же сервис (ему уже лет пять или шесть). Он внутренний.
Потребности наши похожи, но в тоже время, постановка нашей задачи достаточно сильно отличается от того, что у вас. Я вообще не уверен, что это можно просто унифицировать. Например, возможно я не увидел, но у вас вообще не рассматривается вопрос, что источник и реплика не синхронны. В тоже время у нас это практически всегда так — репликация периодическая, и производится раз в сутки или в час. Всех устраивает Т-1 в реплике, потому что это система для отчетности. Соответственно, так как данные не синхронны, возникает вопрос синхронизации их на одно время. А лучше на одну транзакцию.
Да, мы пока не уперлись в эту проблему, чтобы бороться с задержкой в синхронности реплики. Также какое-то время может уходить на доставку данных до хранилища. Если проблемы есть, они в любом случае проявятся на сверке после того как реплика будет синхронизирована, и запущена сверка, которую мы запускаем пока раз в сутки. Хотя для более чувствительных и важных данных возможно будем запускать чаще и проводить сверки за меньшие периоды.
На требование сверки в рамках одной транзакции конечно текущий сервис не заточен, но мы пока так нашли свой баланс между требованиями и вложениями в этот проект. В целом нет уверенности, что движение в эту сторону подсветит какие-то неизвестные проблемы с данными.
Но зато у нас при репликации нет никаких преобразований, кроме изменения типов данных (там где нет совместимых). Все прочие изменения производятся уже на хадупе, который является целью.
У нас есть полностью аналогичная структура, множество продакшн-узлов на MySQL и один аналитический на Clickhouse. Тоже шина данных и весьма сложные процессы трансформации (вплоть до того что сверять по количеству нельзя, надо сверять суммы или другие показатели, да и таблицы не переносятся as is).
Но мы пошли немного другим, более простым, как мне кажется, путем: прокинули туннели от clickhouse к продакшн-базам, подключили их через движок clickhouse, дальше аналитики написали запросы для сверок, и мы обернули их в примитивную систему которая запускает запросы по крону и кидает алерты в слак, если запросы что-то возвращают (разницы).
Это работает, и при том довольно легко масштабируется и дорабатывается. С учетом того что clickhouse выполняет всю работу с данными - ещё и достаточно быстро.
Да еще и заставили аналитиков быть тестерами - i like it !!! Сплошной профит
Мы пробовали этот подход, но в то время мы нагребли много проблем:
- limit не отрабатывал нормально, поэтому не было возможности забирать данные по частям. У нас есть большие таблички, и забирать данные оттуда не получалось вообще никак
- были проблемы с джойнами, условиями (часть внешних фильтров не переносилась на MySQL)
- плохо отрабатывали группировки и having
- из-за сложных запросов прикладывался Clickhouse
Кроме того, сложные запросы могут прикладывать продакшн-базы, но вы видимо сами следите за тем чтобы аналитики писали оптимальные запросы.
Сейчас возможно эти проблемы уже пофиксили, но в нашей инфраструктуре это казалось проблематично. Кликхаус у нас на нескольких нодах, джойны с distributed таблицами могут создавать лишний нагрузочный фон.
В нашем случае мы просто имеем единообразный способ сверять все данные и все поля, без вероятности того, что какая-то часть данных может не оказаться в сверочном запросе аналитика и не доезжать.
А не пробовали рассмотреть great_expectations или по стеку не совсем подходил? https://docs.greatexpectations.io/docs/
Джойны на спарке? Жесть какая.
А про дерево Меркла вы когда-нибудь слышали?
Я никогда не слышал про дерево Меркла, сейчас прочитал, но не понял как это может облегчить решаемую задачу. Не могли бы пояснить?
Потери данных при репликации в аналитическое хранилище — автоматические сверки и мониторинг качества данных