На заре карьеры довелось мне участвовать в постройке маленького локального хранилища данных. Подняли Clickhouse, настроили ETL в Airflow. Всё круто. Но через пару месяцев пришлось пересобирать хранилище заново.
Как говорится, просчитался, но где?...
Во-первых, при выборе технологии (Error #1). Хайпанули. Clickhouse нам не очень подходил. С одной стороны, мы теряли ACID, функциональность внешних ключей и контролировать согласованность данных приходилось самостоятельно. С другой стороны, мы особо не использовали основное преимущество OLAP Clickhouse — колоночное хранение, т.к. объемы данных ожидались небольшие, а для них подойдет и OLTP с индексами.
Во-вторых, при проектировании модели данных (Error #2). Мы очень плохо понимали предметную область. Каждая таблица загружалась нами как независимая, без какой-либо нормализации и осознания, что с этими данными будут дальше делать. В данных постоянно встречалась несогласованность. Аналитики пытались справляться с этими проблемами на своем уровне, тогда как лучшая практика — приводить это в порядок на уровне хранилища.
В-третьих, при написании кода пайплайнов (Error #3). Было много самоповторов. Но это можно было отрефакторить, не пересобирая хранилище, если бы не первые 2 ошибки.
Но в этой бочке дегтя была одна ложка мёда — мы сохраняли сырые данные!
Бережно складывали их неподалёку, в файловой системе (не object storage, но хоть так).
В итоге, мы лучше погрузились в предметную область, определили взаимосвязи между таблицами, немного подкрутили модель данных, переписали код, и собрали новое хранилище на PostgreSQL.
❗️О том как не допускать элементарных ошибок, мы поговорим уже сегодня, 11 сентября, в 19:00, на бесплатном вебинаре «Проектируем хранилища данных с нуля».
➡️ Регистрация на вебинар
P.S. Кстати, вот вам вопрос: а чем, собственно, нам помогло наличие сырых данных, если можно напрямую мигрировать со старой модели на новую? И зачем вообще собирать сырьё, тратить на него место на диске?
Жду ваши ответы в комментариях)