網(wǎng)管產(chǎn)品需要從數(shù)據(jù)倉庫的角度來看，才能獲得完整的視圖。數(shù)據(jù)集成真正從大數(shù)據(jù)的角度來看，才能明白其中的挑戰(zhàn)。一個運(yùn)行了近20年的數(shù)據(jù)架構(gòu)，必然有其合理性。也正是因?yàn)槟甏眠h(yuǎn)，存量過多，才導(dǎo)致舉步維艱。在Cloud和5G時代，超密度網(wǎng)絡(luò)集成和大數(shù)據(jù)洞察需求給電信供應(yīng)商帶來新的挑戰(zhàn)，從數(shù)據(jù)倉庫到數(shù)據(jù)湖，不僅僅架構(gòu)的變革，更是思維方式的升級。本文淺談筆者在組織中看見的技術(shù)嬗變和演進(jìn)。

01

數(shù)據(jù)倉庫歷史沿革

1970年，關(guān)系數(shù)據(jù)庫的研究原型System R 和INGRES開始出現(xiàn)，這兩個系統(tǒng)的設(shè)計(jì)目標(biāo)都是面向on-line transaction processing (OLTP)的應(yīng)用。關(guān)系數(shù)據(jù)庫的真正可用產(chǎn)品直到1980年才出現(xiàn)，分別是DB2 和INGRES。其他的數(shù)據(jù)庫，包括Sybase, Oracle, 和Informix都遵從了相同的數(shù)據(jù)庫基本模型。關(guān)系數(shù)據(jù)庫的特點(diǎn)是按照行存儲關(guān)系表，使用B樹或衍生的樹結(jié)構(gòu)作為索引和基于代價的優(yōu)化器，提供ACID的屬性保證。

到1990年，一個新的趨勢開始出現(xiàn)：企業(yè)為了商業(yè)智能的目的，需要把多個操作數(shù)據(jù)庫中數(shù)據(jù)收集到一個數(shù)據(jù)倉庫中。盡管投資巨大且功能有限，投資數(shù)據(jù)倉庫的企業(yè)還是獲得了不錯的投資回報率。從此，數(shù)據(jù)倉庫開始支撐各大企業(yè)的商業(yè)決策過程。數(shù)據(jù)倉庫的關(guān)鍵技術(shù)包括數(shù)據(jù)建模，ETL技術(shù)，OLAP技術(shù)和報表技術(shù)等。

目前主要的數(shù)據(jù)倉庫產(chǎn)品供應(yīng)商包括Oracle、IBM、Microsoft、SAS、Teradata、Sybase、Business Objects(已被SAP收購)等。

電信行業(yè)是最早采用數(shù)據(jù)倉庫技術(shù)的行業(yè)之一。由于電信公司運(yùn)行在一個快速變化和高速競爭的環(huán)境，擁有大量的客戶基礎(chǔ)，從而產(chǎn)生和存儲海量的高質(zhì)量數(shù)據(jù)。電信公司利用數(shù)據(jù)挖掘技術(shù)降低營銷成本，識別欺詐，并更好地管理其電信網(wǎng)絡(luò)。

02

數(shù)據(jù)倉庫概念

數(shù)據(jù)倉庫之父Bill Inmon在1991年出版的“Building the Data Warehouse”一書中所提出的定義被廣泛接受——數(shù)據(jù)倉庫(Data Warehouse)是一個面向主題的(Subject Oriented)、集成的(Integrated)、相對穩(wěn)定的(Non-Volatile)、反映歷史變化(Time Variant)的數(shù)據(jù)集合，用于支持管理決策(Decision Making Support)。這是一個偏向?qū)W術(shù)的定義，卻非常準(zhǔn)確的界定了數(shù)據(jù)倉庫與其他數(shù)據(jù)庫系統(tǒng)的本質(zhì)區(qū)別。

“A data warehouseis a subject-oriented, integrated, time-variant, and nonvolatile collection ofdata in support of management’s decision-making process.”

—W. H. Inmon

要理解數(shù)據(jù)倉庫的概念，需要從與數(shù)據(jù)庫的系統(tǒng)的對比來看。

數(shù)據(jù)庫是作為“所有處理的單一數(shù)據(jù)源”出現(xiàn)和定義的。數(shù)據(jù)庫的出現(xiàn)有兩個驅(qū)動因素，第一是70年代以前大量應(yīng)用程序和主文件的分散存放導(dǎo)致一片混亂和大量冗余數(shù)據(jù)。第二是直接存取存儲設(shè)備的出現(xiàn)使得按記錄尋址成為可能?；贒BMS的在線事務(wù)處理為商業(yè)發(fā)展開辟全新的視野。

