一、網(wǎng)易云音樂實時數(shù)倉架構(gòu)

首先，從四個方面介紹云音樂的實時數(shù)倉架構(gòu)：云音樂的實時場景、實時數(shù)倉架構(gòu)、技術(shù)架構(gòu)以及技術(shù)選型。

1、云音樂的實時場景

目前云音樂的實時場景主要分為以下三個部分，如圖：

（1）實時特征

該場景主要是配合算法團隊構(gòu)建實時特征。實時數(shù)據(jù)作為推薦、搜索社區(qū)的數(shù)據(jù)輸入，主要用于歌曲推薦、搜索熱度、場景排序、新歌熱歌推廣等場景。其次，針對首頁和搜索流量分發(fā)場景，為了提升流量的轉(zhuǎn)化效率，可以對不同用戶進行個性化的場景排序，如：偏向于聽歌的用戶會把推薦歌曲模塊放在上面、偏向于聽有聲書的則將播客模塊置頂?shù)龋瑥亩嵘脩舻牧髁哭D(zhuǎn)化效率。

（2）場景監(jiān)控

主要針對于資源投放效果和 AB 實時效果。實時和準實時的反饋可以盡早提醒業(yè)務運營或者業(yè)務中后臺了解投放效果如何等。如果效果未達到預期，業(yè)務同學就有更充足的時間來分析其中的原因并進行調(diào)整。還有在針對機械刷歌和刷紅心點贊的行為時，實時風控可以發(fā)現(xiàn)異常用戶，并采取賬號封禁或無效流量分流等策略，防止這類臟數(shù)據(jù)進入到業(yè)務數(shù)據(jù)，影響下游數(shù)據(jù)分析的準確性。

（3）數(shù)據(jù)產(chǎn)品

即實時大屏。通過實時大屏向管理層提供當天的流量轉(zhuǎn)化和業(yè)務增長等最直觀的數(shù)據(jù)表現(xiàn)。并且實時的用戶分析、歌曲表現(xiàn)分析、活動分析、場景分析等特征數(shù)據(jù)作為業(yè)務輸入，可以讓運營有數(shù)據(jù)可依，從而更有效的進行精準推歌、活動運營，防止用戶流失。

2、實時數(shù)倉架構(gòu)

針對以上這些場景，云音樂構(gòu)建了一套基于維度建模的實時數(shù)倉架構(gòu)模型，如圖：

（1）日志采集層（ODS）：

接收來自日志服務器和業(yè)務服務器的原始流量數(shù)據(jù)以及業(yè)務數(shù)據(jù)庫的 binlog 日志，作為實時數(shù)倉中間層的輸入。

（2）數(shù)倉中間層（CDM）：

實時數(shù)倉中間層根據(jù)日志采集層的數(shù)據(jù)進行清洗和解析形成流量中間層和業(yè)務明細中間層。目前流量中間層只對基于埋點的公共屬性進行解析，而對于業(yè)務的個性化場景不會進行處理。原因在于實時數(shù)倉包含了主站所有的流量數(shù)據(jù)，業(yè)務直接使用的成本較高。即使流量中間層會基于各垂類場景進行分區(qū)分流，但例如會員這類橫向業(yè)務場景仍然需要讀取所有的垂類業(yè)務來獲取全量數(shù)據(jù)。為了解決此類問題，云音樂構(gòu)建了相應的業(yè)務明細中間層，進行個性化業(yè)務參數(shù)解析和流量聚焦。因此在基礎流量中間層的基礎上又構(gòu)建了相關(guān)場景的業(yè)務明細中間層。比如：搜索中間層、直播中間層以及社區(qū)中間層等。

（3）數(shù)據(jù)應用層（ADS）：

在離線數(shù)倉架構(gòu)中，為了提升數(shù)據(jù)的復用度一般會構(gòu)建 DWS 輕度匯總層，但在實時場景中因為流式計算的特性，輕度匯總層存在的意義就有待商榷了。

