Как структура данных диктует стиль кода в SQL и pandas

В аналитике часто кажется, что выбор между оконной функцией и GROUP BY — дело случая. Но исследование решений реальных задач показывает чёткую закономерность: тип данных предопределяет преобладающие конструкции.

Временные ряды и задачи типа «самый высокий результат за день» почти всегда приводят к оконным функциям (RANK, LAG). Когда метрика собирается из нескольких таблиц (факты и измерения) — доминируют JOIN + GROUP BY. Задачи на исключения («кто никогда не совершал действие») — это анти-джойны (NOT EXISTS или ~isin). В pandas аналогично: .merge() появляется там, где нужно скомбинировать данные, а .groupby() — на следующем шаге.

Понимание этих паттернов позволяет не гадать, а сразу выбирать нужный инструмент, ускоряя написание и отладку кода. Подробности в статье: https://www.kdnuggets.com/visualizing-patterns-in-solutions-how-data-structure-affects-coding-style

Таблицы для аналитиков в 2026-м: Яндекс 360, Р7 и Google Sheets

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

В полном разборе сравниваются три актуальных варианта по форматам, совместной работе, ИИ-ассистентам и интеграциям с аналитическим стеком (BigQuery, gspread, API). Удобно, что авторы свели всё в одну таблицу сравнения.

Читать полный разбор.

Обновление PostgreSQL остановит ваш CDC-пайплайн на wal2json, если не поправить конфиг

13 августа вышли PostgreSQL 18.6, 17.11, 16.15, 15.19 и 14.24: они закрывают CVE-2026-6471 (7,2 балла из 10 по шкале опасности). Аккаунт с атрибутом REPLICATION мог передать в CREATE_REPLICATION_SLOT любой путь к библиотеке, а сервер загружал её и выполнял код от имени пользователя ОС. Ошибке 12 лет: она с самого появления логического декодирования в 9.4.

Закрыли белым списком: параметр output_plugin_libraries, по умолчанию pgoutput и test_decoding. Любой другой плагин вывода, включая wal2json и decoderbufs, после обновления получает отказ, и декодирование не стартует, пока библиотеку не впишут в список и не перечитают конфиг.

Атрибут REPLICATION висит на бэкапах, standby, мониторинге и CDC. Проверьте plugin в pg_replication_slots до апдейта и допишите его в параметр тем же окном обслуживания.

Офсетный лаг не скажет, насколько старые данные лежат в вашем озере

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

В Twilio для пайплайнов на Apache Hudi Delta Streamer лаг считают во времени, не трогая продюсеров и консьюмеров: берут последний коммит Hudi в S3, достают из него чекпоинт Kafka, перематывают топик на этот офсет и вычитают время сообщения из текущего.

Грабли: в последнем коммите чекпоинта может не быть, если его сделал параллельный легаси-пайплайн. Тогда алгоритм идёт по истории коммитов назад, до ближайшего с метаданными.

Офсетный мониторинг это не отменяет: он ловит зависшего консьюмера, а time in queue даёт возраст данных и порог свежести с алертами на каждый пайплайн. Разбор на 5 трлн записей в месяц у InfoQ.

Трассировки OpenTelemetry можно свернуть в метрику, которая показывает, какой SQL чинить первым

Запрос, вчера укладывавшийся в десятки миллисекунд, сегодня держит витрину минуту, а в трассировках десятки тысяч спанов, и по ним не видно, что просело.

Разбор на блоге CNCF предлагает не копить телеметрию, а сворачивать спаны БД в метрики: у спана есть длительность и текст запроса, по нормализованному тексту считается агрегат, и вместо потока событий выходит ряд для дашборда и алерта.

Метрика закрывает два вопроса. Оптимизация: ускорение какого запроса даст больше всего, если взвесить длительность на частоту вызовов. Инцидент: какой запрос отклонился от собственной нормы прямо сейчас.

SELECT по orders без индекса на customer_id отдаёт 20 мс на 10 тыс. строк и минуты на 10 млн: запрос не менялся, вырос объём. В статье это собрано в лабораторию, повторяемую на своём стеке.

Q4 не сходится, а человек, который писал пайплайн, уволился два года назад

Знакомый маршрут: grep по ETL-скриптам, обход внешних ключей, вью, которая ссылается на другую вью, а та на таблицу, которую когда-то переименовали. Через час вопросов больше, чем ответов.

Задача называется происхождением данных: откуда пришло значение, что от него зависит, через какие преобразования оно прошло и что сломается, если тронуть источник. dbt и Airflow отвечают на это в границах своего графа, а то, что собирается внутри базы, остаётся серым пятном.

Отвечать приходится не только финансистам. SOX требует разбирать квартальный отчёт по шагам, GDPR — объяснять логику обработки данных, а BCBS 239 появился, когда регуляторы устали слышать от банков, что источник цифр риска не установить.

В блоге Cybertec разбирают, что на этот вопрос отвечает PostgreSQL 19.

SQL-запрос доезжает до хранилища набором ключей, и от их формата зависит, будет чтение по ключу или скан

Когда план запроса в TiDB или CockroachDB показывает скан, на уровне SQL это уже не объяснить: раскладывает таблицы и строки по парам «ключ-значение» слой ниже, и обычно его не видно.

В шестой части серии про учебную базу SaarDB автор пишет этот слой руками: движок хранения у него умеет только ключи и строковые значения, про таблицы и типы колонок он не знает. По шагам:
• почему CREATE TABLE и INSERT сводятся к одной операции PUT;
• зачем схема таблицы уезжает под служебный ключ с префиксом _schema:;
• как уложить структуру со списком колонок и их типами в значение, которое всегда строка;
• как из строки собрать ключ, по которому её потом найдут.