數(shù)據(jù)庫系統(tǒng)的設(shè)計(jì)目標(biāo)是事務(wù)處理。數(shù)據(jù)庫系統(tǒng)是為記錄更新和事務(wù)處理而設(shè)計(jì)，數(shù)據(jù)的訪問的特點(diǎn)是基于主鍵，大量原子，隔離的小事務(wù)，并發(fā)和可恢復(fù)是關(guān)鍵屬性，最大事務(wù)吞吐量是關(guān)鍵指標(biāo)，因此數(shù)據(jù)庫的設(shè)計(jì)都反映了這些需求。

數(shù)據(jù)倉庫的設(shè)計(jì)目標(biāo)是決策支持。歷史的，摘要的，聚合的數(shù)據(jù)比原始的記錄重要的多。查詢負(fù)載主要集中在即席查詢和包含連接，聚合等操作的復(fù)雜查詢。相對于數(shù)據(jù)庫系統(tǒng)來說，查詢吞吐量和響應(yīng)時間比事務(wù)處理吞吐量重要的多。

數(shù)據(jù)倉庫和數(shù)據(jù)庫系統(tǒng)的區(qū)別，一言蔽之：OLAP和OLTP的區(qū)別。數(shù)據(jù)庫支持是OLTP，數(shù)據(jù)倉庫支持的是OLAP。

對 OLTP 和OLAP 的區(qū)別還可以有一個維度，就是及時性需求。OLTP對事務(wù)的及時性需求較高，而OLAP 則不然。

——曹洪偉

數(shù)據(jù)倉庫一般基于數(shù)據(jù)庫實(shí)現(xiàn)，但是為部署和維護(hù)上是分離的。數(shù)據(jù)倉庫可以是基于關(guān)系數(shù)據(jù)庫實(shí)現(xiàn)的，這樣的數(shù)據(jù)倉庫被稱為ROLAP。數(shù)據(jù)倉庫也可以是基于多維數(shù)據(jù)結(jié)構(gòu)實(shí)現(xiàn)的，這樣的數(shù)據(jù)倉庫被稱為MOLAP。

03

數(shù)據(jù)倉庫架構(gòu)

數(shù)據(jù)倉庫是一種體系結(jié)構(gòu)，而不是一種技術(shù)。數(shù)據(jù)倉庫最為核心的內(nèi)容分類兩部分：

基于關(guān)系數(shù)據(jù)庫的多維建模(RDBMS-based dimensional modeling)

基于數(shù)據(jù)立方體的OLAP查詢(cube-based OLAP)

數(shù)據(jù)倉庫體系結(jié)構(gòu)包含了從外部數(shù)據(jù)源或者數(shù)據(jù)庫抽取數(shù)據(jù)的ETL工具。ETL還負(fù)責(zé)數(shù)據(jù)的轉(zhuǎn)換，清洗，然后加載到數(shù)據(jù)倉庫的存儲中。一般來說，數(shù)據(jù)都會加載到存取速度較慢的存儲中，以原始數(shù)據(jù)的方式保存下來。為了提高查詢效率，原始數(shù)據(jù)會按主題分類，以聚合的方式存儲到數(shù)據(jù)集市中，稱之為聚合數(shù)據(jù)。參見下圖，原始數(shù)據(jù)往往有多條聚合路徑，時間維度是一個最基本的內(nèi)置聚合路徑，行政級別劃分也是一種常見的聚合路徑，產(chǎn)品屬性也是常見的聚合路徑。

數(shù)據(jù)倉庫體系結(jié)構(gòu)中還包括前端的查詢工具，報表工具和數(shù)據(jù)挖掘工具，被稱為front-end。

最后也是最重要的是，數(shù)據(jù)倉庫體系結(jié)構(gòu)中都會包含一個構(gòu)建數(shù)據(jù)倉庫的元數(shù)據(jù)倉庫。元數(shù)據(jù)倉庫包括數(shù)據(jù)庫schema，view，用于ETL的metadata，用于數(shù)據(jù)聚合的metadata，用于報表呈現(xiàn)的metadata和SQL模板等。數(shù)據(jù)倉庫往往采用meta data driven的架構(gòu)設(shè)計(jì)，這個元數(shù)據(jù)倉庫就至關(guān)重要。

