在大數(shù)據(jù)時(shí)代，凡是AI類項(xiàng)目的落地，都需要具備數(shù)據(jù)、算法、場景、計(jì)算力四個(gè)基本元素，缺一不可。
處理大數(shù)據(jù)已經(jīng)不能僅僅依靠計(jì)算力就能夠解決問題，計(jì)算力只是核心的基礎(chǔ)，還需要結(jié)合不同的業(yè)務(wù)場景與算法相互結(jié)合，沉淀出一個(gè)完整的智能化平臺(tái)。
數(shù)據(jù)中臺(tái)就是以云計(jì)算為數(shù)據(jù)智能提供的基礎(chǔ)計(jì)算力為前提，與大數(shù)據(jù)平臺(tái)提供的數(shù)據(jù)資產(chǎn)能力與技術(shù)能力相互結(jié)合，形成數(shù)據(jù)處理的能力框架賦能業(yè)務(wù)，為企業(yè)做到數(shù)字化、智能化運(yùn)營。
目前，外界與業(yè)內(nèi)很多人對于數(shù)據(jù)中臺(tái)的理解存在誤區(qū)，一直只是在強(qiáng)調(diào)技術(shù)的作用，強(qiáng)調(diào)技術(shù)對于業(yè)務(wù)的推動(dòng)作用，但在商業(yè)領(lǐng)域落地的層面上，更多時(shí)候技術(shù)的發(fā)展和演進(jìn)都是需要跟著業(yè)務(wù)走，技術(shù)的發(fā)展和進(jìn)步需要基于業(yè)務(wù)方的需求與數(shù)據(jù)場景應(yīng)用化的探索來反向推動(dòng)。
這個(gè)也就是為什么最近知乎、脈脈都在瘋傳阿里在拆“大中臺(tái)”？個(gè)人猜想，原因是沒有真正理解中臺(tái)的本質(zhì)，其實(shí)阿里在最初建設(shè)數(shù)據(jù)中臺(tái)的目的主要是為了提升效率和解決業(yè)務(wù)匹配度問題，最終達(dá)到降本增效。
所以說“拆”是假的，在“拆”的同時(shí)一定在“合”，“拆”的一個(gè)方面是企業(yè)戰(zhàn)略布局層面上的規(guī)劃，架構(gòu)升級，如果眼界不夠高，格局不夠大，看到的一定只是表面；另一方面不是由于組織架構(gòu)龐大而做“拆”的動(dòng)作，而是只有這樣才能在效率和業(yè)務(wù)匹配度上，做到最大利益化的解耦。
數(shù)據(jù)中臺(tái)出現(xiàn)的意義在于降本增效，是用來賦能企業(yè)沉淀業(yè)務(wù)能力，提升業(yè)務(wù)效率，最終完成數(shù)字化轉(zhuǎn)型。前一篇數(shù)據(jù)中臺(tái)建設(shè)的價(jià)值和意義，提到過企業(yè)需要根據(jù)自身的實(shí)際情況，打造屬于自己企業(yè)獨(dú)有的中臺(tái)能力。
因?yàn)椋瑪?shù)據(jù)中臺(tái)本身絕對是不可復(fù)制的，從BCG矩陣的維度結(jié)合各家市場資源、市場環(huán)境、市場地位以及業(yè)務(wù)方向來看，幾乎所有企業(yè)的戰(zhàn)略目標(biāo)都是不一樣的。
一、數(shù)據(jù)中臺(tái)演進(jìn)的過程
從數(shù)據(jù)處理的維度來聊一聊數(shù)據(jù)中臺(tái)經(jīng)歷的四個(gè)階段：數(shù)據(jù)庫階段、數(shù)據(jù)倉庫階段、數(shù)據(jù)平臺(tái)階段、數(shù)據(jù)中臺(tái)階段。
- 數(shù)據(jù)庫階段：OLTP（事務(wù)處理）是傳統(tǒng)的關(guān)系型數(shù)據(jù)庫的主要應(yīng)用，主要是基本的、日常的事務(wù)處理，記錄即時(shí)的增、刪、改、查。比如銀行交易、電商交易等
- 數(shù)據(jù)倉庫階段：數(shù)據(jù)倉庫系統(tǒng)的主要應(yīng)用主要是OLAP（聯(lián)機(jī)分析處理），支持復(fù)雜的分析操作，側(cè)重決策支持，并且提供直觀易懂的查詢結(jié)果。比如復(fù)雜的動(dòng)態(tài)報(bào)表分析、用戶價(jià)值分析等
- 數(shù)據(jù)平臺(tái)階段：其實(shí)，目前業(yè)界并沒有對大數(shù)據(jù)平臺(tái)做統(tǒng)一的定義，一般情況下，只要使用了Hadoop/Spark/Storm/Flink等這些分布式的實(shí)時(shí)或者離線計(jì)算框架，建立計(jì)算集群，并在上面運(yùn)行各種計(jì)算任務(wù)
- 數(shù)據(jù)中臺(tái)階段：指具有全域級、可復(fù)用的數(shù)據(jù)資產(chǎn)中心與數(shù)據(jù)能力中心，對海量數(shù)據(jù)進(jìn)行采集、計(jì)算、存儲(chǔ)、加工，同時(shí)統(tǒng)一標(biāo)準(zhǔn)和口徑，提供干凈、透明、智慧的數(shù)據(jù)資產(chǎn)與高效、易用的數(shù)據(jù)能力來，能夠?qū)覱LTP（事務(wù)處理）和OLAP（報(bào)表分析）的需求
剛好之前本人經(jīng)歷過電商公司的0 - 1 - N，就拿電商行業(yè)來舉個(gè)例子，更好的讓大家理解數(shù)據(jù)中臺(tái)演進(jìn)的四個(gè)階段
1、數(shù)據(jù)庫階段
電商創(chuàng)業(yè)早期啟動(dòng)非常容易，門檻相對來說較低，試錯(cuò)成本較少。三五個(gè)小伙伴組個(gè)小團(tuán)隊(duì)，做一個(gè)可以下單的前端頁面，云上搭幾臺(tái)服務(wù)器再加上一個(gè)MySQL數(shù)據(jù)庫，形成一個(gè)簡單的OLTP系統(tǒng)，就可以給用戶去使用，它的主要作用用于保證數(shù)據(jù)持久化存儲(chǔ)和簡單商品交易查詢。
現(xiàn)在估計(jì)很多小型電商與小程序創(chuàng)業(yè)者的初期都是這么干的，甚至找個(gè)外包團(tuán)隊(duì)做完就開始對于市場試錯(cuò)。
原因很簡單，從ROI來看，項(xiàng)目前期業(yè)務(wù)數(shù)據(jù)量不大，簡單的GB級別，每天的訂單和流量數(shù)都比較少，后端數(shù)據(jù)庫只要做簡單的單條數(shù)據(jù)的查詢和展示就能夠滿足了需求，根本就沒有什么高并發(fā)，批量處理等高深技術(shù)，就連做在初期做數(shù)據(jù)統(tǒng)計(jì)/分析用Excel就可以滿足需求。
最終，隨著客戶、訂單和外部流量的逐步上升，數(shù)據(jù)量從GB發(fā)展成TB級別，數(shù)據(jù)庫通過普通查詢存在較大的壓力，只能做升級改造，于是就有了數(shù)據(jù)倉庫的誕生。
2、數(shù)據(jù)倉庫階段
隨著業(yè)務(wù)指數(shù)級的增長，數(shù)據(jù)量增長的同時(shí)公司的組織架構(gòu)慢慢變得龐大、復(fù)雜，面臨的問題也越來越多，越來越深入。公司上層關(guān)心的問題，從最初簡單的想知道“昨天、今天的GMV”、“上周的PV、UV是多少”、“某品類商品的環(huán)比、同比的增長比例是多少”，慢慢演化到希望通過數(shù)據(jù)進(jìn)行精細(xì)化運(yùn)營和用戶的價(jià)值模型分析。
希望通過數(shù)據(jù)統(tǒng)計(jì)/分析/挖掘，分析出用戶在某種特定的使用場景中，比如“18~25歲女性用戶在過去三個(gè)月對服裝類商品的購買行為與節(jié)假日促銷活動(dòng)之間的關(guān)系”。
當(dāng)公司運(yùn)營和高層，提出此類非常具體的case，希望通過數(shù)據(jù)統(tǒng)計(jì)/分析/挖掘?qū)具\(yùn)營決策起到關(guān)鍵性作用的問題，其實(shí)是很難從業(yè)務(wù)數(shù)據(jù)庫從直接調(diào)取出來。
原因是由于數(shù)據(jù)庫是面向事務(wù)的設(shè)計(jì)，數(shù)據(jù)倉庫是面向主題設(shè)計(jì)的。數(shù)據(jù)庫一般存儲(chǔ)在線交易數(shù)據(jù)，為捕獲數(shù)據(jù)而設(shè)計(jì)，在設(shè)計(jì)上數(shù)據(jù)庫是盡量避免冗余，一般采用符合范式的規(guī)則來設(shè)計(jì)。
比如，業(yè)務(wù)數(shù)據(jù)庫中的數(shù)據(jù)結(jié)構(gòu)是為了完成商品交易而設(shè)計(jì)的，不是為了查詢和分析的便利設(shè)計(jì)的。數(shù)據(jù)倉庫存儲(chǔ)的一般是歷史數(shù)據(jù)，為分析數(shù)據(jù)而設(shè)計(jì)，在設(shè)計(jì)上是有意引入冗余，采用反范式的方式來設(shè)計(jì)。
數(shù)據(jù)庫和數(shù)據(jù)倉庫兩個(gè)基本的元素都有維表和事實(shí)表。（維表是看問題的角度，比如時(shí)間，部門、人，維表放的就是這些東西的定義，事實(shí)表里放著要查詢的數(shù)據(jù)，同時(shí)有維表的ID）。
因此，數(shù)據(jù)倉庫的出現(xiàn)，并不是要取代數(shù)據(jù)庫，而是為了更好的做數(shù)據(jù)分析和報(bào)表需求分析，主要處理OLAP（聯(lián)機(jī)分析處理）需求。
但是，隨著客戶、訂單和外部流量的逐步上升，數(shù)據(jù)量從TB發(fā)展成PB級別，原來的技術(shù)架構(gòu)越來越不能支持海量數(shù)據(jù)處理，這時(shí)候又有了數(shù)據(jù)平臺(tái)的誕生。
3、數(shù)據(jù)平臺(tái)階段
第一、企業(yè)業(yè)務(wù)系統(tǒng)過多，彼此數(shù)據(jù)沒有打通。涉及分析數(shù)據(jù)的過程當(dāng)中，需要先從各個(gè)系統(tǒng)尋找到相應(yīng)的數(shù)據(jù)，然后提取數(shù)據(jù)進(jìn)行整合打通，才能做數(shù)據(jù)分析。在這個(gè)過程中人為進(jìn)行整合出錯(cuò)率高，分析效果不及時(shí)，導(dǎo)致整體的效率低下，數(shù)據(jù)遷移、數(shù)據(jù)同步的滯后與錯(cuò)誤；
第二、業(yè)務(wù)系統(tǒng)壓力大，架構(gòu)相對笨重，做數(shù)據(jù)分析計(jì)算消耗資源很大。需要通過將數(shù)據(jù)抽取出來，經(jīng)過獨(dú)立服務(wù)器來處理數(shù)據(jù)查詢、分析任務(wù)，來釋放業(yè)務(wù)系統(tǒng)的壓力；
第三、性能問題，公司業(yè)務(wù)越來越復(fù)雜，數(shù)據(jù)量越來越大。歷史數(shù)據(jù)的積累嚴(yán)重，數(shù)據(jù)沒有得到使用。原始數(shù)據(jù)系統(tǒng)不能承受更大數(shù)據(jù)量的處理時(shí)，數(shù)據(jù)處理效率嚴(yán)重下降。
于是，通過整合Hadoop/Spark/Storm/Flink等分布式的離線與實(shí)時(shí)計(jì)算框架，建立計(jì)算集群，并在上面運(yùn)行各種計(jì)算任務(wù)，搭建大數(shù)據(jù)平臺(tái)，使得平臺(tái)具有數(shù)據(jù)互聯(lián)互通、支持多數(shù)據(jù)集實(shí)時(shí)同步、支持?jǐn)?shù)據(jù)資源管理，實(shí)現(xiàn)多源異構(gòu)數(shù)據(jù)的整合管控能力；
可以提供完善的大數(shù)據(jù)分析基礎(chǔ)運(yùn)行環(huán)境，提供統(tǒng)一二次開發(fā)接口等能力的，用這些能力來解決大數(shù)據(jù)存儲(chǔ)與計(jì)算問題，提升數(shù)據(jù)分析效率以及用戶畫像系統(tǒng)/推薦/搜索系統(tǒng)的運(yùn)用落地。
（此處已添加小程序，請到今日頭條客戶端查看）4、數(shù)據(jù)中臺(tái)階段
數(shù)據(jù)量的指數(shù)級增長，從PB發(fā)展成EB級別，為了更好的賦能業(yè)務(wù)，企業(yè)啟動(dòng)中臺(tái)戰(zhàn)略，打通各個(gè)業(yè)務(wù)線的數(shù)據(jù)，整合匯集數(shù)據(jù)，在底層通過技術(shù)手段解決數(shù)據(jù)統(tǒng)一存儲(chǔ)和統(tǒng)一計(jì)算問題。
在數(shù)據(jù)服務(wù)層通過數(shù)據(jù)服務(wù)化的Data API的方式，打通數(shù)據(jù)平臺(tái)和前臺(tái)的業(yè)務(wù)層對接，結(jié)合算法，把前臺(tái)業(yè)務(wù)的分析需求和交易需求直接對接到中臺(tái)來，通過數(shù)據(jù)中臺(tái)處理和邏輯運(yùn)算，然后在反向賦能業(yè)務(wù)，真正做到意義上的『一切業(yè)務(wù)數(shù)據(jù)化，一切數(shù)據(jù)業(yè)務(wù)化』。
二、數(shù)據(jù)倉庫、數(shù)據(jù)平臺(tái)和數(shù)據(jù)中臺(tái)的架構(gòu)
數(shù)據(jù)倉庫架構(gòu)圖
1、采集層
從各種數(shù)據(jù)源中采集數(shù)據(jù)和存儲(chǔ)到數(shù)據(jù)到存儲(chǔ)在基于Hadoop分布式文件系統(tǒng)HDFS上，期間做ETL操作。其中數(shù)據(jù)采集一般采用Flume收集日志，采用Sqoop將RDBMS以及NoSQL中的數(shù)據(jù)同步到HDFS上
數(shù)據(jù)源主要有：日志數(shù)據(jù)（服務(wù)器日志 + 系統(tǒng)日志等）+ 業(yè)務(wù)數(shù)據(jù)庫（Mysql、Oracle等）+ 埋點(diǎn)數(shù)據(jù)（服務(wù)端埋點(diǎn) + 移動(dòng)端埋點(diǎn)數(shù)據(jù)等）+ 其他數(shù)據(jù)（Excel手工錄入的數(shù)據(jù)、合作伙伴提供的接口數(shù)據(jù)、第三方爬蟲數(shù)據(jù)、合法購買的第三方數(shù)據(jù)等）
2、存儲(chǔ)與分析層
主要有離線計(jì)算 + 實(shí)時(shí)計(jì)算
- 存儲(chǔ)系統(tǒng)：基于Hadoop分布式文件系統(tǒng)對采集層的數(shù)據(jù)進(jìn)行存儲(chǔ)
- 消息系統(tǒng)：加入Kafka防止數(shù)據(jù)丟失
- 離線計(jì)算：是對實(shí)時(shí)性要求不高的部分，通常將計(jì)算結(jié)果保存在Hive中
- 實(shí)時(shí)計(jì)算：使用Spark Streaming、Storm消費(fèi)Kafka中收集的日志數(shù)據(jù)，然后通過實(shí)時(shí)計(jì)算，將結(jié)果保存在redis中
- 機(jī)器學(xué)習(xí)：用Spark MLlib提供的機(jī)器學(xué)習(xí)算法
3、共享層
通過離線和實(shí)時(shí)計(jì)算的數(shù)據(jù)分析與計(jì)算后的結(jié)果存儲(chǔ)在數(shù)據(jù)共享層，做數(shù)據(jù)共享層，主要做數(shù)據(jù)分發(fā)和調(diào)度中心。因?yàn)橥ㄟ^Hive、MR、Spark、SparkSQL分析和計(jì)算的結(jié)果，是存儲(chǔ)在HDFS上，業(yè)務(wù)和應(yīng)用不可能直接從HDFS上獲取數(shù)據(jù)。其中使用Kylin作為OLAP引擎做多維度分析
4、數(shù)據(jù)應(yīng)用
報(bào)表展示 + 數(shù)據(jù)分析 + 即席查詢 + 數(shù)據(jù)挖掘
5、任務(wù)調(diào)度與監(jiān)控
數(shù)據(jù)平臺(tái)架構(gòu)圖
1、采集層
基于Hadoop分布式文件系統(tǒng)對采集層的數(shù)據(jù)進(jìn)行存儲(chǔ)。
- 結(jié)構(gòu)化數(shù)據(jù)：通過兩種途徑抽取并存放到HDFS分布式文件系統(tǒng)中，能夠序列化的數(shù)據(jù)，直接存放到HDFS中;不能夠序列化的數(shù)據(jù),通過數(shù)據(jù)整理后統(tǒng)一存放在分布式數(shù)據(jù)庫環(huán)境中, 再經(jīng)過序列化后和整理后還不能序列化的數(shù)據(jù)一樣直接存放到HDFS中;
- 半結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)：各種日志數(shù)據(jù)(通常序列化半結(jié)構(gòu)化數(shù)據(jù))直接存放到HDFS中;點(diǎn)擊流和數(shù)據(jù)接口中的數(shù)據(jù)(通常序列化半結(jié)構(gòu)化數(shù)據(jù))直接存放到HDFS中；非結(jié)構(gòu)化的數(shù)據(jù)直接存放到HDFS中
2、數(shù)據(jù)層
一方面，把相關(guān)業(yè)務(wù)結(jié)構(gòu)化數(shù)據(jù)和有一定格式關(guān)系的半結(jié)構(gòu)化的數(shù)據(jù)存放在Hadoop Hive數(shù)據(jù)倉庫中，基于業(yè)務(wù)需求，按照特定的業(yè)務(wù)主題域進(jìn)行數(shù)據(jù)集市的構(gòu)建；另一方面把相關(guān)業(yè)務(wù)中半結(jié)構(gòu)化的數(shù)據(jù)直接存放在HDFS分布
3、計(jì)算層
離線計(jì)算 + 實(shí)時(shí)計(jì)算
4、應(yīng)用層
可視化數(shù)據(jù)分析報(bào)表 + 搜索/推薦/廣告具體的場景應(yīng)用
5、任務(wù)調(diào)度與監(jiān)控
阿里數(shù)據(jù)中臺(tái)架構(gòu)圖
- 為了保證快速、高效、高質(zhì)量數(shù)據(jù)接入，建立統(tǒng)一數(shù)據(jù)質(zhì)量管理平臺(tái) + 數(shù)據(jù)能力中心
- 通過數(shù)據(jù)采集和接入為切入角度，按照業(yè)態(tài)接入內(nèi)部數(shù)據(jù)（比如淘寶、天貓、盒馬等）+ 外部數(shù)據(jù)（爬蟲數(shù)據(jù)、第三方合作數(shù)據(jù)、埋點(diǎn)數(shù)據(jù)等）
- 把數(shù)據(jù)抽取到計(jì)算平臺(tái)，通過以“業(yè)務(wù)板塊 + 業(yè)務(wù)過程 + 分析維度”為架構(gòu)去構(gòu)建“數(shù)據(jù)共享中心”，構(gòu)建OneData體系
- 在數(shù)據(jù)共享中心的上層，以業(yè)務(wù)/自然對象 + 萃取標(biāo)簽“為架構(gòu)構(gòu)建“數(shù)據(jù)唯一中心”，構(gòu)建OneID體系，打通消費(fèi)者數(shù)據(jù)體系、企業(yè)數(shù)據(jù)體系、內(nèi)容數(shù)據(jù)體系等
- 經(jīng)過深度加工后，得到干凈、透明、智慧的數(shù)據(jù)賦能產(chǎn)品與業(yè)務(wù)線；通過統(tǒng)一的數(shù)據(jù)服務(wù)中間件“OneService”提供統(tǒng)一數(shù)據(jù)服務(wù)，讓『一切業(yè)務(wù)數(shù)據(jù)化，一切數(shù)據(jù)業(yè)務(wù)化』
三、數(shù)據(jù)倉庫、數(shù)據(jù)平臺(tái)和數(shù)據(jù)中臺(tái)的區(qū)別與聯(lián)系
數(shù)據(jù)倉庫、數(shù)據(jù)平臺(tái)和數(shù)據(jù)中臺(tái)的區(qū)別與聯(lián)系：
1、在概念層面上
數(shù)據(jù)平臺(tái)和數(shù)據(jù)中臺(tái)的技術(shù)能力都是基于數(shù)據(jù)倉庫發(fā)展而來的，在數(shù)據(jù)建設(shè)理論上一脈相承，他們處理的對象都是海量數(shù)據(jù)，服務(wù)目的、商業(yè)價(jià)值也同樣類似。其實(shí)中平臺(tái)和中臺(tái)，兩者在能力上都有對外都提供Open API服務(wù)。
一方面，中臺(tái)是業(yè)務(wù)應(yīng)用，不具體代表著某種技術(shù)，它不是最終用戶能直接使用的，必須結(jié)合企業(yè)的各個(gè)數(shù)據(jù)業(yè)務(wù)場景；另一方面，平臺(tái)是不帶有業(yè)務(wù)特征性質(zhì)的，主要匯集其他人的能力，整合成平臺(tái)的能力，相對來說是靜態(tài)的，而中臺(tái)是動(dòng)態(tài)變化的本身，需要通過數(shù)據(jù)驅(qū)動(dòng)的方式來滋養(yǎng)業(yè)務(wù)，不斷訓(xùn)練調(diào)整業(yè)務(wù)模型和業(yè)務(wù)算法提供的能力，提供給其他系統(tǒng)和平臺(tái)集成的能力。
2、在數(shù)據(jù)層面上
數(shù)據(jù)倉庫的數(shù)據(jù)來源主要來源于RDBMS，其中存儲(chǔ)的數(shù)據(jù)格式以結(jié)構(gòu)化數(shù)據(jù)為主，這些數(shù)據(jù)并非企業(yè)全量數(shù)據(jù)，而是根據(jù)企業(yè)業(yè)務(wù)需求做針對性整合、抽取。數(shù)據(jù)平臺(tái)和數(shù)據(jù)中臺(tái)的數(shù)據(jù)來源的期望都是全域級的數(shù)據(jù)，主要有結(jié)構(gòu)化數(shù)據(jù)、半結(jié)構(gòu)化數(shù)據(jù)、非結(jié)構(gòu)化數(shù)據(jù)等
3、在目標(biāo)層面上
- 數(shù)據(jù)倉庫基于單機(jī)的，一旦數(shù)據(jù)量變大，會(huì)受單機(jī)容量、計(jì)算以及性能等方面的限制。主要用來做報(bào)表分析，目的性相對來說單一，只是針對相關(guān)分析報(bào)表用到基礎(chǔ)數(shù)據(jù)，進(jìn)行抽取、整合、數(shù)據(jù)清洗和分析。比如，新增一張報(bào)表，就要從底層到上層再做一次，流程上相對來說繁瑣；
- 數(shù)據(jù)平臺(tái)建立是為了解決數(shù)據(jù)倉庫不能處理非結(jié)構(gòu)化數(shù)據(jù)和報(bào)表開發(fā)周期長的問題以及計(jì)算和性能等問題。匯集整合打通數(shù)據(jù)，數(shù)據(jù)清洗后，當(dāng)業(yè)務(wù)提出需求的時(shí)候，把業(yè)務(wù)方需要的若干個(gè)小數(shù)據(jù)集單獨(dú)提取出來，以數(shù)據(jù)集的形式提供給業(yè)務(wù)方去使用；
- 數(shù)據(jù)中臺(tái)通常會(huì)對來自多方面的基礎(chǔ)數(shù)據(jù)進(jìn)行數(shù)據(jù)清洗后，然后按照主題域的概念建立多個(gè)以事物為主的主題域；和數(shù)據(jù)平臺(tái)在底層建設(shè)上都是基于分布式計(jì)算平臺(tái)和存儲(chǔ)平臺(tái)，理論上可以通過無限擴(kuò)充平臺(tái)的計(jì)算和存儲(chǔ)能力。目標(biāo)是都是為了融合整個(gè)企業(yè)的全域級數(shù)據(jù)，打通數(shù)據(jù)之間的隔閡，消除數(shù)據(jù)標(biāo)準(zhǔn)和口徑不統(tǒng)一的問題。
4、在應(yīng)用層面上
建立在數(shù)據(jù)中臺(tái)上的數(shù)據(jù)應(yīng)用場景，不僅僅只是面向于數(shù)據(jù)報(bào)表開發(fā)分析與展示處理，更多是將數(shù)據(jù)變成服務(wù)化的方式，然后提供給業(yè)務(wù)系統(tǒng)。
