轉自：安華信達的文章
鏈接地址：http://www.sohu.com/a/133784835_481676

一、大數據技術的發展

大數據技術從誕生到現在，已歷經了十幾個年頭，市場上也早已有公司或機構對廣大金融從業者灌輸大數據未來的美好前景與趨勢。隨著對大數據理念與技術了解的不斷深入，人們開始尋找場景落地，以期讓大數據在自身的企業中落地并開花結果。

從數據的應用角度來看，大數據的應用方向主要集中在兩個領域。第一是大數據分析相關，也就是傳統數據倉庫的延展，將更多的數據挖掘、更復雜的分析算法通過大數據技術來實現;第二是在線數據訪問，也就是傳統ODS的延展，將更長期的數據做到在線化、將所有大量相對靜態的數據(參數)從昂貴的存儲設備下放到大數據平臺，提供給更多的渠道進行并發實時訪問。

大數據技術發展到今天，全新的大數據實現技術大致可以分為3類：Hadoop技術、分析型分布式數據庫和聯機交互型分布式數據庫。

在人們剛開始接觸大數據技術時，第一個想到的場景大多是海量數據分析。但是，隨著人們對大數據技術更加深入的了解，除了單純的批處理分析之外，海量數據交互式實時應用的場景同樣也成為技術人員關注的一個重點。因此，如果從技術路線的角度進行劃分，上述所說的3類實現技術中，Hadoop技術適用于結構化與非結構化的數據批處理分析;分析型分布式數據庫適用于結構化數據批處理分析與OLAP;而聯機交互型分布式數據庫則適用于交互式實時業務場景。

二、技術體系對比

在上述大數據的3種技術實現中，Hadoop技術貌似自成一套體系。Hadoop①與分布式數據庫的設計思路為什么有所差異，其定位和使用場景應該如何與分布式數據庫技術進行區分，這需要從兩種技術的起源與發展來進行分析。

(一)Hadoop

本質上，Hadoop技術只能算是以分布式文件系統 (HDFS)+分布式調度器(YARN)作為基礎的分布式計算框架，而不是數據庫。

Hadoop的歷史可以往前追溯10年，當年Google為了在幾萬臺PC服務器上構建超大數據集合并提供極高性能的并發訪問能力發明了MapReduce，這也是Hadoop誕生的理論基礎。

從Hadoop誕生背景可以看到，其主要解決的是超大規模集群下對于非結構化數據(Google扒取的網頁信息)進行批處理計算(例如計算PageRank等)的問題。實際上，在Hadoop架構中，一個分布式任務可以是類似傳統結構化數據的關聯、排序、聚集操作，也可以是針對非結構化數據的用戶自定義程序邏輯。

從Hadoop的發展歷程可以看到，最開始的Hadoop以Pig，Hive和MapReduce3種開發接口為代表，分別適用于腳本批處理、SQL批處理以及用戶自定義邏輯類型的應用。而Spark的發展更是如此，最開始的SparkRDD幾乎完全沒有SQL能力，還是套用了Hive發展出的Shark才能對SQL有了一部分的支持。但是，隨著企業用戶對Hadoop越發廣泛的使用，SQL漸漸成了大數據平臺在傳統行業的主要訪問方式之一。Hortonworks的Stinger，Cloudera的Impala，Databricks的SparkSQL，IBM的BigSQL都在兩年前開始逐漸進入市場，使Hadoop看起來貌似也成為了SQL的主戰場。

(二)分布式數據庫

分布式數據庫有著悠久的歷史，從以Oracle RAC為代表的聯機交易型分布式數據庫，到IBM DB2 DPF統計分析性分布式數據庫，分布式數據庫覆蓋了OLTP與OLAP幾乎全部的數據應用場景。

大部分分布式數據庫更集中在結構化計算與在線增刪改查上。例如IBM DB2 DPF，用戶可以像使用普通單點DB2數據庫一樣，幾乎透明地使用DPF版本。DPF中的SQL優化器能夠將一個查詢自動拆解并分發到多個節點中并行執行。

但是，傳統分布式數據庫最大的局限性在于對非結構化數據的支持。由于大部分分布式數據庫都是用SQL作為標準查詢語言，因此其數據的處理能力也僅局限在結構化數據，對于無法使用SQL進行解析的裸數據則完全無能為力。

