Как работать с медленно меняющимися измерениями при использовании облачного хранилища данных?

В этом вопросе скрывается довольно много ответов, поэтому давайте сделаем паузу.

В 1996 году Ральф Кимбалл написал книгу The Data Warehouse Toolkit, которая познакомила мир с моделированием данных в стиле Кимбалла. Если вы когда-либо использовали схему «звезда» или имели дело с таблицами измерений и фактов, вы должны поблагодарить Кимбалла за его подход.

В книге The Data Warehouse Toolkit Кимбалл описывает ситуацию, когда ваши таблицы измерений медленно трансформируются с течением времени. Вот пример, который он использовал в книге: допустим, вы — розничный магазин. Вы продаете множество товаров, и каждый товар относится к определенному отделу.

Однажды педантичный сотрудник решает провести реорганизацию продуктов и передает IntelliKidz 1.0 в отдел разработки.

В конце квартала руководство запрашивает отчет о доходах от продаж, и они фильтруют этот отчет, естественно, по отделам. Именно в этот момент они вдруг обнаруживают, что цифры не совпадают с предыдущим отчетом — те же самые запросы теперь дают разные результаты, потому что продукты были перемещены по отделам!

В моделировании данных это известно как проблема «медленно меняющегося измерения», поскольку обновление измерений, вызывающее такие проблемы, происходит очень редко.

Что же делать?

Подход Кимбалла

Кимбалл предлагает три решения. 

В решении типа 1 вы поступаете точно так же, как педантичный сотрудник, описанном выше. То есть, вы обновляете колонку отдела, а затем забываете о ней. У этого подхода есть очевидные проблемы: вы больше не сможете восстановить старые отчеты, которые зависят от предыдущей категоризации продуктов. В нашем примере это легкое неудобство. Но иногда это больше, чем неудобство: например, когда речь идет о сформированных отчетах, которые должны отправляться в налоговую службу. Для такого рода документации это может быть неприемлемо.

Конечно, это решение хорошо тем, что оно простое, а значит, его легко использовать. Я думаю, что Кимбалл включил его исключительно для полноты картины.

Решение №2 более реалистично. Идея здесь заключается в том, чтобы добавить совершенно новую запись в таблицу продуктов. В этом случае вы копируете старые данные, но обновляете ключ продукта, например, так:

Все новые транзакции в таблице фактов теперь будут указывать на новый ключ продукта (25984) вместо старого (12345). Это  означает, что если вы захотите запустить отчет о доходах, старые запросы, сегментированные по отделам, вернут те же цифры.

Но давайте добавим новое требование. Допустим, вы хотите видеть данные о фактах так, как если бы изменения никогда не происходили. Это довольно часто случается, когда вы запускаете отчеты после реорганизации отдела продаж. 

Решение № 3 заключается в добавлении нового столбца в таблицу измерений для захвата предыдущего отдела. Эта настройка поддерживает возможность просмотра «альтернативной реальности» тех же данных. Настройка выглядит следующим образом:

Кимбалл предупреждает, что решение №3 используется нечасто. Но три различных ответа на эту проблему являются, по сути, тремя столпами для решения проблемы SCD.

За годы, прошедшие с тех пор, как Кимбалл написал об этих трех методах, множество других людей представили другие типы в дополнение к первоначальным трем. Как правило, являются гибридными методами. 

Как вы можете относиться к SCD... сегодня?

Мы переживаем очень интересный момент в аналитике данных. Если немного обобщить, то дата-инженеры, расширяющие границы области, начали ставить под сомнение безусловное принятия всего того, что рекомендует The Data Warehouse Toolkit.

Почему это происходит? Я подозреваю, что это происходит по двум причинам:

