iQIYI Data Lake Practice – Entwicklung der Protokollplattformarchitektur basierend auf Data Lake

Wuhan Yuan Chuanghui kehrt zurück, sprechen wir am 20. April über große Models.“

Hintergrund

Um den Anforderungen der Echtzeitabfrage und -analyse von Protokollen innerhalb des Unternehmens gerecht zu werden, hat das Big-Data-Team von iQiyi die Venus-Protokolldienstplattform entwickelt, die für die Erfassung, Speicherung, Verarbeitung und Analyse der Dienstprotokolle von iQiyi verantwortlich ist. In den frühen Tagen wurde die auf ElasticSearch basierende Speicheranalysearchitektur übernommen. Als der Datenumfang weiter zunahm, traten Probleme wie hohe Kosten, schwierige Verwaltung und schlechte Stabilität auf.

Die Data-Lake-Technologie hat sich in den letzten Jahren rasant weiterentwickelt. Sie nutzt eine einheitliche Big-Data-Speicherbasis und eine Architektur, die Speicher und Rechenleistung trennt und eine Lösung bietet, die für Szenarien wie Protokolle mit großen Schreibvorgängen und kleinen Abfragen geeignet ist. Daher führte Venus eine architektonische Transformation basierend auf dem Datensee durch und schob Baumstämme in den See. Nach dem Betreten des Sees wurden die Kosten um 70 % gesenkt und die Stabilität erheblich verbessert. In diesem Artikel wird hauptsächlich der Denk- und Konstruktionsprozess von Venus von einer ElasticSearch-basierten Architektur zu einer Data Lake-basierten Architektur vorgestellt.

Einführung in die Venus-Log-Plattform

Venus ist eine von iQiyi entwickelte Protokolldienstplattform, die Protokolle sammelt, verarbeitet, speichert und analysiert. Sie wird hauptsächlich zur Protokollfehlersuche, zur Big-Data-Analyse, zur Überwachung und zur Alarmierung innerhalb des Unternehmens verwendet 1. angezeigt.

Abbildung 1 Venus-Link

Dieser Artikel konzentriert sich auf die architektonische Entwicklung des Protokoll-Fehlerbehebungslinks. Zu seinen Datenlinks gehören:

Protokollsammlung : Durch die Bereitstellung von Sammlungsagenten auf Maschinen und Container-Hosts werden Protokolle von Front-End, Back-End, Überwachung und anderen Quellen jedes Geschäftsbereichs gesammelt, und das Unternehmen wird auch dabei unterstützt, Protokolle, die den Formatanforderungen entsprechen, selbst bereitzustellen . Es wurden mehr als 30.000 Agenten bereitgestellt, die 10 Datenquellen wie Kafka, MySQL, K8s und Gateways unterstützen.
Protokollverarbeitung : Nach der Protokollerfassung wird es einer standardisierten Verarbeitung wie regelmäßiger Extraktion und integrierter Parser-Extraktion unterzogen und einheitlich im JSON-Format in Kafka geschrieben und dann vom Dump-Programm in das Speichersystem geschrieben.
Protokollspeicher : Venus speichert fast 10.000 Geschäftsprotokollströme mit einer Schreibspitze von mehr als 10 Millionen QPS und täglich neuen Protokollen von mehr als 500 TB. Da sich die Speicherskala ändert, hat auch die Auswahl der Speichersysteme viele Änderungen erfahren, von ElasticSearch bis hin zu Data Lake.
Abfrageanalyse : Venus bietet visuelle Abfrageanalyse, kontextbezogene Abfrage, Protokolldatenträger, Mustererkennung, Protokoll-Download und andere Funktionen.

Um der Speicherung und schnellen Analyse großer Protokolldaten gerecht zu werden, wurde die Venus-Protokollplattform drei großen Architektur-Upgrades unterzogen und entwickelte sich schrittweise von der klassischen ELK-Architektur zu einem selbst entwickelten System, das auf Datenseen basiert. In diesem Artikel werden die aufgetretenen Probleme vorgestellt während der Transformation der Venus-Architektur und -Lösungen.

Venus 1.0: Basierend auf ELK-Architektur

