Вместе с коллегами мы проанализировали, в какую сторону будет направлен вектор развития искусственного интеллекта в наступившем году. Особенное внимание уделили IT-инфраструктуре, организации корпоративной среды и будущему AI-агентов.

В российских проектах НСИ часто выходит далеко за рамки справочников и включает задачи MDM и Data Quality. Разбираемся, чем это отличается от классического RDM и к чему это приводит.

Привет! Сегодня на связи команда вендора Data Sapience, а именно Spark-разработчик Виталий Мартынов и технические лидеры направления разработки Apache Spark платформы Data Ocean Nova Дмитрий Паршин и Евгений Морозов.

Концепция Lakehouse активно продвигается как «золотая середина» между Data Lake и Data Warehouse: она обещает объединить гибкость хранения данных, расширенную аналитику и соблюдение транзакционности в единой архитектуре с использованием современных табличных открытых форматов, таких как Iceberg (который уже де-факто стал общепринятым стандартом при построении Data Lakehouse). И сегодня мы хотим посвятить статью разбору следующего вопроса: почему без использования Spark нельзя построить полноценный Lakehouse? 

Поговорим о том, какую роль Spark играет в Lakehouse-подходе, какие задачи он закрывает успешнее других, о его тесной взаимосвязи с Iceberg и том, почему альтернативы часто не дотягивают до нужного уровня универсальности, масштабируемости и надежности в рамках большой продуктивной среды. Также расскажем, почему мы в Data Ocean Nova используем Spark в качестве движка для обслуживания Iceberg-таблиц и инструмента для миграции данных в Lakehouse.

Привет, Хабр. Меня зовут Василий Мельник, я product owner решения для потоковой обработки данных Data Ocean SDI в компании Data Sapience. Наша команда приобрела большой практический опыт работы с Apache Iceberg в задачах на стыке традиционной пакетной обработки и near real-time и конкретно с использованием технологий на базе Flink, поэтому мы не могли пройти мимо нового открытого табличного формата (OTF) Paimon от разработчиков Apache Flink. В этой статье я опишу наш опыт и те практические выводы, которые мы сделали на промышленных средах, в виде репрезентативного тестирования, на котором проиллюстрирую ключевые практические сценарии.

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

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

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

Привет, Хабр! На связи — технические лидеры направления разработки Apache Spark в составе платформы Data Ocean Андрей Первушин и Дмитрий Паршин из Data Sapience. Мы занимаемся решением нетривиальных задач в области Spark-вычислений, некоторые из которых становятся частью конечного продукта.

Сегодня мы расскажем, с какими проблемами можно столкнуться при реализации Upsert Streaming в Iceberg, что такое equality delete, почему они создают нагрузку при чтении таблиц в Apache Iceberg и как мы оптимизировали Apache Spark, чтобы снизить потребление памяти и ускорить чтение данных.

Недавно на Хабре вышла статья с громким заголовком «Бенчмарк 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, особенно в сценариях, где проблема маленьких файлов быстро становится актуальной.

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

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

Обычно Java‑агенты используются для сбора телеметрии, логирования, профилирования, каких‑то ультрабыстрых хотфиксов и прочих скучных вещей.

Но сегодня мы исследуем приложение Java‑агент, которое модифицирует код другого Java‑приложения «на лету» и создано для обхода лицензионных ограничений. Называть его мы будем «агент», «вредоносный агент» и т. п.

Меня зовут Сергей Капустин, тимлид бэкэнд-команды продукта Data Ocean Cluster Manager вендора Data Sapience.

Код в нашем примере будет максимально обезличен.

Эта тема рассматривается исключительно в целях исследования вопросов безопасности приложений и этичного использования инструментов изменения кода во время компиляции.

В конце я предложу примеры методов отслеживания несанкционированного вмешательства в Java‑приложение, а также методов противодействия, чтобы избавиться от рисков, которые мы обнаружим в процессе исследования.

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

Путь к современному MDM на примере клиентского домена данных

Привет, Хабр! На связи команда российского вендора Data Sapience. Наши специалисты в течение многих лет занимались внедрением и адаптацией различных ИТ-решений, в том числе MDM-систем: как российских, так и зарубежных. Объединив накопленные знания, мы выпустили собственный высокопроизводительный мультидоменный продукт Data Ocean Governance MDM. 

Data Sapience стремилась сделать Data Ocean Governance MDM гибким, комфортным и производительным решением, поэтому внимательно изучала рынок и его потребности. Сегодня хотим поделиться с вами результатами анализа и порассуждать, зачем MDM-решения нужны современному бизнесу, какую роль они выполняют и какие задачи закрывают на примере клиентского домена данных.

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

Привет, меня зовут Сергей, старший разработчик 80 уровня компании DataBlend (группа компаний GlowByte). Наша команда занимается разработкой продукта ClusterManager, который управляет поведением и мониторит состояния таких продуктов, как GreenPlum, ClickHouse, DWH, Nova и т. д.

Около полутора лет назад у нас появилась необходимость собирать и отображать в удобном виде и разрезах метрики и данные об объектах кластеров Kubernetes, в которых развернут продукт Nova.

Для этих целей был выбран официальный kubernetes‑client для Java.

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

Лучше всего для этой цели подходит механизм информеров kubernetes‑client.

И сейчас мы посмотрим, с какой стороны их лучше начинать есть.