Li Auto x JuiceFS: Evolution und Denken von Hadoop zu Cloud Native

Die technische Architektur des idealen Autos in der Hadoop-Ära

Lassen Sie zunächst kurz die Entwicklung der Big-Data-Technologie Revue passieren: Nach meinem persönlichen Verständnis lässt sich die Entwicklung von Big Data in vier Perioden einteilen:

Der erste Zeitraum: 2006 bis 2008. Hadoop wurde um 2008 zum Top-Projekt von Apache und veröffentlichte offiziell die Version 1.0, dessen Fundament hauptsächlich auf der Basis von Googles Troika, GFS, MapReduce und BigTable definiert wurde.

Die zweite Periode: von 2009 bis 2013. Unternehmen wie Yahoo, Alibaba und Facebook nutzen zunehmend Big Data. Ende 2013 hat Hadoop offiziell die Version 2.0 veröffentlicht. Ich hatte das Glück, 2012 mit Big Data in Berührung zu kommen und erlebte es mit Hadoop 1.0 plus Hive. Damals war ich unglaublich. Big Data kann schnell Probleme lösen, die mit SQL Server oder MySQL nicht mit wenigen Maschinen gelöst werden können .

Die dritte Phase: Von 2014 bis 2019, in dieser sehr schnellen Entwicklungsphase, in der sich Spark und Flink zu den Top-Apache-Projekten entwickelt haben. Während dieser schnellen Kletterphase haben wir auch versucht, Storm zu verwenden, das später durch Flink ersetzt wurde.

Die vierte Phase: Von 2020 bis heute, nachdem Hudi seinen Abschluss bei Apache gemacht und 2020 zu einem Top-Level-Projekt geworden war, verstehe ich persönlich, dass der Data Lake in die Reifephase der gesamten Entwicklung eingetreten ist und die Data Lake 2.0-Phase erreicht hat von Big Data. Der Data Lake hat drei Hauptmerkmale, erstens einen einheitlichen und offenen Speicher, zweitens ein offenes Format und umfangreiche Rechenmaschinen.

Im gesamten Entwicklungsprozess hat Big Data vor allem mehrere Eigenschaften, die die vier „Vs“ sind, die alle oft sagen: Volume, Velocity, Variety und Value. Nun gibt es ein fünftes „V“ (Wahrheit), die Genauigkeit und Vertrauenswürdigkeit der Daten. Die Datenqualität wurde immer kritisiert. Ich hoffe, dass es in der Branche eine Reihe von Standards geben wird, um die Qualität des Data Lake zu verbessern. Dies kann der Standard für die Entstehung von Data Lake 2.0 sein, da Projekte wie Hudi und Iceberg soll die Qualität des gesamten Data Lake verbessern, das Management des Data Lake ist gut gemacht.

Ich persönlich denke, dass Hadoop ein Synonym für Big Data ist, aber Big Data ist nicht nur Hadoop. Big Data ist eine Reihe von Lösungen zur Verarbeitung und Nutzung einer großen Datenmenge, die nach der Integration mehrerer Komponenten während des Entwicklungsprozesses entsteht . In den letzten Jahren glaubte im Grunde jeder, dass es mit Hadoop bergab geht: Erstens die Fusion und das Delisting der Hadoop-Kommerzialisierungsunternehmen Cloudera und Hortonworks, das ursprüngliche Geschäftsmodell kann nicht weitergeführt werden, Usability-Herausforderungen und die wachsende Komplexität des Hadoop-Ökosystems selbst.

Aktuelle Architektur der idealen Big-Data-Plattform für Automobile

In diesem Stadium ist die Big-Data-Plattform von Li Auto in der obigen Abbildung dargestellt. Ideal Car verwendet viele Open-Source-Komponenten.

• Transportschicht: Kafka und Pulsar. Kafka wurde in der Anfangsphase des Plattformaufbaus als Ganzes verwendet. Die Cloud-nativen Fähigkeiten von Kafka sind relativ schlecht. Pulsar wurde zu Beginn seines Designs gemäß der Cloud-nativen Architektur entworfen und verfügt über einige Fähigkeiten, die sehr gut für IoT geeignet sind Szenarien, und es passt auch zu unseren Geschäftsszenarien.Deshalb haben wir kürzlich Pulsar eingeführt.
• Die Speicherschicht ist HDFS + JuiceFS.
• Die aktuellen Hauptrechenmaschinen der Rechenschicht sind Spark und Flink, und diese Rechenmaschinen laufen auf dem aktuellen Yarn. Die drei Computer-Engines werden von Apache Linkis verwaltet, das Open Source von WeBank ist, und derzeit verwenden wir Linkis stark.
• Auf der rechten Seite befinden sich drei Datenbanken. Die erste, MatrixDB, ist eine kommerzielle Version der Zeitreihendatenbank. TiDB wird hauptsächlich für gemischte Szenarien aus OLTP und OLAP verwendet. Derzeit verwenden wir sie hauptsächlich für TP-Szenarien. StarRocks ist für das OLAP-Szenario verantwortlich.
• ShardingSphere will mit seinem Database Plus-Konzept die zugrunde liegenden Datenbanken für die Verwaltung auf Gateway-Ebene vereinheitlichen. Es befindet sich noch in der Sondierungsphase und es gibt viele neue Funktionen, an denen wir sehr interessiert sind.
• Weiter rechts stellt Thanos eine Cloud-native Monitoring-Lösung dar. Wir haben die Überwachung von Komponenten, Motoren und Maschinen in die Thanos-Lösung integriert.
• Die Anwendungsschicht sind unsere aktuellen vier wichtigsten Mittelprodukte, darunter Datenanwendung, Datenentwicklung, Datenintegration und Datenverwaltung.

Merkmale

Durch den Status Quo von Big-Data-Plattformen können Sie einige Merkmale finden:

