一、前言

大數(shù)據(jù)技術從誕生到現(xiàn)在缭付，已經(jīng)經(jīng)歷了十幾個年頭毅待。市場上早已不斷有公司或機構政恍，給廣大金融從業(yè)者“洗腦”大數(shù)據(jù)未來的美好前景與趨勢。隨著用戶對大數(shù)據(jù)理念與技術的不斷深入了解，人們已經(jīng)開始從理論探索轉向對場景落地的尋找，讓大數(shù)據(jù)在企業(yè)中落地并開花結果。

從大數(shù)據(jù)的管理和應用方向集中在兩個領域痪欲。第一，大數(shù)據(jù)分析相關攻礼，針對海量數(shù)據(jù)的挖掘业踢、復雜的分析計算；第二秘蛔，在線數(shù)據(jù)操作陨亡，包括傳統(tǒng)交易型操作以及海量數(shù)據(jù)的實時訪問傍衡。大數(shù)據(jù)高并發(fā)查詢操作。用戶根據(jù)業(yè)務場景以及對數(shù)據(jù)處理結果的期望選擇不同的大數(shù)據(jù)管理方法负蠕。

分析型的大數(shù)據(jù)管理以Hadoop/Spark技術為主蛙埂，適用于數(shù)據(jù)批處理分析挖掘的場景。隨著時間推移遮糖，Hadoop由于開源生態(tài)體系過于龐大且擴張迅速绣的，對于大數(shù)據(jù)工具選擇、實施復雜度以及性價比都比較難以控制欲账。近期屡江，著名市場分析和咨詢機構Gartner發(fā)布報告[Gartner 2017年報告《Hype Cycle for Data Management,2017》]，報告指出目前大數(shù)據(jù)服務不再依賴單一Hadoop大數(shù)據(jù)商業(yè)平臺赛不，必須從滿足用戶的場景和案例的角度出發(fā)惩嘉。

分布式數(shù)據(jù)庫則是在線操作性的大數(shù)據(jù)管理而誕生的，強調滿足大數(shù)據(jù)在實時高并發(fā)請求壓力下的交互業(yè)務場景踢故。這一領域的“大數(shù)據(jù)”應用也正在被更多的人接受文黎，又由于分布式數(shù)據(jù)庫的落地更簡單，開發(fā)運維上更接近與傳統(tǒng)數(shù)據(jù)管理系統(tǒng)殿较。因此近年來分布式數(shù)據(jù)庫市場也在快速地發(fā)展壯大耸峭。

二、技術體系對比

在上述大數(shù)據(jù)技術實現(xiàn)中淋纲，Hadoop技術看似是自成一套體系劳闹。Hadoop/Spark與分布式數(shù)據(jù)庫的設計思路為什么有所差異，其定位和使用場景應該如何與分布式數(shù)據(jù)庫技術進行區(qū)分洽瞬？這需要從兩種技術的起源與發(fā)展來進行分析本涕。（Gartner 2017年報告）

1. 大數(shù)據(jù)分析

大數(shù)據(jù)分析體系以Hadoop生態(tài)為主，近年來逐漸火熱的Spark技術也是主要的生態(tài)之一伙窃。其中偏友，Hadoop技術只能算是以HDFS+YARN作為基礎的分布式文件系統(tǒng)，而不是數(shù)據(jù)庫对供。

Hadoop的歷史可以向前追溯10年，當年Google為了在幾萬臺PC服務器上構建超大數(shù)據(jù)集合并提供極高性能的并發(fā)訪問能力氛濒，從而發(fā)明了MapReduce产场，也是Hadoop誕生的理論基礎。

從Hadoop的誕生背景可以看出舞竿，其主要解決的問題是超大規(guī)模集群下如何對非結構化數(shù)據(jù)（Google扒取的網(wǎng)頁信息）進行批處理計算（例如計算PageRank等）京景。實際上，在Hadoop架構中骗奖，一個分布式任務可以是類似傳統(tǒng)結構化數(shù)據(jù)的關聯(lián)确徙、排序醒串、聚集操作，也可以是針對非結構化數(shù)據(jù)的用戶自定義程序邏輯鄙皇。

