Масштабируемость OLAP-данных

Третья статья рубрики посвящена проблеме разрастания данных в многомерных
базах. Автор подробно рассматривает возникновение этого явления и его
последствия для пользователей OLAP-продуктов.

Факт взрывного роста данных в многомерных базах, как это ни странно, часто недооценивают. А ведь для покупателей и пользователей OLAP-продукта принципиально важно понимать, что такое разрастание данных, что его вызывает и как его можно избежать, ибо последствия этого явления могут обойтись очень дорого и в большинстве случаев приводят к краху проекта.

За редким исключением, OLAP-поставщики не могут по-настоящему утверждать, что они преодолели последствия взрывного роста. А по их заявлениям на эту тему разобраться в том, что же здесь действительно важно, а что нет — практически невозможно.

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

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

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

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

Последствия пренебрежительного отношения к взрывному росту данных

Назовем некоторые из таких последствий.

• Возникновение массивных баз, которые буквально в сотни и даже тысячи раз больше, чем это необходимо.
• Для обработки и хранения разросшихся данных требуется дорогое оборудование. Время загрузки или расчетов составляет часы, а не секунды или минуты.
• Большие расходы на построение и поддержку таких монолитных моделей.
• Скрытые потери, связанные с невозможностью обеспечить своевременную и существенную аналитическую поддержку.
• Невозможность принятия быстрых бизнес-решений и предвзятое отношение к таким продуктам, которое преобладает по причине использования неудачных аналитических схем, — всё это несет за собой большие расходы.
• Провал проекта (по крайней мере de facto).

Разреженность (противоположность плотности)

Прежде чем переходить к рассмотрению проблемы взрывного роста данных, необходимо разобраться с двумя довольно важными понятиями, как-то: «разреженность» и «обработка разреженности».

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

Например, если в одномерной матрице можно удалить все пустые значения и таким образом добиться 100%-ой плотности, то в двумерной матрице, если в одном из двух измерений есть элемент с непустым значением, удалить пустые значения уже нельзя (см. рис. 1 и рис. 2).

Рис. 2. Плотность 25% (4 из 16 точек данных заполнены)

Хотя это не всегда соответствует действительности, но если число измерений в модели растет, то, как правило, растет и разреженность данных. Например, если информация о продажах ограничивается только двумя позициями — месяцем и типом продукта, то вполне вероятно, что каждый продукт найдет себе сбыт в течение каждого месяца, и, таким образом, плотность матрицы по-прежнему останется равной 100%. Однако если эту информацию дополнить еще и данными по клиентам и регионам, то очевидно, что продавать каждый продукт каждому клиенту в каждом регионе, да еще и ежемесячно, конечно же, не удастся. Если ввести в эту модель еще одно измерение (например «пол»), то возможный размер куба за счет хранения данных по двум дополнительным переменным удвоится , а объем хранимых данных останется, тем не менее, прежним. В данном случае ввод дополнительного измерения приводит к удвоению разреженности.

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

Также исследовались модели, имеющие отраслевую специфику, как-то: анализ страховых исков, анализ звонков и доходов по клиентам телекоммуникационной компании, анализ продаж медицинского оборудования и т. п. Подробные итоги исследования приведены в приложении.

Итоги исследования

Плотность данных во всех случаях была много меньше процента, что говорит о высокой степени разреженности. Причем рост количества измерений её только увеличивал (в рассмотренных моделях количество измерений колебалось от 5 до 16).

Особенно высокая разреженность характерна для всех отраслевых моделей (плотность не достигала и миллиардной доли процента).

Обработка разреженности

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

Плохая обработка разреженности и взрывной рост данных

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

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

Взрывной рост данных: причины, факты

Взрывной рост данных — явление, возникающее в многомерных моделях, где производные или расчетные значения существенно превышают исходные. Вероятность разрастания повышают три основных фактора:

1. Разрозненность исходных данных.
2. Большое количество измерений в модели.
3. Большое количество уровней для каждого измерения.

Чтобы лучше понять смысл этих факторов, рассмотрим уже упомянутый нами пример. На рисунке 3 одномерная модель со 100%-ой плотностью и двумя уровнями содержит базовые данные, в четыре раза превышающие расчетные данные (4:1). Взрывного роста данных нет. На рисунке 4 двумерная модель с 25% плотностью и тремя уровнями для каждого измерения содержит четыре базовых показателя, которые «разрастаются» до 15 вычисленных.

Рис. 3. Взрывного роста данных нет

Рис. 4. Взрывной рост данных в 3,75 раз

Таким образом, уровень взрывного роста данных в измерениях увеличится за счет увеличения разрозненности и/или добавления измерений и/или добавления дополнительных вычисленных уровней.

Картина взрывного роста данных на практике

