Правда, похоже? Кхоры у буддистского храма в Питере.
#удовольствие_от_аналитики #data_discovery

Свой движок или СУБД?
Думаю, что развитие рынка BI-аналитики в России сейчас определяют два вопроса:
1. Почему поголовно все российские BI-продукты не имели или отказались от своего движка и используют для обработки данных open-source СУБД? Есть только два исключения, расскажу, какие.
2. Почему поголовно все лидирующие в мире BI-продукты из квадранта Гартнера создали или приобрели свои движки и не отдают обработку данных сторонним СУБД? Тут исключений нет.
Очень интересно ваше мнение!
#удовольствие_от_аналитики #dolap

BI на СУБД - что с ними не так?
А что не так с BI на основе СУБД?
Сейчас их в России больше 70 штук, а технологических преимуществ ни у кого, получается, и нет - если десятки продуктов основаны на SQL-запросах и специфических функциях одной и той же СУБД, например, ClickHouse, то функциональных различий ждать не приходится. Отличаются продукты оберткой, особенностями импорта и разными визуализациями данных, а расчеты и функции будут одинаковы.
Процитирую здесь недавний пост одного моего знакомого - эксперта рынка BI Евгения Стучалкина:
«Потихоньку заканчиваю демо-стенд для демонстрации генератора моделей. Сделал 4 простых дашборда на топовых российских платформах: А, B, C, D. (названия скрыты мной - Р.Р.)
Хочу сделать акцент на одном упущении, которое просматривается у всех систем сразу. Это недостаток функционала в области data discovery. Так или иначе, нарисовать приличную картинку можно у всех. У всех есть удобная интерактивность с фильтрацией через диаграммы (кроме A на текущий момент, ха-ха).
Но при этом полностью отсутствует возможность заглянуть в данные глубже, чем в заготовленные картинки. Вот на экране на нижних бар-чартах у меня видно, что московский филиал осуществил продажи 475 клиентам (левый бар чарт), из которых 2 клиента закреплены за другими филиалами (правый бар чарт).
Что это за два клиента? Я никогда не узнаю, если у меня нет готовой визуализации конкретно под этот запрос. Но такие ситуации возникают спонтанно, преднастроенных таблиц не напасешься на все варианты»
Конечно! Вы до сих считаете, что «пользователям нужны дашборды»? Пользователям нужна информация в понятном виде и средства работы с ней без ограничений. BI-продукты на основе СУБД дают картинку из статичных виджетов, каждый из которых является набором из SQL-запроса, настроек и кода визуализации. Упомянутая фильтрация достигается, как правило, модификацией SQL-запроса. Сделать что-то непредусмотренное в такой архитектуре - это полностью пересобрать дашборд.
В ситуации, когда у десятков продуктов нет технологического преимущества в расчетах и обработке данных, продукты будут развиваться, увеличивая число и функционал визуализаций и развивая промежуточный слой бизнес-логики, потому что больше развивать нечего. При этом, каким бы синтаксис внутреннего языка ни был, на выходе в базу идет SQL-запрос. И дальше по циклу - см. цитату выше.
А что плохого в SQL-запросах для BI? Разберемся далее.
#удовольствие_от_аналитики #dolap

Структурность 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

