How we built fast UPDATEs for the ClickHouse column store
▫️Part 1: Purpose-built engines
▫️Part 2: SQL-style UPDATEs
В первой части автор Том Шрайбер поясняет, как ClickHouse обходится без традиционного обновления строк, превращая UPDATE/DELETE в вставки с помощью специальных движков вроде ReplacingMergeTree, CollapsingMergeTree и др., которые позднее сливаются фоновым процессом, обеспечивая высокую скорость и масштабируемость на аналитических нагрузках. Это решение позволило объединить эффективность вставок и возможность правки данных без ущерба для быстрого чтения.
Вторая статья рассказывает о новой архитектуре патч‑партиций (patch parts), благодаря которым ClickHouse наконец поддерживает классический синтаксис UPDATE … WHERE, но без затрат на перестройку колонок: патч‑партиции содержат только изменённые значения и сливаются в фоновом режиме, обеспечивая мгновенную видимость изменений и высокую производительность. Автор подробно описывает эволюцию от тяжёлых мутаций до экономных, декларативных обновлений на основе SQL, вдохновлённых механизмами MergeTree.
#ClickHouse
▫️Part 1: Purpose-built engines
▫️Part 2: SQL-style UPDATEs
В первой части автор Том Шрайбер поясняет, как ClickHouse обходится без традиционного обновления строк, превращая UPDATE/DELETE в вставки с помощью специальных движков вроде ReplacingMergeTree, CollapsingMergeTree и др., которые позднее сливаются фоновым процессом, обеспечивая высокую скорость и масштабируемость на аналитических нагрузках. Это решение позволило объединить эффективность вставок и возможность правки данных без ущерба для быстрого чтения.
Вторая статья рассказывает о новой архитектуре патч‑партиций (patch parts), благодаря которым ClickHouse наконец поддерживает классический синтаксис UPDATE … WHERE, но без затрат на перестройку колонок: патч‑партиции содержат только изменённые значения и сливаются в фоновом режиме, обеспечивая мгновенную видимость изменений и высокую производительность. Автор подробно описывает эволюцию от тяжёлых мутаций до экономных, декларативных обновлений на основе SQL, вдохновлённых механизмами MergeTree.
#ClickHouse
ClickHouse
How we built fast UPDATEs for the ClickHouse column store – Part 1: Purpose-built engines
ClickHouse is a column store, but that doesn’t mean updates are slow. In this post, we explore how purpose-built engines like ReplacingMergeTree deliver fast, efficient UPDATE-like behavior through smart insert semantics.
👍15
Денис Лукьянов - Data Vault 2.0. Когда внедрять, проблемы применения при построении DWH на GreenPlum
https://youtu.be/oGwQbeP5iss?si=HT-W93nX2d6Ig_ZP
#DataVault
https://youtu.be/oGwQbeP5iss?si=HT-W93nX2d6Ig_ZP
#DataVault
YouTube
Денис Лукьянов — Data Vault 2.0. Когда внедрять, проблемы применения при построении DWH на Greenplum
Подробнее о конференции SmartData: https://jrg.su/aTWU2K
— —
Скачать презентацию с сайта SmartData — https://jrg.su/bTcWPn
При внедрении Data Vault на Greenplum возникает множество корнер-кейсов, которые могут привести как к просадке производительности системы…
— —
Скачать презентацию с сайта SmartData — https://jrg.su/bTcWPn
При внедрении Data Vault на Greenplum возникает множество корнер-кейсов, которые могут привести как к просадке производительности системы…
👍9❤1
SmartData 2024: Александр Токарев - Пишем свой cluster manager для Apache Spark
https://youtu.be/oDuL8-ptFyk?si=VO_QTc7E7S8y-16v
https://youtu.be/oDuL8-ptFyk?si=VO_QTc7E7S8y-16v
YouTube
Александр Токарев — Пишем свой cluster manager для Apache Spark
Подробнее о конференции SmartData: https://jrg.su/aTWU2K
— —
Скачать презентацию с сайта SmartData — https://jrg.su/Vsou2A
Apache Spark — это развитый фреймворк для обработки больших объемов неструктурированных данных. Одно из его достоинств — способность…
— —
Скачать презентацию с сайта SmartData — https://jrg.su/Vsou2A
Apache Spark — это развитый фреймворк для обработки больших объемов неструктурированных данных. Одно из его достоинств — способность…
👍4🔥1
Первые 3 главы Designing Data-Intensive Applications, 2nd Edition
Глава 1. Компромиссы в архитектуре систем данных
Глава 2. Определение нефункциональных требований
Глава 3. Модели данных и языки запросов
#DesigningDataIntensiveApplications
Глава 1. Компромиссы в архитектуре систем данных
Глава 2. Определение нефункциональных требований
Глава 3. Модели данных и языки запросов
#DesigningDataIntensiveApplications
DataTalks.RU. Data Engineering / DWH / Data Pipeline
Глава 1. Компромиссы в архитектуре систем данных
🔥18
Глава 4. Хранение и извлечение
Продолжение перевода книги «Designing Data-Intensive Applications, 2nd Edition»
https://datatalks.ru/chapter-4-storage-and-retrieval/
#DesigningDataIntensiveApplications
Продолжение перевода книги «Designing Data-Intensive Applications, 2nd Edition»
Глава объясняет ключевые отличия между движками хранения, оптимизированными под OLTP (такими как лог‑структурированные, LSM‑деревья и B‑деревья), и OLAP/аналитическими хранилищами, где используются колоночные форматы сжатия, векторной обработкой и материализованными представлениями, чтобы эффективно работать с большими объёмами и аналитическими запросами
https://datatalks.ru/chapter-4-storage-and-retrieval/
#DesigningDataIntensiveApplications
DataTalks.RU. Data Engineering / DWH / Data Pipeline
Глава 4. Хранение и извлечение
🔥19❤1👍1
Небольшая статья "Введение в gRPC: Python, proto Protocol Buffers, client и server"
с коротким упрощенным примером "gRPC Unary Client <---> Server" на github grpc-protobuf-example
Краткий алгоритм "Как начать работать с gRPC":
1. Установить зависимости (
2. Определить контракт (
3. Сгенерировать код из
4. Реализовать сервер
5. Реализовать клиент (вызов RPC)
Если вам необходимо интегрироваться с каким-либо сервисом, который поддерживает gRPC, то алгоритм действий следующий:
1. Получить/скачать из репозитория
2. Сгенерировать Python-клиентский код из
3. Импортировать сгенерированный код в ваш проект
4. Подключиться к gRPC-endpoint через channel
5. Вызывать методы через stub
#gRPC #ProtoBuf
с коротким упрощенным примером "gRPC Unary Client <---> Server" на github grpc-protobuf-example
Краткий алгоритм "Как начать работать с gRPC":
1. Установить зависимости (
grpcio, grpcio-tools)2. Определить контракт (
.proto файл)3. Сгенерировать код из
.proto через grpc_tools.protoc4. Реализовать сервер
5. Реализовать клиент (вызов RPC)
Если вам необходимо интегрироваться с каким-либо сервисом, который поддерживает gRPC, то алгоритм действий следующий:
1. Получить/скачать из репозитория
.proto файл2. Сгенерировать Python-клиентский код из
.proto с помощью grpc_tools.protoc3. Импортировать сгенерированный код в ваш проект
4. Подключиться к gRPC-endpoint через channel
5. Вызывать методы через stub
#gRPC #ProtoBuf
DataTalks.RU. Data Engineering / DWH / Data Pipeline
Введение в gRPC: Python, proto Protocol Buffers, client и server
Введение в gRPC: Python, proto Protocol Buffers, client и server. Что такое gRPC и как работает? Сравнение с REST. Примеры на Python
👍5❤3
Глава 5. Кодирование и Эволюция (Encoding and Evolution)
Продолжение перевода книги «Designing Data-Intensive Applications, 2nd Edition»
https://datatalks.ru/chapter-5-encoding-and-evolution/
#DesigningDataIntensiveApplications
Продолжение перевода книги «Designing Data-Intensive Applications, 2nd Edition»
Статья рассматривает, как различные форматы кодирования данных (JSON, XML, Protocol Buffers, Avro и др.) обеспечивают поддержку эволюции — то есть возможности изменять структуры данных (схемы), сохраняя совместимость между старым и новым кодом.
Обсуждаются два вида совместимости: обратная (новый код читает старые данные) и прямая (старый код читает данные, сделанные новым кодом), а также то, как форматы и схемы помогают избежать потери данных при таких изменениях.
Также статья показывает, как схемы и кодирование применяются при передачи данных между компонентами (базы данных, RPC, веб-сервисы, события), и какие практики и форматы (например, Avro, вызовы сервисов) подходят для поддержания эволюции в распределённых системах.
https://datatalks.ru/chapter-5-encoding-and-evolution/
#DesigningDataIntensiveApplications
DataTalks.RU. Data Engineering / DWH / Data Pipeline
Глава 5. Кодирование и Эволюция (Encoding and Evolution)
🔥9👍1
Если хотели поиграться с trino iceberg и minio, тот вот репозиторий с docker compose настройками.
Можно провалиться в кишки таблицы iceberg на s3, ну и посмотреть на логику работы trino в ui.
Для развертывания трино необходим новый тип CPU, не везде может запуститься. Но в крайнем случае можно VPS арендовать на время 😉
https://github.com/ivanshamaev/trino-iceberg-minio
#trino #iceberg #minio
Можно провалиться в кишки таблицы iceberg на s3, ну и посмотреть на логику работы trino в ui.
Для развертывания трино необходим новый тип CPU, не везде может запуститься. Но в крайнем случае можно VPS арендовать на время 😉
https://github.com/ivanshamaev/trino-iceberg-minio
#trino #iceberg #minio
GitHub
GitHub - ivanshamaev/trino-iceberg-minio: Тестовый проект по Trino + Iceberg + Rest Catalog + Minio s3
Тестовый проект по Trino + Iceberg + Rest Catalog + Minio s3 - ivanshamaev/trino-iceberg-minio
🔥30❤4👍4
Оптимизация запросов в Trino
Наковырял из документации основные термины и понятия по Trino (плюс настройки из последней версии 478, которые могут пригодиться для оптимизации). Получился в некотором виде конспект.
https://ivan-shamaev.ru/trino-query-optimizer/
Также на днях вышел перевод книги Trino. Анализ больших данных.
Первая глава и оглавление доступны для просмотра
#trino #iceberg
Наковырял из документации основные термины и понятия по Trino (плюс настройки из последней версии 478, которые могут пригодиться для оптимизации). Получился в некотором виде конспект.
https://ivan-shamaev.ru/trino-query-optimizer/
Также на днях вышел перевод книги Trino. Анализ больших данных.
Первая глава и оглавление доступны для просмотра
#trino #iceberg
Персональный блог Data Engineer | Ex-TeamLead BI Developer
Оптимизация запросов в Trino. Обзор функциональности и настроек
Оптимизация запросов в Trino. Обзор функциональности и настроек. Перевод документации по улучшению производительности sql запросов в трино
🔥20👍7❤1
Как устроена работа Iceberg на примере Trino и Rest Catalog?
Iceberg - это табличный формат хранения данных в datalake, который управляется через библиотеку на Java (есть также реализации на Go, Rust, C++ и Python). Но базово работает через Java.
В статье кратко рассматривается как устроено Trino и как устроен Iceberg Java API (без погружения в разработку).
Ну и ссылочки на deepwiki по Iceberg/Trino/Rest Catalog.
https://ivan-shamaev.ru/how-iceberg-works-using-trino-and-rest-catalog/
#Trino #Iceberg #RestCatalog #Java
Iceberg - это табличный формат хранения данных в datalake, который управляется через библиотеку на Java (есть также реализации на Go, Rust, C++ и Python). Но базово работает через Java.
В статье кратко рассматривается как устроено Trino и как устроен Iceberg Java API (без погружения в разработку).
Ну и ссылочки на deepwiki по Iceberg/Trino/Rest Catalog.
https://ivan-shamaev.ru/how-iceberg-works-using-trino-and-rest-catalog/
#Trino #Iceberg #RestCatalog #Java
Персональный блог Data Engineer | Ex-TeamLead BI Developer
Как устроена работа Iceberg на примере Trino и Rest Catalog?
🔥10❤2👍2👀1
Trino vs Starrocks.pdf
1 MB
Обзор Trino vs Starrocks
Кажется, что Trino выигрывает по популярности, как единый SQL инструмент под разные источники данных и возможность их объединить (Federated queries). Еще в Трино имеется фича по динамическому расширению воркеров и Velox на C++.
На одном из meetup команда Авито говорила, что в Starrocks плохо обстоят дела с ограничениями по ресурсам на query. То есть может случиться, что несколько запросов заберут все ресурсы и кластер может "упасть" (возможно ошибаюсь в пересказе). Может быть уже это пофиксили в новых версиях. В трино похожая ситуация может быть, если включить FTE Task mode, то может закончиться память.
Еще в Starrocks при рестарте загружаются заново детальные Iceberg statistics.
Пока по обзорам Starrocks выглядит лучше, но вероятно есть детали. Нужно иметь ввиду, что у Trino ОЧЕНЬ много различных настроек и конфигураций. Взять тот же FTE (aka spills). Поэтому только по одним графикам сложно утверждать однозначно, что Starrocks лучше.
Не воспринимайте этот пост как рекомендацию 😇
Кажется, что Trino выигрывает по популярности, как единый SQL инструмент под разные источники данных и возможность их объединить (Federated queries). Еще в Трино имеется фича по динамическому расширению воркеров и Velox на C++.
На одном из meetup команда Авито говорила, что в Starrocks плохо обстоят дела с ограничениями по ресурсам на query. То есть может случиться, что несколько запросов заберут все ресурсы и кластер может "упасть" (возможно ошибаюсь в пересказе). Может быть уже это пофиксили в новых версиях. В трино похожая ситуация может быть, если включить FTE Task mode, то может закончиться память.
Еще в Starrocks при рестарте загружаются заново детальные Iceberg statistics.
Пока по обзорам Starrocks выглядит лучше, но вероятно есть детали. Нужно иметь ввиду, что у Trino ОЧЕНЬ много различных настроек и конфигураций. Взять тот же FTE (aka spills). Поэтому только по одним графикам сложно утверждать однозначно, что Starrocks лучше.
Не воспринимайте этот пост как рекомендацию 😇
👍9