各位朋友大家好，我是顧全，目前就職于HVR中國公司擔任大中華區(qū)技術(shù)總監(jiān)一職。非常高興今天能夠有機會和大家做個分享和交流。
先簡單自我介紹一下。我是98年畢業(yè)于中國科學技術(shù)大學，專業(yè)是計算機科學。畢業(yè)后先去AMD做了2年的數(shù)據(jù)庫應用開發(fā)，然后又做了2年的OracleERP技術(shù)顧問，2003年我加入了Quest公司。主要負責APM和數(shù)據(jù)庫實時復制產(chǎn)品。應該算是國內(nèi)最早接觸這種基于數(shù)據(jù)庫日志的復制技術(shù)的。在Quest工作的10年里也親手實施了大量的行業(yè)標桿項目。
2013年我加入了SAP，主要負責的還是數(shù)據(jù)庫和BI產(chǎn)品，包括內(nèi)存計算技術(shù)，預測分析技術(shù)等大數(shù)據(jù)解決方案。
今天是我第一次參加大數(shù)據(jù)雜談的活動，既然我們這是個大數(shù)據(jù)技術(shù)主題的群，我想我就還是從大數(shù)據(jù)談起。
大數(shù)據(jù)分析與傳統(tǒng)BI的區(qū)別
圖1 DT時代的背景
這個片子的內(nèi)容，我相信大家應該都不陌生了。大數(shù)據(jù)的4個V(數(shù)據(jù)量，數(shù)據(jù)復雜性，數(shù)據(jù)產(chǎn)生速度和價值)最終能夠體現(xiàn)為價值，本質(zhì)上也是以分析為核心的，幫助企業(yè)提升業(yè)務洞察力，從而提高組織內(nèi)部甚至組織之間的協(xié)同能力。
大數(shù)據(jù)分析與傳統(tǒng)BI的最大的區(qū)別，我的理解有下面幾個方面：
1.預測性。各個大公司在推他們的大數(shù)據(jù)解決方案的時候都在強調(diào)他們的預測分析能力。
2.綜合性。傳統(tǒng)BI往往是主題分析，大數(shù)據(jù)分析往往是綜合性，跨域跨業(yè)務的分析。往往表現(xiàn)在不同數(shù)據(jù)之間發(fā)現(xiàn)內(nèi)含的相關(guān)性，從而總結(jié)提煉出新的知識和方法。
3.實現(xiàn)更高層次的資源整合，實現(xiàn)協(xié)同效應。
這里我講個例子可能會更加容易理解。
圖2 利用大數(shù)據(jù)實現(xiàn)預測性維護
我們以航空產(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)預測性維護的基礎，相比于規(guī)定每飛行多少小時或里程就必須進行全面檢修一次來說，我想大家很容易理解這種預測性維護大大提高維護工作的精準性同時也大幅度降低了維護成本。
我們現(xiàn)在假設一架飛機在北京飛往上海的過程中，我們的大數(shù)據(jù)分析給出警告說左側(cè)的發(fā)動機雖然仍在正常工作，但數(shù)據(jù)表明有潛在的風險，這有可能是由于某個或某幾個零部件老化造成，那么接下來該怎么辦呢？立刻飛往修理廠進行全面的檢查和維修么？如果這樣做的話可能成本還不如定期檢修來的低。
理想的做法是根據(jù)飛機的飛行計劃(下一站是上海，接下來可能是深圳…)，上�；蛘呱钲诟浇欠裼邢鄳牧悴考䦷齑嬉约凹夹g(shù)人員信息(技能，時間安排)，甚至還要考慮天氣和航空管制信息計算飛機晚點的風險來生成一個檢修計劃;然后根據(jù)計劃向相關(guān)供應商，服務商下達采購訂單。服務商接到訂單后立刻安排工單派出技術(shù)人員帶著零部件在指定時間到指定地點提供飛機的檢修服務。對于航空公司來說提高了飛行的安全性的同時，降低了整體的成本，故障在潛伏初期被發(fā)現(xiàn)并解決;對供應商和服務商提升可客戶滿意度也降低了自己的維修成本。
這個故事是不是很棒？我認為這將是其中一個大數(shù)據(jù)的未來發(fā)展方向，這里我們可以看到預測分析技術(shù)被多次運用，分析的數(shù)據(jù)也呈現(xiàn)多元化態(tài)勢，有些是自己的業(yè)務數(shù)據(jù)(航空公司內(nèi)部ERP數(shù)據(jù)，飛行計劃數(shù)據(jù)，航空班組和地勤人員信息)，有些是外部數(shù)據(jù)(天氣信息，航空管制信息，運營商庫存和技術(shù)服務人員信息)，這些數(shù)據(jù)有些是物聯(lián)網(wǎng)產(chǎn)生的半結(jié)構(gòu)化甚至非結(jié)構(gòu)化數(shù)據(jù)。
通過這樣一套大數(shù)據(jù)應用，飛機、機場、航空公司以及供應商服務商被有機的整合到了一起，實現(xiàn)了更高層面的協(xié)同。
在數(shù)據(jù)集成上面臨的挑戰(zhàn)
為了實現(xiàn)上面的目標，各個公司在數(shù)據(jù)分析方面有各種各樣的技術(shù)創(chuàng)新我這里就不多談了，我主要想從數(shù)據(jù)集成角度來看看我們當前還面臨著哪些挑戰(zhàn)。
首先就是數(shù)據(jù)的來源，這些數(shù)據(jù)根據(jù)其屬性我們可以分成以下4大類：
1.企業(yè)內(nèi)部業(yè)務系統(tǒng)數(shù)據(jù)，這些數(shù)據(jù)往往是由OLTP業(yè)務系統(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ù)，包括供應商，客戶，相關(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ù)。我在這里就不展開了。
圖3 數(shù)據(jù)湖
但是需要注意的是這些大數(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ù)的實時捕獲
目前基于事務日志的數(shù)據(jù)捕獲已經(jīng)變得非常成熟，Oracle有OGG，DB2有CDC，SAPSybase有SRS，當然也包括我們自己的HVR。
這種技術(shù)最大的好處就是對源數(shù)據(jù)庫系統(tǒng)影響較低，是一種非侵入式的數(shù)據(jù)捕獲方式�；驹砭褪撬械年P(guān)系型數(shù)據(jù)庫基本上都會提供事務日志，并且事務日志會記錄所有的數(shù)據(jù)變化信息，數(shù)據(jù)庫的事務提交也往往以寫入事務日志為標志(此時數(shù)據(jù)庫可能只完成了buffer的修改，數(shù)據(jù)文件還未完成寫入)，通過分析日志我們客戶獲得全部的數(shù)據(jù)變化信息，并且這些信息天然就是增量的，按時間排序的，保證讀一致性和事務前后順序的。
2.異構(gòu)平臺支持
圖4 實時數(shù)據(jù)同步軟件
數(shù)據(jù)復制軟件不但要能夠支持傳統(tǒng)的關(guān)系型數(shù)據(jù)庫和各種大數(shù)據(jù)平臺，還應當支持文件系統(tǒng)復制，支持云環(huán)境的部署。上面這個圖是目前我們的HVR可以支持的平臺。
3.數(shù)據(jù)壓縮
數(shù)據(jù)產(chǎn)生的源越來越復雜，企業(yè)可能需要在不同地點的數(shù)據(jù)中心之間，或者在本地系統(tǒng)和云上的系統(tǒng)之間進行數(shù)據(jù)復制;有些數(shù)據(jù)可能由遍布全國的設備產(chǎn)生，例如移動通訊基站，輸變電設施，石油鉆井平臺等;甚至數(shù)據(jù)產(chǎn)生的地點都不是固定的，例如上面例子里說的飛機，船舶;
數(shù)據(jù)壓縮能力可以幫助企業(yè)極大的節(jié)約運營過程中的網(wǎng)絡成本。目前我們HVR的壓縮算法對字符型數(shù)據(jù)可以實現(xiàn)超過95%倍以上的壓縮能力，對其它結(jié)構(gòu)化數(shù)據(jù)類型也可以達到50%至80%的壓縮率。
打個比方，一個oracle數(shù)據(jù)庫產(chǎn)生1GB的redolog，需要復制的信息最多通常在30%左右，我們按照90%的綜合壓縮率來計算，實際需要占用網(wǎng)絡傳輸?shù)臄?shù)據(jù)量僅僅有30M！
4.數(shù)據(jù)加密
遠程數(shù)據(jù)復制場景尤其應當重視數(shù)據(jù)的安全性，防止數(shù)據(jù)在傳輸過程被竊取。
5.可管理性
這里涵蓋的內(nèi)容就比較廣泛了。
一個方面是架構(gòu)上：目前類似的軟件絕大多都采用的點對點部署模式。一個典型的場景可能會是類似下面的這個架構(gòu)圖。大家可以看到這種網(wǎng)站的數(shù)據(jù)復制模式邏輯上非常復雜，對安裝，部署，管理都帶來很大的難度。
圖5 軟件架構(gòu)
為了解決這個問題，HVR提供一個hub-spoken的架構(gòu)，類似下圖：
圖6 hvr_integrate1
這樣的架構(gòu)使得軟件的部署和管理維護非常簡單，在每個數(shù)據(jù)節(jié)點上只需要安裝啟動hvr-listener服務即可，所有的配置，管理和監(jiān)控工作都在hub服務器上進行，listener的工作行為由hub上的作業(yè)進程調(diào)度和管理。
可管理性的另外一個方面就是監(jiān)控和歷史報表。
同樣得益于HVR精煉的架構(gòu)設計，HVR可以方便地提供豐富的歷史數(shù)據(jù)報表，例如復制的延遲信息，復制的數(shù)據(jù)量，增改刪的記錄數(shù)等。HVR還提供了完善的監(jiān)控功能，當有故障發(fā)生的時候可以自動發(fā)送告警email到DBA的郵箱或者通過SNMP方式發(fā)送消息到監(jiān)控告警平臺上。
6.數(shù)據(jù)的轉(zhuǎn)換能力
圖7 傳統(tǒng)的數(shù)據(jù)整體（ETL）流程
上圖是傳統(tǒng)的商業(yè)智能領域通常使用的ETL方法。傳統(tǒng)的商業(yè)智能由于主要面向的是已知的問題(主題)，通常在數(shù)據(jù)倉庫建設階段非常重要的就是數(shù)據(jù)模型設計，從業(yè)務系統(tǒng)取得的數(shù)據(jù)需要經(jīng)過抽取(E)，轉(zhuǎn)換(T)和加載(L)來完成。由于轉(zhuǎn)換的工作量有的時候相當大，還會需要有個專門的數(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)預先的數(shù)據(jù)倉庫模型定義。
但對數(shù)據(jù)依然需要做一些轉(zhuǎn)換工作。
例如1：數(shù)據(jù)的行級轉(zhuǎn)換
圖8 數(shù)據(jù)轉(zhuǎn)換
例如2：數(shù)據(jù)的軟刪除和時間戳轉(zhuǎn)換
圖9 軟刪除和時間戳轉(zhuǎn)換
大數(shù)據(jù)BI需要的不僅僅需要的是業(yè)務數(shù)據(jù)的結(jié)果，業(yè)務數(shù)據(jù)的變化過程可能更重要。
例如對于已經(jīng)刪除的數(shù)據(jù)，生產(chǎn)系統(tǒng)可能不在需要這部分內(nèi)容，但是大數(shù)據(jù)分析依然需要，但是要通過標記列來識別。甚至更進一步，對所有的增改刪，大數(shù)據(jù)分析都需要保留其變化的每一步過程，并通過時間戳和操作類型給予表示，當然在此基礎上可能還會需要保留其它的相關(guān)信息，例如數(shù)據(jù)來源，業(yè)務發(fā)起用戶信息等等。
這種數(shù)據(jù)轉(zhuǎn)換其實不僅僅大數(shù)據(jù)BI需要，傳統(tǒng)的商業(yè)智能也能從中受益。一些簡單的場景，數(shù)據(jù)的行級轉(zhuǎn)換已經(jīng)可以滿足業(yè)務要求。在一些大型的BI項目中，時間戳轉(zhuǎn)換結(jié)合ETL工具的方案可以幫助企業(yè)避免ETL工具在數(shù)據(jù)抽取時對生產(chǎn)造成的性能影響，也避免了對生產(chǎn)系統(tǒng)為了實現(xiàn)數(shù)據(jù)的增量抽取而不得不進行的時間戳改造。
Q&A
Q1：對于異地雙活數(shù)據(jù)中心有什么好的建議嗎？數(shù)據(jù)實時速度有多快？
顧全：先回答上面這倆個問題。正常情況下(也就是沒有明顯的系統(tǒng)瓶頸)，數(shù)據(jù)的同步延遲時間是在秒級，這可能受到網(wǎng)絡延遲，事務的大小，目標數(shù)據(jù)庫性能的影響。對于兩地雙中心，我們也有成功的案例。根本的原則是避免兩地業(yè)務數(shù)據(jù)的沖突。例如，主鍵值的范圍劃分，使得正常情況下每個中心支撐的業(yè)務是被分區(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è)務很精通，那么這些業(yè)務人員是否會有繼續(xù)往大數(shù)據(jù)項目上發(fā)展的可能呢，還是公司會另聘咨詢公司來做大數(shù)據(jù)項目？兩者的比例，依你的經(jīng)驗會有多少分配？現(xiàn)在的大數(shù)據(jù)市場工具眼花繚亂，各有千秋，肯定不是每個工具都能適應所有的項目工程。那么我們怎么選擇才能更快切入大數(shù)據(jù)領域。是否可以推薦系統(tǒng)的書或者您的博客？
顧全：這個問題其實蠻大的，我不認為大數(shù)據(jù)BI會完全取代傳統(tǒng)BI。傳統(tǒng)BI和大數(shù)據(jù)BI會有不同的側(cè)重點，解決的問題也是不完全相同的。但我相信，大數(shù)據(jù)的目標是提高企業(yè)的業(yè)務洞察力，這個洞察力最終是要落在企業(yè)員工身上的。所以業(yè)務人員的培養(yǎng)是非常重要的。咨詢公司主要是扮演顧問的角色，在大數(shù)據(jù)項目落地的過程中，可能根據(jù)企業(yè)具體情況，依然會需要系統(tǒng)集成商，方案供應商，甚至軟件開發(fā)商等多種伙伴的幫助。
Q3：基于行的復制，對批量更新和表更新操作有著天然的缺陷。你們的產(chǎn)品如何緩和批量更新的缺陷？DDL操作是否透明？
顧全：這個朋友說的很對。這種復制技術(shù)應該說主要面對的是源端OLTP類型的業(yè)務。但是批處理往往也是不可避免的。當批處理的量較大的時候，往往目標端數(shù)據(jù)入庫可能會產(chǎn)生一定的延遲，業(yè)務對這個延遲的忍受情況是不同的，數(shù)據(jù)規(guī)模也差異很大，對策可能也會不一樣。這個需要具體問題具體分析了。
Q4：基于數(shù)據(jù)庫日志的大數(shù)據(jù)采集，更新和刪除往往怎么處理？
顧全：通常來說可以采用我演講中提到的轉(zhuǎn)換示例2，也就是軟刪除或者時間戳轉(zhuǎn)換的方式來處理。
轉(zhuǎn)載請注明出處：拓步ERP資訊網(wǎng)http://www.oesoe.com/
本文標題：數(shù)據(jù)庫復制技術(shù)在大數(shù)據(jù)BI上的應用
本文網(wǎng)址：http://www.oesoe.com/html/consultation/10839319670.html
相關(guān)文章