Настоящих буйных мало! (с)
Оглядываясь назад, я понимаю, насколько сложно, долго и дорого создать свой OLAP-движок. А тем более DOLAP-движок, аналогов которому нет в мире. Сама постановка задачи вводит в растерянность, технологии нет, поэтому планировать что-либо невозможно. Нужно обладать великой верой в будущий продукт, иметь супер-команду для того, чтобы приступить к разработке и быть готовым пожертвовать всем ради продукта, пока он не станет на ноги, то есть на протяжении всего времени его разработки. Хоть это и высокопарно звучит, но так оно и есть. И это касается всех членов команды, владельца продукта и инвестирующих в его разработку.
Да, разработка любой технологии - это долго, дорого и рискованно. Но кадровый голод на высококлассных ИТ-специалистов в России в целом и у вендоров в частности, делает главным препятствием в создании движка другой аспект, с которым мне очень повезло - наличие сплоченной команды прекрасно знающих математику, алгоритмы и технологии, обладающих релевантным опытом и в хорошем смысле упёртых. Ведь рядом маячит лёгкий путь зарабатывания денег - бери набор (SuperSet/Datalens + eCharts/d3 + ClickHouse/PostgreSQL) и иди к заказчикам.
Да и что там OLAP-движок - много ли вы знаете полностью российских операционных систем, не основанных на open source? На ум приходят только специализированные ОС типа Kaspersky OS (совсем недавно вышедшей) или ОС реального времени времен еще Советского Союза. А баз данных, не основанных на открытом коде? Только ClickHouse, сам ставший open-source, при этом код никогда и не был российским (сначала владельцем была голландская головная компания Яндекса, затем юр.лицо в юрисдикции США). Есть еще СУБД Линтер и, пожалуй, всё.
Понятно, что при отсутствии кадров для создания даже критических вещей с понятными задачами и рынком очередь до многомерных движков дойдет не скоро. Российские BI-вендоры сейчас заняты первичным захватом освобождающегося рынка. Но стратегическим преимуществом обладает тот, у кого есть своя технология обработки данных, решающая и стандартные задачи, и предлагающая совершенно новую свободу работы с данными.
#удовольствие_от_аналитики

Нашёл!
Я всё-таки нашел первый прототип Области связей (кхора): мне напомнили о моей же статье от 2020 года, где я выдвинул идею непрерывной аналитики и сравнил процесс исследования данных с реальным непрерывным производством.
С удовольствием прочитал собственную статью снова (и вам советую!), потому что именно эту идею Rapeed и реализует.
#удовольствие_от_аналитики #data_discovery

В 2020 году я назвал это Картой связей. Сравните, что изменилось за 4 года.
#удовольствие_от_аналитики #data_discovery

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

Самая большая проблема BI
Некоторые скажут, что основная проблема при внедрении BI - это «грязные данные»: дубликаты, пустые и невалидные значения. Другие возразят, что основная боль - отсутствие мастер-данных. Третьи будут доказывать, что без единой методологии расчета KPI внедрять BI бесполезно.
Представьте, что вам надо проанализировать пример из прошлого поста - ежедневную динамику количества уникальных клиентов в разрезе регионов РФ, и у вас есть источник с этими данными. Если там есть какая-то доля «грязных» данных, это не помешает вам посчитать нужные количества. Потом данные можно почистить, но цифры вы уже знаете. Также не помешает отсутствие методологии и мастер-данных - посчитать требуемый показатель вы сможете прямо из источника.
Настоящая проблема - когда требуемая для расчетов информация содержится в двух или более источниках разной детализации (или, как теперь выражаются, гранулярности).
Например, продажи (строки чеков) в кассовой системе записываются много раз в секунду с фиксацией даты-времени, номера чека, номера кассы, кода товара, кода клиента; остатки товаров на полках снимаются в специальном приложении несколько раз в день с детализацией товар-магазин-полка-время; приходы - товар-поставщик-магазин-дата; расчеты с поставщиками в финансовой системе - поставщик-магазин-дата и т.д.
То есть у нас за один и тот же период четыре источника разной детализации:
1. миллиард строк продаж
Дата_Время (сек) - Чек - Касса - Клиент - Товар - Количество - Сумма
2. два миллиарда строк остатков
Дата_Время (час) - Товар - Магазин - Полка - Количество
3. два миллиона строк приходов
Дата - Товар - Поставщик - Магазин - Количество - Сумма
4. миллион строк платежей
Дата - Поставщик - Магазин - Сумма
(В реальности всё гораздо сложнее и запутаннее!)
И если в этой ситуации вы хотите посчитать, например, на сколько дней продаж хватит товара в магазинах, или движение денежных средств, то есть задействовать более одного источника - вам придется как-то склеивать, группировать и агрегировать данные, чтобы ничего не задвоилось и не потерялось.
Это и есть главнейшая проблема любого внедрения и использования BI-систем на практике - объединение источников разной детализации, качества и размера внутри одного расчета. Есть разные оценки, по которым на это уходит не менее 50% времени разработчиков.
И это объективная ситуация - чем больше компания хочет анализировать данные, тем больше у нее систем, тем они детальнее, тем больше уровней грануляции данных - тем больше ресурсов тратится на анализ совокупных данных.
Технология связанных полей Rapeed избавляет клиентов от этой проблемы - полностью и безоговорочно.
#удовольствие_от_аналитики #связанные_поля

