#olap — Public Fediverse posts

Почему тип `numeric` в PostgreSQL такой медленный?

Три независимые попытки сделать для PostgreSQL быстрый точный десятичный тип расширением заглохли. Но не потому, что не получилось ускорить арифметику — арифметику как раз каждое из них ускоряло. Тогда в чём же дело? Здесь я разбираю технические решения в устройстве numeric, которые приводят к высокой стоимости использования этого типа данных. Изучение провожу в сравнении с устройством типа decimal в DuckDB - будучи OLAP СУБД он свободен от некоторых ограничений PostgreSQL и гонясь за производительностью выбирал другой путь развития. Копнуть матчасть

https://habr.com/ru/companies/tantor/articles/1073040/

#postgresql #numeric #decimal #duckdb #типы_данных #производительность #внутренности_СУБД #olap

Learn all about using #DuckDB with #Python at #techbash 2026.

Join us in the #poconos on Oct 13-16: https://techbash.com/

#programming #olap #database #developers #learning #kalahariresort #devcommunity

От 12 часов к 30 минутам: как мы join’им миллиарды товарных движений в ClickHouse

Всем привет! Меня зовут Муса. Наша команда занимается витринами данных по товарному учёту. Каждый день мы доставляем около 10 млрд записей в разных форматах. На этих данных строится различная аналитика, связанная с товарными запасами и движениями экземпляров. Перед нами встала задача: пять раз в день обогащать выгрузку из миллиардов экземплярных остатков дополнительными атрибутами для построения различного рода аналитики. История этих атрибутов уже измерялась десятками миллиардов записей. Первое решение выглядело просто: положить данные в ClickHouse и сделать JOIN. Но одна выгрузка считалась около 12 часов, а нам нужно было укладываться в десятки минут. В статье расскажу, про то, как мы смогли сократить время обработки примерно до 33 минут, про ключевой подход при работе с большими объёмами данных, а также попытаюсь донести важность локальности данных на примере реальной задачи.

https://habr.com/ru/companies/ozontech/articles/1064182/

#highload #clickhouse #backend #systemdesign #bigdata #базы_данны #sql #olap #архитектура_данных #ozon_tech

Тестирование СУБД с использованием tpc-ds и методы сравнительного анализа

Как выбрать аналитическую СУБД, если одна быстрее, другая проще в эксплуатации, а третья лучше поддерживает нужный SQL? Рассказываю о нашем исследовании: TPC-DS и SSB, экспертные критерии и метод комплексной оценки с расчётом, который можно повторить на своих данных.

https://habr.com/ru/articles/1066926/

#СУБД #OLAP #TPCDS #SSB #TPCH #нагрузочное_тестирование #многокритериальный_анализ #нормализация

Оптимизация MPP-кластера: предсказываем потребление памяти SQL-запросов

В аналитике больших данных системы массивных параллельных вычислений часто находятся под постоянной нагрузкой в режиме 24/7. Из десятков и сотен тысяч запросов в день многие исполняются одновременно и конкурируют за ограниченные ресурсы вычислительного кластера. Чем рациональнее каждый отдельный запрос их использует, тем больше запросов система сможет обслуживать параллельно. Соответственно, выше пропускная способность за конкретный отрезок времени. Как правило, проблема нехватки ресурсов остро ощущается в пиковые часы нагрузки. Можно бесконечно до совершенства настраивать и править параметры сессии на каждый запрос индивидуально вручную, но нам — команде разработки платформы данных Data Ocean Nova — всегда хочется иметь более системный подход. В сегодняшней публикации мы расскажем о том, как реализовали идею автоматической системы предсказания потребления ресурсов SQL-запросами для Impala и StarRocks, основанную на ML-принципах, и сделали её частью платформы данных.

https://habr.com/ru/companies/datasapience/articles/1061866/

#mpp #impala #starrocks #bigdata #dwh #lakehouse #ml #olap

ClickHouse: сценарии, сильные стороны, лучшие практики работы в 2026 году

