Таблицы для аналитиков в 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 млн: запрос не менялся, вырос объём. В статье это собрано в лабораторию, повторяемую на своём стеке.