不過近些年來由于 ClickHouse 等 OLAP 引擎的興起，部分實時場景為了高擴展性，更偏向于基于明細數(shù)據(jù)進行查詢，而非直接查詢計算結(jié)果。在這類場景下，通過 OLAP 引擎構(gòu)建 DWS 表，則可以大大降低 OLAP 的存儲量和前臺業(yè)務的計算成本。應用層的數(shù)據(jù)基本上都是基于中間層聚合生成，應用服務可以直接讀取這些數(shù)據(jù)，主要用于相關(guān)數(shù)據(jù)產(chǎn)品算法模型的輸入、業(yè)務產(chǎn)品展示等。

（4）業(yè)務決策層：

基于構(gòu)建的 ADS 表進行相關(guān)業(yè)務分析決策，并應用于推薦算法、實時風控和精準推歌等場景。

3、技術(shù)架構(gòu)

云音樂的實時數(shù)倉技術(shù)架構(gòu)基本上和目前大多數(shù)大廠的實時數(shù)倉技術(shù)架構(gòu)類似，如圖：

在離線場景下，基于 Spark + Hive 架構(gòu)來實現(xiàn)。在實時場景中從 ODS 層到 CDM 層是通過 Flink + Kafka 的模式實現(xiàn)。從 CDM 層到 ADS 層，準實時場景是 Impala + Kudu 或者 ClickHouse 存儲引擎，來支持 OLAP 即席查詢。

4、技術(shù)選型

云音樂的實時數(shù)倉技術(shù)選型也是經(jīng)過了場景適配、成本評估等一系列調(diào)研后才得出結(jié)論，主要有三條鏈路。這三條鏈路主要是基于業(yè)務對于時效性保障、穩(wěn)定性、可擴展性和普適性的取舍。

（1）秒級實時需求

針對于大屏類和業(yè)務算法類需求，這部分場景對于更新頻率、延時性要求極高。比如實時大屏要求看到秒級的數(shù)據(jù)變動、算法團隊要求看到 5 分鐘級別的用戶特征更新。這類場景基本無法通過準實時鏈路來實現(xiàn)。因此這類場景的需求會通過 Flink 進行增量或全量計算，將結(jié)果數(shù)據(jù)寫入 Redis、HBase 或 MySQL 等可以直接查詢的業(yè)務數(shù)據(jù)源中。這類任務基本上都是優(yōu)先級較高的實時任務，需要重點保障。因此還需要進行全鏈路多備份，防止由于集群問題對大屏數(shù)據(jù)或者業(yè)務數(shù)據(jù)產(chǎn)生影響。這類任務的消耗和異常的修復成本都是非常高的，所以需要盡量保證其高可用。

（2）準實時類數(shù)據(jù)產(chǎn)品

這類主要是 5min 以上的時效性需求，可以充分利用 OLAP 分析工具，通過 Flink 將明細數(shù)據(jù)寫入到 ClickHouse、Kudu 或者 Hive 中。然后通過 ClickHouse、Impala 等 OLAP 引擎進行查詢或者分鐘級別的調(diào)度，實現(xiàn)數(shù)據(jù)計算。因為這套方案操作的是明細數(shù)據(jù)，因此較前一種場景的可擴展性會更強，但是由于需要通過 OLAP 引擎進行即席查詢，這類產(chǎn)品一般需要進行新的技術(shù)棧探索，普適性比較弱，學習成本較高，分析師通常不會使用這種模式來進行數(shù)據(jù)分析。

（3）準實時類數(shù)據(jù)分析

這類場景對于時效性的要求會更低，一般是 2 小時以上的數(shù)據(jù)延遲。通過 DS 采集和 Hive+Spark 生成一套準實時的、小時級別的數(shù)據(jù)，通過批處理鏈路進行調(diào)度計算。該鏈路無其他特殊的技術(shù)棧，可以直接提供給分析師來使用，適配的分析場景也更多。并且可以將復雜的解析邏輯和清洗過程放到小時任務中，T+1 的離線任務基于小時產(chǎn)出數(shù)據(jù)合并獲取，可以大大提升離線基礎表的產(chǎn)出效率。