再來看Hadoop的發(fā)展道路芜赌。最開始的Hadoop以Big、Hive和MapReduce三種開發(fā)接口為代表伴逸，分別適用于腳本批處理缠沈、SQL批處理以及用戶自定義邏輯類型的應用。而Spark的發(fā)展更是如此错蝴，最開始的SparkRDD幾乎完全沒有SQL能力洲愤，還是套用了Hive發(fā)展出的Shark才能對SQL有了一部分的支持。但是顷锰，隨著企業(yè)用戶對Hadoop的使用越發(fā)廣泛柬赐，SQL已經(jīng)漸漸成為大數(shù)據(jù)平臺在傳統(tǒng)行業(yè)的主要訪問方式之一。Hortonworks的Stinger官紫、Cloudera的Impala肛宋、Databricks的SparkSQL、IBM的BigSQL都在兩年前開始慢慢搶占市場万矾，使得Hadoop看起來貌似也成為了SQL的主戰(zhàn)場悼吱。

2. 分布式數(shù)據(jù)庫

分布式數(shù)據(jù)庫有著悠久的歷史，從以Oracle RAC為代表的聯(lián)機交易型分布式數(shù)據(jù)庫良狈，到IBM DB2 DPF統(tǒng)計分析性分布式數(shù)據(jù)庫后添，分布式數(shù)據(jù)庫覆蓋了OLTP與OLAP幾乎全部的數(shù)據(jù)應用場景。

大部分分布式數(shù)據(jù)庫功能集中在結構化計算與在線增刪改查上薪丁。例如IBM DB2 DPF遇西，用戶可以像使用普通單點DB2數(shù)據(jù)庫一樣，幾乎透明地使用DPF版本严嗜。DPF中的SQL優(yōu)化器能夠將一個查詢自動拆解并分發(fā)到多個節(jié)點中并行執(zhí)行粱檀。

但是，這些傳統(tǒng)的分布式數(shù)據(jù)庫以數(shù)倉及分析類OLAP系統(tǒng)為主漫玄，其局限性在于茄蚯，其底層的關系型數(shù)據(jù)庫存儲結構在效率上并不能滿足大量高并發(fā)的數(shù)據(jù)查詢以及大數(shù)據(jù)數(shù)據(jù)加工和分析的效率要求。

因此睦优，分布式數(shù)據(jù)庫在近幾年也有著極大的轉型渗常，從單一的數(shù)據(jù)模型向多模的數(shù)據(jù)模型轉移，將OLTP汗盘、聯(lián)機高并發(fā)查詢以及支持大數(shù)據(jù)加工和分析結合起來皱碘，不再單獨以OLAP作為設計目標。同時隐孽，分布式數(shù)據(jù)庫在訪問模式上也出現(xiàn)了K/V癌椿、文檔健蕊、寬表、圖等分支踢俄，支持除了SQL查詢語言之外的其他訪問模式缩功，大大豐富了傳統(tǒng)分布式數(shù)據(jù)庫單一的用途。一般來說褪贵，多模數(shù)據(jù)庫的主要目的是為了滿足具有高性能要求的操作型需求以及目標明確的數(shù)據(jù)倉庫功能掂之，而不是類似大數(shù)據(jù)深度學習等數(shù)據(jù)挖掘場景。

3. 業(yè)務場景

從大數(shù)據(jù)技術的使用方式上來看脆丁，這些技術一方面可以按照結構化與非結構化數(shù)據(jù)類型劃分世舰，另一方面也可以按照業(yè)務類型，即統(tǒng)計分析與聯(lián)機操作兩種類型（圖1）槽卫。

圖1 大數(shù)據(jù)業(yè)務類型

Hadoop的設計思路是解決超大規(guī)模數(shù)據(jù)場景下的統(tǒng)計分析問題跟压，而分布式數(shù)據(jù)庫則根據(jù)細分領域不同，適用于結構化數(shù)據(jù)的統(tǒng)計分析歼培，以及海量數(shù)據(jù)的聯(lián)機操作震蒋。

