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

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

1、云音樂的實(shí)時(shí)場景

目前云音樂的實(shí)時(shí)場景主要分為以下三個(gè)部分，如圖：

（1）實(shí)時(shí)特征

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4、技術(shù)選型

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

（1）秒級實(shí)時(shí)需求

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

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

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

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

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

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

1、Lambda 架構(gòu)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1、計(jì)算一致性問題

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

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

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

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

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

2、現(xiàn)狀問題

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

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

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

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

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

3、FastX 架構(gòu)

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

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

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

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

運(yùn)維層：主要職責(zé)監(jiān)控、報(bào)警。

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

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

（1）模型化：

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

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

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

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

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

（2）FastX- 組件化：

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

（3）FastX -配置化：

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

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

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

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

（4）FastX- 服務(wù)化血緣化：

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

四、未來規(guī)劃

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

1、鞏固基建

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

和 FastX 共建多鏈路保障機(jī)制。

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

2、低代碼、流批一體

擴(kuò)張更多復(fù)雜的計(jì)算模型。

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

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

3、湖倉探索

實(shí)時(shí)湖倉建設(shè)。

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

Q1：指標(biāo)計(jì)算在錄入時(shí)就要確定嗎？

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

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

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

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

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

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

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

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

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