Сегодня для того, чтобы данные действительно работали на бизнес, недостаточно просто собрать и обработать их. Необходимо превратить их в понятные и удобные решения – своего рода аналитические продукты, которые приносят реальную пользу. Проще говоря, аналитический продукт (он же data product) – это автоматизированная цепочка действий над данными, результатом которой является полезная информация или рекомендация для решения конкретной бизнес-задачи. Появление таких продуктов стало возможным благодаря построению централизованной аналитической платформы с полной архитектурой данных от интеграции до представления. Иными словами, чтобы данные приносили пользу, они должны пройти путь от извлечения из источников до представления в понятной форме, охватывая этапы интеграции, обработки, представления и управления данными.

Наша «база» — единая аналитическая платформа, реализованная по принципам, применяемым в зрелых data-driven компаниях. В её основе – современный техстек, включающий стриминговую шину данных Apache Kafka на слое интеграции (Stage), высокопроизводительное хранилище ClickHouse на уровнях ODS/DWH/Data Mart, оркестратор пайплайнов Apache Airflow (с использованием dbt) для ETL/ELT и контроля качества данных, систему метаданных OpenMetadata для управления информацией о данных, BI-платформу Yandex DataLens для визуализации, а также собственный REST API-слой для интеграции с внешними системами. Такой подход обеспечивает масштабируемость и воспроизводимость: наша база данных поглощает до сотен миллионов записей в сутки и почти мгновенно выдаёт результаты аналитических запросов благодаря ClickHouse. Все инструменты связаны в единую архитектуру, где потоки событий из источников сразу попадают в Kafka, оттуда – в ClickHouse, после чего данные доступны для построения витрин, дашбордов, алертов и API-интеграций в реальном времени.

Apache Airflow давно стал стандартом в мире Data Engineering благодаря своей гибкости, масштабируемости и богатой экосистеме. В этой статье мы подробно разберём, что такое Airflow, почему он так популярен, как эффективно использовать его в аналитической архитектуре, а также предоставим максимально подробную инструкцию по развертыванию Airflow.

Сегодня данные являются ключевым ресурсом для любого бизнеса. Но прежде чем они превратятся в полезную информацию, пригодную для принятия решений, данные проходят длительный и многоступенчатый путь — от извлечения до представления конечному пользователю. Именно этот процесс получил название ETL (Extract, Transform, Load).

Процесс ETL включает:

Недавно перед нашей командой встала непростая задача: объем данных для аналитики вырос до 300 миллионов строк в день. Прежние решения перестали справляться с такой нагрузкой, отчеты строились слишком медленно, а масштабировать существующую систему было дорого и сложно. Нужно было срочно находить новое решение для хранилища данных (DWH), способное глотать миллионы строк ежедневно и отдавать результат аналитических запросов практически мгновенно.

После оценки различных вариантов (классические СУБД, облачные DWH и др.) мы остановились на ClickHouse. Эта колоночная база данных открытого кода изначально создавалась для работы с большими объемами потока событий. ClickHouse славится впечатляющей скоростью агрегаций и фильтрации на терабайтах данных и отлично подходит для аналитики при больших нагрузках. В этой статье расскажем, как мы выбрали и внедрили ClickHouse в нашем проекте, построив систему сбора и анализа данных с нагрузкой сотни миллионов строк в сутки.

Поговорим об архитектуре (как данные летят из Kafka в ClickHouse), о двух подходах загрузки данных (пакетная и стриминговая), о том, какие табличные движки ClickHouse мы использовали и зачем, как нам помогли материализованные представления, об оркестрации процессов через Airflow и dbt. Отдельно разберем типичные ошибки, с которыми столкнулись в процессе, и поделимся улучшениями, которые планируем учесть при следующей реализации подобного решения.

Всем привет! В этой статье поделюсь нашим опытом использования Apache Kafka на слое Stage в аналитической архитектуре. Мы поговорим о том, что такое слой Stage и зачем он нужен, почему именно Kafka стала нашим выбором, как устроен процесс ingest (приёма данных) на базе Kafka, что можно и чего делать не стоит на этом этапе, какие грабли нас ждали и как мы их преодолели, а также дам практические советы из реального опыта. Спойлер: Kafka оказалась не просто очередным модным словом, а действительно упростила нам жизнь в аналитическом проекте. Поехали!

Централизованная аналитика — это фундамент эффективного принятия решений в компании. Чтобы данные действительно работали на бизнес, они должны пройти путь от извлечения до представления в понятной форме. Один из наиболее известных и проверенных временем подходов — архитектура, построенная на четырех ключевых модулях: интеграция, обработка, представление и управление. В этой статье мы познакомимся с каждым из них, а также рассмотрим один из рабочих вариантов реализации (DQ, BI, метаданные и др.).

Современный бизнес нуждается в гибкой и быстрой аналитике. Однако далеко не у всех компаний есть ресурсы, чтобы внедрить полноценное хранилище данных, построить витрины, разработать десятки отчётов и BI-дашбордов. И даже если такая система существует, запросы от пользователей зачастую выходят за пределы заранее разработанных визуализаций: "А можно посмотреть это по неделям, но только по новым клиентам и только для региона X, исключая сегмент Y?".

В этой статье я покажу, как с помощью Power BI и Excel можно построить модель, которая:

- Даёт пользователям гибкость при анализе данных

- Использует Power BI как логическую модель

- Позволяет работать с моделью напрямую из Excel — без SQL и без BI-дэшбордов

Когда владельцы бизнеса просят команду IT «добавить аналитику» в продукт, часто это заканчивается болью — и для разработчиков и для самого бизнеса. За последние несколько лет я участвовал в построении аналитических решений более чем в 10 компаниях — от стартапов до крупных корпораций. Почти во всех компаниях среднего уровня, только начинающих выстраивать BI-аналитику, я видел одну и ту же ошибку: попытку встроить аналитику в архитектуру приложения как обычный модуль. Это не работает, и вот почему.