Hadoop和分布式數(shù)據(jù)庫最大的差異在于控制數(shù)據(jù)的顆粒細度不同。Hadoop傾向于對整體數(shù)據(jù)的操作躲庄，例如對全量數(shù)據(jù)的統(tǒng)計分析查剖；而分布式數(shù)據(jù)庫強調精準控制到數(shù)據(jù)行，譬如對于某一條記錄的查詢更改操作噪窘。由此可見笋庄，Hadoop的業(yè)務場景非常適合低并發(fā)、大吞吐量倔监、離線為主的數(shù)據(jù)分析直砂，而分布式數(shù)據(jù)庫適合高并發(fā)、在線實時的數(shù)據(jù)操作浩习。這些差異性在非結構化數(shù)據(jù)的處理中也非常顯著静暂。

三、行業(yè)發(fā)展趨勢

不論是Hadoop還是分布式數(shù)據(jù)庫谱秽，技術體系上兩者都已經(jīng)向著計算存儲層分離的方式演進洽蛀。對于Hadoop來說這一趨勢非常明顯，HDFS存儲與YARN調度計算的分離疟赊，使得計算與存儲均可以按需橫向擴展辱士。而分布式數(shù)據(jù)庫近年來也在遵循類似的趨勢，很多數(shù)據(jù)庫已經(jīng)將底層存儲與上層的SQL引擎進行剝離听绳，例如直接使用SparkSQL作為統(tǒng)計分析引擎、同時使用PostgreSQL作為交易處理引擎异赫，這是業(yè)界多種分布式數(shù)據(jù)庫使用的技術路線椅挣。

圖2 分布式數(shù)據(jù)庫/Hadoop體系結構

從Gartner在2016年最新的數(shù)據(jù)庫報告中可以看到头岔，國際業(yè)界對新型數(shù)據(jù)庫的定義有了新的劃分。傳統(tǒng)的XML數(shù)據(jù)庫鼠证、OO數(shù)據(jù)庫峡竣、與pre-RDBMS正在消亡；新興領域文檔類數(shù)據(jù)庫量九、圖數(shù)據(jù)庫适掰、Table-Style數(shù)據(jù)庫（類似Cassandra這類有著表結構定義，但是又不存在表之間關系定義的數(shù)據(jù)庫叫做Table-Style數(shù)據(jù)庫）與Multi-Model數(shù)據(jù)庫正在擴大自身影響荠列；傳統(tǒng)關系型數(shù)據(jù)庫类浪、列存儲數(shù)據(jù)庫、內存分析型數(shù)據(jù)庫（以SAP HANA為代表的內存分析型數(shù)據(jù)庫肌似，以PC服務器配置大量內存為硬件基礎费就，將海量數(shù)據(jù)緩存在內存中換取極高的訪問效率，做到對大量數(shù)據(jù)的實時交互式分析川队。這類業(yè)務也稱作HTAP場景）正在考慮轉型力细。

可以看到，從技術完整性與成熟度來看固额，Hadoop確實還處于相對早期的形態(tài)眠蚂。直到今天，一些SQL-on-Hadoop的方案還處于1.x甚至Beta版斗躏，在很多企業(yè)應用中需要大量的手工調優(yōu)才能夠勉強運行逝慧。同時，Hadoop的主要應用場景一直以來面向批處理分析型業(yè)務瑟捣，傳統(tǒng)數(shù)據(jù)庫在線聯(lián)機處理部分不是其主要的發(fā)展方向馋艺。同時Hadoop技術由于開源生態(tài)體系過于龐大，同時參與改造的廠商太多迈套，使得用戶很難完全熟悉整個體系捐祠，這一方面大大增加了開發(fā)的復雜度，提升了用戶使用的難度桑李，另一方面則是各個廠商之間維護不同版本踱蛀，使得產(chǎn)品的發(fā)展方向可能與開源版本差別逐漸加大。

