各位朋友大家好，我是顧全，目前就職于HVR中國公司擔(dān)任大中華區(qū)技術(shù)總監(jiān)一職。非常高興今天能夠有機會和大家做個分享和交流。

先簡單自我介紹一下。我是98年畢業(yè)于中國科學(xué)技術(shù)大學(xué)，專業(yè)是計算機科學(xué)。畢業(yè)后先去AMD做了2年的數(shù)據(jù)庫應(yīng)用開發(fā)，然后又做了2年的Oracle ERP技術(shù)顧問，2003年我加入了Quest公司。主要負(fù)責(zé)APM和數(shù)據(jù)庫實時復(fù)制產(chǎn)品。應(yīng)該算是國內(nèi)最早接觸這種基于數(shù)據(jù)庫日志的復(fù)制技術(shù)的。在Quest工作的10年里也親手實施了大量的行業(yè)標(biāo)桿項目。

2013年我加入了SAP，主要負(fù)責(zé)的還是數(shù)據(jù)庫和BI產(chǎn)品，包括內(nèi)存計算技術(shù)， 預(yù)測分析技術(shù)等大數(shù)據(jù)解決方案。

今天是我第一次參加大數(shù)據(jù)雜談的活動，既然我們這是個大數(shù)據(jù)技術(shù)主題的群，我想我就還是從大數(shù)據(jù)談起。

大數(shù)據(jù)分析與傳統(tǒng)BI的區(qū)別

這個片子的內(nèi)容，我相信大家應(yīng)該都不陌生了。大數(shù)據(jù)的4個V(數(shù)據(jù)量，數(shù)據(jù)復(fù)雜性，數(shù)據(jù)產(chǎn)生速度和價值)最終能夠體現(xiàn)為價值，本質(zhì)上也是以分析為核心的，幫助企業(yè)提升業(yè)務(wù)洞察力，從而提高組織內(nèi)部甚至組織之間的協(xié)同能力。

大數(shù)據(jù)分析與傳統(tǒng)BI的最大的區(qū)別，我的理解有下面幾個方面：

1. 預(yù)測性。各個大公司在推他們的大數(shù)據(jù)解決方案的時候都在強調(diào)他們的預(yù)測分析能力。

2. 綜合性。傳統(tǒng)BI往往是主題分析，大數(shù)據(jù)分析往往是綜合性，跨域跨業(yè)務(wù)的分析。往往表現(xiàn)在不同數(shù)據(jù)之間發(fā)現(xiàn)內(nèi)含的相關(guān)性，從而總結(jié)提煉出新的知識和方法。

3. 實現(xiàn)更高層次的資源整合，實現(xiàn)協(xié)同效應(yīng)。

這里我講個例子可能會更加容易理解。

我們以航空產(chǎn)業(yè)為例。根據(jù)GE說法，早在2013年他們生產(chǎn)的航空發(fā)動機每天就會產(chǎn)生超過1TB的數(shù)據(jù)，這是典型的物聯(lián)網(wǎng)數(shù)據(jù)，也就是機器產(chǎn)生數(shù)據(jù)。這些裝配在航空發(fā)動機上的各種傳感器無時無刻地產(chǎn)生海量的數(shù)據(jù)。

通過對這些數(shù)據(jù)的收集和分析，我們可以對飛機的“健康”狀況做出評估。這是實現(xiàn)預(yù)測性維護(hù)的基礎(chǔ)，相比于規(guī)定每飛行多少小時或里程就必須進(jìn)行全面檢修一次來說，我想大家很容易理解這種預(yù)測性維護(hù)大大提高維護(hù)工作的精準(zhǔn)性同時也大幅度降低了維護(hù)成本。

我們現(xiàn)在假設(shè)一架飛機在北京飛往上海的過程中，我們的大數(shù)據(jù)分析給出警告說左側(cè)的發(fā)動機雖然仍在正常工作，但數(shù)據(jù)表明有潛在的風(fēng)險，這有可能是由于某個或某幾個零部件老化造成，那么接下來該怎么辦呢?立刻飛往修理廠進(jìn)行全面的檢查和維修么?如果這樣做的話可能成本還不如定期檢修來的低。

