Einleitung zu diesem Artikel:
Derzeit fördern technologische Anwendungen wie Big Data, künstliche Intelligenz und Cloud Computing die Entwicklung der Versicherungstechnologie und beschleunigen den Digitalisierungsprozess der Versicherungsbranche. Vor diesem Hintergrund erforscht Cigna weiterhin, wie mehrere Daten integriert und erweitert werden können, um Agenten in die Lage zu versetzen, detailliertere Benutzerhinweise zu erfassen und intelligente Analysen in die gesamte Geschäftskette zu integrieren, um ein umfassendes Verständnis von Benutzern, Produkten und Szenariostrategien zu erreichen Closed-Loop-Iteration. In diesem Artikel wird Cignas Forschungsreise in die Big-Data-Infrastruktur ausführlich vorgestellt, von der ersten OLAP-Engine, die Dienste für Online-Berichte und Ad-hoc-Analysen bereitstellte, bis hin zu einem einheitlichen Echtzeit-Data-Warehouse auf Basis von Apache Doris. Durch eine Reihe von Architekturen ermöglicht Echtzeitanalysen und integrierte einheitliche Verwaltung mehrerer Daten in verschiedenen Geschäftsfeldern und erreicht letztendlich das Ziel, Kosten zu senken und Einnahmen in Versicherungsunternehmen an vorderster Front zu steigern.
Autor: Forschungs- und Entwicklungsteam der Cigna Big Data Platform
China Merchants Cigna Life Insurance Co., Ltd. ist ein chinesisch-ausländisches Joint-Venture-Lebensversicherungsunternehmen zwischen der China Merchants Bank und der Cigna Group. Es bietet Unternehmen und Privatpersonen Produkte und Dienstleistungen in den Bereichen Versicherungsschutz, Gesundheitsmanagement, Vermögensplanung und andere Produkte. Derzeit hat Cigna mehr als 10 Millionen Kunden betreut und Schadensregulierungen für mehr als 1 Million Kunden abgeschlossen. Mit seinen praktischen Gesundheitsmanagementdiensten aus einer Hand und der flexiblen Konfiguration „maßgeschneiderter“ Versicherungspläne hat das Unternehmen die anhaltende Auswahl und das Vertrauen von gewonnen Benutzer.
Angesichts des explosionsartigen Wachstums des globalen Datenvolumens werden Aktualität und Genauigkeit der Daten für Unternehmen immer wichtiger, um ihre Abläufe zu optimieren. Wir hoffen, mithilfe von Daten das Kundenverhalten schnell erkennen, Kundenprobleme lokalisieren und die von den Benutzern benötigten Produkte und Dienstleistungen effizient anpassen zu können, um so Ziele wie ein verfeinertes Geschäftsmarketing und eine Erweiterung der versicherbaren Grenzen zu erreichen.
Da das Geschäft weiter wächst und die Analyseszenarien immer vielfältiger werden, sind die Anforderungen an Geschäftsanalysten immer komplexer geworden. Data Warehouses müssen nicht nur in der Lage sein, schnell Datenberichte zu entwickeln, sondern auch die Integration von Streaming-Batches und Seen zu realisieren Lager und diversifizierte Datentypen. Vereinheitlichen Sie Analyse und Verwaltung. Beim Aufbau einer Big-Data-Infrastruktur werden diese integrierten und einheitlichen Funktionen von entscheidender Bedeutung. In diesem Zusammenhang wird die Data-Warehouse-Architektur weiterhin aktualisiert und verbessert, von der anfänglichen Architektur der ersten Generation, die nur BI-Berichte und große Datenbildschirme unterstützt, über die Architektur der zweiten Generation, die mehrere Systeme und Komponenten zur Bereitstellung von Datendiensten verwendet, bis hin zur heutigen Architektur Neue Generation einheitlicher Echtzeitdaten Das Warehouse verwendet eine Reihe von Apache Doris-Komponenten, um eine Vereinfachung der Architektur, eine Vereinheitlichung des Technologie-Stacks sowie eine einheitliche Verwaltung und Analyse von Daten zu erreichen , was nicht nur die Effizienz der Datenverarbeitung verbessert, sondern auch mehr erfüllt vielfältige Anforderungen an die Datenanalyse.
In diesem Artikel wird detailliert beschrieben, wie Cigna während des Iterations- und Aktualisierungsprozesses der Data-Warehouse-Architektur Speicher-, Berechnungs- und Abfrageexporte auf Basis von Apache Doris vereinheitlicht, wie die Anforderungen an die Aktualität von Schreibvorgängen erfüllt werden und wie Enumerationen mit hoher Parallelität und Multi durchgeführt werden -Tabellenkorrelation in Szenarien wie Erzielen einer extrem schnellen Abfrageleistung, Bereitstellung von Unterstützung für effizientes Schreiben und Abfragen von Vertriebs-Leads, hochfrequente Aktualisierungen von Kundenbindungsinformationen, konsistenter Zugriff auf Service-Szenariodaten usw., wodurch Kunden-Leads weiter in private Domänen umgewandelt werden Geschäftsmöglichkeiten, die Unternehmen in den Bereichen Betrieb, Dienstleistungen, Marketing usw. stärken. Vielseitige Fähigkeiten.
Architektur 1.0: Mehrkomponentiges Quasi-Echtzeit-Data-Warehouse
Die anfängliche Geschäftsanforderung besteht darin, das Data Warehouse zum Hosten von drei Arten von Geschäftsszenarien zu verwenden: Self-Service-Richtlinienabfragen für C-End-Benutzer, mehrdimensionale Analyseberichte für Geschäftsanalysten und Echtzeit-Daten-Dashboards für Manager. Das Data Warehouse muss eine einheitliche Speicherung von Geschäftsdaten und effiziente Abfragefunktionen bieten, um eine effiziente Geschäftsanalyse und Entscheidungsfindung zu unterstützen. Außerdem muss es das Zurückschreiben von Daten unterstützen, um Geschäftsabläufe mit geschlossenem Regelkreis zu erreichen.
- Self-Service-Police-Abfrage: Benutzer können den Versicherungsvertrag anhand der Police-ID über die Cigna Merchants APP selbst abfragen oder benutzerdefinierte Filterabfragen über verschiedene Dimensionen (z. B. Deckungsdauer, Versicherungskategorie, Schadenshöhe) durchführen, um darin enthaltene Informationen anzuzeigen den Lebenszyklus der Police.
- Mehrdimensionale Berichtsanalyse: Basierend auf den Geschäftsanforderungen entwickeln Geschäftsanalysten detaillierte Daten- und Indikatorendimensionsberichte, um geschäftliche Einblicke in Produktinnovationen, Tarife, Betrugsbekämpfung usw. bei Policen zu gewinnen und entsprechende Anpassungen der Geschäftsstrategie zu unterstützen.
- Dashboard: Wird hauptsächlich für Echtzeit-Großbildschirme eines bestimmten Bankkanals und einer bestimmten Filiale verwendet. Durch die einheitliche Aggregation von Indikatoren und anderen Daten werden beliebte Versicherungsarten, Tagesverkäufe, Gesamtzahlung und Anteil der Versicherungsarten sowie Versicherungsinformationen über die Jahre hinweg angezeigt Beispielsweise wird der Zahlungserhöhungstrend auf dem großen Echtzeitbildschirm angezeigt.
In der frühen Geschäftsphase waren die Anforderungen an Datendienste relativ einfach, hauptsächlich um die Aktualität der Berichtsdaten zu verbessern. Daher haben wir beim Aufbau des Data Warehouse die typische Lambda-Architektur übernommen, um Daten über zwei Links zu sammeln: Echtzeit und offline. , Computer und Speicherung, wobei das Data Warehouse hauptsächlich unter Verwendung eines breiten Tabellenmodells entwickelt wurde, um die Abfrage und Analyse von Indikatordaten und detaillierten Daten zu unterstützen.
Wie Sie dem Architekturdiagramm entnehmen können, ist FlinkCDC für die Echtzeit-Datenerfassung verantwortlich, und unsere selbst entwickelten Hisen-Tools (einschließlich Sqoop, DataX und Python) sind für die Offline-Datenerfassung verantwortlich. Nachdem die Originaldaten gesammelt wurden, werden Echtzeitdaten mit Flink berechnet und Offline-Daten zur Stapelverarbeitung an Hive übergeben. Schließlich werden sie in verschiedene OLAP-Komponenten (einschließlich Presto, Clickhouse, HBase und MySQL) importiert. OLAP Bietet Datendienste für übergeordnete Unternehmen. Unter ihnen spielt jede Komponente eine andere Rolle in der Architektur:
MySQL
Je nach Geschäftsanforderungen wird es hauptsächlich zum Speichern von Indikatordaten nach der Datenberechnung verwendet. Derzeit beträgt das Datenvolumen von Data-Warehouse-Tabellen mehrere zehn Millionen, der MySQL-Speicher weist jedoch Einschränkungen auf und ist anfällig für Probleme wie lange Ausführungszeiten und Systemrückgabefehler.
Clickhouse
Clickhouse schneidet bei der Leseleistung von Einzeltabellendaten gut ab, weist jedoch eine schwache Leistung beim Zusammenführen großer Tabellen auf. Da Geschäftsszenarien zunehmen und die Menge an Echtzeitdaten weiterhin überlagert und aktualisiert wird, unterliegt Clickhouse bestimmten Einschränkungen bei der Bewältigung neuer Geschäftsanforderungen:
- Um die wiederholte Berechnung von Indikatoren zu reduzieren, muss ein Sternschema für die Zuordnung mehrerer Tabellen und Abfragen mit hoher Parallelität eingeführt werden. Clickhouse kann dies jedoch nicht unterstützen.
- Wenn sich der Inhalt der Richtlinie ändert, müssen die Daten in Echtzeit aktualisiert und geschrieben werden. Allerdings fehlt Clickhouse die Unterstützung für Echtzeittransaktionen. Bei Datenänderungen müssen breite Tabellen neu generiert werden, um alte Daten zu überschreiben. Es gibt bestimmte Datenmängel Anforderungen an die Aktualität der Aktualisierung;
HBase
Wird hauptsächlich zur Primärschlüsselabfrage und zum Lesen grundlegender Benutzerstatusdaten aus MySQL und Hive verwendet, einschließlich Kundenpunkten, Versicherungszeit und kumulierter Versicherungssumme. Da HBase keine Sekundärindizes unterstützt, ist das Lesen nicht-primärer Schlüsseldaten begrenzt und kann verwandte Abfrageszenarien nicht erfüllen. Gleichzeitig unterstützt HBase keine SQL-Anweisungsabfragen.
Presto
Aufgrund der Szenariobeschränkungen der oben genannten Komponenten bei der Datenabfrage haben wir Presto auch als Abfrage-Engine für Offline-Daten eingeführt, um interaktive Analysen mit Daten in Hive durchzuführen und Berichtsdienste für das Upstream-Ende bereitzustellen.
Nach der Einführung von Data Warehouse 1.0 wurde es in mehr als 10 Branchen eingesetzt und eine große Anzahl großer Datenbildschirme und BI-Berichte entwickelt. Mit der kontinuierlichen Erweiterung des Geschäftsumfangs stellen Szenarien wie Marketing, Betrieb und Kundendienst höhere Anforderungen an das Schreiben von Daten und die Abfrageleistung. Die Architektur der Version 1.0, die vier Komponenten zur Bereitstellung von Datendiensten verwendet, weist jedoch im tatsächlichen Geschäft einige Herausforderungen auf . . Um Probleme wie erhöhte Betriebs- und Wartungskosten und erhöhte Lernkosten für F&E-Personal aufgrund zu vieler Architekturkomponenten zu vermeiden und die Konsistenz von Daten aus mehreren Quellen in Offline- und Echtzeitverbindungen sicherzustellen, haben wir uns entschieden, eine zu starten iterative Reise von Architekturaktualisierungen.
Komponentenanforderungen und Systemauswahl
Um den Geschäftsanforderungen gerecht zu werden, müssen wir die Architektur „auslagern“ und den Datenverarbeitungsprozess so weit wie möglich verkürzen. Die 1.0-Architektur wird aufgrund von Problemen wie zu vielen Komponenten und Verbindungsredundanz zwangsläufig die Leistung und Aktualität der Datenspeicherung und -analyse beeinträchtigen. Daher hoffen wir, ein OLAP-System zu finden, das die meisten Geschäftsszenarien abdeckt, die durch komplexe Technologie-Stacks verursachten Entwicklungs-, Betriebs- und Wartungs- sowie Nutzungskosten senkt und die Architekturleistung maximiert. Spezifische Anforderungen sind wie folgt:
- Importleistung: Es verfügt über die Fähigkeit zum Schreiben und Aktualisieren in Echtzeit und unterstützt das Schreiben großer Datenmengen mit hohem Durchsatz.
- Abfrageleistung: Bietet Abfragedienste für dimensionale Daten und Transaktionsdaten mit leistungsstarken Echtzeit-Abfragefunktionen für große Datenmengen.
- Flexible mehrdimensionale Analyse und Self-Service-Abfragefunktionen: Es kann nicht nur Primärschlüsselindizes unterstützen, um Punkt- und Bereichsabfragen bereitzustellen, sondern auch mehrdimensionale Abrufanalysen unterstützen, Tabellenkorrelationsabfragen für Milliarden von Daten bereitstellen usw Realisieren Sie flexible und dynamische Drill-Down- und Roll-Up-Dienste. Datenanalyse.
- Vereinfachung der Datenplattformarchitektur: Es wird eine Komponente mit starken umfassenden Funktionen benötigt, um die aktuelle redundante Architektur zu ersetzen und den Anforderungen des Lesens und Schreibens von Echtzeit- und Offline-Daten, einer hohen Abfrageleistung in verschiedenen Szenarien sowie einer einfachen und leicht zu bedienenden Architektur gerecht zu werden. Verwenden Sie SQL-Anweisungsabfragen.
Auf dieser Grundlage haben wir mit der Systemauswahl begonnen, beliebte Komponenten auf dem Markt in vielerlei Hinsicht mit vorhandenen Architekturen verglichen und bewertet, ob sie den Geschäftsanforderungen für Komponenten entsprechen. Schließlich haben wir Apache Doris unter vielen OLAPs gesperrt. Die spezifischen Gründe sind wie folgt:
- Unterstützt Echtzeit-Schreiben mit geringer Latenz: Unterstützt das Hochdurchsatz-Schreiben von FlinkCDC bei großen Datenmengen und stellt externe Datendienste in Echtzeit bereit; unterstützt das Zusammenführen von Primärschlüsseltabellenmodellen zur Schreibzeit und realisiert Mikrobatch-Hochfrequenz-Echtzeitschreiben; unterstützt Upsert und Insert Overwrite sorgen für eine hocheffiziente Datenaktualisierung.
- Stellen Sie sicher, dass die Daten konsistent und geordnet sind: Unterstützt den Label-Mechanismus und den Transaktionsimport, um die Exactly-Once-Semantik während des Schreibvorgangs sicherzustellen; unterstützt die Sequenzspalteneinstellungen des Primärschlüsselmodells, um die Ordnung während des Datenimports sicherzustellen.
- Hervorragende Abfrageleistung: Doris unterstützt Rollup-Voraggregation und materialisierte Ansichten, um die Abfragebeschleunigung zu vervollständigen; unterstützt die Vektorisierungsverarbeitung, um virtuelle Funktionsaufrufe und Cache-Miss zu reduzieren; unterstützt invertierten Index, um den Volltextabruf oder Bereichsabfragen wie Text, gewöhnliche Werte usw. zu beschleunigen Termine.
- Unterstützt Punktabfragen mit hoher Parallelität: Unterstützt Partitionierung und Bucketing, Partitionierungszeit durch Partition und Festlegen der Anzahl von Buckets zum Filtern unnötiger Daten, um das Scannen zugrunde liegender Daten zu reduzieren und eine schnelle Abfragepositionierung zu erreichen. Darüber hinaus werden in Doris 2.0 Version A-Serie neue Zeilen hinzugefügt Zahlreiche Optimierungen wie das traditionelle Speicherformat, die Kurzpfadaufzählung und Vorverarbeitungsanweisungen verbessern die Effizienz der Aufzählungsausführung weiter und reduzieren den SQL-Parsing-Overhead.
- Unterstützt mehrere Datenmodelle: Unterstützt Sternschemata, um die Anforderungen der zugehörigen Abfrage von Milliarden von Datentabellen zu erfüllen; unterstützt die Aggregation großer und breiter Tabellen, um eine extrem schnelle Abfrageleistung und mehrdimensionale Analysefunktionen für einzelne Tabellen bereitzustellen.
- Einfache Architektur, einfacher Betrieb und Wartung, einfache Erweiterung und hohe Verfügbarkeit: Doris FE-Knoten sind für die Verwaltung von Metadaten und mehreren Kopien verantwortlich, und BE-Knoten sind für die Datenspeicherung und Aufgabenausführung verantwortlich. Dadurch ist die Architektur einfach bereitzustellen und zu konfigurieren sowie leicht zu bedienen und zu warten. Gleichzeitig kann Doris Knoten mit einem Klick hinzufügen und entfernen, automatische Kopiervervollständigung und Lastausgleich zwischen Knoten durchführen, was eine einfache Erweiterung ermöglicht; und wenn a Fällt ein einzelner Knoten aus, kann Doris den Cluster weiterhin aufrechterhalten. Der stabile Betrieb entspricht unseren Anforderungen an hohe Serviceverfügbarkeit und hohe Datenzuverlässigkeit.
Aus der Vergleichstabelle können wir auch ersehen, dass Apache Doris unabhängig davon, ob in Echtzeit- oder Offline-Szenarien, über die ausgewogensten und besten umfassenden Funktionen verfügt und Self-Service-Abfragen, Echtzeit- und Offline-OLAP-Analysefunktionen sowie hohe Parallelität unterstützen kann Abfrage- und Tabellenzuordnung usw. Abfrageszenarien und hervorragende Schreibleistung, hohe Verfügbarkeit, Benutzerfreundlichkeit usw. Es handelt sich um eine Komponente, die mehrere Geschäftsszenarien erfüllen kann.
Architektur 2.0: Einheitlicher Technologie-Stack basierend auf Apache Doris
Die beiden Generationen der Data-Warehouse-Architektur unterscheiden sich hauptsächlich hinsichtlich der Speicherung, Berechnung, Abfrage und Analyse. Version 1.0 basiert auf mehreren Komponenten, um die OLAP-Analyse-Engine gemeinsam aufzubauen. Während der Geschäftserweiterungsphase treten nach und nach Probleme wie Architekturspeicherredundanz, Datenlatenz und übermäßige Wartungskosten auf. Architekturversion 2.0 basiert auf der Aktualisierung und Transformation von Apache Doris, ersetzt die vier Komponenten Presto, MySQL, HBase und Clickhouse und migriert Daten zu Apache Doris, um einheitliche externe Abfragedienste bereitzustellen.
Die neue Architektur vereinheitlicht nicht nur den Technologie-Stack , sondern reduziert auch die Kosten für Entwicklung, Speicherung, Betrieb und Wartung und vereinheitlicht Geschäft und Daten weiter. Ein auf Apache Doris basierendes System kann sowohl die Online- als auch die Offline-Aufgabenverarbeitung unterstützen, um eine einheitliche Datenspeicherung zu erreichen . Es kann Datenanalysedienste in verschiedenen Szenarien erfüllen, interaktive Analysen mit hohem Durchsatz und Punktabfragen mit hoher Parallelität unterstützen und eine einheitliche Geschäftsanalyse erreichen .
01Beschleunigen Sie die Effizienz der Datenanalyse
Durch die extrem schnelle Analyseleistung von Doris kann QPS in Punktabfrageszenarien mit hoher Parallelität für C-Seite-Benutzer Tausende bis Zehntausende erreichen, und bei Abfragen von Hunderten Millionen oder Milliarden Daten können Antworten auf Millisekundenebene erzielt werden; verwenden Sie Doris‘ Umfangreiche Datenimportmethoden und effiziente Schreibfunktionen, Erzielung einer Schreiblatenz der zweiten Ebene und Verwendung der Zusammenführung von Unique Key-Schreibzeiten, um die Abfrageleistung in der parallelen Lese- und Schreibphase weiter zu beschleunigen. Darüber hinaus haben wir Doris Hot- und Cold-Tiering verwendet, um umfangreiche historische Cold-Daten auf kostengünstigen Speichermedien zu speichern, wodurch die Speicherkosten historischer Daten gesenkt und die Abfrageeffizienz heißer Daten verbessert wurden.
02Reduzieren Sie verschiedene Kosten und Ausgaben
Im Vergleich zur ursprünglichen Architektur hat die neue Architektur die Anzahl der Kernkomponenten um die Hälfte reduziert, die Plattformarchitektur erheblich vereinfacht und die Betriebs- und Wartungskosten erheblich gesenkt. Darüber hinaus eliminiert Apache Doris die Notwendigkeit, Datenspeicherung und Abfragedienste über verschiedene Komponenten abzuwickeln, vereinheitlicht Echtzeit- und Offline-Geschäftslasten und senkt die Speicherkosten; die Datendienst-API muss bei der Bereitstellung keine Echtzeit- und Offline-Daten mehr zusammenführen externe Dienste, wodurch die Datendienst- API-Entwicklungskosten während des Zugriffs auf 50 % reduziert werden;
03 Stellen Sie eine hohe Verfügbarkeit von Datendiensten sicher
Aufgrund der einheitlichen Speicher-, Computer- und Service-Data-Warehouse-Architektur von Doris ist der gesamte Disaster-Recovery-Plan der Plattform einfach zu implementieren, und es besteht kein Grund zur Sorge über Datenverluste und Duplikate, die durch mehrere Komponenten verursacht werden. Noch wichtiger ist, dass die integrierte CCR-Funktion für die Cross-Cluster-Replikation von Doris eine sekundengenaue Synchronisierung von Datenbanktabellen zwischen Clustern ermöglichen kann . Wenn ein Systemabsturz zu Geschäftsunterbrechungen oder -verlusten führt, können wir die Sicherung schnell wiederherstellen.
Die beiden Hauptmechanismen der Cross-Cluster-Replikations-CCR-Funktion von Doris erfüllen unsere Anforderungen an die Verfügbarkeit von Systemdiensten und stellen eine hohe Verfügbarkeit von Datendiensten sicher. Die Details lauten wie folgt:
- Binlog-Mechanismus: Wenn sich Daten ändern, können wir durch diesen Mechanismus automatisch die Aufzeichnungen und Vorgänge von Datenänderungen aufzeichnen und für jeden Vorgang eine zunehmende Folge von LogIDs erstellen, um die Rückverfolgbarkeit und Ordnung der Daten zu erreichen.
- Persistenzmechanismus: Nach einem Systemabsturz oder einem Notfall kann dieser Mechanismus Daten auf der Festplatte speichern, um die Zuverlässigkeit und Konsistenz der Daten sicherzustellen.
Einkommen und Praxis des Versicherungsgeschäfts an vorderster Front
Derzeit wurde das Echtzeit-Data-Warehouse auf Basis des einheitlichen Technologie-Stacks von Apache Doris im dritten Quartal 2022 eingeführt und in die Produktionsumgebung überführt. Es dient zur Unterstützung effizienter OLAP-Analysefunktionen für große Datenmengen und unterstützt weitere geschäftsbezogene Szenarien Plattform. Auch im Hinblick auf den Geschäftsbetrieb nimmt der Umfang der Vertriebskontakte stetig zu und hat inzwischen die 100-Millionen-Marke erreicht. Mit der weiteren Einführung der Apache Doris-Funktionen wächst auch der durch Data Warehouses unterstützte Frontline-Geschäftsumsatz weiter.
- Effiziente Verfolgung von Vertriebskontakten: Derzeit haben wir mehr als 30 neue Szenarioanwendungen für die Vertriebs- und Leistungsverfolgung eingeführt. Geschäftsmitarbeiter können auf offiziellen Websites, in APPs, in Einkaufszentren, auf öffentlichen Konten, in Miniprogrammen und auf anderen Kanälen genau und schnell Informationen zur Kundenversicherung erhalten zu Vertriebs-Leads. Tracks und Daten wie Bewertungen, Live-Übertragungs-Teilnahmedaten, Unternehmens-Mikroaktivitäts-Teilnahmedaten, versicherungsfreie Versicherungen usw. werden durch die mehrdimensionale Analyse von Apache Doris in Hinweise umgewandelt, um letztendlich einen genauen Kundenkontakt zu erreichen und effektiv zu erfassen Kundenmotivation und zeitnahe Auftragsverfolgung.
- Hochfrequenzaktualisierung von Kundenbindungsinformationen: Über 20 neue Szenarioanwendungen wurden in den Kategorien Neukundenkonvertierung und Altkundenbetreuung eingeführt. Der reibungslose Ablauf von Geschäftsszenarien ist untrennbar mit der Hochfrequenzaktualisierungsfähigkeit der Kundenbindungsinformationen der Datenplattform verbunden. Apache Doris wird zur Aktualisierung alter Kunden verwendet. Durch regelmäßige Datenanalysen können die Versicherungsgeschäftsanforderungen der Kunden in verschiedenen Phasen effektiv abgefragt, die Schutzlücken alter Kunden ermittelt, die versicherbaren Grenzen alter Kunden erweitert und das Betriebsergebnis des Unternehmens weiter gesteigert werden.
- Konsistenter Zugriff auf Geschäftsszenariodaten: Im Hinblick auf den Kundenservice legen wir mehr Wert darauf, den Kunden ein konsistentes Erlebnis und schnelle Reaktionsdienste zu bieten. Derzeit haben wir mehr als 20 neue Szenarioanwendungen im Zusammenhang mit der Serviceerfahrung eingeführt, um Informationsasymmetrie und Dateninkonsistenz zu vermeiden und sicherzustellen, dass die Daten jeder Vertriebsverbindung in den Bereichen Underwriting, Schadensregulierung, Kundendienstberatung, Mitgliedercenter usw. konsistent und einheitlich sein können andere Prozesse.
Zukunftsplan
Die Einführung von Apache Doris spielt eine entscheidende Rolle bei der Vereinfachung der Echtzeit-Data-Warehouse-Architektur und der Verbesserung der Leistung. Derzeit haben wir mehrere Komponenten von Presto, Clickhouse, MySQL und HBase auf Basis von Apache Doris ersetzt, um den OLAP-Technologie-Stack zu vereinheitlichen, verschiedene Kosten zu senken und die Import- und Abfrageleistung zu verbessern.
Gleichzeitig planen wir, Doris weiterhin in der Batch-Layer-Testanwendung (Batch Layer) zu verwenden, um die Offline-Datenstapelverarbeitung in Doris zu vereinheitlichen und das Problem der Kostenüberlagerung und Inkompatibilität der Lambda-Architektur in Echtzeit- und Offline-Verbindungen zu lösen. und wirklich erkennen: Die Architektur vereint Computing, Speicherung und Analyse. Gleichzeitig werden wir weiterhin die einheitlichen Vorteile von Doris nutzen und Multi-Catalog verwenden, um den freien Datenfluss zwischen Lakes und Warehouses zu ermöglichen, um nahtlose und extrem schnelle Analysedienste für Data Lakes und mehrere heterogene Storages zu erreichen und so umfassender zu werden Satz von Ein vollständigeres, offeneres und einheitlicheres Big-Data-Technologie-Ökosystem.
Wir sind dem SelectDB- Team für die kontinuierliche technische Unterstützung sehr dankbar . Zu diesem Zeitpunkt ist Cigna Data Warehouse nicht mehr auf einfache Berichtsszenarien beschränkt. Es unterstützt die Datenanalyse in einer Vielzahl verschiedener Szenarien durch eine Reihe von Architekturen, erfüllt das einheitliche Schreiben und Abfragen von Echtzeit- und Offline-Daten und stellt Dienste dafür bereit Produktmarketing, Kundenbetrieb, Unternehmen wie C-Seite und B-Seite bieten Datenwert und ermöglichen es dem Versicherungspersonal, Daten effizienter zu erhalten, Kundenbedürfnisse genauer vorherzusagen und Chancen für Unternehmen zu gewinnen.
Auch in Zukunft werden wir uns weiterhin am Aufbau der Apache Doris-Community beteiligen und die Erfahrungen und praktischen Anwendungen des Echtzeit-Data-Warehouse-Aufbaus der Versicherungsbranche einbringen. Wir hoffen, dass Apache Doris weiter wächst und sich weiterentwickelt und zum Aufbau von beiträgt Basissoftware!