二、網(wǎng)易云音樂流批模型一致性

1、Lambda 架構(gòu)

在構(gòu)建實時數(shù)倉時，一般都會有相對應的離線數(shù)倉。主要用于歷史數(shù)據(jù)的回刷以及更為復雜的場景支持，這樣難免就會存在兩條鏈路進行計算，流鏈路和批鏈路，這也就是我們常說的 Lambda 架構(gòu)。

當天的數(shù)據(jù)會通過流計算任務處理生成實時表提供數(shù)據(jù)接口給數(shù)據(jù)應用。歷史數(shù)據(jù)會通過批計算，生成離線表提供給數(shù)據(jù)服務。

實時和離線兩套方案獨立存在，這時可能會造成數(shù)據(jù)模型不一致的情況。云音樂大部分場景通過字段名稱統(tǒng)一和表名統(tǒng)一來保證實時模型和離線模型的一致性。但是針對分區(qū)模型的話，實時場景比較難處理。

例如實時數(shù)倉中用戶行為日志產(chǎn)生的信息通過 DS 采集寫入到 Kafka 中，作為實時數(shù)倉的 ODS 層輸入，并且還有一份會寫入到 HDFS 中作為離線數(shù)倉的 ODS 層輸入。通過實時數(shù)倉還有離線數(shù)倉的中間層解析操作生成流量中間層。

但是因為流量中間層的數(shù)據(jù)量過大，不可避免的需要對流量進行分區(qū)分流操作。在離線側(cè)進行分區(qū)是比較容易的，可以通過 Hive 進行目錄級別的分區(qū)，然后將數(shù)據(jù)文件動態(tài)的寫入到分區(qū)目錄中，通過 Hive 的元數(shù)據(jù)進行管理。而在實時側(cè)則只能通過 Kafka topic 進行物理分區(qū)，通過手工維護映射規(guī)則。這樣會存在一些問題：第一，通過文檔維護 topic，維護成本非常高；第二，用戶同樣需要知道他們需要的信息是來自哪個 topic，用戶的開發(fā)成本和使用成本也非常高。

因此針對這個實時場景分區(qū)難維護的問題，網(wǎng)易云音樂搭建了一套 Kafka 的分區(qū)流表。具體模型如下圖：

分區(qū)流表內(nèi)部維護了一整套的分區(qū)字段到 Kafka 物理 topic 的映射規(guī)則。寫入側(cè)和讀取側(cè)是無需要關(guān)注這套規(guī)則的，只需要按照離線表的動態(tài)寫入規(guī)則來進行開發(fā)即可，分區(qū)流表會基于這些規(guī)則進行相關(guān)的轉(zhuǎn)換和映射。

下面介紹下云音樂分區(qū)流表在具體實現(xiàn)上做的優(yōu)化：

（1）分區(qū)映射管理。平臺提供了分區(qū)流表的分區(qū)管理機制，用戶在建表過程中可以指定實時表為分區(qū)流表，并將分區(qū)值和物理 Topic 進行綁定。平臺元數(shù)據(jù)管理中心則基于用戶配置信息將分區(qū)流表構(gòu)建成一個內(nèi)存表，以便能夠快速獲取符合條件的物理 Topic。

（2）分區(qū)讀寫路由。為了支持分區(qū)路由，云音樂重寫了 table source 和 table sink。在寫入側(cè)基于分區(qū)字段值自動匹配其對應的物理 Kafka topic。在讀取側(cè)則會根據(jù) where 條件中的分區(qū)條件字段對分區(qū)進行剪枝，并將剪枝條件推向元數(shù)據(jù)管理中心，元數(shù)據(jù)管理中心通過查詢內(nèi)存表，將符合條件的 Topic 返回給讀取側(cè)以達到讀取部分分區(qū)的效果。