На практике обычно используют от 5 до 12 измерений, применяя, как правило, разрозненные модели. Чаще всего плотность не превышает одного процента, и её можно такой и принять, за исключением тех случаев, когда доказано, что она имеет иное значение. Обычно измерению «продукт», соответствует от 4 до 9 уровней, а измерению «счет» — от 8 до 16 уровней. Для других измерений типичных моделей количество уровней чаще всего колеблется в диапазоне от 2 до 6.

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

1. Плотность данных во всех случаях была существенно ниже одного процента, а во всех отраслевых моделях наблюдались исключения.
2. Среднее количество уровней для каждой модели колебалось от 3 до 6.
3. Максимальное количество уровней для всех измерений в каждой модели колебалось от 6 до 16.
4. Для отраслевых моделей характерно количество измерений от 10 до 16.
5. Базовые модели расчета прибылей и убытков содержали от 12 до 40 миллионов исходных элементов данных, а отраслевые модели — от 80 до 366 миллионов.
6. Для базовых моделей расчета прибылей и убытков коэффициент разрастания попал в диапазон от 30 до 500, что приводило к увеличению количества элементов до 600—21 000 миллионов.
7. Для отраслевых моделей расчетные данные разрастались в 4000—66000 раз больше, чем базовые, что привело к увеличению количества элементов до 356—23972 миллиардов.
8. После взрывного роста данных для отраслевых моделей требовалось для хранения от 2 до 150 Тб, тогда как для моделей без взрывного роста достаточно 1—5 Мб.
9. Для загрузки и полного расчета увеличивающихся данных в отраслевых моделях требовалось от 11 часов до 242 дней. Для сравнения в моделях без взрывного роста требовалось от 1 до 27 минут.

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

Очевидно, что среди моделей, где выполняется предварительная подготовка расчетных данных, есть такие, которые нельзя рассматривать. Например, загрузка или расчет в течение 242 дней (или даже 6,5 дней) совершенно недопустимы. Как видно из исследования, такие модели (это может быть анализ продаж, клиентов или продуктов) все без исключения отраслевые, представляющие собой реальные корпоративные модели с большими наборами данных.

Более того, для множества OLAP-приложений модель, которая подразумевает пересчет в течение нескольких часов или даже десяти минут, совершенно не подходит.

Опасность обманчивых сравнений и объяснений поставщиков.

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

1. Попытки скрыть недостатки роста данных, придавая ему окраску преимуществ:

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

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

• использование малого количества измерений;
• использование неразрозненных данных;
• использование малого количества вычисляемых уровней в измерении;
• использование маленьких наборов данных.

Заключение

1. Необходимо остерегаться обманчивых и пустых маркетинговых заявлений и лозунгов.
2. Нужно постараться по-настоящему понять феномен взрывного роста данных и его влияние на базу.
3. Важно не путать обработку разрозненности и взрывной рост данных.
4. Требуется изучить сравнительные оценки поставщиков и демонстрации возможности и убедиться, что эти фирмы не пытаются скрыть какие-либо из четырех основных причин взрывного роста данных. Для этого удобно использовать следующий контрольный список:
   • в модели должно быть не менее шести измерений;
   • плотность исходных данных не должна превышать одного процента;
   • важно, чтобы в модели было не менее трех рассчитываемых уровней по всем измерениям, а также пять и более уровней для двух самых крупных изменений. По крайней мере в одном из измерений должно быть не менее тысячи элементов, а в одном из остальных не менее ста;
   • в модели должно быть по меньшей мере десять миллионов элементов данных. Нужно удостовериться, что это действительно объем базовых данных, а не полное количество рассчитанных элементов. Если базовых данных около десяти тысяч, то при выполнении вычислений может легко образоваться около десяти миллионов элементов. То есть разница в размерах станет тысячекратной.
5. От поставщика нужно потребовать достоверного доказательства концепции или сравнительных тестов с другими производителями. Любой отказ надо рассматривать как намек на слабость поставщика в этой области.
6. Важно ознакомиться с отзывами и задавать подробные вопросы. Например, если рецензент не знает, можно ли провести расчет обновленных или измененных данных в течение секунд, то не исключено, что перерасчет кубов всю ночь напролет для него тоже вполне разумен. Бывает, что на вопрос о производительности прозвучит ответ: «Производительность хорошая», причем без цели обмануть заказчика. Однако если спросить: «А сколько времени потребуется для расчета и консолидации данных после обновления?», то ответ: «Девять часов», — скажет уже о многом.
7. Так как различных OLAP-архитектур много (ROLAP, MOLAP, DOLAP и т. д.), то любая архитектура, использующая подход с частичным или полным предварительным пересчетом, подвержена всем последствиям взрывного роста данных.

Приложение

