Часто коллеги и братья по цеху сталкиваются с подобными задачами и советуются как лучше их решить.
В этой статье я хочу поделиться опытом как решались различные ситуации подобного типа.
Избыточная сложность хранилищ данных и связанных с ними информационных систем затрудняет проведение доработок, необходимых для интеграции систем или для удовлетворения новых требований, задерживает регулярную обработку данных, способствует появлению ошибок и мешает поиску их причин.
Проявления избыточной сложности в хранилищах данных можно перечислять долго. Это таблицы с сотнями полей, SQL-скрипты на тысячи строк, отдельные SQL-скрипты одинакового назначения для разных типов данных, отсутствие необходимой нормализации данных, отсутствие первичных ключей и ограничений целостности, отсутствие необходимых полей начала или окончания срока действия записи, наличие многочисленных и сложных «костылей», перекодировка или реклассификация данных, изменение типа или формата данных, замена идентификаторов, разнобой в наименованиях, излишнее количество слоев информационной системы, «протягивание» полей окольными путями, упаковка и распаковка составных полей, расчет лишних полей и использование лишних связей и условий, дублирование информации в записях и лишняя фильтрация записей, наследование таблиц, отсутствие единых правил заполнения данных.
Основной причиной избыточной сложности является денормализация в витринах данных. Популярное утверждение «денормализируйте, если необходимо повысить производительность» игнорирует проблему избыточной сложности, и поэтому во многих случаях неверно. Впрочем, источник цитаты это признает: «денормализованная база данных под большой нагрузкой может работать медленнее, чем её нормализованный аналог». Нетребовательность к структуре и качеству данных со временем неизбежно приводит к усложнению структуры данных и алгоритмов, ошибкам, замедлению работы информационных систем и раздуванию IT-подразделений.
Но можно значительно упростить доработки и поддержку хранилища данных, если придерживаться описанных далее правил.
Привет! Меня зовут Антон Поляков, и я разрабатываю аналитическое хранилище данных и ELT-процессы в ManyChat.
Несколько лет назад мы выбрали Snowflake как сервис для нашей дата-платформы. С ростом объемов данных до сотен миллионов строк (спойлер: а затем и до десятков миллиардов), мы задались вопросом: «Как тратить меньше времени на расчет запросов для ежедневной отчетности?». Идеальным вариантом было использование материализованных представлений, позволяющих обращаться к предварительно вычисленным результатам расчета витрин гораздо быстрее, чем к исходным данным.
Мы могли отдать управление нашим пайплайном таким популярным сегодня инструментам для трансформации данных, как, например, dbt, Matillion или Dataform. Однако, в начале 2020 года ни у одного из них не было возможности тонкой кастомизации под нужды Snowflake и ManyChat. К тому же, нам не хотелось платить за еще один сторонний инструмент. Так, мы приняли решение изобрести собственный велосипед для работы с материализацией данных. Именно об этом я сегодня и расскажу.