Data Engineering *

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

Привет, Хабр. Меня зовут Алексей Белозерский. Я руководитель профессионального сервиса VK Data Platform, VK Tech. В этой статье я расскажу, что стало предпосылкой появления нового формата данных и что скрывает Iceberg «под толщей воды».

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

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

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

История моделей данных  — это не строгое следование хронологии, а путь нарастания сложности для решения всё более трудных задач. Чтобы понять, почему появились сложные модели, нужно начать с самой простой и интуитивно понятной из них. Это проведет нас от базовых структур к комплексным, позволит осознанно выбирать инструмент, понимая все предпосылки и компромиссы.

«Широкие» таблицы

Путь поиска баланса между простотой, производительностью и гибкостью начинался с «широких» (их также называют «плоских») таблиц, где вся информация хранится в единой структуре. Это была эпоха простоты: достаточно одного запроса — и все двести атрибутов пользователя оказывались у вас в руках. Процесс извлечения данных был быстрым и интуитивно понятным, поскольку обходился без сложных соединений и подзапросов.

Однако у этой простоты обнаружилась обратная сторона — избыточность. Представьте, что данные о сотрудниках и их работодателях хранятся в одной таблице. Если компания меняет название, то необходимо обновлять каждую запись, которая связана с изменяемой информацией. Это не только расточительно с точки зрения хранения, но и чревато аномалиями в данных. Также при увеличении количества данных в «широких плоских» таблицах возрастает и риск нарушения консистентности информации.

Задача: быстро выполнять агрегирующие запросы (JOIN, GROUP BY, COUNT) по десяткам миллионов строк в офлайновых сценариях на Big Data‑платформе. Мы сравнили три подхода: Parquet + Impala в экосистеме CDH, MPP‑движок Greenplum и MPP‑СУБД StarRocks. В единой тестовой среде (SAD ~7 млн, ITEM ~3 млн записей) выполнили серию запросов JOIN + GROUP BY + ORDER BY и замерили суммарное время 10 прогонов. Показано, что внедрение MPP заметно ускоряет аналитику (типично 1–2 с на запрос), при этом StarRocks в среднем немного обходит Greenplum. В статье — методика, параметры развертывания, нюансы импорта из Oracle (CloudCanal) и сводные метрики.

ClickHouse — одна из самых популярных систем для анализа данных. По информации TheirStack, этот инструмент использует более 3 700 компаний по всему миру. 

У ClickHouse быстрая аналитика, эффективное сжатие и отличное масштабирование. Но у системы есть и недостатки — ограниченная поддержка UPDATE и DELETE, а также сложная миграция.

Привет, Хабр! Меня зовут Михаил Филимонов, я руковожу разработкой хранилища данных в группе Магнит OMNI. В этой статье я расскажу о проблемах работы с ClickHouse, как их решать и какие инструменты для этого потребуются. 

Близкая планета вызывает вспышки на звезде (Close-in planet induces flares on its host star)Authors: Ekaterina Ilin et al.Comments: 23 pages, 7 figures, 3 tables. Submitted to Nature 

Наблюдения на TESS и CHEOPS показали, что у молодого G-карлика HIP 67522, вокруг которого обращаются две планеты на низких орбитах, происходят вспышки, вызванные магнитным взаимодействием с одной из планет.

Вертикальная структура и динамика диска Галактики (Vertical Structure and Dynamics of a Galactic Disk)Authors: Chanda J. Jog Comments: 223 pages, 35 figures, 379 references. Invited review for Physics Reports  Большой обзор по структуре и физике галактического диска. На удивление мало формул (с полсотни, и больше половины из них - в 4м разделе), зато много полезных графиков. Приведено много данных наблюдений и разъяснены основные процессы, отвечающие за формирование структуры диска.

Привет, Хабр! Мы — команда DATA ОАТС в билайн. В этой статье расскажем о кейсе, когда стандартный Spark JDBC не справился с параллельным чтением огромной таблицы из ClickHouse, и мы написали свой «мини-движок». Под катом — разбор ограничений, схема с пулом потоков на экзекуторах и опыт, который может пригодиться не только для ClickHouse.

Сравнение ClickHouse и StarRocks: архитектура и функциональность, типы join и модели данных (широкая таблица vs звезда), конкурентность, частые обновления (Primary Key, Merge‑on‑Read), администрирование и онлайн‑масштабирование. Приводим результаты бенчмарков SSB и TPC‑H, а также тесты загрузки (GitHub dataset). Все тестовые данные и конфигурации актуальны на 2022 год. Если вам интересно, воспроизведите эксперименты по актуальным инструкциям проектов и поделитесь результатами и замечаниями — это поможет уточнить выводы и обновить сравнение.