另一方面贵白，分布式數(shù)據(jù)庫領域經(jīng)歷了幾十年的磨練率拒，傳統(tǒng)RDBMS的MPP技術早已經(jīng)爐火純青，在分類眾多的分布式數(shù)據(jù)庫中禁荒，其主要發(fā)展方向基本可以分為“分布式聯(lián)機數(shù)據(jù)庫”與“分布式分析型數(shù)據(jù)庫”兩種猬膨。例如，以結構化數(shù)據(jù)和Multi-Model數(shù)據(jù)庫對結構化與半結構化數(shù)據(jù)的高并發(fā)聯(lián)機處理呛伴，和列存儲勃痴、Table-Style谒所、加內存分析型數(shù)據(jù)庫的結構化數(shù)據(jù)批處理分析，是這兩個方向最常見的技術實現(xiàn)手段沛申。同時劣领，新一代數(shù)據(jù)庫在經(jīng)歷了5-10年的發(fā)展后，已經(jīng)開始進入到一個與傳統(tǒng)技術铁材、其他技術互相融合的時代尖淘。

國內的巨杉數(shù)據(jù)庫SequoiaDB作為分布式數(shù)據(jù)庫，在Multi-Model多模操作型數(shù)據(jù)庫基礎上著觉，已經(jīng)開始全面支持分布式OLTP和分布式對象存儲村生。

對比Hadoop與分布式數(shù)據(jù)庫可以看出，Hadoop的產(chǎn)品發(fā)展方向定位固惯，與分布式數(shù)據(jù)庫中列存儲數(shù)據(jù)庫相當重疊梆造。例如，Pivotal Greenplum葬毫、IBM DB2 BLU镇辉、以及國內的南大通用GBase 8a，都與Hadoop的定位有著明顯的重合贴捡。而在高并發(fā)聯(lián)機交易場景忽肛，在Hadoop中除了HBase能夠勉強沾邊以外，分布式數(shù)據(jù)庫則占據(jù)絕對的優(yōu)勢烂斋。

圖3 分布式數(shù)據(jù)庫與Hadoop適用場景象限

目前屹逛，從Hadoop行業(yè)的發(fā)展來看，Cloudera汛骂、Hortonworks等廠商已經(jīng)不再宣稱自己是Hadoop分銷商罕模，而是將其定位改變?yōu)閿?shù)據(jù)科學與機器學習服務商。因此帘瞭，從商業(yè)模式上看以Hadoop分銷的商業(yè)模式基本已經(jīng)宣告結束淑掌，用戶已經(jīng)體驗到維護整個Hadoop平臺的困難而不愿被強迫購買整個平臺。大量用戶更愿意把原來Hadoop的部件拆開靈活使用蝶念，為使用場景和結果買單抛腕，而非平臺本身買單。

另外一個細分市場——非結構化小文件存儲媒殉，一直以來都是對象存儲担敌、塊存儲，與分布式文件系統(tǒng)的主戰(zhàn)場廷蓉。如今全封，一些新一代數(shù)據(jù)庫也開始進入該領域，可以預見在未來的幾年中，小型非結構化文件存儲也可能成為具備多模數(shù)據(jù)處理能力的分布式數(shù)據(jù)庫的戰(zhàn)場之一刹悴。

四给猾、應用場景

不同應用場景應該使用不同的技術，沒有任何一種技術可以適用于全部業(yè)務場景颂跨。

大數(shù)據(jù)時代，在像金融這種相對嚴謹?shù)男袠I(yè)中扯饶，核心交易類業(yè)務恒削，由于一些歷史原因，很少有企業(yè)敢于立刻使用新技術替換主核心系統(tǒng)尾序。但是在其他的系統(tǒng)中钓丰，分布式數(shù)據(jù)庫既有做到對傳統(tǒng)Oracle、IBM數(shù)據(jù)庫進行替換每币、“瘦身”携丁，同時在大數(shù)據(jù)應用中，分布式數(shù)據(jù)庫地位也不斷上升兰怠。