Venus 1.0 startete im Jahr 2015 und wurde auf Basis des damals beliebten ElasticSearch+Kibana erstellt, wie in Abbildung 2 dargestellt. ElasticSearch ist für die Speicher- und Analysefunktionen von Protokollen verantwortlich, und Kibana bietet visuelle Abfrage- und Analysefunktionen. Sie müssen nur Kafka nutzen und Protokolle in ElasticSearch schreiben, um Protokolldienste bereitzustellen.

Abbildung 2 Venus 1.0-Architektur

Da es Obergrenzen für den Durchsatz, die Speicherkapazität und die Anzahl der Index-Shards eines einzelnen ElasticSearch-Clusters gibt, fügt Venus weiterhin neue ElasticSearch-Cluster hinzu, um der wachsenden Protokollnachfrage gerecht zu werden. Um die Kosten zu kontrollieren, ist die Auslastung jedes ElasticSearch hoch und der Index ist mit 0 Kopien konfiguriert. Es treten häufig Probleme wie plötzliches Schreiben von Datenverkehr, große Datenabfragen oder Maschinenausfälle auf, die zur Nichtverfügbarkeit des Clusters führen. Gleichzeitig sind die Protokolle aufgrund der großen Anzahl von Indizes im Cluster, der großen Datenmenge und der langen Wiederherstellungszeit für lange Zeit nicht verfügbar und das Venus-Nutzungserlebnis wird immer schlechter.

Venus 2.0: Basierend auf ElasticSearch + Hive

Um die bei Venus 1.0 aufgetretenen Probleme zu lindern, führte Venus 2.0 Hive ein. Die Architektur ist in Abbildung 3 dargestellt. Die wichtigsten Verbesserungen sind wie folgt:

Clusterklassifizierung: ElasticSearch-Cluster werden in zwei Kategorien unterteilt: hohe Qualität und niedrige Qualität. Wichtige Unternehmen verwenden hochwertige Cluster, die Last des Clusters wird auf einem niedrigen Niveau gesteuert und der Index ist mit einer 1-Kopie-Konfiguration aktiviert, um den Ausfall eines einzelnen Knotens zu tolerieren wird auf hoher Ebene gesteuert und der Index verwendet weiterhin eine 0-Kopie-Konfiguration.
Speicherklassifizierung: Doppeltes Schreiben von ElasticSearch und Hive für Protokolle mit langer Speicherung. ElasticSearch speichert die Protokolle der letzten 7 Tage und Hive speichert Protokolle über einen längeren Zeitraum, was den Speicherdruck von ElasticSearch verringert und auch das Risiko verringert, dass ElasticSearch durch große Datenabfragen hängen bleibt. Da Hive jedoch keine interaktiven Abfragen durchführen kann, müssen die Protokolle in Hive über eine Offline-Computerplattform abgefragt werden, was zu einer schlechten Abfrageerfahrung führt.
Einheitliches Abfrageportal: Bietet ein einheitliches visuelles Abfrage- und Analyseportal ähnlich wie Kibana und schützt den zugrunde liegenden ElasticSearch-Cluster. Wenn ein Cluster ausfällt, werden neu geschriebene Protokolle für andere Cluster geplant, ohne dass dies Auswirkungen auf die Abfrage und Analyse neuer Protokolle hat. Planen Sie den Datenverkehr zwischen Clustern transparent, wenn die Clusterlast unausgeglichen ist.

Abbildung 3 Venus 2.0-Architektur

Venus 2.0 ist eine Kompromisslösung zum Schutz wichtiger Unternehmen und zur Reduzierung des Risikos und der Auswirkungen von Ausfällen. Sie weist jedoch immer noch die Probleme hoher Kosten und schlechter Stabilität auf:

ElasticSearch hat eine kurze Speicherzeit: Aufgrund der großen Menge an Protokollen kann ElasticSearch nur 7 Tage speichern, was den täglichen Geschäftsanforderungen nicht gerecht wird.
Es gibt viele Eingänge und Datenfragmentierung: mehr als 20 ElasticSearch-Cluster + 1 Hive-Cluster, es gibt viele Abfrageeingänge, was für Abfrage und Verwaltung sehr unpraktisch ist.
Hohe Kosten: Obwohl ElasticSearch Protokolle nur 7 Tage lang speichert, verbraucht es immer noch mehr als 500 Maschinen.
Integriertes Lesen und Schreiben: Der ElasticSearch-Server ist für das gleichzeitige Lesen und Schreiben verantwortlich und beeinflusst sich gegenseitig.
Viele Fehler: ElasticSearch-Fehler machen 80 % der gesamten Fehler bei Venus aus. Nach Fehlern werden Lese- und Schreibvorgänge blockiert, Protokolle gehen leicht verloren und die Verarbeitung ist schwierig.

