大數(shù)據(jù)架構(gòu)平臺(tái)搭建指南及數(shù)據(jù)倉庫演進(jìn)

一、大數(shù)據(jù)架構(gòu)平臺(tái)搭建指南
雖然大數(shù)據(jù)平臺(tái)組件很多，但是對(duì)于沒有參與建設(shè)過大數(shù)據(jù)平臺(tái)的朋友來說，當(dāng)前眾多的大數(shù)據(jù)組件和平臺(tái)架構(gòu)容易讓人眼花繚亂。

本文首先介紹了大數(shù)據(jù)架構(gòu)平臺(tái)的組件架構(gòu)，便于了解大數(shù)據(jù)平臺(tái)的全貌，然后分別介紹數(shù)據(jù)集成、存儲(chǔ)與計(jì)算、分布式調(diào)度、查詢分析等方面的觀點(diǎn)。

01. 大數(shù)據(jù)平臺(tái)架構(gòu)

從圖上可以看出，大數(shù)據(jù)架構(gòu)平臺(tái)分為：數(shù)據(jù)集成、存儲(chǔ)與計(jì)算、分布式調(diào)度、查詢分析等核心模塊。我們就沿著這個(gè)架構(gòu)圖，來剖析大數(shù)據(jù)平臺(tái)的核心技術(shù)。

02.數(shù)據(jù)集成
1. 日志同步

開源日志收集系統(tǒng)有 Sqoop、Flume、Logstash、Filebeat、Vector 等，其中 Flume 在云原生場(chǎng)景用的多，Vector 是一個(gè)很高效的日志同步工具，剛開源不久。

專家觀點(diǎn)：

日志同步系統(tǒng)雖然本身比較成熟，但在平時(shí)工作中也屬于重點(diǎn)，一是因?yàn)樾枰降臄?shù)據(jù)量比較大，二是要保證日志輸出的持續(xù)性，有緩存機(jī)制最大限度保障不丟日志，始終保持平穩(wěn)的運(yùn)行狀態(tài)。

2. 數(shù)據(jù)抽取工具

大數(shù)據(jù)分析不能直接在原始的業(yè)務(wù)數(shù)據(jù)庫上直接操作，所以需要抽取想要的數(shù)據(jù)到分析數(shù)據(jù)庫或者分布式存儲(chǔ)系統(tǒng)（例如 HDFS），常見數(shù)據(jù)抽取工具包括：DataX、BitSail 等。DataxundefinedDataX 是阿里開源的一個(gè)異構(gòu)數(shù)據(jù)源離線同步工具，致力于實(shí)現(xiàn)包括關(guān)系型數(shù)據(jù)庫（MySQL、Oracle 等）、HDFS、Hive、ODPS、HBase、FTP 等各種異構(gòu)數(shù)據(jù)源之間穩(wěn)定高效的數(shù)據(jù)同步功能。BitSail 項(xiàng)目是頭條剛開源的，基于 Flink 開發(fā)，在自己內(nèi)部業(yè)務(wù)應(yīng)用廣泛。BitSail 支持多種異構(gòu)數(shù)據(jù)源間的數(shù)據(jù)同步，并提供離線、實(shí)時(shí)、全量、增量場(chǎng)景下的全域數(shù)據(jù)集成解決方案。

專家觀點(diǎn)：

數(shù)據(jù)集成非常重要，因?yàn)楦鷺I(yè)務(wù)方相關(guān)的第一個(gè)環(huán)節(jié)就是數(shù)據(jù)集成，數(shù)據(jù)集成如果出現(xiàn)問題比如速度慢、丟數(shù)據(jù)等，都會(huì)影響到業(yè)務(wù)方數(shù)據(jù)的使用，也會(huì)影響業(yè)務(wù)方對(duì)大數(shù)據(jù)平臺(tái)的信任度。

3. 數(shù)據(jù)傳輸隊(duì)列

數(shù)據(jù)傳輸有三種：

