Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / OLAP и DWH Новый топик    Ответить
 SAAS для работы с (M)OLAP-кубами www.easyolap.com  [new]
KRED
Member

Откуда: München/Augsburg (Germany)
Сообщений: 595
Постепенно мой проект добрался до версии "альфа", и я хотел бы вам о нём рассказать. Буду рад вашим комментариям, советам, критике и просто пожеланиям.

Итак, идея проекта в том, чтобы результаты вычислений (по терминологии ОЛАП: меры по всем нужным комбинациям измерений) сохранить в хранилище (ОЛАП-кубе), а после этого направлять запросы к уже готовым результатам и без каких-либо вычислений быстро получать необходимый ответ.

Почему, собственно, ОЛАП?
Интересно, что в самом начале проекта я не думал ни о каком ОЛАПе. Моей главной идеей было объединить две технологии в одну и тем самым получить некий гибрид, который должен был бы иметь вычислительную мощность 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, но таковым не является.
+ детальней про язык запросов тут

Простой пример:
get meassureName1, meassureName2 from olapName;



meassureName1 и meassureName2 – имена запрашиваемых мер из ОЛАП-куба olapName. В данном примере будет найдено только одно значение для каждой меры, если таковы были рассчитаны.

Давайте рассмотрим пример с измерениями:
get meassureName from olapName dimention dimName;


В данном примере будут найдены все значения меры meassureName, которые рассчитаны для измерения dimName. Важное замечание: если для какого-то члена измерения отсутствует мера, этот член будет пропущен. Данное свойство очень похоже на обычный join двух таблиц в SQL.Естественно, можно запрашивать несколько измерений одновременно:
get meassureName from olapName dimention dimName1, dimName2;


Также можно ограничивать значения запрашиваемых измерений. При разработке я остановился на следующих способах:
  • dimName = 'value'
  • dimName start 'value1' stop 'value5'
  • dimName in ('value1', 'value5')
  • dimName like '%value%' (в планах)


Первые два способа идеально отрабатывают на физической структуре куба и позволяют естественным образом отказаться от ненужных комбинаций/данных.
Остальные способы обрабатываются программным фильтрованием, на что, соответственно, тратятся ресурсы во время запроса. Пример такого гипотетического запроса с ограничением:
get 
  mName 
from 
  olapName 
dimention 
  dimName1 = ‘value’, 
  dimName2 start ‘value1’ stop ‘value5’ ,
  dimName3 dimName in (value1, value5);


Формат данных. Существуют два формата данных получаемых в качестве ответа по протоколу http: csv и json. Тело запроса передаётся в аргументах/параметрах http протокола, а формат результата – в url адресе.
На сегодняшний день реализован только csv формат. Последовательность измерений в файле csv может не соответствовать последовательности в запросе. После измерений, выводятся значения мер. Примеры дальше по тексту.

Результаты, которых удалось достигнуть:

  • Время от запроса одной существующей ячейки из кэша 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 в Канаде?:
get TMAX_Avg from clima_daten_dim dimention country = 'Canada', time.Year;

Какая среднемесячная TMIN в Канаде?:
get TMIN_Avg from clima_daten_dim dimention country = 'Canada', time.Month;

Сколько всего замеров сделал Germany в 2000 году?:
get 'Records Counter' from clima_daten_dim dimention country = 'Germany', time.Year = '2000';


Имя куба: clima_all_daten
Меры: Precipitation_Avg, TMIN_Avg, TMAX_Avg, ‘Records Counter’
Измерения: (country, province, city)*, name, (time.Year, time.Month,time.Day)*/**
Примеры запросов:
Какие города существуют в ОЛАП-кубе?:
show members from clima_all_daten dimention city;

Какие годы существуют в ОЛАП-кубе?:
show members from clima_all_daten dimention time.Y /* это неправильно и скоро будет переделано на ‘Year’ */;

Показать TMAX i TMIN по дням в определённом городе
get TMAX_Avg,TMIN_Avg from clima_all_daten dimention time.Day, city = 'New York';


* В запросе можно использовать максимум одно измерение/проекцию из списка/группы.
** Обязательное измерение/проекция при запросе.


Для отправки запросов через API можно воспользоваться консольной утилитой:
curl -G -X GET http://gaya.easyolap.com/API/CSV?AccessToken=763211ea9f09d4495787a61aea8a71a5 --data-urlencode "query=show members from clima_all_daten dimention city "

AccessToken - токен для доступа к выше описанным кубам. Если перестанет работать, спрашивайте новый )))
query - тело запроса.


Что дальше?
Ваши комментарии, критика, советы, а также пожелания как раз и помогут мне получить ответ на этот вопрос.
6 фев 18, 01:26    [21168702]     Ответить | Цитировать Сообщить модератору
 Re: SAAS для работы с (M)OLAP-кубами www.easyolap.com  [new]
bideveloper
Member

Откуда:
Сообщений: 353
1. Как задается модель куба?
2. Какова производительность обработки по сравнению с SSAS?
3. Отличие от текущих облачных вариантов на, допустим, платформе Azure?
6 фев 18, 03:43    [21168774]     Ответить | Цитировать Сообщить модератору
 Re: SAAS для работы с (M)OLAP-кубами www.easyolap.com  [new]
kidar2
Member

Откуда:
Сообщений: 12
1. На каком языке написан проект?
2. Почему не выбрали mdx для языка запросов?
6 фев 18, 07:24    [21168824]     Ответить | Цитировать Сообщить модератору
 Re: SAAS для работы с (M)OLAP-кубами www.easyolap.com  [new]
иваннедурак
Guest
kidar2,

какая лицензия ?
чем лучше аналогов ?
6 фев 18, 09:54    [21168994]     Ответить | Цитировать Сообщить модератору
 Re: SAAS для работы с (M)OLAP-кубами www.easyolap.com  [new]
KRED
Member

Откуда: München/Augsburg (Germany)
Сообщений: 595
bideveloper
1. Как задается модель куба?

Модель исходных данных подразумевает csv/текст файл или несколько файлов с одинаковой структурой. То есть нет никаких "звёздочек" и "снежинок". (Кстати нужно обдумать эту идею, предварительные джойны можно реализовать).
В итоге требуется три функции написанных на "луа" : маппер (читает входящие строки и создаёт "факты") и две функции возвращающие список возможных измерений и мер. Скрипт состоящих их этих трёх функций я называю "адаптором". Цель такого адаптора описать все возможные измерения и меры доступные из/в этих данных.

При построении куба требуется выше описанный адаптор и конфигурация нужных/выбранных измерений и мер, а так же другие настройки: параллельность при вычислении, каким кодеком сжимать куб(gzip,lz4,plain), уровень индексации... и другие.


bideveloper
2. Какова производительность обработки по сравнению с SSAS?

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

bideveloper
3. Отличие от текущих облачных вариантов на, допустим, платформе Azure?

Не знаю что тут сказать, я не эксперт по "платформе Azure".
6 фев 18, 13:52    [21169856]     Ответить | Цитировать Сообщить модератору
 Re: SAAS для работы с (M)OLAP-кубами www.easyolap.com  [new]
KRED
Member

Откуда: München/Augsburg (Germany)
Сообщений: 595
kidar2
1. На каком языке написан проект?
2. Почему не выбрали mdx для языка запросов?

1. java
2. Совсем разные идеологии. По моей идее: всё сначала предрасчитать, а потом запрашивать. в MDX же вычисления можно делать прямо во время запроса, что как бы не совместимо.
6 фев 18, 14:01    [21169888]     Ответить | Цитировать Сообщить модератору
Все форумы / OLAP и DWH Ответить