數(shù)據(jù)倉庫延展實際上就是對傳統(tǒng)數(shù)倉模型的一個補充梦鉴。一直以來，數(shù)據(jù)倉庫的建設都是遵從著從頂向下的原則揭保，也就是先建立數(shù)據(jù)模型肥橙，再根據(jù)數(shù)據(jù)模型構建表結構與SQL，之后進行ETL和數(shù)據(jù)清洗秸侣，最后得到相應的報表存筏。而大數(shù)據(jù)與新興的機器學習，帶給人們另一種從底向上的分析思路：首先建立分析型數(shù)據(jù)湖味榛，將需要分析的數(shù)據(jù)均納入湖中進行脫敏和標準化椭坚，之后利用機器學習、深度挖掘等分布式計算技術搏色，在這些海量的數(shù)據(jù)中尋找規(guī)律善茎。這種思路與傳統(tǒng)數(shù)倉思路的最大不同，在于以歷史數(shù)據(jù)展現(xiàn)出的事實為基礎構建分析模型继榆，而非與假設出的數(shù)據(jù)模型為基礎進行構建巾表。數(shù)據(jù)倉庫延展，是Hadoop與分布式列存儲的主打場景略吨。

對于在線和實時數(shù)據(jù)操作集币，分布式數(shù)據(jù)庫則是另一個主要的技術類型。比如翠忠，分布式數(shù)據(jù)庫用于ODS就是其中一個典型的應用案例鞠苟。在規(guī)模相對較大的銀行中，傳統(tǒng)ODS一般僅僅保留一小段時間的歷史數(shù)據(jù)作為數(shù)據(jù)加工的臨時存放區(qū)，而更早期的歷史數(shù)據(jù)要么被歸檔入帶庫当娱，要么被加工清洗后進入數(shù)倉吃既。但在大數(shù)據(jù)的場景中，很多業(yè)務開始對歷史數(shù)據(jù)的在線交互式訪問提出明確的更高需求跨细。例如鹦倚，前臺柜面是否需要提供給用戶對全歷史周期的回單查詢功能；銀行內部運維團隊能否對全行業(yè)務的歷史進行在線查詢訪問冀惭，以應對司法查詢的需求震叙，等等。這些類型的應用場景存在并發(fā)量高散休、索引維度多媒楼、查詢延遲低等特性，使用Hadoop的HBase存在眾多不便戚丸，正是分布式聯(lián)機數(shù)據(jù)庫的主要應用場景划址。

除了存放歷史數(shù)據(jù)以外，ODS延展的另一大方向就是作為數(shù)據(jù)集市限府，存放從Hadoop中分析和挖掘的結果夺颤，供外部應用調用查詢。例如谣殊，手機銀行根據(jù)每個用戶畫像的標簽結果與當前行為提供實時產(chǎn)品推薦拂共，就是將分析結果與實時行為數(shù)據(jù)相結合的場景。這類應用可以進一步擴展到事中風控等更核心的業(yè)務場景中去姻几。

因此宜狐，在大數(shù)據(jù)時代中，Hadoop與分布式數(shù)據(jù)庫在金融行業(yè)的架構中應當相輔相成蛇捌，互相彌補各自的不足抚恒。Hadoop與分布式分析型數(shù)據(jù)庫在結構化數(shù)據(jù)批處理分析中都可以很好地滿足需求；Hadoop對于非結構化數(shù)據(jù)分析有著數(shù)據(jù)庫無法比擬的優(yōu)勢络拌；而分布式聯(lián)機數(shù)據(jù)庫則在高并發(fā)在線業(yè)務場景中能夠更靈活地管理和使用數(shù)據(jù)俭驮。

譬如說，近幾年來很多銀行在做“用戶畫像”業(yè)務春贸，希望通過用戶的歷史交易行為給每個用戶打標簽混萝，并在柜面、網(wǎng)銀萍恕、手機銀行等多個渠道有針對性地推薦理財產(chǎn)品逸嘀。當使用大數(shù)據(jù)技術實現(xiàn)該場景時，一個比較簡單常見的做法是：

（1）將用戶的歷史行為批量寫入Hadoop允粤；

（2）在Hadoop中使用機器學習對用戶行為分類建模崭倘；

（3）在Hadoop中定期批量掃描用戶歷史行為翼岁，根據(jù)模型對用戶打標簽；

（4）將用戶標簽結果寫入分布式數(shù)據(jù)庫司光；

（5）各渠道業(yè)務通過中間件連接數(shù)據(jù)庫琅坡，查詢用戶標簽進行產(chǎn)品推薦。

五残家、展望未來