Kafka：流式傳輸
RabbitMQ：隊(duì)列傳輸
Pulsar：流式傳輸+隊(duì)列傳輸
專家觀點(diǎn)：

Kafka是Hadoop組件全家桶，名氣更大，但是易用性還是差一點(diǎn)。
Pulsar 跟Kafka很像，不過架構(gòu)比Kafka更先進(jìn)，屬于后起之秀。

03. 數(shù)據(jù)處理：數(shù)據(jù)存儲(chǔ)、計(jì)算
1. 數(shù)據(jù)存儲(chǔ)：HDFS

HDFS 特點(diǎn)：橫向擴(kuò)展，數(shù)據(jù)容錯(cuò)性高。

專家觀點(diǎn)：

對(duì)于 HDFS 來說，優(yōu)化是一個(gè)很重要的事情，因?yàn)?HDFS 的集群規(guī)模比較大，又要穩(wěn)定，又要持續(xù)不斷的應(yīng)對(duì)業(yè)務(wù)挑戰(zhàn)，優(yōu)化這一塊還是很重要的。如果集群負(fù)載大時(shí)，訪問延遲，會(huì)影響集群整體使用效率。
HDFS 的優(yōu)化趨勢(shì)包括：架構(gòu)改進(jìn)、讀寫分離、讀寫優(yōu)化等。
雖然 HDFS 是分布式文件系統(tǒng)，但在實(shí)際場(chǎng)景中，由于 NameNode 的單點(diǎn)和小文件過多導(dǎo)致的壓力過大問題，其管理的數(shù)據(jù)節(jié)點(diǎn)是有限的。分布式文件系統(tǒng)的新趨勢(shì)類似 JuiceFS 的架構(gòu)，采用「數(shù)據(jù)」與「元數(shù)據(jù)」分離存儲(chǔ)的架構(gòu)，從而實(shí)現(xiàn)文件系統(tǒng)的分布式設(shè)計(jì)，利用元數(shù)據(jù)緩存極大提升整體文件系統(tǒng)的性能，同時(shí)兼容大數(shù)據(jù)和云原生場(chǎng)景的應(yīng)用。

2. 數(shù)據(jù)計(jì)算

（1）離線計(jì)算引擎

在眾多的計(jì)算引擎中，MapReduce、Hive、Spark 等通常用于離線處理，即批計(jì)算。Storm、Spark Steaming 等處理實(shí)時(shí)計(jì)算的場(chǎng)景較多，即流計(jì)算。不得不說的是，F(xiàn)link 既可以用于流計(jì)算，也可以用于批計(jì)算。

其中 Hive 的用途很廣，也很可靠，底層基于 MapReduce 的封裝，屬于 Hadoop 全家桶組件之一，缺點(diǎn)是只能實(shí)現(xiàn)離線批處理。

Spark 是非常高效的批處理工具，成熟，穩(wěn)定，比 Hive 快很多，并且還能實(shí)現(xiàn)近實(shí)時(shí)的數(shù)據(jù)處理能力。Spark 功能全，架構(gòu)新，基于 RDD，計(jì)算過程中優(yōu)先利用內(nèi)存，并優(yōu)化中間的計(jì)算步驟。

專家觀點(diǎn)：

● Spark+數(shù)據(jù)湖是未來的發(fā)展方向。
● 離線的場(chǎng)景很豐富，但是缺乏處理的非常好的統(tǒng)一的計(jì)算引擎，hive和spark都無法做到，所以這一塊未來還有很大的發(fā)揮空間。

（2）實(shí)時(shí)計(jì)算引擎優(yōu)缺點(diǎn)及適用場(chǎng)景

實(shí)時(shí)計(jì)算引擎大體經(jīng)過了三代，依次是：storm、spark streaming、Flink。其中storm和spark streaming現(xiàn)在用的很少，大部分公司都在用Flink。

專家觀點(diǎn)：