ClickHouse — один из самых востребованных инструментов для хранения и анализа больших объемов данных, обеспечивающий высокую производительность и наблюдаемость сервисов и приложений. Благодаря этим параметрам многие компании внедряют его в свои ИТ-инфраструктуры для решения задач аналитики, логирования и мониторинга. Однако, несмотря на широкое распространение, практика показывает, что далеко не все команды до конца осознают все особенности и нюансы работы с этой системой, что может приводить к неэффективному использованию ресурсов, ошибкам в проектировании и снижению общей производительности. Привет, Хабр. Меня зовут Александр Кривяков. Я пресейл-архитектор VK Data Platform , VK Tech. В этой статье я расскажу об основных принципах работы ClickHouse, а также покажу возможные архитектурные решения и типичные сценарии применения системы.

https://habr.com/ru/companies/vktech/articles/1061284/

#vk_cloud #clickhouse #olap #колоночное_хранение #большие_данные #data_platform #логирование #метрики #архитектура_данных #best_practices

Пока все хоронили пайплайны, ClickHouse достраивал слои

«Отдельные базы больше не нужны», «конец пайплайнов» - каждую неделю кто-то крупный со сцены хоронит то, что ты вчера поставил в прод. ClickHouse поступил ровно наоборот, и поэтому его анонсы стоит прочитать внимательно. Что реально показали на Open House 2026 и что из этого доедет до прода - разбор практика без вендорского глянца.

https://habr.com/ru/articles/1056292/

#clickhouse #postgresql #Clickstack #olap #lakehouse #data_engineering #observability #колоночная_субд #ClickHouse_Agents #Open_House_2026

TPC-DS в 07.2026. Lakehouse: Spark, Trino, StarRocks, Impala и Doris. GreenPlum & Cloudberry vs StarRocks как MPP

Привет, Хабр! На связи команда Data Sapience. С последней публикации результатов тестирования MPP-движков прошло уже несколько месяцев. За этот период произошел ряд изменений в базовых версиях open source движков и фреймворков, а также наша команда разработки внесла ряд улучшений и доработок. Все это может повлиять расстановку сил в рейтинге. В сегодняшней публикации мы представим максимальное число претендентов, среди которых: Spark 3.5.*, Spark 3.5.* + DataFusion Comet, Spark 4.0.1, Spark 4.0.1 + DataFusion Comet, StarRocks (core based 3.5+, 4.0+), Impala (core based 4.5), Trino (459, 476, 479) и новичок нашего рейтинга — Apache Doris. Статья поможет вам ответить на вопросы: стоит ли переходить на Spark 4 в поисках производительности; Как нативные вычисления влияют на результаты Spark; Как улучшилась производительность Trino за последние полгода; нужно ли присмотреться к Apache Doris, если вы ищете альтернативу Impala и StarRocks, и как эти проекты связаны между собой; какие оптимизационные улучшения были добавлены нами в StarRocks и Impala за последнее время. И на десерт мы покажем вам сравнение Greenplum, Cloudberry и StarRocks в режиме Shared-Nothing MPP.

https://habr.com/ru/companies/datasapience/articles/1054316/

#starrocks #trino #spark #impala #greenplum #bigdata #dwh #lakehouse #olap

Как убрать ручную сборку финансовой отчетности: OLAP-модель, семантический слой и живые отчеты в Excel

Финансовые данные в компании обычно уже есть: в 1С, в хранилище, витринах, аналитических кубах. Но в конце отчётного периода аналитики всё равно часто делают одно и то же: выгружают числа в Excel, собирают сводные таблицы, вручную считают отклонения и готовят презентации для руководства. В этой статье покажем, как перевести такой процесс в промышленный контур: создать OLAP-модель, вынести бизнес-логику в семантический слой и получать живые отчёты в Web, Excel и LibreOffice без ручного копипаста. Выгружать данные будем из 1С, но в виду большого количества способов это сделать мы коснёмся этой темы в следующей статье, а здесь сосредоточимся я на возможностях анализа данных. Статья будет особенно полезна: - BI-разработчикам; - архитекторам данных; - бизнес-аналитикам; - финансистам; - руководителям, которым важно быстро получать корректную управленческую отчётность.

