SQL *

Недавно у меня возникла задача по разбиению мульти-терабайтной таблицы на равные диапазоны по числовому полю 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 — добро пожаловать под кат :)

Привет, Хабр! Делимся переводом статьи о патче, сделанном разработчиком «Тантор Лабс» для 19 версии PostgreSQL — по сути, частичкой вклада нашей компании. Благодаря коммиту Ильи Евдокимова, в PostgreSQL 19 планирование JOIN’ов станет до 16 раз быстрее. Если раньше алгоритм сравнения частых значений (MCV) работал за O(N²), и при target=10k само планирование запроса могло занимать десятки миллисекунд, то теперь вместо квадратичного перебора будет использоваться хеш-таблица, а это снижает сложность до O(N). Изменение особенно оценят те, кто работает с неравномерными данными и поднимает default_statistics_target выше 1000.

Подробный разбор с тестами и графиками — в переводе статьи о нашем патче.

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

Подход Инмона обещал «единый источник истины» в корпоративном хранилище — и обернулся бюрократией и запредельной стоимостью любого изменения. Подход Кимбалла дал скорость за счет удобных витрин, но ценой стали хаос, дублирование и информационные «силосы». Data Vault 2.0 — гибкий, аудируемый и мощный — без автоматизации превратился в проклятие для многих команд. И, наконец, Data Mesh: отличная организационная модель, которая дала командам автономию. Каждый домен сам владеет данными, сам отвечает за качество, сам развивается.

Но Data Mesh оставил открытым главный вопрос: как заставить всех этих независимых владельцев данных говорить на одном языке? Команды получили свободу, но работают на общей инфраструктуре, единой платформе с ее хранилищами, ETL-процессами, каталогами. И эта платформа осталась прежней: ждет команд от инженеров, требует ручного вмешательства, не умеет сама связывать данные из разных доменов. Дали командам независимость, но забыли дать им общий «мозг».

А что, если изменить непосредственно природу платформы данных? Сделать ее не пассивным набором инструментов, а системой, которая сама понимает данные, сама связывает домены, сама управляет качеством и развивается вместе с бизнесом?

Про концепцию такой платформы мы и хотим рассказать. Мы назвали ее AIDA (Adaptive Intelligence Data Architecture).

В эпоху урбанизации, когда мегаполисы и региональные центры России растут как на дрожжах, вопрос доступности социальной инфраструктуры выходит на первый план. Родители, ищущие ближайший детский сад для своего малыша, урбанисты, планирующие новые жилые кварталы, или городские власти, стремящиеся оптимизировать транспортную сеть, — все они сталкиваются с одной и той же проблемой: как быстро и точно оценить, насколько "дружественен" город к пешеходам? Сколько минут пешком до ближайшей школы? А до игровой площадки? Эти вопросы, кажущиеся простыми, на деле требуют сложных расчетов, анализа геоданных и визуализации, которая была бы интуитивно понятной.

Именно здесь на сцену выходит Георейтинг — инновационный проект, разработанный командой Геоинтеллект. Это мощный инструмент анализа, который превращает абстрактные данные о расстояниях в живые, наглядные инсайты. Запущенный недавно, Георейтинг уже вызывает интерес среди специалистов и обычных пользователей, обещая стать незаменимым помощником в повседневной жизни. 

Города растут, районы меняются, а людям по-прежнему нужно простое и честное понимание: удобно здесь жить или нет?

До сих пор такую оценку каждый делал сам: «вроде недалеко», «дойти можно», «там есть садик, но как далеко?». Георейтинг убирает эти догадки: теперь доступность района — это цифры и визуализация.

Кому это нужно?

Привет! Меня зовут Дима Кривопальцев, я тимлид бэкенд‑команды Яндекс Диска (Яндекс 360). Уже больше семи лет я занимаюсь разработкой высоконагруженных распределённых систем — и в статье расскажу об одной из них.

В Яндекс 360 есть сервисы с очень большими нагрузками — и по RPS, и по объёму хранимых данных, и по числу обрабатываемых асинхронных задач. Именно последняя часть — асинхронная обработка — будет в центре этого рассказа.

Тема может показаться немного провокационной: речь пойдёт об очередях поверх SQL‑баз, а в сообществе такое решение принято считать антипаттерном — и на это есть основания. На конференциях и в статьях обычно можно услышать скепсис: «Очередь на PostgreSQL? Не стоит даже пытаться». Действительно, подобных попыток было много, и почти все сталкивались с типовыми проблемами — от блокировок до деградации производительности.

Тем не менее, в реальности у многих крупных компаний всё равно есть свои очереди, построенные поверх SQL‑баз — как PostgreSQL, так и MySQL. Это решение встречается и в российских, и в зарубежных командах. Яндекс Диск здесь не исключение — у нас тоже есть своя реализация, о которой сегодня и пойдёт речь.