Расскажи про миграцию с SAS на Greenplum

Я участвовал в проекте по миграции аналитической платформы с проприетарного стека SAS на открытую MPP-СУБД Greenplum. Основная цель была — снизить стоимость лицензий и повысить производительность обработки больших объемов данных.

План и этапы миграции:

1. Инвентаризация и анализ (самый важный этап):

   • Составили каталог всех SAS-скриптов (.sas), макросов, jobs из SAS DI Studio и расписаний.
   • Классифицировали их по типу: извлечение данных (ETL), трансформация, построение отчетов (PROC REPORT), статистический анализ (PROC MEANS, PROC FREQ).
   • Определили, какую логику можно напрямую переложить на SQL Greenplum, а что требует переписывания на Python (например, сложные макросы).

2. Перенос и преобразование данных:

   • Данные из SAS-библиотек (SAS7BDAT) выгружали с помощью утилиты PROC EXPORT в промежуточный формат Parquet на HDFS, что сохраняло типы данных и сжимало объем.
   • В Greenplum создавали схему, таблицы с оптимальным распределением (DISTRIBUTED BY). Ключ распределения выбирали на основе джойнов в факт-таблицах.
   • Загрузка выполнялась через gpfdist для максимальной скорости:

     
     -- Создание внешней таблицы, указывающей на файлы в HDFS
     CREATE EXTERNAL TABLE ext_sales (id int, date date, amount decimal(10,2))
     LOCATION ('gpfdist://hdfs-namenode:8081/data/sales/*.parquet')
     FORMAT 'parquet';

   -- Загрузка во внутреннюю таблицу INSERT INTO internal_sales SELECT * FROM ext_sales;

3. Переписывание бизнес-логики:

   • Простой SQL: Процедуры PROC SQL переводились почти один-в-один в стандартный ANSI SQL для Greenplum.
   • Сложные трансформации: Логику из DATA STEP с множественными условиями и циклами переписывали на Python UDF (User-Defined Functions), которые выполнялись внутри Greenplum, или выносили в отдельные PySpark-джобы, если трансформация была очень ресурсоемкой.
   • Статистика и агрегация: Заменяли PROC MEANS, PROC SUMMARY на агрегатные функции SQL (AVG, SUM, PERCENTILE_CONT) и оконные функции для расчетов.

     -- Пример: Замена PROC MEANS + BY GROUP
     -- SAS: PROC MEANS DATA=sales MEAN SUM MAXDEC=2; CLASS region; VAR revenue; RUN;
     -- Greenplum:
     SELECT 
     region,
     ROUND(AVG(revenue), 2) as avg_revenue,
     SUM(revenue) as total_revenue
     FROM sales
     GROUP BY region;

4. Оптимизация под MPP-архитектуру:

   • Партиционирование: Крупные таблицы партиционировали по дате (PARTITION BY RANGE (date_column)).
   • Индексы: В Greenplum (колоночном хранилище) индексы используются реже, чем в SAS. Вместо этого мы настраивали сегментирование (distribution) и сжатие (WITH (APPENDONLY=true, COMPRESSTYPE=zlib)).
   • Анализ запросов: Использовали EXPLAIN ANALYZE для поиска узких мест — часто это были cross-segment операции (перераспределение данных Redistribute Motion), которые мы устраняли, меняя ключ дистрибуции.

Основные сложности:

• Отсутствие прямых аналогов некоторых SAS-процедур для нишевого статистического анализа. Для этого пришлось интегрировать Greenplum с R или Python (scikit-learn, statsmodels) через PL/R или PL/Python.
• Миграция сложных SAS-макросов, которые генерировали динамический код. Их переписывали на Python, используя шаблонизаторы (Jinja2) для генерации SQL.
• Обеспечение сопоставимой производительности отчетов. В Greenplum мы добились этого за счет предварительной агрегации данных в OLAP-кубы или использование материализованных представлений.