Свою базу писать не обязательно: понимание, во что превращается таблица в хранилище, объясняет цену предиката не по ключевой колонке.

Подзапрос в списке колонок пересчитывается для каждой строки витрины

Витрина собирается минутами, а в плане Postgres висит узел SubPlan. Внутри max(amount) из payments по payments.user_id = users.id, и он выполняется отдельно для каждой строки внешнего запроса: на 10 млн пользователей это 10 млн обращений к payments.

В WHERE так почти не бывает: IN и EXISTS планировщик обычно разворачивает в semi join и проходит payments один раз. Цену задаёт место, где стоит подзапрос, а сами виды подзапросов разбирают на freeCodeCamp.

Лечится агрегатом в CTE: сгруппировать payments по user_id один раз и приджойнить LEFT JOIN, тогда вместо SubPlan появится HashAggregate. В Spark план смотреть отдельно: там коррелированные подзапросы допускаются не везде.

Прогоните EXPLAIN по медленным витринам и поищите SubPlan: в списке колонок его стоит переписывать, под фильтром он обычно уже развёрнут в join.

SQL от ассистента выполнился без ошибок, но число в отчёте завышено

Запрос пишется за десять секунд и сразу отрабатывает, а база проверила в нём только грамматику. Опечатку в имени таблицы она поймает; сумму не по тому столбцу, задвоение строк после join и фильтр, поставленный после группировки, пропустит. Это валидный SQL с неверным числом.

Типовой случай: выручка за вычетом возвратов как SUM(o.amount) - SUM(COALESCE(r.refund_amount, 0)) с LEFT JOIN из orders в refunds. Если возврат по заказу оформлен двумя платежами, заказ превращается в две строки, и его amount уходит в сумму дважды.

Самая дешёвая проверка: до SUM выполнить COUNT(*) с тем же join и сверить с числом строк до соединения. Не совпало, значит join размножает строки, и возвраты надо свернуть подзапросом, а присоединять уже готовую сумму.

Ещё четыре проверки, от фильтров до знаменателя, разобраны в статье на dev.to.

Пятнадцать минут простоя ClickHouse не должны стоить вам пропущенных событий

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

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

В разборе пайплайна для аналитики свопов Solana показана вторая половина: схема таблицы solana_swaps в ClickHouse и то, как один поток разводится на историческую аналитику и на живую отдачу в WebSocket.

А чем вы прикрываете аналитическую базу на время миграций?

9 млрд генетических изменений собрали в карту на 1 ПБ

Для каждого возможного односимвольного изменения в геноме человека уже рассчитан прогноз влияния на молекулярные процессы. В AlphaGenome Atlas лежат 9 млрд таких прогнозов, которые можно быстро запрашивать без повторного расчёта модели.

Чтобы не перебирать тысячи показателей, индекс влияния варианта AVI объединяет прогнозы для кодирующих и некодирующих участков ДНК. На данных 54 000+ участников UK Biobank группировка по ожидаемому молекулярному эффекту помогла найти на 22% больше связей в некодирующих участках.

Для ML-практика здесь полезен сам паттерн: массовый предварительный расчёт, единая оценка и быстрый отбор кандидатов для дальнейшего исследования.

Полезная ML-модель может затеряться в соседнем домене

Эмбеддинги Netflix, созданные для студийных процессов, находят границы сцен, визуальные переходы и структуру видео. Эти числовые представления контента потенциально пригодились бы рекламе для подбора объявления под контекст, а рекомендательной системе — для сопоставления темы или настроения эпизода с интересами зрителя.

Переиспользованию мешает видимость. У доменов разные стеки, бизнес-метрики и оргструктуры; без инфраструктуры поиска наработки превращаются в чёрные ящики, недоступные другим ML-командам.

В Netflix TechBlog разбирают, зачем компании понадобился граф жизненного цикла моделей. Для своей ML-платформы стоит проверить: найдёт ли соседняя команда подходящую модель до того, как обучит свою?

Единый API может убрать маршрутизацию моделей из ваших микросервисов

Запросу рекомендательной системы мало попасть в модель: нужно выбрать нужную версию, экземпляр и шард кластера с учётом пользователя и сценария. При этом клиентскому сервису не обязательно знать устройство платформы инференса.

В Netflix эту границу провели через единый доменно-независимый API. Платформа сама направляет трафик к нужному экземпляру модели и шарду. По данным за 2025 год, так она обслуживала сотни типов и версий моделей и 1 млн запросов в секунду. Архитектуру подробнее разбирают в Netflix TechBlog.

Для своей платформы полезно разделить ответственность так же: доменный сервис знает единый контракт, а платформа выбирает тип и версию модели, экземпляр и шард. Тогда исследователи могут быстрее выпускать новые версии, не раскрывая сервисам детали маршрутизации.

Redshift сводит SQL-запросы к хранилищу и озеру данных в один движок

Таблицы хранилища и файлы в озере данных теперь можно запрашивать через один SQL-движок Redshift. Новые инстансы RG на AWS Graviton обрабатывают нагрузки хранилища до 2,2 раза быстрее RA3, а цена одного виртуального процессорного ядра у них на 30% ниже.

Встроенный движок выполняет SQL-запросы сразу по хранилищу и озеру. По данным Amazon Web Services, на данных Apache Iceberg ускорение относительно RA3 достигает 2,4 раза, на Apache Parquet — 1,5 раза. Это рассчитано в том числе на поток запросов от ИИ-агентов.

Для выбора размера есть прямые пары: вместо ra3.xlplus предлагается rg.xlarge с 4 виртуальными ядрами и 32 ГБ памяти, вместо ra3.4xlarge — rg.4xlarge с 16 ядрами и 128 ГБ. Перед миграцией стоит прогнать собственные SQL-нагрузки: все показатели AWS заявлены как «до».