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