下圖即是我所在的從事數(shù)據(jù)倉庫集成工具開發(fā)的團(tuán)隊(duì)(負(fù)責(zé)生成ETL metadata，Database Schema，Pre-aggregation metadata，Reporter metadata，etc.)。名字是KOALA，slogon是讓生活更簡單。

[[182380]]

上文中提到的維度的概念。維度(dimension)是觀察事物的角度，也是數(shù)據(jù)庫事實(shí)表中用來描述數(shù)據(jù)分類的層次結(jié)構(gòu)。維度在數(shù)據(jù)中就是表示為列，在SQL中用作過濾和分組。

像上圖這樣對數(shù)據(jù)進(jìn)行多個維度的抽象并借助于數(shù)據(jù)庫的select，group by等基本操作形成的OLAP多維數(shù)據(jù)操作(roll up，drill down，slice and dice，pivot)被稱為多維數(shù)據(jù)模型。為了方便復(fù)雜分析和可視化呈現(xiàn)，數(shù)據(jù)倉庫中數(shù)據(jù)往往以多維模型建模。每一個維度被稱為一個層級，三個維度構(gòu)成一個數(shù)據(jù)立方體。維度也通常用來過濾和分組，所以數(shù)據(jù)立方體稱之為group by的并。OLAP也被稱為在基于數(shù)據(jù)倉庫多維模型的基礎(chǔ)上實(shí)現(xiàn)的面向分析的各類操作的集合。

04

數(shù)據(jù)立方體

數(shù)據(jù)立方體只是多維模型的一個形象的說法。立方體其本身只有三維，但多維模型不僅限于三維模型，可以組合更多的維度，但一方面是出于更方便地解釋和描述，同時也是給思維成像和想象的空間;另一方面是為了與傳統(tǒng)關(guān)系型數(shù)據(jù)庫的二維表區(qū)別開來，于是就有了數(shù)據(jù)立方體的稱呼(見下圖)。

OLAP的操作是以查詢——也就是數(shù)據(jù)庫的SELECT操作為主，但是查詢可以很復(fù)雜，比如基于關(guān)系數(shù)據(jù)庫的查詢可以多表關(guān)聯(lián)，可以使用COUNT、SUM、AVG等聚合函數(shù)。OLAP的多維分析操作包括：鉆取(Drill-down)、上卷(Roll-up)、切片(Slice)、切塊(Dice)以及旋轉(zhuǎn)(Pivot)，逐一解釋如下：

Roll up (drill-up): summarize data by climbing up hierarchy or by dimension reduction

Drill down (roll down): reverse of roll-up,from higher level summary to lower level summary or detailed data, or introducing new dimensions

Slice and dice: project and select

Pivot (rotate): reorient the cube, visualization, 3D to series of 2D planes

看了上圖中數(shù)據(jù)立方體的各種操作，有人覺得還是很抽象。下面給一個SQL的例子，說明數(shù)據(jù)立方體的具體操作。

select//公式必須配合group by使用

tmp.time,  
tmp.id1, 
tmp.id2, 
SUM(counter1) counter1, 
SUM(counter2) counter2 

from//雙層SQL，實(shí)現(xiàn)聚合路徑

(

select//trunc實(shí)現(xiàn)時間維度的變化

trunc( p.time, 'min' ) time,  
"country".country_id id1,  
"city".city_id id2,  
SUM(p.counter1) counter1,  
SUM(p.counter2) counter2  
from  
table "country"，  
table "city"，  
table p 

where//選擇計(jì)算的城市

"city".city_id in ( '北京','上海','廣州' )  
and time >= to_date('2016/01/01 00:00:00', 'yyyy/mm/dd hh24:mi:ss')  
and time < to_date('2017/01/01 00:00:00', 'yyyy/mm/dd hh24:mi:ss') 

group by//改變行政維度

trunc( p.period_start_time, 'mi' ),  
"country".country_id,  
"city".city_id  
) tmp 

group by//行政維護(hù)可以不變

tmp.time, 
tmp.id1, 
tmp.id2 

OLAP的優(yōu)勢是基于數(shù)據(jù)倉庫面向主題、集成的、保留歷史及不可變更的數(shù)據(jù)存儲，以及多維模型多視角多層次的數(shù)據(jù)組織形式，如果脫離的這兩點(diǎn)，OLAP將不復(fù)存在，也就沒有優(yōu)勢可言?；诙嗑S模型的數(shù)據(jù)組織讓數(shù)據(jù)的展示更加直觀，它就像是我們平?？创鞣N事物的方式，可以從多個角度多個層面去發(fā)現(xiàn)事物的不同特性，而OLAP正是將這種尋常的思維模型應(yīng)用到了數(shù)據(jù)分析上。

