Datensilos aufbrechen: Wie Apache Doris die Integration von Kundendaten optimiert

Das Problem der Datensilos ist für Online-Unternehmen wie Arthritis, denn fast jeder bekommt es mit zunehmendem Alter. Unternehmen interagieren mit Kunden über Websites, mobile Apps, H5-Seiten und Endgeräte. Aus dem einen oder anderen Grund ist es schwierig, die Daten aus all diesen Quellen zu integrieren. Die Daten bleiben dort, wo sie sind, und können nicht für weitere Analysen miteinander verknüpft werden. So entstehen Datensilos. Je größer Ihr Unternehmen wächst, desto vielfältiger werden Ihre Kundendatenquellen sein und desto wahrscheinlicher ist es, dass Sie in Datensilos gefangen bleiben.

Genau das passiert mit der Versicherungsgesellschaft, über die ich in diesem Beitrag sprechen werde. Bis 2023 haben sie bereits über 500 Millionen Kunden betreut und 57 Milliarden Versicherungsverträge abgeschlossen. Als sie mit dem Aufbau einer Kundendatenplattform (CDP) begannen, um eine solche Datenmenge zu bewältigen, verwendeten sie mehrere Komponenten.

Datensilos in CDP

Wie die meisten Datenplattformen verfügte auch ihr CDP 1.0 über eine Stapelverarbeitungs-Pipeline und eine Echtzeit-Streaming-Pipeline. Offline-Daten wurden über Spark-Jobs nach Impala geladen, wo sie markiert und in Gruppen unterteilt wurden. In der Zwischenzeit hat Spark es auch zur OneID-Berechnung an NebulaGraph gesendet (später in diesem Beitrag näher erläutert). Andererseits wurden Echtzeitdaten von Flink markiert und dann in HBase gespeichert, sodass sie abgefragt werden konnten.

Dies führte zu einer komponentenlastigen Rechenschicht im CDP: Impala, Spark, NebulaGraph und HBase.

Infolgedessen waren Offline-Tags, Echtzeit-Tags und Diagrammdaten auf mehrere Komponenten verteilt. Ihre Integration für weitere Datendienste war aufgrund der redundanten Speicherung und der umfangreichen Datenübertragung kostspielig. Darüber hinaus mussten sie aufgrund von Diskrepanzen im Speicher die Größe des CDH-Clusters und des NebulaGraph-Clusters erweitern, was zu höheren Ressourcen- und Wartungskosten führte.

Apache Doris-basiertes CDP

Für CDP 2.0 beschließen sie, eine einheitliche Lösung einzuführen, um das Chaos zu beseitigen. Auf der Berechnungsebene von CDP 2.0 übernimmt Apache Doris sowohl die Echtzeit- als auch die Offline-Datenspeicherung und -berechnung.

Um Offline-Daten aufzunehmen, verwenden sie die Stream Load- Methode. Ihr 30-Thread-Ingestion-Test zeigt, dass über 300.000 Upserts pro Sekunde durchgeführt werden können. Zum Laden von Echtzeitdaten nutzen sie eine Kombination aus Flink-Doris-Connector und Stream Load. Darüber hinaus nutzen sie bei Echtzeitberichten, bei denen sie Daten aus mehreren externen Datenquellen extrahieren müssen, die Multi-Catalog- Funktion für Verbundabfragen .

Die Kundenanalyse-Workflows auf diesem CDP sehen folgendermaßen aus. Zuerst sortieren sie die Kundeninformationen; Anschließend versehen sie jeden Kunden mit einem Etikett. Anhand der Tags teilen sie Kunden für eine gezieltere Analyse und Bedienung in Gruppen ein.

Als Nächstes werde ich mich mit diesen Arbeitslasten befassen und Ihnen zeigen, wie Apache Doris sie beschleunigt.

OneID

Ist Ihnen das schon einmal passiert, wenn Sie unterschiedliche Benutzerregistrierungssysteme für Ihre Produkte und Dienstleistungen haben? Möglicherweise erfassen Sie die E-Mail-Adresse von Benutzer-ID A von einer Produktwebseite und später die Sozialversicherungsnummer von Benutzer-ID B von einer anderen. Dann stellen Sie fest, dass Benutzer-ID A und Benutzer-ID B tatsächlich derselben Person gehören, da sie dieselbe Telefonnummer verwenden.

Darum entsteht OneID als Idee. Dabei werden die Benutzerregistrierungsinformationen aller Geschäftsbereiche in einer großen Tabelle in Apache Doris zusammengefasst, sortiert und sichergestellt, dass ein Benutzer eine eindeutige OneID hat.

Auf diese Weise finden sie mithilfe der Funktionen von Apache Doris heraus, welche Registrierungsinformationen zum selben Benutzer gehören.

Tagging-Dienste