• Erstens gibt es viele Komponenten in der gesamten Lösung, die Benutzer sind stark von diesen Komponenten abhängig, und die gegenseitige Abhängigkeit zwischen den Komponenten ist ebenfalls relativ stark. Es wird empfohlen, bei der zukünftigen Auswahl von Komponenten zu versuchen, ausgereiftere Cloud-native Komponenten auszuwählen .
• Zweitens haben unsere Daten klare Spitzen und Täler. Die Reiseszene ist im Allgemeinen in der Morgen- und Abendspitze, und samstags und sonntags werden mehr Menschen unterwegs sein.
• Das dritte Merkmal ist, dass die Popularität unserer Daten im Grunde am heißesten ist und wir in der Regel nur auf die Daten der letzten Tage oder der letzten Woche zugreifen. Es wird jedoch eine große Datenmenge generiert, und manchmal kann eine große Menge an Rückverfolgung erforderlich sein, sodass die Daten auch für eine lange Zeit gespeichert werden müssen, sodass die Nutzungsrate der Daten viel schlechter ist.

Schließlich fehlen dem gesamten Datensystem derzeit einige effektive Managementmethoden auf Dateiebene. Von der Konstruktion bis heute basiert es im Wesentlichen auf HDFS, und es gibt eine große Menge nutzloser Daten, die eine Verschwendung von Ressourcen verursachen.Das ist ein Problem, das wir dringend lösen müssen.

Pain Points von Big-Data-Plattformen

• Erstens gibt es viele Komponenten, die die Bereitstellung schwierig und ineffizient machen . Es gibt mehr als 30 Big-Data-Komponenten rund um Hadoop und mehr als 10 häufig verwendete. Zwischen einigen Komponenten bestehen starke und schwache Abhängigkeiten, und eine einheitliche Konfiguration und Verwaltung wird sehr kompliziert.
• Zweitens sind die Maschinen- und Wartungskosten relativ hoch . Für den stabilen Geschäftsbetrieb werden Offline- und Echtzeit-Cluster separat eingesetzt. Aufgrund der oben genannten Geschäftsmerkmale sind die Höhen und Tiefen unseres Geschäfts jedoch offensichtlich, und die Gesamtnutzungsrate ist nicht hoch. Eine große Anzahl von Cluster-Komponenten erfordert spezialisiertes Personal, um sie zu verwalten und zu warten.
• Drittens, plattformübergreifende Datenfreigabefunktionen . Derzeit können Cluster-übergreifende Daten nur über DistCp mit anderen Hadoop-Clustern synchronisiert werden. Es kann nicht einfach und schnell mit anderen Plattformen und Servern synchronisiert werden.
• Viertens Datensicherheit und Einhaltung der Datenschutzbestimmungen . Basierend auf unterschiedlichen Datensicherheitsanforderungen werden normale Benutzer über Ranger verwaltet, und spezielle Sicherheitsanforderungen können nur erfüllt werden, indem verschiedene Cluster erstellt und separate VPC-Richtlinien festgelegt werden, was zu vielen Dateninseln und Wartungskosten führt.

Die Entwicklung und das Denken des idealen Cloud-Natives für Autos

Lassen Sie mich zunächst kurz mein persönliches Verständnis von Cloud Native schildern:

Erstens leitet sich Cloud Native vom Cloud Computing ab. Heute nutzt jeder Cloud-Anbieter wie Alibaba Cloud, AWS, Tencent Cloud, Baidu Cloud usw., die zunächst technische Dienste auf der IaaS-Ebene bereitstellen, um Unternehmen dabei zu helfen, die grundlegendsten Dinge wie Speicher, Computing und Netzwerke für eine einheitliche Verwaltung zu packen müssen nur einen Server darauf beantragen. Nach der Beantragung von Servern werden diese Server weiterhin von Cloud-Anbietern verwaltet, was unser traditioneller Cloud-Betrieb ist.

Cloud Native ist untrennbar mit Cloud Computing verbunden und gehört im Allgemeinen zum PaaS-Layer-Service des Cloud Computing, bei dem es sich hauptsächlich um eine Anwendungsart für Entwickler handelt. Cloud Native muss in der Cloud installiert werden und ist eine cloudbasierte Softwareentwicklungs- und Anwendungsmethode. Cloud + nativ, Cloud ist Cloud Computing, nativ ist es, das traditionelle Framework für die Betriebs- und Wartungsentwicklung durch Containerisierung, DevOps und Microservice-Architektur aufzugeben, um eine elastische Skalierung und automatische Bereitstellung von Anwendungen zu erreichen und die Cloud-Computing-Ressourcen voll auszunutzen, um dies zu erreichen auf kleinstem Raum das Größte tun. Es kann auch einige Schwachstellen unseres aktuellen Big-Data-Systems lösen, wie z. B. schlechte Skalierbarkeit und Wartbarkeit, die viel Personal und Zeit erfordern.

Die obige Abbildung listet kurz mehrere Cloud-native Zeitpunkte auf

• In der ersten Phase schlug AWS das Konzept von Cloud Native vor und startete EC2 im Jahr 2006. Diese Phase ist die Server-Phase, die oben erwähnte Cloud-Computing-Phase.
• Die zweite Phase, die Cloudisierungsphase, findet hauptsächlich nach der Veröffentlichung von Open Source Docker und Googles Open Source Kubernetes statt. Kubernetes ist eine leichtgewichtige und erweiterbare Open-Source-Plattform zur Verwaltung containerisierter Anwendungen und Dienste. Die automatische Bereitstellung und Skalierung von Anwendungen kann über Kubernetes erfolgen.
• In der dritten Phase wurde 2015 die CNCF Foundation gegründet, um Cloud-native Konzepte zu fördern und die Cloud-native Entwicklung insgesamt zu unterstützen. Letztere stellt die Open Source von Knative dar. Ein sehr wichtiges Ziel von Knative ist die Entwicklung von Cloud-nativen, plattformübergreifenden, serverlosen Orchestrierungsstandards. Abgeleitet in die Gegenwart ist es bereits das Stadium von Cloud Native 2.0, also das Stadium von Serverless. Ich persönlich verstehe, dass sich die Entwicklung von Big Data auch in Richtung Serverless entwickeln sollte . Beispielsweise ist der gesamte Online-Service von AWS im Grunde Serverless.

