探析大資料需求下的分散式資料庫

標籤：iad   複雜   十年   並發   oltp   企業級   資料採礦   man   利用   

一、前言

大資料技術從誕生到現在，已經經曆了十幾個年頭。市場上早已不斷有公司或機構，給廣大金融從業者“洗腦”大資料未來的美好前景與趨勢。隨著使用者對大資料理念與技術的不斷深入瞭解，人們已經開始從理論探索轉向對情境落地的尋找，讓大資料在企業中落地並開花結果。

從大資料的管理和應用方向集中在兩個領域。第一，大資料分析相關，針對海量資料的挖掘、複雜的分析計算；第二，線上資料操作，包括傳統交易型操作以及海量資料的即時訪問。大資料高並發查詢操作。使用者根據業務情境以及對資料處理結果的期望選擇不同的大資料管理方法。

分析型的大資料管理以Hadoop/Spark技術為主，適用於資料批處理分析挖掘的情境。隨著時間推移，Hadoop由於開源生態體系過於龐大且擴張迅速，對於大資料工具選擇、實施複雜度以及性價比都比較難以控制。近期，著名市場分析和諮詢機構Gartner發布報告[Gartner 2017年報告《Hype Cycle for Data Management,2017》]，報告指出目前巨量資料服務不再依賴單一Hadoop大資料商業平台，必須從滿足使用者的情境和案例的角度出發。

分散式資料庫則是線上操作性的大資料管理而誕生的，強調滿足大資料在即時高並發請求壓力下的互動業務情境。這一領域的“大資料”應用也正在被更多的人接受，又由於分散式資料庫的落地更簡單，開發營運上更接近與傳統資料管理系統。因此近年來分散式資料庫市場也在快速地發展壯大。

二、技術體系對比

在上述大資料技術實現中，Hadoop技術看似是自成一套體系。Hadoop/Spark與分散式資料庫的設計思路為什麼有所差異，其定位和使用情境應該如何與分散式資料庫技術進行區分？這需要從兩種技術的起源與發展來進行分析。（Gartner 2017年報告）

1. 大資料分析

大資料分析體系以Hadoop生態為主，近年來逐漸火熱的Spark技術也是主要的生態之一。其中，Hadoop技術只能算是以HDFS+YARN作為基礎的Distributed File System，而不是資料庫。

Hadoop的曆史可以向前追溯10年，當年Google為了在幾萬台PC伺服器上構建超大資料集合并提供極高效能的並發訪問能力，從而發明了MapReduce，也是Hadoop誕生的理論基礎。

從Hadoop的誕生背景可以看出，其主要解決的問題是超大規模叢集下如何對非結構化資料（Google扒取的網頁資訊）進行批處理計算（例如計算PageRank等）。實際上，在Hadoop架構中，一個分布式任務可以是類似傳統結構化資料的關聯、排序、聚集操作，也可以是針對非結構化資料的使用者自訂程式邏輯。

再來看Hadoop的發展道路。最開始的Hadoop以Big、Hive和MapReduce三種開發介面為代表，分別適用於指令碼批處理、SQL批處理以及使用者自訂邏輯類型的應用。而Spark的發展更是如此，最開始的SparkRDD幾乎完全沒有SQL能力，還是套用了Hive發展出的Shark才能對SQL有了一部分的支援。但是，隨著企業使用者對Hadoop的使用越發廣泛，SQL已經漸漸成為大資料平台在傳統行業的主要訪問方式之一。Hortonworks的Stinger、Cloudera的Impala、Databricks的SparkSQL、IBM的BigSQL都在兩年前開始慢慢搶佔市場，使得Hadoop看起來貌似也成為了SQL的主戰場。

2. 分散式資料庫

分散式資料庫有著悠久的曆史，從以Oracle RAC為代表的聯機交易型分散式資料庫，到IBM DB2 DPF統計分析性分散式資料庫，分散式資料庫覆蓋了OLTP與OLAP幾乎全部的資料應用情境。

大部分分散式資料庫功能集中在結構化計算與線上增刪改查上。例如IBM DB2 DPF，使用者可以像使用普通單點DB2資料庫一樣，幾乎透明地使用DPF版本。DPF中的SQL最佳化器能夠將一個查詢自動拆解並分發到多個節點中並存執行。

但是，這些傳統的分散式資料庫以數倉及分析類OLAP系統為主，其局限性在於，其底層的關係型資料庫儲存結構在效率上並不能滿足大量高並發的資料查詢以及大資料資料加工和分析的效率要求。

