在2016 Hadoop技術峰會的主題演講上，星環(huán)科技創(chuàng)始人孫元浩深入淺出的闡述了Hadoop是如何推動數(shù)據(jù)倉庫技術進行深刻變革。

一、數(shù)據(jù)庫技術進入戰(zhàn)略轉(zhuǎn)折點

今年大會的主題是Hadoop十年。2006年雅虎等團隊開始研發(fā)Hadoop技術至今已整整十年。在此之間技術發(fā)展迅速，Hadoop上的生態(tài)系統(tǒng)逐漸擴大。各個行業(yè)的用戶逐漸開始基于這一新的技術來開發(fā)全新的應用，甚至將原先的應用向Hadoop之上進行遷移。未來，Hadoop會成為企業(yè)數(shù)據(jù)中心的核心。經(jīng)過這10年的發(fā)展，今年開始進入一個戰(zhàn)略轉(zhuǎn)折點(strategic inflection point)。這意味著新的技術開始逐漸取代和超越老的技術，并在各個行業(yè)迅速發(fā)展。未來的若干年之內(nèi)，取代過程會不斷加速。星環(huán)近3年的發(fā)展，經(jīng)過持續(xù)的研發(fā)、投入以及大量的案例積累，達到新的高度。去年12月份Gartner分析師把星環(huán)科技(Transwarp)列為了國際主流的Hadoop發(fā)行版廠商之一，其他幾家包括Cloudera、Hortonworks、MapR。另外還有兩家公司分別是IBM和Pivotal，他們采用Open data Platform。全球共有6家公司上榜，星環(huán)也很榮幸能成為其中一家。

[[164906]]

今年2月份Gartner發(fā)布的數(shù)據(jù)倉庫魔力象限當中，星環(huán)科技也被放入了遠見者(Visionaries)象限當中。這個象限里基本上都是采用 Hadoop技術的創(chuàng)業(yè)公司。這些公司采用全新的技術，逐漸替代傳統(tǒng)數(shù)據(jù)庫來構造新的數(shù)據(jù)平臺。另外雖然目前***象限(Leaders)仍是大廠商，如 Oracle、Teradata等，但是經(jīng)過這10年的經(jīng)驗技術的積累，逐漸達到戰(zhàn)略轉(zhuǎn)折點，技術的取代過程明顯加速。如果關注這些***公司股票在過去一年的價格變化，就會發(fā)現(xiàn)市場預期在2016至2017年技術會發(fā)生非常大的變化。在企業(yè)客戶中，使用新技術的步伐會明顯加速。

二、中美Hadoop應用統(tǒng)計對比

今天我演講的題目是介紹Hadoop是如何推動數(shù)據(jù)倉庫技術進行深刻變革的。這里有一組統(tǒng)計數(shù)據(jù)：

左邊的數(shù)據(jù)是Wikibon的分析師做的美國市場中Hadoop新技術的應用場景統(tǒng)計。他采訪了上千名Hadoop的用戶，這其中有60%的用戶使用 Hadoop技術來做數(shù)據(jù)倉庫，有25%的用戶是按照交互式BI的，在 Hadoop之上用報表工具、可視化工具來做交互式分析數(shù)據(jù)報表。同時有6%的用戶是在用HBase、Cassandra來做OLAP的簡單輕量級 Key-Value查詢。有4%用戶使用MongoDB、Couchbase文檔式數(shù)據(jù)庫進行文檔存儲，還有5%的用戶使用流處理來做實時數(shù)據(jù)研判，由此構成一個完整的100%的應用分類。當然還有可能有一些其他的應用漏掉了，但這幾個是主要的應用產(chǎn)品。

