#ClickHouse

20 posts loaded — scroll for more

Text

bigdataschool-moscow 2 weeks ago

Как установить и настроить Claude Code в Yandex Cloud на Ubuntu 24.04

bigdataschool-moscow

Как установить и настроить Claude Code в Yandex Cloud на Ubuntu 24.04

Установка Claude Code на Ubuntu 24.04 — процесс довольно прямолинейный, но требующий аккуратности с версиями Node.js и правами доступа. Как «самоучка», я рекомендую использовать официальный скрипт установки или NPM, но без использования sudo для самого пакета, чтобы избежать проблем с правами в будущем.
Claude Code - это специализированный CLI-инструмент от Anthropic, превращающий языковую модель Claude 3.5 Sonnet в автономного агента. Программа работает непосредственно в терминале, имея доступ к файловой системе и инструментам разработки. В инфраструктуре Yandex Cloud это позволяет автоматизировать сложные задачи: от написания Airflow DAGs до администрирования баз данных ClickHouse.

Архитектура и системные требования для установки Claude code под Ubuntu 24

Claude Code функционирует как агентная надстройка над стандартной оболочкой Shell. Основное отличие от чат-ботов заключается в способности инструмента самостоятельно выполнять команды и анализировать их вывод.
Для успешной работы архитектура решения должна включать следующие компоненты:
Node.js Runtime. Среда исполнения для самого CLI-приложения.
Git. Необходим для индексации проекта и понимания контекста изменений.
Сетевой мост (Proxy). Обязателен для обхода региональных блокировок API Anthropic.
Инструмент предъявляет высокие требования к качеству окружения. На Ubuntu 24.04 рекомендуется использовать только LTS-версии Node.js для обеспечения стабильности сетевых сокетов.

Установка и настройка Claude Code для кодогенерации

Ниже — пошаговый алгоритм, который гарантированно заведет агента на твоей машине.
Для начала убедимся, что в системе есть базовые утилиты для загрузки и работы с репозиториями.
sudo apt update && sudo apt upgrade -y
sudo apt install -y curl ca-certificates gnupg build-essential

Шаг 1: Установка Node.js и исправление прав доступа

Стандартные репозитории Ubuntu часто содержат устаревшие версии Node.js. Мы будем использовать официальный репозиторий NodeSource для установки версии 22. Выполните последовательно следующие команды для подготовки среды:

# Добавление репозитория NodeSource
curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt install -y nodejs
# Проверка установленных версий
node -v # Должно быть v22.x
npm -v # Должно быть 10.x или выше

Часто при глобальной установке пакетов возникает ошибка EACCES. Она связана с отсутствием прав на запись в системные папки, NPM пытается вломиться в системную папку /usr/lib/node_modules, на которую у обычного пользователя ubuntu нет прав. Хотя ошибка и предлагает использовать sudo, крайне не рекомендуется этого делать для Claude Code. Это может привести к тому, что агент не сможет записывать логи или обновляться. Давай сделаем по-красоте! Перенастроим NPM, чтобы он устанавливал глобальные пакеты в твою домашнюю папку. Это «золотой стандарт» для работы на Linux.
# Создание папки для глобальных пакетов в домашней директории
mkdir ~/.npm-global
npm config set prefix ’~/.npm-global’
# Добавление пути в конфигурацию оболочки
echo “export PATH=$PATH:~/.npm-global/bin”| tee –append ~/.bashrc
source ~/.bashrc
Теперь установка Claude Code пройдет без использования sudo, что является критически важным для безопасности агента.
npm install -g @anthropic-ai/claude-code
claude –version

Как установить Claude code c помощью npm

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

Шаг 2: Настройка прокси-сервера Dante (SOCKS5) для работы Claude Code

Одной из главных сложностей при работе из Yandex Cloud является региональная блокировка API Anthropic. При попытке прямого обращения серверы Cloudflare возвращают ошибку 403. Поскольку API Anthropic блокирует запросы из некоторых регионов, необходимо поднять прокси-сервер на VPS в разрешенной зоне (например, Beget в Латвии, Free Tier AWS). Мы будем использовать Dante и настроим White List для вашего IP из Yandex Cloud.
Установим Dante сервис на удаленном сервере в разрешенной зоне
sudo apt update && sudo apt install dante-server -y
На сервере отредактируйте файл /etc/danted.conf следующим образом :
logoutput: /var/log/danted.log
user.privileged: root
user.unprivileged: nobody
# Порт и адрес, который слушаем
internal: 0.0.0.0 port = 1080
# Твой внешний интерфейс (проверь через ip -br a)
external: eth0
# Методы аутентификации
socksmethod: none
clientmethod: none
# Блок 1: Кому разрешено подключаться к серверу
client pass {
from: 51.250.13.72/32 to: 0.0.0.0/0
log: error connect
}
# Блок 2: Кому разрешено проксировать трафик
socks pass {
from: 51.250.13.72/32 to: 0.0.0.0/0
log: error connect
}
Вместо адреса 51.250.13.72 подставьте свой адрес определив его с помощью curl ifconfig.me на своем сервере в Yandex Cloud. После правки перезапустите сервис командой sudo systemctl restart danted. Такая конфигурация делает ваш прокси невидимым для всех, кроме вашей рабочей станции. Это исключает возможность брутфорса и несанкционированного использования трафика. Даже если Dante настроен, лучше закрыть порт на уровне ядра системы. Мы воспользуемся ufw (Uncomplicated Firewall) — это проще всего на Ubuntu.
#–Настройка сетевого экрана (Firewall) на Beget
#– Разреши SSH, чтобы не потерять доступ к серверу
sudo ufw allow ssh
#– Разреши доступ к порту 1080 только для твоего IP
sudo ufw allow from 51.250.13.72 to any port 1080
#– Включи Firewall
sudo ufw enable

Шаг 3: Настройка клиента Proxychains4 для подключения к Anthropic

На машине в Yandex Cloud нам нужно заставить Claude Code работать через латвийский прокси. Лучшим инструментом для этого является proxychains4. Установите утилиту и внесите правки в её конфигурацию:
sudo apt install proxychains4 -y
sudo vim /etc/proxychains4.conf
В самом конце файла, в секции , удалите стандартные строки и добавьте адрес вашего Beget-сервера ( замените на свой IP):
#socks4 213.XX.XX.XX 9050
socks5 213.XX.XX.XX 1080
Проверьте работоспособность канала связи перед запуском основного инструмента. Команда proxychains4 curl -I https://api.anthropic.com должна вернуть статус HTTP 400 или 401.

Настройка Proxychain для работы Claude Code в России

Если вы видите OK в логах proxychains, значит, сетевой туннель между Яндексом и Латвией работает исправно.

Шаг 4: Практические примеры использования Claude Code для кодогенерации с Airflow и ClickHouse

