一、網易云音樂實時數倉架構
首先，從四個方面介紹云音樂的實時數倉架構：云音樂的實時場景、實時數倉架構、技術架構以及技術選型。
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 的離線任務基于小時產出數據合并獲取，可以大大提升離線基礎表的產出效率。
二、網易云音樂流批模型一致性
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，基于事件時間和分區時間判斷消費數據。并且為了保證規則的一致性，平臺引入了兩階段的通知機制，確保規則同時生效和同時回滾，實現鏈路的冪等性。目前該方案還在測試和驗證階段，功能暫未上線。
三、網易云音樂低代碼實踐
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 可以作為數據源進行數據模型的輸入的特性，因此可以根據外部的調用情況來評估數據模型的價值。并且數據模型還可以通過任務和服務調用情況構建數據模型和應用的血緣關系圖，還作為模型治理和成本優化的后期依據。
四、未來規劃
云音樂實時數倉之后將圍繞以下內容進行繼續探索：
1、鞏固基建
利用 FastX 的數據模型和血緣關系進行實時資產的統一管控；
和 FastX 共建多鏈路保障機制。
利用血緣關系實現實時資產的評估機制。
2、低代碼、流批一體
擴張更多復雜的計算模型。
增加端到端解決方案，屏蔽實現細節。
構建復雜的流批場景。
3、湖倉探索
實時湖倉建設。
五、問答環節
Q1：指標計算在錄入時就要確定嗎？
A1：指標管理和計算任務是解耦的，指標需求可以先提出，然后進行開發。最后在指標錄入的階段將指標口徑進行錄入，不需要依賴指標口徑的錄入來進行需求管理。
Q2：實時數倉如何支持高可用？
A2：目前通過多集群的配置。例如在大促類需求時，會針對 Flink 集群和底層存儲集群做多集群的配置。如果線上集群出現問題，可以通過一鍵式切換到其他數據源，保證數據的可用性。切換完成后會對故障集群進行問題排查、修復，完成后再將集群切回主鏈路。
Q3：流批一體化數據源都用 binlog 嗎？
A3：binlog 主要適用于關系型數據庫存儲的業務數據，其他類似于流量日志會通過 DS 采集日志服務器中的數據，然后直接寫入到 Kafka 中。
Q4：實時和離線數據的時間差和數據不一致如何核對？
A4：實時計算增加小時級別的計算窗口和離線數據保持一致。計算口徑上實時任務和離線任務的口徑是保持一致的，例如通過日志時間來進行計算。
Q5：通過日志生成的時間如何處理晚到數據？
A5：實時計算的處理思路基本和離線是一致的，會通過多讀取一段時間的數據來保證數據的完整性。