（3）邊界情況優(yōu)化。為了提升計算效率和任務穩(wěn)定性，云音樂進行了一系列的優(yōu)化操作。在寫入和讀取時，可以配置默認的 Topic，對于那些沒有命中配置分區(qū)的記錄將會被寫入到默認 Topic 中，這樣可以降低分區(qū)創(chuàng)建的復雜度，并可以對默認分區(qū)進行監(jiān)控，按需進行單獨分區(qū)或者動態(tài)分區(qū)擴展。分區(qū)流表還支持多個分區(qū)字段指向同一個Topic，以防止 Topic 數(shù)的急劇擴張，雖然這樣可能會導致下游實際讀取的數(shù)據(jù)量會比單分區(qū)單 Topic 模式有所增長，但是平臺通過優(yōu)化分區(qū)字段匹配機制降低下游讀取時的反序列化成本，極大提升了下游的計算效率。即便有這種優(yōu)化機制，分區(qū)流表創(chuàng)建者仍需要考慮 Topic 數(shù)和下游使用便利性的平衡。

（4）動態(tài)分區(qū)架構(gòu)。以上方案均是針對靜態(tài)分區(qū)機制，即在分區(qū)流表創(chuàng)建之后基本不會發(fā)生分區(qū)的新增和變化，或者只能通過上下游通知重啟來感知分區(qū)變化。靜態(tài)分區(qū)機制基本能滿足 90% 的實時場景。然而可能存在部分業(yè)務場景變化較快，可能頻繁進行分區(qū)擴增、更改，這樣會造成維護成本升高?；谶@方面的考慮，云音樂提出了動態(tài)分區(qū)的思想和技術(shù)實現(xiàn)。以下是動態(tài)分區(qū)技術(shù)架構(gòu)：

整個架構(gòu)的前半部分和靜態(tài)分區(qū)是大致相同的，主要區(qū)別在于應對規(guī)則變更的實現(xiàn)流程。平臺通過引入 ZooKeeper 進行監(jiān)聽分區(qū)流表的變更，來實現(xiàn)所有依賴的統(tǒng)一變更。當存在分區(qū)新增/修改時，Zookeeper 將會觸發(fā)分區(qū)流表上下游進行狀態(tài)快照，保存修改前的分區(qū)信息、消費時間戳信息。然后針對之后的所有記錄，寫入端對比該記錄時間戳和修改分區(qū)時間戳，如果在修改分區(qū)之后，將寫入新的分區(qū)中；讀取端則是會按照修改時間戳拉取新增 Topic，基于事件時間和分區(qū)時間判斷消費數(shù)據(jù)。并且為了保證規(guī)則的一致性，平臺引入了兩階段的通知機制，確保規(guī)則同時生效和同時回滾，實現(xiàn)鏈路的冪等性。目前該方案還在測試和驗證階段，功能暫未上線。

三、網(wǎng)易云音樂低代碼實踐

1、計算一致性問題

云音樂分區(qū)流表的實現(xiàn)基本確保了實時模型和離線模型的一致性，但是由于計算鏈路的差異還是不能保證實時和離線計算的一致性?；谠搯栴}，云音樂也進行深入的探究和思考。

目前，針對于計算邏輯一致性的解決方案大致有三類：Kappa 架構(gòu)、DataPhin 平臺和低代碼平臺。

（1）Kappa 架構(gòu)：目前 Kappa 架構(gòu)不太適用于云音樂的場景。大數(shù)據(jù)量的回刷、Flink 吞吐量的受限以及差業(yè)務異化的無法處理，很難滿足目前云音樂的場景。

（2）DataPhin 平臺：強依賴 Flink 技術(shù)棧的開發(fā)。Filnk 的維護成本和學習成本較高，對于剛接觸流計算的同學而言還是有一定學習成本的。并且很難保證批任務計算資源的充足。

