建站
咨詢
售后
建站咨詢
新聞中心
網(wǎng)管產(chǎn)品需要從數(shù)據(jù)倉庫的角度來看，才能獲得完整的視圖。數(shù)據(jù)集成真正從大數(shù)據(jù)的角度來看，才能明白其中的挑戰(zhàn)。一個運行了近20年的數(shù)據(jù)架構(gòu)，必然有其合理性。也正是因為年代久遠，存量過多，才導(dǎo)致舉步維艱。在Cloud和5G時代，超密度網(wǎng)絡(luò)集成和大數(shù)據(jù)洞察需求給電信供應(yīng)商帶來新的挑戰(zhàn)，從數(shù)據(jù)倉庫到數(shù)據(jù)湖，不僅僅架構(gòu)的變革，更是思維方式的升級。本文淺談筆者在組織中看見的技術(shù)嬗變和演進。
01
數(shù)據(jù)倉庫歷史沿革
1970年，關(guān)系數(shù)據(jù)庫的研究原型System R 和INGRES開始出現(xiàn)，這兩個系統(tǒng)的設(shè)計目標都是面向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ù)庫的特點是按照行存儲關(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è)之一。由于電信公司運行在一個快速變化和高速競爭的環(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ù)的定義，卻非常準確的界定了數(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è)計目標是事務(wù)處理。數(shù)據(jù)庫系統(tǒng)是為記錄更新和事務(wù)處理而設(shè)計，數(shù)據(jù)的訪問的特點是基于主鍵，大量原子，隔離的小事務(wù)，并發(fā)和可恢復(fù)是關(guān)鍵屬性，最大事務(wù)吞吐量是關(guān)鍵指標，因此數(shù)據(jù)庫的設(shè)計都反映了這些需求。
數(shù)據(jù)倉庫的設(shè)計目標是決策支持。歷史的，摘要的，聚合的數(shù)據(jù)比原始的記錄重要的多。查詢負載主要集中在即席查詢和包含連接，聚合等操作的復(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ù)庫實現(xiàn)，但是為部署和維護上是分離的。數(shù)據(jù)倉庫可以是基于關(guān)系數(shù)據(jù)庫實現(xiàn)的，這樣的數(shù)據(jù)倉庫被稱為ROLAP。數(shù)據(jù)倉庫也可以是基于多維數(shù)據(jù)結(jié)構(gòu)實現(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還負責(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è)計，這個元數(shù)據(jù)倉庫就至關(guān)重要。
下圖即是我所在的從事數(shù)據(jù)倉庫集成工具開發(fā)的團隊(負責(zé)生成ETL metadata，Database Schema，Pre-aggregation metadata，Reporter metadata，etc.)。名字是KOALA，slogon是讓生活更簡單。
上文中提到的維度的概念。維度(dimension)是觀察事物的角度，也是數(shù)據(jù)庫事實表中用來描述數(shù)據(jù)分類的層次結(jié)構(gòu)。維度在數(shù)據(jù)中就是表示為列，在SQL中用作過濾和分組。
像上圖這樣對數(shù)據(jù)進行多個維度的抽象并借助于數(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ǔ)上實現(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，實現(xiàn)聚合路徑
(
select//trunc實現(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//選擇計算的城市
- "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//行政維護可以不變
- tmp.time,
- tmp.id1,
- tmp.id2
OLAP的優(yōu)勢是基于數(shù)據(jù)倉庫面向主題、集成的、保留歷史及不可變更的數(shù)據(jù)存儲，以及多維模型多視角多層次的數(shù)據(jù)組織形式，如果脫離的這兩點，OLAP將不復(fù)存在，也就沒有優(yōu)勢可言。基于多維模型的數(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è)計呢?
大多數(shù)數(shù)據(jù)倉庫都采用“星型模型”來表示多維數(shù)據(jù)模型。在星型模型中，只有一個事實表，并且每一個維度有一個單獨的表。事實表中的每一個元組都是一個外鍵指向維度表的主鍵。每一個維度表的列是組成這個維度的所有屬性。如下圖所示。
另外一個常見的數(shù)據(jù)庫設(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é)果!其實作者指出了關(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ù)倉庫被認為是對數(shù)據(jù)庫查詢性能問題的一個解決方案。在90年代，人們已經(jīng)都面臨一個數(shù)據(jù)爆炸的挑戰(zhàn)，為了解決那個時代的“大數(shù)據(jù)”問題，數(shù)據(jù)倉庫應(yīng)運而生。
在1980s早期，大數(shù)據(jù)是指數(shù)據(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ù)的定義：
當前流行的技術(shù)處理不了的數(shù)據(jù)，都是大數(shù)據(jù)。
數(shù)據(jù)倉庫的本質(zhì)是把數(shù)據(jù)變小，一般有兩個方法：
第一是通過抽取，轉(zhuǎn)換，加載，清洗。
第二是通過pre-aggregation獲得數(shù)據(jù)的一份單獨拷貝。因此數(shù)據(jù)倉庫被定義為：
為了方便查詢分析，把數(shù)據(jù)從關(guān)系數(shù)據(jù)庫中單獨拷貝一份出來，然后通過ETL或者ELT轉(zhuǎn)換。
對于大數(shù)據(jù)，僅僅簡單構(gòu)建一個數(shù)據(jù)倉庫是不夠的。數(shù)據(jù)應(yīng)該如何結(jié)構(gòu)化才能更便于分析?數(shù)據(jù)庫和分析工具應(yīng)該如何設(shè)計才能更高效的處理大數(shù)據(jù)?
意識到大數(shù)據(jù)固有的時間屬性和空間屬性，是我們理解關(guān)系數(shù)據(jù)庫處理大數(shù)據(jù)時存在性能問題的重要前提。如果說數(shù)據(jù)是我對世界的觀察記錄的話，大數(shù)據(jù)是我們對世界在時間和/或空間維度的重復(fù)觀察。這就是大數(shù)據(jù)的時空特點，也是數(shù)據(jù)倉庫多維模型的構(gòu)建原理。當今的主流數(shù)據(jù)庫模型是關(guān)系數(shù)據(jù)庫，并且該模型顯式地忽略表中的行的順序。這將不可避免導(dǎo)致應(yīng)用以非順序的方式查詢數(shù)據(jù)。在這種情況下，傳統(tǒng)的數(shù)據(jù)架構(gòu)可以通過引入緩存的方式緩解性能問題，而大數(shù)據(jù)則會大大放大了次優(yōu)訪問模式對性能的影響。如下圖所示隨機訪問和順序訪問的差別。
因此我們要引入，也是我們要推導(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ù)，則單獨創(chuàng)建一個表，使用外鍵關(guān)聯(lián)，目的是節(jié)省存儲空間(那個時候存儲很昂貴)。逆正則化則是允許列之間的重復(fù)。如下圖所示。
我有一個看法，NoSQL的鍵值存儲即是用極簡的非結(jié)構(gòu)化來實現(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ù)倉庫時代的半實時在線查詢，剛剛興起的實時流處理(Online )，和批處理數(shù)據(jù)分析(Offline)，給數(shù)據(jù)架構(gòu)的設(shè)計人員提供了一個全面的參考。
再結(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，通過閱讀大量文獻，我得到下面一個范型：
借力開源軟件處理數(shù)據(jù)多樣性挑戰(zhàn)
使用分布式技術(shù)解決數(shù)據(jù)容量問題
使用實時流處理技術(shù)解決數(shù)據(jù)速度問題
傳統(tǒng)的OLAP 而言，實時性需求不明顯，實時分析的強需求是導(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)的幾個要點：
分布式計算
實時流處理
Online和Offline
SQL和No-SQL：混合架構(gòu)也是演進路徑之一
逆正則化(逆規(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ù)在進入倉庫之前需要是事先歸類，以便于未來的分析。這在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ù)據(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ù)湖在多個維度的詳細對比。
總結(jié)起來，數(shù)據(jù)湖架構(gòu)有一下幾個顯著的特點：
數(shù)據(jù)存儲：大容量低成本
數(shù)據(jù)保真度：數(shù)據(jù)湖以原始的格式保存數(shù)據(jù)
數(shù)據(jù)使用：數(shù)據(jù)湖中的數(shù)據(jù)可以方便的被使用
延遲綁定：數(shù)據(jù)湖提供靈活的，面向任務(wù)的數(shù)據(jù)綁定，不需要提前定義數(shù)據(jù)模
當然，對于數(shù)據(jù)湖架構(gòu)的批評也是不絕于耳。有人批評說，匯集各種雜亂的數(shù)據(jù)，應(yīng)該就是數(shù)據(jù)沼澤。Martin Fowler也對數(shù)據(jù)湖中數(shù)據(jù)的安全性和私密性提出了質(zhì)疑。
08
電信運營大數(shù)據(jù)特點
電信運營大數(shù)據(jù)對應(yīng)于TMN/FCAPS模型中的電信設(shè)備管理數(shù)據(jù)。如下圖所示。
Fault Management
Configuration Management
Accounting Management
Performance Management
Security Management
電信運營數(shù)據(jù)的特點是數(shù)據(jù)多樣化要求不高，大多數(shù)數(shù)據(jù)是結(jié)構(gòu)化數(shù)據(jù)，數(shù)據(jù)容量要求不是特別高，數(shù)據(jù)的實時處理要求最高。
電信運行數(shù)據(jù)架構(gòu)強調(diào)演進。步步為營，向前兼容，不是一蹴而就的。
09
演進路徑實踐
現(xiàn)在的架構(gòu)是一個典型的數(shù)據(jù)倉庫架構(gòu)。如下圖所示?，F(xiàn)在的架構(gòu)設(shè)計有以下幾個要點：
ROLAP：基于Oracle數(shù)據(jù)庫，但并沒有用Oracle的數(shù)據(jù)倉庫，單獨構(gòu)建數(shù)據(jù)倉庫。
Meta Data Driven的架構(gòu)設(shè)計：Meta Data覆蓋整個數(shù)據(jù)pipe。當新的數(shù)據(jù)需要集成，只需要編輯新的Meta Data，系統(tǒng)不需要做任何改變。
Schema設(shè)計：主要有兩類表：原始數(shù)據(jù)表和聚合表; 每類表都有三層結(jié)構(gòu)：表，用作聚合的視圖，用作報表的視圖。不同的應(yīng)用使用不同的視圖來操作數(shù)據(jù)。當原始的數(shù)據(jù)表結(jié)構(gòu)變化時，可以根據(jù)需要更改不同層次的視圖。
Schema的演化。這是一個比較大的主題，關(guān)系數(shù)據(jù)是schema on write的，任何列的增加都需要alter表結(jié)構(gòu)，這會帶來客戶系統(tǒng)很長時間的downtime。因此原始表采用1000列的設(shè)計(Oracle支持的最大列數(shù))，并且列只增加，不減少，避免了數(shù)據(jù)庫schema的變化，降低不同release之間migration的成本。
數(shù)據(jù)存儲：定期清除原始數(shù)據(jù)，只保留聚合數(shù)據(jù)。
為什么現(xiàn)在的架構(gòu)需要演進呢?
首先當前架構(gòu)面臨擴展性的挑戰(zhàn)。數(shù)據(jù)庫擴展性主要依賴于Oracle RAC解決方案，Oracle RAC不是一個線性的擴展方案，同時也增加了很多管理和維護成本。并且由于硬件的限制，垂直性擴展不是一個長期的解決方案。
其次，當前的存儲成本太昂貴，因此去IOE成為目標。
第三，實時處理需求也是驅(qū)動架構(gòu)演進的重要因素。
然后，架構(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)擴展性，在滿足業(yè)務(wù)需求的同時，最大化的保護已有投資。
在架構(gòu)演進這個過程中，有一些lesson learned：
SQL on Hadoop是必須的。客戶希望保持SQL接口的連續(xù)性。
混合數(shù)據(jù)倉庫架構(gòu)：針對不同的業(yè)務(wù)采用不同存儲方案(Oracle 和 HDFS)，數(shù)據(jù)量大的采用HDFS存儲，數(shù)據(jù)量不夠大的(不存在擴展性挑戰(zhàn)的)可以依然使用關(guān)系型數(shù)據(jù)庫。
逆規(guī)范化對性能的影響重大。通過對逆規(guī)范設(shè)計，可以達到關(guān)系數(shù)據(jù)庫的查詢性能。但是對于逆規(guī)范化是否存在其他影響，還需要研究。
相對于sequence files 和RC files，ORC文件格式的性能是最好的。
實時pipe使用storm和Kafka實現(xiàn)。
就像 NewSQL 那樣，可以有 New Data Warehouse 的。就是 Data Warehouse與云計算的融合，即數(shù)據(jù)倉庫的存儲層在云平臺，采用分布式系統(tǒng)。對應(yīng)用側(cè)而言， 原有的方式依舊有效，這樣就不會資產(chǎn)浪費，而是有效的繼承， 也是通往數(shù)據(jù)湖的一個較穩(wěn)妥的步驟。
——曹洪偉
老曹這么一說，豁然開朗。我們在談數(shù)據(jù)倉庫架構(gòu)向大數(shù)據(jù)架構(gòu)演進的時候，其實我們在談New Data Warehouse架構(gòu)。就像當初數(shù)據(jù)倉庫的出現(xiàn)是對數(shù)據(jù)庫系統(tǒng)存在的限制進行補充一樣，目前的大數(shù)據(jù)平臺是對數(shù)據(jù)倉庫系統(tǒng)存在的問題進行補充。他們的技術(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ù)集等特點的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如何演進?
對電信行業(yè)來說，NFV和SDN正在推動電信網(wǎng)絡(luò)設(shè)備控制平面和數(shù)據(jù)平面的分離，電信設(shè)備數(shù)據(jù)會走向數(shù)據(jù)湖架構(gòu)。電信設(shè)備數(shù)據(jù)融合，運營數(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)。使用機器學(xué)習(xí)的方式，模型訓(xùn)練成本恐怕和人工抽取schema的工作量是相當?shù)?。這是開放的話題，可以討論。
【本文是專欄作者石頭的原創(chuàng)文章，轉(zhuǎn)載請通過作者微信公眾號補天遺石(butianys)獲取授權(quán)】
戳這里，看該作者更多好文
網(wǎng)頁名稱：從數(shù)據(jù)倉庫到數(shù)據(jù)湖——淺談數(shù)據(jù)架構(gòu)演進(加強版)
URL地址：http://www.fisionsoft.com.cn/article/cdcsgsg.html
