Здравствуйте, Буравчик, Вы писали:
Б>Есть БД с сырыми данными, объем пока около сотни гигабайт. Б>На основе этих сырых данных рассчитываются агрегированные данные. Б>Алгоритмы агрегации достаточно сложны, это не всегда простое сложение, максимум. Б>На основе агрегированных данных в конечном итоге строятся запросы, дашборды и т.п.
Типичное аналитическое хранилище данных (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, делаю такие системы с утра до вечера, если есть специфические вопросы — могу дать более конкретный ответ.
Здравствуйте, Буравчик, Вы писали:
Б>Алгоритмы агрегации достаточно сложны, это не всегда простое сложение, максимум. Б>На основе агрегированных данных в конечном итоге строятся запросы, дашборды и т.п. Б>Возможно, существуют системы, с помощью которых можно управлять такой агрегацией. Б>Которые определяют изменившиеся части данных, управляют запуском пересчетов и т.п. Б>Есть такие системы / подходы? Как они называются, что почитать? Или все всегда строится вручную?
В целом я бы посмотрел на аналитические базы данных. Они сейчас планомерно вытесняют 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 пытаются ее пользовать как таковую. Результаты
обычно плачевные.
— Требует перестройки мышления и соответствующего дизайна схемы
— Апдейты — нет, не слышали
— Плохо работает с маленькими объемами данных
— Нужны достаточно серьезные профи в разработке
— Низкий процент успешных проектов, ибо какой-же студент не мнит себя суперпрофессионалом
— Документация очень отрывочная
Есть БД с сырыми данными, объем пока около сотни гигабайт.
На основе этих сырых данных рассчитываются агрегированные данные.
Алгоритмы агрегации достаточно сложны, это не всегда простое сложение, максимум.
На основе агрегированных данных в конечном итоге строятся запросы, дашборды и т.п.
Добавление в БД может быть долгим, но выборка из нее должна быть быстрой.
Предполагается рассчитывать агрегированные данные заранее — в различных разрезах.
Плюс имеются несколько слоев агрегации, сырые данные -> часы, часы -> дни, дни -> месяцы
Плюс данные могут меняться задним числом.
Возможно, существуют системы, с помощью которых можно управлять такой агрегацией.
Которые определяют изменившиеся части данных, управляют запуском пересчетов и т.п.
Есть такие системы / подходы? Как они называются, что почитать? Или все всегда строится вручную?
Еще раз про задачу. Есть сырые данные (БД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 и т.п.
Или эта часть делается всегда "вручную"?
Здравствуйте, Буравчик, Вы писали:
Б>В целом — технологии позволяют так или иначе решить второй блок задач — быстрая работа с БД2. Б>Но как в них решается вопрос с первым блоком задачи — преобразования БД1 в БД2, отслеживание потока изменений БД1 и т.п. Б>Или эта часть делается всегда "вручную"?
Тут слишком мало деталей чтобы понять что это за специальные алгоритмы, про которые вы говорите. В зависимости от
ответа на этот вопрос многое зависит.
Начиная с того, что формулировка задачи: "данные льются в БД1" ошибочна в 95% случаев. Люди делают не представляя последствий,
как правило. А потом огребаются с проблемами ресинхронизации downstream зависимостей, ибо они очень специальные для каждого случая и требуют ручной работы.
Вы бы написали, что конкретно нужно, на каких объемах и тд. А так решать абстрактного коня в вакууме очень сложно.
Здравствуйте, Gurney, Вы писали:
G>Начиная с того, что формулировка задачи: "данные льются в БД1" ошибочна в 95% случаев. Люди делают не представляя последствий,как правило.
Сейчас данные идут потоком по сервисам AWS, складируются в S3. Далее воркеры с некоторой периодичностью забирают данные из S3, немного чистят их и перекладывают в БД1 (обычная SQL-база с индексами), которая используется для онлайн-запросов. В чем может быть ошибка?
G>А потом огребаются с проблемами ресинхронизации downstream зависимостей, ибо они очень специальные для каждого случая и требуют ручной работы.
Можно чуть подробнее про "проблемы ресинхронизации downstream зависимостей", что это?
Здравствуйте, 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
Вернусь, когда немного въеду в тему. Вопросы будут, вероятно.
