"OLAP с помощью Postgres (как мы строили BI)" Фефелов Андрей, Mastery.pro
2 likes1,973 views
Документ описывает архитектуру и подходы к обработке данных в BI-системе на базе PostgreSQL, применяемой крупнейшей фармацевтической группе в Ирландии. Основные темы включают OLAP, ROLAP, ETL vs ELT, особенности хранения данных, а также преимущества и недостатки использования PostgreSQL для BI. Автор делится опытом реализации и предоставляет рекомендации по оптимизации инфраструктуры и процессам аналитики.
"OLAP с помощью Postgres (как мы строили BI)" Фефелов Андрей, Mastery.pro
- 2. Содержание • Постановка задачи • WTF is OLAP • ROLAP • Обзор нашей архитектуры • Особенности Postgres для BI • ETL vs ELT (stage-nds-ddm) • Column data storage • Configuration • Фишечки • Плюсы/минусы решения 2
- 3. Постановка задачи • Заказчик – крупнейшая в Ирландии фармацевтическая группа • 4 типа аптечного ПО • 250 аптек • Анализировать: • Заказы (Orders) • Рецепты (Scripts) • Возмещения (Claims) • Цели: • Оптимизации товарной политики • Маркетинг 3
- 4. WTF is OLAP • OnLine Analytical Processing • Куб из n-измерений 4
- 6. 6
- 7. Postgres • opensource • ssd • column storage • pl/pgsql • rich feature set • умеем готовить 7
- 8. ROLAP 8
- 10. Архитектура - extractors • Cyclone_client • Mssql (2008-2012) • Golang • CSV + rsync over ssh • Kachok • Web scrapper • Skytools replication • From existing products Extractors Postgres (Load Transform) Cubes (API) Rails + React (UI) Saiku (UI) 10
- 11. Архитектура – API + UI • Cubes - cubes.databrewery.org • Easy drilling-down • Slicing and dicing • Serves aggregates, dimension details, facts • Provides all necessary metadata for a reporting application • Rails, React • Авторизация • d3, dc, crossfilter • Saiku • Только для бэк-офиса Extractors Postgres (Load Transform) Cubes (API) Rails + React (UI) Saiku (UI) 11
- 12. Архитектура – Postgres (load, transform) •raw data •load_something_to_nds(_pharmacy_id integer)stage •normalized data store •load_something_to_ddm(_pharmacy_id integer)nds •Кубы и снэпшоты •viewsddm 12
- 13. Архитектура – Postgres (load, transform) Stage • «Cырые» данные • Полностью очищается в каждом цикле ELT • Служит источником для nds • raw data • load_something_to_nds(_ pharmacy_id integer) stage •normalized data store •load_something_to_ddm(_pharmacy_id integer) nds •Кубы и снэпшоты •viewsddm 13
- 14. Архитектура – Postgres (load, transform) • Normalized Data Store • Данные нормализуются и валидируются • Служит источником для ddm • Вычисляются меры перед загрузкой в ddm • Вычисляется delta для загрузки в ddm на основе last_updated • raw data • load_something_to_nds (_pharmacy_id integer) stage •normalized data store •load_something_to_ddm(_ pharmacy_id integer) nds • Кубы и снэпшоты • viewsddm 14
- 15. Архитектура – Postgres (load, transform) • Dimensional data model • Кубы • Снэпшоты тоже здесь • Спокойно делать релизы • Анализировать состояния «до-после» релиза • View как точка входа для приложения • raw data • load_something_to_nds (_pharmacy_id integer) stage •normalized data store •load_something_to_ddm(_ pharmacy_id integer) nds • Кубы и снэпшоты • viewsddm 15
- 18. Column storage • Подходит для задачи: • агрегаций • вывод фиксированного набора полей из кубов • cstore_fdw -> https://github.com/citusdata/cstore_fdw • Compression: Reduces in-memory and on-disk data size by 2-4x. Can be extended to support different codecs. • Column projections: Only reads column data relevant to the query. Improves performance for I/O bound queries. • Skip indexes: Stores min/max statistics for row groups, and uses them to skip over unrelated rows. 18
- 19. Column storage • Наш опыт: • Не быстрее на нашем профиле, чем “ванильный” postgres (привет, cubes) • Размер кубов уменьшился в 12 раз. Wow. • Не бэкапится стандартным образом (no need?) • Не поддерживает delete/update (snapshots) 19
- 20. Фишечки • DDM может быть вынесена на отдельный сервер (londiste) • Используйте COPY/BULK INSERTS не используйте UPDATE (ха ха ха) • Думайте о горизонтальном и вертикальном партиционировании, поищите хорошие ключи для этого • Думайте о параллелизме с самого начала • Используйте TABLESPACES/PARTIAL INDEXES (и больше дисков) • Вам нужна политика хранения данных 20
- 21. Плюсы и минусы решения • Минусы • Плохо масштабируется горизонтально • Сложный деплой • Плюсы • Local data (no big network transfers) • Effectively parallelized (thanks to pharmacy_id) • PL/pgSQL 21
- 23. Speed limit • cubes не быстрый (сериализация) • json (12 sec) • ujson (4 sec) • postgres json output (1.5 sec) db self time 0.3-0.7 sec 23