在中國市場，根據(jù)我們的樣本中幾百名企業(yè)用戶進行統(tǒng)計，結果跟美國稍微有點差異。分析結果顯示，有56%的客戶是做數(shù)據(jù)倉庫的，包括ODS、 ETL、數(shù)據(jù)清洗等，如在我們的客戶中，用于取代關系型數(shù)據(jù)庫提供完整的數(shù)據(jù)倉庫支持，來建構各種主題模型。這個比例是比較接近美國用戶的。但是我們只有 8%的用戶在做交互式BI。自主BI這一塊在國內(nèi)也開始興起。注意到和美國市場相比，顯著不一樣的地方在于我們有24%的客戶是用來做輕量級查詢的，這個百分比指的是客戶數(shù)量占比而不是客戶集群規(guī)模(構成的集群節(jié)點數(shù)量)。這個比較有趣的現(xiàn)象說明，實際上在中國，應用比較簡單，因為客戶的數(shù)據(jù)量非常巨大，才會使用新技術解決問題。實際上中國客戶的數(shù)據(jù)量，跟美國同類型客戶的數(shù)據(jù)量相比是要大一個數(shù)量級(10倍)的，簡單的查詢對中國的客戶來說是有巨大的困難的。所以我們可以看到有24%的客戶在用Hyperbase(HBase)組件進行簡單查詢。還有2%的客戶是用我們的產(chǎn)品來進行文檔的搜索和圖檢索。另外還有個很大的不同是有10%的用戶是用流處理的。從圖中就可以發(fā)現(xiàn)，我們國家的工業(yè)4.0制造業(yè)傳感器的網(wǎng)絡建設速度是快于美國的。我們的用戶群中比例明顯就超過了美國的市場比例。

三、傳統(tǒng)數(shù)據(jù)倉庫面臨的四大挑戰(zhàn)

實際上大家可以看到，Hadoop技術在過去一段時間之內(nèi)，至少在2015年逐漸開始往數(shù)據(jù)倉庫方向轉(zhuǎn)變。當然，Hadoop在早年剛開始創(chuàng)建的時候，主要也是作為數(shù)據(jù)倉庫的，所以現(xiàn)在越來越多的行業(yè)也開始用Hadoop技術做數(shù)據(jù)倉庫。那么什么是數(shù)據(jù)倉庫?Gartner的解釋是：數(shù)據(jù)倉庫不僅是一個單一的數(shù)據(jù)庫，它是一整套的數(shù)據(jù)管理系統(tǒng)，包含很多的輔助工具、一些設計理念和管理方法。傳統(tǒng)的數(shù)據(jù)倉庫技術，經(jīng)過快20年或者更長時間的發(fā)展，已經(jīng)面臨了一些瓶頸。

***個問題，我們看到隨著數(shù)據(jù)量增大，包括復雜程序應用的增多，傳統(tǒng)數(shù)據(jù)倉庫越來越不堪重負。我們有一個客戶在數(shù)據(jù)倉庫建立了5000個統(tǒng)計報表應用。我們也有客戶使用著數(shù)據(jù)量近20個PB的商業(yè)系統(tǒng)。對于大部分的企業(yè)用戶，數(shù)據(jù)量一般在幾十個TB 或者幾百個TB左右。這么大的數(shù)據(jù)量對傳統(tǒng)的倉庫系統(tǒng)來說是非常大的負擔。單一的數(shù)據(jù)倉庫無法處理這么大量的數(shù)據(jù)，所以在這一塊需要新的技術，特別是利用分布式計算來取代原本單一的計算方式來進行橫向擴展。我們認為Hadoop技術能成功的最根本的原因是它是從單機的集中式運算變成了分布式計算，這是它***的計算模式的演變。把集中計算變成分布計算是一個必然趨勢，這是碰到的***個困難，一是需要一些新型的分布式數(shù)據(jù)庫技術進行性能的加速，來處理這種幾百 TB或者上PB的數(shù)據(jù)量。二是隨著數(shù)據(jù)源的不斷增多，訪問數(shù)據(jù)的方式變得非常復雜。我們很多客戶有幾百個庫表，有幾千上萬張表，這樣復雜的數(shù)據(jù)模型通常很難把所有數(shù)據(jù)存儲到一個數(shù)據(jù)庫當中，只能分攤到很多個庫當中。對數(shù)據(jù)的使用者帶來了很大的困難，因為他們需要把多種數(shù)據(jù)全部存儲起來。這個是***個大的困難。