05

數(shù)據(jù)庫建模

如果把多維數(shù)據(jù)模型映射到關(guān)系數(shù)據(jù)庫和SQL查詢上(ROLAP)，數(shù)據(jù)庫該如何設(shè)計(jì)呢?

大多數(shù)數(shù)據(jù)倉庫都采用“星型模型”來表示多維數(shù)據(jù)模型。在星型模型中，只有一個事實(shí)表，并且每一個維度有一個單獨(dú)的表。事實(shí)表中的每一個元組都是一個外鍵指向維度表的主鍵。每一個維度表的列是組成這個維度的所有屬性。如下圖所示。

另外一個常見的數(shù)據(jù)庫設(shè)計(jì)方法是“雪花模型”。雪花模型通過定義單獨(dú)的維度表，改進(jìn)了星型模型中沒有明確提供維度層級的問題。是謂維度表的正則化，如下圖。但星型模型更適合瀏覽維度層級。

除了事實(shí)表和維度表，數(shù)據(jù)倉庫還需要創(chuàng)建pre-aggregation 表用于存儲挑選的摘要數(shù)據(jù)。

06

大數(shù)據(jù)架構(gòu)

1010data公司高級軟件工程師ADAM JACOBS博士在ACM通訊發(fā)表的《大數(shù)據(jù)病理學(xué)》指出大數(shù)據(jù)的病理在于分析而不在于存儲——我們期望從成年累月積累的數(shù)據(jù)中在幾分鐘或者幾秒內(nèi)獲得分析結(jié)果!其實(shí)作者指出了關(guān)系數(shù)據(jù)庫的在大數(shù)據(jù)時代的病理，如下圖所示一個數(shù)據(jù)倉庫分析操作的SQL在數(shù)據(jù)量超過100萬條記錄時的性能表現(xiàn)。

The pathologies of big data are primarily those of analysis

因此，數(shù)據(jù)倉庫被認(rèn)為是對數(shù)據(jù)庫查詢性能問題的一個解決方案。在90年代，人們已經(jīng)都面臨一個數(shù)據(jù)爆炸的挑戰(zhàn)，為了解決那個時代的“大數(shù)據(jù)”問題，數(shù)據(jù)倉庫應(yīng)運(yùn)而生。

在1980s早期，大數(shù)據(jù)是指數(shù)據(jù)集超出了磁帶機(jī)的處理能力。

在1990s，大數(shù)據(jù)是指數(shù)據(jù)集超出了Microsoft Excel或者桌面PC的處理能力。

今天，大數(shù)據(jù)是指數(shù)據(jù)集超出了關(guān)系數(shù)據(jù)庫的處理能力。

站在大數(shù)據(jù)時代回望數(shù)據(jù)架構(gòu)的發(fā)展歷史，然后思考大數(shù)據(jù)的定義：

當(dāng)前流行的技術(shù)處理不了的數(shù)據(jù)，都是大數(shù)據(jù)。

數(shù)據(jù)倉庫的本質(zhì)是把數(shù)據(jù)變小，一般有兩個方法：

第一是通過抽取，轉(zhuǎn)換，加載，清洗。

第二是通過pre-aggregation獲得數(shù)據(jù)的一份單獨(dú)拷貝。因此數(shù)據(jù)倉庫被定義為：

為了方便查詢分析，把數(shù)據(jù)從關(guān)系數(shù)據(jù)庫中單獨(dú)拷貝一份出來，然后通過ETL或者ELT轉(zhuǎn)換。

對于大數(shù)據(jù)，僅僅簡單構(gòu)建一個數(shù)據(jù)倉庫是不夠的。數(shù)據(jù)應(yīng)該如何結(jié)構(gòu)化才能更便于分析?數(shù)據(jù)庫和分析工具應(yīng)該如何設(shè)計(jì)才能更高效的處理大數(shù)據(jù)?