理想的做法是根據(jù)飛機的飛行計劃(下一站是上海，接下來可能是深圳…), 上海或者深圳附近是否有相應(yīng)的零部件庫存以及技術(shù)人員信息(技能，時間安排)，甚至還要考慮天氣和航空管制信息計算飛機晚點的風(fēng)險來生成一個檢修計劃; 然后根據(jù)計劃向相關(guān)供應(yīng)商，服務(wù)商下達(dá)采購訂單。服務(wù)商接到訂單后立刻安排工單派出技術(shù)人員帶著零部件在指定時間到指定地點提供飛機的檢修服務(wù)。對于航空公司來說提高了飛行的安全性的同時，降低了整體的成本，故障在潛伏初期被發(fā)現(xiàn)并解決;對供應(yīng)商和服務(wù)商提升可客戶滿意度也降低了自己的維修成本。

這個故事是不是很棒?我認(rèn)為這將是其中一個大數(shù)據(jù)的未來發(fā)展方向，這里我們可以看到預(yù)測分析技術(shù)被多次運用，分析的數(shù)據(jù)也呈現(xiàn)多元化態(tài)勢，有些是自己的業(yè)務(wù)數(shù)據(jù)(航空公司內(nèi)部ERP數(shù)據(jù)，飛行計劃數(shù)據(jù)，航空班組和地勤人員信息)，有些是外部數(shù)據(jù)(天氣信息，航空管制信息，運營商庫存和技術(shù)服務(wù)人員信息)，這些數(shù)據(jù)有些是物聯(lián)網(wǎng)產(chǎn)生的半結(jié)構(gòu)化甚至非結(jié)構(gòu)化數(shù)據(jù)。

通過這樣一套大數(shù)據(jù)應(yīng)用，飛機、機場、航空公司以及供應(yīng)商服務(wù)商被有機的整合到了一起，實現(xiàn)了更高層面的協(xié)同。

在數(shù)據(jù)集成上面臨的挑戰(zhàn)

為了實現(xiàn)上面的目標(biāo)，各個公司在數(shù)據(jù)分析方面有各種各樣的技術(shù)創(chuàng)新我這里就不多談了，我主要想從數(shù)據(jù)集成角度來看看我們當(dāng)前還面臨著哪些挑戰(zhàn)。

首先就是數(shù)據(jù)的來源，這些數(shù)據(jù)根據(jù)其屬性我們可以分成以下4大類：

1. 企業(yè)內(nèi)部業(yè)務(wù)系統(tǒng)數(shù)據(jù)，這些數(shù)據(jù)往往是由OLTP業(yè)務(wù)系統(tǒng)產(chǎn)生，是存放在傳統(tǒng)的數(shù)據(jù)庫內(nèi)，屬于結(jié)構(gòu)化數(shù)據(jù);

2. 物聯(lián)網(wǎng)數(shù)據(jù)，由機器產(chǎn)生，往往是定時生產(chǎn)一系列文件的方式，例如交通卡口的攝像頭拍的照片，飛機上傳感器采集到的運行信息等。這些數(shù)據(jù)大部分是半結(jié)構(gòu)化甚至是非結(jié)構(gòu)化的數(shù)據(jù);

3. 互聯(lián)網(wǎng)數(shù)據(jù)，網(wǎng)站，微博，bbs等產(chǎn)生的數(shù)據(jù)，以半結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)為主;

4. 其它組織的數(shù)據(jù)，包括供應(yīng)商，客戶，相關(guān)政府部門等等。這些以結(jié)構(gòu)化數(shù)據(jù)庫為主。

其次是數(shù)據(jù)的分析平臺，現(xiàn)在各種新技術(shù)層出不窮，各大廠商都給出自己的大數(shù)據(jù)解決方案，例如以Hadoop為核心的，或者內(nèi)存計算技術(shù)為核心(如SAP的HANA)以及MPP架構(gòu)數(shù)據(jù)庫技術(shù)(如Teradata，Greenplum)。