Big Data Cloud-native Architektur

Lassen Sie mich als Nächstes die Änderungen in den Komponenten der idealen Big-Data-Plattform für Autos nach der Cloud-Nativeisierung vorstellen:

• Auf der Speicherebene ist der gesamte Speicher nach der Cloud-Nativisierung im Grunde Objektspeicher. Das obige Architekturdiagramm führt zu Lustre, das unten im Detail beschrieben wird. Sie können verstehen, dass die „Cloud-Speicher“-Ebene hauptsächlich JuiceFS verwendet, um Objektspeicher und das parallel verteilte Lustre-Dateisystem zu verwalten (Hinweis: Aufgrund des Single-Copy-Problems von Lustre erwägen wir derzeit die Verwendung von parallelen Dateisystemen, die von Cloud-Dienstanbietern bereitgestellt werden).
• Die Container-Schicht, hauptsächlich über Computing, Speicher und Netzwerk, wird vollständig durch Kubernetes plus Docker ersetzt, und alle Komponenten werden darauf angebaut.
• Bei den Komponenten stellt der erste das Big-Data-Computing-Framework dar. Wir können Hive aufgeben, Spark und Flink direkt verwenden, Hudi als zugrunde liegende Funktionsunterstützung von Data Lake 2.0 verwenden und HDFS schrittweise ersetzen.
• Im Middleware-Teil gibt es neben Pulsar noch Kafka, Kafkas Cloud-Nativisierung ist derzeit nicht besonders gut, ich persönlich ersetze Kafka lieber durch Pulsar. Derzeit wurde Linkis online verwendet, um alle Spark-Engines anzupassen, und Flink wird später angepasst und integriert. ShardingSphere hat gerade Cloud Native in Version 5.1.2 unterstützt, und wir werden die Szenarioverifizierung und die Exploration der Fähigkeiten wie geplant durchführen.
• Die Datenbankebene stellt weiterhin TiDB, StarRocks und MatrixDB dar. Derzeit verfügen diese drei Datenbanken bereits über Cloud-native Fähigkeiten und unterstützen alle Objektspeicherung. Aber dieses Stück wurde nicht separat getestet, und wir verwenden immer noch physische Maschinen. Denn für die Datenbank können die vom aktuellen Objektspeicher bereitgestellten E/A-Fähigkeiten die Leistungsanforderungen der Datenbank nicht erfüllen, was die Gesamtleistung der Datenbank stark reduzieren wird.
• In Bezug auf Betrieb und Wartung wird der Thanos-Lösung ein zusätzliches Loki hinzugefügt, hauptsächlich für die Cloud-native Protokollsammlung. Aber Loki und Thanos sind nur zwei von ihnen.Ich verstehe, dass sie sich in Zukunft an Alis Open-Source-SREWorks-Fähigkeiten ausrichten und die gesamte Qualität, Kosteneffizienz und Sicherheit in den umfassenden Betriebs- und Wartungsfunktionen versiegeln werden, damit das Ganze Cloud-natives Management kann eigenständig verwaltet werden.
• Beobachtbarkeit, ein in letzter Zeit populäres Konzept im Bereich Cloud Native. Einige der Komponenten, die jeder herstellt, beginnen sich Cloud-nativ zu entwickeln, nachdem sie populär geworden sind Sie werden am Anfang nicht in der Cloud geboren, aber sie hoffen einfach, später in der Cloud zu wachsen. In diesem Fall wird es auf einige Probleme stoßen: Das erste Problem ist, dass es keine umfassende Sichtbarkeitsüberwachung gibt. Wir überlegen, wie wir in Zukunft einen Plan für diese Komponenten als Ganzes entwickeln können, damit alle Komponenten effektiv überwacht werden können, nachdem sie Cloud-nativ sind.

Zusammenfassend denke ich persönlich, dass die Big Data native Cloud der Zukunft im Wesentlichen ist:

1. Einheitliche Verwendung von Cloud-nativem Speicher als zugrunde liegendem Speicher für alle Komponenten (einschließlich Datenbanken)
2. Alle Komponenten laufen in Containern
3. Verwenden Sie eine serverlose Architektur, um Anwendungen der oberen Schicht zu bedienen

Dies bringt jedoch auch Herausforderungen für die aktuellen Datenplattformprodukte mit sich, d. h. wie Produkte mit serverlosen Funktionen für Benutzer entwickelt werden können.

Vorteile von Big Data Cloud Native

Der erste Punkt ist die Trennung von Speicherung und Berechnung und elastischer Ausdehnung und Kontraktion . Wenn Sie nach der Verwendung physischer Maschinen zur Bereitstellung von Hadoop die Kapazität erweitern oder verringern müssen, müssen Sie sich an den Betreiber wenden, und es kann zu einem langen Zyklus kommen.Die Trennung von Speicherung und Berechnung löst dieses Problem gut. Die zweite ist Pay-as-you-go, ohne ungenutzte Ressourcen zu kaufen. Derzeit haben die Daten unseres gesamten Geschäftsszenarios Höhen und Tiefen. In Spitzenzeiten müssen Maschinen vorbereitet werden, und Maschinen müssen in Tälern zurückgezogen werden, aber das ist jetzt nicht möglich. Jetzt stapeln wir im Grunde alle Maschinen bis zum Peak. Während des Peaks kann es den Bedarf decken und ist ohne Ausfall stabil. Aber während des Tals ist es mindestens 12 Stunden im Leerlauf. In diesem Fall werden auch Ressourcen aufgeladen. Nach Cloud Native müssen wir nicht mehr dafür bezahlen.

