#greenplum — Public Fediverse posts

Почему база не видит ваш предагрегат

Инженеры данных построили агрегат — маленькую таблицу «продажи по магазинам по дням». Отчёт из неё собирается за доли секунды. А сводная в Excel всё равно ждёт двадцать секунд и читает миллиард строк. Разбираемся на живом ClickHouse, почему база не видит предагрегат, который для неё построили, какая форма запроса это лечит (одна и та же для ClickHouse, Snowflake и BigQuery) и почему в итоге вопрос не к базе, а к семантическому слою. Внутри — замер на миллиарде строк: 3 секунды против 37 миллисекунд, сравнение восьми баз и одно правило, которое стоит проверить в своём BI.

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

#clickhouse #starrocks #trino #greenplum #sql #семантический_слой #excel

Ускоряем федеративные запросы в StarRocks

Когда речь заходит про Lakehouse и федеративный доступ , многие вспоминают про Trino и… часто на этом все. Но федеративные запросы поддерживаются в том или ином виде довольно большим количеством СУБД, SQL-движков и систем для виртуализации данных. В этой статье постараемся немного расширить кругозор читателей, которым интересна данная тема: рассмотрим федеративные запросы на примере набирающего популярность и активно развивающегося StarRocks . Из статьи вы узнаете: что такое федеративные запросы, как обстоят дела с реализацией гетерогенного федеративного доступа в этой СУБД и какие изменения команда решения Data Ocean Nova реализовала для оптимизации в StarRocks и Impala с целью улучшения функционала доступа к внешним данным.

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

#starrocks #федеративные_системы #lakehouse #datalakehouse #dwh #mpp #jdbc #greenplum #trino

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

Миграция с 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

asapBI: архитектура ETL процессов – Trino, Spark, Airflow и прочий зоопарк

С вами снова Виталий Виноградов, я занимаюсь созданием asapBI - платформы для моделирования баз данных и ETL. Продолжу цикл по системе. Чего хочется от ETL процесса? Если процесс простой – например, проброс данных из одной таблицы в другую с промежуточным расчетом – то графический мэппинг полей. Таких простых пробросов в работе – 90%, не хочется лазить по SQL-коду. Если же процесс сложный – только тогда уже в бой идет ручной SQL, Python, Java, Scala, R. Если процесс длительный – тогда его лучше выполнять на внешних кластерах Trino, Spark, Impala – как говорится, хранилища отдельно, считалища – отдельно. Еще нужна только одна точка контроля загрузок – не дело, когда мониторинг загрузок раскидан по разным системам. В связи с последними (?) событиями было бы здорово иметь возможность заниматься разработкой в оффлайне – сидишь в палатке без 5G, разрабатываешь модели и тестируешь трансформации и цепочки без доступа к инету, а вечером результат сбрасываешь в систему разработки через wi-fi придорожного кафе. Причем должна быть возможность убрать asapBI и продолжать заниматься разработкой вручную (= медленно и печально) – этим мы предотвращаем вендор лок. Как бы нам это все замиксовать? На текущий момент существует много систем со своими интерфейсами и для моделей данных, ETL–процессов нужно в них создавать объекты. Объектов много, надо не забывать, где что лежит и как завязано. По идее, хорошо бы иметь единый интерфейс, где объекты, рассыпанные по разным системам, связаны между собой. Если убрать этот интерфейс, то модели данных и ETL процессы не рассыплются, все продолжит работу, но настраивать будет уже не так удобно. Единый интерфейс просто объединяет в себе удобную работу с разными инструментами. Именно этот принцип я и реализую в asapBI. «Миксуем… Сегодня мы с тобой миксуем…»

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

#asapBI #data_platform #trino #spark #postgresql #greenplum #sql #data_engineering #dwh #etlпроцессы

Проблема маленьких файлов. Оценка замедления S3 и проблем HDFS и Greenplum при работе ними

Не так давно в блоге компании Arenadata был опубликован материал тестирования поведения различных распределенных файловых систем при работе с маленькими файлами (~2 Мб). Краткий вывод: по результатам проверки оказалось, что лучше всего с задачей маленьких файлов справляется старый-добрый HDFS, деградируя в 1.5 раза, S3 на базе minIO не тянет, замедляясь в 8 раз, S3 API над Ozone деградирует в 4 раза, а наиболее предпочтительной системой в при работе с мелкими файлами, по утверждению коллег, является Greenplum, в том числе для компаний «экзабайтного клуба». Коллеги также выполнили огромную работу по поиску «Теоретических подтверждений неожиданных показателей». Результаты тестирования в части S3 minIO показались нашей команде неубедительными, и мы предположили, что они могут быть связаны с: -недостаточным практическим опытом эксплуатации SQL compute over S3 и S3 в целом; -отсутствием опыта работы с кластерами minIO. В частности в высоконагруженном продуктивном окружении на 200+ Тб сжатых колоночных данных Iceberg/parquet, особенно в сценариях, где проблема маленьких файлов быстро становится актуальной. -особенностями сборок дистрибутивов; Мы благодарны коллегам за идею и вдохновение провести аналогичное тестирование. Давайте разбираться.

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

#s3 #minio #hdfs #greenplum #bigdata #lakehouse #datalake #dwh