第二個問題是數(shù)據(jù)的類型發(fā)生變化，過去是以結構化數(shù)據(jù)為主，80%是結構化數(shù)據(jù)?，F(xiàn)在非結構化數(shù)據(jù)逐漸增多，這個值開始反過來，80%是非結構化數(shù)據(jù)和半結構化數(shù)據(jù)。但是從價值度來講， 80%的價值密度仍然是來自于結構化數(shù)據(jù)。而對于企業(yè)來講，需要這些非結構化數(shù)據(jù)，進行存儲分析。另外在數(shù)據(jù)源變多以后，用戶和業(yè)務部門也變多。這些部門之間如何進行資源有效管理和隔離，變成一個非常嚴重的問題。例如過去有些銀行客戶是采用行政處罰措施，如果有人寫一條SQL，把數(shù)據(jù)倉庫資源耗盡，導致其他人不能使用，那么這個人今年的獎勵就沒有了。采用這種方式是沒有效果的，因為用戶根本就不知道他寫的這個SQL，會不會把數(shù)據(jù)倉庫跑掛掉。另外做訪問控制也是很痛苦的，為了使不同的分支機構只能訪問自己的數(shù)據(jù)，需要創(chuàng)建視圖。如果用戶有1000張表，同時還有幾十個分支機構，那么久需要創(chuàng)建上萬個視圖，這對數(shù)據(jù)的視圖管理會帶來巨大的挑戰(zhàn)。所以在幾年前，分析機構就提出要建邏輯數(shù)據(jù)倉庫。邏輯數(shù)據(jù)倉庫就是在過去幾年當中一直被數(shù)據(jù)倉庫***反復強調(diào)，我們需要去建一個邏輯上大的數(shù)據(jù)倉庫，他底下可以包括多個數(shù)據(jù)源—-通過database federation(數(shù)據(jù)聯(lián)邦)功能，同時它可以跨多種數(shù)據(jù)源，可以把結構化數(shù)據(jù)和非結構化數(shù)據(jù)統(tǒng)一處理。Michael Stonebraker在前段時間講過，未來不管是傳統(tǒng)數(shù)據(jù)庫技術還是大數(shù)據(jù)技術，大家都會統(tǒng)一到使用SQL接口，包括結構化數(shù)據(jù)與非機構化數(shù)據(jù)，非結構化數(shù)據(jù)也會被結構化后進行處理。所以邏輯數(shù)據(jù)倉庫適應于這種變化，通過統(tǒng)一接口統(tǒng)一方式訪問數(shù)據(jù)源，完成跨各種數(shù)據(jù)源的訪問，同時也會建造一個有多租戶管理、資源管控的環(huán)境，能夠被很多部門、用戶進行使用。這從理論上來講是區(qū)別于傳統(tǒng)數(shù)據(jù)倉庫的應用場景。

第三個挑戰(zhàn)是數(shù)據(jù)處理的延時太長。過去整個數(shù)據(jù)架構前面是OLTP系統(tǒng)，中間是ODS，后面是數(shù)據(jù)倉庫層，再往后是數(shù)據(jù)集市。那么在數(shù)據(jù)倉庫這一層，數(shù)據(jù)是T+1的，意味著第二天才訪問前一天的數(shù)據(jù)。但是很多行業(yè)需要更實時的數(shù)據(jù)，為了了解當前的生產(chǎn)運營狀況,它們需要基于T+0、準實時的，甚至是實時的幾分鐘幾秒鐘之內(nèi)的數(shù)據(jù)。這種需求就演變成第三種數(shù)據(jù)倉庫運營模式——Operational Data Warehouse。這種業(yè)務模式的設計初衷是希望把數(shù)據(jù)實時或準實時的導入到數(shù)據(jù)倉庫當中，能夠?qū)崟r數(shù)據(jù)進行快速的分析和挖掘。傳統(tǒng)的數(shù)據(jù)倉庫是每天晚上數(shù)據(jù)導入，花7-8個小時進行批處理計算，第二天才能看到報表。所以傳統(tǒng)技術面臨一個普遍的問題：不能實現(xiàn)實時處理。

