本文根據杜益凡老師在〖deeplus直播：愛奇藝複雜場景下的大資料體系建設與實踐〗線上分享演講内容整理而成。
分享概要
一、愛奇藝資料中台概況
二、愛奇藝資料湖體系介紹
三、愛奇藝資料湖技術對比
四、愛奇藝資料湖業務落地
五、愛奇藝資料湖性能優化
六、後續計劃
七、Q&A
一、愛奇藝資料中台概況
1.資料中台支撐業務發展
上圖展示了愛奇藝的資料業務鍊路。資料中台的主要職責是制定資料标準，內建來自使用者、業務和合作方的資料。通過規範和系統，資料中台對資料進行綜合管理和治理，確定資料安全，并為上層業務提供服務支撐。
資料科學家們利用資料中台提供的資料服務，提取有價值的資訊，為上層決策提供支援并推動創新。通過科技創新，賦予内容生産與分發更強的能力，為使用者提供在各種智能終端上的卓越視聽互動體驗。
資料中台的核心使命是有效管理和治理所有資料，并以盡可能低的成本實作資料的最大價值。
為了達成這一目标，我們需要對資料體系的各個環節進行标準化操作，并制定相應的衡量标準。這不僅有助于確定資料的品質，還能提高資料處理的效率，進而確定資料治理工作的順利進行。
在此基礎上，我們建構了高效的資料處理鍊路，以形成完整的資料體系，滿足各業務部門對資料的需求。通過結合資料處理技術和人工智能技術，我們能夠顯著提高資料處理效率，使得不同層次的使用者、營運人員、資料分析人員及資料科學工作者都能輕松地使用資料，并從中擷取有價值的洞察和決策支援。這不僅有助于推動業務創新和增長，還能提升公司的整體競争力。
2.資料工作發展過程
1）零散态
在早期，我們直接将原始資料生成到資料報表層級，并存儲在Hadoop叢集中，這種方式在業務較為簡單時能極大發揮生産效率。然而，随着業務變得越來越複雜，了解和尋找資料的難度逐漸增加。普通使用者需要反複詢問資料如何使用、如何查找，或者将資料需求交給資料工作者完成，這會對整體效率産生很大的影響。
2）平台化
從2018年開始，我們緻力于建構一個平台化系統，以提高資料生産、收集的效率。我們建立了離線開發平台和實時開發平台，為使用者提供更便捷的資料擷取和處理方式。
3）标準化
為了更好地規範資料使用，我們重新定義了資料标準，并為所有行為制定了相應的埋點投遞規範。這不僅提高了埋點工作效率，還降低了業務埋點錯誤率，使産品更好地了解設計埋點的方法。
同時，我們規範了數倉體系，統一了次元和名額，以建立更好的資料服務平台。
4）智能化
基于以上建設基礎，我們建立了機器學習平台和深度學習平台，以提高資料品質要求。通過建立資料品質模型，我們可以更好地監控和處理資料。
5）體系化
從2021年開始，資料中台牽頭成立了資料規範工作組，定義了整體資料規範，并提供衡量标準，對資料治理工作進行整體效果評估。
同時，我們引入新技術以提升資料處理效率，為使用者提供更優質的服務。
6）立體化
通過調研業界新技術，我們引入了資料湖和流批一體處理技術，并對鍊路進行了近實時化改造。通過對鍊路進行近實時化改造，我們實作了更高效、更靈活的資料處理和分析，進而更好地支援業務決策。
二、資料湖體系介紹
在資料的早期階段，由于資料的分散和難以擷取，形成了許多資料孤島，這些孤島未能及時得到有效的整合和管理，逐漸形成了資料沼澤。
為了解決這個問題，我們開始進行資料治理，首先對資料倉庫進行治理，重新制定了資料倉庫的統一規範，建立了統一資料倉庫和和資料集市，進而形成了資料池。在這個基礎上，我們對整個資料體系進行了梳理和整合，建立了一個能夠存儲所有資料、友善查找和使用的資料湖體系。
1.資料鍊路
上圖描繪了愛奇藝資料鍊路的構成情況。
在資料生産層，資料來源主要分為兩類，即C端和B端。
C端資料，主要源自使用者終端，具體包括終端埋點資料和終端日志。而B端資料，則來自身服務後端日志、合作方資料，以及視訊資訊、内容資訊等重要業務資料。
這些資料經過接收層和采集層的收集，收集到資料中台。在加工層，部分資料會被處理成為統一資料倉庫，整體以資料湖方式提供，專業的資料工作者對這些資料進行分析，進一步挖掘其價值。
他們會進行使用者畫像，通過資料來描繪出每個使用者的特征和喜好；也會進行内容了解，将資料拆解成不同的内容模型，以提供決策支援；此外，他們還會進行報表分析，報表是使用最廣泛的資料呈現方式，各級使用者可以通過觀察報表的資料變化，直接了解業務情況。
基于這些資料，資料工作者還通過對使用者個性化推薦，對内容更為智能地進行分發，讓使用者能夠接觸到自己最感興趣的内容。
2.資料架構
基于資料鍊路情況，我們結合數倉模組化和資料湖的思想，打造了融合了資料湖思想的資料中台架構。
底層資料層主要囊括各種資料來源，Pingback是埋點資料，主要用來收集使用者行為，業務資料主要存儲在各種關系型資料庫和NoSQL資料庫；資料層的資料通過傳輸層的各收集工具，存儲在存儲層。
存儲層從根本上來說都是存儲在HDFS這個分布式檔案系統中，原始檔案直接存儲在HDFS，其他結構或非結構資料，存儲在Hive、Iceberg或HBase。
在計算層，使用離線引擎Pilot驅動Spark、MapReduce或Trino進行離線計算，使用排程引擎Gear進行工作流排程。使用Europa排程流式計算，經過幾輪疊代，目前流式計算主要使用Flink作為計算引擎。
在計算層之上的開發層，通過對計算層和傳輸層的各個服務子產品進一步封裝，提供了用來開發離線資料處理工作流、對資料進行內建，開發實時處理工作流，開發機器學習工程實作等完成開發工作的工具套件和中間服務。
其中資料湖平台，對資料湖中各個資料檔案與資料表的資訊進行管理，數倉平台數倉資料模型、實體模型、次元、名額等資訊進行管理。
- 縱向，投遞管理工具管理資料中台最主要的資料，Pingback埋點資料的規範、字段、字典、時機等元資訊；
- 中繼資料中心、資源中心等子產品用來維護資料表或資料檔案的元資訊，以及保障資料安全；
- 資料品質中心和鍊路治理平台保障資料品質和資料鍊路生産；
- 底層服務由雲服務團隊提供私有雲和公有雲支援。
上層提供資料圖譜作為資料目錄供使用者尋找所需要的資料。提供魔鏡、北鬥等自助應用，供不同層次的使用者自助進行資料工作。
整個架構體系，在資料的內建和管理上，更加靈活，可以容納所有資料，并通過對自助工具的優化更新，降低使用者使用門檻，滿足不同層次使用者的需求。提高資料使用效率，提升資料價值。
3.資料體系
資料中台建立的目的是解決資料的激增與業務的擴大而出現的統計口徑不一緻、重複開發、名額開發需求響應慢、資料品質低、資料成本高等問題。兩者在一定程度上目标一緻。我們結合資料湖的理念，對資料中台的資料體系進行了優化更新。
在資料中台建設的初始階段，我們對公司的數倉體系進行統一，對業務進行調研，并整理已有的字段次元資訊，歸納出一緻性次元，并建立統一名額體系，制定出統一數倉規範，建構了統一數倉的原始資料層(ODS)、明細資料層(DWD)、聚合資料層(MID)，并建構了裝置庫，包含累積裝置庫和新增裝置庫。
在統一數倉之上，資料團隊根據不同的分析統計方向和業務具體訴求，建構了主題數倉和業務集市。主題數倉和業務集市包含進一步處理的明細資料、聚合資料以及應用層資料表，資料應用層使用這些資料，向使用者提供不同的服務。
在統一數倉體系中，原始資料層及以下是不開放的，使用者隻可以使用資料工程師處理加工後的資料，不可避免的會有資料細節損失。在日常使用中，常常會有具有資料分析能力的使用者希望能夠通路底層原始資料，進行個性化的分析或者排查問題，是以我們引入資料湖的資料治理理念，以資料湖的分區管理方式對資料進行整理，同時對資料中繼資料進行豐富，建構好資料中繼資料中心。
經過資料湖理念的治理，将原始資料層和其他原始資料，比如原始日志檔案，歸置到原始區，該區域有資料處理能力的使用者可以申請權限使用。
統一數倉的明細層、聚合層以及主題數倉、業務集市歸置在産品區，這些資料已經經過資料團隊的資料工程師加工處理作為最終資料成品提供給使用者使用，該區域的資料經過資料治理，對資料品質有保障。
- 為敏感資料存放劃分敏感區，重點管控通路權限；
- 使用者以及資料開發人員日常産生的臨時表或個人表，該區域的資料表由使用者自行負責，可以有條件的開放給其他使用者使用；
- 通過中繼資料中心維護各資料的中繼資料，包含表資訊、字段資訊，以及字段所對應的次元和名額，同時維護資料血緣，資料血緣包含表級别的血緣和字段級别血緣；
- 通過資料資産中心維護資料的資産特性，包含針對資料級别、敏感性和權限的管理。
為了讓使用者更好地自助使用資料：
- 在應用層提供資料圖譜，作為資料目錄，供使用者查詢資料，包含資料的用途，次元、名額、血緣等中繼資料，同時作為權限申請的一個入口；
- 同時提供自助分析平台，為資料使用者提供自助分析的能力。
4.資料湖是一種治理資料的理念
在我們資料中台體系建設過程中，資料湖是作為資料治理的手段使用的。
資料湖作為一種資料治理思想的價值在于：
1）能夠存儲所有資料，不管是目前用到的，還是暫時用不到的,確定資料需要使用的時候能夠查到需要的資料；
2）資料湖存儲的資料經過科學的管理，不再需要資料工程師高度參與，使用者可以自助地查找資料和使用資料。
- 更靈活更便宜的資料存儲：HDFS存儲，從三備份到單備份輔之其他校驗方式，進行無損存儲，進而節省機器資源。引入Iceberg表盡量替代Hive表，表存儲更加靈活。
- 更全的資料：提高資料及時性，存儲更全的資料，保證原始資料開放，以備不時之需。但存儲是有條件的，要遵循一定的生命周期。
- 更容易的資料查找：以盡可能低的成本存儲更多的資料，賦能資料查找，是以開發資料圖譜工具，友善使用者查找資料。
- 更便捷的資料內建：開發BabelX、Acciolog、Venus工具。
- 更高效的資料使用：魔鏡是自助查詢工具，使用者可定制計算。Babel供開發者在此平台上開發自己的資料處理流程。北鬥是營運分析工具，對使用者标簽進行分析，比如分析内容的不同閱聽人。
- 更可靠的資料管理：中繼資料平台、數倉平台、資料鍊路治理平台、資料資産平台。
5.資料湖是一種資料技術實作
資料湖也是一種資料技術實作。因為資料湖的特點存儲所有資料，從技術角度來看，必然研究如何高效內建和處理資料，由此産生了新的存儲格式和流批一體架構。資料湖的優勢是，能夠支援海量資料實時更新，降低存儲、計算成本，解決傳統資料處理流程的痛點。
三、資料湖技術對比
調研資料湖技術的過程中，調研過被廣泛使用的三種資料存儲格式：Delta Lake、Hudi和Iceberg。
1.Delta Lake vs Hudi vs Iceberg
上圖是三種技術的特性對比表格，記錄了調研當時的情況。
經過綜合評估，我們選擇了Iceberg作為資料表的存儲格式。
2.Iceberg是一種表格式
Iceberg是一種新設計的開源表格式，它支援對象存儲、HDFS檔案存儲，其存儲表支援行級更新和行級事務。它并不是查詢引擎，隻是能夠更好地存儲資料。
3.Hive vs Iceberg
相對于Hive表，Iceberg表最大的優勢是可以更好的支援行級更新，資料時效性可以提高到分鐘級，是以在資料處理時，資料及時性可以極大提升，于是在資料處理ETL上，可以友善地改造既有的Lambda架構，實作流批一體架構。
四、資料湖業務落地
1.在服務日志資料的應用
在改造之前，我們使用Venus工具從不同的服務實體機中抽取日志并發送到Kafka。然後，通過實時通路将這些資料插入到Elasticsearch中，以便在查詢平台進行查詢。然而，Elasticsearch的部署成本相對較高，是以整體成本也居高不下。
除此之外，Elasticsearch還存在穩定性方面的問題。如果Elasticsearch出現單節點故障，可能會影響到寫入和查詢功能的正常使用。是以，我們決定使用Iceberg替換Elasticsearch。通過直接使用Spark或Trino，我們可以查詢Iceberg表中的資料。
由于Iceberg是建構在HDFS之上的，是以我們可以利用HDFS叢集進行存儲，進而有效地降低了存儲成本。
在将資料從Elasticsearch遷移到Iceberg的初期，我們注意到查詢速度有所下降。然而，對于整體應用來說，這種差異是可以接受的。在進行日志查詢時，5分鐘和2分鐘的查詢時間差異并不大。是以，我們一直在持續優化查詢性能，目前已經能夠實作秒級查詢。
2.在使用者标簽的應用
使用者标簽是通過對使用者資料進行深入分析，并為每個使用者打上特定的标簽，為營運、廣告、推薦等業務提供重要參考。
在舊的架構中，我們通過将消息寫入Kafka隊列，再實時寫入到HBase，部分離線資料天級批量補入Hbase對資料進行修正，标簽服務基于HBase通過接口提供服務，定期從Hbase導出快照到Hive提供離線分析。
然而，這種架構存在一些問題。
首先，資料導出速度較慢，隻能實作天級别的導出，導緻分析時效性較差。其次，在後續使用中發現Impala運維成本較高且性能不穩定。
引入Iceberg後，我們對架構進行了調整。目前，寫入資料的同時，會将實時更新資訊和HBase的更新資訊一并寫入Iceberg。由此可以實作近實時的資料通路。使用Spark SQL或Trino進行查詢時，查詢效率非常高，大大提高了确認效率和資料通路效率。
改造後的業務效益顯著提高。我們不再需要完全依賴HBase，實作了資源複用和低運維成本。同時，我們提高了資料處理速度和查詢效率，更好地支援了廣告推薦等業務場景。
1）舊架構痛點
實時寫，通過開發實時寫入到HDFS中，進行離線處理，從離線數倉批量寫入HBase中進行資料校正。我們的服務主要是基于HBase進行接口支援。離線分析是将HBase全面導出到Hive表裡，實作離線支援。
在舊架構中，使用HBase為參與引擎。由此，資料導出速度慢，天級才能導出，分析時效性較差。另一方面，在後續使用中發現Pilot性能及運維成本較高。
2）改造後業務效益
引入Iceberg後，将架構調整成寫入Iceberg的同時，将實時更新資訊及HBase的更新資訊寫入，使用近實時的通路。通過Spark SQL或Trino查詢時，查詢效率非常高，提升确認效率和資料通路效率。
3.在CDC訂單資料的應用
CDC訂單資料的應用場景是通過MySQL實時分析binlog，将資料更新到Hadoop叢集，實作離線查詢。
在引入Iceberg之前，我們使用MySQL每天全量導出到Hive或增量同步到Kudu的方式進行離線查詢，難以适應即席查詢的場景。此外，舊架構還存在時效性差、成本高等問題。
通過引入Iceberg，我們實作了流程簡化、查詢效率提高和時效性從天級降低到分鐘級的效果。
同時，不再需要Kudu節點，實作了資源複用和低運維成本。改造後的業務效益顯著提高，為我們的資料處理和分析提供了更加高效和靈活的解決方案。
4.在廣告資料的應用
廣告資料涵蓋了廣告點選日志與使用者觀影日志，這些日志支撐着廣告算法模型的及時更新，為廣告引擎投放廣告提供助力。
原本的處理途徑是使用Hive進行離線資料分析，天級或小時級更新資料模型，然後于Hive和Kudu中形成可供算法調用的新模型。
目前我們引入了Iceberg，以Kafka的實時資料為基礎，通過流批一體方式進行離資料處理，這些資料進入Iceberg表後，我們利用Spark和Trino進行算法側的分析，并快速加載到引擎側。這樣的處理方式将原本需要半小時以上的全鍊路流程縮短至7-10分鐘，同時将原本的幾套架構體系簡化為Iceberg流批一體的架構。
5.在埋點投遞的應用
Pingback埋點投遞是整個資料通路中最重要的通路，Pingback埋點資料包括使用者的啟動退出、頁面展示點選和觀影資料，整體業務基本圍繞着這些資料進行，是資料中台統一數倉的主要資料來源。
在引入資料湖技術之前，資料中台的數倉處理，使用離線處理和實時處理結合的方式提供離線數倉和實時數倉。
全量資料通過傳統離線解析處理的方式，構造成數倉資料，以Hive表的形式存儲在叢集。
實時性要求高的資料，單獨通過實時鍊路生産，以Kafak中的Topic的形式提供給使用者使用。
這樣的架構有以下幾個問題：
- 實時和離線兩條通路，除了最核心的處理清洗邏輯，需要維護兩套代碼邏輯，在有規則更新時，需要實時離線同時更新，否則會産生不一緻；
- 離線鍊路小時級更新，且有1小時左右的延遲，即00:01的資料可能在02:00才能查到，部分有一定實時要求的下遊業務接受不了，需要支援必須上實時鍊路；
- 實時鍊路雖然實時性在秒級，但成本較高，且大多使用者不需要秒級更新，五分鐘級足夠滿足需求，且Kafka流的消費沒有資料表友善。
對于這些問題，Iceberg表+流批一體的資料處理，可以較好的解決上述問題。
主要的優化操作是對ODS層的表和DWD層的表進行Iceberg改造，同時将解析和資料處理加工改造為Flink任務。
在具體實施時，為了保障資料生産的穩定以及資料的準确性不受影響，我們采用如下措施：
- 先從非核心資料開始切換，根據實際業務情況，決定先以QOS投遞和自定義投遞作為試點；
- 對離線解析邏輯抽象後，形成了統一的Pingback解析入庫SDK進行實時離線統一部署，使代碼統一；
- Iceberg表部署完成并開始生産後，先進行了兩個月的雙鍊路并行跑，并對資料進行正常化的對比監測；
- 确認沒問題後，對上層使用進行無感覺切換；
- 核心資料相關的啟動、播放資料，待整體驗證穩定後再進行流批一體改造。
改造後，收益如下：
qos和自定義投遞資料鍊路整體實作了近實時化。小時級延遲的資料達到五分鐘級更新。
除特殊情況，流批一體鍊路已可以滿足實時需求，既有QOS和自定義相關實時鍊路和離線解析鍊路可以下線，節省資源。
五、資料湖性能優化
1.性能優化——小檔案智能合并
在流批一體資料處理落地過程中遇到了很多問題，其中最典型的是小檔案問題。
與Hive的存儲方式不同，Iceberg在資料分區時對于每個檔案的大小控制不夠靈活，這使得解決小檔案問題較為棘手。
Iceberg支援行級更新，這使得每次更新都會生成一個單獨的Iceberg檔案。在頻繁更新和表規模較大的情況下，會産生大量的微小檔案。随着這些檔案的數量增加，HDFS的性能會受到影響，甚至可能導緻Name Node的負載過重。
查詢性能随着需要通路的檔案數量增加而降低。大量的微小檔案嚴重拖慢了查詢速度。是以，我們需要實施有效的優化政策以合并這些小檔案。
1）定時合并
除了控制寫入參數之外，我們還會定期合并小檔案。然而，選擇合适的合并時機并非易事。例如，我們可能會選擇每三小時合并一次小分區，這在一定程度上解決了大部分業務問題。
但在某些場景下，例如收集硬體資訊和更新訂單時，整體資料量巨大且資料更新的頻率非常高。
這種情況下，三小時後小檔案數量已經累積得非常高。對于其他業務，定時三小時合并是有效的，但對于這些特定的業務，三小時後檔案數量就已經很多了。
是以，合并後的短時間内查詢性能會提高，但随着檔案數量的增加，查詢性能會逐漸下降。在接近定時合并的時間門檻值時，可能會出現無法瞬間查詢的情況。
1）智能合并
為了更有效地解決這個問題，我們參考了Netflix的一篇文章，并制定了一個智能合并方案。該方案基于分區下檔案大小均方差來自動選擇需要合并的分區。
對于不同的業務線，我們可以設定不同的權重門檻值，進而實作智能化的合并政策。當達到分區檔案數域值時，該方案能直接觸發檔案合并。這種智能合并政策可以同時處理不同業務線的需求，及時合并檔案，避免因業務更新量瞬間激增導緻設定的時間門檻值失效。
2.性能優化——BloomFilter
和Impala、Kudu對比，Iceberg存在性能較差的情況。經過深入分析發現Impala和Kudu利用索引來加速查詢。但是Iceberg對索引支援有限，查詢時往往是全表掃描。自Parquet1.12版本開始，Parquet已支援BloomFilter。為了提升查詢性能，我們對Iceberg源碼進行修改，激活了對BloomFilter的支援。
經過優化，查詢速度顯著提高，訂單ID查詢時間從900多秒大幅降低到10秒，整體性能現已接近Impala+Kudu的架構。雖然會占用更多存儲空間， 但考慮到其卓越的整體性能，成本效益依然很高。
六、後續計劃
對于資料湖在資料中台應用的後續規劃，主要從兩方面：
- 從架構層面，會繼續細化各個子產品的開發，讓資料中台提供的資料更加全面，更加易用，讓不同的使用者可以自助使用；
- 從技術層面，繼續對資料鍊路進行流批一體改造，同時繼續引入合适的資料湖技術，提高資料的及時性，降低生産成本。
Q&A
Q1：流量資料入湖場景下，使用MOR（Merge on Read）表，還是COW（Copy on Write）表更合适？
A1：我們主要在read時進行合并，MOR，是以我剛才就基本沒有提Copy on Write。
Q2：如何保障資料湖中資料定義和業務規則的一緻？怎麼檢查、清理資料？
A2：通過資料中台的架構進行支援，主要通過投遞管理、中繼資料中心、統一名額平台規定資料定義和業務規則。
檢查和清理資料方面，檢查資料品質由品質平台保障；清理資料則通過資源中心，審計整體的資料資源，清理過期資料。
Q3：Iceberg查詢是标準SQL嗎？
A3：對，使用标準SQL，自研的查詢引擎，封裝Spark SQL、Hive以及Trino。