in ,

Интеграция Apache Doris в архитектуру данных: хранилище данных в реальном времени.

Руководство для пользователей Apache Doris, особенно в финансовом секторе, где требуется высокий уровень безопасности и доступности данных.

Если вы не знаете, как построить конвейер данных в реальном времени и получить максимальную отдачу от Apache Doris, этот пост – хорошее начало.

Это лучшая практика для поставщика небанковских платежных услуг, обслуживающего более 25 миллионов розничных продавцов и обрабатывающего данные с 40 миллионов конечных точек. Источниками данных являются MySQL, Oracle и MongoDB Они использовали Apache Hive в качестве отдельного хранилища данных, но почувствовали необходимость добавить конвейер обработки данных в режиме реального времени После развертывания Apache Doris скорость ввода данных увеличилась в 2-5 раз, производительность ETL – в 3-12 раз. 5 раз, производительность ETL – в 3-12 раз, а скорость выполнения запросов – в 10-15 раз.

В этом посте вы узнаете, как интегрировать Apache Doris в вашу архитектуру данных: как организовать данные в Doris, как загрузить их в Doris и как обеспечить эффективное обновление данных.

Вы также узнаете о корпоративных функциях Apache Doris, обеспечивающих безопасность данных, стабильность системы и доступность сервисов.

Создание хранилища данных в реальном времени с помощью Apache Doris

Выбор моделей данных

Apache Doris использует три модели данных для организации данных. Основное различие между этими моделями заключается в способе агрегирования данных.

  • Модель дублированного ключа: для детальных запросов данных. Он поддерживает специальные запросы любого измерения.
  • Модель уникального ключа: для случаев использования с ограничениями уникальности данных. Он поддерживает точную дедупликацию, многопоточные повторные выборки и частичные обновления столбцов.
  • Модель Aggregate Key: для создания отчетов о данных. Она ускоряет создание отчетов о данных за счет предварительной агрегации данных.

Финансовые пользователи используют различные модели данных на разных уровнях хранилища данных:

  • Модель ODS – дублирующих ключей: Как поставщик платежных услуг, пользователи ежедневно получают миллионы платежных данных. Поскольку цикл выставления счетов может длиться до года, соответствующие данные должны храниться в течение всего года. Поэтому правильный подход заключается в том, чтобы поместить их в модель реплицированных ключей без агрегации данных. Однако некоторые данные постоянно меняются, например статус заказа розничного продавца. Такие данные следует помещать в уникальную ключевую модель, чтобы новая обновленная запись с тем же идентификатором розничного продавца или идентификатором заказа всегда заменяла старую запись.
  • DWD & DWS – модель уникального ключа: Данные на уровне DWD и DWS еще более абстрагированы, но все они помещены в уникальную ключевую модель, чтобы вычисленные данные могли автоматически обновляться.
  • Ключевая модель ADS – Aggregate: На этом уровне данные сильно абстрагированы. Чтобы снизить вычислительную нагрузку при последующем анализе, данные предварительно агрегируются.

Стратегии секционирования и группирования

Идея секционирования и группировки данных заключается в том, чтобы “нарезать” данные и увеличить скорость их обработки.

Главное – установить соответствующее количество секций и сегментов данных. В зависимости от конкретного случая использования пользователи настраивают поля скобок и номера бинов для каждой таблицы.

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

Миграция данных из нескольких источников

При развертывании Apache Doris пользователям необходимо было перенести все локальные данные из своих филиалов в Doris. Миграция оказалась сложной, поскольку филиалы использовали разные базы данных и имели файлы данных в разных форматах.

Apache Doris поддерживает широкий спектр методов интеграции данных, как для потоковой передачи данных в режиме реального времени, так и для импорта данных в автономном режиме.

  • Потоковая передача данных в реальном времени: Apache Doris получает бинарные журналы MySQL в режиме реального времени. Часть из них записывается непосредственно в Doris через Flink CDC, а наиболее объемные синхронизируются в Kafka для максимального сокращения и записываются в Doris через Flink-Doris-Connector.
  • Автономный импорт данных: Это включает в себя большее разнообразие источников и форматов данных: исторические и дополнительные данные из S3 и HDFS загружаются в Doris с помощью метода Broker Load, а данные из Hive и JDBC синхронизируются в Doris с помощью метода Insert Into, Файлы загружаются в Doris с помощью Flink-Doris-Connector и Flink FTP Connector. (Поскольку FTP – это способ передачи файлов между системами, Flink-FTP-Connector разработан для поддержки сложных форматов данных и множества символов новой строки в данных).

Полный сбор данных и дополнительный сбор данных

Для обеспечения непрерывности работы и точности данных пользователи получают полные и дополнительные данные следующими способами

  • Полный прием данных: Создайте временную таблицу целевой схемы в Doris, введите полные данные во временную таблицу, а затем используйте ALTER TABLE t1 REPLACE WITH TABLE t2 инструкцию для атомной замены обычной таблицы временной таблицей. Этот метод предотвращает прерывание запросов во внешнем интерфейсе.