https://habr.com/ru/companies/sberbank/articles/1050458/

#olap #olapкубы #аналитика_данных

Как мы перестали гонять данные туда-сюда и подружили OLTP с аналитикой: знакомьтесь, Postgres Pro AXE

«HTAP», «единая платформа для OLTP и OLAP», «никаких ETL» — такие обещания в индустрии делают каждые полгода. Обычно за этим следуют компромиссы: либо транзакции деградируют, либо аналитика тормозит, либо архитектура превращается в Франкенштейна. Мы расскажем, что конкретно сделали в Postgres Pro AXE — и почему это работает иначе.

https://habr.com/ru/companies/postgrespro/articles/1049148/

#Postgres_Pro_AXE #axe #база_данных #аналитика_данных #статистика #postgresql #htap #oltp #olap

Как Data Fabric и HTAP превращают сырые данные в бизнес-события для мгновенной аналитики

Долгое время главным критерием качества данных считалась их чистота и полнота. Компании инвестировали значительные ресурсы в MDM-системы и процессы проверки, стремясь получить «единую версию правды». Однако сегодня этого уже недостаточно. В условиях, когда скорость реакции определяет успех, на первый план выходит новый критерий — актуальность. Способность данных отражать реальное положение дел в момент принятия решения становится решающим фактором. При этом классические архитектуры, основанные на ночных загрузках в DWH, создают временной лаг, который превращает «правду» во «вчерашнюю». Привет, Хабр. Меня зовут Александр Шалудин. Я Presale-архитектор Data Services VK Tech. В этой статье я разберу, к чему может приводить работа с неактуальной информацией и как выстроить архитектуру, которая позволит устранить этот разрыв. Из-за высокой конкуренции и сопутствующих вызовов многие компании стремятся стать Data-Driven, то есть принимать решения, основываясь на данных, чтобы сохранять конкурентоспособность, быстро реагировать на тренды и взвешенно оценивать бизнес-процессы. Однако точность этих решений напрямую зависит не только от качества информации, но и от ее актуальности и доступности в нужный момент. Ключевая угроза здесь — задержка данных. Это не просто неудобство, а прямые скрытые расходы. Компания может иметь выстроенные процессы контроля качества и полные справочники, но, если ответ от аналитической системы нужен сегодня, а данные поступят только завтра или через неделю, их ценность для принятия оперативных решений стремится к нулю.

https://habr.com/ru/companies/vktech/articles/1044946/

#tarantool_column_store #htap #data_fabric #oltp #olap #realtime_analytics #tarantool #etl #mdm #vk_tech

rapeed: in-memory OLAP-движок с собственной алгеброй связей

Меня зовут Андрей Рыжик, я Product Owner BI-направления в компании «Белый код». Эта статья – обзор платформы rapeed: in-memory OLAP-движка с собственным форматом хранения, нестандартной алгеброй связей между источниками и несколькими клиентами поверх единого ядра.

https://habr.com/ru/companies/w_code/articles/1042524/

#bi #olap #inmemory #аналитика_данных #data_engineering #высоконагруженные_системы #архитектура_по #distributed_systems #mpp #rapeed

Автоскейлинг StarRocks в Kubernetes: как я довел его до предела

Классическая проблема аналитических систем: кластер СУБД сайзится под пик, а 28 дней в месяц он задействован чуть больше чем наполовину. StarRocks (shared-data) и автоскейл Kubernetes убирают этот избыток. Compute добавляется под нагрузку и сворачивается на спаде. Внутри легкая пятничная статья: как это работает и где у эластичности потолок.

https://habr.com/ru/articles/1041278/

#starrocks #olap #kubernetes #autoscaling #selena #субд #mpp

I'm quite curious what are the plans for #DuckDB on 2.0. They have an #OLAP local renaissance in their hands. 😎

https://duckdb.org/2026/05/12/quack-remote-protocol

Насколько многомерным может быть многомерный точный индекс?