Простое решение множества проблем
Связывание полей в Rapeed выглядит и работает крайне просто. Настолько просто, что даже непонятно, как без него обходились раньше. Посмотрите сначала два видео, где я привожу пример связывания двух и трех источников, и продолжим.
#удовольствие_от_аналитики #связанные_поля

#удовольствие_от_аналитики #связанные_поля

#удовольствие_от_аналитики #связанные_поля

Это не JOIN!
И не APPEND, и не UNION. И вообще операция связывания полей не похожа ни на что из того, что вы знаете в SQL.
Это первый новый способ объединения данных за последние 25 лет, после появления CROSS JOIN.
Для связывания полей вам не нужны ключевые поля в таблицах, и вам не надо думать, уникальное это ключевое поле или нет. Здесь нет понятия «один-ко-многим» или «многие-ко-многим». Единственное ограничение - связываемые поля должны быть одного типа: или даты (любого из типов даты-времени), или текст, или double (включая GPS-координаты). Но при этом можно связывать любое количество полей, то есть любое количество источников.
У нас есть пример проекта, когда в качестве источников используются 7 (семь) каталогов Excel-файлов, где объект «организация» называется везде по-разному, «категория» - тоже, и списки организаций и категорий не совпадали, как это обычно и бывает. Что совершенно не помешало связать эти поля во всех источниках, то есть из всех этих полей получилось два набора связей «организация» и «категория», как бы они ни назывались изначально. И пользователи получили сводную информацию по организациями и категориям из всех источников, что раньше было невозможно.
Интересно наблюдать за психологическим эффектом: люди тут же забывают, что данные на самом деле разрозненные, и оперируют показателями, как им удобно. К хорошему быстро привыкаешь.
#удовольствие_от_аналитики #связанные_поля

Динамическое связывание
В связи с большим количеством вопросов про связанные поля, полученных после предыдущих видео, выкладываю еще одно видео. Посмотрите - в нем я сделал упор на то, что это абсолютно легкая процедура, нужная для конкретного расчета, не сложнее ссылки на ячейку Excel.
#удовольствие_от_аналитики #связанные_поля

#удовольствие_от_аналитики #связанные_поля

Что делать с частично перезаписываемыми данными?
У крупных клиентов есть проблема - как правило, данные за последний день (неделю, месяц) много раз перезаписываются. Причин много - много часовых поясов, разные закрытия дня, сторно, возвраты. А анализировать эти меняющиеся данные надо вместе с «фиксированными» данными огромного размера за много месяцев и лет, которые уже не изменятся. На миллиардах строк (тера- и петабайтах) любая перезапись данных в распределенных хранилищах требует большого времени, если вообще возможна.
Что делать?
В Rapeed ответ простой - вы делаете один большой источник данных, который будет только расти, и второй источник данных за тот период, который будет перезаписываться. Связываете соответствующие поля - и готово! При этом, как я писал, детализация данных в этих источниках может быть разной.
Например, 2 последних дня считаем перезаписываемыми, а анализируем информацию за 2 года. Тогда большой источник данных хранит информацию за 2 года минус 2 последних дня («t-2»), и маленький источник - за эти 2 дня. Большой источник обновляется инкрементно раз в день, маленький - полностью перезаписывается несколько раз в день. Связав поля Дата, Товар, товарные группы (или вообще все поля), мы получим эффект полного объединения источников, напоминающий оператор UNION ALL в SQL. Только в Rapeed можно связать не все поля и сделать это динамически, а главное - визуально. На следующем видео я это проиллюстрирую.
Таким образом, связывание полей - более общая операция объединения данных, чем UNION, при этом решающая проблему частичной перезаписи данных внутри огромного массива.
#удовольствие_от_аналитики #связанные_поля

#удовольствие_от_аналитики #связанные_поля