（3）低代碼平臺：目前云音樂采用的技術(shù)方案。主要通過可視化、組件化和配置化將數(shù)據(jù)開發(fā)進行退化，來依托于平臺。從而極大的釋放生產(chǎn)力：數(shù)據(jù)開發(fā)可以更專注于數(shù)據(jù)中間層和數(shù)據(jù)資產(chǎn)的建設、數(shù)據(jù)分析師可以更專注于指標的開發(fā)和看板的搭建、數(shù)據(jù)運營和產(chǎn)品可以在不依托于數(shù)據(jù)開發(fā)的前提下來進行需求任務創(chuàng)建。

2、現(xiàn)狀問題

目前云音樂的實時、離線數(shù)倉主要存在于以下四類問題：

（1）數(shù)據(jù)模型：在模型設計階段標準、規(guī)范很難統(tǒng)一，并且在已有標準的情況下是很難按標準實施。并且即使數(shù)倉同學維護了較全面的白皮書文檔，但在向分析師和運營的同學推廣時也遇到了比較大的阻力，導致數(shù)倉構(gòu)建的比較好用的寬表不能為業(yè)務輸出相應的能力。

（2）計算模型：由于業(yè)務提供的指標口徑是在不同業(yè)務場景下定義的，導致指標口徑不一致且復雜混亂。

（3）實時和離線開發(fā)：由于技術(shù)棧和支撐場景的差異化，導致開發(fā)成本、運維成本較高，并且數(shù)據(jù)一致性較難保證。

（4）資產(chǎn)評估：目前實時數(shù)倉還沒有一套體系化的方案來定位問題，問題的排查比較困難、解決鏈路較長。并且，由于數(shù)據(jù)資產(chǎn)的不完備，也很難量化實時模型的價值。

3、FastX 架構(gòu)

為了解決上述的問題，實現(xiàn)流批場景的計算一致性，云音樂數(shù)據(jù)平臺構(gòu)建了 FastX 平臺。下面和大家分享下 FastX 架構(gòu)實現(xiàn)。首先我會對 FastX 的各層職能進行簡單介紹，然后再分別從模型化、組件化、配置化、服務化血緣化介紹 FastX 的具體架構(gòu)思想。

模型層：數(shù)據(jù)模型管理、指標管理。

配置層：用戶可以配置對應數(shù)據(jù)模型的輸入、輸出以及相關(guān)的計算模型。

執(zhí)行層：將任務轉(zhuǎn)換成 Spark 或者 Flink 可執(zhí)行的調(diào)度。

運維層：主要職責監(jiān)控、報警。

服務層：外部應用通過 API 訪問數(shù)據(jù)模型，提供數(shù)據(jù)服務。

以上就是 FastX 的架構(gòu)各層的主要職能，下面和大家分享下 FastX 抽象后的各個部分主要功能：

（1）模型化：

FastX 是基于模型化進行開發(fā)、管理的。數(shù)據(jù)模型是 Fastx 的唯一出口。目前 

FastX 數(shù)據(jù)模型包含三類：

視圖模型：實時流表和離線天表的映射，作為寫到 FastX 任務的輸入。

AB 模型：優(yōu)化 AB 場景的數(shù)據(jù)開發(fā)和指標管理。

關(guān)系模型：維護了實時和離線的開發(fā)任務，指向?qū)崟r場景和離線場景的物理存儲。

（2）FastX- 組件化：

FastX 將數(shù)據(jù)模型內(nèi)部定義了一整套的組件化開發(fā)模型，將任務抽象為輸入、輸出和計算模型，通過拖拉拽的形式實現(xiàn)任務的開發(fā)。通過組件化的自適應能力，用戶可以不用關(guān)心是否需要流場景或者批場景、數(shù)據(jù)來自哪里或者去哪里，這些 FastX 都會自動識別。

（3）FastX -配置化：

配置化主要是在開發(fā)的易用性方面的優(yōu)化處理，例如：

針對 Binlog 實時同步場景，通過可視化的配置，實現(xiàn) Binlog 的解析和 Topic 的訂閱，極大的減少了開發(fā)成本和使用成本；

