Это не 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
Миллиардом за секунду тут и не пахнет..
Мы решили провести тесты работы rapeed на трёх недорогих серверах. Это даже не серверы, а мощные десктопы.
Машины такие (везде SSD-диски 1,92 Тбайт):
1) AMD Ryzen 9 7950X3D, 192 Гбайт памяти,
2) Intel Core i9-13900, 128 Гбайт памяти,
3) Intel Core i9-13900, 64 Гбайт памяти.
Забегая вперед - те, кто не верил в обработку миллиарда строк за секунду, оказались правы. Результаты оказались совсем не те, которые мы ожидали.
Конфигурация из 6 нод на этих 3х серверах оказалась быстрее, чем размещение этих же 6 нод на одном мощном сервере с двумя Xeon Gold и 1 Тбайт памяти. Если учитывать время первичной загрузки данных с диска, то расчеты стали быстрее на 17-22% в зависимости от плотности (отношения количества уникальных значений поля к количеству строк) поля и его размера. В среднем это время стало 5,6 сек, а было 7,1 сек.
Сами расчеты в памяти ускорились в десятки раз. На одном сервере расчеты составляли чуть больше 1 секунды, на 3х десктопах расчет сводной таблицы из миллиарда записей занимает 50-60 миллисекунд! В следующем видео я привел пример расчета сводной таблицы с нуля, где можно увидеть реальное время получения данных из ядра системы.
Да, rapeed не обрабатывает миллиард записей за секунду. Он обрабатывает миллиард записей за 0,05 секунды! И чем больше недорогих ресурсов ему доступно, тем быстрее он работает и тем бОльшие объемы данных обрабатывает.
#удовольствие_от_аналитики #тесты_rapeed
Мы решили провести тесты работы rapeed на трёх недорогих серверах. Это даже не серверы, а мощные десктопы.
Машины такие (везде SSD-диски 1,92 Тбайт):
1) AMD Ryzen 9 7950X3D, 192 Гбайт памяти,
2) Intel Core i9-13900, 128 Гбайт памяти,
3) Intel Core i9-13900, 64 Гбайт памяти.
Забегая вперед - те, кто не верил в обработку миллиарда строк за секунду, оказались правы. Результаты оказались совсем не те, которые мы ожидали.
Конфигурация из 6 нод на этих 3х серверах оказалась быстрее, чем размещение этих же 6 нод на одном мощном сервере с двумя Xeon Gold и 1 Тбайт памяти. Если учитывать время первичной загрузки данных с диска, то расчеты стали быстрее на 17-22% в зависимости от плотности (отношения количества уникальных значений поля к количеству строк) поля и его размера. В среднем это время стало 5,6 сек, а было 7,1 сек.
Сами расчеты в памяти ускорились в десятки раз. На одном сервере расчеты составляли чуть больше 1 секунды, на 3х десктопах расчет сводной таблицы из миллиарда записей занимает 50-60 миллисекунд! В следующем видео я привел пример расчета сводной таблицы с нуля, где можно увидеть реальное время получения данных из ядра системы.
Да, rapeed не обрабатывает миллиард записей за секунду. Он обрабатывает миллиард записей за 0,05 секунды! И чем больше недорогих ресурсов ему доступно, тем быстрее он работает и тем бОльшие объемы данных обрабатывает.
#удовольствие_от_аналитики #тесты_rapeed
👍15🔥5👏2✍1
Достаточно 12 Гбайт
Что будет, если увеличить число нод в 2 раза на тех же серверах? Мы решили попробовать и сравнить скорость работы системы. Каждой ноде выделили по 12 Гбайт оперативной памяти. Всего получилось 12 нод, по 4 ноды на сервер, и 144 Гбайт распределенной памяти на источник размером в 1 млрд записей.
Как видно на следующем видео, скорость работы системы осталась такой же, как в случае с 2 нодами на сервер - каждый расчет занимает 30-55 миллисекунд. Специально для тех, кто еще сомневается в том, что это настоящая скорость работы rapeed, в видео я создаю новый показатель, считающий число уникальных объектов (count distinct), и работаю с ним в сводной таблице.
Живая скорость работы системы - в видео.
#удовольствие_от_аналитики #тесты_rapeed
Что будет, если увеличить число нод в 2 раза на тех же серверах? Мы решили попробовать и сравнить скорость работы системы. Каждой ноде выделили по 12 Гбайт оперативной памяти. Всего получилось 12 нод, по 4 ноды на сервер, и 144 Гбайт распределенной памяти на источник размером в 1 млрд записей.
Как видно на следующем видео, скорость работы системы осталась такой же, как в случае с 2 нодами на сервер - каждый расчет занимает 30-55 миллисекунд. Специально для тех, кто еще сомневается в том, что это настоящая скорость работы rapeed, в видео я создаю новый показатель, считающий число уникальных объектов (count distinct), и работаю с ним в сводной таблице.
Живая скорость работы системы - в видео.
#удовольствие_от_аналитики #тесты_rapeed
👍7🔥3
Незыблемые законы тестирования и правило из Рататуя
Я тестировал очень много систем за свои 28 лет в ИТ - начиная с UNIX-систем на DB/2 для мейнфреймов, SCALA, ConcordeXAL и Axapta, Sybase ASE (теперь MS SQL Server) и Sybase IQ (теперь SAP HANA), SalesLogix, Oracle DB и Essbase, MS SQL Server и MS OLAP, Tableau, SiSence, другие аналитические продукты, не говоря уже о продуктах моей разработки. Например, мы проходили аудированные тесты производительности Полиматики в Швейцарии с привлечением американцев. После этого еще доводилось промышленные системы (MES) пощупать на предмет наработки на отказ.
И везде, всегда, в 100% случаев при нагрузочном тестировании соблюдаются следующие 2 закона (их может быть и больше, но эти два - точно и всегда):
1. При увеличении объема данных время их обработки растёт.
2. При увеличении количества пользователей задержка в ответе (N+100)-му пользователю увеличивается по сравнению с первым, вторым, … N-ным пользователем.
По какому закону растут 1. и 2. - линейно, квадратично, логарифмически… - зависит от конкретной системы, но они растут всегда.
Но: «Одно нужно знать наверняка - ничего нельзя знать наверняка», как говорится в любимом мультфильме моих детей «Рататуй».
С высоты всего моего опыта мне приходится признать, что есть одна система, которая плевать хотела на эти законы.
Сначала был повержен первый закон. Выше я приводил результаты тестов, где видно, что при росте объема данных время обработки в rapeed не растет - как было меньше секунды, так и осталось. Для системы, похоже, чем распределённее инсталляция, тем она быстрее работает.
При этом многие клиенты интересуются, как rapeed справляется с большим количеством пользователей на один сервер. Может, это он только для одного пользователя так? А для сотен одновременно работающих пользователей будут критические задержки?
Мы решили проэмулировать работу 300 пользователей с одним контуром rapeed и одной точкой входа - master-нодой.
Были взяты те же серверы и источник «Чеки» размером 365 млн записей. Вопрос, на который должен был ответить тест, такой: как изменяется время отклика платформы для 301-го пользователя в сравнении с откликом для 1-го пользователя?
Ответ: никак не меняется.
Я уже свыкся с этим фактом после восьмого запуска и того, что я «переспал» с результатами. В следующем посте я подробно опишу сценарий теста, выложу аналитику и графики и - для желающих - сводный файл результатов.
#удовольствие_от_аналитики #тесты_rapeed
Я тестировал очень много систем за свои 28 лет в ИТ - начиная с UNIX-систем на DB/2 для мейнфреймов, SCALA, ConcordeXAL и Axapta, Sybase ASE (теперь MS SQL Server) и Sybase IQ (теперь SAP HANA), SalesLogix, Oracle DB и Essbase, MS SQL Server и MS OLAP, Tableau, SiSence, другие аналитические продукты, не говоря уже о продуктах моей разработки. Например, мы проходили аудированные тесты производительности Полиматики в Швейцарии с привлечением американцев. После этого еще доводилось промышленные системы (MES) пощупать на предмет наработки на отказ.
И везде, всегда, в 100% случаев при нагрузочном тестировании соблюдаются следующие 2 закона (их может быть и больше, но эти два - точно и всегда):
1. При увеличении объема данных время их обработки растёт.
2. При увеличении количества пользователей задержка в ответе (N+100)-му пользователю увеличивается по сравнению с первым, вторым, … N-ным пользователем.
По какому закону растут 1. и 2. - линейно, квадратично, логарифмически… - зависит от конкретной системы, но они растут всегда.
Но: «Одно нужно знать наверняка - ничего нельзя знать наверняка», как говорится в любимом мультфильме моих детей «Рататуй».
С высоты всего моего опыта мне приходится признать, что есть одна система, которая плевать хотела на эти законы.
Сначала был повержен первый закон. Выше я приводил результаты тестов, где видно, что при росте объема данных время обработки в rapeed не растет - как было меньше секунды, так и осталось. Для системы, похоже, чем распределённее инсталляция, тем она быстрее работает.
При этом многие клиенты интересуются, как rapeed справляется с большим количеством пользователей на один сервер. Может, это он только для одного пользователя так? А для сотен одновременно работающих пользователей будут критические задержки?
Мы решили проэмулировать работу 300 пользователей с одним контуром rapeed и одной точкой входа - master-нодой.
Были взяты те же серверы и источник «Чеки» размером 365 млн записей. Вопрос, на который должен был ответить тест, такой: как изменяется время отклика платформы для 301-го пользователя в сравнении с откликом для 1-го пользователя?
Ответ: никак не меняется.
Я уже свыкся с этим фактом после восьмого запуска и того, что я «переспал» с результатами. В следующем посте я подробно опишу сценарий теста, выложу аналитику и графики и - для желающих - сводный файл результатов.
#удовольствие_от_аналитики #тесты_rapeed
👍7🔥2👏2
Тесты производительности rapeed на 300 пользователях
Как говорилось выше, мы решили проэмулировать работу 300 пользователей с одним контуром rapeed и одной точкой входа - master-нодой.
Был взят распределенный контур из 3х серверов и источник «Чеки» размером 365 440 448 записей.
Для каждого из 300 пользователей выполнялись следующие действия:
0. Авторизация (в результаты не вошла)
1. Создание таблицы из одной колонки: слева поле name_group_level3, показатель Сумма (quantity). Без сортировки.
2. Открытие состава поля (get_elements) по полю name_group_level2
3. Создание таблицы с левым полем name_group_level3, верхним полем name_group_level2 с сортировкой по показателю по убыванию для каждого столбца (перебор столбцов для сортировки распределен случайным образом между пользователями)
4. Открытие состава поля (get_elements) по полю short_name - код магазина
5. Создание таблицы с левым полем short_name, вторым (вложенным) левым полем name_wares (название товара) с раскрытием по первому элементу поля short_name, фильтр по price_segment = Премиум, с сортировкой по показателю по убыванию
6. Открытие состава поля (get_elements) по полю short_name и по полю name_group_level2
7. Создание таблицы с верхним полем name_group_level2, левым полем short_name, вторым левым полем name_wares с последовательным раскрытием по первому элементу поля short_name для каждого столбца, фильтр по price_segment = Эконом, с сортировкой по показателю по убыванию для каждого столбца.
Пользователи перебираются последовательно. По какому столбцу делается сортировка в п.3, раскрытие в п.5 и раскрытие и сортировка в п.7, определяется случайно и равномерно распределяется между пользователями.
Последовательность тестов повторяется после небольшой паузы. Итого сделано 4200 запросов от пользователей (300 пользователей * 7 действий * 2 повтора) и получено 4200 ответов. Ошибочных ответов нет.
Параллельно снималась нагрузка на сервера - использование совокупного CPU в %, объем памяти и обмен по сети.
Ниже выложен сводный файл запросов и ответов в формате XLSX, а также график распределения времени отклика от количества запросов в секунду, график среднего времени отклика по пользователям и динамика среднего времени отклика по времени.
Всё время теста занимает 1 минуту. То есть распределенный кластер из трёх десктопов обработал 4200 аналитических запросов в минуту без ошибок со средним временем отклика 0,3 секунды.
Повторю вывод: время отклика системы на запрос пользователя при многопользовательской работе остается стабильным и не меняется.
#удовольствие_от_аналитики #тесты_rapeed
Как говорилось выше, мы решили проэмулировать работу 300 пользователей с одним контуром rapeed и одной точкой входа - master-нодой.
Был взят распределенный контур из 3х серверов и источник «Чеки» размером 365 440 448 записей.
Для каждого из 300 пользователей выполнялись следующие действия:
0. Авторизация (в результаты не вошла)
1. Создание таблицы из одной колонки: слева поле name_group_level3, показатель Сумма (quantity). Без сортировки.
2. Открытие состава поля (get_elements) по полю name_group_level2
3. Создание таблицы с левым полем name_group_level3, верхним полем name_group_level2 с сортировкой по показателю по убыванию для каждого столбца (перебор столбцов для сортировки распределен случайным образом между пользователями)
4. Открытие состава поля (get_elements) по полю short_name - код магазина
5. Создание таблицы с левым полем short_name, вторым (вложенным) левым полем name_wares (название товара) с раскрытием по первому элементу поля short_name, фильтр по price_segment = Премиум, с сортировкой по показателю по убыванию
6. Открытие состава поля (get_elements) по полю short_name и по полю name_group_level2
7. Создание таблицы с верхним полем name_group_level2, левым полем short_name, вторым левым полем name_wares с последовательным раскрытием по первому элементу поля short_name для каждого столбца, фильтр по price_segment = Эконом, с сортировкой по показателю по убыванию для каждого столбца.
Пользователи перебираются последовательно. По какому столбцу делается сортировка в п.3, раскрытие в п.5 и раскрытие и сортировка в п.7, определяется случайно и равномерно распределяется между пользователями.
Последовательность тестов повторяется после небольшой паузы. Итого сделано 4200 запросов от пользователей (300 пользователей * 7 действий * 2 повтора) и получено 4200 ответов. Ошибочных ответов нет.
Параллельно снималась нагрузка на сервера - использование совокупного CPU в %, объем памяти и обмен по сети.
Ниже выложен сводный файл запросов и ответов в формате XLSX, а также график распределения времени отклика от количества запросов в секунду, график среднего времени отклика по пользователям и динамика среднего времени отклика по времени.
Всё время теста занимает 1 минуту. То есть распределенный кластер из трёх десктопов обработал 4200 аналитических запросов в минуту без ошибок со средним временем отклика 0,3 секунды.
Повторю вывод: время отклика системы на запрос пользователя при многопользовательской работе остается стабильным и не меняется.
#удовольствие_от_аналитики #тесты_rapeed
👍6🔥3👏2