20-летняя история - С.М.А.Р.Т., Полиматика, Rapeed
Создание аналитических технологий стало моей профессией, моим хобби и основным средством существования 20 лет назад - в 2004 году. Точнее, первая технология появилась чуть раньше, а в 2004 году она стала отдельным продуктом.
Началось это случайно.
Наш крупнейший клиент, где мы внедрили свою ERP-систему «МАГНАТ» - Братский лесопромышленный комплекс (БЛПК), входящий в холдинг «Илим Палп» - заказал нам 750 отчетов.
Сшитое и подписанное ТЗ на отчеты было толщиной сантиметров 20. Во всех отчетах информация повторялась, но в каждом отчете ее нужно было представлять в разных разрезах - отгрузка по цехам, отгрузка по группам номенклатуры и т.д., даже в разрезе портов (!) - до сих помню, как меня поразило, сколько там портов было предусмотрено. Документов в БЛПК создавалось 1,5 миллиона в месяц. У них был установлен Sybase IQ (теперь - SAP HANA) специально для того, чтобы отчеты формировались не неделями, а хотя бы часами и минутами.
Конечно, хотелось заработать много денег и сделать эти 750 отчетов. Но стало ясно, что нужно средство, которое позволит пользователям самим эти разрезы получать. После года крайне интенсивной разработки родился С.М.А.Р.Т. - Система Мгновенного Анализа Реляционных Таблиц, написанная на Delphi. Сначала С.М.А.Р.Т. был частью «Магната», но я заметил, что на всех презентациях я показываю только то, как можно вертеть-крутить-играть с данными. Поэтому в 2004 году С.М.А.Р.Т. стал отдельным продуктом и был им до 2010 года.
У С.М.А.Р.Т.а было много клиентов - и розница, и госструктуры, и транспортные компании, и нефтяные. Проблема была в том, что он был обычным WIndows-приложением, поэтому не мог обработать больше 150 миллионов записей - память кончалась и система падала. Помню, что первый раз это случилось в «Связном», а на второй раз я понял, что это будет случаться на каждом крупном клиенте.
Со свойственным мне максимализмом я решил разработать систему на новых технологиях, чтобы снять это ограничение. Это значит - Линукс, прямая работа с памятью, зто значит - новая команда, новые алгоритмы, принципы хранения и обработки, новое всё.
В 2011 году я начал разрабатывать новую систему. До сих пор помню момент, как после недельного придумывания имени меня озарило: всё можно посчитать! Всё - по-гречески «поли», «посчитать» - «матика». Есть математика, а у меня будет Полиматика. Так родилось имя, а технология рождалась после этого еще 5 лет силами пяти разработчиков под моим руководством.
Было 4 или 5 неудачных попыток, результаты которых меня не устраивали. На шестой раз, похоже, что-то получилось. У нас возникли пилотные проекты, причем первый сразу в ФНС, потому что они не могли найти другой системы, способной показать таблицу из 15 миллионов строк (организации), раскрывающихся до документа (сотни миллионов), с десятками столбцов (корректировать отчетность можно в течение нескольких кварталов), раскрывающихся до инспекции. И не только показывать, а быстро сортировать, фильтровать её, да еще и создавать свои расчетные факты, по которым тоже - сортировать, фильтровать, раскрывать… Это был 2016 год. Тот сервер, наверно, до сих пор стоит в Межрайонной инспекции на Павелецкой - внести дали, а вот вынести никто так и не смог разрешить.
После этого в ФНС было много проектов на Полиматике, было много других клиентов, было международное развитие, офисы в Лондоне, Цюрихе, Берлине - как-нибудь расскажу. Достаточно быстро выяснилось два неприятных момента.
Первый - все данные грузятся в память сервера и считаются там.
#история_rapeed
Создание аналитических технологий стало моей профессией, моим хобби и основным средством существования 20 лет назад - в 2004 году. Точнее, первая технология появилась чуть раньше, а в 2004 году она стала отдельным продуктом.
Началось это случайно.
Наш крупнейший клиент, где мы внедрили свою ERP-систему «МАГНАТ» - Братский лесопромышленный комплекс (БЛПК), входящий в холдинг «Илим Палп» - заказал нам 750 отчетов.
Сшитое и подписанное ТЗ на отчеты было толщиной сантиметров 20. Во всех отчетах информация повторялась, но в каждом отчете ее нужно было представлять в разных разрезах - отгрузка по цехам, отгрузка по группам номенклатуры и т.д., даже в разрезе портов (!) - до сих помню, как меня поразило, сколько там портов было предусмотрено. Документов в БЛПК создавалось 1,5 миллиона в месяц. У них был установлен Sybase IQ (теперь - SAP HANA) специально для того, чтобы отчеты формировались не неделями, а хотя бы часами и минутами.
Конечно, хотелось заработать много денег и сделать эти 750 отчетов. Но стало ясно, что нужно средство, которое позволит пользователям самим эти разрезы получать. После года крайне интенсивной разработки родился С.М.А.Р.Т. - Система Мгновенного Анализа Реляционных Таблиц, написанная на Delphi. Сначала С.М.А.Р.Т. был частью «Магната», но я заметил, что на всех презентациях я показываю только то, как можно вертеть-крутить-играть с данными. Поэтому в 2004 году С.М.А.Р.Т. стал отдельным продуктом и был им до 2010 года.
У С.М.А.Р.Т.а было много клиентов - и розница, и госструктуры, и транспортные компании, и нефтяные. Проблема была в том, что он был обычным WIndows-приложением, поэтому не мог обработать больше 150 миллионов записей - память кончалась и система падала. Помню, что первый раз это случилось в «Связном», а на второй раз я понял, что это будет случаться на каждом крупном клиенте.
Со свойственным мне максимализмом я решил разработать систему на новых технологиях, чтобы снять это ограничение. Это значит - Линукс, прямая работа с памятью, зто значит - новая команда, новые алгоритмы, принципы хранения и обработки, новое всё.
В 2011 году я начал разрабатывать новую систему. До сих пор помню момент, как после недельного придумывания имени меня озарило: всё можно посчитать! Всё - по-гречески «поли», «посчитать» - «матика». Есть математика, а у меня будет Полиматика. Так родилось имя, а технология рождалась после этого еще 5 лет силами пяти разработчиков под моим руководством.
Было 4 или 5 неудачных попыток, результаты которых меня не устраивали. На шестой раз, похоже, что-то получилось. У нас возникли пилотные проекты, причем первый сразу в ФНС, потому что они не могли найти другой системы, способной показать таблицу из 15 миллионов строк (организации), раскрывающихся до документа (сотни миллионов), с десятками столбцов (корректировать отчетность можно в течение нескольких кварталов), раскрывающихся до инспекции. И не только показывать, а быстро сортировать, фильтровать её, да еще и создавать свои расчетные факты, по которым тоже - сортировать, фильтровать, раскрывать… Это был 2016 год. Тот сервер, наверно, до сих пор стоит в Межрайонной инспекции на Павелецкой - внести дали, а вот вынести никто так и не смог разрешить.
После этого в ФНС было много проектов на Полиматике, было много других клиентов, было международное развитие, офисы в Лондоне, Цюрихе, Берлине - как-нибудь расскажу. Достаточно быстро выяснилось два неприятных момента.
Первый - все данные грузятся в память сервера и считаются там.
#история_rapeed
👍6
Что значит «считаются»? При любом расчете данные нужно сортировать и агрегировать. Так вот, несмотря на постоянную оптимизацию алгоритмов, мы наткнулись на то, что 150 миллионов записей, на которых умирал С.М.А.Р.Т., считаются достаточно быстро - допустим, секунд за 10 я получаю на экране нужную табличку. Если данных 300 миллионов записей, то я буду ждать уже секунд 40 или минуту. Миллиард записей считался минутами, иногда десятками минут, если не повезет (это еще хорошо, потому что конкуренты тогда и близко к этим показателям не стояли). То есть время расчетов росло быстрее объема данных, где-то между N*ln(N) и N в квадрате.
Мы немножко улучшили скорость, подключив для сортировки данных видеокарты (GPU). Это сейчас на GPU все майнят и обучают модели искусственного интеллекта, а в 2017 году это была необычная идея. Она позволила поднять скорость на 10-15%, но маркетингового шума мы навели гораздо больше.
Второй момент, в который я долго не мог поверить - опять потолок количества записей! Уже не 150 миллионов, спасибо, а 2 миллиарда строк, на практике еще меньше. Но всё равно - потолок! Практический потолок, связанный с объемом доступной памяти для процессора (через 5 лет я узнаю, что не мы одни - в него уткнулись все разработчики в России и, кажется, в мире). Теоретический потолок тоже существует - это 4 млрд строк, что связано с хранением целочисленных индексов.
Помню, как я обрадовался, когда нам на супер-дорогих компьютерах IBM Power9 удалось дойти до 2 млрд записей в одном кубе! Это было связано с тем, что на Power9 можно установить максимально не 1 Тб памяти, а 2Тб, и вся она доступна процессору (в Интелах при установленной GPU доступно только 768 Гбайт). Но эти машинки стоили каждая под 70 000 долларов и оправдывали свое существование далеко не у всех клиентов.
Итак, 1) долго считаем и 2) потолок - опять! При этом клиенты и проекты масштаба страны, команда под 100 человек, известность на рынке, конференции, поездки, Лондон, Цюрих, внутренний язык компании - английский.. Тем не менее мне становились очевидны ограничения, которые опять нужно преодолевать.
И в сентябре 2019 года я ушел из компании, которую создал, для того, чтобы снова делать технологию, не имеющую изъянов и ограничений. Чтобы делать то, что сейчас называется Rapeed.
(Продолжение следует)
#история_rapeed
Мы немножко улучшили скорость, подключив для сортировки данных видеокарты (GPU). Это сейчас на GPU все майнят и обучают модели искусственного интеллекта, а в 2017 году это была необычная идея. Она позволила поднять скорость на 10-15%, но маркетингового шума мы навели гораздо больше.
Второй момент, в который я долго не мог поверить - опять потолок количества записей! Уже не 150 миллионов, спасибо, а 2 миллиарда строк, на практике еще меньше. Но всё равно - потолок! Практический потолок, связанный с объемом доступной памяти для процессора (через 5 лет я узнаю, что не мы одни - в него уткнулись все разработчики в России и, кажется, в мире). Теоретический потолок тоже существует - это 4 млрд строк, что связано с хранением целочисленных индексов.
Помню, как я обрадовался, когда нам на супер-дорогих компьютерах IBM Power9 удалось дойти до 2 млрд записей в одном кубе! Это было связано с тем, что на Power9 можно установить максимально не 1 Тб памяти, а 2Тб, и вся она доступна процессору (в Интелах при установленной GPU доступно только 768 Гбайт). Но эти машинки стоили каждая под 70 000 долларов и оправдывали свое существование далеко не у всех клиентов.
Итак, 1) долго считаем и 2) потолок - опять! При этом клиенты и проекты масштаба страны, команда под 100 человек, известность на рынке, конференции, поездки, Лондон, Цюрих, внутренний язык компании - английский.. Тем не менее мне становились очевидны ограничения, которые опять нужно преодолевать.
И в сентябре 2019 года я ушел из компании, которую создал, для того, чтобы снова делать технологию, не имеющую изъянов и ограничений. Чтобы делать то, что сейчас называется Rapeed.
(Продолжение следует)
#история_rapeed
🔥11❤1👍1👏1
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