Телеграм канал «Data Analysis / Big Data»

DuckDB File Storage Inspection показывает блоки базы и содержимое WAL

Размер файла базы вырос, но из таблиц непонятно, что занимает место? DuckDB File Storage Inspection показывает физическую раскладку: заголовки, метаданные, группы строк, сегменты колонок, свободные и индексные блоки.

Файл подключается в режиме чтения через DuckDB-Wasm и разбирается по блокам. Загружать всю базу в память сразу не требуется.

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

Инструмент помогает изучать повреждённые файлы, но не восстанавливает их. В README указана проверка формата DuckDB 1.5.5; зашифрованные базы не поддерживаются.

Код автора доступен на GitHub. При выборе через браузер передайте файл базы и его WAL вместе, чтобы увидеть обе части.

#duckdb #хранениеданных #диагностика

Нативный .NET-клиент ClickHouse передаёт данные блоками колонок

ClickHouse обрабатывает данные по колонкам, но при обмене через построчный RowBinary сервер и клиент тратят работу на смену представления.

В новом TCP-клиенте для .NET используется Native-формат: по сети идут блоки колонок. Значения фиксированной длины можно читать пачкой, а не разбирать по одному полю каждой строки.

При этом выбор интерфейса влияет на аллокации. Работа с колонками позволяет избежать создания объекта на каждую строку. При преобразовании в обычные объекты эта стоимость возвращается.

Клиент входит в ClickHouse.Driver, но пока экспериментальный и выдаёт предупреждение CHTCP0001. Поддержка DbConnection для работы через ADO.NET ещё в планах.

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

#clickhouse #dotnet #производительность

Flink CDC 3.7 проверяет схему существующей таблицы перед записью

Источник добавил колонку, а целевая таблица уже создана с прежней схемой. Для CDC-конвейера важно заранее определить, как обрабатывать такое расхождение.

В Flink CDC 3.7.0 приёмники Paimon и Fluss получили режимы CHECK, TRY_EXPAND и EXPAND. Они позволяют проверять существующую схему и, в зависимости от режима, добавлять или расширять типы неключевых колонок перед записью.

Эта возможность относится именно к указанным приёмникам: переносить её поведение на любой коннектор Flink CDC нельзя.

В релизе также появился Pipeline-коннектор для SQL Server с инкрементальным чтением снимка и синхронизацией изменений схемы.

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

#flink #cdc #dataengineering

Aurora PostgreSQL объединяет данные базы и Iceberg одним запросом

Последние операции лежат в PostgreSQL, многолетняя история — в S3. Для совместного запроса теперь можно обойтись без предварительной загрузки всей истории в операционную базу.

В Aurora PostgreSQL встроили DuckDB: расширение aurora_analytics читает Iceberg и Parquet через внешние таблицы. Дальше их можно объединять с обычными таблицами SQL-запросами.

Движок применяет фильтры и отбор колонок при чтении, а часто используемые данные кеширует. Аналитические запросы можно направлять на читающую реплику.

Нужны Aurora PostgreSQL 17.11+ или 18.6+, расширение и IAM-роль с доступом к данным. Это возможность Aurora, не обычного PostgreSQL.

Отдельной платы за функцию нет, но вычисления Aurora и запросы к S3 оплачиваются. Нагрузку и объём чтения стоит измерить до переноса регулярных отчётов.

#postgresql #iceberg #duckdb

iSAM Funds отказалась от части предрасчётов при анализе опционных данных

У одного базового инструмента могут быть тысячи связанных опционов. Поэтому число исходных инструментов плохо описывает реальную нагрузку на хранение и аналитику.

Команда iSAM Funds сначала измерила масштаб задачи, затем организовала параллельную запись в ClickHouse на том же оборудовании, где проверяла решение на PostgreSQL.

В своём эксперименте команда получила сжатие в 35–50 раз относительно прежнего объёма хранения и рост загрузки на одном ядре с 8 тысяч до 800 тысяч строк в секунду. Это результаты конкретного набора данных, схемы и реализации.

Быстрые запросы позволили убрать часть заранее рассчитанных агрегатов и материализованных представлений. Для передачи данных команда использует Apache Arrow.

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

#clickhouse #архитектура #аналитика

DuckDB превращает JSON из текстового столбца в типизированные колонки

События часто приходят как JSON в поле payload. Выгружать их в файл, чтобы затем прочитать через read_json, необязательно: команда DuckDB показывает, как выполнить преобразование внутри SQL.

Сначала можно получить общую структуру документов:

SELECT json_group_structure(payload::JSON)
FROM events;

Затем скорректировать типы и передать схему в json_transform. Функция создаст STRUCT, а unnest развернёт его верхний уровень в колонки.

Если сохранить результат отдельной таблицей, следующие запросы будут работать с обычными типизированными колонками без повторного разбора JSON.

Проверьте обработку ошибок: json_transform может заменить значение, которое не удалось преобразовать, на NULL. Для отказа с ошибкой есть json_transform_strict. А вывод схемы по выборке может пропустить редкие поля.

#duckdb #json #etl

Как число кандидатов меняет стоимость гибридного поиска

Больше кандидатов для ранжирования означает больше чтений и работы базы. При этом итоговая десятка результатов может измениться совсем немного.

В разборе Lakebase Search приложение Slide Hub объединяет векторный поиск и BM25 через Reciprocal Rank Fusion. Команда сравнила размеры списков кандидатов на 20 запросах.

При сокращении списка с 1000 до 200 число затронутых страниц уменьшилось с 28 972 до 10 401. В итоговом top-10 сохранилось 90,5% результатов относительно варианта с 1000 кандидатами. Это совпадение двух выдач, а не оценка качества по экспертной разметке.

На холодном кеше запрос шёл 387 мс вместо 740 мс; повторный — 11,7 мс вместо 35,3 мс. Эти значения относятся к запросу в базе, а полный путь приложения включает и другие задержки.

Авторы проверяют пределы базы и сервера приложения отдельно. Увеличение ресурсов базы со временем перестало помогать — потребовались дополнительные обработчики запросов приложения.

#поиск #производительность