Вот, например, Milvius(DiskANN) рассчитан на вектора размерности до 32 768 , но это приближенный поиск. Но как насчёт поиска точного? В данной статье рассматривается работоспособность 1024 мерного индекса, хранилищем которого служит обычное B-дерево (насколько вообще может быть обычным такое дерево). Используемый диск - вполне себе “железный” старый добрый WD Purple, оперативная память сознательно ограничена 8 Гб. Можно ли что-то из этого выжать на рядовом десктопе за приемлемое время?

https://habr.com/ru/articles/1036056/

#olapкубы #olap #dbms

ClickHouse для больших данных: полный гайд по интеграции с NoSQL‑экосистемой

Когда классические SQL‑базы падают под аналитической нагрузкой, а Hadoop‑кластер напоминает чемодан без ручки — пора искать новое решение. В этой статье разбираем, как ClickHouse в связке с NoSQL‑экосистемой закрывает бреши в высоконагруженных проектах. Разберём архитектурные ловушки, Best Practices и честно оценим, где этот инструмент экономит миллионы, а где может создать проблемы.

https://habr.com/ru/companies/otus/articles/1022158/

#clickhouse #nosql #big_data #аналитика_данных #kafka #olap #архитектура_данных

apache iceberg и его философия

iceberg и его философия metadata расскажем почему iceberg эффективно выполняет запросы и прост в управлении данными благодаря своей metadata

https://habr.com/ru/articles/1033546/

#iceberg #metadata #data_lake #s3 #hdfs #data_lakehouse #acid #olap

Миграция с Greenplum. Эпизод I: Атака клонов и спасение на звёздных камнях

В мае 2024 года Broadcom заархивировал публичный репозиторий Greenplum: последний коммит остался на месте, дальнейшая разработка ушла в закрытый репозиторий, enterprise-сборка теперь доступна только по подписке. Greenplum как живой OSS-проект остановился — но сам код, выпускавшийся с октября 2015-го, остался под Apache 2.0. Именно на этой кодовой базе стартанули остальные форки. Те, кто строил аналитику на Greenplum, оказались перед развилкой. Сообщество разделилось: Apache Cloudberry (incubating) , Greengage DB от Arenadata, WarehousePG от EDB. Каждый форк продолжает линию, но в собственной траектории. У компании с боевым кластером появляется конкретный вопрос: переехать/остаться в одном из этих форков или мигрировать на принципиально другую платформу и архитектурную парадигму. Эта статья (сага из трёх эпизодов) будет полезна, если у вас уже есть Greenplum-кластер, вы понимаете его DDL/ETL/backup-процессы и хотите оценить, насколько болезненным будет переход на StarRocks.

https://habr.com/ru/articles/1031358/

#starrocks #Lakehouse #greenplum #sql #миграция_данных #субд #mpp #dwh #olap #etl

Иллюзия точности метрик: о чем не принято говорить в «высоком обществе» BI-аналитиков

Как только вы уходите от сырых транзакционных данных к предагрегированным витринам, ваша BI-система начинает врать. И чем сложнее бизнес-логика и больше сложных показателей, тем сильнее искажения. Давайте разберем механику этой проблемы на фундаментальном уровне. Почему системы, в которые инвестированы миллионы, показывают фейк?

https://habr.com/ru/articles/1025328/

#BI #DWH #OLAP #DAX #MDX #архитектура_данных #rapeed #аналитика_данных #clickhouse #superset

OLAP-кубы в финансах: превращаем бюджетирование в управляемую систему

Цифровизация финансовой функции нередко воспринимается как масштабный и дорогостоящий проект. Со стороны кажется, что единовременно требуется внедрить несколько сложных систем и полностью перестроить бизнес-процессы. Евгения Крюкова , старший аналитик «Оптимакрос» , разобрала в статье, как OLAP-кубы (Online Analytical Processing) меняют бюджетирование и планирование в организации и почему именно их выбор становится критически важным этапом цифровой трансформации финансового подразделения компании. Материал будет полезен финансовым директорам, руководителям планово-экономических отделов и аналитикам, которые ищут инструменты для повышения качества управленческой отчетности.

https://habr.com/ru/articles/1017470/

#olap #olapкубы #финансовый_учет #бюджетирование #excel #bi #sql #cfo #моделирование #планирование

