01
網易雲音樂實時數倉架構
首先，從四個方面介紹雲音樂的實時數倉架構：雲音樂的實時場景、實時數倉架構、技術架構以及技術選型。
1.雲音樂的實時場景
目前雲音樂的實時場景主要分為以下三個部分，如圖：
（1）實時特征
該場景主要是配合算法團隊建構實時特征。實時資料作為推薦、搜尋社群的資料輸入，主要用于歌曲推薦、搜尋熱度、場景排序、新歌熱歌推廣等場景。其次，針對首頁和搜尋流量分發場景，為了提升流量的轉化效率，可以對不同使用者進行個性化的場景排序，如：偏向于聽歌的使用者會把推薦歌曲子產品放在上面、偏向于聽有聲書的則将播客子產品置頂等，進而提升使用者的流量轉化效率。
（2）場景監控
主要針對于資源投放效果和 AB 實時效果。實時和準實時的回報可以盡早提醒業務營運或者業務中背景了解投放效果如何等。如果效果未達到預期，業務同學就有更充足的時間來分析其中的原因并進行調整。還有在針對機械刷歌和刷紅心點贊的行為時，實時風控可以發現異常使用者，并采取賬号封禁或無效流量分流等政策，防止這類髒資料進入到業務資料，影響下遊資料分析的準确性。
（3）資料産品
即實時大屏。通過實時大屏向管理層提供當天的流量轉化和業務增長等最直覺的資料表現。并且實時的使用者分析、歌曲表現分析、活動分析、場景分析等特征資料作為業務輸入，可以讓營運有資料可依，進而更有效的進行精準推歌、活動營運，防止使用者流失。
2. 實時數倉架構
針對以上這些場景，雲音樂建構了一套基于次元模組化的實時數倉架構模型，如圖：
（1）日志采集層（ODS）：
接收來自日志伺服器和業務伺服器的原始流量資料以及業務資料庫的 binlog 日志，作為實時數倉中間層的輸入。
（2）數倉中間層（CDM）：
實時數倉中間層根據日志采集層的資料進行清洗和解析形成流量中間層和業務明細中間層。目前流量中間層隻對基于埋點的公共屬性進行解析，而對于業務的個性化場景不會進行處理。原因在于實時數倉包含了主站所有的流量資料，業務直接使用的成本較高。即使流量中間層會基于各垂類場景進行分區分流，但例如會員這類橫向業務場景仍然需要讀取所有的垂類業務來擷取全量資料。為了解決此類問題，雲音樂建構了相應的業務明細中間層，進行個性化業務參數解析和流量聚焦。是以在基礎流量中間層的基礎上又建構了相關場景的業務明細中間層。比如：搜尋中間層、直播中間層以及社群中間層等。
（3）資料應用層（ADS）：
在離線數倉架構中，為了提升資料的複用度一般會建構 DWS 輕度彙總層，但在實時場景中因為流式計算的特性，輕度彙總層存在的意義就有待商榷了。
不過近些年來由于 ClickHouse 等 OLAP 引擎的興起，部分實時場景為了高擴充性，更偏向于基于明細資料進行查詢，而非直接查詢計算結果。在這類場景下，通過 OLAP 引擎建構 DWS 表，則可以大大降低 OLAP 的存儲量和前台業務的計算成本。應用層的資料基本上都是基于中間層聚合生成，應用服務可以直接讀取這些資料，主要用于相關資料産品算法模型的輸入、業務産品展示等。
（4）業務決策層：
基于建構的 ADS 表進行相關業務分析決策，并應用于推薦算法、實時風控和精準推歌等場景。
3. 技術架構
雲音樂的實時數倉技術架構基本上和目前大多數大廠的實時數倉技術架構類似，如圖：
在離線場景下，基于 Spark + Hive 架構來實作。在實時場景中從 ODS 層到 CDM 層是通過 Flink + Kafka 的模式實作。從 CDM 層到 ADS 層，準實時場景是 Impala + Kudu 或者 ClickHouse 存儲引擎，來支援 OLAP 即席查詢。
4. 技術選型
雲音樂的實時數倉技術選型也是經過了場景适配、成本評估等一系列調研後才得出結論，主要有三條鍊路。這三條鍊路主要是基于業務對于時效性保障、穩定性、可擴充性和普适性的取舍。
（1）秒級實時需求
針對于大屏類和業務算法類需求，這部分場景對于更新頻率、延時性要求極高。比如實時大屏要求看到秒級的資料變動、算法團隊要求看到 5 分鐘級别的使用者特征更新。這類場景基本無法通過準實時鍊路來實作。是以這類場景的需求會通過 Flink 進行增量或全量計算，将結果資料寫入 Redis、HBase 或 MySQL 等可以直接查詢的業務資料源中。這類任務基本上都是優先級較高的實時任務，需要重點保障。是以還需要進行全鍊路多備份，防止由于叢集問題對大屏資料或者業務資料産生影響。這類任務的消耗和異常的修複成本都是非常高的，是以需要盡量保證其高可用。
（2）準實時類資料産品
這類主要是 5min 以上的時效性需求，可以充分利用 OLAP 分析工具，通過 Flink 将明細資料寫入到 ClickHouse、Kudu 或者 Hive 中。然後通過 ClickHouse、Impala 等 OLAP 引擎進行查詢或者分鐘級别的排程，實作資料計算。因為這套方案操作的是明細資料，是以較前一種場景的可擴充性會更強，但是由于需要通過 OLAP 引擎進行即席查詢，這類産品一般需要進行新的技術棧探索，普适性比較弱，學習成本較高，分析師通常不會使用這種模式來進行資料分析。
（3）準實時類資料分析
這類場景對于時效性的要求會更低，一般是 2 小時以上的資料延遲。通過 DS 采集和 Hive+Spark 生成一套準實時的、小時級别的資料，通過批處理鍊路進行排程計算。該鍊路無其他特殊的技術棧，可以直接提供給分析師來使用，适配的分析場景也更多。并且可以将複雜的解析邏輯和清洗過程放到小時任務中，T+1 的離線任務基于小時産出資料合并擷取，可以大大提升離線基礎表的産出效率。
02
網易雲音樂流批模型一緻性
1. Lambda 架構
在建構實時數倉時，一般都會有相對應的離線數倉。主要用于曆史資料的回刷以及更為複雜的場景支援，這樣難免就會存在兩條鍊路進行計算，流鍊路和批鍊路，這也就是我們常說的 Lambda 架構。
當天的資料會通過流計算任務處理生成實時表提供資料接口給資料應用。曆史資料會通過批計算，生成離線表提供給資料服務。
實時和離線兩套方案獨立存在，這時可能會造成資料模型不一緻的情況。雲音樂大部分場景通過字段名稱統一和表名統一來保證明時模型和離線模型的一緻性。但是針對分區模型的話，實時場景比較難處理。
例如實時數倉中使用者行為日志産生的資訊通過 DS 采集寫入到 Kafka 中，作為實時數倉的 ODS 層輸入，并且還有一份會寫入到 HDFS 中作為離線數倉的 ODS 層輸入。通過實時數倉還有離線數倉的中間層解析操作生成流量中間層。
但是因為流量中間層的資料量過大，不可避免的需要對流量進行分區分流操作。在離線側進行分區是比較容易的，可以通過 Hive 進行目錄級别的分區，然後将資料檔案動态的寫入到分區目錄中，通過 Hive 的中繼資料進行管理。而在實時側則隻能通過 Kafka topic 進行實體分區，通過手工維護映射規則。這樣會存在一些問題：第一，通過文檔維護 topic，維護成本非常高；第二，使用者同樣需要知道他們需要的資訊是來自哪個 topic，使用者的開發成本和使用成本也非常高。
是以針對這個實時場景分區難維護的問題，網易雲音樂搭建了一套 Kafka 的分區流表。具體模型如下圖：
分區流表内部維護了一整套的分區字段到 Kafka 實體 topic 的映射規則。寫入側和讀取側是無需要關注這套規則的，隻需要按照離線表的動态寫入規則來進行開發即可，分區流表會基于這些規則進行相關的轉換和映射。
下面介紹下雲音樂分區流表在具體實作上做的優化：
（1）分區映射管理。平台提供了分區流表的分區管理機制，使用者在建表過程中可以指定實時表為分區流表，并将分區值和實體 Topic 進行綁定。平台中繼資料管理中心則基于使用者配置資訊将分區流表建構成一個記憶體表，以便能夠快速擷取符合條件的實體 Topic。
（2）分區讀寫路由。為了支援分區路由，雲音樂重寫了 table source 和 table sink。在寫入側基于分區字段值自動比對其對應的實體 Kafka topic。在讀取側則會根據 where 條件中的分區條件字段對分區進行剪枝，并将剪枝條件推向中繼資料管理中心，中繼資料管理中心通過查詢記憶體表，将符合條件的 Topic 傳回給讀取側以達到讀取部分分區的效果。
（3）邊界情況優化。為了提升計算效率和任務穩定性，雲音樂進行了一系列的優化操作。在寫入和讀取時，可以配置預設的 Topic，對于那些沒有命中配置分區的記錄将會被寫入到預設 Topic 中，這樣可以降低分區建立的複雜度，并可以對預設分區進行監控，按需進行單獨分區或者動态分區擴充。分區流表還支援多個分區字段指向同一個Topic，以防止 Topic 數的急劇擴張，雖然這樣可能會導緻下遊實際讀取的資料量會比單分區單 Topic 模式有所增長，但是平台通過優化分區字段比對機制降低下遊讀取時的反序列化成本，極大提升了下遊的計算效率。即便有這種優化機制，分區流表建立者仍需要考慮 Topic 數和下遊使用便利性的平衡。
（4）動态分區架構。以上方案均是針對靜态分區機制，即在分區流表建立之後基本不會發生分區的新增和變化，或者隻能通過上下遊通知重新開機來感覺分區變化。靜态分區機制基本能滿足 90% 的實時場景。然而可能存在部分業務場景變化較快，可能頻繁進行分區擴增、更改，這樣會造成維護成本升高。基于這方面的考慮，雲音樂提出了動态分區的思想和技術實作。以下是動态分區技術架構：
整個架構的前半部分和靜态分區是大緻相同的，主要差別在于應對規則變更的實作流程。平台通過引入 ZooKeeper 進行監聽分區流表的變更，來實作所有依賴的統一變更。當存在分區新增/修改時，Zookeeper 将會觸發分區流表上下遊進行狀态快照，儲存修改前的分區資訊、消費時間戳資訊。然後針對之後的所有記錄，寫入端對比該記錄時間戳和修改分區時間戳，如果在修改分區之後，将寫入新的分區中；讀取端則是會按照修改時間戳拉取新增 Topic，基于事件時間和分區時間判斷消費資料。并且為了保證規則的一緻性，平台引入了兩階段的通知機制，確定規則同時生效和同時復原，實作鍊路的幂等性。目前該方案還在測試和驗證階段，功能暫未上線。
03
網易雲音樂低代碼實踐
1. 計算一緻性問題
雲音樂分區流表的實作基本確定了實時模型和離線模型的一緻性，但是由于計算鍊路的差異還是不能保證明時和離線計算的一緻性。基于該問題，雲音樂也進行深入的探究和思考。
目前，針對于計算邏輯一緻性的解決方案大緻有三類：Kappa 架構、DataPhin 平台和低代碼平台。
（1）Kappa 架構：目前 Kappa 架構不太适用于雲音樂的場景。大資料量的回刷、Flink 吞吐量的受限以及差業務異化的無法處理，很難滿足目前雲音樂的場景。
（2）DataPhin 平台：強依賴 Flink 技術棧的開發。Filnk 的維護成本和學習成本較高，對于剛接觸流計算的同學而言還是有一定學習成本的。并且很難保證批任務計算資源的充足。
（3）低代碼平台：目前雲音樂采用的技術方案。主要通過可視化、元件化和配置化将資料開發進行退化，來依托于平台。進而極大的釋放生産力：資料開發可以更專注于資料中間層和資料資産的建設、資料分析師可以更專注于名額的開發和看闆的搭建、資料營運和産品可以在不依托于資料開發的前提下來進行需求任務建立。
2. 現狀問題
目前雲音樂的實時、離線數倉主要存在于以下四類問題：
（1）資料模型：在模型設計階段标準、規範很難統一，并且在已有标準的情況下是很難按标準實施。并且即使數倉同學維護了較全面的白皮書文檔，但在向分析師和營運的同學推廣時也遇到了比較大的阻力，導緻數倉建構的比較好用的寬表不能為業務輸出相應的能力。
（2）計算模型：由于業務提供的名額口徑是在不同業務場景下定義的，導緻名額口徑不一緻且複雜混亂。
（3）實時和離線開發：由于技術棧和支撐場景的差異化，導緻開發成本、運維成本較高，并且資料一緻性較難保證。
（4）資産評估：目前實時數倉還沒有一套體系化的方案來定位問題，問題的排查比較困難、解決鍊路較長。并且，由于資料資産的不完備，也很難量化實時模型的價值。
3. FastX 架構
為了解決上述的問題，實作流批場景的計算一緻性，雲音樂資料平台建構了 FastX 平台。下面和大家分享下 FastX 架構實作。首先我會對 FastX 的各層職能進行簡單介紹，然後再分别從模型化、元件化、配置化、服務化血緣化介紹 FastX 的具體架構思想。
模型層：資料模型管理、名額管理。
配置層：使用者可以配置對應資料模型的輸入、輸出以及相關的計算模型。
執行層：将任務轉換成 Spark 或者 Flink 可執行的排程。
運維層：主要職責監控、報警。
服務層：外部應用通過 API 通路資料模型，提供資料服務。
以上就是 FastX 的架構各層的主要職能，下面和大家分享下 FastX 抽象後的各個部分主要功能：
（1）模型化：
FastX 是基于模型化進行開發、管理的。資料模型是 Fastx 的唯一出口。目前
FastX 資料模型包含三類：
視圖模型：實時流表和離線天表的映射，作為寫到 FastX 任務的輸入；
AB 模型：優化 AB 場景的資料開發和名額管理；
關系模型：維護了實時和離線的開發任務，指向實時場景和離線場景的實體存儲。
（2）FastX- 元件化：
FastX 将資料模型内部定義了一整套的元件化開發模型，将任務抽象為輸入、輸出和計算模型，通過拖拉拽的形式實作任務的開發。通過元件化的自适應能力，使用者可以不用關心是否需要流場景或者批場景、資料來自哪裡或者去哪裡，這些 FastX 都會自動識别。
（3）FastX -配置化：
配置化主要是在開發的易用性方面的優化處理，例如：
針對 Binlog 實時同步場景，通過可視化的配置，實作 Binlog 的解析和 Topic 的訂閱，極大的減少了開發成本和使用成本；
針對于 ClickHouse sink 場景，由于 ck 的 sql 文法與其他 RDBMS 文法差異較大，并且使用上也存在很多不同。為了減輕學習成本，FastX 在簡化 ck 的使用上做出了很大的努力。例如，提供了一鍵式建表工具，使用者隻需要根據實際場景配置索引和分區就可以一鍵生成建表 sql；針對離線和實時資料的回刷場景提供了一鍵式資料切換；針對分區表和非分區表自适應選擇底層的實作邏輯，防止線上資料跌 0 的情況；針對于寫入端，FastX 實作了自定義 shard 寫入模型，通過 Flink 進行 Hash 分流将資料直接寫入 ck 的本地表，減輕了 ck 的代理壓力。
針對于 AB 開發場景，與 AB 實驗平台進行打通，支援 AB 實驗平台的名額一鍵式導入，并且可以進行批量口徑管理，降低 AB 實驗開發複雜度。将 AB 任務轉化為名額口徑錄入，使得實時名額開發無需資料開發介入，産品、分析師等都可以通過名額錄入完成實時 AB 任務開發。
（4）FastX- 服務化血緣化：
由于 FastX 可以作為資料源進行資料模型的輸入的特性，是以可以根據外部的調用情況來評估資料模型的價值。并且資料模型還可以通過任務和服務調用情況建構資料模型和應用的血緣關系圖，還作為模型治理和成本優化的後期依據。
04
未來規劃
雲音樂實時數倉之後将圍繞以下内容進行繼續探索：
1. 鞏固基建
利用 FastX 的資料模型和血緣關系進行實時資産的統一管控；
和 FastX 共建多鍊路保障機制；
利用血緣關系實作實時資産的評估機制。
2. 低代碼、流批一體
擴張更多複雜的計算模型；
增加端到端解決方案，屏蔽實作細節；
建構複雜的流批場景。
3. 湖倉探索
實時湖倉建設。