Говоря о серьезных кластерах в компаниях, нам часто приходится взаимодействовать со сторонними отделами и их данными. И зачастую, когда речь идет об ad-hoc, самый эффективный инструмент - Trino. Он удобен тем, что в платформе данных можно добавить каталог, который позволит по сути избежать настройки коннекшена для конечного пользователя. Просто в запросе указываешь название каталога данных и трино сам понимает, что нужно взять данные со сторонней базы данных. Но все меняется, когда выразительности SQL нам перестает хватать для выполнения поставленных задач и мы переходим в Spark. Точнее, менялось. С релизом Spark 3.0 появилась возможность взаимодействовать с внешними источниками так же просто, как в Trino.

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

В этой статье мы детально рассмотрим поведение аналитических движков при выполнении отдельного TPC-DS запроса на одном узле.

Это глубоко технический текст, в котором мы увидим, как (1) три родственных движка (Impala, StarRocks и Doris) с трудом справляются с конкурентной нагрузкой, (2) разработчики StarRocks и Doris затачивают дефолты своих движков под бенчмарки, (3) Trino реализует эффективный шедулер запросов, но имеет ряд дефектов, ухудшающих производительность, (4) Presto строит хорошие планы запросов, но демонстрирует катастрофически плохую производительность из-за отсутствия буквально одной фичи. Ну а победит, конечно, наш движок CedrusData.

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

Современные языковые модели (LLM) вроде GPT, LLaMA или Mistral обладают поразительной универсальностью. Они обучены на триллионах токенов из открытых источников и научились объяснять сложные вещи, поддерживать диалог в свободной форме и даже писать код. Однако при решении реальных бизнес-задач универсальность становится слабым местом: бизнесу нужны не «всезнающие ассистенты», а узкоспециализированные инструменты, хорошо понимающие внутренние процессы и терминологию.

В гонке за следующей волной «умных» систем большие языковые модели (LLM) берут на себя неожиданные роли. Одна из самых интересных — использовать такие модели как «судей» для оценки других моделей. Подход уже экономит командам массу ручной работы, но остаются вопросы: способен ли LLM уловить каждую тонкую ошибку? Что происходит в ситуациях, где критичны человеческая интуиция или глубокая предметная экспертиза?

Реальность такова: человеческие ревьюеры по-прежнему обеспечивают уровень контекстного понимания, которому ИИ пока не соответствует. Поэтому вместо того чтобы противопоставлять методы, многие в индустрии приходят к связке «LLM-судья + человеческая оценка» как к наиболее эффективной комбинации. В этой статье разберём, что такое LLM-судья, как он соотносится с человеческой оценкой и почему гибридный подход имеет наибольший смысл.

При пиковых нагрузках отчётные и аналитические системы сталкиваются с лавиной схожих агрегирующих запросов: растёт загрузка CPU и увеличиваются задержки. В StarRocks эту проблему решает Query Cache — кэширование промежуточных результатов агрегаций в памяти с их последующим переиспользованием. В реальных сценариях даёт 3–17× ускорение, работает для семантически эквивалентных запросов, перекрывающихся партиций и append-only данных. Внутри — лучшие практики, пример настройки и метрики диагностики.

Выпуск 448

Пределы космологии (The limits of cosmology)Authors: Joseph SilkComments: 23 pages, Gen Relativ Gravit 57, 127 (2025) 

Если вы думаете, что известный космолог-теоретик пишет про теорию, то вы ошибаетесь! Силк внезапно втопил за лунные проекты. И это не только низкочастотные радионаблюдения на другой стороне Луны, но и совершенно фантастические (очень дорого и сложно) проекты гравитационно-волновых детекторов (типа LIGO, Virgo) на Луне (там низкий сейсмический шум, и можно уйти на низкие частоты).

Радиопроекты могут быть реализованы в середине этого века. Гравволновые - точно нет. Но интересно, что Силк погружает все это в интересный и понятно описанный контекст космологических задач (отсюда и название статьи). Так что читать все равно интересно. Вот это и впрямь научная фантастика!

А еще… затронем ИИ и прочие захватывающие темы.

Эта статья - пример того как можно с помощью публичных Python библиотек обогатить тестовый датасет новыми внешними полезными данными и значимо улучшить качество ML модели.

Представьте инженера по добыче на центральном объекте в Permian Basin (прим.перев. крупнейший нефтегазовый бассейн США), которому до рассвета нужно успеть десятки дел. Одна скважина работает ниже нормы. Для другой нужно принять решение о капитальном ремонте. Данные разбросаны по электронным таблицам, SAP, PDF‑документам и полевым логам. Знакомая ситуация? А теперь представьте, что у инженера есть помощник, который читает все файлы по скважинам, анализирует сигналы SCADA, понимает исторические тенденции добычи, проверяет наличие запчастей на складе, формирует рекомендацию и отправляет краткий отчет руководителю операций — ещё до второй чашки кофе.

В современных реалиях всё чаще встаёт вопрос о переходе с вендорских продуктов на open-source. Компании активно рассматривают DBT как стандарт для управления трансформациями данных, но сталкиваются с проблемами: существующие алгоритмы загрузки оказываются недостаточными, а адаптеры для СУБД - устаревшими.

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