Der zweite Punkt ist die automatisierte Bereitstellung und Bedienbarkeit . Kubernetes unterstützt integrierte DevOps-Bereitstellungslösungen. Auf diese Weise können unsere Komponenten als Ganzes schnell bereitgestellt werden (z. B. über ein Helm-Diagramm), und die Betriebs- und Wartungsfunktionen der Komponenten werden auf die Cloud-native Plattform herabgesetzt, sodass Big Data den Betrieb und die Wartung der Komponenten nicht berücksichtigen muss Szenarien.

Der dritte Punkt ist die Objektspeicherung . Objektspeicherung ist das Kernstück und wichtigste Produkt, das durch Cloud Computing eingeführt wurde. Die Vorteile des Objektspeichers liegen auf der Hand, einfache Erweiterbarkeit, unbegrenzter Speicherplatz, relativ niedriger Stückpreis, und der Objektspeicher ist auch in Niederfrequenzspeicher, Archivspeicher und andere Speichertypen unterteilt, wodurch die Speicherkosten weiter gesenkt werden können länger gelagert. Gleichzeitig sind kontrollierbare Kosten, hohe Zuverlässigkeit und geringe Betriebskomplexität auch Vorteile der Objektspeicherung.

Der vierte Punkt ist Sicherheit und Compliance . Nach der Cloud können native, dedizierte Namespaces, Multi-Tenant-Isolierung und Remote-Authentifizierung realisiert werden. Was wir derzeit erreicht haben, ist im Wesentlichen eine Isolierung auf Netzwerkebene.Die weithin anerkannte Lösung für die HDFS-Dateiverwaltung ist Ranger. Die Verwendung von Ranger zur Verwaltung von HDFS-Verzeichnisberechtigungen kann auch einige Berechtigungen wie Hive-Server, HBase und Kafka verwalten, aber diese Berechtigungen sind relativ schwach.

Eine andere Lösung stellt Kerberos dar. Die Sicherheit der gesamten Big-Data-Komponente wird erheblich verbessert, ist jedoch mit hohen Kosten verbunden, und jede Anfrage muss verifiziert werden. Wir haben diese Lösung bisher nicht genutzt und es hat etwas mit unserer Cluster-Umgebung und unseren Szenarien zu tun: Wir sind im Wesentlichen im Intranet und bieten keine externen Dienste an. Wenn Ihr Big-Data-Projekt einige Dienste für das externe Netzwerk bereitstellen muss, benötigen Sie dennoch eine starke Authentifizierung, da die Daten sonst leicht durchsickern können.

Schwierigkeiten von Cloud Native Big Data

Die Schwierigkeit von Big Data Cloud Native besteht ebenfalls.

Erstens gibt es viele Komponenten, die mit Big Data zu tun haben, gleichzeitig ist die Aktualisierung von Kubernetes relativ schnell, und nachdem die Komponenten gekreuzt sind, gibt es Probleme bei Kompatibilität, Komplexität und Skalierbarkeit.

Zweitens die Zuweisung und Umverteilung von Ressourcen. Kubernetes ist ein universelles Container-Ressourcenplanungstool, und es ist schwierig, die Ressourcennutzungsszenarien verschiedener Big-Data-Komponenten zu erfüllen. In einem Big-Data-Szenario ist die Ressourcennutzung relativ hoch, die Anforderungshäufigkeit hoch und die Anzahl der Pods jedes Mal relativ groß – für diesen Fall gibt es derzeit keine gute Lösung. Derzeit schauen wir uns die Lösung von Fluid an. Fluid implementiert auch die Laufzeit von JuiceFS. Darauf werden wir später eingehen. Fluid behauptet derzeit, dass es Big Data und KI unterstützen kann, nicht nur KI-Szenarien, weil Big Data und KI die Szenarien sind ähnlich und stellen alle datenintensive Vorgänge dar. Fluid hat einige Durchbrüche in der Recheneffizienz und im Datenabstraktionsmanagement erzielt.

Drittens hat die Objektspeicherung auch einige Nachteile. Die Nachteile der Objektspeicherung sind eine geringe Metadaten-Operationsleistung, schlechte Kompatibilität mit Big-Data-Komponenten und eventuelle Konsistenz.

Der letzte Punkt sind datenintensive Anwendungen. Der Speicher-Computing-Trennmodus kann die Anforderungen von datenintensiven Anwendungen wie Big Data und KI in Bezug auf die Rechenbetriebseffizienz und das Datenabstraktionsmanagement nicht erfüllen.

Die Erforschung und Implementierung von JuiceFS in Cloud-nativen Big-Data-Lösungen

Vor der Open-Source-Version von JuiceFS haben wir darauf geachtet und einige Landetests durchgeführt.Nach dem Start der Open-Source-Version werden wir sie sofort verwenden. Als es online ging, stieß ich auch auf einige Berechtigungsprobleme und ein paar kleine Fehler. Die Community war sehr unterstützend und half uns, sie schnell zu lösen.

HDFS geht wegen seiner schlechten Skalierbarkeit offline, gleichzeitig ist unser Datenvolumen relativ groß und die Speicherkosten von HDFS relativ hoch. Nach dem Speichern mehrerer Datenstapel reicht der Speicherplatz auf dem physischen Computer nicht aus, und es sind viele Berechnungen erforderlich. Damals steckte unsere Geschäftsentwicklung noch in den Kinderschuhen, und um möglichst viel Wert aus den Daten zu ziehen, wollten wir so viele Daten wie möglich behalten. Außerdem erfordert HDFS drei Kopien, wir haben es später auf zwei Kopien geändert, aber zwei Kopien sind immer noch riskant.

Auf dieser Grundlage haben wir JuiceFS ausführlich getestet und nach Abschluss des Tests schnell JuiceFS in unserer Online-Umgebung eingeführt. Die Migration einiger relativ großer Tabellen von HDFS zu JuiceFS entlastete unsere dringende Notwendigkeit.