После настройки Claude Code может выполнять роль Senior Data Engineer. Он понимает структуру специфических фреймворков и баз данных.
Автоматизация Apache Airflow
Вы можете поручить агенту написание и проверку сложных DAG-файлов.

Как написать DAG импорта данных из S3 в ClickHouse c помощью Claude Code

# Пример запроса к агенту
proxychains4 claude –edit “Создай Airflow DAG в папке dags/s3_export.py.
Используй S3ToClickHouseOperator. Настрой расписание на каждые 4 часа.”

Как установить или написать код Operator для DAG Airflow для работы с ClickHouse и S3 с помощью Claude Code

Агент сам найдет нужные импорты и проверит синтаксис Python, настроит Connections и docker compose файлы и запустит на исполнение. Если в коде будут ошибки, он увидит их при попытке “прогнать” файл через интерпретатор.

Как настроить Connections для S3 и ClickHouse в Airflow c Claude code

Работа с ClickHouse через SQL

Claude Code умеет писать оптимизированные запросы, если вы предоставите ему схему таблиц.
# Запрос на оптимизацию
proxychains4 claude “Проанализируй схему таблицы ‘events’ в ClickHouse.
Предложи оптимальный ключ сортировки для ускорения фильтрации по user_id.”
Инструмент анализирует кардинальность данных и предлагает решения на основе лучших практик (например, использование проекций или материализованных представлений). Для эффективного взаимодействия с СУБД вроде ClickHouse используется Model Context Protocol (MCP). Этот протокол дает Claude возможность «видеть» схему таблиц и выполнять SQL-запросы напрямую.
Более подробно о возможностях взаимодействия вы можете познакомиться на курсах ClickHouse Построение DWH и Практический курс Apache Airflow для инженеров данных

Заключение