第四個挑戰(zhàn)是原先的邏輯數(shù)據(jù)模型不能有效支撐數(shù)據(jù)快速分析和價值發(fā)現(xiàn)。過去大家做統(tǒng)計是對數(shù)據(jù)做一些常見的聚合以及連接關聯(lián)操作。遵循關系數(shù)據(jù)庫的模式，有很多模型和各種范式，像很多廠商在相關行業(yè)設計了十大主題模型、八大主題模型，中間數(shù)據(jù)的關聯(lián)程度是非常高的。一個有幾千個數(shù)據(jù)源表的業(yè)務系統(tǒng)，中間層需要用上萬張數(shù)據(jù)表來滿足它的模型。這樣一個復雜的模型所帶來的弊端就是數(shù)據(jù)結構一旦發(fā)生變化或者增加時，模型就不堪重負。預先設定的模型沒法適應業(yè)務的快速變化，所以我們經(jīng)常能看到銀行花幾年時間建立一個數(shù)據(jù)倉庫，反復投入，每年在改造它。近期了解到一家銀行科技部門，前后10年投入十幾億來建數(shù)據(jù)倉庫。而今天一方面大量數(shù)據(jù)在產(chǎn)生，同時新的數(shù)據(jù)也在增加，有些來自內(nèi)部的數(shù)據(jù)，有些來自新的外部數(shù)據(jù)。數(shù)據(jù)處理方法的確到了應該變革的時候。通過利用新的機器學習的統(tǒng)計方法，不僅做傳統(tǒng)SQL的統(tǒng)計，還希望能夠從數(shù)據(jù)關聯(lián)上面發(fā)現(xiàn)規(guī)律、關聯(lián)模式、時序上的特征。通過對它進行一些預測分析，能夠發(fā)現(xiàn)統(tǒng)計學意義上的因果關系。這就變得對企業(yè)更加重要。這一塊是第四種數(shù)據(jù)倉庫新的設計模式，叫context independent data warehouse，也就是說拋棄這些邏輯關聯(lián)模型，在不知道這些模型的情況下，也能通過機器學習的方法找到數(shù)據(jù)之間的關聯(lián)關系，能夠找到他們之間統(tǒng)計學的因果關系。

四、全新的數(shù)據(jù)倉庫設計模式

這四個應用模式，這四個困境引出了新的數(shù)據(jù)倉庫的設計模式。意味著這四種應用模式需要全新的技術支撐，這也是我們看到新的技術，特別是Hadoop產(chǎn)生以后，衍生出來新的技術演進逐步在滿足這些需求。

現(xiàn)在講***個，傳統(tǒng)數(shù)據(jù)倉庫為了應對數(shù)據(jù)量的增加，需要采用新的方式。我們看到計算模式在過去的十幾年里發(fā)生了非常明顯的變化，從單機開始，首先是***步計算并行化。計算并行化就是我們稱為并行數(shù)據(jù)庫——數(shù)據(jù)庫引擎并行化，但是對存儲無法有效擴展，所以就演變出了第二代計算和存儲的分布式化，產(chǎn)生了第二代分布式技術，大規(guī)模并行數(shù)據(jù)庫就是MPP數(shù)據(jù)庫，這個數(shù)據(jù)庫解決了一部分問題——幾個TB級別的數(shù)據(jù)的高速處理問題。但是在數(shù)量增加的時候，又遇到一個瓶頸，它需要一個新一代的技術。新一代的計算模式發(fā)生了變化，這個是Google在2003、2004年中發(fā)布的兩篇論文中，解釋了 MapReduce的計算模式。大家發(fā)現(xiàn)，經(jīng)過這么多年發(fā)展，MapReduce計算模式仍然是***的分布式計算模式，它把計算和存儲有效地結合了起來，它仍然是現(xiàn)在***有擴展性、***容錯性，現(xiàn)在隨著我們星環(huán)新的技術實現(xiàn)，它甚至是性能***的計算模式。這樣一個演變使得新的數(shù)據(jù)倉庫技術能夠處理從幾個 TB到幾十個PB的數(shù)據(jù)量，能夠線性擴展，而且在每個數(shù)量級上都可以比傳統(tǒng)的數(shù)據(jù)處理技術快若干倍甚至一個數(shù)量級(10倍)。這里有一組數(shù)據(jù)，是我們在春節(jié)前測試的數(shù)據(jù)結果，今天的演講也是為了介紹我們在TPC-DS標準測試集上的***進展。去年的時候我們已經(jīng)做到了基于TPC-DS benchmark從1TB到100TB都能有效地處理，而且處理的性能是，我們用29臺機器，能夠在40個小時內(nèi)完成100TB總共99個報表處理。我們測試使用的是普通的兩路的服務器，CPU還是比較弱的，今天能夠在TPC-DS benchmark上跑過100TB的數(shù)據(jù)倉庫，應該是***的。大家可以發(fā)現(xiàn)新的技術，在處理100TB上是沒有壓力的。