因此，分散式資料庫在近幾年也有著極大的轉型，從單一的資料模型向多模的資料模型轉移，將OLTP、聯機高並發查詢以及支援大資料加工和分析結合起來，不再單獨以OLAP作為設計目標。同時，分散式資料庫在訪問模式上也出現了K/V、文檔、寬表、圖等分支，支援除了SQL查詢語言之外的其他訪問模式，大大豐富了傳統分散式資料庫單一的用途。一般來說，多模資料庫的主要目的是為了滿足具有高效能要求的操作型需求以及目標明確的資料倉儲功能，而不是類似大資料深度學習等資料採礦情境。

3. 業務情境

從大資料技術的使用方式上來看，這些技術一方面可以按照結構化與非結構化資料類型劃分，另一方面也可以按照業務類型，即統計分析與聯機操作兩種類型（圖1）。

 

圖1 大資料業務類型

 

Hadoop的設計思路是解決超大規模資料情境下的統計分析問題，而分散式資料庫則根據細分領域不同，適用於結構化資料的統計分析，以及海量資料的聯機操作。

Hadoop和分散式資料庫最大的差異在於控制資料的顆粒細度不同。Hadoop傾向於對整體資料的操作，例如對全量資料的統計分析；而分散式資料庫強調精準控制到資料行，譬如對於某一條記錄的查詢更改操作。由此可見，Hadoop的業務情境非常適合低並發、大輸送量、離線為主的資料分析，而分散式資料庫適合高並發、線上即時的資料操作。這些差異性在非結構化資料的處理中也非常顯著。

三、行業發展趨勢

不論是Hadoop還是分散式資料庫，技術體繫上兩者都已經向著計算儲存層分離的方式演化。對於Hadoop來說這一趨勢非常明顯，HDFS儲存與YARN調度計算的分離，使得計算與儲存均可以按需橫向擴充。而分散式資料庫近年來也在遵循類似的趨勢，很多資料庫已經將底層儲存與上層的SQL引擎進行剝離，例如直接使用SparkSQL作為統計分析引擎、同時使用PostgreSQL作為交易處理引擎，這是業界多種分散式資料庫使用的技術路線。

 

圖2 分散式資料庫/Hadoop體繫結構

 

從Gartner在2016年最新的資料庫報告中可以看到，國際業界對新型資料庫的定義有了新的劃分。傳統的XML資料庫、OO資料庫、與pre-RDBMS正在消亡；新興領域文檔類資料庫、圖資料庫、Table-Style資料庫（類似Cassandra這類有著表結構定義，但是又不存在表之間關係定義的資料庫叫做Table-Style資料庫）與Multi-Model資料庫正在擴大自身影響；傳統關係型資料庫、列儲存資料庫、記憶體AnalyticDB（以SAP HANA為代表的記憶體AnalyticDB，以PC伺服器配置大量記憶體為硬體基礎，將海量資料緩衝在記憶體中換取極高的訪問效率，做到對大量資料的即時互動式分析。這類業務也稱作HTAP情境）正在考慮轉型。

可以看到，從技術完整性與成熟度等級來看，Hadoop確實還處於相對早期的形態。直到今天，一些SQL-on-Hadoop的方案還處於1.x甚至Beta版，在很多公司專屬應用程式中需要大量的手工調優才能夠勉強運行。同時，Hadoop的主要應用情境一直以來面向批處理分析型業務，傳統資料庫線上聯機處理部分不是其主要的發展方向。同時Hadoop技術由於開源生態體系過於龐大，同時參與改造的廠商太多，使得使用者很難完全熟悉整個體系，這一方面大大增加了開發的複雜度，提升了使用者使用的難度，另一方面則是各個廠商之間維護不同版本，使得產品的發展方向可能與開源版本差別逐漸加大。

另一方面，分散式資料庫領域經曆了幾十年的磨練，傳統RDBMS的MPP技術早已經爐火純青，在分類眾多的分散式資料庫中，其主要發展方向基本可以分為“分布式線上資料庫”與“分布式AnalyticDB”兩種。例如，以結構化資料和Multi-Model資料庫對結構化與半結構化資料的高並發聯機處理，和列儲存、Table-Style、加記憶體AnalyticDB的結構化資料批處理分析，是這兩個方向最常見的技術實現手段。同時，新一代資料庫在經曆了5-10年的發展後，已經開始進入到一個與傳統技術、其他技術互相融合的時代。

