В 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
Простое решение множества проблем
Связывание полей в Rapeed выглядит и работает крайне просто. Настолько просто, что даже непонятно, как без него обходились раньше. Посмотрите сначала два видео, где я привожу пример связывания двух и трех источников, и продолжим.
#удовольствие_от_аналитики #связанные_поля
Связывание полей в Rapeed выглядит и работает крайне просто. Настолько просто, что даже непонятно, как без него обходились раньше. Посмотрите сначала два видео, где я привожу пример связывания двух и трех источников, и продолжим.
#удовольствие_от_аналитики #связанные_поля
Это не JOIN!
И не APPEND, и не UNION. И вообще операция связывания полей не похожа ни на что из того, что вы знаете в SQL.
Это первый новый способ объединения данных за последние 25 лет, после появления CROSS JOIN.
Для связывания полей вам не нужны ключевые поля в таблицах, и вам не надо думать, уникальное это ключевое поле или нет. Здесь нет понятия «один-ко-многим» или «многие-ко-многим». Единственное ограничение - связываемые поля должны быть одного типа: или даты (любого из типов даты-времени), или текст, или double (включая GPS-координаты). Но при этом можно связывать любое количество полей, то есть любое количество источников.
У нас есть пример проекта, когда в качестве источников используются 7 (семь) каталогов Excel-файлов, где объект «организация» называется везде по-разному, «категория» - тоже, и списки организаций и категорий не совпадали, как это обычно и бывает. Что совершенно не помешало связать эти поля во всех источниках, то есть из всех этих полей получилось два набора связей «организация» и «категория», как бы они ни назывались изначально. И пользователи получили сводную информацию по организациями и категориям из всех источников, что раньше было невозможно.
Интересно наблюдать за психологическим эффектом: люди тут же забывают, что данные на самом деле разрозненные, и оперируют показателями, как им удобно. К хорошему быстро привыкаешь.
#удовольствие_от_аналитики #связанные_поля
И не APPEND, и не UNION. И вообще операция связывания полей не похожа ни на что из того, что вы знаете в SQL.
Это первый новый способ объединения данных за последние 25 лет, после появления CROSS JOIN.
Для связывания полей вам не нужны ключевые поля в таблицах, и вам не надо думать, уникальное это ключевое поле или нет. Здесь нет понятия «один-ко-многим» или «многие-ко-многим». Единственное ограничение - связываемые поля должны быть одного типа: или даты (любого из типов даты-времени), или текст, или double (включая GPS-координаты). Но при этом можно связывать любое количество полей, то есть любое количество источников.
У нас есть пример проекта, когда в качестве источников используются 7 (семь) каталогов Excel-файлов, где объект «организация» называется везде по-разному, «категория» - тоже, и списки организаций и категорий не совпадали, как это обычно и бывает. Что совершенно не помешало связать эти поля во всех источниках, то есть из всех этих полей получилось два набора связей «организация» и «категория», как бы они ни назывались изначально. И пользователи получили сводную информацию по организациями и категориям из всех источников, что раньше было невозможно.
Интересно наблюдать за психологическим эффектом: люди тут же забывают, что данные на самом деле разрозненные, и оперируют показателями, как им удобно. К хорошему быстро привыкаешь.
#удовольствие_от_аналитики #связанные_поля
🔥3👍1
Динамическое связывание
В связи с большим количеством вопросов про связанные поля, полученных после предыдущих видео, выкладываю еще одно видео. Посмотрите - в нем я сделал упор на то, что это абсолютно легкая процедура, нужная для конкретного расчета, не сложнее ссылки на ячейку Excel.
#удовольствие_от_аналитики #связанные_поля
В связи с большим количеством вопросов про связанные поля, полученных после предыдущих видео, выкладываю еще одно видео. Посмотрите - в нем я сделал упор на то, что это абсолютно легкая процедура, нужная для конкретного расчета, не сложнее ссылки на ячейку Excel.
#удовольствие_от_аналитики #связанные_поля
Что делать с частично перезаписываемыми данными?
У крупных клиентов есть проблема - как правило, данные за последний день (неделю, месяц) много раз перезаписываются. Причин много - много часовых поясов, разные закрытия дня, сторно, возвраты. А анализировать эти меняющиеся данные надо вместе с «фиксированными» данными огромного размера за много месяцев и лет, которые уже не изменятся. На миллиардах строк (тера- и петабайтах) любая перезапись данных в распределенных хранилищах требует большого времени, если вообще возможна.
Что делать?
В Rapeed ответ простой - вы делаете один большой источник данных, который будет только расти, и второй источник данных за тот период, который будет перезаписываться. Связываете соответствующие поля - и готово! При этом, как я писал, детализация данных в этих источниках может быть разной.
Например, 2 последних дня считаем перезаписываемыми, а анализируем информацию за 2 года. Тогда большой источник данных хранит информацию за 2 года минус 2 последних дня («t-2»), и маленький источник - за эти 2 дня. Большой источник обновляется инкрементно раз в день, маленький - полностью перезаписывается несколько раз в день. Связав поля Дата, Товар, товарные группы (или вообще все поля), мы получим эффект полного объединения источников, напоминающий оператор UNION ALL в SQL. Только в Rapeed можно связать не все поля и сделать это динамически, а главное - визуально. На следующем видео я это проиллюстрирую.
Таким образом, связывание полей - более общая операция объединения данных, чем UNION, при этом решающая проблему частичной перезаписи данных внутри огромного массива.
#удовольствие_от_аналитики #связанные_поля
У крупных клиентов есть проблема - как правило, данные за последний день (неделю, месяц) много раз перезаписываются. Причин много - много часовых поясов, разные закрытия дня, сторно, возвраты. А анализировать эти меняющиеся данные надо вместе с «фиксированными» данными огромного размера за много месяцев и лет, которые уже не изменятся. На миллиардах строк (тера- и петабайтах) любая перезапись данных в распределенных хранилищах требует большого времени, если вообще возможна.
Что делать?
В Rapeed ответ простой - вы делаете один большой источник данных, который будет только расти, и второй источник данных за тот период, который будет перезаписываться. Связываете соответствующие поля - и готово! При этом, как я писал, детализация данных в этих источниках может быть разной.
Например, 2 последних дня считаем перезаписываемыми, а анализируем информацию за 2 года. Тогда большой источник данных хранит информацию за 2 года минус 2 последних дня («t-2»), и маленький источник - за эти 2 дня. Большой источник обновляется инкрементно раз в день, маленький - полностью перезаписывается несколько раз в день. Связав поля Дата, Товар, товарные группы (или вообще все поля), мы получим эффект полного объединения источников, напоминающий оператор UNION ALL в SQL. Только в Rapeed можно связать не все поля и сделать это динамически, а главное - визуально. На следующем видео я это проиллюстрирую.
Таким образом, связывание полей - более общая операция объединения данных, чем UNION, при этом решающая проблему частичной перезаписи данных внутри огромного массива.
#удовольствие_от_аналитики #связанные_поля
👍8
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 суток с лишним. Цель тестирования - вывести формулы оптимального количества нод, воркеров и размера шарда в зависимости от характеристик конкретного процессора и источника данных.
#удовольствие_от_аналитики #связанные_поля
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 суток с лишним. Цель тестирования - вывести формулы оптимального количества нод, воркеров и размера шарда в зависимости от характеристик конкретного процессора и источника данных.
#удовольствие_от_аналитики #связанные_поля
🔥6👍5👏2
Из разговора с клиентом:
Он: «Я по образованию математик и кибернетик. Но я, хоть убей, не могу понять, как работают ваши связанные поля».
Я: «Поэтому я продаю это просто как чудо».
Ключевое слово здесь - «работают».
#удовольствие_от_аналитики #связанные_поля
Он: «Я по образованию математик и кибернетик. Но я, хоть убей, не могу понять, как работают ваши связанные поля».
Я: «Поэтому я продаю это просто как чудо».
Ключевое слово здесь - «работают».
#удовольствие_от_аналитики #связанные_поля
👍8🔥4👏2😁2
Снова в строю
Оф-топ: Спасибо докторам, прежде всего Шавырину Дмитрию Александровичу, за прекрасно проведенную операцию! Скоро на обеих ногах буду неотличим от молодых)
Оф-топ: Спасибо докторам, прежде всего Шавырину Дмитрию Александровичу, за прекрасно проведенную операцию! Скоро на обеих ногах буду неотличим от молодых)
👍10🔥6🙏4❤1
Какой движок у Rapeed?
Многие клиенты просят как-то описать движок Rapeed. Он какой?
Во-первых, он распределенный. Он хранит и обрабатывает данные, разбитые по кусочкам (шардам) на множестве машин (нод).
Во-вторых, он динамический. Нет никаких предрассчитанных агрегатов, всё всегда считается динамически, на лету, на основании потребностей пользователей, возникших прямо сейчас.
А что движок делает с данными?
Он на лету формирует из них многомерные структуры. Особенно это касается операции связывания полей - это (динамическое) создание новой оси в пространстве данных, а затем вычисления по этой и другим осям. Тем, кто изучал тензорную алгебру, это знакомо - это очень напоминает тензорные операции. (Тензор, упрощенно - это многомерная матрица). Поэтому движок Rapeed - это тензорный движок.
На тензорах и тензорных операциях (умножении многомерных матриц весов) основаны любые нейросети и все AI-технологии. Одна из основных AI-библиотек от Google называется TensorFlow - название, думаю, можно не переводить. Отличие тензорного движка Rapeed заключается в том, что он ориентирован на обычные процессоры (CPU), а не GPU, как TensorFlow и прочие библиотеки машинного обучения.
Таким образом, у системы Rapeed распределенный динамический тензорный движок, работающий на обычных процессорах. По-английски - Distributed Dynamic Tensor engine, или DDT-engine. Nice to meet you!
#удовольствие_от_аналитики #dolap
Многие клиенты просят как-то описать движок Rapeed. Он какой?
Во-первых, он распределенный. Он хранит и обрабатывает данные, разбитые по кусочкам (шардам) на множестве машин (нод).
Во-вторых, он динамический. Нет никаких предрассчитанных агрегатов, всё всегда считается динамически, на лету, на основании потребностей пользователей, возникших прямо сейчас.
А что движок делает с данными?
Он на лету формирует из них многомерные структуры. Особенно это касается операции связывания полей - это (динамическое) создание новой оси в пространстве данных, а затем вычисления по этой и другим осям. Тем, кто изучал тензорную алгебру, это знакомо - это очень напоминает тензорные операции. (Тензор, упрощенно - это многомерная матрица). Поэтому движок Rapeed - это тензорный движок.
На тензорах и тензорных операциях (умножении многомерных матриц весов) основаны любые нейросети и все AI-технологии. Одна из основных AI-библиотек от Google называется TensorFlow - название, думаю, можно не переводить. Отличие тензорного движка Rapeed заключается в том, что он ориентирован на обычные процессоры (CPU), а не GPU, как TensorFlow и прочие библиотеки машинного обучения.
Таким образом, у системы Rapeed распределенный динамический тензорный движок, работающий на обычных процессорах. По-английски - Distributed Dynamic Tensor engine, или DDT-engine. Nice to meet you!
#удовольствие_от_аналитики #dolap
👍8🔥5
Аналитика со скоростью мысли
Статей с таким названием выходит много, я тоже в 2015 году в одном из выступлений обозначил свою мечту фразой «миллиард записей в секунду». Сейчас в rapeed мы достигли и превзошли этот показатель. Подробностями хочу поделиться с вами.
На протяжении нескольких месяцев мы занимались оптимизацией и тестированием работы системы на объемах данных от миллиарда записей и выше. Десятки и сотни миллиардов записей - это наш целевой рынок. В организациях с такими объемами данных и источников данных сотни, и пользователей тысячи, об этом напишу отдельно. Пока сосредоточимся на аналитической обработке источника данных объемом в 1 млрд записей.
Под аналитической обработкой я имею в виду расчет сводной таблицы на лету - создание, добавление показателей, добавление полей, раскрытие. Это действия, знакомые любому пользователю Excel и его сводных таблиц. Какое время занимает работа сводной таблицы на миллиарде записей в rapeed?
Первый этап. Источник данных на одном физическом сервере
Мы провели замеры сначала на одном физическом сервере, любезно предоставленном нам провайдером cloud.ru.
На контур с тестами было выделено: один процессор Intel Xeon Gold, 24 ядра, 48 потоков; 512 Гбайт доступной памяти; 10 Тбайт доступного диска.
Источник данных объемом 975 млн записей (природа данных - логи пользователей) в MS SQL Server занимает 310 Гбайт, а в rapeed - 86 Гбайт на диске без потери детализации. Источник под NDA, поэтому видео, к сожалению, прикрепить не могу. Некоторые из подписчиков его видели в частном порядке.
На сервере создано 4 виртуальных машины (ноды), данные распределены между ними поровну по количеству записей.
Расчет сводной таблицы на этой сборке занимает:
⁃ первичная загрузка данных с диска в распределенную память нод - 5-7 секунд
⁃ сам расчет - до 2 секунд
⁃ второй и последующие расчеты происходят моментально, то есть менее 2 секунд.
Менее 2 секунд на миллиарде записей - звучит как воплощение мечты и закрытие 10-летнего гештальта!
Однако всем нашим клиентам с их огромными объемами данных нужна распределенная установка. Поэтому вторым этапом было тестирование скорости работы rapeed на территориально распределенной установке.
(продолжение следует)
#удовольствие_от_аналитики #тесты_rapeed
Статей с таким названием выходит много, я тоже в 2015 году в одном из выступлений обозначил свою мечту фразой «миллиард записей в секунду». Сейчас в rapeed мы достигли и превзошли этот показатель. Подробностями хочу поделиться с вами.
На протяжении нескольких месяцев мы занимались оптимизацией и тестированием работы системы на объемах данных от миллиарда записей и выше. Десятки и сотни миллиардов записей - это наш целевой рынок. В организациях с такими объемами данных и источников данных сотни, и пользователей тысячи, об этом напишу отдельно. Пока сосредоточимся на аналитической обработке источника данных объемом в 1 млрд записей.
Под аналитической обработкой я имею в виду расчет сводной таблицы на лету - создание, добавление показателей, добавление полей, раскрытие. Это действия, знакомые любому пользователю Excel и его сводных таблиц. Какое время занимает работа сводной таблицы на миллиарде записей в rapeed?
Первый этап. Источник данных на одном физическом сервере
Мы провели замеры сначала на одном физическом сервере, любезно предоставленном нам провайдером cloud.ru.
На контур с тестами было выделено: один процессор Intel Xeon Gold, 24 ядра, 48 потоков; 512 Гбайт доступной памяти; 10 Тбайт доступного диска.
Источник данных объемом 975 млн записей (природа данных - логи пользователей) в MS SQL Server занимает 310 Гбайт, а в rapeed - 86 Гбайт на диске без потери детализации. Источник под NDA, поэтому видео, к сожалению, прикрепить не могу. Некоторые из подписчиков его видели в частном порядке.
На сервере создано 4 виртуальных машины (ноды), данные распределены между ними поровну по количеству записей.
Расчет сводной таблицы на этой сборке занимает:
⁃ первичная загрузка данных с диска в распределенную память нод - 5-7 секунд
⁃ сам расчет - до 2 секунд
⁃ второй и последующие расчеты происходят моментально, то есть менее 2 секунд.
Менее 2 секунд на миллиарде записей - звучит как воплощение мечты и закрытие 10-летнего гештальта!
Однако всем нашим клиентам с их огромными объемами данных нужна распределенная установка. Поэтому вторым этапом было тестирование скорости работы rapeed на территориально распределенной установке.
(продолжение следует)
#удовольствие_от_аналитики #тесты_rapeed
👍9🔥4👏3
(продолжение)
Второй этап. Источник данных на двух территориально разнесенных серверах
Первый из этих серверов тот же, что и на первом этапе. Второй сервер находится в Западной Европе, его характеристики очень скромные: Intel Core i7 (16 ядер), на контур выделено 64 Гбайт памяти, место на диске специально расчищали, чтобы половина источника влезла.
Источник данных тот же. Ноды сделали вперемешку между двумя серверами - 1я и 3я на одном, 2я и 4я на другом, вот копия с конфигурационного файла:
Увидев результаты, я специально попросил измерить канал между этими серверами. Прямое копирование файла в 2,8 Гбайт с одного сервера на другой заняло 230 секунд, то есть ширина канала - 98,8 Мбит/сек.
Почему я попросил измерить канал - потому что скорость расчета практически не отличается от первого случая!
⁃ первичная загрузка данных с диска в распределенную память нод - 5-7 секунд
⁃ сам расчет - до 2 секунд
⁃ второй и последующие расчеты происходят моментально, то есть менее 2 секунд.
Проверены все шаги базового сценария тестирования, сценарий был идентичен первому этапу.
Визуально и по ощущениям загрузка с диска и время расчета если и превышает время на первом этапе, то не больше чем на 10%. Точно замерять и сравнивать смысла нет, потому что мощности серверов (и половинок серверов тоже) сильно различаются. Но как первичная загрузка с диска была 5-7 секунд, так и осталась. Особенно удивляет вторичное обращение к расчетам - как оно было в категории «до 2 секунд», так и осталось.
И именно из-за этого факта я испытываю самое большое удивление на грани потрясения. Я ожидал возрастания времени работы в 2 раза. Оно, может, и увеличилось, но максимум на 10%, в пределах погрешности - это при понижении совокупной расчетной мощности в десятки раз, ширины канала обмена данными в 200 раз и географическом разнесении серверов!
Результаты можно объяснить архитектурой системы и тензорной алгеброй. Основные расчеты происходят внутри ноды. Но, чтобы получить уникальный список элементов полей и сагрегировать по всем пересечениям элементов всех полей, неизбежен обмен данными между всеми нодами и несколько шагов промежуточной агрегации. Они происходят и работают правильно, потому что результаты теста идентичны в обоих случаях и верны. И это буквально взрывает мозг.
#удовольствие_от_аналитики #тесты_rapeed
Второй этап. Источник данных на двух территориально разнесенных серверах
Первый из этих серверов тот же, что и на первом этапе. Второй сервер находится в Западной Европе, его характеристики очень скромные: Intel Core i7 (16 ядер), на контур выделено 64 Гбайт памяти, место на диске специально расчищали, чтобы половина источника влезла.
Источник данных тот же. Ноды сделали вперемешку между двумя серверами - 1я и 3я на одном, 2я и 4я на другом, вот копия с конфигурационного файла:
rapeed.master.child0.id = ***01
rapeed.master.child0.address = g****.rapeed.ai:5****
rapeed.master.child1.id = ***02
rapeed.master.child1.address = d****.rapeed.ai:5****
rapeed.master.child2.id = ***03
rapeed.master.child2.address = g****.rapeed.ai:5****
rapeed.master.child3.id = ***04
rapeed.master.child3.address = d****.rapeed.ai:5****
Увидев результаты, я специально попросил измерить канал между этими серверами. Прямое копирование файла в 2,8 Гбайт с одного сервера на другой заняло 230 секунд, то есть ширина канала - 98,8 Мбит/сек.
Почему я попросил измерить канал - потому что скорость расчета практически не отличается от первого случая!
⁃ первичная загрузка данных с диска в распределенную память нод - 5-7 секунд
⁃ сам расчет - до 2 секунд
⁃ второй и последующие расчеты происходят моментально, то есть менее 2 секунд.
Проверены все шаги базового сценария тестирования, сценарий был идентичен первому этапу.
Визуально и по ощущениям загрузка с диска и время расчета если и превышает время на первом этапе, то не больше чем на 10%. Точно замерять и сравнивать смысла нет, потому что мощности серверов (и половинок серверов тоже) сильно различаются. Но как первичная загрузка с диска была 5-7 секунд, так и осталась. Особенно удивляет вторичное обращение к расчетам - как оно было в категории «до 2 секунд», так и осталось.
И именно из-за этого факта я испытываю самое большое удивление на грани потрясения. Я ожидал возрастания времени работы в 2 раза. Оно, может, и увеличилось, но максимум на 10%, в пределах погрешности - это при понижении совокупной расчетной мощности в десятки раз, ширины канала обмена данными в 200 раз и географическом разнесении серверов!
Результаты можно объяснить архитектурой системы и тензорной алгеброй. Основные расчеты происходят внутри ноды. Но, чтобы получить уникальный список элементов полей и сагрегировать по всем пересечениям элементов всех полей, неизбежен обмен данными между всеми нодами и несколько шагов промежуточной агрегации. Они происходят и работают правильно, потому что результаты теста идентичны в обоих случаях и верны. И это буквально взрывает мозг.
#удовольствие_от_аналитики #тесты_rapeed
🔥9👍5👏2
Перейдет ли OLAP на SQL? Или наоборот?
Недавно я написал отзыв на статью Дмитрия Волкова в «Открытых системах», которая посвящена обзору-манифесту технологий работы с данными Майкла Стоунбрейкера и Эндрю Павло. Эти гуру в мире СУБД утверждают, что всё будет SQL и реляционная модель данных, несмотря ни на что - будущее индустрии.
Я уже писал о том, что SQL не обладает гибкостью многомерной модели и не подходит для аналитической работы. Да, классические технологии OLAP (MS OLAP - SSAS, SAP BW, Oracle Essbase - BI) перестали справляться с резко выросшим объемом данных и кажется, что колоночные БД отобрали у них аналитическую функцию на больших объемах. Опыт моих коллег показывает, что, приложив серьезные усилия, предварительно настроив и проиндексировав (!) каждую таблицу, создав промежуточные вьюхи (views) и прочими ухищрениями можно добиться вывода примитивной сводной таблицы из ClickHouse на 1 млрд записей со временем отклика порядка 10 секунд. Фактически каждый экземпляр сводной таблицы из СУБД - это результат кастомной разработки с приличным объемом кода, который надо поддерживать.
При этом в rapeed сводные таблицы, связи, графики и другие виджеты на миллиарде записей вычисляются около 1 секунды и так же быстро перестраиваются, потому что в rapeed распределенный OLAP-движок. В отличие от ClickHouse, здесь не требуется никаких «танцев» с источниками - всё работает прямо из коробки, обеспечивая на порядок бОльшую скорость, функциональность и простоту эксплуатации.
В результате отправки от клиента всего одной API-команды ядро системы сразу возвращает сводную таблицу с несколькими полями слева и сверху, показателями, сортировкой, фильтрацией и количеством записей (в случае графика или индикатора поля указываются только с одной стороны или вовсе отсутствуют). Для человека это гибкость работы и скорость быстрее мысли, для виджета - простота и надежность конструкции.
Поэтому разработчики, продолжающие создавать аналитические системы на реляционной модели, подобны человеку с молотком, которому всё вокруг кажется гвоздями. Однако уже появились технологии, которые лучше взять на вооружение, и за ними будущее аналитической работы с данными.
#удовольствие_от_аналитики #dolap
Недавно я написал отзыв на статью Дмитрия Волкова в «Открытых системах», которая посвящена обзору-манифесту технологий работы с данными Майкла Стоунбрейкера и Эндрю Павло. Эти гуру в мире СУБД утверждают, что всё будет SQL и реляционная модель данных, несмотря ни на что - будущее индустрии.
Я уже писал о том, что SQL не обладает гибкостью многомерной модели и не подходит для аналитической работы. Да, классические технологии OLAP (MS OLAP - SSAS, SAP BW, Oracle Essbase - BI) перестали справляться с резко выросшим объемом данных и кажется, что колоночные БД отобрали у них аналитическую функцию на больших объемах. Опыт моих коллег показывает, что, приложив серьезные усилия, предварительно настроив и проиндексировав (!) каждую таблицу, создав промежуточные вьюхи (views) и прочими ухищрениями можно добиться вывода примитивной сводной таблицы из ClickHouse на 1 млрд записей со временем отклика порядка 10 секунд. Фактически каждый экземпляр сводной таблицы из СУБД - это результат кастомной разработки с приличным объемом кода, который надо поддерживать.
При этом в rapeed сводные таблицы, связи, графики и другие виджеты на миллиарде записей вычисляются около 1 секунды и так же быстро перестраиваются, потому что в rapeed распределенный OLAP-движок. В отличие от ClickHouse, здесь не требуется никаких «танцев» с источниками - всё работает прямо из коробки, обеспечивая на порядок бОльшую скорость, функциональность и простоту эксплуатации.
В результате отправки от клиента всего одной API-команды ядро системы сразу возвращает сводную таблицу с несколькими полями слева и сверху, показателями, сортировкой, фильтрацией и количеством записей (в случае графика или индикатора поля указываются только с одной стороны или вовсе отсутствуют). Для человека это гибкость работы и скорость быстрее мысли, для виджета - простота и надежность конструкции.
Поэтому разработчики, продолжающие создавать аналитические системы на реляционной модели, подобны человеку с молотком, которому всё вокруг кажется гвоздями. Однако уже появились технологии, которые лучше взять на вооружение, и за ними будущее аналитической работы с данными.
#удовольствие_от_аналитики #dolap
👍10🔥5
Перегнать, не обгоняя
В журнале «Открытые системы» №3 за 2024 год вышла моя статья «Перегнать, не обгоняя». Тем, кто читает мой канал, выводы статьи покажутся интересными. А тем, кто недавно присоединился, очень рекомендую прочесть!
#удовольствие_от_аналитики
В журнале «Открытые системы» №3 за 2024 год вышла моя статья «Перегнать, не обгоняя». Тем, кто читает мой канал, выводы статьи покажутся интересными. А тем, кто недавно присоединился, очень рекомендую прочесть!
#удовольствие_от_аналитики
👍8👏2🔥1
Привычки и паттерны мышления. Причем тут SQL и джойны?
Всё использование ИТ-технологий основано на когнитивной психологии - в общем-то, по определению. Механизмы восприятия информации, особенно НОВОЙ информации, которая рушит всё, что человек знал до этого, особо не изменились за последние 10 000 лет. Это вообще моя любимейшая тема - сопротивление мозга и всего естества человека новому, иногда выливающееся в притворство понимания, иногда в грубое хамство и даже ярость.
Последние 2-3 месяца, после выхода rapeed на крейсерскую скорость обработки данных в режиме «миллиарды-строк-в-секунду», я постоянно наблюдаю проблемы восприятия новой технологии у, казалось бы, признанных экспертов в отрасли.
Редко, но встречаются инженеры, которые после просмотра живого видео показа системы сразу понимают, что аналогов этой технологии нет. Цитата: «То что инструмент интересный и уникальный - даже доказывать не требуется» (здесь и далее орфография и пунктуация авторов сохранены).
Основная группа людей (ранга CDO, главного по данным или по технологиям в крупной компании) проходит 5 известных стадий принятия изменений (отрицание - гнев - торг - депрессия - принятие), застревая на какой-то из них.
Отрицание выражается в виде «Вы всё врёти», конечно, завуалированной: «Вы же упираетесь в предел пропускной способности сети и не можете передать 90 Гбайт за 1-2 секунды!» - «Мы не передаем данные по сети». «Посморел презентацию и меня впечатлило то как быстро он джойнит большие массивы данных», хотя никаких джойнов у нас нет. «Вы хотите сказать что обмен внешими ключами между нодами занимает 1-2 секунды?» - «У нас нет обмена внешними ключами!». Самый классный перл был - «Джойны тоже на лету считаются!» Постоянно повторяю - у нас нет SQL, у нас не реляционная модель, у нас не СУБД, у нас нет джойнов, ключей и всего того, к чему все привыкли за 50 лет существования SQL и реляционной модели. Между прочим, люди этого не слышат, даже когда кричу.
Гнев тоже встречается. «Вытащите, пожалуйста, сюда что-нибудь маленькое, а сюда - что-нибудь большое, и какой-нибудь count посчитайте. НУ КАК ЖЕ ТАК??!!! (в голос). Должны же быть предагрегаты!» - «У нас нет никаких предагрегатов». В этом случае, поскольку в результате торга технология продолжила существовать, то затем наступила депрессия, то есть отсутствие принятия каких-либо решений.
Продавать революционную технологию очень сложно, в особенности удалённо. Психологически мы всегда можем «положить трубку» при неудобной информации, которая не вмещается в нашу систему знаний и убеждений. Добиться принятия и использования новой технологии - это серьёзные усилия и время, причём с двух сторон. Тем большее счастье и удовлетворение (по-психологически катарсис) ждет нас в финале. И еще большее - когда технология изменит шаблоны и станет массовой.
#удовольствие_от_аналитики
Всё использование ИТ-технологий основано на когнитивной психологии - в общем-то, по определению. Механизмы восприятия информации, особенно НОВОЙ информации, которая рушит всё, что человек знал до этого, особо не изменились за последние 10 000 лет. Это вообще моя любимейшая тема - сопротивление мозга и всего естества человека новому, иногда выливающееся в притворство понимания, иногда в грубое хамство и даже ярость.
Последние 2-3 месяца, после выхода rapeed на крейсерскую скорость обработки данных в режиме «миллиарды-строк-в-секунду», я постоянно наблюдаю проблемы восприятия новой технологии у, казалось бы, признанных экспертов в отрасли.
Редко, но встречаются инженеры, которые после просмотра живого видео показа системы сразу понимают, что аналогов этой технологии нет. Цитата: «То что инструмент интересный и уникальный - даже доказывать не требуется» (здесь и далее орфография и пунктуация авторов сохранены).
Основная группа людей (ранга CDO, главного по данным или по технологиям в крупной компании) проходит 5 известных стадий принятия изменений (отрицание - гнев - торг - депрессия - принятие), застревая на какой-то из них.
Отрицание выражается в виде «Вы всё врёти», конечно, завуалированной: «Вы же упираетесь в предел пропускной способности сети и не можете передать 90 Гбайт за 1-2 секунды!» - «Мы не передаем данные по сети». «Посморел презентацию и меня впечатлило то как быстро он джойнит большие массивы данных», хотя никаких джойнов у нас нет. «Вы хотите сказать что обмен внешими ключами между нодами занимает 1-2 секунды?» - «У нас нет обмена внешними ключами!». Самый классный перл был - «Джойны тоже на лету считаются!» Постоянно повторяю - у нас нет SQL, у нас не реляционная модель, у нас не СУБД, у нас нет джойнов, ключей и всего того, к чему все привыкли за 50 лет существования SQL и реляционной модели. Между прочим, люди этого не слышат, даже когда кричу.
Гнев тоже встречается. «Вытащите, пожалуйста, сюда что-нибудь маленькое, а сюда - что-нибудь большое, и какой-нибудь count посчитайте. НУ КАК ЖЕ ТАК??!!! (в голос). Должны же быть предагрегаты!» - «У нас нет никаких предагрегатов». В этом случае, поскольку в результате торга технология продолжила существовать, то затем наступила депрессия, то есть отсутствие принятия каких-либо решений.
Продавать революционную технологию очень сложно, в особенности удалённо. Психологически мы всегда можем «положить трубку» при неудобной информации, которая не вмещается в нашу систему знаний и убеждений. Добиться принятия и использования новой технологии - это серьёзные усилия и время, причём с двух сторон. Тем большее счастье и удовлетворение (по-психологически катарсис) ждет нас в финале. И еще большее - когда технология изменит шаблоны и станет массовой.
#удовольствие_от_аналитики
🔥13👍9❤3✍2🥰1👏1
Субботний тост
Если кто-то скажет, что обработать миллиард за секунду невозможно - мы отвечаем «да, поэтому нам понадобилось 5 лет работы и 10 лет предыдущего опыта, чтобы создать эту технологию».
#удовольствие_от_аналитики
Если кто-то скажет, что обработать миллиард за секунду невозможно - мы отвечаем «да, поэтому нам понадобилось 5 лет работы и 10 лет предыдущего опыта, чтобы создать эту технологию».
#удовольствие_от_аналитики
👍9❤3🔥3👏2⚡1