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 sowohl die Echtzeit- als auch die Offline-Datenspeicherung und -berechnung. Apache Doris Um aufzunehmen, verwenden sie die Methode. Ihr 30-Thread-Ingestion-Test zeigt, dass über 300.000 Upserts pro Sekunde durchgeführt werden können. Zum Laden nutzen sie eine Kombination aus und Stream Load. Darüber hinaus nutzen sie bei Echtzeitberichten, bei denen sie Daten aus mehreren externen Datenquellen extrahieren müssen, die Funktion für . Offline-Daten Stream Load- von Echtzeitdaten Flink-Doris-Connector Multi-Catalog- 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 , die aus über stammen und insgesamt an über angehängt sind. 500 Millionen Kunden 500 Quelltabellen 2000 Tags 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 Funktion von Apache Doris und aktivieren . Dadurch wird der Speicherverbrauch erheblich reduziert und die Systemstabilität während des Datenladens aufrechterhalten. INSERT INTO SELECT- die teilweise Spaltenaktualisierung 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, auf zu setzen. 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. 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 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 als Ergänzung zum spaltenorientierten Apache Doris. vorbereitete Anweisung den Zeilencache 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 dauerte, dauert . in Impala früher 50 Sekunden 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: ist eine schnelle Möglichkeit, zu überprüfen, ob ein Kunde Teil einer bestimmten Gruppe ist, und , und sind die Auswahlmöglichkeiten für die Kreuzanalyse. BITMAP_CONTAINS BITMAP_OR BITMAP_INTERSECT BITMAP_XOR 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 und das Team werden bei diesem Upgrade weiterhin unterstützende Partner sein. Apache Doris-Community VeloDB- Auch veröffentlicht. hier

This story contains new, firsthand information uncovered by the writer.

Find the Apache Doris community on Slack

Read My Stories

Dieses Audio ist in der Originalsprache der Geschichte produziert!

Datensilos aufbrechen: Wie Apache Doris die Integration von Kundendaten optimiert

Zu lang; Lesen

People Mentioned

Frank Z

STORY’S CREDIBILITY

Original Reporting

About Author

Hängeetiketten

Languages

DIESER ARTIKEL WURDE VORGESTELLT IN...