意識到大數(shù)據(jù)固有的時間屬性和空間屬性，是我們理解關(guān)系數(shù)據(jù)庫處理大數(shù)據(jù)時存在性能問題的重要前提。如果說數(shù)據(jù)是我對世界的觀察記錄的話，大數(shù)據(jù)是我們對世界在時間和/或空間維度的重復(fù)觀察。這就是大數(shù)據(jù)的時空特點(diǎn)，也是數(shù)據(jù)倉庫多維模型的構(gòu)建原理。當(dāng)今的主流數(shù)據(jù)庫模型是關(guān)系數(shù)據(jù)庫，并且該模型顯式地忽略表中的行的順序。這將不可避免導(dǎo)致應(yīng)用以非順序的方式查詢數(shù)據(jù)。在這種情況下，傳統(tǒng)的數(shù)據(jù)架構(gòu)可以通過引入緩存的方式緩解性能問題，而大數(shù)據(jù)則會大大放大了次優(yōu)訪問模式對性能的影響。如下圖所示隨機(jī)訪問和順序訪問的差別。

因此我們要引入，也是我們要推導(dǎo)的結(jié)論：逆正則化(逆規(guī)范化)和順序存儲，不可更改數(shù)據(jù)集(append only，immutable data set)。順著存儲棧往下走，直到數(shù)據(jù)存儲格式。

是時候放棄關(guān)系數(shù)據(jù)庫了。

簡單解釋一下逆正則化(逆規(guī)范化)。經(jīng)典關(guān)系數(shù)據(jù)庫介紹的所有范式指導(dǎo)思想都是正則化，減少重復(fù)數(shù)據(jù)，如果重復(fù)，則單獨(dú)創(chuàng)建一個表，使用外鍵關(guān)聯(lián)，目的是節(jié)省存儲空間(那個時候存儲很昂貴)。逆正則化則是允許列之間的重復(fù)。如下圖所示。

我有一個看法，NoSQL的鍵值存儲即是用極簡的非結(jié)構(gòu)化來實(shí)現(xiàn)結(jié)構(gòu)化存儲的逆規(guī)范化。

鍵值是極簡的結(jié)構(gòu)化，也是極簡的非結(jié)構(gòu)化。

關(guān)于順序存儲，不可更改數(shù)據(jù)集，可以參考Pat Helland《Immutability Changes Everything》，和我上面的介紹是一致的。

關(guān)于傳統(tǒng)關(guān)系數(shù)據(jù)庫的討論還有數(shù)據(jù)庫知名專家，2015年圖靈獎得主Michael Stonebraker撰寫的《One Size Fits All》，分別從數(shù)據(jù)倉庫和流處理兩個方面探討了數(shù)據(jù)庫25年來一招不變的靈丹妙藥已經(jīng)不再適合現(xiàn)在的業(yè)務(wù)發(fā)展。文章的中心思想和Pat Helland提出lambda架構(gòu)也有異曲同工之妙。

speed layer 
(i) compensates for the high latency of updates to the serving layer  
(ii) deals with recent data only 
serving layer 
(i) indexes the batch views  
(ii) Can be queried in low-latency, ad-hoc way 
batch layer 
(i) managing the master dataset (an immutable, append-only set of raw data), 
(ii) pre-compute the batch views 

Lambda架構(gòu)統(tǒng)一了傳統(tǒng)數(shù)據(jù)倉庫時代的半實(shí)時在線查詢，剛剛興起的實(shí)時流處理(Online )，和批處理數(shù)據(jù)分析(Offline)，給數(shù)據(jù)架構(gòu)的設(shè)計(jì)人員提供了一個全面的參考。

再結(jié)合半結(jié)構(gòu)化，結(jié)構(gòu)化數(shù)據(jù)存儲，SQL and No-SQL混合，我們可以得到下面一個典型的數(shù)據(jù)架構(gòu)：

上面的討論是架構(gòu)的微觀考慮，讓我們回到大數(shù)據(jù)架構(gòu)的宏觀指導(dǎo)上來。

目前業(yè)界對大數(shù)據(jù)的一個共識的定義是5個V。如下圖所示。

從技術(shù)的角度需要專注于其中的三個V，通過閱讀大量文獻(xiàn)，我得到下面一個范型：

借力開源軟件處理數(shù)據(jù)多樣性挑戰(zhàn)

使用分布式技術(shù)解決數(shù)據(jù)容量問題

使用實(shí)時流處理技術(shù)解決數(shù)據(jù)速度問題

傳統(tǒng)的OLAP 而言，實(shí)時性需求不明顯，實(shí)時分析的強(qiáng)需求是導(dǎo)致大數(shù)據(jù)技術(shù)的一個原因。

——曹洪偉

基于此，我個人推薦的大數(shù)據(jù)架構(gòu)是BDAS, the Berkeley Data Analytics Stack。這個架構(gòu)中不僅包含上面提到的三個思考維度，還提供了整個大數(shù)據(jù)架構(gòu)blueprint。內(nèi)容很多，使用時各個擊破，在此不贅述。