Venus 3.0: Neue Architektur basierend auf Data Lake

Denken Sie über die Einführung eines Data Lake nach

Nach einer eingehenden Analyse des Protokollszenarios der Venus fassen wir seine Eigenschaften wie folgt zusammen:

Große Datenmenge : fast 10.000 Geschäftsprotokollströme mit einer Spitzenschreibkapazität von 10 Millionen QPS und Datenspeicherung auf PB-Ebene.
Mehr schreiben und weniger prüfen : Unternehmen fragen Protokolle normalerweise nur dann ab, wenn eine Fehlerbehebung erforderlich ist. Bei den meisten Protokollen sind innerhalb eines Tages keine Abfragen erforderlich, und die Abfrage-QPS ist insgesamt äußerst niedrig.
Interaktive Abfrage : Protokolle werden hauptsächlich zur Fehlerbehebung in dringenden Szenarien verwendet, die mehrere aufeinanderfolgende Abfragen erfordern und eine interaktive Abfrageerfahrung der zweiten Ebene erfordern.

Bezüglich der Probleme, die bei der Verwendung von ElasticSearch zum Speichern und Analysieren von Protokollen auftreten, glauben wir, dass es aus folgenden Gründen nicht ganz mit dem Venus-Protokollszenario übereinstimmt:

Ein einzelner Cluster hat begrenzte Schreib-QPS und Speicherskalierung, daher müssen sich mehrere Cluster den Datenverkehr teilen. Komplexe Planungsstrategieprobleme wie Clustergröße, Schreibverkehr, Speicherplatz und Anzahl der Indizes müssen berücksichtigt werden, was die Verwaltung schwieriger macht. Da der Geschäftsprotokollverkehr stark schwankt und unvorhersehbar ist, ist es häufig erforderlich, mehr ungenutzte Ressourcen zu reservieren, um die Auswirkungen plötzlichen Datenverkehrs auf die Clusterstabilität zu beheben, was zu einer enormen Verschwendung von Clusterressourcen führt.
Die Volltextindizierung während des Schreibens verbraucht viel CPU, was zu einer Datenerweiterung und einem erheblichen Anstieg der Rechen- und Speicherkosten führt. In vielen Szenarien erfordert das Speichern von Analyseprotokollen mehr Ressourcen als Hintergrunddienstressourcen. Für Szenarios wie Protokolle, in denen es viele Schreibvorgänge und wenige Abfragen gibt, ist die Vorberechnung des Volltextindex aufwändiger.
Speicherdaten und Berechnungen erfolgen auf demselben Computer. Abfragen großer Datenmengen oder aggregierte Analysen können sich leicht auf das Schreiben auswirken und zu Schreibverzögerungen oder sogar Clusterfehlern führen.

为了解决上述问题，我们调研了ClickHouse、Iceberg数据湖等替代方案。其中，Iceberg是爱奇艺内部选择的数据湖技术，是一种存储在HDFS或对象存储之上的表结构，支持分钟级的写入可见性及海量数据的存储。Iceberg对接Trino查询引擎，可以支持秒级的交互式查询，满足日志的查询分析需求。

针对海量日志场景，我们对ElasticSearch、ElasticSearch+Hive、ClickHouse、Iceberg+Trino等方案做了对比评估：

通过对比，我们发现基于Iceberg+Trino的数据湖架构最适合Venus日志场景：

存储空间大：Iceberg底层数据存储在大数据统一的存储底座HDFS上，意味着可以使用大数据的超大存储空间，不需要再通过多个集群分担存储，降低了存储的维护代价。
存储成本低：日志写入到Iceberg不做全文索引等预处理，同时开启压缩。HDFS开启三副本相比于ElasticSearch的三副本存储空间降低近90%，相比ElasticSearch的单副本存储空间仍然降低30%。同时，日志存储可以与大数据业务共用HDFS空间，进一步降低存储成本。
计算成本低：对于日志这种写多查少的场景，相比于ElasticSearch存储前做全文索引等预处理，按查询触发计算更能有效利用算力。
存算隔离：Iceberg存储数据，Trino分析数据的存算分离架构天然的解决了查询分析对写入的影响。