***個問題我們可以通過分布式計算來解決，第二個是通過數(shù)據(jù)聯(lián)邦技術處理多數(shù)據(jù)源以及解決多租戶的問題，這個是 Gartner分析師在幾年之前提出來的，叫邏輯數(shù)據(jù)倉庫。邏輯data warehouse能夠比較有效地解決這個問題。分析師認為，邏輯數(shù)倉應該有三個部分。***個部分是中心的Repository，所有數(shù)據(jù)全部集中放在這個上面。第二個是需要有一個數(shù)據(jù)庫虛擬化，或者叫數(shù)據(jù)庫聯(lián)邦技術，能夠把多種數(shù)據(jù)源融合起來，從應用角度來看使用更加方便。第三個是在邏輯數(shù)倉之上，最核心的就是分布式計算。同時其中有兩個特性是需要滿足的，一個就是能不能按需對數(shù)據(jù)倉庫進行擴張、能不能實現(xiàn)多個用戶共享一個平臺。這個是邏輯數(shù)據(jù)倉庫必須要解決的問題。第二個是對于元數(shù)據(jù)的管理、對數(shù)據(jù)質(zhì)量管理的有效方法、對數(shù)據(jù)訪問要有審計，這也是邏輯數(shù)據(jù)庫核心設計的原則。當然我們這里介紹的兩個技術，是星環(huán)用來支撐邏輯數(shù)據(jù)庫建設的。

我們在SQL層也支持傳統(tǒng)數(shù)據(jù)庫的數(shù)據(jù)聯(lián)邦的概念，可以支持DBlink的語法。我們把這個計算分散開，劃到多個數(shù)據(jù)源上面。這里有兩種實現(xiàn)方式，一種是傳統(tǒng)關系型數(shù)據(jù)庫的方式，把Hadoop作為另外備用的計算引擎。另外一種，星環(huán)是建造SQL翻譯層，把源數(shù)據(jù)放到Hadoop上的執(zhí)行計劃里，但是如果數(shù)據(jù)在關系型數(shù)據(jù)庫上，我們會把SQL給到關系型數(shù)據(jù)庫執(zhí)行，執(zhí)行的時候?qū)嶋H上計算仍然是分布式的，仍然在Hadoop上進行運算，只不過數(shù)據(jù)源在關系型數(shù)據(jù)庫里。這里面有兩個優(yōu)化技術，一個優(yōu)化是把數(shù)據(jù)抽取到多個節(jié)點上進行分布式計算，同時把SQL中的一些過濾條件下推(pushdown)到關系型數(shù)據(jù)庫。這種方式的變化就是關系型數(shù)據(jù)庫以及傳統(tǒng)上現(xiàn)在處于***象限的廠商實際上希望是以他們的數(shù)據(jù)庫為主，而我們是希望以Hadoop為主，來構造這樣一個數(shù)據(jù)聯(lián)邦的實現(xiàn)方案。今天看來，這種技術是***的，因為我們的計算是全部分布式化的，所以我們的性能比他們更有優(yōu)勢。第二個，為了構造邏輯數(shù)倉引入了微服務的概念，那微服務的實現(xiàn)是用容器來實現(xiàn)的。我們有個產(chǎn)品，也有相應的演講是介紹新的產(chǎn)品TOS(Transwarp Operating System)，這個產(chǎn)品是基于Docker和kubernetes來構造彈性的基于容器化的計算環(huán)境。在這之上我們把傳統(tǒng)的數(shù)據(jù)倉庫的應用，即剛才我們講的上千個應用，全部容器化，放在我們的應用商店當中。應用商店里面的每一項應用都是標準的服務，這些服務在實例化的時候可能會由幾百個上千個容器組成。那么我們會把這個應用打包成一個服務，作為整體進行調(diào)度。通過這種方式，我們可以有效地實現(xiàn)把數(shù)據(jù)庫本身的服務當成平臺服務，能夠一件一件部署，能夠進行靈活地擴張，同時我們也可以把上層應用像蘋果的apple store安裝應用一樣，在我們的應用商店中快速地部署。同時，不同應用之間可以通過容器技術進行有效的隔離。