Shared Dimensions в Tableau: идеи носятся в воздухе
24 июня на конференции Tableau Conference была представлена новая функциональность продукта Tableau - Shared Dimensions (общие размерности - здесь и далее перевод мой). По смыслу и по идее это очень сильно повторяет наши связанные поля в Rapeed. Идея заключается в том, чтобы объединять для анализа источники данных разной детализации (да-да, гранулярности), чтобы избежать цифрового взрыва, характерного для SQL-операторов JOIN.
В статье евангелиста Tableau эта технология названа «крупнейшим обновлением со времен запуска продукта в 2005 году». Еще бы, ведь речь идет об объединении источников на основе создания виртуальных общих размерностей! Это прорыв для мирового лидера BI-рынка Tableau, который с гордостью демонстрирует его на датасетах по 100 тысяч записей. Что ж, вы молодцы, но у меня для вас плохие новости:
1. Ваша технология подразумевает создание модели данных, то есть статическую операцию. Наше связывание полей - это динамическая операция, в каждом воркспейсе у пользователя может быть свой набор связанных полей.
2. Отменить Shared Dimensions нельзя, надо удалить для этого схему данных. В Rapeed связать и развязать поля можно одним движением мыши.
3. Создание Shared Dimension - это материальная операция. Для вашего монолитного движка это некоторое, что ли, извращение, или выход за рамки монолита ради решения задачи. Поскольку Rapeed - это распределенный движок, то для него связывание полей - это естественная операция, следующая из его природы, и никакой дополнительной материализации данных в ней нет.
Есть еще 4., 5., 6. и так далее. В целом очевидно, что связь разнородных источников данных - это «горячая» тема для мировых BI-вендоров. Rapeed в этой сфере обладает технологическим преимуществом и заявочным приоритетом, поскольку я показал нашу технологию в действии раньше анонса Tableau.
А пока мы проводим тестирование Rapeed на массиве данных в 9 млрд записей. Процесс увлекательный, но длительный - одна закачка данных съедает 2 суток с лишним. Цель тестирования - вывести формулы оптимального количества нод, воркеров и размера шарда в зависимости от характеристик конкретного процессора и источника данных.
#удовольствие_от_аналитики #связанные_поля

Из разговора с клиентом:
Он: «Я по образованию математик и кибернетик. Но я, хоть убей, не могу понять, как работают ваши связанные поля».
Я: «Поэтому я продаю это просто как чудо».
Ключевое слово здесь - «работают».
#удовольствие_от_аналитики #связанные_поля

Снова в строю
Оф-топ: Спасибо докторам, прежде всего Шавырину Дмитрию Александровичу, за прекрасно проведенную операцию! Скоро на обеих ногах буду неотличим от молодых)

Какой движок у Rapeed?
Многие клиенты просят как-то описать движок Rapeed. Он какой?
Во-первых, он распределенный. Он хранит и обрабатывает данные, разбитые по кусочкам (шардам) на множестве машин (нод).
Во-вторых, он динамический. Нет никаких предрассчитанных агрегатов, всё всегда считается динамически, на лету, на основании потребностей пользователей, возникших прямо сейчас.
А что движок делает с данными?
Он на лету формирует из них многомерные структуры. Особенно это касается операции связывания полей - это (динамическое) создание новой оси в пространстве данных, а затем вычисления по этой и другим осям. Тем, кто изучал тензорную алгебру, это знакомо - это очень напоминает тензорные операции. (Тензор, упрощенно - это многомерная матрица). Поэтому движок Rapeed - это тензорный движок.
На тензорах и тензорных операциях (умножении многомерных матриц весов) основаны любые нейросети и все AI-технологии. Одна из основных AI-библиотек от Google называется TensorFlow - название, думаю, можно не переводить. Отличие тензорного движка Rapeed заключается в том, что он ориентирован на обычные процессоры (CPU), а не GPU, как TensorFlow и прочие библиотеки машинного обучения.
Таким образом, у системы Rapeed распределенный динамический тензорный движок, работающий на обычных процессорах. По-английски - Distributed Dynamic Tensor engine, или DDT-engine. Nice to meet you!
#удовольствие_от_аналитики #dolap