● Flink的優(yōu)點(diǎn)是：可以實(shí)時(shí)的進(jìn)行計(jì)算，在處理流計(jì)算這個(gè)方向上是最好的組件，而且?guī)缀蹩梢蕴娲鼘?shí)時(shí)的業(yè)務(wù)場(chǎng)景。
● 缺點(diǎn)是對(duì)離線處理會(huì)略顯不足，不太適合處理大批量的離線數(shù)據(jù)集。
● Flink的優(yōu)化方向很多：a. Flink在流處理穩(wěn)定性上，雖然已經(jīng)做到極細(xì)粒度，但是遇到阻塞時(shí)，會(huì)存在丟失數(shù)據(jù)的問題。需要加強(qiáng)穩(wěn)定性。b. 實(shí)時(shí)性的提升：實(shí)時(shí)的優(yōu)化是無底洞，業(yè)務(wù)需求能到秒級(jí)別、毫秒級(jí)別，怎么能讓Flink在業(yè)務(wù)場(chǎng)景用的好，提升速度的同時(shí)，保持?jǐn)?shù)據(jù)一致性，是Flink面臨的挑戰(zhàn)。

04. 數(shù)據(jù)調(diào)度
1. 常用任務(wù)調(diào)度系統(tǒng)

提到常用的任務(wù)調(diào)度系統(tǒng)，大家都會(huì)想到非常多，包括但不限于：Crontab、Apache Airflow、Oozie、Azkaban、Kettle、XXL-JOB、Apache DolphinScheduler、SeaTunnel 等，五花八門。

專家觀點(diǎn)：

● Apache DolphinScheduler（海豚調(diào)度）更專注于大數(shù)據(jù)場(chǎng)景，調(diào)度功能不復(fù)雜，但是足夠把任務(wù)管理起來。并且它是中文的，這一點(diǎn)對(duì)于中文用戶較友好。
● Apache Airflow 國外用的多。

2. 資源調(diào)度系統(tǒng)

資源調(diào)度系統(tǒng)主要包括 Yarn 和 Azkaban。Yarn 用的廣泛，上層很多組件都要支持，所以很受歡迎，對(duì)其優(yōu)化很多。

Azkaban 是資源調(diào)度的小眾分支，用的人不多。

05. 大數(shù)據(jù)查詢
1. 大數(shù)據(jù)查詢引擎

常用的OLAP引擎對(duì)比：


專家觀點(diǎn)： 專家之一曾經(jīng)用 Presto 和 StarRocks 做過對(duì)比 Impala 的性能測(cè)試，結(jié)論如下：

● 結(jié)果上看 StarRocks 的性能確實(shí)很強(qiáng)大，速度最快，但三者對(duì)比提升相同量級(jí)的性能需要更多的 CPU、內(nèi)存資源等；
● Impala 在開啟各項(xiàng)優(yōu)化之后，效果是可以接近 StarRocks 的；
● Presto 性能一般，而且發(fā)現(xiàn)跑部分 TPC-DS 測(cè)試時(shí)，調(diào)用 HMS API 的頻率偶爾很高，曾經(jīng)把 HMS 搞掛過。但是 Presto 的易用性感覺最好，差不多就是開箱即用，配置很簡單。支持多源數(shù)據(jù)（多Catalog）的接入，但是隨著數(shù)據(jù)湖對(duì)底層數(shù)倉存儲(chǔ)層的統(tǒng)一加上各個(gè)。其他高效分析引擎對(duì)數(shù)據(jù)湖的支持，這塊的優(yōu)勢(shì)也會(huì)被逐步抹平。

專家對(duì)查詢引擎優(yōu)化的觀點(diǎn)：