Определение фактического профиля нагрузки в PostgreSQL и динамические состояния БД

Привет, ХАБР! Я Владимир Хаймин , эксперт по системам управления базами данных PostgreSQL в ВТБ. Когда вы знакомитесь с документацией по какой-то системе в части базы данных, то обычно характер нагрузки определяется исходно в архитектуре проекта. Но если система определена архитектором как OLTP, но в действительности может вести себя в некоторые периоды времени как OLAP. Нормально ли такое поведение, и каким образом мы можем определить, что она ведет себя как-то иначе? Как определить фактический профиль нагрузки OLAP или OLTP и выразить это через метрики, пригодные для событийного и графического мониторинга? Эта статья является скорее исследовательской в области Data Science в прикладном контексте PostgreSQL. Data Science – это не только задачи ИИ: (ML, LLM,..), но прежде всего математика. Мы используем регрессивные методы для получения некоторых нужных нам параметров исходя из табличных рекомендованных данных. Также мы делаем упор на исследование состояния БД на основе статистики динамики ожиданий. Задача, несмотря на ее простой смысл, в решении оказалась не такой простой, и мы в итоге работали над ней довольно долго, хоть и в фоновом режиме. Также обратились к студенческому сообществу и провели по этой теме Хакатон ВТБ х Башня , прошедший в МГТУ им. Баумана 27 ноября 2025 года. В нем приняли участие студенты и выпускники НИУ ВШЭ, СПбГУ, ВКА им. А.Ф. Можайского, РАНХИГС, Московского Политехнического университета, НИТУ МИСИС, а также уже действующие архитекторы и администраторы БД. У команд было всего три дня на решение задачи, и хотя полностью её не удалось выполнить никому, совокупный результат всех участников позволил сформировать корректное решение. Результат именно этих работ я и изложил в статье и обязательно буду упоминать команды и авторов интересных идей, о которых пойдет речь.

https://habr.com/ru/companies/vtb/articles/1011188/

#postgresql #postgresql_performance #olap #oltp #htap

Считаем ресурсы под PostgreSQL

Не так давно на моей текущей работе впервые за весь мой немногочисленный 4-летний опыт бэкендера понадобилось для нового микросервиса рассчитывать ресурсы под PostgreSQL для данного сервиса. Раньше для меня данная тема было чем-то, чем занимаются DevOps/DBA и никогда прежде не задумывался и не исследовал информацию о том, как качественно рассчитать необходимые ресурсы, чтобы бизнесу не пришлось переплачивать за очень дорогие железки лишние деньги, чтобы потом оказалось, что от купленных мощностей в реальности используется 20-40% (опыт на нескольких работах показывает, что такое случается ну очень часто). Q: Для кого эта статья? A: Да в целом для любых технических специалистов, которые так или иначе взаимодействуют с технической поддержкой PostgreSQL и которым впервые нужно для новой БД (например, под микросервис) и сформулировать задачу для DevOps команды на поднятие СУБД для вашего сервиса. Q: «Зачем мне это? Ну прикину я на глаз, что здесь нужно 50ГБ диска, 64ГБ RAM и нормально поедет» A: Очень часто в условиях микросервисной архитектуры используется парадигма database per service и в таком случае нельзя просто запросить максимально мощную виртуальную машину. Ресурсы стоят много денег, инфраструктура должна масштабироваться, а значит необходимо уметь определять, какой именно мощности ВМ требуется и какие параметры PostgreSQL следует задать на старте. В статье вы получите пошаговый расчёт диска, RAM, CPU и базовые рекомендации по конфигу PostgreSQL, а также в подарок готовый промпт для ИИ, если захотите делегировать все расчёты нейромозгу. Ну давай считать

https://habr.com/ru/articles/995722/

#PostgreSQL #расчёт_ресурсов #sizing_базы_данных #OLTP #OLAP #shared_buffers #max_connections #connection_pool #PGTune #database_per_service

INSERT в StarRocks: как три кластера раскрыли цену commit protocol

