Наш сайт использует файлы cookie, чтобы улучшить работу сайта, повысить его эффективность и удобство
Настройки сookie
Файлы cookie, необходимые для правильной работы сайта, всегда разрешены.
Основные файлы cookie
Всегда Включено. Эти файлы cookie необходимы для использования веб-сайта и его функций. Их нельзя отключить. Они устанавливаются в ответ на ваши запросы, такие как настройка параметров конфиденциальности, вход в систему или заполнение форм.
Аналитические файлы cookie
Disabled
Эти файлы cookie нужны чтобы помочь нам понять, на сколько вам удобен наш веб-сайт и насколько эффективны наши маркетологи:) Смотрите список аналитических файлов cookie, которые мы используем.
Рекламные файлы cookie
Disabled
Эти файлы cookie предоставляют информацию рекламным компаниям с целью предоставления или ограничения персонализированной рекламы. Эта информация может быть передана другим рекламным компаниям. Смотрите список рекламных файлов cookie, которые мы используем.

Оптимизация ETL-процессов DWH в десятки раз

блог о bi, №1 в рунете
ETL - это конвейер, который ежедневно переносит и преобразует данные из операционных систем в DWH. По мере роста объема источников и числа витрин именно этапы извлечения и загрузки чаще всего начинают ограничивать скорость обновления аналитики: бизнес ожидает актуальные данные к началу рабочего дня, а регламентное окно не растет.

Почему ETL становится узким местом аналитических систем

Современные DWH агрегируют десятки и сотни миллионов строк, а количество интеграций постоянно увеличивается. ETL конкурирует за ресурсы с другими задачами, упирается в сетевую пропускную способность и I/O, и поэтому становится основным ограничителем скорости обновления отчетности.

Причины медленного ETL

  1. Рост объема данных при межсерверной выгрузке. Чем больше фактов и исторических периодов нужно перенести, тем сильнее проявляются задержки сети и узкие места дисковой подсистемы на источнике и в DWH.
  2. Отсутствие инкрементальности: когда выгрузка идет полностью, без CDC и без фильтрации по измененным данным, нагрузка растет линейно и быстро «съедает» ночное регламентное окно.
  3. Недостаточная параллелизация и неэффективный режим вставки заметно увеличивают время интеграции: последовательное выполнение шагов и построчные вставки остаются узким местом даже при умеренных объемах.
  4. Дополнительно замедляют процесс тяжелые трансформации после загрузки и дефицит ресурсов (RAM/CPU/IOPS), когда ETL конкурирует с другими регламентными процессами.

Случаи из практики

В процессе организации DWH на платформах MS SQL Server/Postgresql/Greenplum возникали вопросы, связанные с увеличением времени, затрачиваемого на извлечение данных из внешних СУБД, с которыми DWH взаимодействуют путем создания соединений «сервер-сервер»: если подобные соединения используются для получения справочных, «легких» данных (таблицы, наборы данных до 5 млн строк), то проблем с производительностью нет, однако при выгрузке данных о фактах деятельности бизнеса (более 50 миллионов строк) производительность интеграции данных ощутимо снижается.
  • DWH MS SQL Server – источник данных PostgreSQL
    DWH на платформе MS SQL Server в рамках политики регламентного обновления ежедневно (в период с 00:00 по 03:00) подключается к серверу-источнику на PostgreSQL, при этом получая объем данных по фактам чеков более 80 миллионов строк за одну сессию, что занимает 1,5-2 часа от всего времени интеграции.
  • DWH Greenplum – источник данных Oracle
    В случае DWH на платформе Greenplum – происходит ежедневное получение более 150 миллионов строк данных товародвижений с сервера источника Oracle, что занимает около 3 часов.

Методы ускорения ETL-процессов

Заметный эффект дает уменьшение объема передаваемых данных. Инкрементальные загрузки и CDC позволяют забирать только изменения, а грамотная фильтрация и выбор нужных колонок сокращают сетевой трафик и нагрузку на источники.

Параллелизация ускоряет загрузку без потери контроля над качеством данных. Разделение по диапазонам, партициям или бизнес-ключам и запуск нескольких потоков лучше использует ресурсы DWH.

Отдельно стоит выделить высокопроизводительные способы вставки. Пакетные операции и bulk-методы значительно эффективнее построчной загрузки и лучше используют возможности СУБД.

Также имеет смысл переносить часть преобразований ближе к источнику, а сам ETL-контур изолировать по ресурсам, чтобы он не конкурировал с другими регламентными задачами.

Разработка драйвера интеграции данных

Понимая, что стандартных средств MS SQL Server/PostgreSQL (Airflow, Spark, Nifi)/Greenplum (Airflow, Spark, Nifi) недостаточно для эффективной интеграции данных, было решено разработать универсальное решение.
На языке C# был создан драйвер, обеспечивающий интеграцию данных из источников (Oracle/PostgreSQL/MS SQL Sever/Greenplum) в целевые таблицы БД назначений. В основу драйвера были вложены 4 ключевые концепции для оптимизации интеграции:
  • Многопоточность;
  • Асинхронность;
  • Im-memory обработка;
  • Пакетная вставка.

Механизм работы драйвера

Драйвер локально разворачивается на сервере, на котором находится DWH и интегрируется в БД в качестве вызываемой хранимой процедуры, в которую передаются следующие параметры:
  1. Локальный путь к файлу запуска драйвера;
  2. Тип СУБД назначения данных (Oracle/PostgreSQL/MS SQL Sever/Greenplum);
  3. Тип СУБД источника данных (Oracle/PostgreSQL/MS SQL Sever/Greenplum);
  4. Строка подключения к источнику данных;
  5. SQL-запрос для извлечения необходимого датасета;
  6. Строка подключения к целевой БД;
  7. Наименование целевой таблицы для вставки датасета;
  8. Количество строк для вставки в одном пакете интеграции.
Далее, драйвер создает объект подключения к базе данных сервера-источника и выполняет переданный SQL-запрос для получения датасета. Сохраняя данные в оперативной памяти, драйвер пакетно вставляет их в целевую таблицу сервера назначения, используя встроенные высокопроизводительные методы вставки данных в таблицу:
  • BCP для MS SQL Server;
  • SQL*Loader/External Tables для Oracle;
  • COPY для PostgreSQL;
  • gpload/gpfdist для Greenplum.

Результаты: зачем оптимизировать ETL

Оптимизация ETL дает бизнесу предсказуемость: регламентные окна становятся устойчивыми, а аналитические отчеты обновляются вовремя. Это снижает операционные риски, когда задержка загрузки приводит к устаревшим метрикам и ошибочным решениям.

Технически оптимизация уменьшает нагрузку на источники и DWH, освобождает ресурсы для параллельных процессов и повышает стабильность процедур. В результате система легче масштабируется при росте объемов и числа интеграций.

В нашем кейсе использование разработанного драйвера позволило сократить время извлечения данных с источника до 10 раз: операции, которые ранее занимали час, теперь выполняются за 4-7 минут.
Для максимальной эффективности драйвера требуется потребление увеличенного объема оперативной памяти. Драйвер сильно зависит от доступных ресурсов, поэтому рекомендуется избегать запуска «прожорливых» процессов параллельно с ним. Важно настроить алгоритм регламентных процедур, чтобы драйвер запускался в отдельном блоке с минимальным количеством параллельных обновлений.
Таким образом, оптимизация ETL-процессов и разработка специализированного драйвера интеграции данных существенно ускоряют обновление DWH и обеспечивают бизнес-аналитиков актуальными данными.
Разберем вашу задачу и предложим подход
Без длинных созвонов и маркетинговых презентаций