Постепенно мой проект добрался до версии "альфа", и я хотел бы вам о нём рассказать. Буду рад вашим комментариям, советам, критике и просто пожеланиям.
Итак, идея проекта в том, чтобы результаты вычислений (по терминологии ОЛАП: меры по всем нужным комбинациям измерений) сохранить в хранилище (ОЛАП-кубе), а после этого направлять запросы к уже готовым результатам и без каких-либо вычислений быстро получать необходимый ответ.
Почему, собственно, ОЛАП?
Интересно, что в самом начале проекта я не думал ни о каком ОЛАПе. Моей главной идеей было объединить две технологии в одну и тем самым получить некий гибрид, который должен был бы иметь вычислительную мощность MapReduce и скорость ответа KeyValue хранилища Hbase. Когда я размышлял о том, что же у меня получилось (в то время внутренняя версия проекта была 2.0 и делала то, что и было запланировано ранее), мне в голову пришла идея: если изменить/дополнить один или несколько комбинаторных алгоритмов, я смогу рассчитать все комбинации между заданными измерениями, а это, в свою очередь, напомнило мне об ОЛАП. Взглянув еще раз на теорию ОЛАП и обнаружив множество параллелей с моим проектом, я решил полностью перейти на терминологию ОЛАП и сделать его ближе к этой замечательной технологии насколько это возможно.
Кратко о том, как всё работает.
Проект построен на фреймворке HADOOP и использует такие технологии как MapReduce для вычислений и Hbase в качестве хранилища. Данные для анализа представляют собой обычные текстовые/csv файлы хранящиеся в HDFS. Запросы через протокол http в отдельно написанном веб-сервисе преобразуются в запросы к ОЛАП-кубу / Hbase. Результаты обработки данных (то есть сам ОЛАП-куб) хранятся в Hbase и представляются клиенту в виде csv или json.
Текущее состояние проекта.
Я научился рассчитывать "полные" ОЛАП-кубы – такие кубы, в которых учтены все возможные комбинации. Их достоинством является наличие любого ответа в любой комбинации из настроенных/доступных измерений. Недостатками же являются их размер и требуемый объем вычислений из-за проблемы комбинаторного взрыва. Эффективного метода обновления таких ОЛАП кубов, что, соответственно, требует полного пересчёта всего куба каждый раз при обновлении исходных данных, придумать, к сожалению, не удалось.
Помимо "полных" ОЛАП кубов я также научился строить "исторические" кубы . Они отличаются тем, что алгоритм генерации комбинаций имеет ограничение, вследствие чего рассчитываются не все комбинации. Таким ограничением является обязательное присутствие измерения времени (точнее, одной из его проекций) в будущих запросах. Данное условие не только позволяет существенно сократить размер и время расчета, но и даёт возможность сравнительно легко обновлять ОЛАП-куб при появлении новых данных.
Обычная агрегация. Можно заставить куб генерировать только одну комбинацию, для того чтобы потом экспортировать эти данные в свою систему анализа. Такой куб также можно обновлять инкрементально, если есть измерение времени. О деталях спрашивайте в комментариях.
Меры. Мерой является результат вычисления над вашими данными для определённой комбинации измерений. Результат может быть представлен как простым видом данных (числом), так и сложным (массивом, объектом и т. д., смотрите типы данных "json"). На сегодня реализованы самые простые варианты: Counter, Sum, Max, Min, Avg, Std_Stat (это набор из: counter, sum, max, min), DistInct_Count, который реализован довольно просто через хешсет в памяти. Как правило, все меры обрабатывают результат с помощью "BigDecimal", но мера LCounter является реализацией Counter на основе "long", и в проведённых мной тестах она на 1% быстрее оригинала.
Мера реализована как отдельный модуль/драйвер. В ближайших планах – создание меры на основе алгоритма HyperLogLog.
Измерения. Для более четкого понимания, что такое измерения и что под ними подразумевается в проекте, я выделил два таких типа: лексикографические и математические. Рассмотрим их более детально:
К лексикографическим измерениям относятся те, которые состоят из придуманных человеком имён, например: города, страны, группы товаров, марки автомобилей, цвета радуги и т.д. На оси измерения такие имена создают точки, расположение которых соответствует их алфавитному порядку.
К математическим относятся те измерения, которые имеют следующие свойства:
на оси измерения они представляют не точки, а отрезки. Размер такого отрезка, в свою очередь, является масштабом проекции (о проекциях далее);
порядок расположения не алфавитный, а математический;
между двумя членами измерения, например “1” и “4”, можно рассчитать присутствие других членов измерения: “2” и “3” ;
разные способы представления одних и тех же величин (основное свойство проекции). Например, расстояния можно представлять не только в метрах/километрах, но и футах/милях;
у одного измерения могут присутствовать несколько проекций, отличающихся друг от друга масштабом и/или единицей измерения (кг/фунт, метр/фут и т. д.).
Единственным представителем таких измерений в моём проекте является время, остальные в разработке.
Язык запросов. По синтаксису язык очень похож на SQL, но таковым не является.
детальней про язык запросов тут
Простой пример:
1.
2.
get meassureName1, meassureName2 from olapName;
1.
2.
get meassureName from olapName dimention dimName;
1.
2.
get meassureName from olapName dimention dimName1, dimName2;
dimName = 'value'
dimName start 'value1' stop 'value5'
dimName in ('value1', 'value5')
dimName like '%value%' (в планах)
Первые два способа идеально отрабатывают на физической структуре куба и позволяют естественным образом отказаться от ненужных комбинаций/данных.
Остальные способы обрабатываются программным фильтрованием, на что, соответственно, тратятся ресурсы во время запроса. Пример такого гипотетического запроса с ограничением:
1.
2.
3.
4.
5.
6.
7.
8.
9.
get
mName
from
olapName
dimention
dimName1 = ‘value’,
dimName2 start ‘value1’ stop ‘value5’ ,
dimName3 dimName in (value1, value5);
Время от запроса одной существующей ячейки из кэша Hbase до отправки в сокет клиенту: от 4 до 20 миллисекунд. Оно в большой степени зависит от задержек сети (TCP/IP) и теоретически может быть немного улучшено, что является делом будущих настроек.
Время запроса 2000 ячеек около 30 миллисекунд.
При запросах множества ячеек, а точнее – потока данных, время равняется примерно 150 тыс. ячеек в секунду или 5 МБайт данных в секунду (теоретически, его также можно улучшить).
Вдобавок нужно сказать, что время ответа не зависит от размера самого ОЛАП-куба, т.е. скоростные показатели идентичны как для куба в несколько мегабайт, так и для куба в десятки раз больше (благодаря Hbase).
Заключение.
Невозможно описать все тонкости проекта в одном сообщении на форуме, следовательно, подведу итоги. О чем же еще мне хотелось бы рассказать:
Настройка расчёта куба на конкретных данных.
Загрузка данных.
Некоторые недостатки моей идеи (например, отсутствие real-time).
Планы развития текущего языка запросов, а также подводные камни в нём.
Работа API.
Веб-клиент.
Инкрементальное обновление.
Чего ждать дальше.
Эти и другие вопросы могут быть рассмотрены в комментариях или в дальнейших сообщениях на этом форуме.
Я благодарен вам за то, что дочитали до конца!
Все, кто заинтересовался, могут поиграть с двумя OLAP-кубами, построенными мной на основе погодных данных.
детали скрыты тут
Имя куба: clima_daten_dim
Меры: TMIN_Avg, TMAX_Avg, ‘Records Counter’
Измерения: country, province, city, name, (time.Year, time.Month)*/**
Примеры запросов:
Какая среднегодовая TMAX в Канаде?:
1.
2.
get TMAX_Avg from clima_daten_dim dimention country = 'Canada', time.Year;
1.
2.
get TMIN_Avg from clima_daten_dim dimention country = 'Canada', time.Month;
1.
2.
get 'Records Counter' from clima_daten_dim dimention country = 'Germany', time.Year = '2000';
1.
2.
show members from clima_all_daten dimention city;
1.
2.
show members from clima_all_daten dimention time.Y /* это неправильно и скоро будет переделано на ‘Year’ */;
1.
2.
get TMAX_Avg,TMIN_Avg from clima_all_daten dimention time.Day, city = 'New York';
|