Интеграция Claude Code в Yandex Cloud - это задача на стыке DevOps и Data Engineering. Правильная настройка прокси-сервера и прав Node.js превращает стандартный терминал в мощную интеллектуальную среду. Агент берет на себя рутину, позволяя инженеру сфокусироваться на архитектурных решениях.
Референсные ссылки
(https://docs.anthropic.com/en/docs/agents-and-tools/claude-code)
(https://www.inet.no/dante/doc/1.4.x/config/auth_none.html)
(https://docs.npmjs.com/resolving-eacces-permissions-errors-when-installing-packages-globally)
(https://cloud.yandex.ru/docs/vpc/concepts/network)

Text

dataautomationtools 1 month ago

Data Analytics: An Overview of the Architecture

dataautomationtools

a metaphorical illustration of a data analytics pipeline composed of stacked platforms

Ask ten developers what data analytics actually is, and you’ll get ten slightly different answers — each involving some combination of dashboards, SQL queries, and a vague promise of “insights.” What Is Data Analytics, Really? At its core, data analytics is the process of collecting, transforming, and interpreting data to support decision-making. That might sound abstract, but think of it as a pipeline with three distinct engineering challenges:

- Collect — Gather data from diverse sources: app logs, APIs, user events, IoT sensors, databases.
- Transform — Clean, structure, and enrich that data so it’s usable.
- Analyze & Visualize — Query, model, and present that data so humans (and algorithms) can interpret it.

A good analytics system automates all three. It bridges the gap between data in the wild (raw, messy, inconsistent) and data in context (structured, queryable, meaningful). Let’s go deeper…

What Data Analytics Means To You

Data analytics isn’t just for analysts anymore. Engineers now sit at the center of how data flows through an organization. Whether you’re instrumenting an app for product metrics, scaling ETL jobs, or optimizing queries on a data warehouse, you’re part of the analytics ecosystem.

And that ecosystem is increasingly code-driven — not just tool-driven. Data pipelines are versioned. Analytics infrastructure is deployed with Terraform. SQL is templated and tested. The boundaries between software engineering and data engineering are blurring fast.

When you hear “data analytics,” it’s tempting to picture business users reading charts in Tableau. But under the hood, analytics is a deeply technical ecosystem. It involves data ingestion, storage, transformation, querying, modeling, and visualization, all stitched together through carefully architected workflows. Understanding how these parts fit gives developers the power to build data platforms that scale — and, more importantly, deliver meaning.

Architecture: The Flow of Data Analytics

Ingestion → Storage → Transformation → Analytics Layer → Visualization

a visualization of the data analytics architecture

Imagine a layered architecture. At the bottom, your app emits raw event data — clickstreams, API requests, errors, transactions.

Data ingestion services capture these and deposit them into a data lake, or staging area.

Then, an ETL (Extract–Transform–Load) or ELT (Extract–Load–Transform) tool takes over, cleaning and shaping that data using frameworks like dbt or Spark.

Once transformed, the data lands in a data warehouse — the single source of truth that analysts and ML pipelines query from.

On top of all of that that sit your data analysis tools — the visualization platforms that frame the analysis with dashboards, notebooks, and charts. This is where users can see what’s in your system, and where the primary meaning is made.

The Evolution: From BI to DataOps

Ten years ago, analytics was something you bolted onto your app — usually through a BI dashboard that only executives looked at. Today, analytics is baked in to every product decision.

This shift has given rise to DataOps, a set of practices that apply DevOps principles — version control, CI/CD, observability — to data pipelines.

In modern teams:

- ETL scripts live in Git.
- Data transformations are deployed via CI/CD.
- Data quality is monitored through metrics and alerts.

This is the new normal — where engineers own not just code, but the data lifecycle that code produces.

Data analytics isn’t just about insights — it’s about building systems that make insight repeatable. For developers, it’s an opportunity to bring engineering rigor to a traditionally ad hoc domain.

If you’re comfortable with CI/CD, APIs, and distributed systems, you already have the foundation to excel at data analytics. The next step is learning the data layer — how to collect, transform, and expose it safely and scalably.

The organizations that win with data aren’t the ones that collect the most — they’re the ones that engineer it best.

The Foundation: Data Collection and Ingestion

Every analytics journey starts with data ingestion — the act of bringing data into your environment. In practice, this might mean pulling event logs from Kafka, syncing Salesforce records via Fivetran, or streaming sensor data from IoT devices.

There are two main ingestion models:

- Batch ingestion, where data is loaded in scheduled intervals (e.g., daily imports from a CSV dump or nightly ETL jobs).
- Streaming ingestion, where data is continuously processed in near real-time using tools like Apache Kafka, Flink, or Spark Structured Streaming.

Developers building ingestion pipelines have to think about idempotency, schema drift, and ordering. What happens if a record arrives twice? What if a field disappears? These are not business questions — they’re software design problems. Robust ingestion systems handle retries gracefully, store checkpoints, and log events for observability.

Data Storage: From Lakes to Warehouses

Once data arrives, it needs to live somewhere that supports analytics — which means optimized storage. There are two broad categories:

- Data lakes store raw, unstructured data (logs, JSON, Parquet, CSV) cheaply and flexibly, typically in S3 or Azure Data Lake. They’re schema-on-read, meaning the structure is defined only when you query it.
- Data warehouses store structured, query-optimized data (Snowflake, BigQuery, Redshift). They’re schema-on-write, enforcing structure as data is ingested.

Increasingly, the lines blur thanks to lakehouse architectures (like Delta Lake or Apache Iceberg) that combine both paradigms — giving developers the scalability of a lake with the transactional guarantees of a warehouse.

Transformation: Cleaning and Structuring the Raw

Before you can analyze data, you have to transform it — clean, filter, join, aggregate, and model it into something usable. This is the realm of ETL (Extract, Transform, Load) or ELT (Extract, Load, Transform), depending on whether the transformation happens before or after data lands in the warehouse.

Tools like dbt (Data Build Tool) have revolutionized this step by treating transformations as code. Instead of opaque SQL scripts buried in cron jobs, dbt defines reusable “models” in version-controlled SQL, with automated tests and lineage tracking.

For more programmatic transformations, engineers turn to Apache Spark, Flink, or Beam, which let you define transformations as distributed compute jobs. Spark’s DataFrame API, for instance, lets you filter and aggregate terabytes of data as if you were working with a local pandas DataFrame.

At this stage, the key developer mindset is determinism: the same data, the same inputs, should always yield the same result. That’s what separates robust analytics engineering from ad-hoc scripting.

Data Analytics: Where Data Becomes Meaning

data analytics and data visualization platforms atop the warehouse, transformation, and ingestion tools

Once transformed, data is ready for analysis — the act of querying and interpreting patterns. Analysts and developers both query data, but their goals differ. Accordingly, analysts look for meaning, while developers often build pipelines to surface meaning automatically.

The dominant language of analytics is still SQL, because it’s declarative, composable, and optimized for set-based operations. However, analytics increasingly extends beyond SQL. Python libraries like pandas, polars, and DuckDB allow developers to perform high-performance, local analytics with minimal overhead.

For larger-scale systems, OLAP (Online Analytical Processing) engines like ClickHouse, Druid, or BigQuery handle complex aggregations over billions of rows in milliseconds. They do this through columnar storage, vectorized execution, and aggressive compression — architectural details that developers should understand when tuning performance.

Visualization and Communication

Even the cleanest data loses value if it can’t be communicated effectively. That’s where visualization tools — Tableau, Power BI, Metabase, Looker, and Superset — come in. These platforms translate data into charts and dashboards, but from a developer’s perspective, they’re also query generators, caching layers, and permission systems.

Increasingly, teams are adopting semantic layers like MetricFlow or Transform, which define metrics (“active users,” “conversion rate”) as reusable code objects. This prevents each dashboard from redefining business logic differently — a subtle but vital problem in scaling analytics systems.

Automation and Orchestration

In modern data analytics, nothing should run manually. Once you define data pipelines, transformations, and reports, you have to orchestrate them. Tools like Apache Airflow, Dagster, and Prefect schedule, monitor, and retry pipelines automatically.

Think of orchestration as CI/CD for data — the same principles apply. You define tasks as code, store them in Git, test them, and deploy them via automated workflows. The best analytics systems are those that minimize human error and maximize visibility.

From Data Analytics to Action

The final — and most often overlooked — step in data analytics is operationalization. Because Insights don’t matter if they don’t change behavior. For developers, this means integrating analytics results back into applications: predictive models feeding recommendation systems, dashboards triggering alerts, or APIs serving analytical summaries.

Modern analytics platforms are increasingly “real-time,” collapsing the boundary between analysis and action. Kafka streams feed Spark jobs; Spark writes back to Elasticsearch; APIs expose aggregates to user-facing applications. The result is analytics not as a department — but as a feature of every system.

The Data Analytics Feedback Loop

Data analytics is no longer a specialized afterthought — it’s a core engineering discipline. Understanding the architecture of analytics systems makes you a better developer: it teaches data modeling, scalability, caching, and automation.

At its best, data analytics is a feedback loop: collect → store → transform → analyze → act → collect again. Each iteration tightens your understanding of both your systems and your users.

So, whether you’re debugging an ETL pipeline, writing a dbt model, or optimizing a Spark job, remember: you’re not just moving data. You’re translating the world into something measurable — and, eventually, something actionable. That’s the real art of data analytics.

Data Analytics FAQs

What’s the difference between BI and data analytics?

Business intelligence focuses on reporting and dashboards that describe what already happened. Data analytics is broader—it includes exploration, statistics, forecasting, and advanced analysis used to understand patterns and make predictions.

Should analytics run in the app database or a data warehouse?

For small datasets, the app database can work. At scale, analytics should run in a dedicated warehouse like Snowflake, BigQuery, or Redshift to avoid slowing production systems and to enable complex queries.

What’s the role of a semantic layer?

A semantic layer defines consistent business metrics in one place so every dashboard uses the same logic. It prevents “multiple versions of the truth” and reduces one-off SQL scattered across reports.

How real-time does analytics need to be?

Most reporting can be near-real-time or refreshed every few minutes. True sub-second analytics is expensive and rarely necessary unless you’re building operational dashboards or customer-facing features.

Extracts or live queries—what’s better?

Extracts are faster and simpler but add another pipeline to maintain. Live queries keep data fresh and simpler architecturally but depend on warehouse performance and cost.

How do I best handle analytics security?

Go with row-level security, role-based access controls, and single sign-on. Analytics platforms should enforce permissions centrally so sensitive data isn’t accidentally exposed through dashboards.

What’s the hardest part of analytics projects?

Data prep: cleaning, modeling, and governing data consistently is almost always harder than choosing a visualization tool or building dashboards

Text

simple-logic 2 months ago

simple-logic

#Guess

Let’s play ‘Guess The Logo!’ 🤔

Can you name it?

Drop your guesses below!👇

💻 Explore insights on the latest in #technology on our Blog Page 👉 https://simplelogic-it.com/simple-logic-it-services-tech-insights-blog/

🚀 Ready for your next career move? Check out our #careers page for exciting opportunities 👉 https://simplelogic-it.com/careers/

Text

avertigo 3 months ago

avertigo

Cloudflare Outage Analysis of November 18, 2025: Causes and Solution

On November 18, 2025, at 11:20 UTC, users around the world started seeing HTTP 5xx errors when trying to access websites protected by Cloudflare. What initially seemed like a massive attack turned out to be a complex internal error. The company has published a detailed post-mortem analysis explaining the incident.

When a crisis occurs in a company, communication has to become essential to inform…

Cloudflare Outage Analysis of November 18, 2025: Causes and Solution

Text

avertigo 3 months ago

avertigo

Análisis del Apagón de Cloudflare del 18 de Noviembre de 2025: Causas y Solución

El 18 de noviembre de 2025, a las 11:20 UTC, usuarios de todo el mundo comenzaron a ver errores HTTP 5xx al intentar acceder a sitios web protegidos por Cloudflare. Lo que inicialmente parecía un ataque masivo resultó ser un error interno complejo. La compañía ha publicado un análisis post-mortem detallado explicando el incidente.

Cuando se produce una crisis en una empresa la comunicación tiene…

Análisis del Apagón de Cloudflare del 18 de Noviembre de 2025: Causas y Solución

Text

bigdataschool-moscow 8 months ago

Интеграции ClickHouse: работа с MySQL, S3, Kafka и внешними словарями. Урок 7

bigdataschool-moscow

Интеграции ClickHouse: работа с MySQL, S3, Kafka и внешними словарями. Урок 7

ДлДо сих пор мы рассматривали ClickHouse как самостоятельную систему: создавали в нем таблицы и загружали данные. Однако в реальном мире данные редко живут в одном месте. Транзакционная информация находится в реляционных базах вроде MySQL или PostgreSQL, архивы логов — в объектных хранилищах типа Amazon S3, а потоки событий в реальном времени — в Apache Kafka. Перемещать все эти данные в ClickHouse с помощью сложных ETL-процессов — долго и дорого. К счастью, ClickHouse спроектирован как открытый аналитический хаб и умеет работать с внешними данными напрямую. В этой статье мы рассмотрим самые важные механизмы интеграции, которые превращают ClickHouse из просто быстрой базы данных в центр вашей аналитической экосистемы.
Движки для внешних баз данных: Запросы без перемещения
Частая задача — объединить аналитические данные из ClickHouse (например, логи событий) со справочной информацией из основной, транзакционной базы данных. ClickHouse позволяет делать это “на лету” с помощью специальных движков таблиц. Как это работает? Вы создаете в ClickHouse таблицу, которая не хранит данные сама, а выступает в роли “прокси” или коннектора к таблице во внешней базе. Каждый раз, когда вы делаете SELECT к такой таблице, ClickHouse перенаправляет запрос во внешнюю систему.
Пример: Подключение к MySQL
Предположим, в MySQL у нас есть таблица users с информацией о пользователях. Создадим ее “отражение” в ClickHouse:
CREATE TABLE users_from_mysql (
user_id UInt64,
user_name String,
registration_date Date
)
ENGINE = MySQL(‘mysql_host:3306’, 'mysql_db’, 'users’, 'mysql_user’, 'password’);
Важные оговорки:
Производительность: Этот способ не предназначен для высоконагруженных запросов к внешней базе. Он отлично подходит для JOIN'ов с небольшими справочниками.
Predicate pushdown: ClickHouse старается “проталкивать” WHERE условия во внешнюю базу, чтобы фильтровать данные на ее стороне, но это работает не для всех типов запросов.

Интеграция ClickHouse при работе с файлами в S3: Анализируем архивы на месте
Объектные хранилища, такие как Amazon S3, — популярное место для хранения огромных архивов логов. Загружать терабайты таких данных в ClickHouse для разового анализа неэффективно. И этого не нужно делать! Интеграция ClickHouse может помочь выполнять запросы напрямую к файлам в S3 с помощью табличной функции s3()
Пример: Запрос к CSV файлу в S3
SELECT
request_method,
status_code,
count()
FROM s3(
'https://my-bucket.s3.us-east-1.amazonaws.com/logs/archive-*.csv.gz’,
'AWS_ACCESS_KEY_ID’,
'AWS_SECRET_ACCESS_KEY’,
'CSVWithNames’,
'request_method String, status_code UInt16’
)
GROUP BY request_method, status_code;
Это невероятно мощный инструмент для работы с “холодными” данными.
Потоковая обработка: Интеграция ClickHouse с Apache Kafka
Для аналитики в реальном времени данные часто поступают через брокеры сообщений, и Apache Kafka — самый популярный из них. ClickHouse имеет нативный движок Kafka для создания эффективных real-time пайплайнов. Более подробно мы рассматриваем примеры построения pipelinов на наших курсах, посвященных созданию хранилищ данных на ClickHouse и Kafka для инженеров данных
Архитектура пайплайна:
Стандартный подход состоит из трех компонентов:
Таблица с движком Kafka: Она подключается к топику Kafka и работает как потребитель (consumer).
Целевая таблица с движком MergeTree: Это основная, оптимизированная таблица, где данные будут храниться постоянно.
Материализованное представление (Materialized View): Это “клей”, который автоматически читает новые данные из таблицы Kafka и вставляет их в таблицу MergeTree.
Теперь любой JSON, отправленный в топик в Kafka, будет автоматически распарсен и практически мгновенно попадет в нашу основную аналитическую таблицу.

Интеграция ClickHouse с Apache Kafka - бесплатный курс ClickHouse от https://bigdataschool.ru

Обогащение данных: Внешние словари
Еще одна частая задача — обогащение данных. Ваши основные таблицы содержат идентификаторы (user_id), а в отчетах нужны имена (user_name). Делать JOIN каждый раз может быть неэффективно.
Решение — внешние словари. Это справочники (key-value), которые ClickHouse подгружает из внешнего источника и кэширует в оперативной памяти для сверхбыстрого доступа.

Внешние словари для интеграции ClickHouse - бесплатный курс ClickHouse от https://bigdataschool.ru

Как это работает? Для этого Вам нужно описать словарь (в XML или DDL), указывая его структуру, источник (например, таблица в MySQL) и правила обновления. В запросах вы используете специальную функцию dictGet() для получения значения по ключу. Функция dictGet() работает невероятно быстро, так как обращается к данным в оперативной памяти.
Заключение
Бесспорно, ClickHouse — это не изолированная база данных, а мощный аналитический процессор. Освоив эти инструменты интеграции ClickHouse, вы сможете решать гораздо более широкий класс задач, сокращая затраты на разработку сложных ETL-пайплайнов и строя по-настоящему современные аналитические системы.
Использованные референсы и материалы
Официальный сайт Apache Kafka.
Документация ClickHouse по табличной функции s3().
Документация ClickHouse по Внешним словарям.
Статья HTTP Analytics for 6M requests per second using ClickHouse на Cloudflare
SQL-блокнот к Уроку 7 бесплатного курса доступен в нашем репозитории на GitHub

Read the full article

Text

fraoula1 11 months ago

fraoula1

𝐁𝐢𝐠𝐐𝐮𝐞𝐫𝐲 𝐯𝐬 𝐂𝐥𝐢𝐜𝐤𝐇𝐨𝐮𝐬𝐞: 𝐖𝐡𝐨 𝐖𝐢𝐧𝐬 𝐭𝐡𝐞 𝐎𝐋𝐀𝐏 𝐖𝐚𝐫?

OLAP systems like BigQuery and ClickHouse are no longer optional—they’re essential. In this video, we’ll dive deep into how these platforms are transforming industries, enabling real-time analytics, and saving companies millions.

From speed and scalability to cost and real-world use cases, this is the ultimate showdown of modern OLAP systems.

Watch here https://youtu.be/2cOIbU7LSHw

Text

insurgentepress 1 year ago

insurgentepress

ClickHouse adquiere HyperDX para acelerar el futuro de la observabilidad

ClickHouse, la empresa detrás de la base de datos analítica más rápida del mundo, anunció hoy la adquisición de HyperDX, una plataforma de observabilidad de código abierto basada en ClickHouse. Esta adquisición estratégica refuerza el compromiso de ClickHouse por ofrecer las soluciones más rápidas, rentables y escalables para desarrolladores y empresas de todo el mundo, incluida la observabilidad.

La adquisición combina el rendimiento y la escalabilidad inigualables de ClickHouse con la experiencia orientada al desarrollador de HyperDX para crear una plataforma de observabilidad completa que integra de manera transparente reproducción de sesiones, excepciones, registros, métricas de infraestructura y rastreo distribuido a través de un enfoque nativo de OpenTelemetry.

“Las funcionalidades de análisis y el ecosistema abierto de ClickHouse la convierten en una tecnología potente para la observabilidad. No obstante, la experiencia de usuario final carecía de algunas características integrales presentes en soluciones más establecidas. HyperDX es muy interesante, ya que combina una experiencia de consultas mejorada con una interfaz de usuario más intuitiva para flujos de trabajo de observabilidad exploratorios”.
Viktor Eriksson, Lovable

“La observabilidad es fundamentalmente un problema de datos”, indicó Tanya Bragin, vicepresidenta de producto y marketing de ClickHouse. “El tamaño del conjunto de datos dicta qué tan difícil y costoso será diseñar una plataforma de observabilidad. Por ese motivo, ClickHouse ha sido la columna vertebral de las plataformas de observabilidad durante años, con tecnología para soluciones de registros, métricas y rastreo para firmas como eBay y Netflix”.

Originalmente, ClickHouse exploró nuevas soluciones de observabilidad durante su transición de Datadog a su pila de LogHouse interna (Cómo diseñamos una plataforma 19 PiB Logging con ClickHouse y ahorramos millones), que se basó en ClickHouse para manejar sus cargas de trabajo a escala de petabytes. Durante este proceso, descubrieron HyperDX y observaron la facilidad con la que podía transformar una implementación de ClickHouse existente en una plataforma de observabilidad completa.

“Cuando comenzamos HyperDX, teníamos dos principios fundamentales: queríamos diseñar la mejor plataforma de observabilidad de código abierto posible, y ClickHouse era la ÚNICA base de datos con la tecnología para lograrlo”, explicó Michael Shi, director ejecutivo de HyperDX. “Nuestra misión siempre ha sido ayudar a que los ingenieros diagnostiquen y resuelvan problemas de producción más rápido, y ClickHouse ha sido una parte muy importante de ese camino desde el primer día”.

El futuro de la observabilidad de código abierto

A través de conversaciones, las empresas descubrieron que compartían la misma visión:

La observabilidad debe ser rentable y fácil de usar para los desarrolladores
El rendimiento y la escalabilidad de ClickHouse la convierten en la mejor base para la observabilidad
La experiencia orientada al desarrollador de HyperDX permite que los equipos la implementen sin esfuerzo

La integración ofrece numerosos beneficios, entre ellos:

Recopilación de datos basada en estándares: tanto ClickHouse como HyperDX han asumido un compromiso con OpenTelemetry, y actualmente ClickHouse mantiene el exportador ClickHouse OpenTelemetry
Priorización del código abierto: hacer que una observabilidad sólida sea accesible para todos, con productos de nube que ofrezcan una experiencia operativa simple y rentable
Acceso a datos flexible: acceso directo a datos de observabilidad con varias opciones de análisis
Rendimiento de datos ultrarrápido: consulte terabytes en cuestión de segundos para solucionar problemas en tiempo real

HyperDX Cloud seguirá prestando servicios a los clientes existentes e incorporando nuevos, y el proyecto de código abierto seguirá siendo mantenido y desarrollado de forma activa. Al mismo tiempo, la hoja de ruta conjunta está pensada para sumar herramientas de observabilidad aún más potentes para los ingenieros.

Text

pythonjobsupport 1 year ago

pythonjobsupport

ClickHouse Meetup London, July 20, 2022

Slides: 18:00 Doors Open – Networking & Snacks …
source

ClickHouse Meetup London, July 20, 2022

Text

openbooth 1 year ago

openbooth

ClickHouse or StarRocks? Here is a Detailed Comparison

While StarRocks and ClickHouse have a lot in common, there are also differences in functions, performance, and application scenarios. Check out this breakdown of both! A New Choice of Column DBMS Hadoop was developed 13 years ago.

— https://ift.tt/OuPeUFB

Text

openbooth 1 year ago

openbooth

ClickHouse vs. StarRocks: A Detailed Comparison

Apache Hadoop® was developed 13 years ago. Its suppliers have been enthusiastic about offering open-source plug-ins, as well as technical solutions.

— https://ift.tt/lhtx9VT

Link

dromologue 1 year ago

Apache Kafka and Tinybird (ClickHouse) for Streaming Analytics HTTP APIs

dromologue

Apache Kafka became the de facto standard for data streaming. However, the combination of an event-driven architecture with request-response APIs is crucial for most enterprise architectures. This blog post explores how Tinybird innovates with a REST/HTTP layer on top of the open source analytics database ClickHouse in the cloud. Integrating Kafka with Tinybird, the benefits of fully managed services like Confluent Cloud, and customer stories from Factorial, FanDuel and Hard Rock Digital show why Kafka and analytics databases complement each other for more innovation and faster time-to-market.
The post Apache Kafka and Tinybird (ClickHouse) for Streaming Analytics HTTP APIs appeared first on Kai Waehner.

Link

bigdataschool-moscow 1 year ago

Как масштабировать ClickHouse: тонкости шардирования

bigdataschool.ru

Text

pavel-nosok 3 years ago

pavel-nosok

ClickHouse launches ClickHouse Cloud, extends its Series B

Since its launch as an open-source project by Yandex in 2016, ClickHouse has become one of the leading databases for online analytical processing (OLAP), allowing businesses to quickly generate ad-hoc reports over very large datasets. In 2021, Yandex spun off ClickHouse into its own company and joined an initial $50 million Series A funding round led by Index Ventures and Benchmark Capital. Two…

View On WordPress

Text

gslin 3 years ago

gslin

ClickHouse 自家做的 benchmark 比較

在「Show HN: A benchmark for analytical databases (Snowflake, Druid, Redshift) (clickhouse.com)」這邊看到 ClickHouse 自家做的 benchmark 比較，網站在「ClickBench — a Benchmark For Analytical DBMS」這邊。
這種 benchmark 基本上是拿來當作清單來看，另外 Hacker News 上的討論一定得看，尤其是沒被列上 benchmark 的…
講到 ClickHouse，先前是有朋友跑來說他有個需求是需要跑分析，但遇到用 PostgreSQL 時發現寫入速度不夠快的問題，看看有沒有什麼方法可以解。問了多一點以後發現他的需求是 OLAP 類而不是 OLTP 類，就先跟他講要去找 OLAP engine…

View On WordPress

Text

reportwire 4 years ago

reportwire

ClickHouse Visualization with Altinity and Cube

I like counting stars. Especially stars on GitHub! Tracking the growth of popular GitHub repositories has always been interesting to me. That’s why I decided to use the public data set of GitHub events in ClickHouse to create dashboards with actionable metrics.
In this tutorial, I’ll explain how to build a custom front-end visualization that fetches data from a ClickHouse instance. I’ll use a…

View On WordPress

Text

bigdataschool-moscow 4 years ago

Платформа аналитики больших данных Леруа Мерлен: потоковый CDC с Apache Kafka, NiFi, AirFlow и Flink в DWH на Greenplum

bigdataschool-moscow

Платформа аналитики больших данных Леруа Мерлен: потоковый CDC с Apache Kafka, NiFi, AirFlow и Flink в DWH на Greenplum

Чтобы добавить в наши курсы для дата-инженеров по технологиям Apache Kafka, Spark, AirFlow, NiFi, Flink и Greenplum, еще больше практических примеров, сегодня разберем кейс ритейлера Леруа Мерлен. Читайте далее, как сотрудники российского отделения этой международной компании интегрировали в единую платформу более 350 реляционных СУБД и NoSQL-источников с помощью CDC-подхода на конвейерах пакетной и потоковой аналитики больших данных, а также с какими проблемами они столкнулись и как это было решено.

CDC-конвейер на Apache Kafka, NiFi, Spark и AirFlow для DWH на Greenplum

Проект разработки собственной платформы данных в российском отделении международного DIY-ритейлера Леруа Мерлен начался еще в 2019 году. 2 года спустя, в середине 2021 эта Big Data система была полностью реализована и сейчас активно используется в production, обрабатывая около 2000 запросов в минуту для 2 тысяч пользователей. В качестве ключевого элемента платформы, хранилища данных, была выбрана MPP-СУБД Greenplum из-за open-source статуса, поддержки ANSI SQL и совместимости с ранее внедренными решениями на базе PostgreSQL. Прежде всего была организована интеграция данных из существующих реляционных СУБД в платформу, чтобы пользователи могли строить свои аналитические отчеты на едином источнике, а не множестве разрозненных баз. С учетом большого количества систем-источников (более 350 реляционных баз данных) на них был настроен механизм захвата измененных данных (CDC, Change Data Capture), которые с помощью Debezium отправлялись в Apache Kafka. Подробнее о том, как Debezium связан с Apache Kafka через фреймворк Connect мы рассказывали здесь и здесь. За дальнейшую маршрутизацию и обработку этих сообщений отвечал инструмент потокового ETL - Apache NiFi, отправляя сырые данные в первичный слой DWH-хранилища на Greenplum .
Таким образом, «сырые» данные из множества систем-источников записываются в топики Kafka в виде сообщений в формате AVRO и в режиме реального времени с помощью Apache NiFi отправляются в формате Parquet в облачное хранилище Amazon S3. Далее эти данные обрабатывают Spark-задания :
- мелкие файлы объединяются в более крупные, чтобы снизить количество выходных файлов для оптимизации записи и последующего чтения, а также удаляются дубли с помощью методов distinct()и coalesce(). Результат также сохраняется в AWS S3 как архив исходных данных;
- далее выполняется синтаксический анализ или парсинг данных с последующим сохранением в плоские структуры согласно маппингу в метаданных. Так из одного входного файла могут получиться несколько плоских структур в виде сжатых CSV-файлов. Они также сохраняются в AWS.
Наконец, CSV-файлы загружаются в ODS-слой DWH на базе Greenplum путем создания временной внешней таблицы над данными из AWS S3 через PXF-коннектор. За оркестрацию заданий отвечает Apache Airflow, DAG’и для которого генерируются динамически на основании метаданных. По мере роста количества источников и разнообразия данных возникла потребность в модификации этого конвейера. В частности, некоторые источники данных не являлись реляцонными СУБД, а сами данные могли представлять собой не табличные записи со строго определенной структурой, а поток JSON-объектов. Поэтому дата-инженеры Леруа Мерлен разработали собственный конвертер схемы данных из AVRO в JSON, работающий с использованием Kafka Schema Registry и Spark-задания, преобразующего JSON-объекты в датафреймы.
Для работы с потоками событий, например, данных о пользовательском поведении (клики, просмотры и пр.), добавлено Yandex Object Storage, куда Apache NiFi отправлял файлы в формате Parquet. А Spark-задания выполняли парсинг этих данных и загружали их в Greenplum через PXF-коннектор .

дата-инженерия пример, обучение Apache Kafka курсы, DWH на Greenplum

Первая версия аналитической платформы Леруа Мерлен

Потоковая аналитика больших данных с Apache Flink и Superset

В рамках эксплуатации пользователи и администраторы платформы столкнулись со следующими проблемами и ограничениям :- отсутствие возможности строить отчеты по бизнес-показателям в реальном времени;
- низкая скорость выполнения аналитических запросов из-за большого количества накопленных данных и разнообразия самих запросов, не адаптированных к особенностям Greenplum. В итоге обработка 150 млн CDC-событий занимала до 4 часов.
- отсутствие возможности прямого подключения BI-инструментов к Greenplum для конечных пользователей;
- высокое потребление ресурсов.
Чтобы удовлетворить самую большую потребность пользователей (в операционных данных), был разработан новый сервис на базе аналитического фреймворка Apache Flink, который начиная с версии 1.11 поддерживает CDC-потоки, генерируемые Debezium. Как и Apache Spark, Flink имеет SQL-модуль и поддерживает реестр схем Kafka Confluent, а также имеет большое количество коннекторов к различным источникам и приемникам данных. Но, в отличие от Spark, Flink реализует не микро-пакетный, а настоящий потоковый режим обработки событий. ClickHouse выбран как средство операционной отчетности поверх Yandex Object Storage и AWS S3.В качестве презентационного слоя для конечных пользователей выбран Apache Superset – веб-интерфейс для написания SQL-запросов и визуализации результатов на наглядных дэшбордах и графиках с поддержкой функций администрирования и CI/CD-задач. Таким образом, Greenplum формируются аналитические витрины, которые выгружаются в PostgreSQL с помощью PXF-коннектора и дополняются оперативными данными из ClickHouse.

курсы Flink jобучение примеры, потоковая аналитика больших данных кейсы, Apache Flink Spark Kafka data pipeline, DWH Greenplum ClickHouse Superset BI пример

Улучшенная версия аналитической платформы Леруа Мерлен
Развернув вышеописанное решение в production, дата-инженеры Леруа Мерлен столкнулись со следующими проблемами :- Большое количество топиков Apache Kafka из-за подхода «один источник данных – один топик». Много таблиц в одном источнике данных хранятся в одном топике Kafka. При необходимости обработать данные одной таблицы из одного источника с помощью Flink приходится читать весь поток по этому источнику.
- Отсутствие метаданных из Debezium. В используемой версии Apache Flink 1.12 нет возможности получить метаданные из полей Debezium, т.е. определить имя таблицы по имени сообщения из Kafka с данными CDC-потока.
- Ограничения генерации схем – текущая версия Flink не позволяет генерировать схему данных из заголовка сообщений без использования Schema Registry;
- Трудность конфигурирования Apache Superset - большое количество параметров с ограничениями на количество обрабатываемых и выгружаемых строк;
- Сложность подключения проприетарных источников, в частности Oracle и DB2 требуют установки дополнительных драйверов и пакетов.
- Высокая частота обновлений Apache Superset из-за «молодого» возраста этого open-source проекта.
Также дата-инженеры строительного ритейлера отметили сложность первоначальных настроек сети Greenplum, ускоренный износ жестких дисков из-за большого количества IOPS-операций и чрезмерное потребление вычислительных ресурсов (ЦП, память). Поэтому было решено перевести всю инфраструктуру в гибридное облако, чтобы сэкономить и управлять ей как кодом с помощью набора DevOps-инструментов и средств мониторинга: Terraform, Ansible, Jenkins, ELK, Consul, Prometheus и Grafana. В результате этого решения дата-инженеры Леруа Мерлен получили качественную и масштабируемую платформу данных на open source продуктах в облачной инфраструктуре .Больше полезных примеров администрирования и эксплуатации Apache Kafka, Spark, Flink, NiFi, AirFlow, Greenplum и других технологий Big Data для разработки распределенных приложений аналитики больших данных вы узнаете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и дата-аналитиков в Москве:
- Greenplum для инженеров данных
- Apache NiFI для инженеров данных
- Data Pipeline на Apache Airflow и Apache Hadoop
- Apache Kafka для разработчиков
- Потоковая обработка в Apache Spark
Источники
1. https://habr.com/ru/company/leroy_merlin/blog/561072/
2. https://habr.com/ru/company/leroy_merlin/blog/563066/
3. https://habr.com/ru/company/leroy_merlin/blog/567874/

Read the full article

Text

bigdataschool-moscow 4 years ago

Тонкости интеграции Apache Kafka с Pinot для аналитики больших данных в реальном времени

bigdataschool-moscow

Тонкости интеграции Apache Kafka с Pinot для аналитики больших данных в реальном времени

Продолжая вчерашний разговор про потоковую аналитику больших данных на Apache Kafka и Pinot, сегодня рассмотрим особенности интеграции этих систем. Читайте далее, как входные данные Kafka разделяются, реплицируются и индексируются в Pinot, каким образом выполняется обработка данных через распределенные SQL-запросы. Также разберем, почему управление памятью серверов Pinot, потребляющих данные из Kafka, влияет на общую производительность всей Big Data системы.

Как устроен Apache Pinot: краткий обзор архитектуры и принципов работы

Прежде чем говорить об интеграции Apache Kafka и Pinot, рассмотрим, как устроено это быстрое OLAP-хранилище больших данных. Вчера мы уже упоминали, что на фундаментальном уровне оно немного похоже на Apache Druid и яндексовский ClickHouse, а также основанную на нем Arenadata QuickMarts. Все эти аналитические хранилища выполняют обработку запросов на одних и тех же узлах, уходя от разрозненной архитектуры BigQuery, а также выполняют запросы быстрее, чем Big Data инструменты класса SQL-on-Hadoop: Hive, Impala, Presto и Spark, даже при обработке данных в колоночном формате, таких как Parquet или Kudu. Такая оперативность достигается за счет собственного формата хранения индексированных данных, интегрированного с движками обработки запросов. Кроме того, данные в Apache Pinot, Druid и ClickHouse c Arenadata QuickMarts статично распределены между узлами, поэтому при быстром выполнении локальных данных не поддерживаются запросы с межузловыми перемещениями, такие как join-соединение между двумя большими таблицами. Также отсутствуют точечные обновления и удаления за счет эффективного колоночного сжатия и разнообразных индексов. Таблица Pinot состоит из набора сегментов, распределенных по серверам. Сегмент – это единица разделения, репликации и обработки запросов, которая включает в себя метаданные таблицы, сжатые колоночные данные и индексы. Сегменты хранятся в файловой системе, например, Hadoop HDFS и для вычислений могут быть загружены на узлы обработки запросов. Сегменты данных не привязаны жестко к конкретным узлам кластера: за присвоение сегментов узлам, их и перемещение между узлами и репликацию отвечает контроллер – специальный выделенный сервер. Брокеры Pinot используют информацию с контроллера, чтобы рассылать запросы на отдельные серверы и собирать их вместе. Метаданные сегментов хранятся в Apache ZooKeeper, обращение к которому выполняется с использованием фреймворка Helix. Узлы обработки запросов загружают сегменты и обслуживают запросы к хранящимся в них данным, но не занимаются накоплением новых данных и производством новых сегментов.

Ключевое отличие Pinot от Druid – это реализация управления сегментами: Druid реализует всю логику самостоятельно, используя Curator для взаимодействия с ZooKeeper, а Pinot полагается на фреймворк Helix. За счет отсутствия сегментации управление данными в ClickHouse c Arenadata QuickMarts проще, чем в Druid и Pinot, но последние выигрывают с точки зрения оптимизации инфраструктурной стоимости больших кластеров, и лучше подходят для облачных окружений [1]. О прочих сходствах и отличиях Apache Pinot, Druid и ClickHouse с Arenadata QuickMarts мы поговорим в другой раз. А пока рассмотрим, как данные из Kafka представляются в Pinot для аналитики в реальном времени.

Из Kafka в Pinot: потоковая аналитика больших данных

Конвейер интеграции Kafka с Pinot выглядит следующим образом [2]: сперва данные записываются в топиках Kafka; затем Pinot считывает сообщения из топиков Kafka и создает соответствующие сегменты данных, делая их доступными для SQL-запросов в реальном времени. Если данные секционируются в Kafka по каким-либо ключам измерений, информация об этом разбиении учитывается при создании сегментов в Pinot. при выполнении запроса с предикатом на конкретном измерении, брокер-узел Pinot фильтрует сегменты так, чтобы затронуть как можно меньше сегментов и узлов обработки запросов. Эта концепция называется «predicate pushdown» и важна для поддержания высокой производительности в некоторых приложениях. При создании таблицы в Pinot следует указать два элемента: схема, которая определяет столбцы размеров и показателей, а также обозначает один из столбцов как столбец времени. Как правило, основой для этого является исходная схема Kafka. конфигурация таблицы, которая указывает ее свойства – репликация, хранение, квоты, параметры индексации, а также источник данных и, в случае Kafka, начальное смещение, с которого начинается потребление данных. Пример кода по созданию таблицы в Pinot, куда в реальном времени принимаются данные из Kafka, выглядит так: “REALTIME”: { “tableName”: “pinotTable”, “tableType”: “REALTIME”, “segmentsConfig”: { “schemaName”: “pinotTable”, } }, “tableIndexConfig”: { “streamConfigs”: { “streamType”: “kafka”, “stream.kafka.consumer.type”: “lowlevel”, “stream.kafka.topic.name”: “”, “stream.kafka.broker.list”: “”, } }, } Создание схемы и конфигурации таблицы уведомляет контроллер Pinot о начале приема данных для этой таблицы, который из Kafka обнаруживает разделы и определяет начальное смещение, по умолчанию установленное на последнее сообщение в каждом разделе. Сегменты Pinot, которые хранятся в памяти называются «изменяемые» (mutable) и находятся в состоянии потребления (CONSUMING). Каждый изменяемый сегмент упорядочивает входящие данные в колоночном формате и обновляет необходимые индексы в реальном времени. Изменяемые сегменты доступны для SQL-запросов сразу после создания. Таким образом, актуальность данных у Pinot совпадает со свежестью данных Kafka при очень низких накладных расходах на прием сообщений. При сохранении изменяемых сегментов из памяти их на диск они становятся неизменяемыми (immutable). Согласованность данных между репликами на разных узлах и конечным смещением Kafka при этом обеспечивается с помощью протокола контроллера Pinot. Для отдельного раздела Kafka, когда текущий изменяемый сегмент полностью сохраняется, т.е. становится неизменяемым, контроллер Pinot создает следующий изменяемый сегмент и назначает его некоторому набору серверов Pinot. Начальное смещение нового изменяемого сегмента на единицу больше конечного смещения последнего зафиксированного сегмента. Обработка аналитических запросов выполняется брокером Pinot, который представляет собой stateless-сервер следующим образом [2]: клиентское приложение обращается к любому из развернутых в кластере Pinot брокеров; при получении запроса брокер определяет, какие сегменты (изменяемые и неизменяемые) необходимы для получения результата; брокер ищет информацию о местоположении сегмента через Helix и рассылает запрос на соответствующие серверы; каждый сервер локально выполняет полученный запрос, обрабатывая данные из своих локальных сегментов и отправляя промежуточный ответ брокеру; получив результаты с разных серверов, брокер объединяет их и отправляет окончательный ответ клиенту. «Под капотом» этого несложного на первый взгляд алгоритма спрятаны особенности, которые позволяют ускорить выполнение запросов за счет сокращения пересылаемых данных. По умолчанию брокер Pinot выбирает все доступные сегменты для обработки запроса, а отдельные серверы сокращают сегменты по критериям фильтрации запросов. Большой диапазон запросов увеличивает вероятность попадания в «медленный сервер» и, следовательно, влияет на общую задержку. Предупредить это можно, обрезав сегменты на уровне брокера, т.е. предварительно разбить их на разделы. Также можно заранее разделить данные Kafka с ksqlDB, применив «PARTITION BY» к столбцу, часто используемому в условии WHERE. Затем следует указать Pinot, что входные данные уже разделены по этому столбцу, используя поле segmentPartitionConfig внутри конфигурации таблицы Pinot. На основе этих данных брокер Pinot сократит список сегментов, которые необходимо запросить.

Например, данные из топика Kafka topic1 повторно разделяются на topic2 на основе выбранного столбца member_id. Таким образом, SQL-запрос обработки данных из таблицы Pinot, куда поступают данные из топика Kafka topic2, выглядит следующим образом [2]: select count(*) from pinot_table where member_id = 123 Если все записи с member_id=123 принадлежат разделу 1 топику Kafka topic2, то брокеру Pinot потребуется только запросить сегмент S1, что позволит выполнить запрос очень быстро.

Как выполнять SQL-запрос еще быстрее: управление памятью в сегментированных таблицах и общая latency всей Big Data системы

Наконец, отметим, как управление памятью в сегментированных таблицах Pinot влияет на общую задержку потоковой аналитики больших данных во всей Big Data системе на базе Apache Kafka. Изначально в Pinot изменяемый сегмент полностью управлялся в динамической памяти, упрощая реализацию таких структур данных, как словари, прямые и инвертированные индексы за счет к большого потребления памяти на хостах. Это увеличивало вероятность возникновения проблем со сборкой мусора (Garbage Collection), предупредить которые можно через следующие подходы [2]: память вне кучи (Off-heap memory), доступная для большинства структур данных, кроме инвертированного индекса; перенос неизменяемых сегментов, которые используют меньше резидентной памяти, чем изменяемые сегменты. Pinot позволяет перемещать неизменяемые сегменты на хосты, которые не потребляют данные от Kafka, чтобы обеспечить точное выделение ресурсов на них и снизить общую стоимость кластера. Также Pinot может использовать Kafka для координации между репликами. Два разных формата сегментов позволяют немедленно запрашивать данные, но имеют компактное и эффективное представление на диске. А управление памятью вне кучи в изменяемом сегменте Pinot делает таблицы реального времени более эффективными и повышает стабильность кластера. Узнайте больше об администрировании кластеров Apache Kafka, а также использования этой event-streaming платформы для интеграции информационных систем и разработки распределенных приложений потоковой аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве: Apache Kafka для разработчиков Администрирование кластера Kafka Источники 1. https://habr.com/ru/company/oleg-bunin/blog/351308/ 2. https://www.confluent.io/blog/real-time-analytics-with-kafka-and-pinot/

Read the full article

Link

portugalemdestaque 5 years ago

CLICKHOUSE - O novo paradigma da construção

portugalemdestaque

Video

zef-zef 5 years ago

zef-zef

“snaking and stretching along like a rubber band“ (BBC)

..