基于数据湖架构的建设

通过上述评估，我们基于Iceberg和Trino构建了Venus 3.0。采集到Kafka中的日志由转存程序写入Iceberg数据湖。Venus查询平台通过Trino引擎查询分析数据湖中的日志。架构如图4所示。

图4 Venus 3.0架构

日志存储

如图4所示，数据湖中的日志存储包含三个层次，分别是HDFS数据存储层、Alluxio缓存层及Iceberg表格式层。对读写可见的是Iceberg表格式层，日志流以表的形式写入，并持久化存储到HDFS。对于查询性能要求高的日志流会开启Alluxio缓存，日志流同时写入Alluxio和HDFS，查询时优先读取Alluxio的数据，加快数据加载速度。所有日志都存在一个Iceberg库下，一个日志流对应一张Iceberg表。表的schema由日志的格式决定，按日志中的时间戳字段做小时级分区，并按业务需求配置TTL。Iceberg的数据可见性由写入时提交周期决定，我们按需每分钟或者每5分钟做一次提交。

查询分析

Venus日志平台将用户的查询分析请求翻译成SQL，通过Trino查询Iceberg，所有SQL的执行由一个Trino集群承担。对于10亿行日志，字符串匹配的查询5秒左右返回结果，聚合查询30秒内返回结果，满足大部分的日志使用场景。

对日志查询性能要求更高的表，我们开启了Alluxio缓存。如图5所示，对于慢查询，使用Alluxio后查询速度有大幅的提升，P99耗时降低84%。

图5 日志查询性能对比

转存程序

Venus转存程序将Kafka中的数据写入数据湖中，采用了对Iceberg支持比较好的Flink计算引擎，通过Flink SQL消费Kafka写入Iceberg。每个日志流运行一个转存程序，单核支持16MB/s的写入，是写入ElasticSearch的3倍。在爱奇艺，Flink程序部署在YARN集群上，最小的CPU调度粒度为1个核，加上Flink Master，运行起来至少需要2个核。Venus接入的近万个日志采集中95%的日志流量低于16MB/s，相当大比例的日志流量在KB/s级别，部署在YARN上将造成巨大的资源浪费。因此，我们选择了大小流量调度策略，将资源需求大于1核的转存程序部署在YARN上，资源需求小于1核的转存程序，以Flink单机运行模式部署在K8S上，将部署资源粒度降低到0.1核。与写入ElasticSearch的转存程序相比，计算资源消耗降低了70%。

落地效果

得益于Venus 提供的统一查询分析入口，从ElasticSearch到数据湖的切换过程对业务几乎透明。相比旧架构，整体成本降低70%以上，每年节省上千万元，同时故障率降低了85%：

存储空间 ：日志的物理存储空间降低30%，考虑到ElasticSearch集群的磁盘存储空间利用率较低，实际存储空间降低50%以上。
计算资源 ：Trino使用的CPU核数相比于ElasticSearch减少80%，转存程序资源消耗降低70%。
稳定性提升：迁移到数据湖后，故障数降低了85%，大幅节省运维人力。

总结与规划

目前基于数据湖的Venus架构已稳定上线一年，为业务提供高性价比的日志服务。未来Venus将在以下几个方面进一步探索：

Iceberg+Trino的数据湖架构支持的查询并发较低，我们将尝试使用Bloomfilter、Zorder等轻量级索引提升查询性能，提高查询并发，满足更多的实时分析的需求。
目前Venus存储了近万个业务日志流，日新增日志超过500TB。计划引入基于数据热度的日志生命周期管理机制，及时下线不再使用的日志，进一步节省资源。
如图1所示，Venus同时也承载了大数据分析链路的Pingback用户数据的采集与处理，该链路与日志数据链路比较类似，参考日志入湖经验，我们对Pingback数据的处理环节进行基于数据湖的流批一体化改造。目前已完成一期开发与上线，应用于直播监控、QOS、DWD湖仓等场景，后续将继续推广至更多的湖仓场景。详细技术细节将在后续的数据湖系列文章中介绍。

也许你还想看

爱奇艺数据湖实战

爱奇艺大数据加速 - 从Hive到Spark SQL

爱奇艺数据湖实战 - 广告数据湖应用

本文分享自微信公众号 - 爱奇艺技术产品团队（iQIYI-TP）。
如有侵权，请联系 [email protected] 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。