Wir schätzen drei Punkte von JuiceFS:

• Erstens ist JuiceFS mit mehreren Protokollen kompatibel . Es ist vollständig kompatibel mit POSIX-, HDFS- und S3-Protokollen und ist im aktuellen Gebrauch ohne Probleme 100% kompatibel.

• Zweitens die Fähigkeit, Wolken zu überqueren . Um systemische Risiken zu vermeiden, wird ein Unternehmen ab einer bestimmten Größe nicht nur einen Cloud-Dienstleister verwenden. Es wird nicht an eine Cloud gebunden sein, es wird alles Multi-Cloud-Operationen sein. In diesem Fall spielt die Fähigkeit von JuiceFS, Daten über Clouds hinweg zu synchronisieren, eine Rolle.

• Drittens Cloud-native Szenarien . JuiceFS unterstützt CSI. Derzeit haben wir CSI in diesem Szenario nicht verwendet. Wir verwenden grundsätzlich POSIX zum Mounten, aber die Verwendung von CSI wird einfacher und kompatibler. Wir entwickeln uns jetzt auch in Richtung Cloud Native, aber die gesamte Komponente hat nicht wirklich noch zu Kubernetes gekommen.

Anwendung von JuiceFS im idealen Auto

Behalten Sie Daten von HDFS im Objektspeicher bei

Nachdem JuiceFS Open Source war, begannen wir zu versuchen, die Daten auf HDFS mit JuiceFS zu synchronisieren. Zu Beginn der Synchronisierung wurde DistCp verwendet, das sehr komfortabel mit dem Hadoop-SDK von JuiceFS synchronisiert werden kann und die Migration insgesamt relativ reibungslos verläuft. Der Grund für die Migration von Daten von HDFS zu JuiceFS liegt in einigen Problemen.

Das erste ist, dass das Speicher-Computing-Kopplungsdesign von HDFS eine schlechte Skalierbarkeit aufweist und es keine Möglichkeit gibt, dieses Problem zu lösen. Mein persönliches Verständnis von Big Data von Anfang an ist, dass Big Data auf physischen Maschinen bereitgestellt werden muss, nicht auf Cloud-Hosts. Einschließlich der verschiedenen EMR-Systeme, die später von Cloud-Anbietern eingeführt wurden, kapseln sie tatsächlich Hadoop.In den letzten ein oder zwei Jahren wurden diese EMR-Systeme schrittweise von Hadoop befreit.

Zweitens lässt sich HDFS nur schwer an die Cloud-Nativisierung anpassen. Das aktuelle HDFS ist schwierig an Cloud-Native anzupassen, da es relativ schwer ist.Obwohl sich die Community auf Cloud-Native konzentriert hat, denke ich persönlich, dass der Entwicklungstrend von Hadoop bergab geht und die Zukunft auf Objektspeicherung basieren sollte.

Drittens hat Object Storage auch einige Nachteile: Es lässt sich nicht gut an die HDFS-API anpassen, aus Netzwerk- und anderen Gründen unterscheidet sich auch die Performance stark von der lokaler Platten, außerdem sind Metadaten-Operationen wie das Auflisten von Verzeichnissen sehr stark langsam. Wir verwenden JuiceFS, um etwas zu beschleunigen, und die gemessene Leistung ist sehr beeindruckend. Sie ist im Grunde vergleichbar mit der lokalen Festplatte im Fall von Cache. Basierend darauf schalten wir die aktuelle Szene schnell direkt auf JuiceFS um.

Dateifreigabe auf Plattformebene

Das zweite Szenario ist die Dateifreigabe auf Plattformebene. Alle gemeinsam genutzten Dateidaten unseres aktuellen Planungssystems, Echtzeitsystems und der Entwicklungsplattform werden auf HDFS gespeichert. Wenn wir HDFS später nicht mehr verwenden, müssen wir diese Daten migrieren. Die aktuelle Lösung stellt die Verbindung zum Objektspeicher über JuiceFS dar. Durch den Dienst der Anwendungsschicht werden alle im POSIX-Modus gemountet, und jeder kann die Dateien in JuiceFS bedenkenlos anfordern.

JuiceFS erfüllt die meisten unserer Anwendungsanforderungen in diesem Szenario, aber es gibt immer noch einige kleine Szenarien, die Probleme haben. Die ursprüngliche Idee war, die gesamte Python-Umgebung und ähnliches hineinzupacken, aber später fand ich, dass die eigentliche Bedienung zu schwierig ist, weil viele kleine Dateien in der Python-Umgebung sind und es immer noch Probleme beim Laden gibt. Szenarien wie die Python-Umgebung, die eine große Anzahl fragmentierter Dateien enthalten, müssen für den Betrieb dennoch auf der lokalen Festplatte gespeichert werden. In Zukunft werden wir eigens dafür ein Stück Blocklager aufhängen.

Teilen Sie uns einige Probleme mit, auf die wir zuvor mit HDFS gestoßen sind:

Erstens, wenn der NameNode unter starkem Druck oder Full GC steht, kommt es zu Download-Fehlern, und es gibt derzeit keine perfekte Lösung. Unsere Lösung besteht darin, den Speicher so weit wie möglich zu erhöhen oder beim Herunterladen des Pakets einige Wiederholungen hinzuzufügen, um die Spitzenzeit zu vermeiden, aber es ist in diesem Fall schwierig, das Problem von HDFS vollständig zu lösen, da es schließlich in Java geschrieben ist. und der GC Es gibt keine Möglichkeit, die Szene zu vermeiden.