談了那么多，總結(jié)一下大數(shù)據(jù)架構(gòu)的幾個要點(diǎn)：

分布式計(jì)算

實(shí)時流處理

Online和Offline

SQL和No-SQL：混合架構(gòu)也是演進(jìn)路徑之一

逆正則化(逆規(guī)范化)和順序存儲，不可更改數(shù)據(jù)集

07

數(shù)據(jù)湖架構(gòu)

Pentaho的CTO James Dixon 在2011年提出了“Data Lake”的概念。在面對大數(shù)據(jù)挑戰(zhàn)時，他聲稱：不要想著數(shù)據(jù)的“倉庫”概念，想想數(shù)據(jù) 的“湖”概念。數(shù)據(jù)“倉庫”概念和數(shù)據(jù)湖概念的重大區(qū)別是：數(shù)據(jù)倉庫中數(shù)據(jù)在進(jìn)入倉庫之前需要是事先歸類，以便于未來的分析。這在OLAP時代很常見，但是對于離線分析卻沒有任何意義，不如把大量的原始數(shù)據(jù)線保存下來，而現(xiàn)在廉價的存儲提供了這個可能。

Nearly unlimited potential for operational insight and data discovery. As data volumes, data variety, and metadata richness grow, so does the benefit.

形象的來看，如下圖所示，數(shù)據(jù)湖架構(gòu)保證了多個數(shù)據(jù)源的集成，并且不限制schema，保證了數(shù)據(jù)的精確度。數(shù)據(jù)湖可以滿足實(shí)時分析的需要，同時也可以作為數(shù)據(jù)倉庫滿足批處理數(shù)據(jù)挖掘的需要。數(shù)據(jù)湖還為數(shù)據(jù)科學(xué)家從數(shù)據(jù)中發(fā)現(xiàn)更多的靈感提供了可能。

和數(shù)據(jù)倉庫對比來看，數(shù)據(jù)倉庫是高度結(jié)構(gòu)化的架構(gòu)，數(shù)據(jù)在轉(zhuǎn)換之前是無法加載到數(shù)據(jù)倉庫的，用戶可以直接獲得分析數(shù)據(jù)。而在數(shù)據(jù)湖中，數(shù)據(jù)直接加載到數(shù)據(jù)湖中，然后根據(jù)分析的需要再轉(zhuǎn)換數(shù)據(jù)。

下面我整理了數(shù)據(jù)倉庫和數(shù)據(jù)湖在多個維度的詳細(xì)對比。

總結(jié)起來，數(shù)據(jù)湖架構(gòu)有一下幾個顯著的特點(diǎn)：

數(shù)據(jù)存儲：大容量低成本

數(shù)據(jù)保真度：數(shù)據(jù)湖以原始的格式保存數(shù)據(jù)

數(shù)據(jù)使用：數(shù)據(jù)湖中的數(shù)據(jù)可以方便的被使用

延遲綁定：數(shù)據(jù)湖提供靈活的，面向任務(wù)的數(shù)據(jù)綁定，不需要提前定義數(shù)據(jù)模

當(dāng)然，對于數(shù)據(jù)湖架構(gòu)的批評也是不絕于耳。有人批評說，匯集各種雜亂的數(shù)據(jù)，應(yīng)該就是數(shù)據(jù)沼澤。Martin Fowler也對數(shù)據(jù)湖中數(shù)據(jù)的安全性和私密性提出了質(zhì)疑。

08

電信運(yùn)營大數(shù)據(jù)特點(diǎn)

電信運(yùn)營大數(shù)據(jù)對應(yīng)于TMN/FCAPS模型中的電信設(shè)備管理數(shù)據(jù)。如下圖所示。

Fault Management

Configuration Management

Accounting Management

Performance Management

Security Management

電信運(yùn)營數(shù)據(jù)的特點(diǎn)是數(shù)據(jù)多樣化要求不高，大多數(shù)數(shù)據(jù)是結(jié)構(gòu)化數(shù)據(jù)，數(shù)據(jù)容量要求不是特別高，數(shù)據(jù)的實(shí)時處理要求最高。

電信運(yùn)行數(shù)據(jù)架構(gòu)強(qiáng)調(diào)演進(jìn)。步步為營，向前兼容，不是一蹴而就的。

09

演進(jìn)路徑實(shí)踐

現(xiàn)在的架構(gòu)是一個典型的數(shù)據(jù)倉庫架構(gòu)。如下圖所示。現(xiàn)在的架構(gòu)設(shè)計(jì)有以下幾個要點(diǎn)：

