Недавно перед нашей командой встала непростая задача: объем данных для аналитики вырос до 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-аналитику, я видел одну и ту же ошибку: попытку встроить аналитику в архитектуру приложения как обычный модуль. Это не работает, и вот почему.