查詢引擎優(yōu)化在大數(shù)據(jù)平臺(tái)架構(gòu)只算一環(huán)，不算難點(diǎn)，但確實(shí)很重要。整個(gè)大數(shù)據(jù)生態(tài)的上下游優(yōu)化應(yīng)該是逐步協(xié)同進(jìn)行的，查詢引擎上游的數(shù)據(jù)是需要下功夫治理的，不然 Impala 遇到比如小文件問題是很拖累性能的；查詢引擎下游需要一個(gè)合適的平臺(tái)作為數(shù)據(jù)的展示窗口，比如 BI 工具，或用協(xié)議比較通用的客戶端，像支持 MySQL 協(xié)議的 SR 和 Doris 這些，如果下游沒法做比較好的數(shù)據(jù)展示，查詢引擎再牛也沒法讓大家用起來。

2. 大數(shù)據(jù)查詢優(yōu)化工具

大數(shù)據(jù)查詢優(yōu)化工具包括 Alluxio、JuiceFS 和 JindoFS。

專家觀點(diǎn)：

Alluxio：

數(shù)據(jù)編排最為強(qiáng)大，市面上常見的存儲(chǔ)系統(tǒng)、云存儲(chǔ)服務(wù)均可以直接接入，也可以自行實(shí)現(xiàn)相關(guān) api 以接入其他自研存儲(chǔ)系統(tǒng)，可以說 Alluxio 最為通用，既可用于云存儲(chǔ)服務(wù)的緩存接入或數(shù)據(jù)編排，也可作為傳統(tǒng) HDFS 的多集群數(shù)據(jù)編排。

JuiceFS：

● 提供了和 Alluxio 非常相似的功能，如元數(shù)據(jù)與數(shù)據(jù)分離的存儲(chǔ)、數(shù)據(jù)編排、與 Hadoop API 兼容、Fuse 等特性；

● JuiceFS 也有不錯(cuò)的數(shù)據(jù)編排特性，元數(shù)據(jù)存儲(chǔ)的方式比 Alluxio 更多元，主要用于云存儲(chǔ)場(chǎng)景。

JindoFS：

● 局限于阿里云 oss 場(chǎng)景的分布式存儲(chǔ)系統(tǒng)；

● 支持與 Alluxio 非常相似的功能，也能提供內(nèi)存級(jí)的緩存加速；

● 但場(chǎng)景局限于 oss 內(nèi)。

二、數(shù)據(jù)倉庫演進(jìn)
01. 標(biāo)準(zhǔn)化
1. 數(shù)據(jù)治理

數(shù)據(jù)倉庫的標(biāo)準(zhǔn)化主要指的是數(shù)據(jù)治理。數(shù)據(jù)治理是數(shù)倉落地應(yīng)用的核心問題，在近年受到越來越多的關(guān)注，其根本上是為了解決數(shù)據(jù)倉庫煙囪式開發(fā)帶來的資源浪費(fèi)等問題。


例如上圖所示，企業(yè)發(fā)展初期，因?yàn)闃I(yè)務(wù)模式不穩(wěn)定，多個(gè)業(yè)務(wù)線都有獨(dú)立研發(fā)的技術(shù)棧，到后期就會(huì)出現(xiàn)標(biāo)準(zhǔn)不統(tǒng)一、重復(fù)計(jì)算、模型依賴關(guān)系混亂的問題。


而經(jīng)過標(biāo)準(zhǔn)統(tǒng)一、底層邏輯屏蔽和不同粒度的匯總，各個(gè)業(yè)務(wù)線的技術(shù)棧得以統(tǒng)一，就能大大簡化模型計(jì)算鏈路、降低成本、提高速度。

也可以從數(shù)據(jù)建模的角度來理解這個(gè)問題。數(shù)據(jù)建模是數(shù)倉建設(shè)的核心環(huán)節(jié)之一，包括自上而下（范式建模，Inmon模式）和自下而上（維度建模，Kimball模式）兩種建模方式。

范式建模主要在電信、金融、政務(wù)、工業(yè)等傳統(tǒng)行業(yè)用的比較多，而互聯(lián)網(wǎng)由于業(yè)務(wù)變化很快，初期需要更加靈活的分布式?jīng)Q策結(jié)構(gòu)，因此維度建模會(huì)更加合適，但也因此基于Kimball模式建模的后期會(huì)出現(xiàn)數(shù)據(jù)孤島問題和治理需求。不過，專家表示，維度建模在前期若有指導(dǎo)思想或方法論的話，或許能提前避免這個(gè)問題。