針對于 ClickHouse sink 場景，由于 ck 的 sql 語法與其他 RDBMS 語法差異較大，并且使用上也存在很多不同。為了減輕學習成本，F(xiàn)astX 在簡化 ck 的使用上做出了很大的努力。例如，提供了一鍵式建表工具，用戶只需要根據(jù)實際場景配置索引和分區(qū)就可以一鍵生成建表 sql；針對離線和實時數(shù)據(jù)的回刷場景提供了一鍵式數(shù)據(jù)切換；針對分區(qū)表和非分區(qū)表自適應選擇底層的實現(xiàn)邏輯，防止線上數(shù)據(jù)跌 0 的情況；針對于寫入端，F(xiàn)astX 實現(xiàn)了自定義 shard 寫入模型，通過 Flink 進行 Hash 分流將數(shù)據(jù)直接寫入 ck 的本地表，減輕了 ck 的代理壓力。

針對于 AB 開發(fā)場景，與 AB 實驗平臺進行打通，支持 AB 實驗平臺的指標一鍵式導入，并且可以進行批量口徑管理，降低 AB 實驗開發(fā)復雜度。將 AB 任務轉(zhuǎn)化為指標口徑錄入，使得實時指標開發(fā)無需數(shù)據(jù)開發(fā)介入，產(chǎn)品、分析師等都可以通過指標錄入完成實時 AB 任務開發(fā)。

（4）FastX- 服務化血緣化：

由于 FastX 可以作為數(shù)據(jù)源進行數(shù)據(jù)模型的輸入的特性，因此可以根據(jù)外部的調(diào)用情況來評估數(shù)據(jù)模型的價值。并且數(shù)據(jù)模型還可以通過任務和服務調(diào)用情況構(gòu)建數(shù)據(jù)模型和應用的血緣關(guān)系圖，還作為模型治理和成本優(yōu)化的后期依據(jù)。

四、未來規(guī)劃

云音樂實時數(shù)倉之后將圍繞以下內(nèi)容進行繼續(xù)探索：

1、鞏固基建

利用 FastX 的數(shù)據(jù)模型和血緣關(guān)系進行實時資產(chǎn)的統(tǒng)一管控；

和 FastX 共建多鏈路保障機制。

利用血緣關(guān)系實現(xiàn)實時資產(chǎn)的評估機制。

2、低代碼、流批一體

擴張更多復雜的計算模型。

增加端到端解決方案，屏蔽實現(xiàn)細節(jié)。

構(gòu)建復雜的流批場景。

3、湖倉探索

實時湖倉建設。

五、問答環(huán)節(jié)

Q1：指標計算在錄入時就要確定嗎？

A1：指標管理和計算任務是解耦的，指標需求可以先提出，然后進行開發(fā)。最后在指標錄入的階段將指標口徑進行錄入，不需要依賴指標口徑的錄入來進行需求管理。

Q2：實時數(shù)倉如何支持高可用？

A2：目前通過多集群的配置。例如在大促類需求時，會針對 Flink 集群和底層存儲集群做多集群的配置。如果線上集群出現(xiàn)問題，可以通過一鍵式切換到其他數(shù)據(jù)源，保證數(shù)據(jù)的可用性。切換完成后會對故障集群進行問題排查、修復，完成后再將集群切回主鏈路。

Q3：流批一體化數(shù)據(jù)源都用 binlog 嗎？

A3：binlog 主要適用于關(guān)系型數(shù)據(jù)庫存儲的業(yè)務數(shù)據(jù)，其他類似于流量日志會通過 DS 采集日志服務器中的數(shù)據(jù)，然后直接寫入到 Kafka 中。

Q4：實時和離線數(shù)據(jù)的時間差和數(shù)據(jù)不一致如何核對？

A4：實時計算增加小時級別的計算窗口和離線數(shù)據(jù)保持一致。計算口徑上實時任務和離線任務的口徑是保持一致的，例如通過日志時間來進行計算。

Q5：通過日志生成的時間如何處理晚到數(shù)據(jù)？

A5：實時計算的處理思路基本和離線是一致的，會通過多讀取一段時間的數(shù)據(jù)來保證數(shù)據(jù)的完整性。