В первой таблице содержатся фактические данные и показатели на примере семи компаний, использовавших ПО без частичного или полного предварительного вычисления, где взрывного роста данных не наблюдалось. Во второй таблице содержатся показатели, рассчитанные для иллюстрации взрывного роста данных при использовании такого ПО, где используется подход на основе предварительных расчетов. Как следует из этой таблицы, первые три модели не годны, так как размеры баз данных превышают 2,2 Тб, а время загрузки 11 часов.

Определения и допущения:

1. Память, использованная для базовых данных. Обнаружилось, что в 1 Мб оперативной памяти OLAP-продукта хранится около 80 тыс. элементов данных. Это значение было получено путем деления количества элементов в базе данных на 80 000.
2. Количество элементов данных в базе. Для вычисления эго параметра были подсчитаны все (или большая часть) исходных данных в каждой модели, затем экстраполированы для получения полной, но разумно заполненной модели. Например, если расчет был проведен по данным за полгода, то полученное значение удваивалось, чтобы отразить картину за год. Однако такой подход не использовался для оценки таких измерений, как клиент, продукт и т.п., так как он не отразил бы возможный набор данных в моделях.
3. Время загрузки исходных данных (в минутах). В OLAP-базу удавалось последовательно загрузить 500 тыс. элементов данных в минуту. Поэтому указанный параметр был получен путем деления общего количества элементов на 500 000.
4. Время загрузки дополнительных данных, специфичных для модели (в минутах). Для каждой модели существуют свои дополнительные данные. Например, если модель изменяется ежемесячно и хранит данные за год, то время такой загрузки составит 1/12 часть времени загрузки базовых данных. Если в модели хранятся данные за 12 месяцев и за 2 года, то время дополнительной загрузки составит 1/24 от времени загрузки исходных данных.
5. Суммарное количество возможных точек данных. Для получения этого параметра было перемножено полное количество элементов в каждом измерении.
6. Разреженность. Число исходных элементов данных, деленное на полное возможное количество элементов в данной базе.
7. Составной Коэффициент роста (Compound Growth Factor, CGF). CGF — термин, введенный в OLAP Report, используется для расчета взрывного роста данных и представляет собой фактор роста данных в расчете на одно измерение. В OLAP Report утверждается, что для приложений с умеренной разреженностью и полукластеризованными данными этот параметр можно принять равным  2. Поэтому в данном исследовании во всех расчетах использовался CGF, равный 2, хотя в OLAP Report предлагается использовать значение 2,5 или даже 3, если модель очень разрежена и в ней шесть и более измерений.
8. Объем разросшихся данных. Количество исходных данных в базе, помноженное на CGF и возведенное в степень, равную количеству измерений в модели.
9. Во сколько раз разросшиеся данные по объему превышают исходные. Объем разросшихся данных, деленный на количество исходных.
10. Память, необходимая для разросшихся данных. Количество элементов данных, хранящихся в одном мегабайте памяти, было взято из белых бумаг, описывающих проекты, где хранятся предварительно вычисленные или частично вычисленные данные. Во всех расчетах использовался максимальный параметр, составивший 160 000 элементов в мегабайте. Так как по размеру это в два раза больше, чем для неразросшихся данных, то можно утверждать, что доказательства против взрывного роста данных не преувеличены. Поэтому данный параметр рассчитывался путем деления количества разросшихся данных на 160 000.
11. Время на загрузку и предварительные вычисления: Время загрузки и вычислений были собраны из опубликованных белых бумаг, описывающих операции загрузки и вычисления. По данным таких исследований в минуту обрабатывается в среднем 508 800 записей. Эта цифра очень близка к 500 000 элементам в минуту для неразросшейся базы, поэтому такой показатель авторы сочли разумным. Для расчета параметра количество разросшихся элементов базы делилось на 508 800.
12. Время дополнительной загрузки и вычислений, характерное для выбранной модели. Для каждой модели характерно введение своих дополнительных данных. Например, если модель изменяется ежемесячно и в ней хранятся данные за год, то время дополнительной загрузки составит одну двенадцатую от времени загрузки основных данных. Если в модели содержатся данные за 12 месяцев и два года, то время дополнительное время загрузки составит 1/24 от загрузки основных данных.
13. Время на загрузку и вычисления (16 процессоров и 5 разделов). Время на загрузку и вычисления были выбраны из публикаций по загрузке и вычислению данных. Пять параллельных процессов, состоящих из 16 центральных процессоров, обрабатывают 2 544 000 записей в минуту. Поэтому данный параметр рассчитывался путем делений объема разросшихся данных на 2 544 000.
14. Время дополнительной загрузки и вычислений, характерное для выбранной модели. Для каждой модели характерно введение своих дополнительных данных. Например, если модель изменяется ежемесячно и в ней хранятся данные за год, то время дополнительной загрузки составит одну двенадцатую от времени загрузки основных данных. Если в модели содержатся данные за 12 месяцев и два года, то время дополнительное время загрузки составит 1/24 от загрузки основных данных.

Автор: Йохан Потгитер (Johann Potgieter)