第三種就是實現(xiàn)實時數(shù)據(jù)倉庫。我們需要有一種新的方法把數(shù)據(jù)實時導入到數(shù)倉當中，一種方法是把傳統(tǒng)的OLTP數(shù)據(jù)庫通過ETL抽入到一個operational database當中。過去，這就是 關系型數(shù)據(jù)庫，現(xiàn)在，很多人是用HBase或Cassandra來實現(xiàn)。但是有一個普遍的問題就是數(shù)據(jù)進入這個operational database以后，大家需要對數(shù)據(jù)進行復雜的分析，因為數(shù)據(jù)倉庫是用來做分析的。數(shù)據(jù)分析的復雜程度可能是在上面跑幾十萬行SQL統(tǒng)計。同時，它的一個復雜分析可能就有上萬行，需要快速地完成。這樣的一個要求實際上是很難滿足的，因為它的特點是要對數(shù)據(jù)進行實時的寫入，同時也要對它進行復雜的分析，目前沒有一項數(shù)據(jù)庫技術能夠同時滿足這兩個需求。當然有的廠商號稱既能支持OLTP又能支持OLAP。有一個新的類別叫Hybrid Transactional &AnalyticalDatabase，這種數(shù)據(jù)庫也有相關分析報告，但目前好像沒有技術能比較成熟地來解決這個問題。那我們在實現(xiàn)該設計模式的時候，底層采用的技術其實就是基于Hadoop，我們是在HDFS上構造自己的分布數(shù)據(jù)庫，存儲格式改進了ORC的存儲格式，可以支持增刪查改，也可以支持分布式事務處理。我們前面開發(fā)了一個ETL的工具，可以把數(shù)據(jù)庫的日志進行重放，直接插入到ORC事務表里面去。這是一個準實時的操作，通常是幾分鐘內(nèi)能完成從交易型數(shù)據(jù)庫實時同步到Hadoop當中，然后在這個上面的做復雜關系，這個分析是非常高效的。這是一種實現(xiàn)方式，但是他的延時還不夠快，因為它是分鐘級別的，比如是業(yè)務數(shù)據(jù)庫，如DB2借助IBM Datastage把操作日志放出來之后，再解讀這個日志，寫到倉庫中去。但是還有一些客戶希望是更實時的，他希望在幾秒鐘之內(nèi)能夠完成計算，這個時候我們采用第二種方法是把數(shù)據(jù)與復雜計算前推到流處理框架中去。前置的交易系統(tǒng)通常是采用這種方式，今天有很多金融機構的應用，特別是網(wǎng)銀，像互聯(lián)網(wǎng)金融，全部的交易訂單都在消息隊列中，如RabbitMQ、Kafka，這個時候我們天生的優(yōu)勢，就是可以直接從交易隊列中把數(shù)據(jù)取出來，在流上進行運算。流上的計算實際上也是在數(shù)據(jù)倉庫中的一個復雜的運算，也有大量存儲過程和SQL，這方面星環(huán)做了大量的工作，我們能夠在流上進行復雜的SQL運算，支持標準 SQL2003和存儲過程，包括DB2和Oracle存儲過程，也就意味著你可以把原來在后端的復雜的SQL運算前置到流上面來做，例如時間窗口中的數(shù)據(jù)構成一張表，這張表跟普通表不一樣的地方是，它是一直處于變化流動當中。這種方式適合對計算延時要求很高的，我們有一個客戶要在一秒鐘之內(nèi)對市場行情進行運算，他有160個復雜模型，有些復雜模型其實是用存儲過程來寫得偏微分方程的構成。這就意味著我們需要在流上面做復雜計算，然后延時要在幾秒鐘內(nèi)完成，新型的高頻交易的場合就非常需要這種模式。

