logo.png
8.7 KB
Идеальная система для игры с данными
Легко сказать «создай новую технологию» - после 9 лет создания предыдущей! Главный вопрос был - зачем это пользователям?
«Пользователям нужны дашборды» - говорили мне, «а не гибкость расчетов и аналитика на лету». Я бесился от этой фразы и думал, что у любого человека, увидевшего дашборд, возникнут вопросы типа: «А почему тут спад, а по каким именно клиентам, а кто лучший, а где нам ждать следующей проблемы?» А меня в ответ убеждали, что таких пользователей-исследователей единицы, а потребителей информации - тысячи, причем чаще всего среди них и высшее руководство.
И это была первая и самая главная проблема при обдумывании Rapeed - точно не хотелось становиться еще одной системой дашбордов, но саму подачу информации панелями виджетов нужно было оставить как «входную дверь» для пропуска системы к пользователям и данным.
Вторая проблема, про которую говорили и говорят на всех проектах внедрения - объединение данных разных источников. Это настолько большая тема, что я буду про нее отдельно говорить. Но каждый человек, работающий с данными, это пытается делать, и решить эту проблему - это достойная задача!
Наконец, нужно окончательно уйти от этого постоянно настигающего ограничения на объем данных. Тут только один путь - делать обработку распределенной, не на одной машине, а на многих.
А дальше четвертое-пятое-двадцатое: мне не нравится ни один из существующих построителей формул, не нравится обрезанная функциональность графиков, фильтров, не нравится, что виджеты надо программировать.
И самое главное: в чем фишка? А фишка должна быть в поразительном удобстве и легкости работы с любыми источниками данных без какого-либо кода.
Всё это роилось в моей голове, когда я полгода размышлял о концепции системы. Но сначала, как и раньше, я придумал название - Рапид, стремительный. Легкость и игру с данными показывает его логотип. Обратите внимание на капельки - спасибо нашему главному дизайнеру Паше.
(Дальше расскажу о распределенной обработке данных и почему её никто не смог сделать)
#удовольствие_от_аналитики #история_rapeed
Легко сказать «создай новую технологию» - после 9 лет создания предыдущей! Главный вопрос был - зачем это пользователям?
«Пользователям нужны дашборды» - говорили мне, «а не гибкость расчетов и аналитика на лету». Я бесился от этой фразы и думал, что у любого человека, увидевшего дашборд, возникнут вопросы типа: «А почему тут спад, а по каким именно клиентам, а кто лучший, а где нам ждать следующей проблемы?» А меня в ответ убеждали, что таких пользователей-исследователей единицы, а потребителей информации - тысячи, причем чаще всего среди них и высшее руководство.
И это была первая и самая главная проблема при обдумывании Rapeed - точно не хотелось становиться еще одной системой дашбордов, но саму подачу информации панелями виджетов нужно было оставить как «входную дверь» для пропуска системы к пользователям и данным.
Вторая проблема, про которую говорили и говорят на всех проектах внедрения - объединение данных разных источников. Это настолько большая тема, что я буду про нее отдельно говорить. Но каждый человек, работающий с данными, это пытается делать, и решить эту проблему - это достойная задача!
Наконец, нужно окончательно уйти от этого постоянно настигающего ограничения на объем данных. Тут только один путь - делать обработку распределенной, не на одной машине, а на многих.
А дальше четвертое-пятое-двадцатое: мне не нравится ни один из существующих построителей формул, не нравится обрезанная функциональность графиков, фильтров, не нравится, что виджеты надо программировать.
И самое главное: в чем фишка? А фишка должна быть в поразительном удобстве и легкости работы с любыми источниками данных без какого-либо кода.
Всё это роилось в моей голове, когда я полгода размышлял о концепции системы. Но сначала, как и раньше, я придумал название - Рапид, стремительный. Легкость и игру с данными показывает его логотип. Обратите внимание на капельки - спасибо нашему главному дизайнеру Паше.
(Дальше расскажу о распределенной обработке данных и почему её никто не смог сделать)
#удовольствие_от_аналитики #история_rapeed
👍8🔥6👏1👌1
DOLAP
Когда данные хранятся в одном массиве памяти (или одном массиве на диске, который имеет образ в памяти), мы можем легко посчитать, сколько у нас, например, уникальных клиентов, чеков или товаров. Или, например, столь любимый в рознице средний чек по магазинам в динамике. Проблем никаких: массив памяти объявлен, границы известны, хоть вдоль его считай, хоть поперек, причем одни потоки процессора могут вдоль, а другие в это время - поперек. Это если памяти хватило. И только после того, как вычисление в принципе состоялось, скорость вычислений выходит на первый план.
Но, как мы знаем, одного массива памяти нам не хватает. Даже так: любое фиксированное количество массивов памяти является ограничением. Выход именно в неограниченном количестве массивов оперативной памяти, увеличивающихся на лету при росте объема данных. При этом даже содержимое одного поля может не помещаться в память одной машины и должно обрабатываться (сортироваться, агрегироваться..) на многих машинах.
Это и есть постановка задачи для аналитического хранилища Rapeed.
Поскольку на выходе мы должны получать не статичную, а динамическую таблицу с несколькими уровнями, то это уже знакомый нам OLAP, или куб. Стало быть, на самом нижнем уровне тоже должны быть такие же OLAP-кубы, только агрегирующие свои кусочки порознь. Получается структура распределенного OLAP-куба, или DOLAP (distributed OLAP).
Ну хорошо, подумал я в 2020 году, DOLAP так DOLAP. И меня не смутило то, что почему-то нет ни одного готового решения на DOLAP - всё считается на распределенных базах данных (яркий пример - ClickHouse), а хранится в распределенных файловых хранилищах (S3, Hadoop и пр.), где есть часть «горячих» данных, но большинство данных «холодные», которые надо сначала достать, ночью «разогреть» и только потом что-то посчитать.
Если не вдаваться в тонкости, то DOLAP до Рапида не было потому, что заранее даже неизвестно количество значений поля. Не количество уникальных значений (это важная расчетная задача), а просто значений - сколько у нас, например, ФИО. Или точек переходов на сайте. Мы этого не знаем!! Любому OLAP-кубу нужно знать, какого он размера по всем осям, чтобы не потерять целостность. Любому, кроме нашего - DOLAP в Rapeed делает расчеты, пока данные не закончатся.
(Продолжение следует)
#удовольствие_от_аналитики #история_rapeed #dolap
Когда данные хранятся в одном массиве памяти (или одном массиве на диске, который имеет образ в памяти), мы можем легко посчитать, сколько у нас, например, уникальных клиентов, чеков или товаров. Или, например, столь любимый в рознице средний чек по магазинам в динамике. Проблем никаких: массив памяти объявлен, границы известны, хоть вдоль его считай, хоть поперек, причем одни потоки процессора могут вдоль, а другие в это время - поперек. Это если памяти хватило. И только после того, как вычисление в принципе состоялось, скорость вычислений выходит на первый план.
Но, как мы знаем, одного массива памяти нам не хватает. Даже так: любое фиксированное количество массивов памяти является ограничением. Выход именно в неограниченном количестве массивов оперативной памяти, увеличивающихся на лету при росте объема данных. При этом даже содержимое одного поля может не помещаться в память одной машины и должно обрабатываться (сортироваться, агрегироваться..) на многих машинах.
Это и есть постановка задачи для аналитического хранилища Rapeed.
Поскольку на выходе мы должны получать не статичную, а динамическую таблицу с несколькими уровнями, то это уже знакомый нам OLAP, или куб. Стало быть, на самом нижнем уровне тоже должны быть такие же OLAP-кубы, только агрегирующие свои кусочки порознь. Получается структура распределенного OLAP-куба, или DOLAP (distributed OLAP).
Ну хорошо, подумал я в 2020 году, DOLAP так DOLAP. И меня не смутило то, что почему-то нет ни одного готового решения на DOLAP - всё считается на распределенных базах данных (яркий пример - ClickHouse), а хранится в распределенных файловых хранилищах (S3, Hadoop и пр.), где есть часть «горячих» данных, но большинство данных «холодные», которые надо сначала достать, ночью «разогреть» и только потом что-то посчитать.
Если не вдаваться в тонкости, то DOLAP до Рапида не было потому, что заранее даже неизвестно количество значений поля. Не количество уникальных значений (это важная расчетная задача), а просто значений - сколько у нас, например, ФИО. Или точек переходов на сайте. Мы этого не знаем!! Любому OLAP-кубу нужно знать, какого он размера по всем осям, чтобы не потерять целостность. Любому, кроме нашего - DOLAP в Rapeed делает расчеты, пока данные не закончатся.
(Продолжение следует)
#удовольствие_от_аналитики #история_rapeed #dolap
👍10🔥4👏1
DOLAP vs OLAP
После 4 лет разработки DOLAP интересно посмотреть, что у нас получилось по сравнению с OLAP in-memory.
Первое, что я сделал - крайне упростил структуру работы с данными. Нет больше заранее объявленных размерностей и фактов (мер) - есть просто поля и любые формулы на их основе. Какая мне разница, как пользователю, что кто-то решил это назвать размерностью и по ней нельзя посчитать сумму?? И зачем мне думать, в каких разрезах считать факт (меру)?? Я просто оперирую любым набором полей из любых источников, и любое поле может быть хоть чем в системе в зависимости от ситуации.
Отмена размерностей и фактов сама по себе привела к серьезной экономии ресурсов. Но радикальным (я бы сказал, убийственным) преимуществом стало само распараллеливание вычислений и его следствия.
Если движок OLAP in-memory сортирует миллион клиентов по миллиарду строк чеков от большего клиента к меньшему по количеству чеков, он использует около терабайта памяти - надо хранить и сами данные и вспомогательные структуры для агрегаций и сортировки.
Для расчетов этому движку потребуется от 40 до 80 секунд в зависимости от процессора.
Наш DOLAP решает ту же задачу, используя 62 Гбайт памяти на всех машинах - в 16 раз меньше. Считает он меньше 5 секунд - в 8-16 раз быстрее. И чем больше объем данных, чем больше разница.
При этом увеличение данных в 2 раза, до 2 млрд записей, приведет к краху OLAP-движка, потому что потребуется больше 2,5 Тбайт памяти (её столько не может быть установлено на обычных серверах). Но даже если и было бы, то OLAP считал бы от 180 до 300 секунд, потому что время расчета у него растет нелинейно.
В DOLAP у Rapeed увеличение данных в 2 раза приводит к возрастанию потребления памяти всего на 20% (напомню, это распределенная память, то есть её предела нет), а время расчета увеличивается незначительно, в пределах 10% - ведь базовые кусочки DOLAP (шарды) отрабатывают моментально, просто их стало больше.
В чем подвох, спросите вы?
Распределенное хранение иногда требует перемещения данных между шардами или нодами. В первый раз, когда запускается какой-нибудь хитрый расчет, я могу ждать 10 секунд, иногда больше, если данные лежат не так, как надо для расчета. Но - жду я только в первый раз, и недолго. Согласитесь, это можно простить из-за огромных плюсов технологии DOLAP по сравнению с обычным движком OLAP in memory.
#удовольствие_от_аналитики #dolap
После 4 лет разработки DOLAP интересно посмотреть, что у нас получилось по сравнению с OLAP in-memory.
Первое, что я сделал - крайне упростил структуру работы с данными. Нет больше заранее объявленных размерностей и фактов (мер) - есть просто поля и любые формулы на их основе. Какая мне разница, как пользователю, что кто-то решил это назвать размерностью и по ней нельзя посчитать сумму?? И зачем мне думать, в каких разрезах считать факт (меру)?? Я просто оперирую любым набором полей из любых источников, и любое поле может быть хоть чем в системе в зависимости от ситуации.
Отмена размерностей и фактов сама по себе привела к серьезной экономии ресурсов. Но радикальным (я бы сказал, убийственным) преимуществом стало само распараллеливание вычислений и его следствия.
Если движок OLAP in-memory сортирует миллион клиентов по миллиарду строк чеков от большего клиента к меньшему по количеству чеков, он использует около терабайта памяти - надо хранить и сами данные и вспомогательные структуры для агрегаций и сортировки.
Для расчетов этому движку потребуется от 40 до 80 секунд в зависимости от процессора.
Наш DOLAP решает ту же задачу, используя 62 Гбайт памяти на всех машинах - в 16 раз меньше. Считает он меньше 5 секунд - в 8-16 раз быстрее. И чем больше объем данных, чем больше разница.
При этом увеличение данных в 2 раза, до 2 млрд записей, приведет к краху OLAP-движка, потому что потребуется больше 2,5 Тбайт памяти (её столько не может быть установлено на обычных серверах). Но даже если и было бы, то OLAP считал бы от 180 до 300 секунд, потому что время расчета у него растет нелинейно.
В DOLAP у Rapeed увеличение данных в 2 раза приводит к возрастанию потребления памяти всего на 20% (напомню, это распределенная память, то есть её предела нет), а время расчета увеличивается незначительно, в пределах 10% - ведь базовые кусочки DOLAP (шарды) отрабатывают моментально, просто их стало больше.
В чем подвох, спросите вы?
Распределенное хранение иногда требует перемещения данных между шардами или нодами. В первый раз, когда запускается какой-нибудь хитрый расчет, я могу ждать 10 секунд, иногда больше, если данные лежат не так, как надо для расчета. Но - жду я только в первый раз, и недолго. Согласитесь, это можно простить из-за огромных плюсов технологии DOLAP по сравнению с обычным движком OLAP in memory.
#удовольствие_от_аналитики #dolap
👍17🔥1👏1
Связи и Data Discovery
Как я писал раньше, Rapeed - это далеко не только BI-система. В ней исследуют данные и связи между ними без кодирования, что называется Data Discovery.
Многие говорят, что у них системы класса Data Discovery, но при этом 99,9% из них лукавит, подменяя понятия. Главный недостаток всех этих систем - одно поле нельзя использовать повторно в одном виджете или в таблице. В продвинутых инструментах можно делать копии полей, или размерностей, но по сути это одно поле - оно может быть либо строкой, либо фильтром. Поэтому, когда нужно показать связи между данными, все продукты поголовно предлагают только графовые представления (пример - ниже после текста).
Их проблема очевидна - на экран поместится максимум 20 объектов, чтобы что-то можно было разобрать. В примере всего 9 человек и маленький график и уже мало что понятно. Попробуйте последить за движениями собственных глаз, когда будете смотреть на этот пример.
А если объектов - тысячи? Количество сотрудников вполне может исчисляться десятками тысяч, магазинов - тысячами, товаров - миллионами. Никакой граф уже ничего не покажет и обработать такое количество связей будет не в состоянии.
Визуальное исследование данных (Data Discovery) должно решать, например, следующую задачу: 1) я вижу своего целевого клиента, который платит такой-то картой с определенной частотой, покупает при этом в определенное время определенные товары или группы товаров, делает при этом транзакции определенного типа и живет в конкретном районе; 2) я хочу увидеть похожих на него людей, но не его самого. Причем всё это визуально, быстро и без кодирования на Питоне (Python).
Сама формулировка подразумевает, что поле «Клиент» должно присутствовать в зоне исследования минимум дважды и без ограничений - мы же заранее не знаем, кто окажется похож на целевые объекты. И остальные поля, значит, тоже.
И как это всё отобразить, сделать понятным, функциональным и гибким?
В результате долгих размышлений и многочисленных попыток реализации родился супервиджет, который называется «Область связей». А мы внутри Rapeed его называем «кхор». Почему? Об этом в следующем посте.
#удовольствие_от_аналитики #data_discovery
Как я писал раньше, Rapeed - это далеко не только BI-система. В ней исследуют данные и связи между ними без кодирования, что называется Data Discovery.
Многие говорят, что у них системы класса Data Discovery, но при этом 99,9% из них лукавит, подменяя понятия. Главный недостаток всех этих систем - одно поле нельзя использовать повторно в одном виджете или в таблице. В продвинутых инструментах можно делать копии полей, или размерностей, но по сути это одно поле - оно может быть либо строкой, либо фильтром. Поэтому, когда нужно показать связи между данными, все продукты поголовно предлагают только графовые представления (пример - ниже после текста).
Их проблема очевидна - на экран поместится максимум 20 объектов, чтобы что-то можно было разобрать. В примере всего 9 человек и маленький график и уже мало что понятно. Попробуйте последить за движениями собственных глаз, когда будете смотреть на этот пример.
А если объектов - тысячи? Количество сотрудников вполне может исчисляться десятками тысяч, магазинов - тысячами, товаров - миллионами. Никакой граф уже ничего не покажет и обработать такое количество связей будет не в состоянии.
Визуальное исследование данных (Data Discovery) должно решать, например, следующую задачу: 1) я вижу своего целевого клиента, который платит такой-то картой с определенной частотой, покупает при этом в определенное время определенные товары или группы товаров, делает при этом транзакции определенного типа и живет в конкретном районе; 2) я хочу увидеть похожих на него людей, но не его самого. Причем всё это визуально, быстро и без кодирования на Питоне (Python).
Сама формулировка подразумевает, что поле «Клиент» должно присутствовать в зоне исследования минимум дважды и без ограничений - мы же заранее не знаем, кто окажется похож на целевые объекты. И остальные поля, значит, тоже.
И как это всё отобразить, сделать понятным, функциональным и гибким?
В результате долгих размышлений и многочисленных попыток реализации родился супервиджет, который называется «Область связей». А мы внутри Rapeed его называем «кхор». Почему? Об этом в следующем посте.
#удовольствие_от_аналитики #data_discovery
👍8🔥5👏1
cases-Риск ухода.png
1.8 MB
Пример графа по связям данных.
Всего 9 элементов, а экран уже заполнен.
Источник: сторонняя система
#удовольствие_от_аналитики #data_discovery
Всего 9 элементов, а экран уже заполнен.
Источник: сторонняя система
#удовольствие_от_аналитики #data_discovery
👍1😢1
У неё такие связи! (с)
После прошлой публикации я два дня искал в истории разработки прототипы области связей - самому стало интересно вспомнить, как тогда мысль работала.
Я тогда думал о пути анализа данных, что хочу видеть и всё содержимое поля и все связи этого поля; хочу произвольно двигать поля и понимать, как меняются связи в динамике; хочу даже видеть связи разных элементов поля между собой. В таблице этого сделать нельзя, и в графе тоже; как же это должно выглядеть и работать??
В зависимости от порядка полей связи между ними могут радикально различаться. Тут я вспомнил про вращающиеся барабаны - кхоры, установленные у входов в буддистские храмы. Их положено крутить, причем порядок и последовательность вращения определяет судьбу паломника. А в области связей порядок столбцов определяет путь аналитического исследования! Без шуток, именно поэтому наша область связей, автоматически формирующая направление исследования данных (и управляющая информацией, как мы увидим дальше) внутри команды называется «кхор».
Предположим, у нас есть данные о платежах - клиенты платят получателям за кредиты, товары и услуги. Давайте посмотрим, кто кому платит - вытащим в область связей поля «Клиент» с общей суммой платежей и «Получатель» с количеством полученных платежей. Для удобства отсортируем оба поля по убыванию. «Бегая» мышкой по столбцам, можно сразу видеть связи полей (на скриншоте этого не передать): например, при наведении на клиента помечаются все получатели его платежей и наоборот - при наведении на получателя помечаются все его плательщики (скриншот ниже).
#удовольствие_от_аналитики #data_discovery
После прошлой публикации я два дня искал в истории разработки прототипы области связей - самому стало интересно вспомнить, как тогда мысль работала.
Я тогда думал о пути анализа данных, что хочу видеть и всё содержимое поля и все связи этого поля; хочу произвольно двигать поля и понимать, как меняются связи в динамике; хочу даже видеть связи разных элементов поля между собой. В таблице этого сделать нельзя, и в графе тоже; как же это должно выглядеть и работать??
В зависимости от порядка полей связи между ними могут радикально различаться. Тут я вспомнил про вращающиеся барабаны - кхоры, установленные у входов в буддистские храмы. Их положено крутить, причем порядок и последовательность вращения определяет судьбу паломника. А в области связей порядок столбцов определяет путь аналитического исследования! Без шуток, именно поэтому наша область связей, автоматически формирующая направление исследования данных (и управляющая информацией, как мы увидим дальше) внутри команды называется «кхор».
Предположим, у нас есть данные о платежах - клиенты платят получателям за кредиты, товары и услуги. Давайте посмотрим, кто кому платит - вытащим в область связей поля «Клиент» с общей суммой платежей и «Получатель» с количеством полученных платежей. Для удобства отсортируем оба поля по убыванию. «Бегая» мышкой по столбцам, можно сразу видеть связи полей (на скриншоте этого не передать): например, при наведении на клиента помечаются все получатели его платежей и наоборот - при наведении на получателя помечаются все его плательщики (скриншот ниже).
#удовольствие_от_аналитики #data_discovery
👍3❤2🔥1
Кликнем на конкретном получателе. Ему платило 17 человек. Можно ли узнать, по каким адресам располагались его офисы? Никаких проблем - вытаскиваем поле «Адрес регистрации». А интересно, кто-то другой по этим адресам располагался? Снова вытаскивваем поле «Получатель» - оказывается, у этой организации было 104 адреса, по которым располагалось еще 14 получателей платежей! (видимо, неспроста).
#удовольствие_от_аналитики #data_discovery
#удовольствие_от_аналитики #data_discovery
🔥2
А если мы еще раз вытащим в область связей поле «Клиент», то увидим, что платили этим 15ти получателям 223 клиента!
То есть мы нашли, во-первых, связанных через общий адрес офиса получателей платежа, а во-вторых, 223 клиента, связанных с первоначальной группой из 17 человек, просто двигая мышкой. От нас требуется просто любознательность и понимание, что все ограничения, до сих пор существовавшие в аналитических системах, сняты.
#удовольствие_от_аналитики #data_discovery
То есть мы нашли, во-первых, связанных через общий адрес офиса получателей платежа, а во-вторых, 223 клиента, связанных с первоначальной группой из 17 человек, просто двигая мышкой. От нас требуется просто любознательность и понимание, что все ограничения, до сих пор существовавшие в аналитических системах, сняты.
#удовольствие_от_аналитики #data_discovery
🔥3❤1👏1
Область связей, как видно, отображает сотни тысяч связей, в реальном времени перерисовывая картинку, и занимает при этом места на экране не намного больше обычной таблицы. Нужно же оставить место для других виджетов. Но об этом - в другой раз.
#удовольствие_от_аналитики #data_discovery
#удовольствие_от_аналитики #data_discovery
👍1
Khor.jpg
146.6 KB
🔥3👍2
Свой движок или СУБД?
Думаю, что развитие рынка BI-аналитики в России сейчас определяют два вопроса:
1. Почему поголовно все российские BI-продукты не имели или отказались от своего движка и используют для обработки данных open-source СУБД? Есть только два исключения, расскажу, какие.
2. Почему поголовно все лидирующие в мире BI-продукты из квадранта Гартнера создали или приобрели свои движки и не отдают обработку данных сторонним СУБД? Тут исключений нет.
Очень интересно ваше мнение!
#удовольствие_от_аналитики #dolap
Думаю, что развитие рынка BI-аналитики в России сейчас определяют два вопроса:
1. Почему поголовно все российские BI-продукты не имели или отказались от своего движка и используют для обработки данных open-source СУБД? Есть только два исключения, расскажу, какие.
2. Почему поголовно все лидирующие в мире BI-продукты из квадранта Гартнера создали или приобрели свои движки и не отдают обработку данных сторонним СУБД? Тут исключений нет.
Очень интересно ваше мнение!
#удовольствие_от_аналитики #dolap
👍1🔥1👏1💯1
BI на СУБД - что с ними не так?
А что не так с BI на основе СУБД?
Сейчас их в России больше 70 штук, а технологических преимуществ ни у кого, получается, и нет - если десятки продуктов основаны на SQL-запросах и специфических функциях одной и той же СУБД, например, ClickHouse, то функциональных различий ждать не приходится. Отличаются продукты оберткой, особенностями импорта и разными визуализациями данных, а расчеты и функции будут одинаковы.
Процитирую здесь недавний пост одного моего знакомого - эксперта рынка BI Евгения Стучалкина:
«Потихоньку заканчиваю демо-стенд для демонстрации генератора моделей. Сделал 4 простых дашборда на топовых российских платформах: А, B, C, D. (названия скрыты мной - Р.Р.)
Хочу сделать акцент на одном упущении, которое просматривается у всех систем сразу. Это недостаток функционала в области data discovery. Так или иначе, нарисовать приличную картинку можно у всех. У всех есть удобная интерактивность с фильтрацией через диаграммы (кроме A на текущий момент, ха-ха).
Но при этом полностью отсутствует возможность заглянуть в данные глубже, чем в заготовленные картинки. Вот на экране на нижних бар-чартах у меня видно, что московский филиал осуществил продажи 475 клиентам (левый бар чарт), из которых 2 клиента закреплены за другими филиалами (правый бар чарт).
Что это за два клиента? Я никогда не узнаю, если у меня нет готовой визуализации конкретно под этот запрос. Но такие ситуации возникают спонтанно, преднастроенных таблиц не напасешься на все варианты»
Конечно! Вы до сих считаете, что «пользователям нужны дашборды»? Пользователям нужна информация в понятном виде и средства работы с ней без ограничений. BI-продукты на основе СУБД дают картинку из статичных виджетов, каждый из которых является набором из SQL-запроса, настроек и кода визуализации. Упомянутая фильтрация достигается, как правило, модификацией SQL-запроса. Сделать что-то непредусмотренное в такой архитектуре - это полностью пересобрать дашборд.
В ситуации, когда у десятков продуктов нет технологического преимущества в расчетах и обработке данных, продукты будут развиваться, увеличивая число и функционал визуализаций и развивая промежуточный слой бизнес-логики, потому что больше развивать нечего. При этом, каким бы синтаксис внутреннего языка ни был, на выходе в базу идет SQL-запрос. И дальше по циклу - см. цитату выше.
А что плохого в SQL-запросах для BI? Разберемся далее.
#удовольствие_от_аналитики #dolap
А что не так с BI на основе СУБД?
Сейчас их в России больше 70 штук, а технологических преимуществ ни у кого, получается, и нет - если десятки продуктов основаны на SQL-запросах и специфических функциях одной и той же СУБД, например, ClickHouse, то функциональных различий ждать не приходится. Отличаются продукты оберткой, особенностями импорта и разными визуализациями данных, а расчеты и функции будут одинаковы.
Процитирую здесь недавний пост одного моего знакомого - эксперта рынка BI Евгения Стучалкина:
«Потихоньку заканчиваю демо-стенд для демонстрации генератора моделей. Сделал 4 простых дашборда на топовых российских платформах: А, B, C, D. (названия скрыты мной - Р.Р.)
Хочу сделать акцент на одном упущении, которое просматривается у всех систем сразу. Это недостаток функционала в области data discovery. Так или иначе, нарисовать приличную картинку можно у всех. У всех есть удобная интерактивность с фильтрацией через диаграммы (кроме A на текущий момент, ха-ха).
Но при этом полностью отсутствует возможность заглянуть в данные глубже, чем в заготовленные картинки. Вот на экране на нижних бар-чартах у меня видно, что московский филиал осуществил продажи 475 клиентам (левый бар чарт), из которых 2 клиента закреплены за другими филиалами (правый бар чарт).
Что это за два клиента? Я никогда не узнаю, если у меня нет готовой визуализации конкретно под этот запрос. Но такие ситуации возникают спонтанно, преднастроенных таблиц не напасешься на все варианты»
Конечно! Вы до сих считаете, что «пользователям нужны дашборды»? Пользователям нужна информация в понятном виде и средства работы с ней без ограничений. BI-продукты на основе СУБД дают картинку из статичных виджетов, каждый из которых является набором из SQL-запроса, настроек и кода визуализации. Упомянутая фильтрация достигается, как правило, модификацией SQL-запроса. Сделать что-то непредусмотренное в такой архитектуре - это полностью пересобрать дашборд.
В ситуации, когда у десятков продуктов нет технологического преимущества в расчетах и обработке данных, продукты будут развиваться, увеличивая число и функционал визуализаций и развивая промежуточный слой бизнес-логики, потому что больше развивать нечего. При этом, каким бы синтаксис внутреннего языка ни был, на выходе в базу идет SQL-запрос. И дальше по циклу - см. цитату выше.
А что плохого в SQL-запросах для BI? Разберемся далее.
#удовольствие_от_аналитики #dolap
👍4🔥3💯2❤1
Структурность vs многомерность и аналитика данных
SQL (структурный язык запросов) отмечает в этом году 50-летие(!) рождения внутри IBM. Через 23 года после него силами Microsoft появился MDX (язык многомерных выражений), который в 2018 году трансформировался в DAX (язык выражений для анализа данных).
То есть после четверти века существования SQL возник специализированный язык аналитических запросов, который активно развивается до сих пор. Его отличительной особенностью является, как следует из названия, ориентация на многомерность данных: иерархию размерностей, просмотр значений в различных разрезах - в общем, на принципы OLAP-работы с данными Э.Кодда. SQL, очевидно, этого обеспечить не может - он был разработан для отдачи плоских наборов данных.
Например, у нас есть 3 справочника: 1) справочник адресов, где есть поле Город, 2) справочник клиентов, где есть поле Клиент и связь с со строчкой адреса, и 3) справочник Товаров. Также есть таблица, где сказано, какой клиент сколько товара, когда и по какой цене купил. Мы хотим не просто посмотреть на наши продажи, но и проанализировать их: сравнить территории менеджеров (группы Городов), Клиентов как внутри территорий, так и в «абсолютном зачете», понять, продажи каких Товаров растут, а каких - падают, и так далее. Для такого анализа достаточно одного OLAP-куба, а SQL-запросов требуются сотни и тысячи (итоги по городу - один запрос, продажи по городу - второй, продажи и итоги по клиенту - третий и четвертый, клиент-товар - пятый, город-клиент - шестой…) Это азбучные истины, известные десятилетиями. Это разница между обычным листом Excel и сводной таблицей на его основе.
Почему же российские BI-продукты отказываются от собственных OLAP-движков и продолжают посылать на сервера PostgreSQL и ClickHouse всё больше SQL-запросов? Разберемся дальше (спойлер: комплекс причин, среди которых «долго» и «дорого» не главные).
#удовольствие_от_аналитики #dolap
SQL (структурный язык запросов) отмечает в этом году 50-летие(!) рождения внутри IBM. Через 23 года после него силами Microsoft появился MDX (язык многомерных выражений), который в 2018 году трансформировался в DAX (язык выражений для анализа данных).
То есть после четверти века существования SQL возник специализированный язык аналитических запросов, который активно развивается до сих пор. Его отличительной особенностью является, как следует из названия, ориентация на многомерность данных: иерархию размерностей, просмотр значений в различных разрезах - в общем, на принципы OLAP-работы с данными Э.Кодда. SQL, очевидно, этого обеспечить не может - он был разработан для отдачи плоских наборов данных.
Например, у нас есть 3 справочника: 1) справочник адресов, где есть поле Город, 2) справочник клиентов, где есть поле Клиент и связь с со строчкой адреса, и 3) справочник Товаров. Также есть таблица, где сказано, какой клиент сколько товара, когда и по какой цене купил. Мы хотим не просто посмотреть на наши продажи, но и проанализировать их: сравнить территории менеджеров (группы Городов), Клиентов как внутри территорий, так и в «абсолютном зачете», понять, продажи каких Товаров растут, а каких - падают, и так далее. Для такого анализа достаточно одного OLAP-куба, а SQL-запросов требуются сотни и тысячи (итоги по городу - один запрос, продажи по городу - второй, продажи и итоги по клиенту - третий и четвертый, клиент-товар - пятый, город-клиент - шестой…) Это азбучные истины, известные десятилетиями. Это разница между обычным листом Excel и сводной таблицей на его основе.
Почему же российские BI-продукты отказываются от собственных OLAP-движков и продолжают посылать на сервера PostgreSQL и ClickHouse всё больше SQL-запросов? Разберемся дальше (спойлер: комплекс причин, среди которых «долго» и «дорого» не главные).
#удовольствие_от_аналитики #dolap
👍3
Настоящих буйных мало! (с)
Оглядываясь назад, я понимаю, насколько сложно, долго и дорого создать свой OLAP-движок. А тем более DOLAP-движок, аналогов которому нет в мире. Сама постановка задачи вводит в растерянность, технологии нет, поэтому планировать что-либо невозможно. Нужно обладать великой верой в будущий продукт, иметь супер-команду для того, чтобы приступить к разработке и быть готовым пожертвовать всем ради продукта, пока он не станет на ноги, то есть на протяжении всего времени его разработки. Хоть это и высокопарно звучит, но так оно и есть. И это касается всех членов команды, владельца продукта и инвестирующих в его разработку.
Да, разработка любой технологии - это долго, дорого и рискованно. Но кадровый голод на высококлассных ИТ-специалистов в России в целом и у вендоров в частности, делает главным препятствием в создании движка другой аспект, с которым мне очень повезло - наличие сплоченной команды прекрасно знающих математику, алгоритмы и технологии, обладающих релевантным опытом и в хорошем смысле упёртых. Ведь рядом маячит лёгкий путь зарабатывания денег - бери набор (SuperSet/Datalens + eCharts/d3 + ClickHouse/PostgreSQL) и иди к заказчикам.
Да и что там OLAP-движок - много ли вы знаете полностью российских операционных систем, не основанных на open source? На ум приходят только специализированные ОС типа Kaspersky OS (совсем недавно вышедшей) или ОС реального времени времен еще Советского Союза. А баз данных, не основанных на открытом коде? Только ClickHouse, сам ставший open-source, при этом код никогда и не был российским (сначала владельцем была голландская головная компания Яндекса, затем юр.лицо в юрисдикции США). Есть еще СУБД Линтер и, пожалуй, всё.
Понятно, что при отсутствии кадров для создания даже критических вещей с понятными задачами и рынком очередь до многомерных движков дойдет не скоро. Российские BI-вендоры сейчас заняты первичным захватом освобождающегося рынка. Но стратегическим преимуществом обладает тот, у кого есть своя технология обработки данных, решающая и стандартные задачи, и предлагающая совершенно новую свободу работы с данными.
#удовольствие_от_аналитики
Оглядываясь назад, я понимаю, насколько сложно, долго и дорого создать свой OLAP-движок. А тем более DOLAP-движок, аналогов которому нет в мире. Сама постановка задачи вводит в растерянность, технологии нет, поэтому планировать что-либо невозможно. Нужно обладать великой верой в будущий продукт, иметь супер-команду для того, чтобы приступить к разработке и быть готовым пожертвовать всем ради продукта, пока он не станет на ноги, то есть на протяжении всего времени его разработки. Хоть это и высокопарно звучит, но так оно и есть. И это касается всех членов команды, владельца продукта и инвестирующих в его разработку.
Да, разработка любой технологии - это долго, дорого и рискованно. Но кадровый голод на высококлассных ИТ-специалистов в России в целом и у вендоров в частности, делает главным препятствием в создании движка другой аспект, с которым мне очень повезло - наличие сплоченной команды прекрасно знающих математику, алгоритмы и технологии, обладающих релевантным опытом и в хорошем смысле упёртых. Ведь рядом маячит лёгкий путь зарабатывания денег - бери набор (SuperSet/Datalens + eCharts/d3 + ClickHouse/PostgreSQL) и иди к заказчикам.
Да и что там OLAP-движок - много ли вы знаете полностью российских операционных систем, не основанных на open source? На ум приходят только специализированные ОС типа Kaspersky OS (совсем недавно вышедшей) или ОС реального времени времен еще Советского Союза. А баз данных, не основанных на открытом коде? Только ClickHouse, сам ставший open-source, при этом код никогда и не был российским (сначала владельцем была голландская головная компания Яндекса, затем юр.лицо в юрисдикции США). Есть еще СУБД Линтер и, пожалуй, всё.
Понятно, что при отсутствии кадров для создания даже критических вещей с понятными задачами и рынком очередь до многомерных движков дойдет не скоро. Российские BI-вендоры сейчас заняты первичным захватом освобождающегося рынка. Но стратегическим преимуществом обладает тот, у кого есть своя технология обработки данных, решающая и стандартные задачи, и предлагающая совершенно новую свободу работы с данными.
#удовольствие_от_аналитики
👍6🔥4💯3👏2
Нашёл!
Я всё-таки нашел первый прототип Области связей (кхора): мне напомнили о моей же статье от 2020 года, где я выдвинул идею непрерывной аналитики и сравнил процесс исследования данных с реальным непрерывным производством.
С удовольствием прочитал собственную статью снова (и вам советую!), потому что именно эту идею Rapeed и реализует.
#удовольствие_от_аналитики #data_discovery
Я всё-таки нашел первый прототип Области связей (кхора): мне напомнили о моей же статье от 2020 года, где я выдвинул идею непрерывной аналитики и сравнил процесс исследования данных с реальным непрерывным производством.
С удовольствием прочитал собственную статью снова (и вам советую!), потому что именно эту идею Rapeed и реализует.
#удовольствие_от_аналитики #data_discovery
👍4🔥4😁1
В 2020 году я назвал это Картой связей. Сравните, что изменилось за 4 года.
#удовольствие_от_аналитики #data_discovery
#удовольствие_от_аналитики #data_discovery
👍3🔥2👏1
DOLAP vs ClickHouse
ClickHouse, без сомнений, выдающаяся колоночная СУБД, очень хорошо распараллеленная по дате/времени и превосходящая конкурентов по многим аспектам. Яндекс потратил на ее создание (и в рамках Я.Метрики и после) тысячи человеко-лет и затем сделал open-source-версию продукта.
Было бы неплохо сравнить скорость вычислений нашего DOLAP-движка с ClickHouse (например, ежедневную динамику уникальных абонентов в разрезе регионов РФ на 20+ млрд записей на одном и том же железе), и мы это обязательно сделаем. Но разрабатывать свой движок и не использовать ClickHouse или подобную СУБД меня заставило другое, а именно желание сделать Data Discovery.
Помните, что в одном окне Области связей можно видеть связи элементов «поле 1 - поле 1» и «поле 2 - поле 2» через промежуточные поля? То есть одних клиентов, похожих на других клиентов, получателей, связанных с другими получателями, и т.д. - через огромные по размеру поля платежей и адресов внутри огромных таблиц?
При этих вычислениях, какая бы замечательная ни была СУБД, не избежать «цифрового взрыва», то есть умножения больших таблиц самих на себя. Технически это несколько операций JOIN с последующей группировкой.
По-простому, если у вас всего 10 000 клиентов и 20 000 платежей, то количество возможных связей «клиент-клиент», из которых надо выявить реальные, составляет 2 триллиона. Все СУБД тут же выходят из чата на пару дней или насовсем. Мы проверяли ClickHouse на этой задаче - всё предсказуемо, задача на 1000 объектов считается за минуты и время растет в геометрической прогрессии. Никто не станет столько ждать в процессе исследования данных. По этой причине, кстати, и придумали NoSQL базы. И по этой же причине каждое поле в виджетах обычных BI-продуктов можно использовать только один раз.
Ни одна СУБД, в том числе ClickHouse, не справляется с цифровым взрывом, возникающим при Data Discovery. Это первая причина разработки нашего DOLAP-движка. Но с точки зрения клиентов самая важная причина доминирования нашего DOLAP над любой СУБД - это технология связанных полей. О ней дальше.
#удовольствие_от_аналитики #data_discovery
ClickHouse, без сомнений, выдающаяся колоночная СУБД, очень хорошо распараллеленная по дате/времени и превосходящая конкурентов по многим аспектам. Яндекс потратил на ее создание (и в рамках Я.Метрики и после) тысячи человеко-лет и затем сделал open-source-версию продукта.
Было бы неплохо сравнить скорость вычислений нашего DOLAP-движка с ClickHouse (например, ежедневную динамику уникальных абонентов в разрезе регионов РФ на 20+ млрд записей на одном и том же железе), и мы это обязательно сделаем. Но разрабатывать свой движок и не использовать ClickHouse или подобную СУБД меня заставило другое, а именно желание сделать Data Discovery.
Помните, что в одном окне Области связей можно видеть связи элементов «поле 1 - поле 1» и «поле 2 - поле 2» через промежуточные поля? То есть одних клиентов, похожих на других клиентов, получателей, связанных с другими получателями, и т.д. - через огромные по размеру поля платежей и адресов внутри огромных таблиц?
При этих вычислениях, какая бы замечательная ни была СУБД, не избежать «цифрового взрыва», то есть умножения больших таблиц самих на себя. Технически это несколько операций JOIN с последующей группировкой.
По-простому, если у вас всего 10 000 клиентов и 20 000 платежей, то количество возможных связей «клиент-клиент», из которых надо выявить реальные, составляет 2 триллиона. Все СУБД тут же выходят из чата на пару дней или насовсем. Мы проверяли ClickHouse на этой задаче - всё предсказуемо, задача на 1000 объектов считается за минуты и время растет в геометрической прогрессии. Никто не станет столько ждать в процессе исследования данных. По этой причине, кстати, и придумали NoSQL базы. И по этой же причине каждое поле в виджетах обычных BI-продуктов можно использовать только один раз.
Ни одна СУБД, в том числе ClickHouse, не справляется с цифровым взрывом, возникающим при Data Discovery. Это первая причина разработки нашего DOLAP-движка. Но с точки зрения клиентов самая важная причина доминирования нашего DOLAP над любой СУБД - это технология связанных полей. О ней дальше.
#удовольствие_от_аналитики #data_discovery
👍7🔥1
Самая большая проблема BI
Некоторые скажут, что основная проблема при внедрении BI - это «грязные данные»: дубликаты, пустые и невалидные значения. Другие возразят, что основная боль - отсутствие мастер-данных. Третьи будут доказывать, что без единой методологии расчета KPI внедрять BI бесполезно.
Представьте, что вам надо проанализировать пример из прошлого поста - ежедневную динамику количества уникальных клиентов в разрезе регионов РФ, и у вас есть источник с этими данными. Если там есть какая-то доля «грязных» данных, это не помешает вам посчитать нужные количества. Потом данные можно почистить, но цифры вы уже знаете. Также не помешает отсутствие методологии и мастер-данных - посчитать требуемый показатель вы сможете прямо из источника.
Настоящая проблема - когда требуемая для расчетов информация содержится в двух или более источниках разной детализации (или, как теперь выражаются, гранулярности).
Например, продажи (строки чеков) в кассовой системе записываются много раз в секунду с фиксацией даты-времени, номера чека, номера кассы, кода товара, кода клиента; остатки товаров на полках снимаются в специальном приложении несколько раз в день с детализацией товар-магазин-полка-время; приходы - товар-поставщик-магазин-дата; расчеты с поставщиками в финансовой системе - поставщик-магазин-дата и т.д.
То есть у нас за один и тот же период четыре источника разной детализации:
1. миллиард строк продаж
Дата_Время (сек) - Чек - Касса - Клиент - Товар - Количество - Сумма
2. два миллиарда строк остатков
Дата_Время (час) - Товар - Магазин - Полка - Количество
3. два миллиона строк приходов
Дата - Товар - Поставщик - Магазин - Количество - Сумма
4. миллион строк платежей
Дата - Поставщик - Магазин - Сумма
(В реальности всё гораздо сложнее и запутаннее!)
И если в этой ситуации вы хотите посчитать, например, на сколько дней продаж хватит товара в магазинах, или движение денежных средств, то есть задействовать более одного источника - вам придется как-то склеивать, группировать и агрегировать данные, чтобы ничего не задвоилось и не потерялось.
Это и есть главнейшая проблема любого внедрения и использования BI-систем на практике - объединение источников разной детализации, качества и размера внутри одного расчета. Есть разные оценки, по которым на это уходит не менее 50% времени разработчиков.
И это объективная ситуация - чем больше компания хочет анализировать данные, тем больше у нее систем, тем они детальнее, тем больше уровней грануляции данных - тем больше ресурсов тратится на анализ совокупных данных.
Технология связанных полей Rapeed избавляет клиентов от этой проблемы - полностью и безоговорочно.
#удовольствие_от_аналитики #связанные_поля
Некоторые скажут, что основная проблема при внедрении BI - это «грязные данные»: дубликаты, пустые и невалидные значения. Другие возразят, что основная боль - отсутствие мастер-данных. Третьи будут доказывать, что без единой методологии расчета KPI внедрять BI бесполезно.
Представьте, что вам надо проанализировать пример из прошлого поста - ежедневную динамику количества уникальных клиентов в разрезе регионов РФ, и у вас есть источник с этими данными. Если там есть какая-то доля «грязных» данных, это не помешает вам посчитать нужные количества. Потом данные можно почистить, но цифры вы уже знаете. Также не помешает отсутствие методологии и мастер-данных - посчитать требуемый показатель вы сможете прямо из источника.
Настоящая проблема - когда требуемая для расчетов информация содержится в двух или более источниках разной детализации (или, как теперь выражаются, гранулярности).
Например, продажи (строки чеков) в кассовой системе записываются много раз в секунду с фиксацией даты-времени, номера чека, номера кассы, кода товара, кода клиента; остатки товаров на полках снимаются в специальном приложении несколько раз в день с детализацией товар-магазин-полка-время; приходы - товар-поставщик-магазин-дата; расчеты с поставщиками в финансовой системе - поставщик-магазин-дата и т.д.
То есть у нас за один и тот же период четыре источника разной детализации:
1. миллиард строк продаж
Дата_Время (сек) - Чек - Касса - Клиент - Товар - Количество - Сумма
2. два миллиарда строк остатков
Дата_Время (час) - Товар - Магазин - Полка - Количество
3. два миллиона строк приходов
Дата - Товар - Поставщик - Магазин - Количество - Сумма
4. миллион строк платежей
Дата - Поставщик - Магазин - Сумма
(В реальности всё гораздо сложнее и запутаннее!)
И если в этой ситуации вы хотите посчитать, например, на сколько дней продаж хватит товара в магазинах, или движение денежных средств, то есть задействовать более одного источника - вам придется как-то склеивать, группировать и агрегировать данные, чтобы ничего не задвоилось и не потерялось.
Это и есть главнейшая проблема любого внедрения и использования BI-систем на практике - объединение источников разной детализации, качества и размера внутри одного расчета. Есть разные оценки, по которым на это уходит не менее 50% времени разработчиков.
И это объективная ситуация - чем больше компания хочет анализировать данные, тем больше у нее систем, тем они детальнее, тем больше уровней грануляции данных - тем больше ресурсов тратится на анализ совокупных данных.
Технология связанных полей Rapeed избавляет клиентов от этой проблемы - полностью и безоговорочно.
#удовольствие_от_аналитики #связанные_поля
👍4🔥4