Нам пришлось сломать стандартный подход DWH, чтобы повысить качество данных
Кажется странным, да? Вроде стандарты создаются, чтобы улучшать подходы, процессы, продукты. Но в нашем случае привычный подход просто не работал.
Мы всё время не сходились по количеству пользователей и актуальности данных между источником и DWH.
Дело в том, что нужная нам таблица отличается от всего остального. Стандарты DWH заточены на событийные данные, где каждое событие хранится в своей строке или одни типы событий агрегируются по части полей.
Но у нас одна строка должна содержать и агрегировать внутри себя множество событийных данных клиента из разных источников: регистрации, авторизации, удаления, коммуникации, установки приложений и т. д.
Стандартный подход DWH: инкремент по дате.
Наш подход: инкременты по дате каждого типа событий + общий инкремент по ID пользователей, исходя из первых инкрементов.
Так мы перестали терять апдейты, а данные выровнялись и по количеству, и по актуальности с системой-источником.
Вот так переход от очевидного и принятого решения сделал наши данные чистыми и правдивыми для всех команд компании, хотя даже сейчас этот скрипт витрины выглядит неординарно по сравнению со всем остальным репозиторием :)
Ещё больше таких историй о нестандартных решениях будет обсуждаться в зале «Ломаем шаблоны» на конференции «Продукты 24 × ffdd2d».
Из интересного мне хочется послушать доклад «Почему хорошие решения не всегда рождаются по правилам» от Максима Кирилычева.
Обязательно зарегистрируйтесь и приходите 12 сентября в Москве, в комплекс «Мечта» на набережной парка Горького.
Кажется странным, да? Вроде стандарты создаются, чтобы улучшать подходы, процессы, продукты. Но в нашем случае привычный подход просто не работал.
Мы всё время не сходились по количеству пользователей и актуальности данных между источником и DWH.
Дело в том, что нужная нам таблица отличается от всего остального. Стандарты DWH заточены на событийные данные, где каждое событие хранится в своей строке или одни типы событий агрегируются по части полей.
Но у нас одна строка должна содержать и агрегировать внутри себя множество событийных данных клиента из разных источников: регистрации, авторизации, удаления, коммуникации, установки приложений и т. д.
Стандартный подход DWH: инкремент по дате.
Наш подход: инкременты по дате каждого типа событий + общий инкремент по ID пользователей, исходя из первых инкрементов.
Так мы перестали терять апдейты, а данные выровнялись и по количеству, и по актуальности с системой-источником.
Вот так переход от очевидного и принятого решения сделал наши данные чистыми и правдивыми для всех команд компании, хотя даже сейчас этот скрипт витрины выглядит неординарно по сравнению со всем остальным репозиторием :)
Ещё больше таких историй о нестандартных решениях будет обсуждаться в зале «Ломаем шаблоны» на конференции «Продукты 24 × ffdd2d».
Из интересного мне хочется послушать доклад «Почему хорошие решения не всегда рождаются по правилам» от Максима Кирилычева.
Обязательно зарегистрируйтесь и приходите 12 сентября в Москве, в комплекс «Мечта» на набережной парка Горького.