對于大數(shù)據(jù)技術未來的發(fā)展榆俺，還是會回歸用戶的真正需求，Hadoop/Spark將會繼續(xù)在數(shù)據(jù)分析領域獨占鰲頭坞淮，而在實時聯(lián)機交互領域谴仙，分布式數(shù)據(jù)庫則會成為另一股重要技術力量。

在銀行中碾盐，對于新技術的產(chǎn)品選型不能單從當前業(yè)務場景的需求出發(fā)，更要考慮到該產(chǎn)品未來3-5年的發(fā)展道路和方向揩局，是否能夠不斷迭代滿足企業(yè)未來的需求毫玖。因此，用戶僅了解每一種技術的現(xiàn)狀是遠遠不夠的凌盯，只有當認識到一種技術的發(fā)展策略以及其架構局限性后付枫，才能夠預見和洞察未來。

架構局限性并不等于功能的缺失驰怎。很多新型技術在開始時都無法提供像Oracle一樣完備的企業(yè)級功能阐滩，但并不是說用戶必須要等到全部功能完備后才開始考慮學習和使用。用戶在評估一種新產(chǎn)品和技術時县忌，產(chǎn)品的功能點需要滿足幾個必備的基礎功能掂榔，而一些高級功能則不需要立刻具備。作為IT決策層症杏，最重要的是評估該產(chǎn)品和技術的架構局限性装获，即是否在可預見的未來，基于該架構能夠實現(xiàn)和滿足銀行一段時間后的業(yè)務需求厉颤。

Hadoop的架構基礎核心是HDFS與YARN穴豫，任何請求首先被發(fā)送至YARN進行調度。而YARN則是根據(jù)NameNode計算出一個任務需要訪問的數(shù)據(jù)塊所在服務器生成一系列任務逼友，并發(fā)送給相應的服務器進行執(zhí)行精肃。除非從底層重寫整個調度算法，該機制冗長的流程制約著Hadoop向聯(lián)機業(yè)務繼續(xù)發(fā)展帜乞。

數(shù)據(jù)庫的架構核心是數(shù)據(jù)存儲結構司抱。只有存在可定義的存儲結構，數(shù)據(jù)庫才能夠提供對數(shù)據(jù)字段的檢索挖函、查詢状植、更新等操作浊竟。該機制一方面提供了對結構化與半結構化數(shù)據(jù)有效的管理能力，另一方面卻制約著用戶對于非結構化數(shù)據(jù)的處理能力津畸。短期來看振定，分布式數(shù)據(jù)庫在非結構化數(shù)據(jù)管理上，主要還停留在小文件的存儲和檢索領域肉拓。對于文件內部信息的查詢能力后频，可以使用全文檢索索引實現(xiàn)，但是對于二進制非文本類的無結構數(shù)據(jù)暖途，分布式數(shù)據(jù)庫還不存在較好的方式能夠對其中的信息做到全維度自由檢索和查詢卑惜。

從分布式數(shù)據(jù)庫的角度來看，筆者認為驻售，在未來的3-5年中露久，新一代數(shù)據(jù)庫將會漸漸向Multi-Model數(shù)據(jù)庫演進，同時提供SQL和API兩種數(shù)據(jù)訪問模式欺栗。 例如毫痕，巨杉數(shù)據(jù)庫SequoiaDB在支持SQL和API訪問結構化和半結構化存儲的同時，也支持其他類型的數(shù)據(jù)存儲格式迟几，包括非結構化的對象存儲消请。同時，分布式關系型數(shù)據(jù)庫會進一步加強融合类腮，提供多引擎存儲方案（GBase 8a/8t）臊泰，甚至有的產(chǎn)品已經(jīng)開始支持JSON等半結構化數(shù)據(jù)（PostgreSQL）。

總而言之蚜枢，在大數(shù)據(jù)技術下缸逃，分布式數(shù)據(jù)庫與Hadoop兩者相輔相成。Hadoop適合非結構化批處理分析場景厂抽；分布式數(shù)據(jù)庫則更適合高并發(fā)在線業(yè)務場景察滑。

我的博客：CODE大全：www.codedq.net；業(yè)余草：www.xttblog.com修肠；愛分享：www.ndislwf.com或ifxvn.com贺辰。