ROLAP：基于Oracle數(shù)據(jù)庫，但并沒有用Oracle的數(shù)據(jù)倉庫，單獨(dú)構(gòu)建數(shù)據(jù)倉庫。

Meta Data Driven的架構(gòu)設(shè)計(jì)：Meta Data覆蓋整個數(shù)據(jù)pipe。當(dāng)新的數(shù)據(jù)需要集成，只需要編輯新的Meta Data，系統(tǒng)不需要做任何改變。

Schema設(shè)計(jì)：主要有兩類表：原始數(shù)據(jù)表和聚合表; 每類表都有三層結(jié)構(gòu)：表，用作聚合的視圖，用作報表的視圖。不同的應(yīng)用使用不同的視圖來操作數(shù)據(jù)。當(dāng)原始的數(shù)據(jù)表結(jié)構(gòu)變化時，可以根據(jù)需要更改不同層次的視圖。

Schema的演化。這是一個比較大的主題，關(guān)系數(shù)據(jù)是schema on write的，任何列的增加都需要alter表結(jié)構(gòu)，這會帶來客戶系統(tǒng)很長時間的downtime。因此原始表采用1000列的設(shè)計(jì)(Oracle支持的最大列數(shù))，并且列只增加，不減少，避免了數(shù)據(jù)庫schema的變化，降低不同release之間migration的成本。

數(shù)據(jù)存儲：定期清除原始數(shù)據(jù)，只保留聚合數(shù)據(jù)。

為什么現(xiàn)在的架構(gòu)需要演進(jìn)呢?

首先當(dāng)前架構(gòu)面臨擴(kuò)展性的挑戰(zhàn)。數(shù)據(jù)庫擴(kuò)展性主要依賴于Oracle RAC解決方案，Oracle RAC不是一個線性的擴(kuò)展方案，同時也增加了很多管理和維護(hù)成本。并且由于硬件的限制，垂直性擴(kuò)展不是一個長期的解決方案。

其次，當(dāng)前的存儲成本太昂貴，因此去IOE成為目標(biāo)。

第三，實(shí)時處理需求也是驅(qū)動架構(gòu)演進(jìn)的重要因素。

然后，架構(gòu)變成了這樣子：

傳統(tǒng) SQL 基于云平臺重新定義為 NewSQL，那么 Data Warehouse 也可以重新定義 New Data Warehouse。

——曹洪偉

這樣的架構(gòu)是不是New Data Warehouse，我不知道，可能是。在這樣的架構(gòu)下，最大的變化就是更換Oracle數(shù)據(jù)為HDFS，并使用SQL on Hadoop(比如Hive SQL，Spark SQL)等保持SQL接口，維持了前端分析引擎的不變。Meta Data部分依然保持了原來的數(shù)據(jù)建模，并沒有改變數(shù)據(jù)集成方式。這樣的架構(gòu)繼承了經(jīng)典的倉庫架構(gòu)，提高系統(tǒng)擴(kuò)展性，在滿足業(yè)務(wù)需求的同時，最大化的保護(hù)已有投資。

在架構(gòu)演進(jìn)這個過程中，有一些lesson learned：

SQL on Hadoop是必須的?？蛻粝Ｍ３諷QL接口的連續(xù)性。

混合數(shù)據(jù)倉庫架構(gòu)：針對不同的業(yè)務(wù)采用不同存儲方案(Oracle 和 HDFS)，數(shù)據(jù)量大的采用HDFS存儲，數(shù)據(jù)量不夠大的(不存在擴(kuò)展性挑戰(zhàn)的)可以依然使用關(guān)系型數(shù)據(jù)庫。

逆規(guī)范化對性能的影響重大。通過對逆規(guī)范設(shè)計(jì)，可以達(dá)到關(guān)系數(shù)據(jù)庫的查詢性能。但是對于逆規(guī)范化是否存在其他影響，還需要研究。

相對于sequence files 和RC files，ORC文件格式的性能是最好的。

實(shí)時pipe使用storm和Kafka實(shí)現(xiàn)。

就像 NewSQL 那樣，可以有 New Data Warehouse 的。就是 Data Warehouse與云計(jì)算的融合，即數(shù)據(jù)倉庫的存儲層在云平臺，采用分布式系統(tǒng)。對應(yīng)用側(cè)而言， 原有的方式依舊有效，這樣就不會資產(chǎn)浪費(fèi)，而是有效的繼承， 也是通往數(shù)據(jù)湖的一個較穩(wěn)妥的步驟。

