Системы агрегации данных
От: Буравчик Россия  
Дата: 18.04.20 08:55
Оценка:
Есть БД с сырыми данными, объем пока около сотни гигабайт.
На основе этих сырых данных рассчитываются агрегированные данные.
Алгоритмы агрегации достаточно сложны, это не всегда простое сложение, максимум.
На основе агрегированных данных в конечном итоге строятся запросы, дашборды и т.п.

Добавление в БД может быть долгим, но выборка из нее должна быть быстрой.
Предполагается рассчитывать агрегированные данные заранее — в различных разрезах.
Плюс имеются несколько слоев агрегации, сырые данные -> часы, часы -> дни, дни -> месяцы
Плюс данные могут меняться задним числом.

Возможно, существуют системы, с помощью которых можно управлять такой агрегацией.
Которые определяют изменившиеся части данных, управляют запуском пересчетов и т.п.

Есть такие системы / подходы? Как они называются, что почитать? Или все всегда строится вручную?

P.S. Стек технологий — любой
Best regards, Буравчик
Re: Системы агрегации данных
От: Dym On Россия  
Дата: 18.04.20 09:01
Оценка: +1
Здравствуйте, Буравчик, Вы писали:

Б>Есть такие системы / подходы? Как они называются, что почитать? Или все всегда строится вручную?

OLAP, оно?
Счастье — это Glück!
Re: Системы агрегации данных
От: Gurney Великобритания www.kharlamov.biz
Дата: 18.04.20 10:44
Оценка: 21 (2)
Здравствуйте, Буравчик, Вы писали:

Б>Алгоритмы агрегации достаточно сложны, это не всегда простое сложение, максимум.

Б>На основе агрегированных данных в конечном итоге строятся запросы, дашборды и т.п.
Б>Возможно, существуют системы, с помощью которых можно управлять такой агрегацией.
Б>Которые определяют изменившиеся части данных, управляют запуском пересчетов и т.п.
Б>Есть такие системы / подходы? Как они называются, что почитать? Или все всегда строится вручную?

В целом я бы посмотрел на аналитические базы данных. Они сейчас планомерно вытесняют OLAP, и относительно дешевы.

В принципе существует 3 группы технологий:
1. Analytical Databases (Vertica, Snowflake, AWS Athena, SparkSQL)
+ Философия — загрузим данные, а обработки будем делать по мере поступления запросов
+ В связи с этим выше процент успешных проектов
+ Бежит на относительно дешевом железе и сами недороги
+ Позволяет строить materialised views с автоматическим пересчетом, и при помощи них оптимизировать запросы
+ Более дружественная к современным разработчикам знающим про CI/CD
+ Горизонтальная масштабируемость под объемы данных и число разработчиков (если никто не выполняет
запросы, ты платишь только за хранение данных)
+ Приемлемая скорость разработки
— Выглядит "как нормальная БД". В связи с чем люди из OLTP пытаются ее пользовать как таковую. Результаты
обычно плачевные.
— Требует перестройки мышления и соответствующего дизайна схемы
— Медленные updates

2. OLAP (Oracle, Microsoft, etc). Имеет смысл _до_ единиц ТБ
+ Философия — все сделать заранее.
+ Enterprise решения от больших компаний с историей в 40 лет и более.
+ По фичам впереди всего остального.
+ Достаточно много документации, best practices и т. д.
— Требует перестройки мышления и соответствующего дизайна схемы
— Медленные цикл разарботки, про вещи типа тестирования, CI/CD, version control, merging там не слышали
— Дорого (лицензии, железо, консультанты)
— Медленные updates.


3. Spark/Hive (Имеет смысл начиная с 50ТБ)
+ Философия — загрузим данные, а обработки будем делать по мере поступления запросов
+ Очень высокая масштабируемость по объему данных
+ Бежит на дешевом железе
+ Бесплатные
— Многие интеграции и орекстрация требует доработки напильником
— Выглядит "как нормальная БД". В связи с чем люди из OLTP пытаются ее пользовать как таковую. Результаты
обычно плачевные.
— Требует перестройки мышления и соответствующего дизайна схемы
— Апдейты — нет, не слышали
— Плохо работает с маленькими объемами данных
— Нужны достаточно серьезные профи в разработке
— Низкий процент успешных проектов, ибо какой-же студент не мнит себя суперпрофессионалом
— Документация очень отрывочная
Re[2]: Системы агрегации данных
От: Буравчик Россия  
Дата: 19.04.20 16:10
Оценка:
Здравствуйте, Gurney, Вы писали:

Спасибо. Но не все понятно.

Еще раз про задачу. Есть сырые данные (БД1), в нее текут постоянно данные. Проблемы:
1. Преобразование БД1 в БД2 (по специальным алгоритмам)
2. Предоставление быстрого доступа к БД2.

Для реализации пункта 1 предполагалось:
— отслеживать "участки изменений" в БД1
— сделать воркер, который будет объединять эти маленькие изменившиеся участки в участки большего размера, пересчитывать большие блоки БД1 и класть результаты расчетов в БД2

Для реализации пункта 2:
— поверх БД2 построить агрегированную базу БД3 (по часам), поверх неё агрегированную БД4 (по дням) и т.п.
— при обновлении БД2 периодические пересчитывать БД3, затем пересчитывать БД4 и т.д. (хранить изменения в очередях)

Собственно, показалось, что изобретаю велосипед. Многоуровневая организация данных БД2 — БД3 — БД4 для агрегации кем-то должна быть решена.

Теперь касаем этих технологий. Поправьте меня:

G>В принципе существует 3 группы технологий:

G>1. Analytical Databases (Vertica, Snowflake, AWS Athena, SparkSQL)

ClickHouse и Apache Druid сюда же?

Здесь работаем с БД2. Агрегации рассчитываются реалтайм.
БД3 и БД4 не нужны. Работает быстро за счет колоночной организации данных.

Как решается вопрос преобразования БД1 в БД2?

G>2. OLAP (Oracle, Microsoft, etc). Имеет смысл _до_ единиц ТБ


Здесь в OLAP предоставляется готовая БД2.
Могу рассчитать заранее кучу агрегаций (собственно это и есть БД3 и БД4, которые строятся автоматически)
При изменении БД2 нужно все агрегации считать заново, что долго.

Процесс преобразования БД1 в БД2 остается за рамками технологии.

G>3. Spark/Hive (Имеет смысл начиная с 50ТБ)


Здесь работаем с БД2. Агрегации по ней рассчитываются реалтайм.
Работает быстро за счет распределения работы по серверам.

Как решается вопрос преобразования БД1 в БД2?


В целом — технологии позволяют так или иначе решить второй блок задач — быстрая работа с БД2.
Но как в них решается вопрос с первым блоком задачи — преобразования БД1 в БД2, отслеживание потока изменений БД1 и т.п.
Или эта часть делается всегда "вручную"?
Best regards, Буравчик
Re[3]: Системы агрегации данных
От: Gurney Великобритания www.kharlamov.biz
Дата: 20.04.20 08:04
Оценка:
Здравствуйте, Буравчик, Вы писали:

Б>В целом — технологии позволяют так или иначе решить второй блок задач — быстрая работа с БД2.

Б>Но как в них решается вопрос с первым блоком задачи — преобразования БД1 в БД2, отслеживание потока изменений БД1 и т.п.
Б>Или эта часть делается всегда "вручную"?

Тут слишком мало деталей чтобы понять что это за специальные алгоритмы, про которые вы говорите. В зависимости от
ответа на этот вопрос многое зависит.

Начиная с того, что формулировка задачи: "данные льются в БД1" ошибочна в 95% случаев. Люди делают не представляя последствий,
как правило. А потом огребаются с проблемами ресинхронизации downstream зависимостей, ибо они очень специальные для каждого случая и требуют ручной работы.

Вы бы написали, что конкретно нужно, на каких объемах и тд. А так решать абстрактного коня в вакууме очень сложно.
Re[4]: Системы агрегации данных
От: Буравчик Россия  
Дата: 20.04.20 12:06
Оценка:
Здравствуйте, Gurney, Вы писали:

G>Начиная с того, что формулировка задачи: "данные льются в БД1" ошибочна в 95% случаев. Люди делают не представляя последствий,как правило.


Сейчас данные идут потоком по сервисам AWS, складируются в S3. Далее воркеры с некоторой периодичностью забирают данные из S3, немного чистят их и перекладывают в БД1 (обычная SQL-база с индексами), которая используется для онлайн-запросов. В чем может быть ошибка?

G>А потом огребаются с проблемами ресинхронизации downstream зависимостей, ибо они очень специальные для каждого случая и требуют ручной работы.


Можно чуть подробнее про "проблемы ресинхронизации downstream зависимостей", что это?
Best regards, Буравчик
Re: Системы агрегации данных
От: Milena США  
Дата: 20.04.20 17:12
Оценка: 122 (6)
Здравствуйте, Буравчик, Вы писали:

Б>Есть БД с сырыми данными, объем пока около сотни гигабайт.

Б>На основе этих сырых данных рассчитываются агрегированные данные.
Б>Алгоритмы агрегации достаточно сложны, это не всегда простое сложение, максимум.
Б>На основе агрегированных данных в конечном итоге строятся запросы, дашборды и т.п.
Типичное аналитическое хранилище данных (data warehouse) с разными видами факт-таблиц.

Б>Добавление в БД может быть долгим, но выборка из нее должна быть быстрой.

Схема, оптимизарованная под чтение. База данных должна быть в идеале column-store.

Б>Предполагается рассчитывать агрегированные данные заранее — в различных разрезах.

Б>Плюс имеются несколько слоев агрегации, сырые данные -> часы, часы -> дни, дни -> месяцы
Да, на каждый тип агрегации (grain level) должна быть разная факт-таблица. Иногда делают OLAP-кубы, но они сильно тормозят на больших объемах, поэтому лучше в это не лезть.
Б>Плюс данные могут меняться задним числом.



Б>Возможно, существуют системы, с помощью которых можно управлять такой агрегацией.

Посмотрите в сторону предложений в области хранилищ данных. Лидеры рынка сейчас:
1. В облаках: Amazon Redshift, Microsoft Azure SQL Warehouse, Snowflake, Big Query (не совсем DW, а скорее Query engine)
2. Решения в области Data Lakes. Это будет быстрее сделать технически, так как данных хранятся в файлах и будет schema-on-read, но это более "холодные" данные, а по сему выборка медленнее,больше проблем с качеством, нужно разбираться, как делать патриции и т.д. Там своя теория, нужно много читать, прежде чем получится толковое решение.
3. Можно взять традиционные движки БД и попробовать сделать star schema там, но опять же нужно правильно патриции сделать. В MySQL есть возможность переключаться с OLTP на OLAP движок.
Б>Которые определяют изменившиеся части данных, управляют запуском пересчетов и т.п.
Изменившиеся части (транзакции) в исходной ("сырой") системе мониторятся через CDC (change data capture) или CT (change tracking). Все современные ETL продукты имеют такой функционал встроенным в продукт, но если писать самим, просто почитать теорию хранилищ данных и как делать правильно Merge изменений, правильно подобрать SCD type (slowly changing dimensions).

Б>Есть такие системы / подходы? Как они называются, что почитать? Или все всегда строится вручную?

1. Книги по теории архитектуры хранилищ данных. Лучше всего начать с Кимбалла и Инмона.
2. Документация и white papers современных систем для Data Platforms. Все доступно тонлайн и бесплатно.
3. Теория по data lakes: преимущества и отличия от традиционных хранилищ данных.
4. Если есть доступ к онлайн-курсам, есть хороший курс на Pluralsight по этому делу. Ну или просто видео на YouTube посмотреть: data warehousing, star schema fundamentals, fact tables design.

P.S. Я работаю Data Architect, делаю такие системы с утра до вечера, если есть специфические вопросы — могу дать более конкретный ответ.
Re[2]: Системы агрегации данных
От: Буравчик Россия  
Дата: 20.04.20 20:21
Оценка:
Здравствуйте, Milena, Вы писали:

M>Типичное аналитическое хранилище данных (data warehouse) с разными видами факт-таблиц.

M>Схема, оптимизарованная под чтение. База данных должна быть в идеале column-store.
M>Да, на каждый тип агрегации (grain level) должна быть разная факт-таблица. Иногда делают OLAP-кубы, но они сильно тормозят на больших объемах, поэтому лучше в это не лезть.
M>Посмотрите в сторону предложений в области хранилищ данных. Лидеры рынка сейчас:

Спасибо, очень интересно.

M>1. Книги по теории архитектуры хранилищ данных. Лучше всего начать с Кимбалла и Инмона.

M>2. Документация и white papers современных систем для Data Platforms. Все доступно тонлайн и бесплатно.
M>3. Теория по data lakes: преимущества и отличия от традиционных хранилищ данных.
M>4. Если есть доступ к онлайн-курсам, есть хороший курс на Pluralsight по этому делу. Ну или просто видео на YouTube посмотреть: data warehousing, star schema fundamentals, fact tables design.

Ушел читать литературу и изучать терминологию.

M>P.S. Я работаю Data Architect, делаю такие системы с утра до вечера, если есть специфические вопросы — могу дать более конкретный ответ.


Много интересного, захотелось стать data architect

Вернусь, когда немного въеду в тему. Вопросы будут, вероятно.
Best regards, Буравчик
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.