第四種數(shù)據(jù)倉庫設計模式指的是，叫context independent Data warehouse，一種上下文無關的數(shù)據(jù)倉庫設計架構。這個架構通常需要完成幾項重要的工作。首先就是說，這個數(shù)據(jù)倉庫應該能夠支持關聯(lián)分析，對于數(shù)據(jù)和表，能夠通過相關性找到它們之間的關聯(lián)關系，同時也能發(fā)現(xiàn)一些統(tǒng)計學上的因果關系。這一塊我們是借助R語言來實現(xiàn)的。只不過我們把R語言的很多算法分布式化了，但是對用戶來講，體驗是跟R語言一模一樣的。如果用戶有熟悉R語言的專家，可以很快上手，能夠用R語言來做復雜的關聯(lián)分析和機器學習。其實這一塊，也就意味著是不需要復雜模型模式，對數(shù)據(jù)特征抽取以后就可以進行機器學習，也不需要太多的專家來幫你設計規(guī)則，它是通過機器學習方法自動幫你補充的。這是***大功能，第二是網(wǎng)絡分析、圖分析的能力?，F(xiàn)在特別是社交網(wǎng)絡分析、通訊網(wǎng)絡分析，又比如銀行資金轉(zhuǎn)賬鏈、擔保關系、企業(yè)投資關系，都要用圖的技術來實現(xiàn)。圖技術就廣泛地運用到金融機構的反欺詐當中。在這樣一個數(shù)據(jù)倉庫中，圖的分析能力也是一個重要的關鍵能力。第三塊是需要文本的分析挖掘能力，也需要文本制作能力。第四個就是我們希望能摒棄過去設計復雜的邏輯模型，有幾萬張中間表，這種模型代價非常高，而且固定下來就很難變化。我們希望能自由地進行探索，我們希望能有一個自主的工具對它進行數(shù)據(jù)挖掘分析，這一塊也需要工具上的支撐。所以我們今天在實現(xiàn)這種數(shù)據(jù)倉庫架構的時候，綜合使用了我們的絕大部分組件，我們使用了Inceptor分析型數(shù)據(jù)庫，對數(shù)據(jù)特征進行清洗，甚至SQL能直接用圖的算法進行分析。同時，我們在Hyperbase上還能支持文檔搜索、文本搜索，也支持大規(guī)模圖的并發(fā)查詢，我們對外提供 DataFrame的抽象，就是R語言的DataFrame的抽象，和R語言的原始DataFrame是一樣的，可以用R的算法去訪問這些 DataFrame，同時我們也提供幾十種分布式機器學習算法，讓用戶來做大規(guī)模的機器學習。中間演變出幾種應用模式，有風險分析、有精準營銷的，也有反欺詐、文本分析。當然我們也綜合了傳統(tǒng)的R的單機算法包，也提供傳統(tǒng)的R的體驗。

這些技術組件構建出一個完整的數(shù)據(jù)倉庫。如果把這些數(shù)據(jù)倉庫全部放在一張紙上的話，那我們就能看到整個架構的底層其實是用TOS實現(xiàn)資源管理多租戶的能力，用容器來隔離，中間層是一個邏輯數(shù)據(jù)倉庫，把結構化以及非結構化數(shù)據(jù)全部放到這個邏輯層當中，同時上層是借助TOS創(chuàng)建邏輯集群來構建如自由探索的應用，也可以用來構建傳統(tǒng)數(shù)據(jù)倉庫、構造數(shù)據(jù)集市、構造實時數(shù)據(jù)倉庫。整體來說就是可以用全新的技術來打造一個新的企業(yè)數(shù)據(jù)平臺，這也是為什么我們被 Gartner選為數(shù)據(jù)倉庫中在遠見象限中是最右邊的廠商，是因為我們的技術在支持這四類新的數(shù)據(jù)倉庫中是最領先的而且是最完備的廠商。