這些技術(shù)各有其優(yōu)缺點，越來越多的客戶在構(gòu)建自己的大數(shù)據(jù)解決方案時候往往也會綜合采用上述多種解決方案，而不是僅僅依賴單一的技術(shù)。我在這里就不展開了。

但是需要注意的是這些大數(shù)據(jù)平臺本身不是數(shù)據(jù)的來源，而是數(shù)據(jù)的存儲和處理平臺。隨著這些技術(shù)的發(fā)展，大數(shù)據(jù)平臺的吞吐能力越來越大，運算效率越來越高，各大廠商都在強調(diào)自己的大數(shù)據(jù)實時處理能力，但是如果獲得的數(shù)據(jù)不是實時，那么實時運算也就失去了它的意義。所以作為大數(shù)據(jù)平臺的第一公里，數(shù)據(jù)集成技術(shù)也越來越受到業(yè)界的重視。

數(shù)據(jù)集成需要考慮的因素在這樣一個綜合性的環(huán)境里，數(shù)據(jù)集成需要考慮哪些方面的因素呢?

1. 數(shù)據(jù)的實時捕獲

目前基于事務(wù)日志的數(shù)據(jù)捕獲已經(jīng)變得非常成熟，Oracle有OGG，DB2有CDC，SAP Sybase有SRS，當(dāng)然也包括我們自己的HVR。

這種技術(shù)最大的好處就是對源數(shù)據(jù)庫系統(tǒng)影響較低，是一種非侵入式的數(shù)據(jù)捕獲方式?；驹砭褪撬械年P(guān)系型數(shù)據(jù)庫基本上都會提供事務(wù)日志，并且事務(wù)日志會記錄所有的數(shù)據(jù)變化信息，數(shù)據(jù)庫的事務(wù)提交也往往以寫入事務(wù)日志為標(biāo)志(此時數(shù)據(jù)庫可能只完成了buffer的修改，數(shù)據(jù)文件還未完成寫入)，通過分析日志我們客戶獲得全部的數(shù)據(jù)變化信息，并且這些信息天然就是增量的，按時間排序的，保證讀一致性和事務(wù)前后順序的。

2. 異構(gòu)平臺支持

數(shù)據(jù)復(fù)制軟件不但要能夠支持傳統(tǒng)的關(guān)系型數(shù)據(jù)庫和各種大數(shù)據(jù)平臺，還應(yīng)當(dāng)支持文件系統(tǒng)復(fù)制，支持云環(huán)境的部署。上面這個圖是目前我們的HVR可以支持的平臺。

3. 數(shù)據(jù)壓縮

數(shù)據(jù)產(chǎn)生的源越來越復(fù)雜，企業(yè)可能需要在不同地點的數(shù)據(jù)中心之間，或者在本地系統(tǒng)和云上的系統(tǒng)之間進(jìn)行數(shù)據(jù)復(fù)制;有些數(shù)據(jù)可能由遍布全國的設(shè)備產(chǎn)生，例如移動通訊基站，輸變電設(shè)施，石油鉆井平臺等;甚至數(shù)據(jù)產(chǎn)生的地點都不是固定的，例如上面例子里說的飛機，船舶;

數(shù)據(jù)壓縮能力可以幫助企業(yè)極大的節(jié)約運營過程中的網(wǎng)絡(luò)成本。目前我們HVR的壓縮算法對字符型數(shù)據(jù)可以實現(xiàn)超過95%倍以上的壓縮能力，對其它結(jié)構(gòu)化數(shù)據(jù)類型也可以達(dá)到50%至80%的壓縮率。

打個比方，一個oracle數(shù)據(jù)庫產(chǎn)生1GB的redo log，需要復(fù)制的信息最多通常在30%左右，我們按照90%的綜合壓縮率來計算，實際需要占用網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)量僅僅有30M!

4. 數(shù)據(jù)加密

遠(yuǎn)程數(shù)據(jù)復(fù)制場景尤其應(yīng)當(dāng)重視數(shù)據(jù)的安全性，防止數(shù)據(jù)在傳輸過程被竊取。

5. 可管理性

這里涵蓋的內(nèi)容就比較廣泛了。

