Преодоление разрыва между аналитическими системами (OLAP) и транзакционными базами данных (OLTP) традиционно связано с большой сложностью. Синхронизация данных между этими двумя системами, часто называемая обратным ETL (Reverse ETL — извлечение, преобразование и загрузка), исторически требует громоздкого промежуточного ПО, промежуточных хранилищ (staging buckets) и сложной оркестрации, особенно в масштабах предприятия.
Мы объявляем о всеобщей доступности (GA) функции экспорта из BigQuery в AlloyDB, которая позволяет командам по обработке данных использовать один декларативный SQL-запрос для экспорта данных из BigQuery в AlloyDB. Такой подход полностью исключает необходимость в сложном промежуточном ПО для ETL.
Чтобы продемонстрировать преимущества этой функции, мы рассказываем о том, как компания Copel, бразильский поставщик электроэнергии, устранила масштабное «бутылочное горлышко» в оркестрации и масштабировала телеметрию интеллектуальных счетчиков благодаря миграции на высокопроизводительный встроенный обратный ETL.
Проблема масштабирования телеметрии интеллектуальных счетчиков
В Copel управление данными телеметрии от миллионов интеллектуальных электросчетчиков является критически важной операцией. Эти данные передаются в режиме непрерывного потока и консолидируются в аналитическом золотом слое (Gold layer) в BigQuery. Однако для поддержки «систем действия» (Systems of Action) компании Copel — панелей мониторинга службы поддержки клиентов с малой задержкой, мобильных приложений и систем оперативного выставления счетов — этот богатый набор данных должен постоянно синхронизироваться обратно с высокопроизводительной транзакционной базой данных AlloyDB for PostgreSQL.
До недавнего времени компания Copel оркестровала эту архитектуру обратного ETL с помощью сложного процесса DAG в управляемом сервисе Google для Apache Airflow. Тем не менее, процесс обогащения и экспорта сотен миллионов записей из BigQuery в AlloyDB состоял из множества хрупких промежуточных этапов:
Рисунок 1: Устаревшая многоуровневая архитектура Copel, требующая дампов файлов в Cloud Storage и последовательных скриптов gCloud.
- BigQuery выполняла запросы на обогащение и извлечение, сбрасывая результаты SQL в десятки фрагментированных CSV-файлов внутри бакета Google Cloud Storage.
BigQuery выполняла запросы на обогащение и извлечение, сбрасывая результаты SQL в десятки фрагментированных CSV-файлов внутри бакета Google Cloud Storage.
- Apache Airflow выполнял SQL для создания временных таблиц в AlloyDB во избежание блокировки записи или повреждения данных в производственных таблицах.
Apache Airflow выполнял SQL для создания временных таблиц в AlloyDB во избежание блокировки блокировки записи или повреждения данных в производственных таблицах.
- Последовательные скрипты gCloud сканировали CSV-файлы в Cloud Storage для загрузки данных в соответствующие кластер и шарды AlloyDB.
Последовательные скрипты gCloud сканировали CSV-файлы в Cloud Storage для загрузки данных в соответствующие кластер и шарды AlloyDB.
- Наконец, блок транзакции SQL безопасно удалял производственную таблицу и переименовывал временную таблицу в производственную.
Наконец, блок транзакции SQL безопасно удалял производственную таблицу и переименовывал временную таблицу в производственную.
Для поддержки этой устаревшей архитектуры команде Copel приходилось обслуживать пайплайн, тщательно управлять промежуточными файлами, выполнять сложную олицетворение IAM (impersonation) между несколькими сервисами и постоянно следить за работоспособностью системы от начала и до конца.
Прорыв: Встроенный обратный ETL
С помощью функции EXPORT DATA в AlloyDB от BigQuery компания Copel смогла заменить всю эту многоэтапную инфраструктуру пайплайна одним элегантным SQL-запросом.
Теперь экспорты из BigQuery напрямую взаимодействуют с инстансами AlloyDB по высокооптимизированным параллельным соединениям — никаких промежуточных файлов в Cloud Storage, скриптов gCloud или необходимости управлять временными таблицами!
Рисунок 2: Новая архитектура, демонстрирующая прямое параллельное соединение для обратного ETL между BigQuery и AlloyDB.
Вот как просто выглядит новый процесс обратного ETL в коде:
Полученные значения из BigQuery идеально сопоставляются со стобцами AlloyDB во время экспорта, благодаря чему вложенные структуры остаются полностью доступными для запросов и индексации на стороне PostgreSQL.
Оценка производительности и масштабируемости
Чтобы проверить эту новую архитектуру, компания Copel провела два крупномасштабных бенчмарка обратного ETL, сравнив производительность и масштабируемость небольшого инкрементального экспорта Reverse ETL с гораздо более крупным полноразмерным экспортом всей таблицы.
Результаты производительности превзошли все первоначальные ожидания:
Метрика
Тест 1: Инкрементальный экспорт
Тест 2: Экспорт всей таблицы
Всего экспортировано строк
18 145 589 строк
207 484 577 строк
Логический размер данных
2,32 ГБ
188,87 ГБ
Пропускная способность экспорта
~3,1 миллиона строк/минута
~4,2 миллиона строк/минута
Характеристики AlloyDB
N2 (16 vCPU, 128 ГБ ОЗУ)
N2 (16 vCPU, 128 ГБ ОЗУ)
Загрузка ЦП
Стабильно держалась на уровне ~85%
Стабильно держалась на уровне ~85%
Полезный совет по загрузке: Поддержание пропускной способности экспорта на уровне ~4,2 миллиона строк в минуту для сложных полей телеметрии JSONB — это выдающееся техническое достижение. Оно подчеркивает низкоуровневые оптимизации между распределенным движком обработки BigQuery и продвинутым слоем хранения AlloyDB.
Основные выводы и преимущества
Приняв этот подход с декларативными SQL, компания Copel успешно удалила десятки строк сложного скриптинга и пользовательских блоков обработки ошибок. Их DAG в Airflow теперь содержит единственную упрощенную задачу BigQueryInsertJobOperator, которая выполняет запрос на экспорт.
Этот встроенный подход открывает несколько ключевых преимуществ для бизнеса:
- Прямое сокращение расходов: За счет полного обхода Cloud Storage отсутствуют затраты на хранение промежуточных данных и связанные с ними комиссии за операции чтения/записи через API.
Прямое сокращение расходов: За счет полного обхода Cloud Storage отсутствуют затраты на хранение промежуточных данных и связанные с ними комиссии за операции чтения/записи через API.
- Повышенная безопасность данных: Данные перемещаются напрямую из BigQuery в AlloyDB по защищенной внутренней сети Google, не выгружаясь в виде читаемых CSV-файлов.
Повышенная безопасность данных: Данные перемещаются напрямую из BigQuery в AlloyDB по защищенной внутренней сети Google, не выгружаясь в виде читаемых CSV-файлов.
- Обслуживание, стремящееся к нулю: Ошибки пайплайнов теперь локализованы в рамках одного SQL-запроса, что значительно упрощает поиск и устранение неисправностей, а также ведение журналов.
Обслуживание, стремящееся к нулю: Ошибки пайплайнов теперь локализованы в рамках одного SQL-запроса, что значительно упрощает поиск и устранение неисправностей, а также ведение журналов.
- Масштабируемая распределенная запись: Прямой экспорт позволил достичь скорости записи, превышающей 4 миллиона записей в минуту, за счет использования массового параллелизма BigQuery в сочетании с оптимизированной производительностью записи PostgreSQL в AlloyDB.
Масштабируемая распределенная запись: Прямой экспорт позволил достичь скорости записи, превышающей 4 миллиона записей в минуту, за счет использования массового параллелизма BigQuery в сочетании с оптимизированной производительностью записи PostgreSQL в AlloyDB.
Теперь вместо того, чтобы тратить драгоценные инженерные часы на мониторинг сбоев пайплайнов и промежуточных буферов хранения, команды по работе с данными могут сосредоточиться на том, что действительно важно: предоставлении интеллектуальной аналитики и качественного пользовательского опыта для клиентов.
Начните работу сегодня: модернизируйте свой обратный ETL
Теперь, когда функция экспорта из BigQuery в AlloyDB стала общедоступной, настал лучший момент для упрощения вашей архитектуры данных. Если ваша команда борется со сложными многоэтапными пайплайнами для передачи данных BigQuery в нижестоящие OLTP-базы данных, мы приглашаем вас попробовать встроенную функцию экспорта для AlloyDB, Bigtable, Spanner или Pub/Sub уже сегодня.
- Аналитика данных
- BigQuery
- Базы данных
