Проблема разрозненных данных подобна артриту для онлайн-бизнеса, потому что почти каждый заболевает с возрастом. Компании взаимодействуют с клиентами через веб-сайты, мобильные приложения, страницы 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 Для приема они используют метод . Их 30-поточный тест приема показывает, что он может выполнять более 300 000 обновлений в секунду. Для загрузки они используют комбинацию и Stream Load. Кроме того, при составлении отчетов в режиме реального времени, когда им необходимо извлечь данные из нескольких внешних источников данных, они используют функцию для . офлайн-данных Stream Load данных в реальном времени Flink-Doris-Connector мультикаталога объединенных запросов Рабочие процессы анализа клиентов в этом 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, учитывая огромный масштаб данных. Чтобы избежать этого, они используют функцию Apache Doris и включают . Это позволит значительно сократить потребление памяти и сохранить стабильность системы во время загрузки данных. INSERT INTO SELECT частичное обновление столбцов 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 Также опубликовано . здесь