Zweitens ist es bei der systemübergreifenden Verwendung von HDFS, wenn wir beispielsweise zwei Cluster haben, grundsätzlich unrealistisch, einen Cluster zum Teilen von Dateien zu verwenden, da das Netzwerk geöffnet werden muss, um die beiden Cluster zu verbinden oder durch die Anwendung zu gelangen, so gibt es keine Möglichkeit, Sicherheit zu garantieren. Derzeit haben wir im Wesentlichen zwei Cluster, die ihre eigenen gemeinsam genutzten Dateien unabhängig voneinander verwalten. Jetzt wurde die Echtzeitplattform (z. B. die Flink-Plattform) auf JuiceFS umgestellt und läuft immer noch sehr reibungslos und ohne Probleme.

Drittens haben wir derzeit eine große Anzahl von Bereitstellungen physischer Maschinen, die alle Single-Cluster sind, ohne eine Disaster-Recovery-Strategie.Wenn ein katastrophales Problem im Computerraum auftritt, ist unser gesamter Service nicht verfügbar. Aber der Objektspeicher selbst ist computerraumübergreifend, in der gleichen Region sollten es mindestens drei Kopien sein, Cloud-Anbieter helfen uns bei der Sicherung. In Zukunft werden wir möglicherweise mehrere Clouds entwickeln, in der Hoffnung, JuiceFS verwenden zu können, um einige High-Level-Dateien, Kerndatenbanken, einschließlich einiger Kern-Sicherungsdateien, gemeinsam zu nutzen und Sicherungen in mehreren Clouds zu erstellen. Auf diese Weise werden Multi-Cloud, Multi-Region und Multi-Region realisiert, wodurch das Problem der Single-Point-Disaster-Recovery gelöst werden kann.

Plattformübergreifende Nutzung massiver Daten

In einem anderen Szenario teilen alle Plattformen riesige Datenmengen über JuiceFS. Die erste Art von gemeinsam genutzten Daten auf unserer Seite sind Straßentestdaten. Für Straßentests wird eine große Menge an Video-, Audio- und Bilddaten hochgeladen. Nach dem Hochladen werden diese Daten direkt in JuiceFS eingegeben, was für Downstream-Teilnehmer praktisch ist Synchronisierung und gemeinsame Nutzung Einschließlich einiger Datenprüfung, und dann erhalten Sie PFS ist ein paralleles Dateisystem, unter dem SSD gemountet wird. Dadurch kann die GPU-Auslastung höher werden, da die Objektspeicherkapazität relativ schwach ist, da ansonsten viel GPU-Kapazität verschwendet wird.

Die verbleibenden Datentypen umfassen einige Protokolle, die von Fahrzeugen zur Analyse gemeldet werden, Daten zu vergrabenen Punkten und fahrzeugbezogene Signaldaten, die von einigen nationalen Plattformen benötigt werden. Diese Daten werden für einige Analysen in das Data Warehouse eingegeben. Wir werden auch einige Merkmalsdatenextraktionen für diese Daten durchführen, Modelltraining für das Algorithmusteam durchführen oder einige NLP-Abrufe und andere weitere Szenarien durchführen.

Cloud Native Storage Acceleration – Lustre als Lese-Cache (im Test)

Jetzt testen wir ein weiteres Szenario, das darin besteht, einen Lustre an die Objektspeicherschicht zu hängen, um als Lese-Cache für JuiceFS zu dienen, und den Cache von Luster zu verwenden, um JuiceFS dabei zu helfen, die Lesegeschwindigkeit und die Cache-Trefferrate zu verbessern.

Ein Vorteil davon ist, dass wir jetzt physische Maschinen verwenden, die über physische Festplatten verfügen, die zum Zwischenspeichern von Daten verwendet werden können. Da Rechenaufgaben jedoch auf mehreren Knoten ausgeführt werden, ist die Cache-Trefferrate nicht sehr hoch. Dies liegt daran, dass die Community-Version von JuiceFS noch kein verteiltes P2P-Caching unterstützt und nur lokales Caching mit einem einzelnen Knoten unterstützt und jeder Knoten viele Daten lesen kann. In diesem Fall wird auch ein gewisser Plattendruck auf dem Rechenknoten verursacht, da der Cache eine gewisse Menge an Plattenplatz belegt.

Unsere aktuelle Lösung besteht darin, Lustre als Lese-Cache von JuiceFS zu verwenden. Hängen Sie je nach Größe der zwischenzuspeichernden Daten ein Lustre-Dateisystem mit einer Kapazität von etwa 20 bis 30 TB an den lokalen Rechenknoten an und verwenden Sie dann diesen Lustre-Mount-Punkt als Cache-Verzeichnis von JuiceFS. In diesem Fall kann JuiceFS die Daten nach dem Lesen asynchron in Lustre zwischenspeichern. Diese Lösung kann das Problem der niedrigen Cache-Trefferrate effektiv lösen und die Leseleistung erheblich verbessern.

Wenn wir im Spark-Szenario Daten direkt in den Objektspeicher schreiben, kommt es zu Bandbreiten- und QPS-Einschränkungen. Wenn das Schreiben zu langsam ist, können die Upstream-Tasks jittern. In diesem Fall kann die Schreib-Cache-Funktion von JuiceFS zum Schreiben von Daten verwendet werden zuerst in Lustre zu schreiben und dann asynchron in den Objektspeicher zu schreiben, ist diese Lösung in einigen Szenarien anwendbar. Aber es gibt ein Problem, dass Lustre keine Cloud-native Lösung ist, es wird vom Benutzer wahrgenommen und der Benutzer muss explizit einen Befehl schreiben, um es beim Starten des Pods zu mounten. Daher hoffen wir auch, in Zukunft einige Änderungen an JuiceFS vorzunehmen, Objektspeicher und Lustre automatisch zu identifizieren und dann automatisch einige Caching-Mechanismen zu implementieren, damit Benutzer die Existenz von Lustre nicht wahrnehmen müssen.

Derzeit ist der PoC dieser Lösung abgeschlossen und hat den Basistest bestanden. Als nächstes werden wir viele Drucktests in der Produktionsumgebung durchführen. Es wird erwartet, dass sie im dritten Quartal dieses Jahres offiziell eingeführt wird, um einige Edge-Dienste abzudecken .