在業(yè)界，數(shù)倉治理最核心的工作是改善數(shù)據(jù)質(zhì)量，數(shù)據(jù)的完整性、一致性等指標(biāo)都會(huì)影響最終的數(shù)據(jù)決策的好壞，這對(duì)于整個(gè)行業(yè)都是一個(gè)挑戰(zhàn)。因?yàn)閿?shù)據(jù)質(zhì)量僅僅通過簡單的唯一性校驗(yàn)、波動(dòng)性校驗(yàn)等手段是很難排查出業(yè)務(wù)波動(dòng)的根本原因的。

而除了人為制定規(guī)則以外，如今也有不少企業(yè)正在嘗試引入AI算法對(duì)質(zhì)量監(jiān)控進(jìn)行預(yù)測(cè)，目前技術(shù)上尚未成熟，但AI的潛力值得期待。

DataOPs是近期比較熱的概念，很大程度上也是圍繞數(shù)據(jù)質(zhì)量的工作，但其本質(zhì)和數(shù)據(jù)治理相差不遠(yuǎn)，關(guān)注數(shù)據(jù)生產(chǎn)的標(biāo)準(zhǔn)化、流程化、自動(dòng)化、智能化，也就是將越來越多大數(shù)據(jù)技術(shù)環(huán)節(jié)中的人工工作自動(dòng)化，也會(huì)開始結(jié)合AI技術(shù)，涉及開發(fā)和運(yùn)維過程。


上圖展示了一個(gè)數(shù)倉開發(fā)的工作流程，包括模型檢索、模型創(chuàng)建、ETL開發(fā)、作業(yè)發(fā)布、監(jiān)控報(bào)警等全流程的標(biāo)準(zhǔn)化、自動(dòng)化都是DataOPs關(guān)心的問題。

提到標(biāo)準(zhǔn)化和數(shù)據(jù)治理，又不得不提到數(shù)據(jù)中臺(tái)。目前業(yè)界對(duì)于數(shù)據(jù)中臺(tái)都有不同的解釋，有專家對(duì)DataFun表示，數(shù)據(jù)倉庫和數(shù)據(jù)中臺(tái)其實(shí)是相對(duì)的概念。

實(shí)際上，中小企業(yè)通常只限于搭建數(shù)據(jù)倉庫，很多中小企業(yè)聲稱的數(shù)據(jù)中臺(tái)其實(shí)也是局限于某個(gè)業(yè)務(wù)的數(shù)據(jù)倉庫，不是真正的數(shù)據(jù)中臺(tái)。

真正的數(shù)據(jù)中臺(tái)主要在大企業(yè)，其中每個(gè)部門都擁有一個(gè)數(shù)倉體系，那么每個(gè)部門相當(dāng)于一個(gè)小型公司。而在業(yè)務(wù)發(fā)展中后期會(huì)出現(xiàn)數(shù)據(jù)一致性、數(shù)據(jù)標(biāo)準(zhǔn)等方面的困難，因而就產(chǎn)生數(shù)據(jù)治理和建設(shè)中臺(tái)的需求。這也意味著，數(shù)據(jù)治理通常只在大企業(yè)中有足夠的需求。

2. 流批一體

數(shù)據(jù)治理在標(biāo)準(zhǔn)化方面的一大特點(diǎn)是將并行的業(yè)務(wù)線進(jìn)行合并。實(shí)際上，這種合并統(tǒng)一的趨勢(shì)不僅存在于業(yè)務(wù)邏輯和數(shù)據(jù)層面，其根本上還存在于存儲(chǔ)、計(jì)算、處理等底層邏輯中。存儲(chǔ)、計(jì)算、處理的兩種基本的開發(fā)模式是離線計(jì)算和實(shí)時(shí)計(jì)算，因此數(shù)倉標(biāo)準(zhǔn)化的另一個(gè)方向是流批一體。