國內的巨杉資料庫SequoiaDB作為分散式資料庫，在Multi-Model多模操作型資料庫基礎上，已經開始全面支援分布式OLTP和分布式Object Storage Service。

對比Hadoop與分散式資料庫可以看出，Hadoop的產品發展方向定位，與分散式資料庫中列儲存資料庫相當重疊。例如，Pivotal Greenplum、IBM DB2 BLU、以及國內的南大通用GBase 8a，都與Hadoop的定位有著明顯的重合。而在高並發聯機交易情境，在Hadoop中除了HBase能夠勉強沾邊以外，分散式資料庫則佔據絕對的優勢。

 

圖3 分散式資料庫與Hadoop適用情境象限

 

目前，從Hadoop行業的發展來看，Cloudera、Hortonworks等廠商已經不再宣稱自己是Hadoop分銷商，而是將其定位改變為資料科學與機器學習服務商。因此，從商業模式上看以Hadoop分銷的商業模式基本已經宣告結束，使用者已經體驗到維護整個Hadoop平台的困難而不願被強迫購買整個平台。大量使用者更願意把原來Hadoop的組件拆開靈活使用，為使用情境和結果買單，而非平台本身買單。

另外一個細分市場——非結構化小檔案儲存體，一直以來都是Object Storage Service、Block Storage，與Distributed File System的主戰場。如今，一些新一代資料庫也開始進入該領域，可以預見在未來的幾年中，小型非結構化檔案儲存體也可能成為具備多模資料處理能力的分散式資料庫的戰場之一。

四、應用情境

不同應用情境應該使用不同的技術，沒有任何一種技術可以適用於全部業務情境。

大資料時代，在像金融這種相對嚴謹的行業中，核心交易類業務，由於一些曆史原因，很少有企業敢於立刻使用新技術替換主核心系統。但是在其他的系統中，分散式資料庫既有做到對傳統Oracle、IBM資料庫進行替換、“瘦身”，同時在大資料應用中，分散式資料庫地位也不斷上升。

資料倉儲延展實際上就是對傳統數倉模型的一個補充。一直以來，資料倉儲的建設都是遵從著從頂向下的原則，也就是先建立資料模型，再根據資料模型構建表結構與SQL，之後進行ETL和資料清洗，最後得到相應的報表。而大資料與新興的機器學習，帶給人們另一種從底向上的分析思路：首先建立分析型資料湖，將需要分析的資料均納入湖中進行脫敏和標準化，之後利用機器學習、深度挖掘等分散式運算技術，在這些海量的資料中尋找規律。這種思路與傳統數倉思路的最大不同，在於以曆史資料展現出的事實為基礎構建分析模型，而非與假設出的資料模型為基礎進行構建。資料倉儲延展，是Hadoop與分布式列儲存的主打情境。

對於線上和即時資料操作，分散式資料庫則是另一個主要的技術類型。比如，分散式資料庫用於ODS就是其中一個典型的應用案例。在規模相對較大的銀行中，傳統ODS一般僅僅保留一小段時間的曆史資料作為資料加工的臨時存放區，而更早期的曆史資料要麼被歸檔入帶庫，要麼被加工清洗後進入數倉。但在大資料的情境中，很多業務開始對曆史資料的線上互動式訪問提出明確的更高需求。例如，前台櫃面是否需要提供給使用者對全曆史周期的回單查詢功能；銀行內部營運團隊能否對全行業務的曆史進行線上查詢訪問，以應對司法查詢的需求，等等。這些類型的應用情境存在並發量高、索引維度多、查詢延遲低等特性，使用Hadoop的HBase存在眾多不便，正是分布式線上資料庫的主要應用情境。

除了存放曆史資料以外，ODS延展的另一大方向就是作為資料集市，存放從Hadoop中分析和挖掘的結果，供外部應用調用查詢。例如，手機銀行根據每個使用者畫像的標籤結果與當前行為提供即時產品推薦，就是將分析結果與即時行為資料相結合的情境。這類應用可以進一步擴充到事中風控等更核心的業務情境中去。

因此，在大資料時代中，Hadoop與分散式資料庫在金融行業的架構中應當相輔相成，互相彌補各自的不足。Hadoop與分布式AnalyticDB在結構化資料批處理分析中都可以很好地滿足需求；Hadoop對於非結構化資料分析有著資料庫無法比擬的優勢；而分布式線上資料庫則在高並發線上業務情境中能夠更靈活地管理和使用資料。