1. Во-первых, правильное, старое, «четырехшаговое» моделирование измерений занимает огромное количество человекочасов. Вам придется тщательно продумать проблемную область и бизнес-процесс, который вы хотите смоделировать, прежде чем создавать схему. Приверженцы Кимбалла могли бы утверждать, что все эти затраты того стоят. Современные профессионалы в области данных согласятся, что некоторое количество моделирования того стоит. Вопрос в том, насколько? Этот вопрос стал актуальным сегодня, потому что …

2. Хранение данных и вычисления наконец-то стали достаточно дешевыми. Это переворачивает с ног на голову обычный вопрос о ценности хранилища данных. В своей классической книге Кимбалл утверждал, что правильное моделирование данных даст вам огромные преимущества в производительности. И это действительно так — для систем его времени. Сегодня вычислительные мощности и хранилища дешевы, массовая параллельная обработка стала реальностью, и поэтому труд команды по работе с данными теперь обходится дороже, чем просто оплата сырой вычислительной мощности.

В итоге мы приходим к выводу, что увеличение вычислительных мощностей в аналитике — это абсолютно правильная стратегия. И, пожалуй, нигде больше мы не видим этого так ясно, как на примере SCD.

Как команды по работе с данными, находящиеся на переднем крае аналитики, справляются с SCD? В докладе 2018 года Максим Бошемин представил стратегию, которую он видел в Facebook, Airbnb и Lyft (где на момент выступления он был старшим инженером-программистом).

Если в двух словах, то идея Бошемина заключалась в том, чтобы сделать снапшот всех размерных данных.

Это означает, что команда Бошемина использует разделы таблиц для сегментации всех размерных таблиц в хранилище данных. Затем каждый день с помощью ETL-инструмента (например, Airflow, который написал Бошемин) создаются и копируются новые ежедневные разделы таблиц в качестве снапшота всех размерных данных.

Затем Бошемин предлагает три превентивных аргумента на  возражения, которые могут возникнуть против такого подхода:

1. Вычисления и хранение стоят дешево. Инженерное время стоит дорого».

2. Во-вторых, размерные данные малы и просты по сравнению с фактическими данными. Это означает, что даже пара тысяч строк, сфотографированных за десять лет назад — капля в море для современных хранилищ данных.

3. Наконец, снапшоты дают аналитикам простую визуальную модель для рассуждений, по сравнению с запросами, которые вам, возможно, придется написать для ответа в решении № 2 или № 3. Также, в качестве дополнительного эффекта, вы бесплатно получаете идеальную воспроизводимость.

Последний пункт очень важен. Бошемин представляет пример запроса следующим образом:

--- With current attribute
select * 
FROM fact a 
JOIN dimension b ON
	a.dim_id = b.dim_id AND
	date_partition = `{{ latest_partition('dimension') }}`

--- With historical attribute 
select * 
FROM fact a 
JOIN dimension b ON
	a.dim_id = b.dim_id AND
	a.date_partition = b.date_partition

Поразительно, насколько просты для понимания эти запросы. Более классический подход привел бы к гораздо более сложным запросам, и мы даже не говорим о времени, необходимом для выполнения и поддержки этих решений.

Чистый результат? Подход Бошемина делает SCD неактуальным, и вы получаете все эти преимущества, используя возможности современного хранения данных. 

Вывод

Кимбалл написал книгу The Data Warehouse Toolkit в 1996 году и обновил ее в 2002 году. Билл Инмон написал свою книгу о моделировании данных в 1992 году. Прошло почти два десятилетия с тех пор, как эти два подхода впервые появились, и нам давно пора выработать новый подход к моделированию данных. Я не знаю, как это будет выглядеть, но выступление Бошемина и его подход к SCD дают нам несколько важных подсказок.

Самая важная, на мой взгляд, следующая: ищите места, где современные технологии работы с данными могут вытеснить усилия, необходимые для моделирования. Когда вы найдете такое место, скорее всего, вы найдете главу в классическом учебнике по моделированию данных, которую можно просто вырвать.

Все, что останется в классическом учебнике, скорее всего, будет считаться best practices.