alter table ${DB_NAME}.${TBL_NAME} drop partition IF EXISTS p${P_DOWN_DATE};
ALTER TABLE ${DB_NAME}.${TBL_NAME} ADD PARTITION IF NOT EXISTS  p${P_DOWN_DATE} VALUES [('${P_DOWN_DATE}'), ('${P_UP_DATE}'));

LOAD LABEL ${TBL_NAME}_${load_timestamp} ...
  • Инкрементный прием данных: создайте новый раздел данных для размещения инкрементных данных.

Автономная обработка данных

Пользователь перенес часть своей рабочей нагрузки по автономной обработке данных на Apache Doris и, таким образом, увеличил скорость выполнения в 5 раз.

  • Раньше: Старое автономное хранилище данных на базе Hive ежедневно обрабатывало 30 миллионов новых записей данных с помощью механизма выполнения TEZ; при 2 ТБ вычислительных ресурсов весь конвейер занимал 2,5 часа.
  • После: Apache Doris выполняет ту же задачу всего за 30 минут и потребляет всего 1 ТБ. На выполнение сценариев уходит всего 10 секунд вместо восьми минут.

Корпоративные функции для финансовых игроков

Изоляция многопользовательских ресурсов

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

Ограничение ресурсов для различных рабочих нагрузок

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

Таким образом, если один клиент запросит слишком много ресурсов, его собственная эффективность будет только снижена и не повлияет на других клиентов.

Изоляция на основе тегов ресурсов

Чтобы обеспечить безопасность данных в иерархии материнской и дочерней компаний, пользователь создал раздельные группы ресурсов для дочерних компаний.

Данные каждой дочерней компании хранятся в собственной группе ресурсов с тремя копиями, а данные материнской компании – в четырех копиях, три из которых находятся в группе ресурсов материнской компании, а еще одна – в группе ресурсов дочерней.

Таким образом, если сотрудник дочерней компании запрашивает данные у материнской компании, запрос выполняется только в группе ресурсов дочерней компании. В частности, выполняются следующие шаги:

Группа рабочих нагрузок

Хотя план изоляции на основе ресурсных тегов обеспечивает изоляцию на физическом уровне, мы, разработчики Apache Doris, хотим еще больше оптимизировать использование ресурсов и обеспечить более тонкую изоляцию ресурсов. С этой целью в Apache Doris 2.0 мы выпустили функцию групп рабочих нагрузок.

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

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

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

Детализированное управление привилегиями пользователей

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

  • Настройка пользовательских привилегий: пользователям системы из разных дочерних компаний или с разными бизнес-потребностями предоставляются разные права доступа к данным.
  • Контроль привилегий над базами данных, таблицами и строкамиROW POLICY Механизм Apache Doris упрощает эти операции.
  • Контроль привилегий над столбцами: это делается путем создания представлений.

Гарантия стабильности кластера

  • Отключение сети: Иногда пользователи системы могут вводить некорректный SQL, что приводит к чрезмерному расходу ресурсов. По этой причине предусмотрен механизм отключения сети. Это позволяет быстро останавливать ресурсоемкие запросы и предотвращает перебои в работе системы.
  • Контроль параллелизма приема данных: часто приходится интегрировать исторические данные в свои платформы обработки данных. Это требует большого количества задач по модификации данных и может быть обременительным для кластеров. Чтобы решить эту проблему, включите режим слияния при записи в модель уникальных ключей, включите вертикальное и сегментное сжатие и настройте параметры сжатия данных для управления параллелизмом при вводе данных.
  • Управление сетевым трафиком: Поскольку два кластера расположены в разных городах, они используют стратегии качества обслуживания (QoS), адаптированные к различным сценариям, чтобы точно разделить сети и обеспечить их качество и стабильность.
  • Мониторинг и оповещения: Эти пользователи интегрировали Doris со своей собственной платформой мониторинга и оповещения, поэтому они получают уведомления о любых обнаруженных проблемах в режиме реального времени через программное обеспечение для обмена сообщениями или электронную почту.

Межкластерная репликация

Аварийное восстановление критически важно для финансовой отрасли. Пользователи используют функцию репликации между кластерами (CCR) для создания двухкластерного решения.

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

Это обеспечивает непрерывность бизнеса в случае перебоев в обслуживании основного кластера.

Заключение

Они также довольны тем, что многие функции Apache Doris отвечают потребностям их пользователей.

Они также изучат федеративные запросы, разделение вычислений и хранения данных и автоматизированное обслуживание с помощью Apache Doris. Мы с нетерпением ждем от них новых рекомендаций и отзывов.

What do you think?

Начинающий

Written by Drimprog

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

GIPHY App Key not set. Please check settings