Die Gesamtlösung von JuiceFS in Big Data Cloud nativ

Wie aus dem Architekturdiagramm der Gesamtlösung ersichtlich, nutzen wir derzeit alle drei Methoden, die der JuiceFS-Client bereitstellt.

Wie in der linken Hälfte der obigen Abbildung gezeigt, haben wir unabhängige Spark- und Flink-Cluster, und wir werden JuiceFS über den CSI-Treiber direkt in den gesamten Cluster einhängen, sodass Benutzer beim Starten von Spark und Flink nichts davon bemerken JuiceFS überhaupt Es existiert, und das Lesen und Schreiben von Rechenaufgaben wird alles über den Objektspeicher erledigt.

In diesem Abschnitt gibt es derzeit eine Frage zu Shuffle. Da für die Spark-Aufgabe während der Shuffle-Phase des Berechnungsprozesses eine große Datenmenge auf den Datenträger geschrieben werden muss, stellt eine große Anzahl von Lese- und Schreibanforderungen für Dateien, die in diesem Zeitraum generiert werden, höhere Leistungsanforderungen an den zugrunde liegenden Speicher. Flink ist relativ besser, weil es streamt und keine große Anzahl von Festplatten benötigt. Wir hoffen, dass JuiceFS in Zukunft direkt in Lustre schreiben kann, aber dies erfordert einige Änderungen in JuiceFS. Durch die Client-Integration kann JuiceFS Lustre direkt lesen und schreiben. Dies wird von Benutzern nicht wahrgenommen und kann auch das Shuffle-Stage-Read verbessern und Schreibleistung.

Die Anwendung in der rechten Hälfte der obigen Abbildung hat zwei Szenarien. Eine davon besteht darin, JuiceFS-Daten einfach abzufragen, beispielsweise eine Datenvorschau über HiveJDBC.In diesem Szenario kann auf JuiceFS über das S3-Gateway zugegriffen werden.

Das zweite ist das Szenario, in dem die Big-Data-Plattform und die KI-Plattform verknüpft sind. Beispielsweise müssen Kollegen auf der KI-Plattform in ihrer täglichen Arbeit häufig Beispieldaten, Feature-Daten usw. lesen, und diese Daten werden normalerweise von Spark- oder Flink-Aufgaben auf der Big-Data-Plattform generiert und in JuiceFS gespeichert . Um Daten zwischen verschiedenen Plattformen auszutauschen, wird JuiceFS beim Start des Pods der KI-Plattform direkt über FUSE in den Pod gemountet, sodass Kollegen auf der KI-Plattform über Jupyter direkt auf die Daten in JuiceFS zugreifen können Anstatt wie bei der traditionellen Architektur Daten wiederholt zwischen verschiedenen Plattformen zu kopieren, verbessert das Training einiger Modelle die Effizienz der teamübergreifenden Zusammenarbeit.

Da JuiceFS POSIX-Standardbenutzer und Benutzergruppen für die Berechtigungskontrolle verwendet und der Container standardmäßig als Root-Benutzer startet, was die Kontrolle von Berechtigungen erschwert. Daher haben wir eine Änderung an JuiceFS vorgenommen, um das Dateisystem über ein Authentifizierungstoken zu mounten, das die Verbindungsinformationen der Metadaten-Engine und andere Informationen zur Berechtigungssteuerung enthält. In einigen Szenarien, in denen auf mehrere JuiceFS-Dateisysteme gleichzeitig zugegriffen werden muss, verwenden wir das JuiceFS S3-Gateway in Kombination mit IAM-Richtlinien für eine einheitliche Berechtigungsverwaltung.

Derzeit treten einige Schwierigkeiten bei der Verwendung von JuiceFS auf

Der erste Punkt ist, dass die Berechtigungsverwaltung basierend auf Benutzern und Benutzergruppen relativ einfach ist: In einigen Szenarien startet der Container standardmäßig als Root-Benutzer und die Berechtigungen sind nicht einfach zu steuern.

Der zweite Punkt betrifft die Konfigurationsoptimierung von JuiceFS Hadoop SDK. Derzeit haben wir hauptsächlich drei Konfigurationen zur Optimierung des JuiceFS Hadoop SDK: juicefs.prefetch, juicefs.max-uploadsund juicefs.memory-size. Beim Optimieren juicefs.memory-sizeder Konfiguration sind einige Probleme aufgetreten. Der Standardwert dieser Konfiguration ist 300 MB. Der offizielle Vorschlag lautet, einen Off-Heap-Speicher festzulegen, der viermal so groß ist wie der Standardwert, der 1,2 GB beträgt. Derzeit sind die meisten unserer Aufgaben auf 2 GB Off-Heap-Speicher konfiguriert, aber einige Aufgaben können gelegentlich nicht schreiben, selbst wenn mehr als 2 GB Speicher konfiguriert sind (HDFS kann stabil schreiben). Dies ist jedoch nicht unbedingt ein Problem mit JuiceFS, es kann auch durch Spark oder Objektspeicher verursacht werden. Daher planen wir derzeit auch, Spark und JuiceFS tiefgreifend anzupassen und dann Schritt für Schritt die Gründe herauszufinden, um all diese Fallstricke zu überwinden und den Speicher zu reduzieren, während die Task-Stabilität gewährleistet ist.

Der dritte Punkt ist, dass es mit zunehmender Komplexität der Gesamtarchitektur (JuiceFS + Objektspeicher + Lustre) mehr mögliche Fehlerpunkte gibt und die Stabilität von Aufgaben abnehmen kann, was andere fehlertolerante Mechanismen zur Gewährleistung erfordert. Beispielsweise kann während der Shuffle-Write-Phase der Spark-Aufgabe ein Fehler ähnlich wie „verlorene Aufgabe“ gemeldet werden, und die spezifische Ursache des Fehlers wurde noch nicht lokalisiert.