Dieses CDP beherbergt Informationen von 500 Millionen Kunden , die aus über 500 Quelltabellen stammen und insgesamt an über 2000 Tags angehängt sind.

Nach Aktualität können die Tags in Echtzeit-Tags und Offline-Tags unterteilt werden. Die Echtzeit-Tags werden von Apache Flink berechnet und in die flache Tabelle in Apache Doris geschrieben, während die Offline-Tags von Apache Doris berechnet werden, da sie aus der Benutzerattributtabelle, der Geschäftstabelle und der Benutzerverhaltenstabelle in Doris abgeleitet werden. Hier ist die Best Practice des Unternehmens beim Daten-Tagging:

1. Offline-Tags:

Während der Datenschreibspitzen kann ein vollständiges Update angesichts des großen Datenumfangs leicht zu einem OOM-Fehler führen. Um dies zu vermeiden, nutzen sie die INSERT INTO SELECT- Funktion von Apache Doris und aktivieren die teilweise Spaltenaktualisierung . Dadurch wird der Speicherverbrauch erheblich reduziert und die Systemstabilität während des Datenladens aufrechterhalten.

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

2. Echtzeit-Tags:

Teilweise Spaltenaktualisierungen sind auch für Echtzeit-Tags verfügbar, da Echtzeit-Tags unterschiedlich schnell aktualisiert werden. Alles, was benötigt wird, ist, partial_columns auf true zu setzen.

 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. Punktabfragen mit hoher Parallelität:

Aufgrund seiner aktuellen Unternehmensgröße erhält das Unternehmen Abfrageanfragen für Tags mit einer Parallelitätsstufe von über 5000 QPS. Sie verwenden eine Kombination von Strategien, um eine hohe Leistung zu gewährleisten. Erstens übernehmen sie eine vorbereitete Anweisung zur Vorkompilierung und Vorausführung von SQL. Zweitens optimieren sie die Parameter für Doris Backend und die Tabellen, um die Speicherung und Ausführung zu optimieren. Schließlich ermöglichen sie den Zeilencache als Ergänzung zum spaltenorientierten Apache Doris.

• Feinabstimmung der Doris-Backend-Parameter in be.conf :

 disable_storage_row_cache = false storage_page_cache_limit=40%

• Feinabstimmung der Tabellenparameter bei der Tabellenerstellung:

 enable_unique_key_merge_on_write = true store_row_column = true light_schema_change = true

4. Tag-Berechnung (Join):

In der Praxis werden viele Tagging-Dienste durch Multi-Table-Joins in der Datenbank implementiert. Dabei handelt es sich oft um mehr als zehn Tische. Für eine optimale Rechenleistung übernehmen sie in Doris die Colocation-Gruppenstrategie .

Kundengruppierung

Die Kundengruppierungspipeline in CDP 2.0 sieht folgendermaßen aus: Apache Doris empfängt SQL vom Kundendienst, führt die Berechnung aus und sendet den Ergebnissatz über SELECT INTO OUTFILE an den S3-Objektspeicher. Das Unternehmen hat seine Kunden in 1 Million Gruppen eingeteilt. Die Kundengruppierungsaufgabe, die in Impala früher 50 Sekunden dauerte, dauert in Doris jetzt nur noch 10 Sekunden .

Abgesehen von der Gruppierung der Kunden für eine detailliertere Analyse führen sie manchmal auch eine Analyse in umgekehrter Richtung durch. Das heißt, einen bestimmten Kunden anzusprechen und herauszufinden, zu welchen Gruppen er/sie gehört. Dies hilft Analysten, die Merkmale der Kunden sowie die Überschneidungen verschiedener Kundengruppen zu verstehen.

In Apache Doris wird dies durch die BITMAP-Funktionen implementiert: BITMAP_CONTAINS ist eine schnelle Möglichkeit, zu überprüfen, ob ein Kunde Teil einer bestimmten Gruppe ist, und BITMAP_OR , BITMAP_INTERSECT und BITMAP_XOR sind die Auswahlmöglichkeiten für die Kreuzanalyse.

Abschluss

Von CDP 1.0 bis CDP 2.0 übernimmt die Versicherungsgesellschaft Apache Doris, ein einheitliches Data Warehouse, um Spark+Impala+HBase+NebulaGraph zu ersetzen. Dadurch wird die Effizienz der Datenverarbeitung erhöht, indem die Datensilos aufgebrochen und die Datenverarbeitungspipelines optimiert werden. Im kommenden CDP 3.0 möchten sie ihre Kunden durch die Kombination von Echtzeit-Tags und Offline-Tags gruppieren, um eine vielfältigere und flexiblere Analyse zu ermöglichen. Die Apache Doris-Community und das VeloDB- Team werden bei diesem Upgrade weiterhin unterstützende Partner sein.

Auch hier veröffentlicht.