——曹洪偉

老曹這么一說，豁然開朗。我們在談數(shù)據(jù)倉庫架構(gòu)向大數(shù)據(jù)架構(gòu)演進(jìn)的時候，其實(shí)我們在談New Data Warehouse架構(gòu)。就像當(dāng)初數(shù)據(jù)倉庫的出現(xiàn)是對數(shù)據(jù)庫系統(tǒng)存在的限制進(jìn)行補(bǔ)充一樣，目前的大數(shù)據(jù)平臺是對數(shù)據(jù)倉庫系統(tǒng)存在的問題進(jìn)行補(bǔ)充。他們的技術(shù)思路，技術(shù)架構(gòu)，用戶需求某種程度上是一致，或者說核心的思想是一致的。不一致的地方僅僅是為了滿足性能而做的技術(shù)方案的調(diào)整。

首先看數(shù)據(jù)集成架構(gòu)。如下圖，基于Hadoop的數(shù)據(jù)集成架構(gòu)和基于關(guān)系數(shù)據(jù)庫的傳統(tǒng)數(shù)據(jù)集成架構(gòu)是一致的。不同地方在于由于數(shù)據(jù)量的增大，左邊的架構(gòu)采用具有逆正則化(逆規(guī)范化)和順序存儲，不可更改數(shù)據(jù)集等特點(diǎn)的Hadoop平臺存儲數(shù)據(jù)。

其次看數(shù)據(jù)分析方法。雖然說基于Hadoop的數(shù)據(jù)集成架構(gòu)采用了Hadoop數(shù)據(jù)存儲平臺(內(nèi)置MapRdecue數(shù)據(jù)處理引擎)，其數(shù)據(jù)操作，數(shù)據(jù)分析方法在思想上是一致的——從大量的數(shù)據(jù)集中獲得由價值的信息——如下圖所示，數(shù)據(jù)倉庫的操作語句(group-by-aggregation)與MapRdecue的操作函數(shù)對應(yīng)關(guān)系。所以MapRdecue的核心思想就是把數(shù)據(jù)倉庫中的group-by-aggregation操作轉(zhuǎn)換成分布式執(zhí)行。所謂創(chuàng)新，大概如此吧。

The Map-Reduce programming model provides a good abstraction of group-by-aggregation operations over a cluster of machines.

The programmer provides a map function that performs grouping and a reduce function that performs aggregation.

The underlying run-time system achieves parallelism by partitioning the data and processing different partitions concurrently using multiple machines.

在New Data Warehouse架構(gòu)的基礎(chǔ)上，向Data Lake如何演進(jìn)?

對電信行業(yè)來說，NFV和SDN正在推動電信網(wǎng)絡(luò)設(shè)備控制平面和數(shù)據(jù)平面的分離，電信設(shè)備數(shù)據(jù)會走向數(shù)據(jù)湖架構(gòu)。電信設(shè)備數(shù)據(jù)融合，運(yùn)營數(shù)據(jù)融合，最終會走向一個大融合。

總結(jié)起來，電信大數(shù)據(jù)對于數(shù)據(jù)湖架構(gòu)的擁抱，來自于以下四個方面的驅(qū)動。我用四個推導(dǎo)公式，如下：

5G->BigData (Semi-Structured and Unstructured) -> Modern Data Architecture for Enterprise -> Data Lake Storage Architecture -> Data Lake

Cloud -> Network Function Cloudification -> Network Function Virtualization -> stateless VNF -> Distributed Sharing Storage -> Data Lake

Distributed analytics -> Data Lake

Hierarchy architecture -> Flat operations architecture -> Data Lake

我們嘗試過在數(shù)據(jù)加載過程中自學(xué)習(xí)的產(chǎn)生數(shù)據(jù)庫schema，證明這個思路是可行的?；诮Y(jié)構(gòu)化的數(shù)據(jù)，這個過程非常容易。但對于非結(jié)構(gòu)化的數(shù)據(jù)，還是存在很大的挑戰(zhàn)。使用機(jī)器學(xué)習(xí)的方式，模型訓(xùn)練成本恐怕和人工抽取schema的工作量是相當(dāng)?shù)摹＿@是開放的話題，可以討論。

【本文是51CTO專欄作者石頭的原創(chuàng)文章，轉(zhuǎn)載請通過作者微信公眾號補(bǔ)天遺石(butianys)獲取授權(quán)】

戳這里，看該作者更多好文