(выдержка из статьи, которая должна была появиться в журнале
Intelligent Enterprise)
Материал опубликован с разрешения компании
Автор оригинала: Ральф Кимбалл (все
статьи)
Перевод на русский язык: Константин Лисянский
Оригинальный документ располагается здесь.
Несмотря на то, что временной разрыв между производственными транзакционными
системами и хранилищами данных сократился в большинстве случаев
до 24 часов, ненасытные маркетинговые пользователи требуют, чтобы
хранилище данных наполнялось данными в режиме реального времени.
Большинство разработчиков хранилищ данных скептически относятся
к возможностям ускорения существующих ETL-процессов (extract transform
load) с 24-часового цикла до цикла в 15 минут. Разработчики хранилищ
данных отвечают на это требование созданием партиции реального времени
рядом с обычным статическим хранилищем данных.
Требования к партиции реального времени
Для достижения целей создания отчётов в режиме реального времени
мы строим отдельную партицию, которая физически и административно
отделена от обычных статических таблиц хранилища данных. Партиция
реального времени фактически является отдельной таблицей, подчиняющейся
особым правилам обновления и особым правилам построения запросов.
Партиция реального времени в идеале должна подчиняться следующим
требованиям. Она должна:
регистрировать все события, происходящие с момента последней
загрузки статического хранилища данных
насколько возможно иметь ту же степень детализации, что и таблицы
фактов хранилища
быть настолько легко проиндексированной, что входящие данные
могут постоянно заводиться в неё
поддерживать высокую производительность при выполнении запросов
В мире многомерного моделирования существует три основных типа
таблиц фактов: транзакционная таблица, периодические снимки и
аккумулирующие снимки. Наша партиция реального времени имеет различную
структуру, соответствующую каждому из этих типов.
Транзакционная партиция реального времени
Если таблица фактов статического хранилища данных объявлена на
уровне транзакций, то она содержит ровно по одной записи для каждой
отдельной транзакции в системах-источниках, начиная с самого начала
«зарегистрированной истории». Партиция реального времени имеет абсолютно
такую же структуру, что и соответствующая статическая таблица фактов.
Она содержит только транзакции, произошедшие с полуночи, когда мы
выполнили регулярную загрузку таблиц хранилища данных. Партиция
реального времени практически не должна иметь индексов, поскольку
нам нужно иметь постоянно «открытое окно» для загрузки. Мы избегаем
построения агрегатов на этой таблице, поскольку мы желаем применить
минималистский подход в отношении администрирования в течение дня.
Мы присоединяем нашу партицию реального времени к нашим существующим
приложениям посредством выполнения операции drill across из статической
таблицы фактов к партиции реального времени. Агрегации временных
рядов (например, все продажи за текущий месяц) потребуют выполнения
идентичных запросов к двум таблицам с последующим сложением результатов.
В сравнительно большой системе в области розничной торговли, где
выполняется порядка 10 миллионов транзакций в день, статическая
таблица фактов будет довольно большой. Предположив, что каждая запись
о транзакции занимает 40 байт (7 измерений плюс 3 факта, всё упаковано
в поля по 4 байта), мы будем собирать по 400 МБ данных ежедневно.
В течение года это составит около 150 ГБ сырых данных. Такая таблица
фактов будет сильно проиндексирована, и будет поддерживаться агрегированными
таблицами. Но ежедневная порция в 400 МБ (партиция реального времени)
могла бы размещаться в оперативной памяти. Забудьте про индексы,
возможно, за исключением индекса B-Tree на первичном ключе для поддержки
операций вставки! Забудьте про агрегаты!
Наша партиция реального времени может больше склоняться к обеспечению
быстрой загрузки, при этом обеспечивая высокую производительность
выполнения запросов.
Партиция реального времени периодических снимков
Если статическая таблица фактов хранилища данных имеет периодический
уровень детализации (скажем, месяц), то партиция реального времени
может выглядеть как текущий скользящий месяц. Предположим, что мы
– большой розничный банк с 15 миллионами счетов.
Статическая таблица фактов имеет степень детализации счёт/месяц.
Временной ряд из 36 месяцев будет состоять из 540 миллионов значений
таблицы фактов. И снова, эта таблица будет сильно проиндексирована
и будет поддерживаться агрегатами с тем, чтобы обеспечивать высокую
производительность. Партиция реального времени, с другой стороны,
это текущие данные текущего месяца, обновляемые ежедневно в течение
месяца. Полуаддитивные балансы и полностью аддитивные факты обновляются
с необходимой для выполнения отчётов частотой. В розничном банке
«базовая» таблица фактов, содержащая информацию обо всех счетах,
будет, скорее всего, достаточно узкой, и, возможно, будет содержать
4 измерения и 4 факта, что даёт партицию реального времени размером
в 480 МБ. И опять, партиция реального времени может быть размещена
в оперативной памяти.
Операция drill across из статической таблицы фактов к партиции
реального времени будет иметь логику, немного отличную от логики
в случае с транзакционной таблицей фактов. Несмотря на то, что тренды
по балансам и другим мерам интенсивности можно строить напрямую
на двух таблицах, аддитивные итоги, накапливаемые в течение текущего
периода, возможно, придётся спроецировать вперёд до эквивалента
всего месяца с тем, чтобы результаты не выглядели аномально.
Наконец, мы надеемся, что в последний день месяца данные из партиции
реального времени можно будет перегрузить в статическое хранилище
данных на место самого последнего месяца, и начать процесс снова
с пустой партиции реального времени.
Партиция реального времени аккумулирующих снимков
Аккумулирующие снимки используются для процессов с коротким жизненным
циклом, наподобие размещения заказов и выполнения отгрузок. Для
каждой позиции заказа или накладной создают запись. В главной таблице
фактов эта запись постоянно обновляется по мере наступления событий.
Мы создаём запись для позиции, когда заказ впервые размещается,
затем мы обновляем её, когда товар отгружается, в момент произведения
оплаты, или в момент возврата. Таблицы фактов аккумулирующих снимков
содержат внешние ключи, представляющие даты наступления каждого
из этих событий.
В данном случае называть главную таблицу хранилища данных «статической»
будет неправильным, поскольку это единственный вид таблиц фактов,
которые постоянно, зачастую многократно, обновляются. Но, давайте
предположим, что с целью повышения производительности запросов эти
обновления происходят только в то время, когда пользователи не подключены
к системе. В этом случае партиция реального времени будет состоять
только из строк для тех позиций, которые обновлялись сегодня. В
конце дня записи в партиции реального времени будут являться в точности
новыми версиями записей, которые нужно будет записать в главную
таблицу фактов посредством вставки новых записей или заменой существующих
записей с теми же первичными ключами.
Во многих ситуациях с заказами и поставками количество строк в
партиции реального времени будет значительно меньше, чем в двух
предыдущих примерах. Например, крупнейший в США производитель корма
для собак и кошек обрабатывает около 60 000 счетов в месяц. Каждый
счёт может иметь до 20 позиций. Если позиция счёта имеет нормальную
продолжительность жизни в два месяца и обновляется в течение этого
интервала пять раз, то мы увидим около 7500 позиций, создаваемых
и обновляемых в течение среднего рабочего дня. Даже в случае достаточно
широкой записи размером в 80 байт, типичной для таблиц фактов счетов,
наша партиция реального времени будет содержать всего 600 КБ данных.
Этот объём, очевидно, поместится в оперативную память. Забудьте
об индексах и агрегатах для этой партиции реального времени.
Запросы к аккумулирующим снимкам с партицией реального времени
должны выбирать соответствующие строки, как из главной таблицы фактов,
так и из партиции, и могут либо выполнять операцию drill across
между двумя таблицами посредством короткого внешнего соединения
по идентичным заголовкам строк, либо выполнять объединение строк
из двух таблиц, представляя статическую картину, обогащённую дополнительными
строками, представляющими важные сегодняшние события.
В этой статье я описал то, что я считаю сильным бизнес-сценарием
для удовлетворения новых требований к анализу в реальном времени
посредством специально разработанных, но, тем не менее, уже знакомых,
расширений наших существующих таблиц фактов. Если вы удалите почти
все индексы и агрегаты у этих таблиц, и разместите их в оперативной
памяти, вы должны получить высокую производительность обновления
и ответов на запросы, которая вам требуется.
Если вы нашли в сети интересные ссылки на ресурсы по технологиям
хранилищ данных, OLAP, CRM или data mining, и хотите поделиться
ими с другими, присылайте их.
Я с удовольствием размещу их на этом сайте.
RSS