流批一體除了解決多條技術(shù)棧之間的標(biāo)準(zhǔn)不統(tǒng)一之外，還有一大好處就在于成本層面。在發(fā)展到一定階段的時(shí)候，離線數(shù)倉通常已經(jīng)無法滿足業(yè)務(wù)需求了。而實(shí)時(shí)數(shù)倉對(duì)于下游的成本比較高，普惠性不足。

根據(jù)一些分析結(jié)果，批計(jì)算的成本和數(shù)據(jù)體量大致呈線性關(guān)系，而流計(jì)算的成本卻隨著數(shù)據(jù)體量的增長而呈指數(shù)級(jí)增長，背后原因包括隨機(jī)IO、存算不分離、寫放大等。因而實(shí)時(shí)計(jì)算一般不直接面向業(yè)務(wù)，更多面向算法或數(shù)據(jù)工具。

另外，流批一體能夠?qū)崿F(xiàn)狀態(tài)復(fù)用，很多時(shí)候這是有必要的，因?yàn)殡x線計(jì)算在取數(shù)的時(shí)候，經(jīng)常會(huì)遇到數(shù)據(jù)有效期不足的問題，而復(fù)用實(shí)時(shí)計(jì)算的結(jié)果就能很好地解決這個(gè)問題。

總體而言，流批一體架構(gòu)的好處是解決流批不統(tǒng)一帶來的數(shù)據(jù)不一致、開發(fā)成本、使用成本、運(yùn)維成本問題。

人們一般默認(rèn)流批一體的解決方案是Kappa架構(gòu)，采用Kafka和Flink也就是消息隊(duì)列和實(shí)時(shí)計(jì)算引擎的組合。


但Kappa架構(gòu)嚴(yán)重依賴消息隊(duì)列的順序處理，而在順序存儲(chǔ)上進(jìn)行OLAP分析是比較困難的。


因此在業(yè)界，許多企業(yè)開始探索通過數(shù)據(jù)湖方案實(shí)現(xiàn)流批一體，比如Iceberg支持讀寫分離，又支持并發(fā)讀、增量讀、小文件合并，還可以支持秒級(jí)到分鐘級(jí)的延遲，因此可以實(shí)現(xiàn)近實(shí)時(shí)數(shù)據(jù)接入。


同時(shí)，Iceberg底層依賴列式存儲(chǔ)，用于替換Kafka后就可以對(duì)OLAP分析進(jìn)行基本的優(yōu)化，在中間層直接用Flink執(zhí)行批式計(jì)算或流式計(jì)算。最后，再結(jié)合Alluxio的緩存能力，就可以對(duì)近實(shí)時(shí)的數(shù)據(jù)湖架構(gòu)進(jìn)一步加速。

盡管如此，目前在業(yè)界，無論是流批一體還是數(shù)據(jù)湖，其技術(shù)發(fā)展都還存在很大挑戰(zhàn)。據(jù)專家反饋，業(yè)界的方案基本都局限于部分場(chǎng)景，距離通用方案還很遙遠(yuǎn)。

流批一體的含義包含了多個(gè)層次，首先是存儲(chǔ)流批一體，其次是計(jì)算流批一體，最后是處理結(jié)果的流批一體，也就是讓同一段代碼在分別做批處理和流處理時(shí)，得到的結(jié)果是一致的，而這通常也是最難的。

02. 實(shí)時(shí)處理
1. 實(shí)時(shí)查詢

流批一體技術(shù)的需求自然來源于實(shí)時(shí)計(jì)算的發(fā)展。如今越來越多的服務(wù)面向ToC用戶，實(shí)時(shí)性需求越來越強(qiáng)，這些業(yè)務(wù)包括了風(fēng)控事件處理，搜廣推的實(shí)時(shí)特征計(jì)算，以及指標(biāo)監(jiān)控等等，實(shí)時(shí)數(shù)倉的開發(fā)也愈發(fā)受到企業(yè)的重視和投入。