一個方面是架構(gòu)上：目前類似的軟件絕大多都采用的點對點部署模式。一個典型的場景可能會是類似下面的這個架構(gòu)圖。大家可以看到這種網(wǎng)站的數(shù)據(jù)復(fù)制模式邏輯上非常復(fù)雜，對安裝，部署，管理都帶來很大的難度。

為了解決這個問題，HVR提供一個hub-spoken的架構(gòu)，類似下圖：

這樣的架構(gòu)使得軟件的部署和管理維護(hù)非常簡單，在每個數(shù)據(jù)節(jié)點上只需要安裝啟動hvr-listener服務(wù)即可，所有的配置，管理和監(jiān)控工作都在hub服務(wù)器上進(jìn)行，listener的工作行為由hub上的作業(yè)進(jìn)程調(diào)度和管理。

可管理性的另外一個方面就是監(jiān)控和歷史報表。

同樣得益于HVR精煉的架構(gòu)設(shè)計，HVR可以方便地提供豐富的歷史數(shù)據(jù)報表， 例如復(fù)制的延遲信息，復(fù)制的數(shù)據(jù)量，增改刪的記錄數(shù)等。HVR還提供了完善的監(jiān)控功能，當(dāng)有故障發(fā)生的時候可以自動發(fā)送告警email到DBA的郵箱或者通過SNMP方式發(fā)送消息到監(jiān)控告警平臺上。

6. 數(shù)據(jù)的轉(zhuǎn)換能力

上圖是傳統(tǒng)的商業(yè)智能領(lǐng)域通常使用的ETL方法。傳統(tǒng)的商業(yè)智能由于主要面向的是已知的問題(主題)，通常在數(shù)據(jù)倉庫建設(shè)階段非常重要的就是數(shù)據(jù)模型設(shè)計，從業(yè)務(wù)系統(tǒng)取得的數(shù)據(jù)需要經(jīng)過抽取(E)，轉(zhuǎn)換(T)和加載(L)來完成。由于轉(zhuǎn)換的工作量有的時候相當(dāng)大，還會需要有個專門的數(shù)據(jù)庫來支撐，所以有的廠商提出了ELT的解決方案。不論是ETL還是ELT，一般的工作特點都是定時抽取，批量轉(zhuǎn)換和加載。數(shù)據(jù)倉庫得到的數(shù)據(jù)是非實時的。

而大數(shù)據(jù)BI由于往往面對的是未知的問題，需要通過更加廣泛的數(shù)據(jù)去探索和發(fā)現(xiàn)其中內(nèi)涵的相關(guān)性，大部分情況下難以實現(xiàn)預(yù)先的數(shù)據(jù)倉庫模型定義。

但對數(shù)據(jù)依然需要做一些轉(zhuǎn)換工作。

例如1： 數(shù)據(jù)的行級轉(zhuǎn)換

例如2： 數(shù)據(jù)的軟刪除和時間戳轉(zhuǎn)換

大數(shù)據(jù)BI需要的不僅僅需要的是業(yè)務(wù)數(shù)據(jù)的結(jié)果，業(yè)務(wù)數(shù)據(jù)的變化過程可能更重要。

例如對于已經(jīng)刪除的數(shù)據(jù)，生產(chǎn)系統(tǒng)可能不在需要這部分內(nèi)容，但是大數(shù)據(jù)分析依然需要，但是要通過標(biāo)記列來識別。甚至更進(jìn)一步，對所有的增改刪，大數(shù)據(jù)分析都需要保留其變化的每一步過程，并通過時間戳和操作類型給予表示，當(dāng)然在此基礎(chǔ)上可能還會需要保留其它的相關(guān)信息，例如數(shù)據(jù)來源，業(yè)務(wù)發(fā)起用戶信息等等。