tl;dr: Каждая операция INSERT несет фиксированный overhead (в наших тестах 64–99 ms), независимо от количества строк. Формула: Total_time = N_statements * fixed_overhead + actual_write_time — подтверждена тестами. 1000 single-row INSERT = 64 секунды (Shared-data) или 100 секунд (Shared-Nothing). Разница не в диске и не в Docker, а в протоколе commit: TxnLog + publish через BRPC против 2PC + publish_version. В ANALYZE PROFILE commit overhead прячется в разнице TotalTime - ExecutionTime — это FE overhead. Батчинг нивелирует разницу: при INSERT SELECT оба режима дают ~0.25 с на 1000 строк.

https://habr.com/ru/articles/995484/

#StarRocks #OLAP #distributed_databases #performance #INSERT_optimization #архитектура

In meinen heutigen #TechTipps möchte ich Euch gerne #duckdb
vorstellen.
DuckDB (https://duckdb.org) könnte Euch dann interessieren wenn ihr:

- in der IT (#Softwareentwicklung, Datenanalyse #Olap, Qualitätssicherung, Forschung, etc ) arbeitet
- privat an Datenanlyse jenseits von unübesichtlichen Tabellen (#Spreadsheets) interessiert seid
- Daten wie Kontoauszüge, Telefonbücher oder (elektronische) Kataloge durchforsten wollt

DuckDB kann als eigenständiges Kommandozeilen (#CLI) Programm ohne Abhängigkeiten bezogen und verwendet werden oder auch intergriert in andere #programmiersprachen (#python) oder #tools wie #jupyter integriert werden.

Die CLI-Version kann mit Parameter "-ui" verwendet werden und startet damit ein recht komfortables #webui im lokalen #browser.
Im ersten Schritt legt man nun ein "Notebook" an das zellenweise strukturiert ist.
Es können jederzeit neue Zellen an jeder Stelle im #workflow hinzugefügt, eingefügt oder gelöscht werden.
Unterteilt man nun seinen Anwendungsfall in kleine Schritte (Zellen) wird ein komplexes Thema schon viel einfacher.

Beispiel:
1. Zelle:
-- Datenbank im Speicher anlegen
ATTACH IF NOT EXISTS ':memory:' AS memory;

2.Zelle:
-- Tablle BLS 4.0 importieren
CREATE OR REPLACE TABLE BLS AS
SELECT * FROM
read_xlsx('/home/XXX/Downloads/BLS_4_0_2025_DE/BLS_4_0_Daten_2025_DE.xlsx',
sheet = 'BLS_4_0_Daten_2025_DE',
header = true, all_varchar = true);

3. Zelle
-- Zeige mir Lebensmittel mit Vitamin D
select Lebensmittelbezeichnung, "VITD Vitamin D [µg/100g]" as VD
from'BLS'
where
VD is not null and VD not ilike '0'
order by VD DESC;

Ergebnisse können als Tabelle oder CSV mit "Download" gespeichert werden.
😀

StarRocks to the rescue! 🚀 Apparently, the #OLAP world was too busy having a mental breakdown over #joins to realize that #StarRocks has some secret sauce that makes them faster than a cat meme's rise to fame. 😂 But hey, who cares about real solutions when we can just keep denormalizing everything into oblivion, right? 🙄
https://www.starrocks.io/blog/inside-starrocks-why-joins-are-faster-than-youd-expect #performance #dataanalytics #datavisualization #technologyhumor #HackerNews #ngated

Как JOIN изменил наш подход к инфраструктуре данных в NAVER

После миграции с ClickHouse на StarRocks NAVER существенно оптимизировала обработку многотабличных JOIN. StarRocks повысил производительность запросов, обеспечил бесшовное масштабирование и позволил построить единый слой запросов, совместимый с множеством источников данных. Эти улучшения позволили предоставлять инсайты в реальном времени и поддерживать принятие решений на основе данных во всей экосистеме NAVER.

https://habr.com/ru/articles/983356/

#StarRocks #ClickHouse #Apache_Iceberg #Lakehouse #JOIN #OLAP #Kubernetes #материализованные_представления #federated_analytics #аналитика_в_реальном_времени