小米數(shù)據(jù)管理與應(yīng)用實踐
導(dǎo)讀：本文的主題為小米數(shù)據(jù)管理與應(yīng)用實踐，主要介紹小米在數(shù)據(jù)管理建設(shè)方面的理解和探索。數(shù)據(jù)管理的核心重點在于元數(shù)據(jù)平臺的建設(shè)，用以支撐數(shù)據(jù)管理的上層應(yīng)用，包括數(shù)據(jù)地圖、數(shù)據(jù)規(guī)范治理、數(shù)據(jù)成本治理及數(shù)據(jù)質(zhì)量建設(shè)，以及未來的規(guī)劃。將圍繞以下三個方向展開：①?元數(shù)據(jù)平臺的建設(shè)；②?元數(shù)據(jù)應(yīng)用；③?未來規(guī)劃。
01
元數(shù)據(jù)平臺的建設(shè)
小米元數(shù)據(jù)平臺的建設(shè)內(nèi)容，主要包括數(shù)據(jù)管理架構(gòu)的現(xiàn)狀、以及架構(gòu)的演化過程。在建設(shè)元數(shù)據(jù)技術(shù)平臺的過程中，針對以下三個方面進行了改進，也是平臺進化的三個關(guān)鍵點：
實現(xiàn)全域元數(shù)據(jù)
實現(xiàn)實時血緣
實現(xiàn)精準計量
1. 元數(shù)據(jù)
元數(shù)據(jù)是用來描述數(shù)據(jù)的數(shù)據(jù)。請參見圖2 。從抽象來看，包括分為實體、實體的屬性以及實體與實體之間的關(guān)系三個方面來進行分類。實體主要指表元數(shù)據(jù)和作業(yè)元數(shù)據(jù)，來自于工程師在ETL的實際工作中所涉及到的系統(tǒng)。如：Hive、Doras、Kudu、MQ、ES、Iceberg，即傳統(tǒng)的數(shù)倉及上下游。
比如：實體包含了技術(shù)元數(shù)據(jù)和生產(chǎn)元數(shù)據(jù)。其中技術(shù)元數(shù)據(jù)用于支撐數(shù)據(jù)資產(chǎn)管理的資產(chǎn)地圖；生產(chǎn)元數(shù)據(jù)，主要是作業(yè)的一些調(diào)度信息和運行信息，用于支撐數(shù)據(jù)資產(chǎn)管理的數(shù)據(jù)質(zhì)量和成本治理的服務(wù)。
實體的屬性，包含業(yè)務(wù)元數(shù)據(jù)和衍生元數(shù)據(jù)。
業(yè)務(wù)元數(shù)據(jù)包括數(shù)倉分層、數(shù)據(jù)分類、指標關(guān)聯(lián)、應(yīng)用信息、隱私分級等內(nèi)容。內(nèi)容來源于建模規(guī)范、業(yè)務(wù)、指標系統(tǒng)、BI看板、數(shù)據(jù)報表，以及來自于業(yè)務(wù)的隱私分級定義等。業(yè)務(wù)元數(shù)據(jù)用于支撐資產(chǎn)管理的資產(chǎn)價值、安全治理以及規(guī)范治理。
衍生元數(shù)據(jù)包含元數(shù)據(jù)的存儲計量和訪問計量。存儲計量是服務(wù)于存儲層面的成本治理；訪問計量用于描述數(shù)據(jù)的使用情況，從技術(shù)角度去衡量資產(chǎn)的價值。衍生元數(shù)據(jù)來源于ETL工作中涉及的HDFS-Image、Doris、Kudu、MQ、ES以及HDFS-Log、SQL-Log。
描述實體的關(guān)系，包括血緣元數(shù)據(jù)，用于描述元數(shù)據(jù)之間的關(guān)聯(lián)關(guān)系，用于支撐數(shù)據(jù)資產(chǎn)管理中的影響分析和資產(chǎn)地圖服務(wù)。
圖 2?元數(shù)據(jù)分類
2. 元數(shù)據(jù)平臺技術(shù)架構(gòu)
小米元數(shù)據(jù)平臺的技術(shù)架構(gòu)如圖3所示，整體架構(gòu)與Apache的Atlas非常相似。
整體上可以劃分為三層。最上層是數(shù)據(jù)采集的源頭，以及最終數(shù)據(jù)支撐的應(yīng)用，包括Metadata Source、Lineage Source、Log Source和應(yīng)用Application。中間層是集成層，集成層是由Metacat、MQ以及API層組成。最底層是核心的存儲層。
最上層的Metadata Source用于對表元數(shù)據(jù)采集。最早只限于Hive表，后來實現(xiàn)了全域元數(shù)據(jù)的采集。主要包括ETL整個生產(chǎn)鏈路及上下游的全鏈路。比如：元數(shù)據(jù)采自于業(yè)務(wù)的Mysql數(shù)據(jù)庫。其中消息隊列采用了小米自研的Talos，簡單說實現(xiàn)了數(shù)據(jù)集成與分發(fā)的總線。而下游元數(shù)據(jù)的采集由Hive、Doris、ES、Kudu等實現(xiàn)。
圖 3?元數(shù)據(jù)平臺技術(shù)架構(gòu)?
Lineage Source實現(xiàn)血緣信息采集。血緣元數(shù)據(jù)是來自于從各個計算引擎。通常血緣元數(shù)據(jù)是通過SQL的查詢?nèi)肟诨蛘哒{(diào)度入口去采集。由于小米的業(yè)務(wù)特別多，且部門各自獨立，因此入口也特別多，很難通過常規(guī)的入口采集的方式提升數(shù)據(jù)采集覆蓋率。考慮到各部門的計算引擎都是在部門的計算平臺進行維護，從而可以在引擎?zhèn)却螯c，實現(xiàn)血緣元數(shù)據(jù)的采集。同時結(jié)合SQL入口對SQL的審計日志做補充，兩者的數(shù)據(jù)進行合并，得到較為滿意的血緣元數(shù)據(jù)采集及采集覆蓋率。
Lineage Source中的DataHub是小米內(nèi)部的數(shù)據(jù)集成平臺，包括離線整理集成和實時集成。DataHub集成平臺也有上下游的血緣關(guān)系，也進行血緣元數(shù)據(jù)的采集。
日志層面調(diào)度日志、計量日志以及運行日志。這些日志跟質(zhì)量建設(shè)和訪問相關(guān)。Application應(yīng)用，包含數(shù)據(jù)平臺的上層應(yīng)用、數(shù)據(jù)地圖、成本治理、規(guī)范治理等內(nèi)容。
在中間層的Metacat，是在采集諸多原圖的元數(shù)據(jù)時，提供一個統(tǒng)一元數(shù)據(jù)的視角。所以通過基于Metacat進行二次定制開發(fā)，實現(xiàn)內(nèi)部的各個系統(tǒng)的適配。元數(shù)據(jù)的采集統(tǒng)一通過Metacat實現(xiàn)，包括T+1和增量變更，都要通過Metacat來實現(xiàn)。因此，Metacat與Messaging連接起來，Metacat把每天增量變更送到Messaging。之后包含血緣信息的日志通過Messaging送到數(shù)據(jù)總線，使下游層面可以使用這些數(shù)據(jù)，通過API為上層應(yīng)用提供數(shù)據(jù)服務(wù)和支撐。
最底層的存儲部分，基本信息都存儲在Mysql中；T+1的快照存儲在Hive中；血緣圖關(guān)系存儲在JanusGraph。元數(shù)據(jù)的檢索，包括權(quán)限的檢索過濾、審計檢索等都放在ElasticSearch。?
3. 全域元數(shù)據(jù)
元數(shù)據(jù)平臺進化過程中，關(guān)鍵的演化點之一是全域元數(shù)據(jù)。之前提到元數(shù)據(jù)都是基于Hive進行管理，顯然只能看到Hive層的數(shù)據(jù)，無法知道產(chǎn)生的Hive表，到下游后最終有沒有被使用。舉例來說，有一堆數(shù)據(jù)給上層應(yīng)用，用于看板或者指標，產(chǎn)生了一張Doris表；但對應(yīng)的看板可能并沒有人看，所以可以通過倒推，把鏈路中的這一條鏈路進行優(yōu)化或者治理。而實現(xiàn)這樣的場景，就需要打通全鏈路，包括看板信息，搜索等，都需要全域元數(shù)據(jù)進行支撐。此時就需要進行域拓展。以Hive為中心去看上下游，包括上游的業(yè)務(wù)數(shù)據(jù)庫、Messaging，下游的Doris、Kudu、ES，包括內(nèi)部重構(gòu)傳統(tǒng)Hive 數(shù)倉的Iceberg，都要采集元數(shù)據(jù)。在實現(xiàn)全域的過程中，同時打開統(tǒng)一元數(shù)據(jù)的Hive Metastore，實現(xiàn)統(tǒng)一的表數(shù)據(jù)視角和管理。請參見圖4。
圖 4?實現(xiàn)全域元數(shù)據(jù)
4. 實時血緣
關(guān)鍵的演化點之二是實時血緣。如前所述，小米入口非常多，血緣關(guān)系采集很難實現(xiàn)面面俱到。最早采用解析HDFS日志的辦法，存在血緣很難正確解析的問題。例如：讀一個表，可能會有很多open操作，這些Open操作很難對應(yīng)表和表之間的關(guān)系，就會帶來血緣關(guān)系不準的問題。早期的解決方案是找出所有的讀和寫操作后，做一個笛卡爾乘積，但這樣就會產(chǎn)生大量不存在的血緣。
以上這些痛點嚴重影響了上層的數(shù)據(jù)治理，影響了解決問題的溯源過程。此外解析日志，由于只能T+1，認知量也比較大；而如果出現(xiàn)一個流式數(shù)據(jù)，就根本無法解析。這些都與通過SQL解析、能確定血緣的情況完全不同。
所以在進化版的新版方案中，考慮到?了入口問題和引擎接入的改造成本問題。方案最終采用實時引擎MQ埋點的方案。同時各個引擎本身要去執(zhí)行這個SQL，比如Hive、Flink、Spark等，包括Presto、Distcp。因為需要執(zhí)行這種操作，本身就需要去解析執(zhí)行計劃。而Spark、Flink也都支持對這些操作。通過對血緣關(guān)系的解析進行了內(nèi)部改造（請參見圖5），整體運行流暢。同時結(jié)合SQL Proxy Log去做血緣關(guān)系整合，從而實現(xiàn)血緣關(guān)系的精準解析。
圖 5?元數(shù)據(jù)實時血緣
5. 精準計量
關(guān)鍵的演化點之三是精準計量。精準計量目前還不能做到完全精準的計量，但是解決了計量的零和一的問題。?在最早的入口問題中，計量不準就無法對數(shù)據(jù)的冷熱程度進行判斷。比如用戶操作Hive表，會有各種各樣的形式，通過各種各樣的SQL。
尤其研發(fā)的種查詢需求就很難應(yīng)對。比如：Spark SQL分為常駐服務(wù)和非常駐服務(wù)，都是為了解決Spark SQL作業(yè)執(zhí)行的啟動問題。非常駐服務(wù)與Hive ?SQL一樣，每次都要有一個啟動過程。常駐服務(wù)則可以及時響應(yīng)SQL需求，直接執(zhí)行，減少了幾分鐘的啟動過程，其查詢過程能夠快速響應(yīng)。還有Flink SQL、 Beeline、Flink ?Jar和Spark Jar，包括Distcp想去覆蓋這些入口的計量，訪問情況的確定也是解析HDFS日志。通過這些日志解析血緣存在的問題，就是在Hive ?Jar的層面，無法確定上層誰提交的訪問。
計量部分現(xiàn)階段解決了零和一的問題。簡單的說當數(shù)據(jù)被訪問后，能基本保證打上數(shù)據(jù)訪問的標記。同時，通過與HDFS日志提供的足夠信息、進行精準的統(tǒng)計和整理，并結(jié)合頂層的SQL審計進行修正后，可以得到具體被訪問次數(shù)的精準計量。請參見圖6。
圖 6?元數(shù)據(jù)精準計量
下面在元數(shù)據(jù)平臺建設(shè)的基礎(chǔ)上，講述小米元數(shù)據(jù)應(yīng)用在以下四個方面的進展：
數(shù)據(jù)地圖
數(shù)據(jù)規(guī)范治理
數(shù)據(jù)成本治理
數(shù)據(jù)質(zhì)量建設(shè)
02
數(shù)據(jù)地圖
數(shù)據(jù)地圖是元數(shù)據(jù)應(yīng)用的典型應(yīng)用，包含兩個方面的內(nèi)容：數(shù)據(jù)地圖中數(shù)據(jù)的搜索和血緣關(guān)系。
1. 數(shù)據(jù)地圖-搜索
數(shù)據(jù)地圖在業(yè)界已經(jīng)是比較成熟的服務(wù)，小米的數(shù)據(jù)地圖建設(shè)目前處在追趕階段。數(shù)據(jù)地圖需要支持元數(shù)據(jù)的搜索與發(fā)現(xiàn)，具體包括以下三個方面的內(nèi)容：
① 支持表、字段、描述信息、數(shù)倉分層、數(shù)據(jù)分類、標簽、部門等信息搜索，即實現(xiàn)可對實體屬性再加關(guān)系的數(shù)據(jù)進行的全域搜索；
② 除了Hive 表，完善全域元數(shù)據(jù)概念中的其它引擎，如：Talos、Doris、Kudu、Iceberg、ES、MySQL等數(shù)據(jù)引擎；
③ 實現(xiàn)支持對指標、維度、看板等信息的搜索。
例如：一個新零售的搜索，如圖7的左側(cè)所示。根據(jù)用戶的收藏數(shù)據(jù)域分類打了標簽。將大權(quán)重記錄放在上面，搜索的結(jié)果更多的作為展示產(chǎn)品的形式。
圖 7?數(shù)據(jù)地圖-搜索結(jié)果
2. 數(shù)據(jù)地圖-血緣
通過數(shù)據(jù)地圖，可以更清晰展現(xiàn)數(shù)據(jù)之間的血緣關(guān)系。通過技術(shù)架構(gòu)改造，實現(xiàn)了全鏈路的數(shù)據(jù)血緣，使不同系統(tǒng)的鏈路關(guān)系都能展示（如圖8），包括 MySQL/MQ/Hive/Iceberg/Doris 等。這樣用戶就能很方便的從數(shù)據(jù)最早的源頭，一直追溯到最上層的應(yīng)用。大大方便了對問題的追溯，也更方便的實現(xiàn)對整體數(shù)據(jù)價值的評估。
數(shù)據(jù)地圖的后續(xù)建設(shè)會增加對血緣的搜索和變更通知。
圖 8?數(shù)據(jù)地圖-血緣關(guān)系
03
數(shù)據(jù)規(guī)范治理
元數(shù)據(jù)應(yīng)用中的重點應(yīng)用是數(shù)據(jù)規(guī)范治理，對元數(shù)據(jù)的生態(tài)健康起到至關(guān)重要的作用。數(shù)據(jù)規(guī)范治理分為兩個度量維度：
建模規(guī)范度；
建模完善度。
數(shù)據(jù)規(guī)范治理通過以上兩個維度作為指標，量化數(shù)據(jù)健康完善的程度。
圖 9?元數(shù)據(jù)應(yīng)用-數(shù)據(jù)規(guī)范治理
1. 建模規(guī)范度
建模規(guī)范度又分為以下三個方面：
① 命名，是指表的命名是否符合收藏的規(guī)范；
② 分層，是指表需要按照收藏的規(guī)范進行分層。比如：目前有超過70%的表是沒有按照收藏的規(guī)范來分層。希望能結(jié)合一系列的整改措施，配合整體的數(shù)據(jù)治理，推動用戶進行分層治理或者整改；
③ 打標，是對業(yè)務(wù)板塊數(shù)據(jù)域、標簽等進行標記。
2. 建模完善度
建模完善度包括以下二個方面：
跨層引用：是指用戶的作業(yè)在DWS、ADS層，直接去訪問ODS。這樣的形式定義為跨層引用。這種現(xiàn)象說明底層DWD的建設(shè)不足，不足以支撐上層。
查詢覆蓋：是用來衡量上層的建設(shè)情況。例如：ID號的查詢到底是否命中DWS或者ADS層。如果是命中ODS，則說明上層的建設(shè)不夠好。
04
數(shù)據(jù)成本治理
元數(shù)據(jù)應(yīng)用中數(shù)據(jù)成本治理是優(yōu)化數(shù)據(jù)使用成本最直接的部分。數(shù)據(jù)成本治理在元數(shù)據(jù)應(yīng)用中是重點投入。因為小米的數(shù)據(jù)量增長比較快，整體的業(yè)務(wù)成本就上漲也比較多，對成本的訴求也比較高。
圖 10?元數(shù)據(jù)應(yīng)用-成本治理
1. 數(shù)據(jù)成本治理的起因
成本治理是從商務(wù)的角度出發(fā)，成本的根因最終回歸到底層，即主機和整個網(wǎng)絡(luò)這樣的資源；再往上層應(yīng)用追尋則是存儲計算的資源。對主機的成本來說，從商務(wù)談判層面，包括折扣已經(jīng)做了很大的努力，單純的再依賴商務(wù)層面，無法再挖掘成本優(yōu)化的潛力。
存儲計算的技術(shù)也在追趕階段，尤其涉及到成本，比如：分層存儲。此外計算層面的彈性算力也在建設(shè)過程中，很難快速把成本治理做到位，把成本降下來。
在當商務(wù)已經(jīng)達到極限，技術(shù)層面也在追趕業(yè)務(wù)，此時從元數(shù)據(jù)的角度思考成本優(yōu)化，面臨一個簡單問題，業(yè)務(wù)不知道自己有多少數(shù)據(jù)，這些數(shù)據(jù)好比就是花了多少錢，最后這些錢到底花在哪里了，應(yīng)該怎么優(yōu)化，優(yōu)化了之后會有什么反饋？。
針對這個問題做了產(chǎn)品層面的分析優(yōu)化的閉環(huán)，即成本分析優(yōu)化閉環(huán)。這個閉環(huán)的關(guān)鍵環(huán)節(jié)簡單稱作：觀現(xiàn)狀、查問題、做優(yōu)化、拿反饋。
觀現(xiàn)狀，就是看有什么數(shù)據(jù)，花了多少錢；
查問題，就是看這些數(shù)據(jù)到底有沒有什么問題，哪些是浪費的，或者錢主要花去處；
做優(yōu)化，就是尋找應(yīng)該怎么去優(yōu)化的突破點；
拿反饋，就是通過這些優(yōu)化，確定到底能省多少錢？
2. 數(shù)據(jù)成本治理方案
為了支撐成本分析優(yōu)化閉環(huán)，對數(shù)據(jù)成本治理進行了改造。改造主要包括以下四個方面內(nèi)容：
① 數(shù)出一孔，指是使用的數(shù)據(jù)要跟底層HDFS存儲的數(shù)據(jù)進行對齊，保證數(shù)據(jù)量的統(tǒng)一計量口徑。在成本治理存儲在計算中是指存儲維度，存儲本質(zhì)上要回歸到底層的數(shù)據(jù)存儲。比如：HDFS層面存儲的數(shù)據(jù)，?通過HDFS-Image計量最精確。它會精準的描述每一個文件到每一個路徑、以及存儲量。數(shù)據(jù)成本治理的首要工作就是數(shù)據(jù)與底層HDFS存儲的數(shù)據(jù)對齊，保證存儲量的數(shù)出一孔；
② 天級帳單，由于數(shù)據(jù)太多，需要及時跟蹤數(shù)據(jù)的費用優(yōu)化情況。否則選定了數(shù)據(jù)，過一個月才說這個數(shù)據(jù)優(yōu)化能省多少錢，反饋太長，難以完成閉環(huán)；
③ 按人歸屬，明確數(shù)據(jù)對應(yīng)的使用人。使用數(shù)據(jù)頻度高的人，其名下的表也比較多，對應(yīng)的的費用也比較高；
④ 及時預(yù)估，對于任何一個數(shù)據(jù)相關(guān)的操作，都應(yīng)該能及時預(yù)估、反饋數(shù)據(jù)量及成本。
這些優(yōu)化，確定到底能省多少錢？
3. 數(shù)據(jù)成本治理成果
通過提供成本分析優(yōu)化的閉環(huán)能力，成本治理短期取得了不錯的成果，合計優(yōu)化了 40% 的數(shù)據(jù)，如圖11所示，可以清晰的描述成本治理的效果：
最上側(cè)的曲線表示過去一年公司離線數(shù)據(jù)的增長趨勢；下面的分叉線左側(cè)黑色部分表示治理之前的歷史成本曲線；右側(cè)紅色線表示順著歷史成本曲線，使用最小二乘模擬出未來業(yè)務(wù)正常增長情況下的成本曲線；藍色橫線表示假設(shè)業(yè)務(wù)不增長的成本控制線；最下面的橙色表示成本治理后實際的成本曲線；
橙色線與紅色線之間的 gap 就是成本治理的價值所在。
圖 11?元數(shù)據(jù)應(yīng)用-成本治理
05
數(shù)據(jù)質(zhì)量建設(shè)
1. 數(shù)據(jù)質(zhì)量建設(shè)的內(nèi)容
首先數(shù)據(jù)質(zhì)量建設(shè)中，采用了業(yè)界比較成熟的一些質(zhì)量管理方法。如圖12所示。
小米的數(shù)據(jù)質(zhì)量建設(shè)強調(diào)以下兩方面：
數(shù)據(jù)生產(chǎn)的及時性，指在一個workflow或者一個DAG生產(chǎn)的數(shù)據(jù)，要保證在限定時間內(nèi)，或限定時間點必須產(chǎn)出，即數(shù)據(jù)生產(chǎn)的及時性，強調(diào)了對數(shù)據(jù)生產(chǎn)的保障。數(shù)據(jù)生產(chǎn)保障包含較多相關(guān)因素，如：調(diào)度，計算資源等。
數(shù)據(jù)內(nèi)容質(zhì)量檢查，指生產(chǎn)出來的數(shù)據(jù)內(nèi)容產(chǎn)出是否符合要求，是否經(jīng)過質(zhì)量檢查。
合格的數(shù)據(jù)產(chǎn)品具有以下特征：
唯一性，即主鍵唯一準確；
準確性，即數(shù)值要在一個范圍內(nèi)，符合預(yù)設(shè)數(shù)值要求，必須非空等條件；
完整性，即每天產(chǎn)出數(shù)據(jù)的波動情況。如果出現(xiàn)較大的波動率，會影響完整性；
一致性，即數(shù)據(jù)在上下游的鏈路系統(tǒng)中，對特定字段進行一致性校驗。
圖 12 元數(shù)據(jù)應(yīng)用-質(zhì)量建設(shè)
2. 質(zhì)量建設(shè)的技術(shù)架構(gòu)
數(shù)據(jù)質(zhì)量建設(shè)的技術(shù)架構(gòu)，沒有采用開源的技術(shù)架構(gòu)，而是采用內(nèi)部開發(fā)的方式。架構(gòu)示意圖所圖13所示。
圖 13 元數(shù)據(jù)應(yīng)用-質(zhì)量建設(shè)之技術(shù)架構(gòu)
①?事件觸發(fā)
在圖12中，最左側(cè)是調(diào)度系統(tǒng)對DAG（有向無環(huán)圖）執(zhí)行完成、產(chǎn)出DAG對應(yīng)的表后，專設(shè)用戶會配置事件觸發(fā)條件、觸發(fā)對表的內(nèi)容進行質(zhì)量檢查，以確定產(chǎn)出的表是否符合質(zhì)量要求。進行的事件觸發(fā)配置會把檢查事件放在MQ中，質(zhì)量系統(tǒng)則從消費視角，實現(xiàn)實時的事件觸發(fā)。即把對內(nèi)容的質(zhì)量檢查任務(wù)，直接掛載到調(diào)度系統(tǒng)DAG，在數(shù)據(jù)產(chǎn)出后，通過事件觸發(fā)，實現(xiàn)自動對產(chǎn)出數(shù)據(jù)進行質(zhì)量檢查。
② 時間觸發(fā)
在圖12中，架構(gòu)的最上層就是RestServer，它是一個可擴展的接收器，接收上述質(zhì)量規(guī)則的配置，或者查詢及對結(jié)果的查詢等。通過DB層面，觸發(fā)觸發(fā)器，實現(xiàn)時間觸發(fā)。比如：業(yè)務(wù)不是通過DAG實現(xiàn)事件觸發(fā)，而是可以通過設(shè)置的時間點去觸發(fā)。
③ 可擴展無狀態(tài)Worker
觸發(fā)器連接下層的Worker實現(xiàn)服務(wù)的執(zhí)行。Worker是無狀態(tài)的、可擴展執(zhí)行機。通過Worker可以實現(xiàn)支持多個數(shù)據(jù)源，比如：檢查HDFS。通過Presto、Spark SQL以及Doris，實現(xiàn)對表的檢查。
06
未來規(guī)劃
根據(jù)元數(shù)據(jù)平臺及元數(shù)據(jù)應(yīng)用的需求，未來的規(guī)劃包括三個方面：
生產(chǎn)保障聯(lián)動資源調(diào)度；
元數(shù)據(jù)建設(shè)的長期路線；
業(yè)務(wù)賦能。?
1.?生產(chǎn)保障聯(lián)動資源調(diào)度
生產(chǎn)保障聯(lián)動資源調(diào)度，是將生產(chǎn)保障從基線、到作業(yè)、到調(diào)度、到Y(jié)arn的全鏈路打通。包括基線管理、生產(chǎn)執(zhí)行，還有監(jiān)控預(yù)警等。
計算資源治理，目前還在開發(fā)進展中。如圖14所示。
圖 14 數(shù)據(jù)管理與應(yīng)用的未來規(guī)劃
2. 元數(shù)據(jù)建設(shè)的長期路線
元數(shù)據(jù)建設(shè)的長期路線就是數(shù)據(jù)管理，需要回答好兩個問題：
如何定義數(shù)據(jù)的健康定義，如何評判數(shù)據(jù)的健康程度；
如何治理不夠好或者不健康的數(shù)據(jù)，之后能有什么樣的收益。
綜合元數(shù)據(jù)平臺和元數(shù)據(jù)應(yīng)用中的經(jīng)驗，要回答上述問題，需要從數(shù)據(jù)治理、數(shù)據(jù)模型規(guī)范、資源的使用與計量、數(shù)據(jù)安全與防范、數(shù)據(jù)價值及其挖掘等多方面考慮，進行規(guī)劃和建設(shè)。
圖 15 未來規(guī)劃-長期路線
3. 業(yè)務(wù)賦能
業(yè)務(wù)賦能就是如何讓業(yè)務(wù)愿意把數(shù)據(jù)接入到中臺。根據(jù)以往做消息中間件的經(jīng)驗，需要從業(yè)務(wù)所重視的痛點出發(fā)。比如：對于任何一個業(yè)務(wù)，它在質(zhì)量層面都涉及到的重要數(shù)據(jù)，是否能及時產(chǎn)出；以及產(chǎn)出之后數(shù)據(jù)的質(zhì)量是否可信？是否有問題？
根據(jù)以往經(jīng)驗，業(yè)務(wù)賦能需要從數(shù)據(jù)治理的層面綜合考慮，通過質(zhì)量、效率、成本三個維度，確保能切實解決業(yè)務(wù)在質(zhì)量、效率和成本這三個維度的痛點：
① 在質(zhì)量層面，通過基線管理、數(shù)據(jù)質(zhì)量檢查、內(nèi)容檢查，包括重保數(shù)據(jù)產(chǎn)出的整體鏈路，都能夠?qū)崿F(xiàn)實時監(jiān)控產(chǎn)出；
② 在效率層面，可以通過規(guī)范建模、查詢優(yōu)化，出數(shù)加快和對數(shù)據(jù)地圖的優(yōu)化，讓業(yè)務(wù)找數(shù)速度加快。包括元數(shù)據(jù)血緣的建設(shè)，需要加快對業(yè)務(wù)中問題的追溯，即提升業(yè)務(wù)的效率；
③ 在成本層面，幫助業(yè)務(wù)實現(xiàn)成本分析優(yōu)化的閉環(huán)，就能夠為成本優(yōu)化提供一些工具或者抓手。
當能夠提供這樣完整的解決方案，讓業(yè)務(wù)覺得好用時，業(yè)務(wù)就有意愿進行嘗試。解決業(yè)務(wù)會遇到的風(fēng)險，必須要從這三個方面得到切實的落實。
以上的經(jīng)驗得到證實：最早小米內(nèi)部有特別多的MQ，通過與各部門溝通與策劃各自的MQ對接業(yè)務(wù)，最終統(tǒng)一了所有的MQ。其中包括Talos，成為小米數(shù)據(jù)總線的實施標準。
圖 16 未來規(guī)劃-業(yè)務(wù)賦能