譬如說，近幾年來很多銀行在做“使用者畫像”業務，希望通過使用者的曆史交易行為給每個使用者打標籤，並在櫃面、網銀、手機銀行等多個渠道有針對性地推薦理財產品。當使用大資料技術實現該情境時，一個比較簡單常見的做法是：

（1）將使用者的曆史行為批量寫入Hadoop； 
（2）在Hadoop中使用機器學習對使用者行為分類建模； 
（3）在Hadoop中定期批量掃描使用者曆史行為，根據模型對使用者打標籤； 
（4）將使用者標籤結果寫入分散式資料庫； 
（5）各渠道業務通過中介軟體串連資料庫，查詢使用者標籤進行產品推薦。

五、展望未來

對於大資料技術未來的發展，還是會迴歸使用者的真正需求，Hadoop/Spark將會繼續在資料分析領域獨佔鰲頭，而在即時聯機互動領域，分散式資料庫則會成為另一股重要技術力量。

在銀行中，對於新技術的產品選型不能單從當前業務情境的需求出發，更要考慮到該產品未來3-5年的發展道路和方向，是否能夠不斷迭代滿足企業未來的需求。因此，使用者僅瞭解每一種技術的現狀是遠遠不夠的，只有當認識到一種技術的發展策略以及其架構局限性後，才能夠預見和洞察未來。

架構局限性並不等於功能的缺失。很多新型技術在開始時都無法提供像Oracle一樣完備的企業級功能，但並不是說使用者必須要等到全部功能完備後才開始考慮學習和使用。使用者在評估一種新產品和技術時，產品的功能點需要滿足幾個必備的基礎功能，而一些進階功能則不需要立刻具備。作為IT決策層，最重要的是評估該產品和技術的架構局限性，即是否在可預見的未來，基於該架構能夠實現和滿足銀行一段時間後的業務需求。

Hadoop的架構基礎核心是HDFS與YARN，任何請求首先被發送至YARN進行調度。而YARN則是根據NameNode計算出一個任務需要訪問的資料區塊所在伺服器產生一系列任務，並發送給相應的伺服器進行執行。除非從底層重寫整個調度演算法，該機制冗長的流程制約著Hadoop向聯機業務繼續發展。

資料庫的架構核心是資料存放區結構。只有存在可定義的儲存結構，資料庫才能夠提供對資料欄位的檢索、查詢、更新等操作。該機制一方面提供了對結構化與半結構化資料有效管理能力，另一方面卻制約著使用者對於非結構化資料的處理能力。短期來看，分散式資料庫在非結構化資料管理上，主要還停留在小檔案的儲存和檢索領域。對於檔案內部資訊的查詢能力，可以使用全文檢索索引索引實現，但是對於二進位非文本類的無結構資料，分散式資料庫還不存在較好的方式能夠對其中的資訊做到全維度自由檢索和查詢。

從分散式資料庫的角度來看，筆者認為，在未來的3-5年中，新一代資料庫將會漸漸向Multi-Model資料庫演化，同時提供SQL和API兩種資料訪問模式。 例如，巨杉資料庫SequoiaDB在支援SQL和API訪問結構化和半結構化儲存的同時，也支援其他類型的資料存放區格式，包括非結構化的Object Storage Service。同時，Distributed Relational Database Service會進一步加強融合，提供多引擎儲存方案（GBase 8a/8t），甚至有的產品已經開始支援JSON等半結構化資料（PostgreSQL）。

總而言之，在大資料技術下，分散式資料庫與Hadoop兩者相輔相成。Hadoop適合非結構化批處理分析情境；分散式資料庫則更適合高並發線上業務情境。

王濤，SequoiaDB巨杉資料庫聯合創始人，目前擔任SequoiaDB的CTO與總架構師。在王濤先生的領導下，SequoiaDB的技術團隊從零開始打造的分散式資料庫，如今SequoiaDB已經在國內同類產品中市場份額第一併得到了海內外業界的廣泛認可。自從2011年在北美將SequoiaDB資料庫核心原型研發成功後，王濤先生一直致力於SequoiaDB大規模分散式資料庫的研究，推動新一代資料庫在大資料行業中的發展與應用。王濤曾是IBM DB2 Lab北美核心研發成員，有著超過十年的資料庫核心架構設計，資料庫引擎研發和企業級資料庫應用的經驗。

探析大資料需求下的分散式資料庫