Die oben erwähnte Architekturkombination aus JuiceFS + Objektspeicher + Lustre verbessert die Lese- und Schreibleistung in gewissem Maße, macht die Architektur aber auch komplexer und erhöht entsprechend einige mögliche Fehlerpunkte. Lustre hat beispielsweise keine starke Disaster-Recovery-Kopierfähigkeit.Wenn Lustre einen Knoten plötzlich auflegt, können die laufenden Tasks weiterhin stabil Daten in Lustre lesen und schreiben, oder gehen die Daten in Lustre versehentlich verloren?Kann es noch stabil sein? • Es ist derzeit ungewiss, ob wir zu JuiceFS gehen und es erneut durch den Objektspeicher ziehen sollen, und wir führen derzeit diese Art von Katastrophentest durch.

Zukunft und Ausblick

Echtzeit-Data-Lake-Lösung basierend auf Flink + Hudi + JuiceFS

Eines der Dinge, die wir in naher Zukunft tun werden, ist die Echtzeit-Data-Lake-Lösung von Flink + Hudi + JuiceFS. Die linke Seite der obigen Abbildung stellt die Datenquelle dar. Über Flink, Kafka/Pulsar werden die Daten in Echtzeit in Hudi geschrieben, gleichzeitig werden die Daten von Hudi in JuiceFS fallen, um unsere aktuellen Echtzeitdaten zu ersetzen Lagerhaus.

Langfristige Planung von Big Data Cloud Native

Abschließend möchte ich den langfristigen Plan von Ideal Car Big Data Cloud Native vorstellen, der auch ein Ausblick ist.

Der erste Punkt ist ein einheitliches Datenmanagement- und Governance-System. Wir glauben, dass in der Data Lake 2.0-Ära das größte Problem, das gelöst werden muss, darin besteht, das Data Swamp-Problem im Data Lake 1.0-Szenario zu lösen. Aber jetzt scheint es kein besseres Open-Source-Produkt für einheitliches Metadatenmanagement, Datenverzeichnismanagement und Datensicherheitskontrolle zu geben, ähnlich wie AWS Glue und AWS Lake Formation. Wir arbeiten derzeit an einem „Origin System"-Projekt. Der erste Schritt dieses Systems besteht darin, alle Metadaten in der oben genannten Datenbank und Objektspeicherung in einer einheitlichen Verzeichnisverwaltung, einheitlichen Sicherheitskontrolle und einheitlichen Datenverwaltung zu verwalten. Wir tüfteln an unserem Weg nach vorn.

Der zweite Punkt sind schnellere, stabilere und kostengünstigere zugrunde liegende Speicherfunktionen. Die größte Schwierigkeit stellt derzeit in allen Szenarien die Objektspeicherung dar. Die Vorteile der Objektspeicherung sind Stabilität und niedrige Kosten, gleichzeitig iteriert die Objektspeicherung ständig. Im Moment denke ich, dass, wenn Big Data Cloud Native entwickelt werden soll, Objektspeicher eine bessere Leistung unter der Prämisse der Gewährleistung von Stabilität bieten muss.

Gleichzeitig kann S3 behaupten, eine starke Konsistenz zu unterstützen, aber derzeit verstehe ich, dass es schwierig sein kann, mit dem auf Objektspeicherung basierenden Architekturdesign eine starke Konsistenz zu erreichen, oder um eine starke Konsistenz zu erreichen, muss es zwangsläufig einige Dinge opfern. Dies kann eine Frage des Gleichgewichts sein. JuiceFS unterstützt nativ starke Konsistenz, was für Big-Data-Plattformen sehr freundlich ist.

Der dritte Punkt ist eine intelligentere, effizientere und benutzerfreundlichere Abfrage-Engine. Um das Denken über die oben erwähnte Integration von Seen und Lagerhäusern zu erweitern, befindet sich die Integration von Seen und Lagerhäusern noch in den frühen Stadien der Entwicklung, und es kann 5 bis 10 Jahre der Entwicklung dauern. Databricks und Microsoft versuchen, eine vektorisierte MPP-Engine auf dem Data Lake aufzubauen, in der Hoffnung, die integrierte Architektur von Lake und Warehouse zu fördern. Dies mag eine zukünftige Entwicklungsrichtung sein, aber es scheint, dass es keine Möglichkeit gibt, eine Engine zu verwenden, um die Anforderungen aller Szenarien in kurzer Zeit zu erfüllen.

Unsere aktuelle Architektur ist grundsätzlich mit allen Query Engines wie Spark, Flink, relationale Datenbank (für OLTP-Szenarien), Zeitreihendatenbank und OLAP-Datenbank ausgestattet. Grundsätzlich ist es besser, den Besseren zu verwenden, und unsere obere Schicht wird dies über eine einheitliche Middleware verwalten. Ein weiteres Beispiel stellt Snowflake dar. Obwohl es bereits die gleichzeitige Abfrage von strukturierten und halbstrukturierten Daten unterstützt, ist noch unklar, wie in Zukunft unstrukturierte Daten (wie Bilder, Sprache und Videos) im Zusammenhang mit künstlicher Intelligenz unterstützt werden sollen. klar. Ich denke jedoch, dass dies definitiv eine zukünftige Entwicklungsrichtung ist. Li Auto hat auch ein ähnliches Szenario für künstliche Intelligenz, also werden wir es gemeinsam mit verschiedenen Geschäftspartnern untersuchen und aufbauen.

Schließlich ist das ultimative Ziel der gesamten Big-Data-Entwicklung, die Datenanalyse zu den niedrigsten Kosten und der höchsten Leistung durchzuführen, um einen echten Geschäftswert zu realisieren .

Wenn Sie hilfreich sind, beachten Sie bitte unser Projekt  Juicedata/JuiceFS  ! (0ᴗ0✿)

{{o.name}}

{{m.name}}