分布式數據庫在近幾年也有著極大的轉型。從早年間NoSQL的異軍突起占據了互聯網分布式數據庫的半壁江山，到如今很多傳統關系型數據庫紛紛開始支持JSON格式，數據庫已經從單一的關系型數據庫向混合型數據庫發展。

(三)業務場景

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

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

三、行業發展趨勢

不論是Hadoop還是新一代分布式數據庫，在技術體系上兩者都已經向著計算存儲層分離的方式演進。對于Hadoop來說尤其明顯，HDFS存儲與YARN調度計算的分離，使得計算與存儲均可以按需橫向擴展。而分布式數據庫近年來也在遵循類似的趨勢，很多數據庫已經將底層存儲與上層的SQL引擎進行剝離，例如直接使用SparkSQL作為統計分析引擎、同時使用PostgreSQL作為交易處理引擎，是業界多種分布式數據庫使用的技術路線。兩種技術的體系結構如圖2所示。

Gartner2016年最新的數據庫報告中可以看到，國際業界對新型數據庫的定義有了新的劃分。傳統的XML數據庫、OO數據庫與pre-RDBMS正在消亡;新興領域的文檔類數據庫、圖數據庫、Table-Style數據庫②與Multi-Model③數據庫正在擴大自身影響;而傳統關系型數據庫、列存儲數據庫、內存分析型數據庫④也在考慮轉型。

可以看到，從技術完整性與成熟度來看，Hadoop確實還處于相對早期的形態。直到今天，一些SQL-on-Hadoop的方案還處于1.x甚至Beta版，在很多企業應用中需要大量的手工調優才能夠勉強運行。同時，Hadoop的主要應用場景一直以來面向批處理分析型業務，傳統數據庫在線聯機處理部分不是其主要的發展方向。

分布式數據庫領域經歷了幾十年的磨練，傳統RDBMS的MPP技術早已經爐火純青。不像Hadoop的發展方向完全固定為批處理作業，在分類眾多的分布式數據庫中，其主要發展方向基本可以分為“分布式聯機數據庫”與“分布式分析型數據庫”兩種。例如，以文檔和Multi-Model數據庫對結構化與半結構化數據的高并發進行聯機處理，以及列存儲、Table-Style、加內存分析型數據庫的結構化數據批處理分析，是這兩個方向最常見的技術實現手段。

同時，新型NoSQL數據庫在經歷了5-10年的發展后，已經開始進入到與傳統技術、其他技術互相融合的時代。例如，全球最知名的文檔數據庫與Multi-Model數據庫應屬MongoDB，在支持JSON存儲的同時也開始支持內置圖計算功能。國內的巨杉數據庫SequoiaDB也是以文檔數據庫為基礎，開始支持SQL與對象存儲。

對比Hadoop與分布式數據庫可以看出，Hadoop的產品發展方向定位與分布式數據庫中列存儲數據庫相當重疊。例如，Pivotal Greenplum，IBM DB2 BLU及國內的南大通用GBase 8a等，都與Hadoop的定位有著明顯的重合。而高并發聯機交易場景，在Hadoop中除了HBase能夠勉強沾邊以外，分布式數據庫則占據絕對的優勢，如圖3所示。

在另外的一個細分市場，即非結構化小文件存儲上，一直以來該領域都是對象存儲、塊存儲、與分布式文件系統的主戰場。如今，非關系型數據庫也開始進入該領域，可以預見，在未來的幾年中，小型非結構化文件存儲也可能成為分布式數據庫的戰場之一。

四、應用場景

不同應用場景應該使用不同的技術，沒有任何一種技術可以適用于所有業務場景。

大數據時代，在像金融這種傳統保守的行業中，對于交易類業務很少有企業敢于使用新技術替換主核心系統。一些企業開始嘗試在部分非核心交易的業務中使用MySQL，PostgreSQL等開源關系型數據庫。相比起過往任何業務都要使用Oracle或IBM的數據庫來說，這已經是國內金融行業在去IOE道路上的一大進步。

Hadoop與新型分布式數據庫在金融行業中的主要戰場則集中在非交易型業務上，也就是數據倉庫的延展，以及ODS的延展兩大方向。

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