目前而言，業(yè)界最關(guān)心的數(shù)據(jù)倉庫核心性能指標(biāo)是查詢的實(shí)時(shí)性。性能指標(biāo)設(shè)置對(duì)于業(yè)務(wù)成長非常重要，背后的考慮因素有兩個(gè)，一個(gè)是性能本身會(huì)導(dǎo)致數(shù)據(jù)產(chǎn)出的延遲，另一個(gè)是性能差一般也代表著資源消耗大。

提高數(shù)據(jù)處理實(shí)時(shí)性的解決方案類型主要有兩種，包括：數(shù)據(jù)和業(yè)務(wù)邏輯優(yōu)化（主要指數(shù)據(jù)治理）、底層計(jì)算引擎優(yōu)化。

其中，底層計(jì)算引擎的優(yōu)化也是大企業(yè)比較常用的方法，常用的選型包括Spark、Flink、Blink等。

但嚴(yán)格來說，對(duì)于大企業(yè)而言，一般不存在選型的概念。專家表示，因?yàn)榇笃髽I(yè)一般都有成熟的大數(shù)據(jù)平臺(tái)，里面包括了采集、模型設(shè)計(jì)等模塊，經(jīng)過優(yōu)化和協(xié)同，這些組件都已經(jīng)封裝成了一套完整的體系。

但對(duì)于中小企業(yè)來說，他們一般很難抉擇如何做具體的選型，一般都是考慮模仿大企業(yè)的架構(gòu)，或者直接購買大企業(yè)的平臺(tái)產(chǎn)品。

2. 流式ETL

除了查詢以外，數(shù)倉中另一個(gè)消耗資源較大的流程是ETL。在業(yè)界，數(shù)倉比較常用的ETL模式是增量ETL和全量ETL。

數(shù)倉ETL通常面臨的核心挑戰(zhàn)是高效實(shí)施，也就是如何用最低資源產(chǎn)出最多成果，另一個(gè)是數(shù)據(jù)質(zhì)量。

除了增量ETL、全量ETL之外，還有一種ETL的模式是流式ETL，自然也是源于實(shí)時(shí)計(jì)算的業(yè)務(wù)需求，據(jù)專家介紹，目前在業(yè)界的成熟度還比較低。

03. 整體衡量
專家表示，對(duì)數(shù)據(jù)模型的優(yōu)劣判斷（比如數(shù)據(jù)的業(yè)務(wù)覆蓋率、數(shù)據(jù)的業(yè)務(wù)使用率等），目前行業(yè)內(nèi)還缺乏統(tǒng)一的、成熟的衡量指標(biāo)。而數(shù)據(jù)模型是數(shù)倉的核心，其優(yōu)劣判斷關(guān)系到數(shù)倉整體能力的判斷，重要性很高。

04. 總結(jié)
通過以上分析可知，除了標(biāo)準(zhǔn)化、模塊化、實(shí)時(shí)處理、整體衡量等發(fā)展特點(diǎn)以外，數(shù)據(jù)倉庫也還面臨許多整體層面的挑戰(zhàn)，包括解決方案通用性、整體衡量標(biāo)準(zhǔn)等。

目前業(yè)界正在投入數(shù)據(jù)編織、DataOPs等方向，使得數(shù)據(jù)倉庫在標(biāo)準(zhǔn)化、模塊化等方面走的更遠(yuǎn)，并實(shí)現(xiàn)更強(qiáng)的通用性，從而實(shí)至名歸地演化成數(shù)據(jù)中臺(tái)、數(shù)據(jù)湖等架構(gòu)，適應(yīng)數(shù)據(jù)智能業(yè)務(wù)不斷增長的規(guī)?；?、多樣化、產(chǎn)品化需求。


作者： 大數(shù)據(jù)球球


歡迎關(guān)注微信公眾號(hào) ：大數(shù)據(jù)球球