Polars: как отличить медленный JOIN от ожидания данных
В примере профилирования Polars запрос выполнялся около 5 секунд, а CPU-время JOIN составило примерно 103 мс. Основным ограничением было чтение из S3.
Профилировщик показывает логический и физический планы, потоки строк и прогресс узлов. Для локального запроса нужно установить
Запрос исполняется на вашей инфраструктуре; планы и телеметрия передаются в платформу Polars Cloud. Там можно смотреть текущие и завершённые запросы, находить дорогие операции и проверять, насколько рано применяются фильтры.
Такой профиль помогает выбрать, что оптимизировать первым: загрузку данных, JOIN или агрегацию.
Подключение и разбор профиля Polars
В примере профилирования Polars запрос выполнялся около 5 секунд, а CPU-время JOIN составило примерно 103 мс. Основным ограничением было чтение из S3.
Профилировщик показывает логический и физический планы, потоки строк и прогресс узлов. Для локального запроса нужно установить
polars_cloud и включить pl.Config.enable_monitoring(). Возможность описана для streaming- и distributed-движков.Запрос исполняется на вашей инфраструктуре; планы и телеметрия передаются в платформу Polars Cloud. Там можно смотреть текущие и завершённые запросы, находить дорогие операции и проверять, насколько рано применяются фильтры.
Такой профиль помогает выбрать, что оптимизировать первым: загрузку данных, JOIN или агрегацию.
Подключение и разбор профиля Polars
Polars
Profile your Polars queries
You can now query profile your locally running queries live & historically in our platform.
Когда DuckDB хватает для ETL вместо Spark
В примере AWS задание на DuckDB выполнилось примерно за 56 секунд, а эквивалентное на Spark — за 117. Оба запускались в Glue 6.0 с конфигурацией 2 DPU и вернули 1176 строк.
DuckDB работает внутри одного воркера: читает Parquet из S3, выполняет SQL-преобразования и записывает результат в S3 Tables через Iceberg REST catalog. Выходную таблицу можно запрашивать из Athena.
Для небольших регулярных заданий время запуска и накладные расходы движка могут заметно влиять на итог. Здесь DuckDB уложился в минимальную минуту тарификации, а Spark потребовал две.
Это замер одного сценария. Для своего ETL сравните объём входных данных, сложность JOIN, доступную память и полное время задания.
Код пайплайна и условия сравнения
В примере AWS задание на DuckDB выполнилось примерно за 56 секунд, а эквивалентное на Spark — за 117. Оба запускались в Glue 6.0 с конфигурацией 2 DPU и вернули 1176 строк.
DuckDB работает внутри одного воркера: читает Parquet из S3, выполняет SQL-преобразования и записывает результат в S3 Tables через Iceberg REST catalog. Выходную таблицу можно запрашивать из Athena.
Для небольших регулярных заданий время запуска и накладные расходы движка могут заметно влиять на итог. Здесь DuckDB уложился в минимальную минуту тарификации, а Spark потребовал две.
Это замер одного сценария. Для своего ETL сравните объём входных данных, сложность JOIN, доступную память и полное время задания.
Код пайплайна и условия сравнения
Как LinkedIn ищет метрики среди миллиардов записей
Индекс метаданных метрик LinkedIn обслуживает более 150 тысяч запросов в минуту со средней задержкой 68 мс. Он работает с более чем 13 млрд метрик, около 30% которых меняются за день.
Раньше запросы распределялись между собственным поисковым индексом, Elasticsearch и KV-хранилищем. Теперь общий шлюз переводит их в SQL для ClickHouse, поэтому потребителям не пришлось менять интеграции.
Данные лежат в ReplacingMergeTree. Поток изменений поддерживает актуальность индекса, а свежая ежедневная таблица догоняет изменения перед переключением. Отдельные колонки заменяют поиск регулярками по составным именам; projections ускоряют тяжёлые агрегации.
По оценке команды, расход памяти сократился примерно в пять раз. 68 мс — среднее по разным типам запросов, включая аналитические.
Архитектура индекса и результаты миграции
Индекс метаданных метрик LinkedIn обслуживает более 150 тысяч запросов в минуту со средней задержкой 68 мс. Он работает с более чем 13 млрд метрик, около 30% которых меняются за день.
Раньше запросы распределялись между собственным поисковым индексом, Elasticsearch и KV-хранилищем. Теперь общий шлюз переводит их в SQL для ClickHouse, поэтому потребителям не пришлось менять интеграции.
Данные лежат в ReplacingMergeTree. Поток изменений поддерживает актуальность индекса, а свежая ежедневная таблица догоняет изменения перед переключением. Отдельные колонки заменяют поиск регулярками по составным именам; projections ускоряют тяжёлые агрегации.
По оценке команды, расход памяти сократился примерно в пять раз. 68 мс — среднее по разным типам запросов, включая аналитические.
Архитектура индекса и результаты миграции
Как ускорить запросы Spark без переписывания SQL
Тяжёлый запрос приходит из BI-дашборда, а изменить его SQL сложно. В AWS Spark runtime можно ускорить такой запрос через материализованное представление Iceberg.
Оптимизатор сравнивает логический план с доступными представлениями. Если одно из них покрывает запрос целиком или частично, план читает заранее вычисленный результат. Если совпадения нет, выполняется исходный запрос.
Статья разбирает разные варианты покрытия: JOIN, агрегации и точное совпадение более сложных вычислений. Представление хранится как Iceberg-таблица; обновление можно настроить по расписанию.
Автоматическая подстановка доступна в Amazon EMR начиная с 7.12.0 и AWS Glue с 5.1. При выборе представления учитывайте частоту запросов, стоимость обновления и допустимую задержку данных.
Примеры планов и настройка подстановки
Тяжёлый запрос приходит из BI-дашборда, а изменить его SQL сложно. В AWS Spark runtime можно ускорить такой запрос через материализованное представление Iceberg.
Оптимизатор сравнивает логический план с доступными представлениями. Если одно из них покрывает запрос целиком или частично, план читает заранее вычисленный результат. Если совпадения нет, выполняется исходный запрос.
Статья разбирает разные варианты покрытия: JOIN, агрегации и точное совпадение более сложных вычислений. Представление хранится как Iceberg-таблица; обновление можно настроить по расписанию.
Автоматическая подстановка доступна в Amazon EMR начиная с 7.12.0 и AWS Glue с 5.1. При выборе представления учитывайте частоту запросов, стоимость обновления и допустимую задержку данных.
Примеры планов и настройка подстановки
Как передавать данные датчиков из MQTT в Kafka
Датчик публикует JSON в локальный MQTT-брокер. Чтобы отправить эти события в Kafka, нужно выбрать маршрут, схему сообщений и способ сохранить сведения об источнике.
Автор проверил несколько вариантов, включая MQTT Source Connector, Pro Mosquitto и HiveMQ. Коннектор забирает сообщения из доступного ему брокера и использует полное имя MQTT-топика как ключ Kafka-сообщения.
У MQTT нет встроенной схемы данных. Для дальнейшей обработки автор предлагает задать и проверять её, например, во Flink. В отдельных интеграциях имя исходного топика не переносится: идентификатор площадки придётся добавить в payload.
Есть и нюанс эксплуатации: изменение числа задач или списка топиков MQTT Source Connector может привести к потере данных из-за перераспределения подписок.
Схемы подключения, конфигурации и ограничения
Датчик публикует JSON в локальный MQTT-брокер. Чтобы отправить эти события в Kafka, нужно выбрать маршрут, схему сообщений и способ сохранить сведения об источнике.
Автор проверил несколько вариантов, включая MQTT Source Connector, Pro Mosquitto и HiveMQ. Коннектор забирает сообщения из доступного ему брокера и использует полное имя MQTT-топика как ключ Kafka-сообщения.
У MQTT нет встроенной схемы данных. Для дальнейшей обработки автор предлагает задать и проверять её, например, во Flink. В отдельных интеграциях имя исходного топика не переносится: идентификатор площадки придётся добавить в payload.
Есть и нюанс эксплуатации: изменение числа задач или списка топиков MQTT Source Connector может привести к потере данных из-за перераспределения подписок.
Схемы подключения, конфигурации и ограничения
Как обслуживать большой dbt-проект и находить медленные модели
В IFCO миллиарды событий отслеживания превращаются в показатели движения тары. Некоторые данные опаздывают на недели и месяцы, поэтому пайплайн должен корректировать уже рассчитанную историю.
Команда настраивала инкрементальные dbt-модели по реальному плану выполнения: проверяла объём чтения и записи, стратегию MERGE, liquid clustering и dynamic file pruning. Время основного задания сократилось более чем на 60%; ночной полный пересчёт убрали.
Для эксплуатации каждую модель вынесли в отдельную задачу Databricks Jobs через открытый databricks-dbt-factory. Так видно, какой шаг задерживает запуск, а повторно выполнять можно конкретные модели.
Скомпилированный SQL показывает намерение модели. План выполненного запроса помогает проверить, сколько данных она действительно обработала.
Разбор моделей, диагностики и запуска dbt
В IFCO миллиарды событий отслеживания превращаются в показатели движения тары. Некоторые данные опаздывают на недели и месяцы, поэтому пайплайн должен корректировать уже рассчитанную историю.
Команда настраивала инкрементальные dbt-модели по реальному плану выполнения: проверяла объём чтения и записи, стратегию MERGE, liquid clustering и dynamic file pruning. Время основного задания сократилось более чем на 60%; ночной полный пересчёт убрали.
Для эксплуатации каждую модель вынесли в отдельную задачу Databricks Jobs через открытый databricks-dbt-factory. Так видно, какой шаг задерживает запуск, а повторно выполнять можно конкретные модели.
Скомпилированный SQL показывает намерение модели. План выполненного запроса помогает проверить, сколько данных она действительно обработала.
Разбор моделей, диагностики и запуска dbt
Forwarded from Типичный программист
🧑💻 Какие навыки помогают вам в разработке в 2026 году?
Что вы чаще используете в работе? В каких задачах помогает ИИ, а где проще справиться самостоятельно?
Мы решили собрать портрет современного разработчика — и приглашаем вас поделиться своим опытом. Расскажите, какие навыки вам пригодились и как вы используете ИИ. Если обходите его стороной, нам тоже интересно узнать почему.
Опрос анонимный и займёт около 5 минут. Результаты опубликуем в общем большом исследовании.
👉 Пройти опрос
Что вы чаще используете в работе? В каких задачах помогает ИИ, а где проще справиться самостоятельно?
Мы решили собрать портрет современного разработчика — и приглашаем вас поделиться своим опытом. Расскажите, какие навыки вам пригодились и как вы используете ИИ. Если обходите его стороной, нам тоже интересно узнать почему.
Опрос анонимный и займёт около 5 минут. Результаты опубликуем в общем большом исследовании.
👉 Пройти опрос
👍1
Почему резервное копирование вытесняет данные из кеша PostgreSQL
Во время бэкапа PostgreSQL запросы могут замедлиться из-за page cache Linux. Последовательное чтение всей базы заполняет кеш данными для копирования и вытесняет страницы, нужные рабочей нагрузке.
Команда ClickHouse Managed Postgres проверила это на базе размером 467 ГБ. Буферизованный бэкап вытеснил все 40 GiB прогретой неактивной таблицы. В вариантах с direct I/O её данные остались в кеше.
Direct I/O обходит page cache, но отключает у этих чтений автоматическое упреждающее чтение — readahead. Поэтому маленькие запросы к массиву NVMe могут недогружать диски.
В разборе подбирают размер блока под полную полосу RAID0 и число параллельных читателей под оборудование. Проверять нужно и скорость бэкапа, и задержки запросов во время него.
Эксперимент с четырьмя режимами чтения
Во время бэкапа PostgreSQL запросы могут замедлиться из-за page cache Linux. Последовательное чтение всей базы заполняет кеш данными для копирования и вытесняет страницы, нужные рабочей нагрузке.
Команда ClickHouse Managed Postgres проверила это на базе размером 467 ГБ. Буферизованный бэкап вытеснил все 40 GiB прогретой неактивной таблицы. В вариантах с direct I/O её данные остались в кеше.
Direct I/O обходит page cache, но отключает у этих чтений автоматическое упреждающее чтение — readahead. Поэтому маленькие запросы к массиву NVMe могут недогружать диски.
В разборе подбирают размер блока под полную полосу RAID0 и число параллельных читателей под оборудование. Проверять нужно и скорость бэкапа, и задержки запросов во время него.
Эксперимент с четырьмя режимами чтения
Как Flink SQL понимает нестандартные CDC-события
CDC-источник может обозначать изменения как INSERT, MODIFY и REMOVE, а Flink ждёт свои типы операций. FROM_CHANGELOG позволяет задать соответствие в SQL и превратить журнал событий в обновляемую таблицу.
TO_CHANGELOG выполняет обратное преобразование: выдаёт изменения как обычные записи с колонкой операции. Это помогает передавать результат потоковой агрегации в приёмник, который принимает только вставки.
Соответствие операций нужно проверять: ошибочная настройка может испортить состояние таблицы без исключения. FROM_CHANGELOG также не разделяет одно событие со старым и новым состоянием на две строки.
В Flink 2.3 поддержка ограничена. Расширенные параметры из статьи доступны с 2.4 и уже есть в Confluent Cloud for Apache Flink.
SQL-примеры и ограничения CDC-функций
CDC-источник может обозначать изменения как INSERT, MODIFY и REMOVE, а Flink ждёт свои типы операций. FROM_CHANGELOG позволяет задать соответствие в SQL и превратить журнал событий в обновляемую таблицу.
TO_CHANGELOG выполняет обратное преобразование: выдаёт изменения как обычные записи с колонкой операции. Это помогает передавать результат потоковой агрегации в приёмник, который принимает только вставки.
Соответствие операций нужно проверять: ошибочная настройка может испортить состояние таблицы без исключения. FROM_CHANGELOG также не разделяет одно событие со старым и новым состоянием на две строки.
В Flink 2.3 поддержка ограничена. Расширенные параметры из статьи доступны с 2.4 и уже есть в Confluent Cloud for Apache Flink.
SQL-примеры и ограничения CDC-функций
❤1
Как искать ближайшие векторы массовым SQL-соединением
Для каждой строки с вектором нужно найти k ближайших строк в другой таблице. Когда запросов миллионы, отдельное сетевое обращение для каждого поиска ограничивает скорость всего задания.
Databricks реализовала эту операцию как SQL-соединение NEAREST BY. Оно поддерживает точный и приближённый пакетный поиск; Photon вычисляет расстояния блоками с помощью специализированного ядра матричного умножения.
Для приближённого поиска IVF-индекс хранится в обычной Delta-таблице с liquid clustering. При чтении движок отсекает большую часть разделов и проверяет кандидатов.
Подход рассчитан на массовое сопоставление сущностей, обогащение записей и подготовку рекомендаций. Здесь оценивают пропускную способность всего задания и соблюдение SLA.
Устройство соединения и векторного индекса
Для каждой строки с вектором нужно найти k ближайших строк в другой таблице. Когда запросов миллионы, отдельное сетевое обращение для каждого поиска ограничивает скорость всего задания.
Databricks реализовала эту операцию как SQL-соединение NEAREST BY. Оно поддерживает точный и приближённый пакетный поиск; Photon вычисляет расстояния блоками с помощью специализированного ядра матричного умножения.
Для приближённого поиска IVF-индекс хранится в обычной Delta-таблице с liquid clustering. При чтении движок отсекает большую часть разделов и проверяет кандидатов.
Подход рассчитан на массовое сопоставление сущностей, обогащение записей и подготовку рекомендаций. Здесь оценивают пропускную способность всего задания и соблюдение SLA.
Устройство соединения и векторного индекса
Как Delivery Hero сократила задержку обработки рекламных событий
В рекламном пайплайне Delivery Hero средний промежуток между событием и его записью сократился с 61 минуты до 1,2 секунды. Команда перешла с часовых пакетов на Apache Flink.
Пайплайн расшифровывает события, удаляет дубликаты и асинхронно обогащает их данными из DynamoDB. Затем многодневное соединение связывает взаимодействия с заказами, а агрегаты сохраняются в отчётную базу каждые пять минут.
Дедупликация держит ключи в RocksDB-состоянии 30 часов. Инкрементальные checkpoints уходят в S3; после сбоя повторно доставленные события отсеиваются. Так команда получила фактически однократный биллинг поверх доставки at-least-once.
Эксплуатационные расходы снизились примерно на 57%. Задержка 1,2 секунды относится к записи событий, а не к обновлению отчётных агрегатов.
Архитектура обработки и результаты миграции
В рекламном пайплайне Delivery Hero средний промежуток между событием и его записью сократился с 61 минуты до 1,2 секунды. Команда перешла с часовых пакетов на Apache Flink.
Пайплайн расшифровывает события, удаляет дубликаты и асинхронно обогащает их данными из DynamoDB. Затем многодневное соединение связывает взаимодействия с заказами, а агрегаты сохраняются в отчётную базу каждые пять минут.
Дедупликация держит ключи в RocksDB-состоянии 30 часов. Инкрементальные checkpoints уходят в S3; после сбоя повторно доставленные события отсеиваются. Так команда получила фактически однократный биллинг поверх доставки at-least-once.
Эксплуатационные расходы снизились примерно на 57%. Задержка 1,2 секунды относится к записи событий, а не к обновлению отчётных агрегатов.
Архитектура обработки и результаты миграции
Как анализировать IP-адреса и подсети встроенными SQL-функциями
В сетевых журналах IP выглядит как строка, но проверка попадания в подсеть требует работы с диапазонами. Разбор адресов регулярками и собственные UDF усложняют такие запросы на больших объёмах.
В Databricks Runtime 18 LTS и новее доступны встроенные функции для IPv4, IPv6 и CIDR. Они принимают строковое и бинарное представления адресов.
Функция ip_cidr_contains(cidr, needle) проверяет, входит ли адрес или другая подсеть в заданный блок. Её можно использовать для соединения журналов соединений со справочником опасных сетей.
В статье таким запросом обогащают сетевые события и ищут источники, сканирующие много адресов и портов. Операции встроены в движок, поэтому оптимизатор и Photon могут ускорять их выполнение.
Пример SQL для анализа сетевых журналов
В сетевых журналах IP выглядит как строка, но проверка попадания в подсеть требует работы с диапазонами. Разбор адресов регулярками и собственные UDF усложняют такие запросы на больших объёмах.
В Databricks Runtime 18 LTS и новее доступны встроенные функции для IPv4, IPv6 и CIDR. Они принимают строковое и бинарное представления адресов.
Функция ip_cidr_contains(cidr, needle) проверяет, входит ли адрес или другая подсеть в заданный блок. Её можно использовать для соединения журналов соединений со справочником опасных сетей.
В статье таким запросом обогащают сетевые события и ищут источники, сканирующие много адресов и портов. Операции встроены в движок, поэтому оптимизатор и Photon могут ускорять их выполнение.
Пример SQL для анализа сетевых журналов
Как ускорить GROUP BY по повторяющимся строкам в DuckDB
В наборе железнодорожных данных 380 959 строк, но всего 537 названий станций. При группировке по названию движок снова и снова хеширует и сравнивает одни и те же строки.
Команда DuckDB предлагает вынести названия в таблицу измерений, а в основной таблице хранить числовые ключи. Для 537 значений достаточно двухбайтового
Числовые ключи уменьшают размер записей хеш-таблицы и стоимость сравнения. При компактном диапазоне ключей оптимизатор может выбрать агрегацию с прямой индексацией массива.
В разборе с SQL-примерами показаны создание справочника и его обновление. Приём полезен для повторных запросов по длинным строкам с частыми повторами. Он не уменьшает число групп; для почти уникальных значений выгода ограничена.
В наборе железнодорожных данных 380 959 строк, но всего 537 названий станций. При группировке по названию движок снова и снова хеширует и сравнивает одни и те же строки.
Команда DuckDB предлагает вынести названия в таблицу измерений, а в основной таблице хранить числовые ключи. Для 537 значений достаточно двухбайтового
USMALLINT. Запрос сначала агрегирует по ключам, затем возвращает названия через JOIN уже небольшого результата. Для top-N соединение можно выполнить после LIMIT.Числовые ключи уменьшают размер записей хеш-таблицы и стоимость сравнения. При компактном диапазоне ключей оптимизатор может выбрать агрегацию с прямой индексацией массива.
В разборе с SQL-примерами показаны создание справочника и его обновление. Приём полезен для повторных запросов по длинным строкам с частыми повторами. Он не уменьшает число групп; для почти уникальных значений выгода ограничена.
Как сократить паузы при ребалансировке Kafka
Добавление потребителя в большую группу может задержать обработку событий: участникам нужно перераспределить партиции. Протокол KIP-848 переносит координацию на брокер и выполняет перераспределение инкрементально. Потребители с неизменившимися назначениями продолжают работу.
В Amazon MSK нужен Kafka 4.0+ и клиент с поддержкой протокола. На клиенте задают
Новый протокол не отменяет диагностику задержек. Проверьте фактически используемый протокол по логам, стабильность потребителей и корректное завершение через
В инструкции AWS разобраны переход на KIP-848 и проверка результата по consumer lag. Материал пригодится для потоковых пайплайнов с частыми перезапусками и масштабированием обработчиков.
Добавление потребителя в большую группу может задержать обработку событий: участникам нужно перераспределить партиции. Протокол KIP-848 переносит координацию на брокер и выполняет перераспределение инкрементально. Потребители с неизменившимися назначениями продолжают работу.
В Amazon MSK нужен Kafka 4.0+ и клиент с поддержкой протокола. На клиенте задают
group.protocol=consumer. Интервал heartbeat, таймаут сессии и алгоритмы назначения теперь управляются на стороне брокера; прежние клиентские параметры нужно убрать.Новый протокол не отменяет диагностику задержек. Проверьте фактически используемый протокол по логам, стабильность потребителей и корректное завершение через
consumer.close().В инструкции AWS разобраны переход на KIP-848 и проверка результата по consumer lag. Материал пригодится для потоковых пайплайнов с частыми перезапусками и масштабированием обработчиков.
Как выполнять свой код рядом с данными в ClickHouse
Чтобы посчитать токены в сохранённых запросах к LLM, обычно выгружают тексты, вызывают библиотеку и загружают результат обратно. Executable UDF позволяет вызвать такой код из SQL внутри ClickHouse Cloud.
В разборе рабочего примера Rust-функция считает токены при вставке данных через материализованное представление. Отдельная Python-функция с сетевым доступом периодически отправляет выборку ответов на оценку модели.
Функции используют CPU и память того же сервиса, что и запросы. Их расходы видны в
В тесте подсчёта токенов Rust оказался в 1,4 раза быстрее Python. Это результат конкретных библиотек и нагрузки: сама смена языка ускорения не гарантирует. Сетевой доступ пока доступен Python-функциям; Native runtime предназначен для вычислений.
Чтобы посчитать токены в сохранённых запросах к LLM, обычно выгружают тексты, вызывают библиотеку и загружают результат обратно. Executable UDF позволяет вызвать такой код из SQL внутри ClickHouse Cloud.
В разборе рабочего примера Rust-функция считает токены при вставке данных через материализованное представление. Отдельная Python-функция с сетевым доступом периодически отправляет выборку ответов на оценку модели.
Функции используют CPU и память того же сервиса, что и запросы. Их расходы видны в
system.query_log: время выполнения, ожидание пула и объём переданных данных. Версии можно закреплять отдельно для каждого сервиса.В тесте подсчёта токенов Rust оказался в 1,4 раза быстрее Python. Это результат конкретных библиотек и нагрузки: сама смена языка ускорения не гарантирует. Сетевой доступ пока доступен Python-функциям; Native runtime предназначен для вычислений.
Как менять таблицу Iceberg без переписывания старых файлов
Таблица выросла, диапазона числового поля больше не хватает, а запросы требуют другого партиционирования. В Iceberg такие изменения можно выполнить через метаданные.
В практическом разборе Redshift показаны добавление, удаление и переименование колонок, безопасное расширение типов и изменение полей партиционирования через
При смене партиционирования новые данные записываются по обновлённой схеме, а старые файлы сохраняют прежнюю раскладку. Движок учитывает оба варианта при чтении. Для замены одного преобразования другим предусмотрена атомарная операция
Изменение метаданных не перераспределяет уже записанные данные. Схему стоит выбирать под реальные фильтры и соединения; если нужно изменить физическую раскладку старых файлов, потребуется отдельная переработка данных.
Таблица выросла, диапазона числового поля больше не хватает, а запросы требуют другого партиционирования. В Iceberg такие изменения можно выполнить через метаданные.
В практическом разборе Redshift показаны добавление, удаление и переименование колонок, безопасное расширение типов и изменение полей партиционирования через
ALTER TABLE. Колонки отслеживаются по уникальным идентификаторам. Для добавленного поля старые строки возвращают NULL.При смене партиционирования новые данные записываются по обновлённой схеме, а старые файлы сохраняют прежнюю раскладку. Движок учитывает оба варианта при чтении. Для замены одного преобразования другим предусмотрена атомарная операция
REPLACE PARTITION FIELD.Изменение метаданных не перераспределяет уже записанные данные. Схему стоит выбирать под реальные фильтры и соединения; если нужно изменить физическую раскладку старых файлов, потребуется отдельная переработка данных.
❤1
Как поделиться Parquet через небольшой каталог DuckDB
Чтобы дать коллегам доступ к набору Parquet-файлов, можно подготовить DuckDB-файл только с представлениями. Он хранит запросы и имена отношений, а сами данные остаются в объектном хранилище.
В руководстве команды DuckDB создают VIEW над удалённым файлом и публикуют каталог по URL. Получатель подключает его в режиме READ_ONLY и обращается к представлениям как к таблицам.
В определениях VIEW можно закрепить названия колонок, фильтры и соединения. Если данные разделили на файлы по годам или переименовали поле, автор обновляет представление, сохраняя привычный запрос для потребителей.
Каталог не заменяет доступ к источникам: читателю нужны права и на DuckDB-файл, и на данные, на которые он ссылается. Для изменения опубликованного каталога редактируют локальную копию и загружают её заново. Скорость запросов зависит от сети и устройства Parquet-файлов.
#duckdb #dataengineering
Чтобы дать коллегам доступ к набору Parquet-файлов, можно подготовить DuckDB-файл только с представлениями. Он хранит запросы и имена отношений, а сами данные остаются в объектном хранилище.
В руководстве команды DuckDB создают VIEW над удалённым файлом и публикуют каталог по URL. Получатель подключает его в режиме READ_ONLY и обращается к представлениям как к таблицам.
В определениях VIEW можно закрепить названия колонок, фильтры и соединения. Если данные разделили на файлы по годам или переименовали поле, автор обновляет представление, сохраняя привычный запрос для потребителей.
Каталог не заменяет доступ к источникам: читателю нужны права и на DuckDB-файл, и на данные, на которые он ссылается. Для изменения опубликованного каталога редактируют локальную копию и загружают её заново. Скорость запросов зависит от сети и устройства Parquet-файлов.
#duckdb #dataengineering
Почему быстрый запрос ClickHouse ждёт лишний RTT
У клиента ClickHouse простой SELECT после простоя соединения занимал около 64 мс вместо 32 мс. Команда обнаружила дополнительный сетевой обмен, хотя вычисление запроса было быстрым.
В Native-протоколе клиент ждёт пакет EndOfStream. Перед ним сервер отправляет результат и служебные пакеты с логами, прогрессом и метриками. После простоя TCP уменьшает окно перегрузки: в него может не поместиться вся эта последовательность.
С TCP_NODELAY небольшие записи уходят сразу и создают много отдельных TCP-сегментов. Сервер исчерпывает окно и ждёт подтверждения клиента, прежде чем отправить остаток. Так появляется лишний RTT.
В разборе расследования проблему воспроизводят через Linux network namespaces. Исправление — собрать служебные пакеты в буфер и отправлять вместе. Число 32 мс относится к сети конкретного клиента; причина полезна для диагностики хвоста задержек после простоя.
#clickhouse #производительность
У клиента ClickHouse простой SELECT после простоя соединения занимал около 64 мс вместо 32 мс. Команда обнаружила дополнительный сетевой обмен, хотя вычисление запроса было быстрым.
В Native-протоколе клиент ждёт пакет EndOfStream. Перед ним сервер отправляет результат и служебные пакеты с логами, прогрессом и метриками. После простоя TCP уменьшает окно перегрузки: в него может не поместиться вся эта последовательность.
С TCP_NODELAY небольшие записи уходят сразу и создают много отдельных TCP-сегментов. Сервер исчерпывает окно и ждёт подтверждения клиента, прежде чем отправить остаток. Так появляется лишний RTT.
В разборе расследования проблему воспроизводят через Linux network namespaces. Исправление — собрать служебные пакеты в буфер и отправлять вместе. Число 32 мс относится к сети конкретного клиента; причина полезна для диагностики хвоста задержек после простоя.
#clickhouse #производительность
Как изменить партиции Spark Streaming и сохранить состояние
Число партиций stateful-запроса закрепляется в checkpoint. Поэтому изменение
В разборе Databricks показана функция On-Demand State Repartitioning. Она доступна в Public Preview для Databricks Runtime 18+ с RocksDB state store.
Процедура требует остановки запроса: задайте новое значение
Длительность операции видна в
#spark #streaming
Число партиций stateful-запроса закрепляется в checkpoint. Поэтому изменение
spark.sql.shuffle.partitions после перезапуска не перераспределяет уже накопленное состояние.В разборе Databricks показана функция On-Demand State Repartitioning. Она доступна в Public Preview для Databricks Runtime 18+ с RocksDB state store.
Процедура требует остановки запроса: задайте новое значение
spark.sql.streaming.stateStore.partitions и перезапустите обработку с прежним checkpoint. Система завершит незаконченный запланированный микробатч, если он есть, затем перераспределит состояние и продолжит поток.Длительность операции видна в
controlBatch.REPARTITION внутри метрик прогресса. Она зависит от объёма состояния, поэтому изменение стоит планировать на окно обслуживания. Такой подход позволяет подобрать параллелизм без сброса накопленных окон, агрегатов и данных дедупликации.#spark #streaming
Как сохранить структуру HL7v2 при загрузке в Spark
Медицинские системы обмениваются HL7v2-сообщениями: внутри есть сегменты, поля, компоненты и повторы. Превращение каждого сообщения в плоскую таблицу заранее ограничивает, какие детали потом сможет изучить аналитик.
В разборе Funke команда Databricks показывает парсер на Python и PySpark, который сохраняет эту иерархию в стандартных типах Spark. Нужные элементы можно извлекать через DataFrame API или SQL.
Пайплайн сначала записывает исходные сообщения и метаданные загрузки в bronze-таблицу
В демо события поступления, перевода и выписки превращают в историю и текущую занятость коек. Funke отвечает за разбор и загрузку; смысл полей и правила расчёта показателей по-прежнему определяют специалисты предметной области.
#pyspark #dataengineering
Медицинские системы обмениваются HL7v2-сообщениями: внутри есть сегменты, поля, компоненты и повторы. Превращение каждого сообщения в плоскую таблицу заранее ограничивает, какие детали потом сможет изучить аналитик.
В разборе Funke команда Databricks показывает парсер на Python и PySpark, который сохраняет эту иерархию в стандартных типах Spark. Нужные элементы можно извлекать через DataFrame API или SQL.
Пайплайн сначала записывает исходные сообщения и метаданные загрузки в bronze-таблицу
raw_messages. Затем в silver-таблице parsed_messages появляется колонка hl7 с разобранной структурой. На её основе строят gold-таблицы под конкретные метрики.В демо события поступления, перевода и выписки превращают в историю и текущую занятость коек. Funke отвечает за разбор и загрузку; смысл полей и правила расчёта показателей по-прежнему определяют специалисты предметной области.
#pyspark #dataengineering
Что внутри Iceberg-таблицы и как это проверить
Запрос читает слишком много файлов, а таблица постепенно замедляется? Причину можно искать в метаданных Iceberg, открывая их через DuckDB.
В разборе команды DuckDB показан путь от каталога до строк. Каталог хранит указатель на актуальный JSON-файл метаданных. Тот ведёт к списку манифестов и самим манифестам в Avro, а дальше — к файлам данных и удалений.
Каждое изменение создаёт новые файлы и переключает указатель каталога. Старые версии остаются, пока их не очистит процедура обслуживания.
В манифестах можно проверить границы значений колонок и партиции: соответствуют ли они фильтру запроса и позволяют ли исключить ненужные файлы. Число манифестов и файлов удалений помогает оценить последствия частых небольших изменений.
В статье есть SQL для обхода этих слоёв. Сводные счётчики снимков стоит использовать как подсказку: спецификация делает их необязательными, и другой движок может их не заполнить.
#iceberg #duckdb
Запрос читает слишком много файлов, а таблица постепенно замедляется? Причину можно искать в метаданных Iceberg, открывая их через DuckDB.
В разборе команды DuckDB показан путь от каталога до строк. Каталог хранит указатель на актуальный JSON-файл метаданных. Тот ведёт к списку манифестов и самим манифестам в Avro, а дальше — к файлам данных и удалений.
Каждое изменение создаёт новые файлы и переключает указатель каталога. Старые версии остаются, пока их не очистит процедура обслуживания.
В манифестах можно проверить границы значений колонок и партиции: соответствуют ли они фильтру запроса и позволяют ли исключить ненужные файлы. Число манифестов и файлов удалений помогает оценить последствия частых небольших изменений.
В статье есть SQL для обхода этих слоёв. Сводные счётчики снимков стоит использовать как подсказку: спецификация делает их необязательными, и другой движок может их не заполнить.
#iceberg #duckdb