ODS的延展，是對銀行歷史數據的歸集與聯機使用。在規模相對較大的銀行中，傳統ODS一般僅僅保留一小段時間的歷史數據作為數據加工的臨時存放區，而更早期的歷史數據要么被歸檔入帶庫，要么被加工清洗后進入數倉。而在大數據的場景中，很多業務開始對歷史數據的在線交互式訪問提出明確的需求。例如，前臺柜面是否需要提供給用戶對全歷史周期的回單查詢功能;銀行內部運維團隊能否對全行業務的歷史進行在線查詢訪問，以應對司法查詢的需求等。這些類型的應用場景存在并發量高、索引維度多、查詢延遲低等特性，使用Hadoop的HBase存在眾多不便，是分布式聯機數據庫的主要應用場景。

除了存放歷史數據以外，ODS延展的另一大方向是存放從數據倉庫中分析和挖掘的結果，供外部應用調用查詢。例如，手機銀行根據每個用戶畫像的標簽結果與當前行為提供實時產品推薦，就是將分析結果與實時行為數據相結合的場景。這類應用可以進一步擴展到事中風控等更核心的業務場景中去。

因此，在大數據時代中，Hadoop與分布式數據庫在金融行業的架構中應當相輔相成，互相彌補各自的不足。Hadoop與分布式分析型數據庫在結構化數據批處理分析中都可以得到很好的滿足;Hadoop對于非結構化數據內容分析有著數據庫無法比擬的優勢;而分布式聯機數據庫則在高并發在線業務場景中能夠更靈活地管理和使用數據。

譬如，近幾年來很多銀行在做“用戶畫像”業務，希望根據用戶的歷史交易行為給每個用戶打標簽，并在柜面、網銀、手機銀行等多個渠道有針對性地推薦理財產品。當使用大數據技術實現該場景時，一個比較簡單常見的做法是：

(1)將用戶的歷史行為批量寫入Hadoop;

(2)在Hadoop中使用機器學習對用戶行為分類建模;

(3)在Hadoop中定期批量掃描用戶歷史行為，根據模型對用戶打標簽;

(4)將用戶標簽結果寫入分布式數據庫;

(5)各渠道業務通過中間件連接數據庫，查詢用戶標簽進行產品推薦。

五、展望未來

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

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

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

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

從分布式數據庫的角度來看，筆者認為，在未來3-5年中，NoSQL數據庫將漸漸向Multi-Model數據庫演進，在提供直接API訪問數據的同時，提供SQL結構化數據的訪問方式。例如，業界知名的MongoDB與國內的巨杉數據庫SequoiaDB都在支持JSON存儲的同時，支持SQL甚至其他類型的數據存儲格式⑤。同時，分布式關系型數據庫會進一步加強融合，提供多引擎存儲方案(GBase 8a/8t)，甚至開始支持JSON等半結構化數據(PostgreSQL)。

總而言之，在大數據技術下，分布式數據庫與Hadoop兩者相輔相成。Hadoop適合非結構化批處理分析場景;分布式分析型數據庫與SQL-on-Hadoop方案在結構化批處理分析場景中有所重疊;而分布式聯機數據庫則更適合高并發在線業務場景。

① 盡管如今Spark異軍突起，MapReduce后繼無力，但多數廠商或機構漸漸開始將Spark與Hadoop進行融合。本文中，所有提到Hadoop的部分均指Hadoop與Spark兩種技術。

② 類似Cassandra這類有著表結構定義，但是又不存在表之間關系定義的數據庫叫做Table-Style數據庫。

③ 類似MongoDB這類在一個數據庫中支持多種存儲格式，例如JSON、圖、表，并提供不同類型使用接口的數據庫。

④ 以SAP HANA為代表的內存分析型數據庫，以PC服務器配置大量內存為硬件基礎，將海量數據緩存在內存中換取極高的訪問效率，做到對大量數據的實時交互式分析。這類業務也稱作HTAP場景。

⑤ SequoiaDB支持小文件對象存儲;MongoDB支持內置圖計算機制。

總結

以上是生活随笔為你收集整理的大数据技术下 分布式数据库何去何从？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。