這種數(shù)據(jù)轉(zhuǎn)換其實不僅僅大數(shù)據(jù)BI需要，傳統(tǒng)的商業(yè)智能也能從中受益。一些簡單的場景，數(shù)據(jù)的行級轉(zhuǎn)換已經(jīng)可以滿足業(yè)務(wù)要求。在一些大型的BI項目中，時間戳轉(zhuǎn)換結(jié)合ETL工具的方案可以幫助企業(yè)避免ETL工具在數(shù)據(jù)抽取時對生產(chǎn)造成的性能影響，也避免了對生產(chǎn)系統(tǒng)為了實現(xiàn)數(shù)據(jù)的增量抽取而不得不進(jìn)行的時間戳改造。

我的分享結(jié)束了，謝謝大家!

Q&A

Q1：對于異地雙活數(shù)據(jù)中心有什么好的建議嗎? 數(shù)據(jù)實時速度有多快?

顧全：先回答上面這倆個問題。正常情況下(也就是沒有明顯的系統(tǒng)瓶頸)，數(shù)據(jù)的同步延遲時間是在秒級，這可能受到網(wǎng)絡(luò)延遲，事務(wù)的大小，目標(biāo)數(shù)據(jù)庫性能的影響。對于兩地雙中心，我們也有成功的案例。根本的原則是避免兩地業(yè)務(wù)數(shù)據(jù)的沖突。例如，主鍵值的范圍劃分，使得正常情況下每個中心支撐的業(yè)務(wù)是被分區(qū)的。

Q2：傳統(tǒng)BI和大數(shù)據(jù)肯定是未來企業(yè)發(fā)展的兩方面，不能斷言到底大數(shù)據(jù)會不會替代傳統(tǒng)BI。那么問題在這里，傳統(tǒng)BI肯定是企業(yè)著手做了很長時間的工程了，培養(yǎng)的分析人員，數(shù)據(jù)倉庫開發(fā)員必然對企業(yè)的自有業(yè)務(wù)很精通，那么這些業(yè)務(wù)人員是否會有繼續(xù)往大數(shù)據(jù)項目上發(fā)展的可能呢，還是公司會另聘咨詢公司來做大數(shù)據(jù)項目?兩者的比例，依你的經(jīng)驗會有多少分配? 現(xiàn)在的大數(shù)據(jù)市場工具眼花繚亂，各有千秋，肯定不是每個工具都能適應(yīng)所有的項目工程。那么我們怎么選擇才能更快切入大數(shù)據(jù)領(lǐng)域。 是否可以推薦系統(tǒng)的書或者您的博客?

顧全：這個問題其實蠻大的，我不認(rèn)為大數(shù)據(jù)BI會完全取代傳統(tǒng)BI。傳統(tǒng)BI和大數(shù)據(jù)BI會有不同的側(cè)重點，解決的問題也是不完全相同的。但我相信，大數(shù)據(jù)的目標(biāo)是提高企業(yè)的業(yè)務(wù)洞察力， 這個洞察力最終是要落在企業(yè)員工身上的。所以業(yè)務(wù)人員的培養(yǎng)是非常重要的。咨詢公司主要是扮演顧問的角色，在大數(shù)據(jù)項目落地的過程中，可能根據(jù)企業(yè)具體情況，依然會需要系統(tǒng)集成商，方案供應(yīng)商，甚至軟件開發(fā)商等多種伙伴的幫助。

Q3：基于行的復(fù)制，對批量更新和表更新操作有著天然的缺陷。你們的產(chǎn)品如何緩和批量更新的缺陷?DDL操作是否透明?

顧全：這個朋友說的很對。這種復(fù)制技術(shù)應(yīng)該說主要面對的是源端OLTP類型的業(yè)務(wù)。但是批處理往往也是不可避免的。當(dāng)批處理的量較大的時候，往往目標(biāo)端數(shù)據(jù)入庫可能會產(chǎn)生一定的延遲，業(yè)務(wù)對這個延遲的忍受情況是不同的，數(shù)據(jù)規(guī)模也差異很大，對策可能也會不一樣。這個需要具體問題具體分析了。

Q4：基于數(shù)據(jù)庫日志的大數(shù)據(jù)采集，更新和刪除往往怎么處理?

顧全：通常來說可以采用我演講中提到的轉(zhuǎn)換示例2，也就是軟刪除或者時間戳轉(zhuǎn)換的方式來處理。

來源：大數(shù)據(jù)雜談