22.10.2025 09:37
PhoenixLi 0 213 Источник

В ходе разработки продукта в области больших данных (Big Data) возникла потребность: при работе с гигантскими объемами данных на платформе пользователям необходимо выполнять агрегирующие запросы по разным таблицам, включая JOIN, GROUP BY, COUNT и т. п., и быстро получать результаты.
Сейчас основная цель — офлайновые данные; сценарии обработки в реальном времени временно не рассматриваются.
Текущий технологический стек — Big Data‑платформа CDH; вычисления выполняются на движках MapReduce или Spark, однако интерактивная обработка работает неидеально.

Анализ и соображения

Рассматриваемый кейс — типичный OLAP‑сценарий, где требуется быстрая аналитическая обработка на платформе больших данных. На рынке есть несколько подходящих решений, из которых обычно выбирают:

  1. Хранение в формате Parquet на базе CDH + Impala для быстрых запросов по офлайновым данным (при наличии сценариев реального времени — связка Kudu + Impala).

  2. Внедрение MPP (Massively Parallel Processing)‑движка, например Greenplum или StarRocks, которые могут работать независимо от экосистемы Hadoop.

Далее проведем проверку и сравнение трех вариантов: Parquet + Impala, Greenplum и StarRocks.

Сравнение решений и методика

  • Тестовые данные: две таблицы — SAD (7 000 000 строк) и ITEM (дочерняя таблица SAD, связь по SAD_ID, 3 000 000 строк).

  • Сценарий тестирования: операции JOIN + GROUP BY + ORDER BY.

  • Тестовые запросы: см. код (листинги не приводятся в данном документе).

a) Hive (Parquet) + Impala

  • Загрузка данных (Oracle → Hive): скрипты Sqoop + скрипты Hive.

  • Хранение в формате Parquet; исполнение запросов — через Impala.

b) Greenplum

Развертывание кластера: 1 master + 2 segment (узел standby не разворачивается).

Конфигурация узлов:

master

segment

CPU: 8 cores, 2.5 GHz

Memory: DDR4, 64GB

Hard Disk: 256GB SSD

Network Card: Internal 10 Gigabit Ethernet Card Interconnection

CPU: 8 cores, 2.5 GHz

Memory: DDR4, 64GB

Hard Disk: 256GB SSD

Network Card: Internal 10 Gigabit Ethernet Card Interconnection

Примечания по установке:

  • На всех трех узлах необходимо скорректировать параметры ядра ОС и установить требуемые компоненты.

  • Настроить доступ по SSH без пароля между всеми узлами.

  • Каталог хранения данных (например, /opt/) должен располагаться на соответствующем дисковом томе; владельцем назначить пользователя gpadmin и выдать ему все необходимые права.

  • Большинство операций выполняется с узла master (при настроенном SSH без пароля — удаленное управление узлами segment).

Greenplum основан на PostgreSQL. Базовые команды:

  • Запуск (под пользователем gpadmin на master): gpstart

  • Подключение: psql -d gp_sydb -h mpp-cluster-master -p 5432 -U gpadmin

  • Список БД: \l

  • Подключение к БД demo: \c demo

  • Список таблиц: \d

  • Выход: \q

  • Пример запроса: select count(1) from public."ITEM";

  • Остановка: gpstop

Загрузка данных (Oracle → Greenplum):

  • Используется инструмент CloudCanal, устанавливаемый на узел master. Для повышения производительности можно добавить sidecar‑узел на worker01.

  • Рекомендуется корректировать параметры задач, например fullbatchsize, подбирая их экспериментально для достижения оптимальной производительности.

c) StarRocks

Развертывание кластера: 1 FE + 3 BE (FE также используется как один из BE).

Конфигурация узлов:

fe

be

CPU: 8 cores, 2.5 GHz

Memory: DDR4, 64GB

Hard Disk: 256GB SSD

Network Card: Internal 10 Gigabit Ethernet Card Interconnection

CPU: 8 cores, 2.5 GHz

Memory: DDR4, 64GB

Hard Disk: 256GB SSD

Network Card: Internal 10 Gigabit Ethernet Card Interconnection

Примечания по установке:

  • Установочные пакеты необходимо скопировать на все три узла.

  • Настроить SSH‑доступ без пароля между всеми узлами.

  • Для запуска FE/BE требуется перейти под root.

Запуск FE (на master):

cd /data/software/fe/bin
bin/start_fe.sh --daemon

Подключение MySQL‑клиентом:

mysql -uroot -P 9030 -h 52.130.81.91

  • Пароль по умолчанию отсутствует.

  • Просмотр состояния FE:

show frontends \G

Запуск BE:

# master
cd /data/software/be/bin
bin/start_be.sh --daemon

# worker01
cd /data/software/be/bin
bin/start_be.sh --daemon

# worker02
cd /data/software/be/bin
bin/start_be.sh --daemon

  • Просмотр состояния BE:

show backends \G

Примечание по протоколу:

  • StarRocks использует MySQL‑совместимый протокол; команды схожи с MySQL. Пример: 

    mysql -uroot -P 9030 -h <ip>

Загрузка данных (Oracle → StarRocks):

  • Используется CloudCanal для миграции.

  • Типичная ошибка при выгрузке в StarRocks: Failed to flush data to StarRocks — требуется проверка параметров задачи (включая fullbatchsize), конфигурации целевой таблицы и сетевых настроек.

Результаты тестирования

По 10 прогонам каждого варианта (единицы соответствуют метрике исходного теста):

Category

parquet+impala

greenplum

starrocks（test1）

starrocks（test2）

10 Test Results

Test 1 Result: 1960

Test 2 Result: 2184

Test 3 Result: 1771

Test 4 Result: 2049

Test 5 Result: 1824

Test 6 Result: 2055

Test 7 Result: 1791

Test 8 Result: 2177

Test 9 Result: 2046

Test 10 Result: 2176

Test 1 Result: 1607

Test 2 Result: 1445

Test 3 Result: 1441

Test 4 Result: 1517

Test 5 Result: 1493

Test 6 Result: 1406

Test 7 Result: 1473

Test 8 Result: 1584

Test 9 Result: 1569

Test 10 Result: 1468

Test 1 Result: 3867

Test 2 Result: 820

Test 3 Result: 959

Test 4 Result: 2324

Test 5 Result: 976

Test 6 Result: 1439

Test 7 Result: 1889

Test 8 Result: 1253

Test 9 Result: 1215

Test 10 Result: 1133

Test 1 Result: 1446

Test 2 Result: 980

Test 3 Result: 1112

Test 4 Result: 1362

Test 5 Result: 901

Test 6 Result: 1126

Test 7 Result: 1322

Test 8 Result: 1199

Test 9 Result: 1420

Test 10 Result: 1480

Total Time of 10 Queries

20040

15009

15880

12353

Выводы

  • Внедрение MPP‑движка действительно повышает производительность запросов: время выполнения одного запроса преимущественно находится в диапазоне 1–2 секунд.

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

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

Комментарии (0)