講師介紹
張旭，光大銀行準實時資料平台技術負責人，專注于分布式系統核心研發。在OLAP & 消息中間件領域有較豐富經驗。開源愛好者，Apache RocketMQ committer，Prometheus contributor。
分享概要
一、準實時資料平台
二、架構演進實踐
- 實時資料湖架構
- 資料服務總線實踐
三、總結&未來規劃
一、準實時資料平台
光大銀行資料資産部以提升服務和經營效率為核心目标，負責光大銀行的資料管理和數字化轉型工作，提供關鍵性的底層技術支撐。在整個數字化轉型和業務更新過程中，資料資産部支撐業務關鍵資源、保障關鍵基礎設施運作，在我行扮演着重要角色。
準實時資料平台則是光大銀行資料資産部-大資料平台團隊下的重要項目。
準實時資料平台始于2016年研發，至今已有6-7年的演進，上圖是平台的整體架構圖，資料流向從左到右。
初期平台的定位是準實時資料采集與流式計算，向外提供準實時技術支援和按需開發的流式資料加工等服務。基于此，平台分為三個子產品：資料采集、資料标準化和資料釋出。
簡單來說，我們的資料采集接近于資料貼源層的邏輯，整個流程更像一個實時的資料倉庫。資料源通過兩種方式被傳送到我們的Kafka貼源層：
- 第一種是傳統關系型資料庫的CDC資料，這些資料會通過我們的OGG工具進行同步并存儲于貼源層，另外，業務系統中的有異步導出需求且對延時敏感的資料通過Kafka API直接寫入到貼源層。這些資料大多不可被直接使用于下遊業務應用。是以在标準化子產品進行公共邏輯處理，資料會被傳遞到SparkStreaming或Flink實時流式任務，随後被存儲于Kafka标準層。在标準層進行的處理後，其中的一部分資料可以被直接用于下遊應用的消費。
- 另一種資料則通過各種相對複雜的計算邏輯（flink/spark）或批處理技術寫入到我們最終的釋出層。與前兩層處理不同，第三層着重處理業務邏輯并将最終的資料提供給下遊系統進行實時訂閱。
整個架構經過多年演進，展現出如下三個特點：
- 具有清晰的分層邏輯，并且基于實時數倉的設計邏輯；
- 該架構涵蓋廣泛的元件，包括明顯的業務邏輯處理，初衷是提供流式資料加工架構相關的服務；
- 兼具準時資料的存儲平台和計算資源服務提供平台。
随着大資料領域多年的發展，元件分工也更加細化。元件細分為大資料架構提供更高的可維護性、可擴充性、安全性、穩定性、性能、效率和易用性，使得整個架構更加靈活和強大，能夠更好地滿足不斷增長的資料處理需求。
然而，反觀我們的系統，存在兩個問題：
- 首先，我們必須維護大量業務處理邏輯，随着時間推移，這對我們平台的資源配置設定和能力優化帶來了巨大壓力；
- 其次，我們維護了大量元件，從導入層到存儲層、計算層、上層排程層，使得該平台的定位相對較模糊，需要更加明确和細化。
是以，我們需要加強對架構的管理，以縮小各個元件之間的差異，同時優化架構的組織和協調，使之更加适應未來的需求。
二、架構演進實踐
針對上述問題，我們結合整個準實時資料平台的元件架構特點，将平台拆分成了兩個子平台：
- 實時資料湖平台
- 資料服務總線平台
整個準實時資料平台維護的相關元件從左到右，包括資料接入和導出層、消息中間件層、資料計算層以及資料存儲層。最上層是排程層，分為資源排程和任務排程，資源排程也由我們完成。
這樣的拆分更好地解決平台定位不清晰的問題，同時也提高了平台元件之間的協作效率。
資料服務總線平台拆分後以Kafka為中心的部分，該部分包括前端封裝的SDK和OGG，以及随後引入的Schema Registry元件，緻力于提供更完備的流式資料供給能力。
同時，我們引入了Apache Hudi，并結合原有的流式計算元件生态，建構出實時資料湖平台，旨在實作實時資料的高效處理和存儲。該平台緻力于實時貼源資料存儲，在資料的管理、查詢和可視化分析等方面提供優化的解決方案。
1、實時資料湖
下圖是實時資料湖的資料處理鍊路，中間是綠色的部分是資料湖的存儲層，由Hudi和HDFS實作。
左邊是資料導入層，分為兩部分：
- 一是我們存量的貼源資料，基于Spark的批量任務從資料湖導入；
- 二是實時貼源資料，基于Flink實時流任務，從資料服務總線貼源層導入。
這兩部分共同彙總在實時資料湖，實作了一個完整的實時貼源資料存儲，對外提供分鐘級的一個貼源的資料的可見性。
右邊是資料導出層，分三種場景：
- 一是基于 Spark/Hive的這種批處理的導出的能力，給下遊的數倉和其他業務系統提供更穩定、低延遲時間的資料可用性；
- 二是基于Flink去提供秒級的實時資料的消費的能力；
- 三是基于内部的多源分析查詢平台(Presto)，提供實時資料的OLAP查詢能力。
實時資料湖提供的是分鐘級貼源資料存儲，填補了資料湖天級延遲場景和資料服務總線秒級延遲場景之間的空白。實時資料湖不僅是一種存儲方式，更提供了快速響應業務需求能力，實作了現代化的資料處理，推動了企業數字化轉型程序。
此外，對于光大内部許多業務而言，對資料的實時性并不需要完全做到秒級，分鐘級的延遲就已能夠滿足目前六成的業務需求。
下圖是我們内部一個核心的業務營運系統的資料處理鍊路，在引入實時資料湖之前和之後的演進路線：
未使用實時資料湖之前，資料來源于Kafka的ods層，通過Spark Streaming的流處理寫入Hbase，然後經過Hive的Tez批處理，最終通過基于Hive on Hbase表提供給業務查詢。整條資料鍊路的延遲時間非常長，達到了小時級别，這種延時對營運系統的性能影響非常大，明顯減緩了業務觸達的時效性。
演進後是基于Hudi的改進的資料處理鍊路，可以達到分鐘級的一個延遲。資料來源還是Kafka貼源層，會基于Flink的流處理，再去實時導入到Hudi，最終通過 Presto提供給業務實時貼源資料的互動查詢的能力。
整條鍊路經過改造後，資料可見性延遲從小時級别下降到了分鐘級别，處理環節相對簡化，同時Hudi提供了更穩定的資料來源。
2、資料服務總線
資料服務總線方面的實踐，主要涉及三個方面：
- 基于Confluent開源的Schema Registry實作了schema解耦；
- 對Kafka的原生API進行了封裝，以便更好地對外提供服務；
- 提升了服務的可觀測性和可視化水準。
1）Schema的解耦
下圖是優化前的資料流轉圖。
黑色實線表示資料流轉的方向，黑色虛線表示中繼資料流轉的方向。資料來源于Oracle資料庫，通過OGG進行導入，以Avro的格式，通過Kafka做資料層的解耦，由下遊基于Schema去做解析，下遊解析資料的Schema來源于上遊OGG接收到資料變更自動生成（即圖中藍色的.avsc檔案）。
是以，在上遊表結構發生變更時，遊必須同步去更新這個Schema檔案才能完成資料的解析，這個Schema檔案導緻上下遊系統在資料層是未完全解耦的狀态；當上遊系統發生變更時，下遊系統需要先基于舊的Schema完成舊資料的消費，然後再把新的Schema同步過來，重新開機服務使用新的Schema消費新的資料。
總的來說，這個變更流程比較複雜，且下遊對上遊存在依賴，并且如果上遊在投産的時候，沒有來得及通知下遊，當Schema變更以後，下遊系統會使用舊的Schema去解析新的資料，可能就會導緻無法預知的程式當機，影響下遊服務的穩定運作。
為解決這一問題，我們引入了Confluent的Schema Registry來實作Schema的解耦。
上圖展示了在引入了Schema Registry後的資料流轉圖。
資料的流向和之前一樣，主要差別是：在OGG側感覺到源端的表結構變更時，會主動去Schema Registry注冊新的Schema，同時将擷取到的Schema ID和資料一起寫入Kafka。下遊消費系統從消息中擷取新的Schema ID，也會去Schema Registry請求擷取對應的Schema，并使用這個Schema去解析資料。
是以，當Schema發生變化時，下遊的自動擷取和更新，免去了非必要的重新開機和未通知變更情況下的當機問題。同時，我們通過Schema Registry将Schema中心化存儲起來，友善後續進一步的管理。同時，引入Schema Registry以後，上遊系統和下遊系統都會對它有很強的依賴關系，這對Schema Registry服務本身的高可用提出了高要求。
①Schema Registry高可用實踐
上圖右側是Schema Registry單個執行個體的内部實作原理。最上層是接口層，對外提供Restful形式的通路接口，注冊請求（寫請求）過來後，會基于内部的store層将資料以消息的形式寫入Kafka的topic中，也就是說Schema Registry底層的真實存儲實際上是一個Kafka的topic；而Store層會緩存所有的Schema，對于讀請求，會直接從記憶體中擷取。
高可用實踐分為用戶端和服務端兩部分：
用戶端：高可用的一部分依賴于用戶端本身對Schema的緩存，在這種情況下，服務端如果暫時不可用，隻會影響新增Schema的注冊和解析；同時為了讓服務端部署多個執行個體，以此避免單點問題導緻的服務不可用問題，也要求用戶端配置多執行個體位址。是以，我們在自研的SDK裡內建了自動化配置這個功能。
服務端：除多執行個體部署以外，每個執行個體本身也做了獨立的部署，以此避免和其他服務混部造成影響；第二層是服務層自身的存儲緩存，在底層存儲出現問題時，可以提供讀服務。
同時，針對業務的需求，我們實作了叢集跨域部署和容災方案。
在我們内部，存在跨域擷取資料的需求，自然就會産生跨域擷取Schema的需求。
上圖有兩個域，左邊是DC A，右邊是DC B。在A域裡，生産者将相關資料寫入Kafka叢集，将Schema注冊到Schema Registry服務。在消費端，同時在A域和B域都會有對資料的消費需求，資料的同步一般的方案就是Replicator或MM等工具完成，比如topic1同步到B域對應A.topic1；在B域，拿到資料後，需要擷取Schema ID對應的Schema才能去解析出資料。是以，我們需要跨域擷取Schema的解決方案。
上圖最下面藍框中的就是一個跨域的Schema Registry叢集的實作。橙色是A域的Schema Registry執行個體，綠色是B域。整個叢集會有一個主節點，通過參數設定隻能在A域産生。同時，Schema Registry底層的存儲也使用A域的topic（即圖中的_schemas），這是為了保證資料沒有跨域寫入，并盡量避免因為網絡問題導緻的資料重複或丢失問題。
對于寫請求，都會轉發給主節點實作，這要求B域中的Schema Registry執行個體開通和A域中的Schema Registry執行個體之間的網絡關系；對于讀請求，節點要緩存Schema資料，需要和底層的存儲通信，這要求B域中的Schema Registry執行個體開通和A域中的Kafka Broker節點之間的網絡關系，讀請求是增量擷取，跨域請求對網絡流量的影響也會比較小。
針對單個域的Kafka叢集故障或機房故障，資料本身的備份可以通過同步工具完成，由于Schema Registry底層的存儲也是一個topic，它的資料也可以通過這種方式備份。在主節點叢集出現問題時，我們可以通過腳本去實作參數的一鍵切換，進而保證服務的可用性。
以上是整個Schema Registry的跨域災備方案。
我們使用的Schema Registry是Confluent的開源版本，在光大銀行的系統整合過程中，進行了一些改造，主要包括兩個方面：
- 安全&權限：這是将開源系統內建到企業内部所必需的改進之一，是以Schema Registry的實作充分考慮到這點，為使用者提供了标準的插件接口。我們基于這個接口實作了一個RBAC鑒權機制，確定服務的安全性，同時還增加了審計日志，以便進行使用者請求的跟蹤。
- 運維：我們先将服務與Kerberos整合，再把服務的内部名額和行内監控系統進行了打通。上圖是測試環境的示例，由于Schema Registry服務本身對高可用性要求較高，我們在監控和報警方面前期做了很多工作，未來也将不斷優化。
2）SDK封裝
我們對Kafka用戶端所做的二次開發做了SDK封裝，提供統一的用戶端接口，解決了以下問題：
- 減少不同用戶端版本帶來的性能差異和穩定性問題；
- 友善更新管理、災備切換等；
- 更好地規範用戶端行為，增強對用戶端的資料面控制。
在上圖右側，我們展示了SDK已經實作及計劃實作的特性，下面重點介紹下消費定制化這一特性。
如圖所示，在消費定制化的使用場景中，某個生産者寫入的某個資料，在下遊可能并不是關心的，以訂單資料為例，有些業務可能隻關心訂單的流轉狀态，有些業務隻關心下單後的物流資訊。是以，在大部分情況下，下遊消費資料隻是上遊寫入資料的一個子集，不同的消費者子集也可能不同。
基于這些場景，我們實作了消費定制化訂閱的特性，将業務真正關心的schema托管到我們自研的Schema Manager服務中，在SDK消費時，可以提供給下遊業務真正關心的資料，進而滿足不同消費者的不同資料需求。
該特性的對外暴露由SDK封裝實作，底層依賴于Schema Registry和Schema Manager，其中Schema Registry實作了用于中心化托管和對外服務的schema寫入，而Schema Manager實作了使用者自定義schema的中心化托管和對外服務，在SDK側，我們實作了和這兩個服務之間的互動，及自定義schema的擷取，并完成底層異常情況的處理以及消費資料的抽取。
上圖展示了消費定制化特性的處理流程，其核心實作有兩個方面：
一是實作了和Schema Manager之間互動及容錯的能力，并且提供給用戶端調整能力，實作了一層緩存以提高效率。在未來，我們将考慮在用戶端中實作checkpoint機制，以提高可用性。
二是實作了基于讀schema解析時的相容性，對于一些字段的偏差，我們可以自動處理，并提供給業務一些常用比對政策的配置。
3）可觀測性&可視化
最後介紹一些我們在觀測性和可視化方面做的事情。
首先，我們對Kafka進行了全面的監控。之前，我們發現基于Kafka的機制的産品端監控粒度比較低，且缺失很多關鍵名額，如Kafka服務端網絡請求處理線程的繁忙率，業務側消費延遲等。是以，我們結合Kafka本身的名額以及我們内部的雲原生監控體系，實作了更細粒度的監控報警方案，以更好地掌握Kafka的狀态。
其次，我們還開發了服務控制台。前面我們提到，通過Schema Registry我們可以将schema的中心化存儲。但是，這種資料并不是一種結構化的存儲，這就需要我們通過控制台進行可視化的管理。自定義的schema也通過控制台去完成建立、更新和删除的操作。下面的圖展示了一個租戶自定義schema清單的示例。
三、總結&未來規劃
1、總結
通過結合大資料領域新興技術，我們對整個平台進行了拆分，解決了多項問題，目前準實時資料平台實作了以下收益：
1）更清晰的平台邊界；
2）覆寫分鐘級實時貼源資料場景；
3）資料服務總線生态建設；
4）提升了運維和營運能力。
2、未來規劃
1）實時資料湖
實時資料湖平台目前處于持續落地階段，未來我們将持續遷移适用于分鐘級實時資料庫的全部貼源場景，同時探索基于行業經驗的湖倉一體和流批一體場景。
2）資料服務總線
- 持續圍繞消息中間件生态進行拓展，基于SDK實作用戶端的災備切換功能，并結合服務端的災備，共同實作平台級别的災備方案；
- 由于總線的上下遊接口的一個重要計算架構是Flink Connector，是以我們将基于它進行二次開發，實作部分核心功能，為接入的業務提供統一的體驗；
- 除增強用戶端接入能力外，我們将積極開發管理控制台，将一些重要的Kafka運維操作和服務部分營運能力整合到我們的控制台上，以提高整體的運維和營運效率；
- 着手計劃長期的信創叢集建設。
關于我們
dbaplus社群是圍繞Database、BigData、AIOps的企業級專業社群。資深大咖、技術幹貨，每天精品原創文章推送，每周線上技術分享，每月線下技術沙龍，每季度Gdevops&DAMS行業大會。
關注公衆号【dbaplus社群】，擷取更多原創技術文章和精選工具下載下傳