Типовые сценарии на базе StarRocks + DeepSeek. DeepSeek: генерация качественных эмбеддингов и ответов, StarRocks: высокоэффективный векторный поиск и хранение.Вместе они образуют основу для точных и масштабируемых AI‑решений.
В статье разберем, как синхронизировать данные из Oracle, MySQL, SQL Server, PostgreSQL, Kafka и MongoDB в StarRocks. Сравним Flink+CDC+SMT, DataX, Routine Load и Python по применимости, ограничениям и удобству эксплуатации, а также дадим рекомендации по выбору под разные сценарии.
В статье — пошаговый разбор создания и обновления материализованных представлений (MV) в StarRocks: от парсинга SQL (ANTLR) и инициализации свойств до сериализации метаданных (edit log, checkpoint, image) и планирования refresh. Разбираем синхронизацию партиций (range‑партиционирование), параметр partition_refresh_number и оптимизацию обновлений. Отдельный блок — поддержка нескольких выражений в UNION ALL и механизм VirtualPartitions из PR #60035, позволяющий корректно обновлять сдвинутые временными функциями (date_add/date_sub) диапазоны без пропусков. Материал будет полезен инженерам данных и тем, кто проектирует OLAP‑модели и MV под высокую нагрузку.
Материализованные представления (MV) в StarRocks — это не просто кэш агрегатов, а полноценный механизм ускорения запросов с автоматическим переписыванием (query rewrite). На практических примерах разбираем, как движок сопоставляет поддеревья плана запроса со SPJG‑MV, как работают join/aggregate/nested/union rewrite, как обеспечивается строгая согласованность и настраиваемая устарелость данных (staleness), и за счёт чего достигается ускорение на SSB и TPC‑H.
Недавно у меня возникла задача по разбиению мульти-терабайтной таблицы на равные диапазоны по числовому полю id. Причём данные распределены по id крайне неравномерно, где-то есть большие "лакуны", где-то непоследовательная генерация и т.д., и т.п. Конечно, можно применить честное решение в лоб — использовать функцию NTILE, но я довольно быстро осознал, что это приведёт к многочасовому запросу с большой вероятностью упасть из-за недостатка TEMP. Но, к счастью, зачастую в таких задачах, как и в моём случае, идеальное разделение на диапазоны не требуется, достаточно более-менее приличного.
Я решил провернуть небольшой трюк для получения приблизительного разделения. Давайте посмотрим, что у меня получилось на модельном примере.
Осторожно, спойлеры! Не читайте, пока хотите решить задачу самостоятельно.
В этой челлендж-серии статей, начатой с прошлогоднего эвента, попробуем использовать PostgreSQL как среду для решения задач Advent of Code 2025.
Возможно, SQL не самый подходящий для этого язык, зато мы рассмотрим его различные возможности, о которых вы могли и не подозревать.
В современных data-процессах ключевую роль играет обеспечение качества данных. Рассмотрим четыре популярных подхода: DBT, SQL, Python (Pandas/SQLAlchemy) и Great Expectations, оценив их эффективность для различных сценариев проверки данных.
Эта статья будет интересна и полезна Data-инженерам, аналитикам данных и специалистам Data Quality для выбора оптимального метода валидации данных в зависимости от стека технологий и сложности бизнес-логики. Материал ориентирован на начинающий уровень подготовки: тем, кто еще не сталкивался системно с инструментами управления качеством данных.
Привет, Хабр! Меня зовут Мария, я Data-инженер в SimbirSoft, и предлагаю для начала немного познакомиться с каждым из вышеперечисленных инструментов.
Хотелось бы сразу сделать небольшой дисклеймер. Это не супер‑экспертная статья. Скажем так — это мой инсайд о том, как еще можно работать с SQL запросами в Go проекте. В этой статье я расскажу о том как удобно хранить запросы в embeded sql файлах. Решение о котором я буду писать — лишь один из инструментов в арсенале разработчика, а не универсальное решение призванное вылечить все болезни. Надеюсь тебе это будет полезно.
Всем привет, меня зовут Игорь Горбенко, и я системный аналитик в компании М2.
Отчёты, которые обновляются раз в сутки, хорошо подходят для стратегической аналитики. Но в какой-то момент бизнесу становится важно понимать, что происходит в течение дня, а не только по итогам ночной загрузки.
В М2 мы столкнулись с этим, когда от продуктовых команд и службы поддержки начали приходить запросы на внутридневную отчётность и почти real-time метрики. Наш основной подход — ежедневная батчевая загрузка данных — перестал закрывать такие сценарии, и нам понадобился другой способ работы с изменениями в продуктовых базах.
В этой статье я расскажу, как мы внедряли Change Data Capture (CDC) с использованием Apache Flink, какие задачи это помогло решить, с какими ограничениями мы столкнулись и почему CDC — полезный, но не универсальный инструмент.
CDC и Apache Flink: кратко о технологии и нашем подходе
Давайте начнем разбираться. Некоторые из вас наверняка знакомы с понятием CDC, Change Data Capture — техника захвата изменений в базах данных.
Для контекста стоит отметить Apache Flink — движок для загрузки и обработки батчей и стриминговых данных в реальном времени. В статье речь пойдет про Flink CDC — фреймворк с открытым исходным кодом для отслеживания изменений данных в базах данных в реальном времени.
В проектах нашего отдела в М2 основной метод загрузки — это ежедневное ночное
копирование продуктовых баз данных (PostgreSQL, MongoDB) в аналитическое хранилище на базе Apache Iceberg и последующая их обработка с помощью движка Trino.
На SQL-собеседованиях интервьюер часто формулирует условия устно, просит рассуждать вслух и быстро писать запрос в реальном времени. Это непривычный формат — и именно поэтому он становится испытанием даже для тех, кто много практиковался.
Введение: почему запросы вдруг тормозят?
Представьте ситуацию: вчера приложение работало нормально, сегодня получили звонок – «Сайт грузит 10 секунд!». Заглядываете в логи, видите, что SQL-запрос выполняется 8 секунд вместо обычных 0.2 секунды. Но база данных, таблицы – всё то же самое. Что изменилось?
Дело в том, что PostgreSQL Query Planner – оптимизатор запросов – принимает решения на основе статистики. Когда статистика устаревает или таблица растёт в 10 раз, планировщик может выбрать неэффективный план выполнения. Например, вместо быстрого Index Scan он выберет медленный Seq Scan всей таблицы. Это не баг – это следствие неправильной информации о данных.
Статья полезна:
- Новичкам в SQL: разберётесь, как работают запросы
- Разработчикам на Symfony/Doctrine, Go с pgx: увидите интеграцию с вашим кодом
- Опытным DBA: найдёте оптимизации для таблиц в миллионы строк
Не требуется: специального опыта. Нужны базовые знания SQL и доступ к PostgreSQL.
Осторожно, спойлеры! Не читайте, пока хотите решить задачу самостоятельно.
В этой челлендж-серии статей, начатой с прошлогоднего эвента, попробуем использовать PostgreSQL как среду для решения задач Advent of Code 2025.
Возможно, SQL не самый подходящий для этого язык, зато мы рассмотрим его различные возможности, о которых вы могли и не подозревать.
Мы забыли вовремя создать партиции, и все новые данные полетели в events_default_partition. Default дорос до ~1.1 ТБ, а простое «ATTACH PARTITION» требовало часов сканирования и долгой блокировки. В статье — почему «быстрые» рецепты оказываются медленными, как я перенёс данные в нужные диапазоны, и как мы уложили критическую блокировку в 44 с.
Default-партиция — это не озеро Байкал. Если туда всё сливать, экосистема потом мстит.
Искусственный интеллект резко ворвался в нашу жизнь. Для кого-то это возможность смотреть или генерировать прикольные и не очень картинки и видео, которые многим уже надоели.
А для нас, коллеги, это мощный инструмент, позволяющий быстрее решать различные задачи. Многие кто уже успел попробовать Cursor и подобные инструменты, восхищаются как ИИ способен писать код.
В этой статье речь пойдёт о менее заезженной, но не менее актуальной теме – как ИИ уже сейчас помогает проектировать базы данных.
Всем привет! Меня зовут Александр Гаврилов, я архитектор баз данных и аналитических систем в GRI. Если вы когда-нибудь пытались выполнить одну и ту же операцию с похожими таблицами в разных базах, да ещё и на разных серверах, то знаете, насколько это может быть мучительно.
В этой статье я покажу один из рабочих вариантов, как упростить такую задачу, и заодно расскажу про интересную функцию XQuery, которая может неожиданно помочь.
Многие команды сейчас меняют проприетарное ПО на открытые аналоги. Под «открытостью» мы понимаем не только миграцию с платного софта на бесплатный, но и новый подход к построению data-платформ, где каждый продукт развивает свой сегмент платформы с помощью релевантного стека технологий.
Полноценных open-source-альтернатив, которые закрыли бы все наши потребности, не нашлось. Поэтому мы решили создать свой «мультитул» — low-code-фреймворк для генерации гетерогенных Airflow DAG с незамысловатым названием dag_generator.
Цель этой статьи — поделиться опытом внедрения подобного инструмента. Генерация выполняется по старинке, так что про ИИ здесь пока ничего не найдете.
Привет, Хабр!
Мы много работаем с компаниями, которым необходимо использовать отечественное ПО для баз данных. В таких проектах часто уже есть инфраструктура на MS SQL Server, PostgreSQL или Oracle Database. Основной конфликт — требования регуляторов и высокая стоимость миграции логики приложений на другую СУБД.
Мы создали продукт, который нативно понимает диалекты и позволяет работать с существующими базами без переписывания кода. В статье расскажем, как развернуть Digital Q.DataBase для начала работы с базами без долгой и затратной миграции.
Мухи — отдельно, котлеты — отдельно. Отделяем Go-код от SQL-запросов. Зачем это делать и как?Личный опыт миграции большого проекта на новую СУБД показал: смешивание SQL с кодом приложения создаёт проблемы. Представляю простую библиотеку SQLSet для хранения именованных SQL-запросов в отдельных файлах.
Осторожно, спойлеры! Не читайте, пока хотите решить задачу самостоятельно.
В этой челлендж-серии статей, начатой с прошлогоднего эвента, попробуем использовать PostgreSQL как среду для решения задач Advent of Code 2025.
Возможно, SQL не самый подходящий для этого язык, зато мы рассмотрим его различные возможности, о которых вы могли и не подозревать.
Power BI и язык DAX являются удобными инструментами аналитиков. В DAX важно учитывать гранулярность — уровень детализации, который зависит от текущего контекста фильтров и группировки.
Мы привыкли работать с гранулярностью, и если в транзакционной системе проблемы с гранулярностью могут быть относительно незаметны, то в BI системах проблемы гранулярности сразу влияют на дашборды. Это усугубляется поведением движков BI систем, в которых гранулярность таблицы считается динамически в зависимости от выражения — как в Power BI.
При использовании некоторых функций, например, REMOVEFILTERS, снижение гранулярности может приводить к интуитивно непонятным результатам и считаться плохой практикой. Интересующимся особенностями снижения гранулярности на примере REMOVEFILTERS — добро пожаловать под кат :)
