Вас приветствует команда Data Sapience, и в сегодняшней публикации мы расскажем о реализации процедурного расширения для работы с MPP-движками Lakehouse-платформы данных Data Ocean Nova, которое стало доступным для пользователей. В материале пойдет речь о возможностях, применимости и сценариях использования процедурного языка в аналитической платформе данных и примеры реализации решения типовых задач.

В сегодняшней публикации мы попробуем разобраться в производительности популярных MPP-движков в специализированной задаче ХД – предоставлении доступа к денормализованной витрине данных. Также ответим на вопрос: нужен ли ClickHouse в аналитическом ландшафте, спроектированном по принципу Lakehouse-платформ? Для этого будем использовать бенчмарк ClickBench.

ClickBench появился не так давно, в 2022 году. Методика создана и поддерживается командой ClickHouse. Авторы позиционируют его следующим образом -  «Этот бенчмарк представляет типичную рабочую нагрузку в следующих областях: анализ потоков кликов и трафика, веб-аналитика, машинно-генерируемые данные, структурированные журналы и данные о событиях. Он охватывает типичные запросы в ad-hoc аналитике и дашбордах реального времени». Последний сценарий вызывает у нас особый интерес, ведь редко встретишь архитектурный дизайн аналитического ландшафта, где не было бы решения на базе ClickHouse именно для этой цели, на вершине пирамиды тракта данных от источника до потребителя.

Недавно на Хабре вышла статья с громким заголовком «Бенчмарк lakehouse‑движков, часть 1: StarRocks и Doris падают под нагрузкой, Presto аутсайдер, CedrusData быстрее всех». В своей статье авторы из Кверифай Лабс выбрали методику TPC‑DS, но вместо 99 запросов остановилась на одном, который к тому же запускается на одной машине. Обосновывается это тем, что на одном конкретном запросе нужно разобрать работу оптимизаторов. По результатам исследования делается вывод, что решение, разработанное авторами, является лучшим, в том числе для запуска одного конкретного запроса на одном узле. Давайте попробуем разобраться, действительно ли это так.

В сегодняшней, уже третьей по счету, публикации я продолжу делится результатами нагрузочных испытаний вычислительных технологий массивных параллельных вычислений (на Habr уже представлены мои материалы, посвященные сравнению Impala, Trino и Greenplum, в том числе по методике TPC-DS). В этот раз в список решений добавляется Spark, включая работающий с технологией нативных вычислений DataFusion Comet, и набирающий популярность StarRocks.

Не так давно в блоге компании Arenadata был опубликован материал тестирования поведения различных распределенных файловых систем при работе с маленькими файлами (~2 Мб). Краткий вывод: по результатам проверки оказалось, что лучше всего с задачей маленьких файлов справляется старый-добрый HDFS, деградируя в 1.5 раза, S3 на базе minIO не тянет, замедляясь в 8 раз, S3 API над Ozone деградирует в 4 раза, а наиболее предпочтительной системой в при работе с мелкими файлами, по утверждению коллег, является Greenplum, в том числе для компаний «экзабайтного клуба». Коллеги также выполнили огромную работу по поиску «Теоретических подтверждений неожиданных показателей».  

Результаты тестирования в части S3 minIO показались нашей команде неубедительными, и мы предположили, что они могут быть связаны с:

• недостаточным практическим опытом эксплуатации SQL compute over S3 и S3 в целом;

• отсутствием опыта работы с кластерами minIO. В частности в высоконагруженном продуктивном окружении на 200+ Тб сжатых колоночных данных Iceberg/parquet, особенно в сценариях, где проблема маленьких файлов быстро становится актуальной.

• особенностями сборок дистрибутивов;

Мы благодарны коллегам за идею и вдохновение провести аналогичное тестирование. Давайте разбираться.

Привет! Сегодня я продолжаю тему сравнения систем и движков массивных параллельных вычислений. В прошлой публикации я раскрыл основные принципы проведения тестирования, которыми руководствуется наша команда, и привел результаты как реальных промышленных сценариев, так и синтетических тестов. Материал вызвал интерес и дискуссию: значит, он актуальный и полезный. Для кого-то факты стали убедительными, а кто-то усомнился в объективности результатов, поэтому, как и было обещано, я делюсь материалами сравнительного тестирования, выполненного по общепринятому стандарту TPC-DS. Сегодня вы узнаете, повлияла ли смена методики на результаты.

Наполнение данными хранилища или озера, как правило, является первым большим шагом к доступности аналитической среды для основного функционала и работы конечных пользователей. От эффективной реализации этой задачи зависят стоимость и длительность всего проекта по созданию хранилища данных и сроки предоставления отдельных data-сервисов.

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

Успешные тестирование производительности и нагрузочные испытания – важнейшие условия для выбора аналитической системы массивной обработки больших данных. В этой публикации я хочу поделиться подходами к тестированию, которые используются нашей командой как в проектной работе, так и при разработке Lakehouse-платформы данных Data Ocean Nova, и познакомить вас с результатами сравнения различных движков и систем. Вы узнаете, как правильно ставить цели, выбирать методику и из каких сценариев ее нужно составлять, как протоколировать результаты и делать выводы. И самое главное – получите ответ на вопросы: кто быстрее: заяц Trino или антилопа Impala?

Привет. Меня зовут Евгений Вилков. Я занимаюсь системами управления и интеграции данных с 2002 г., а конкретно системами анализа и обработки данных — с 2007 г. Технологии, с которыми я имел дело на протяжении моего профессионального пути, стремительно развивались. Начиная с решений, основанных на стеке традиционных СУБД, таких как Oracle, MS SQL Server, Postgres, постепенно эволюционируя в ставшие уже классическими (а некоторые даже и закрытыми) MPP-системы, такие как Teradata, GreenPlum, Netezza, Vertica, IQ, HANA, Exadata, ClickHouse, в различные решения на базе экосистемы Hadoop, облачные сервисы и платформы. Меняется мир, меняются технологии, меняются подходы к проектированию, меняются и требования к задачам аналитического ландшафта данных.

Уверен, что многие, кто уже знаком с терминами Data Mesh и Data Lakehouse, задаются вопросом: что может предложить рынок аналитических систем в этих методологиях проектирования и архитектурных подходах. Я хочу рассказать об аналитической платформе данных Data Ocean Nova, владельцем и технологическим идеологом которой я являюсь.

Наши коллеги из группы компаний ГлоуБайт не так давно публиковали достаточно развернутый материал по графовой аналитике, в котором содержится базовая теория и приведены области практического применения. В этой статье мы бы хотели поделиться опытом проектирования данного класса систем, какие специализированные движки используем, какую типовую архитектуру применяем и как к ней пришли.

В предыдущей статье я поделился нашим опытом создания аналитического хранилища полного цикла на базе экосистемы Hadoop. Одним из тезисов той статьи стало утверждение о том, что аналитическую систему можно спроектировать, не прибегая к федерализации разных технологических платформ, предназначенных для решения локальных задач.

В этом материале я попробую подробнее раскрыть, как в нашей системе реализован подход обработки и загрузки данных в реальном времени с использованием технологии Kudu, при котором эти данные сразу доступны для анализа.

Привет.

В конце прошлого года GlowByte и Газпромбанк сделали большой совместный доклад на конференции Big Data Days, посвященный созданию современного аналитического хранилища данных на базе экосистемы Cloudera Hadoop. В статье мы детальнее расскажем об опыте построения системы, о сложностях и вызовах с которыми пришлось столкнуться и преодолеть и о тех успехах и результатах, которых мы достигли.