Разрушение хранилищ данных: как Apache Doris оптимизирует интеграцию данных клиентов

Проблема разрозненных данных подобна артриту для онлайн-бизнеса, потому что почти каждый заболевает с возрастом. Компании взаимодействуют с клиентами через веб-сайты, мобильные приложения, страницы H5 и конечные устройства. По тем или иным причинам сложно интегрировать данные из всех этих источников. Данные остаются там, где они есть, и их нельзя связать между собой для дальнейшего анализа. Именно так формируются хранилища данных. Чем больше растет ваш бизнес, тем более диверсифицированными будут источники данных о клиентах и тем больше вероятность, что вы попадете в ловушку разрозненных данных.

Именно это происходит со страховой компанией, о которой я собираюсь рассказать в этом посте. К 2023 году они уже обслужили более 500 миллионов клиентов и заключили 57 миллиардов договоров страхования. Когда они начали создавать платформу данных клиентов (CDP) для размещения такого размера данных, они использовали несколько компонентов.

Хранилища данных в CDP

Как и большинство платформ данных, их CDP 1.0 имел конвейер пакетной обработки и конвейер потоковой передачи в реальном времени. Автономные данные загружались с помощью заданий Spark в Impala, где они были помечены и разделены на группы. Тем временем Spark также отправил его в NebulaGraph для вычисления OneID (подробно ниже в этом посте). С другой стороны, данные в реальном времени помечались Flink, а затем сохранялись в HBase и были готовы к запросу.

Это привело к появлению в CDP вычислительного уровня с большим количеством компонентов: Impala, Spark, NebulaGraph и HBase.

В результате автономные теги, теги реального времени и графические данные были разбросаны по нескольким компонентам. Их интеграция для дальнейших услуг по передаче данных была дорогостоящей из-за избыточного хранилища и объемной передачи данных. Более того, из-за несоответствий в хранилищах им пришлось расширить размер кластера CDH и кластера NebulaGraph, что увеличило затраты на ресурсы и обслуживание.

CDP на базе Apache Doris

Для CDP 2.0 они решили представить единое решение, чтобы навести порядок. На вычислительном уровне CDP 2.0 Apache Doris обеспечивает хранение и вычисления данных как в реальном времени, так и в автономном режиме.

Для приема офлайн-данных они используют метод Stream Load . Их 30-поточный тест приема показывает, что он может выполнять более 300 000 обновлений в секунду. Для загрузки данных в реальном времени они используют комбинацию Flink-Doris-Connector и Stream Load. Кроме того, при составлении отчетов в режиме реального времени, когда им необходимо извлечь данные из нескольких внешних источников данных, они используют функцию мультикаталога для объединенных запросов .

Рабочие процессы анализа клиентов в этом CDP выглядят следующим образом. Сначала они сортируют информацию о клиентах; затем они прикрепляют метки к каждому покупателю. На основе тегов они делят клиентов на группы для более целенаправленного анализа и работы.

Далее я углублюсь в эти рабочие нагрузки и покажу, как Apache Doris их ускоряет.

OneID

Случалось ли с вами когда-нибудь подобное, когда у вас используются разные системы регистрации пользователей для ваших продуктов и услуг? Вы можете получить адрес электронной почты UserID A с одной веб-страницы продукта, а затем номер социального страхования UserID B с другой. Затем вы обнаруживаете, что UserID A и UserID B на самом деле принадлежат одному и тому же человеку, поскольку у них один и тот же номер телефона.

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

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

Службы тегирования

Этот CDP содержит информацию о 500 миллионах клиентов , которая поступает из более чем 500 исходных таблиц и в общей сложности прикреплена к более чем 2000 тегам .

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

1. Офлайн-теги:

Во время пиков записи данных полное обновление может легко вызвать ошибку OOM, учитывая огромный масштаб данных. Чтобы избежать этого, они используют функцию INSERT INTO SELECT Apache Doris и включают частичное обновление столбцов . Это позволит значительно сократить потребление памяти и сохранить стабильность системы во время загрузки данных.

 set enable_unique_key_partial_update=true; insert into tb_label_result(one_id, labelxx) select one_id, label_value as labelxx from .....

2. Теги реального времени:

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

 curl --location-trusted -u root: -H "partial_columns:true" -H "column_separator:," -H "columns:id,balance,last_access_time" -T /tmp/test.csv http://127.0.0.1:48037/api/db1/user_profile/_stream_load

3. Точечные запросы с высоким параллелизмом:

Учитывая нынешний размер бизнеса, компания получает запросы на теги с уровнем параллелизма более 5000 QPS. Они используют комбинацию стратегий, чтобы гарантировать высокую производительность. Во-первых, они используют подготовленный оператор для предварительной компиляции и предварительного выполнения SQL. Во-вторых, они настраивают параметры Doris Backend и таблиц для оптимизации хранения и выполнения. Наконец, они включают кэширование строк в качестве дополнения к Apache Doris, ориентированному на столбцы.

• Точная настройка параметров Doris Backend в be.conf :

 disable_storage_row_cache = false storage_page_cache_limit=40%

• Точная настройка параметров таблицы при ее создании:

 enable_unique_key_merge_on_write = true store_row_column = true light_schema_change = true

4. Вычисление тегов (объединение):

На практике многие службы тегирования реализуются путем объединения нескольких таблиц в базе данных. Часто это включает более десяти таблиц. Для оптимальной производительности вычислений они применяют стратегию группового размещения в Doris.

Группировка клиентов

Конвейер группировки клиентов в CDP 2.0 выглядит следующим образом: Apache Doris получает SQL от службы поддержки клиентов, выполняет вычисления и отправляет набор результатов в объектное хранилище S3 через SELECT INTO OUTFILE. Компания разделила своих клиентов на 1 миллион групп. Задача группировки клиентов, выполнение которой раньше в Impala занимало 50 секунд , теперь требует всего 10 секунд в Doris .

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

В Apache Doris это реализовано с помощью функций BITMAP: BITMAP_CONTAINS — это быстрый способ проверить, является ли клиент частью определенной группы, а BITMAP_OR , BITMAP_INTERSECT и BITMAP_XOR — варианты перекрестного анализа.

Заключение

От CDP 1.0 до CDP 2.0 страховая компания использует Apache Doris, единое хранилище данных, вместо Spark+Impala+HBase+NebulaGraph. Это повышает эффективность обработки данных за счет устранения разрозненности данных и оптимизации конвейеров обработки данных. В грядущей версии CDP 3.0 они хотят сгруппировать своих клиентов, объединив теги реального времени и офлайн-теги для более диверсифицированного и гибкого анализа. Сообщество Apache Doris и команда VeloDB продолжат оказывать поддержку во время этого обновления.

Также опубликовано здесь .