首先，介紹兩個使用案例。

第一個是OLTP流程，主要指的是整個商業(yè)應用和流程。我們會收集交易數(shù)據(jù)，在業(yè)務過程當中收集數(shù)據(jù)，比如要銷售一些網(wǎng)上產(chǎn)品，可能希望把每一單都能夠記錄下來。

第二個主要案例是OLAP，主要指的是分析數(shù)據(jù)，我們讓所有收集的數(shù)據(jù)能夠有意義，可以幫助我們生成報告，根據(jù)數(shù)據(jù)分析，進行業(yè)務決策。這個應用場景下，我們會把一些數(shù)字，比如說收益，將整個數(shù)據(jù)維度Dimensions以及Measures和數(shù)據(jù)整合在一起。

Small Data Analytics

在一個小數(shù)據(jù)里可以做以上兩個應用，單個系統(tǒng)都可以應用，非常簡單。我們主要做什么呢?我們會像微軟表格當中收集數(shù)據(jù)，之后進行一系列視覺化。

我們提供的解決方案對于小的數(shù)據(jù)而言主要使用單個系統(tǒng)，這個單個系統(tǒng)主要通過一個系統(tǒng)解決所有的問題和所有的應用場景，而且能夠快速提取出關鍵數(shù)據(jù)，并且很容易的去創(chuàng)建各種不同的數(shù)據(jù)展現(xiàn)形式。

在過去幾年里，數(shù)據(jù)一直在快速發(fā)展，人們意識到有些解決方案針對小數(shù)據(jù)已經(jīng)無效了。數(shù)據(jù)已經(jīng)不能夠通過一臺機器或設備來解決，所以我們需要通過多臺設備共同來解決大數(shù)據(jù)的問題。

當數(shù)據(jù)快速發(fā)展的時候，當時我們確實也存在很多數(shù)據(jù)解決方案，這些解決方案主要是由IBM等等公司提供。這些解決方案看起來非常并行，是企業(yè)數(shù)據(jù)的解決方案。但是對于這些解決方案存在的問題就是針對專屬的數(shù)據(jù)，要付出高昂的代價解決這些問題。在大數(shù)據(jù)世界里，很多中小公司也會產(chǎn)生大量的數(shù)據(jù)，他們無法支付得起高昂的企業(yè)解決方案。

The rise of Hadoop

1.history of Hadoop

2003年，谷歌發(fā)布了一篇Google GFS論文，論文介紹了如何將GFS系統(tǒng)用于大型的、分布式的、對大量數(shù)據(jù)進行訪問的應用。2004年，谷歌公布了另外一篇關于MapReduce的介紹一種用于大規(guī)模數(shù)據(jù)集(大于1TB)的并行運算編程模型，即MapReduce編程模型。

2005年初，雅虎啟動了Nutch項目，同時，Nutch項目的開發(fā)者在Nutch上有了一個可工作的MapReduce應用，到當年年中，所有主要的Nutch算法被移植到使用MapReduce和HDFS來運行。

在2006年2月，他們從Nutch轉移出來成為一個獨立的Lucene子項目，稱為Hadoop。大約在同一時間，Doug Cutting加入雅虎。Yahoo提供一個專門的團隊和資源將Hadoop發(fā)展成一個可在網(wǎng)絡上運行的系統(tǒng)。

2008年1月，Hadoop已成為Apache頂級項目，證明它是成功的，是一個多樣化、活躍的社區(qū)。通過這次機會，Hadoop成功地被雅虎之外的很多公司應用。

今天有很多不同的技術存在于整個大數(shù)據(jù)的技術空間里，大多數(shù)的技術像Hadoop一樣都是開源的技術。很多人當他們最開始關注大數(shù)據(jù)空間的時候，他們覺得太復雜了，他們很難理清每個系統(tǒng)到底做什么的，或者他們應該什么樣的系統(tǒng)解決現(xiàn)實存在的問題。

2.Early Open Source Stacks

早期的應用都是直接現(xiàn)將數(shù)據(jù)存儲到數(shù)據(jù)庫中，應用/用戶直接/間接從數(shù)據(jù)庫中獲取所需數(shù)據(jù)。

隨著數(shù)據(jù)量的增大，人們開始關注Hadoop進一步替代他們使用的傳統(tǒng)方法。Hadoop有兩個重要的組成部分，一個是存儲引擎，這都是以谷歌HDFS作為依據(jù)，一個是數(shù)據(jù)處理模型MapReduce。Hadoop是一套很靈活的解決方案，它也是最常用的一種數(shù)據(jù)處理方式。但是它在某些方面表現(xiàn)的比較乏力。

3.Rise of Open Source Data Infrastructure

當一項技術變得被廣泛采納的時候，那么他的局限性也變得眾所周知了，Hadoop也不例外,下文羅列了Hadoop的部分缺點

1)、快速查詢;

2)、(流式)事件的傳遞;

3)、流處理;

4)、內(nèi)存計算

為了解決Hadoop的缺點，許多新的技術被創(chuàng)建出來。

Data Infrastructure Space Today

1.Modern Open Source Stacks

當下的數(shù)據(jù)處理模型如下圖所示：

當我思考當今的大數(shù)據(jù)現(xiàn)狀的時候，大多數(shù)技術都會歸為四類，第一個是整個傳輸數(shù)據(jù)，第二加工數(shù)據(jù)，第三存儲數(shù)據(jù)，以及數(shù)據(jù)的問詢或分析?，F(xiàn)在關于技術有很多不同的領域，因為談到大數(shù)據(jù)的時候，人們已經(jīng)意識到即使簡單的問題也需要很多復雜的解決方案，和一種專署的技術，或者大規(guī)模的技術才能夠解決。比如說從一個位置向另外一個位置進一步傳輸數(shù)據(jù)的數(shù)據(jù)是比較簡單的，但對大量數(shù)據(jù)就是非常復雜的問題了，這些都需要非常先進的技術才能夠解決。

所以這四類技術所有的開源的大數(shù)據(jù)技術都可以歸為四類當中的一類技術，很多人都已經(jīng)開始意識到不同的技術其實可以結合到一起，把它用為一種端對端的技術來對所有的數(shù)據(jù)進行分析，我會給大家介紹一下四種不同的技術。不同的技術在整個大數(shù)據(jù)空間如何歸為四類當中的其中一類。

這里有很多的不同技術，有很多技術都是彼此競爭關系，我沒有時間給大家做逐一贅述，也不能夠進一步詳細介紹每個技術是什么。但是我希望給大家提供簡介，幫助大家了解這些技術是做什么的，以及整個構架是什么樣的。

2.Data Delivery

第一類技術是數(shù)據(jù)傳輸系統(tǒng)，數(shù)據(jù)傳輸系統(tǒng)他們主要負責把事件從一個位置進一步運輸?shù)搅硗庖粋€位置，所以我們可能會產(chǎn)生一些數(shù)據(jù)的，比如說把數(shù)據(jù)進一步傳到整個數(shù)據(jù)系統(tǒng)。數(shù)據(jù)傳輸系統(tǒng)他們主要專注于短期儲存，這些系統(tǒng)通常會和數(shù)據(jù)流來打交道。這些系統(tǒng)可以分為不同的類別，每個系統(tǒng)都有不同的框架和不同的關鍵點傳輸數(shù)據(jù)。

但是我給大家介紹一下上層的架構，就像kafka，它提供了資源的上分區(qū)，把生產(chǎn)數(shù)據(jù)和消費數(shù)據(jù)直接分開，現(xiàn)在這個架構是根據(jù)分布式邏輯來進行的，你可以把這些數(shù)據(jù)按照分布的邏輯進行分布，之后從分布式邏輯上來收集數(shù)據(jù)，這是一個非常好的描述數(shù)據(jù)的一個方式。

MQ是提取數(shù)據(jù)的系統(tǒng)，不完全一樣，這兩個架構有些不同，不同的架構，不同的結構可以產(chǎn)生不同范圍，不同規(guī)模的表現(xiàn)性能，以提升不同的操作性能。

現(xiàn)在Kafka逐步變成了這個領域的標準。

　　3.Storage

數(shù)據(jù)提供系統(tǒng)是怎么工作的呢?它通常把數(shù)據(jù)提供到其它地方進行進一步的處理，首先可以把數(shù)據(jù)提供到存儲的機制當中，存儲機制只是數(shù)據(jù)庫，會存儲數(shù)據(jù)，也可以從這里調(diào)用數(shù)據(jù)。然而現(xiàn)在更普遍的情況是一種專門的儲存數(shù)據(jù)庫，可以看到很多的專門的存儲數(shù)據(jù)的系統(tǒng)。

現(xiàn)在最普遍的存儲方式是分布式數(shù)據(jù)存儲系統(tǒng)，也就是說把這些數(shù)據(jù)無限制地放到HDFS系統(tǒng)當中，隨時進行提取數(shù)據(jù)。文件系統(tǒng)和數(shù)據(jù)提交系統(tǒng)有一些重疊的地方，如果你在Kafka里長時間存儲數(shù)據(jù)的話，你會考慮它是一種存儲的方式。但是有些時候這種數(shù)據(jù)推送，數(shù)據(jù)提供需要同樣的技術。

4.Processing

數(shù)據(jù)處理的技術是做什么的呢?也就是說它把數(shù)據(jù)進行變化，讓它更簡潔，或者把數(shù)據(jù)進行變形，以便于更容易的處理。在查詢和數(shù)據(jù)處理方面也有一些重合。我們應該這么理解，處理過程是把數(shù)據(jù)進行變形，輸出的數(shù)據(jù)和輸入的數(shù)據(jù)量是一樣大的，查詢系統(tǒng)的輸出數(shù)據(jù)比輸入數(shù)據(jù)比較小一些，這在很多的系統(tǒng)里都是這樣的。在大數(shù)據(jù)系統(tǒng)方面你可以看到這些系統(tǒng)不斷來增強處理的性能。另外一些系統(tǒng)重點放到查詢方面技術的提高。

5.Stream Processing

有兩種子類型，關于處理的，第一個流處理，流處理也就是把數(shù)據(jù)放到一個流的程序當中進行連續(xù)處理。首先數(shù)據(jù)提供到Kafka里，需要先進行流處理，之后才進入存儲器進行存儲。還有一種就是直接放到查詢系統(tǒng)當中，這是兩種不同流處理的流程。

有很多不同的流處理的處理器，有很多的開源的流處理的程序，下面這三種是非常流行的處理方式。

　　6.Batch Processing

現(xiàn)在我要給大家介紹批處理。批處理方式在流處理方面當中不是一種真正的流處理的方式，它只是以批的方式來收集數(shù)據(jù)，然后把它放到一種特定的構架下面，然后來進行批處理。這是兩種不同的架構，兩種表現(xiàn)也是不同，它們擔心的問題也不一樣。通過流處理可以得到非常快速處理的結果。

現(xiàn)在有兩個非常流行的技術，他們分別是Hadoop和Spark對大型靜態(tài)數(shù)據(jù)集的處理，Hadoop是批處理非常流行的一種技術，但是它有很多的局限。在過去幾年當中Spark更加受到大家的歡迎。

Spark的工作方式就是考慮你的處理過程，將它想象成一個過程或者一個舞臺，Spark做的就是非常有效地利用內(nèi)存，每一個計算過程都會輸出一個結果，Spark會把這些結果做一個統(tǒng)計，這種工作的方法是迭代式的，而且是非常高效的迭代式。Spark會把所有的數(shù)據(jù)都進行統(tǒng)一的整理，而且Spark比Hadoop的API更加有優(yōu)勢，所以在過去幾年當中，Spark幾乎慢慢地變成了批處理的標配。

　　7.Querying

最后一個環(huán)節(jié)要說的是查詢環(huán)節(jié)，查詢環(huán)節(jié)目前是最大的一個環(huán)節(jié)，而且是最先進的一種數(shù)據(jù)查詢。這種查詢技術的目的就是為了快速，我們?nèi)绾蝸砝貌樵兗夹g呢?我們要輸入一個查詢的命令，然后把這個命令進行處理，把輸出的數(shù)據(jù)放到查詢環(huán)節(jié)當中以便用戶隨時查詢，這就需要我們對數(shù)據(jù)進行預處理，然后把預處理數(shù)據(jù)放到存儲器當中，然后再送到查詢處理器當中以便查詢。

8.SQL-on-Hadoop

數(shù)據(jù)的操作語言是SQL，因此很多工具的開發(fā)目標自然就是能夠在Hadoop上使用SQL。這些工具有些只是在MapReduce之上做了簡單的包裝。SQL-on-Hadoop工作的原理就是從某些地方提取數(shù)據(jù)，提取數(shù)據(jù)可能是分布式處理，把數(shù)據(jù)放到自己引擎當中，這樣就可以控制數(shù)據(jù)，改變數(shù)據(jù)，并且創(chuàng)造數(shù)據(jù)。所以SQL是非常靈活的一種過程，這是它的主要的特點。

很多SQL on Hadoop都支持SQL查詢的功能，SQL可以幫助你非常便捷得到想得到的數(shù)據(jù)。但是缺點是處理速度非常慢，因為中間涉及到一些過程要從HDFS提取數(shù)據(jù)，處理數(shù)據(jù)，然后再放到存儲器當中。這樣就會非常慢，如果需要快速反應的話，這種小的延遲期的操作還需要進一步的提升。所以我們就需要進一步提高優(yōu)化存儲。

9.Key/Value Stores

另一種加速查詢速度的方法就是要把資料庫進行優(yōu)化，這樣就能夠打造一種非?？焖俚牟樵兊募軜嫛Ｋ梢灾С址浅？焖俚牟檎?，也可以進行快速的寫入，我們有很多時間序列的數(shù)據(jù)庫都有鍵值存儲。

鍵值存儲有兩種方式，第一個方式就是預計算，預計算方面要把每個查詢命令都進行預測，然后把這些查詢命令進行預處理，把數(shù)據(jù)進行預存儲。左邊是非常分散的數(shù)據(jù)，右邊根據(jù)鍵入的信息進行分類，這樣的話在某種程度上是非常有效的。在你預計算之后查詢將變得非常之快，因為它會快速來查詢一些映射。

但問題是一些數(shù)據(jù)庫的預計算可能會耗時很長，有些時候預計算會花幾個小時才能得到數(shù)據(jù)，所以提前進行預計算是非常省時的方式。常用的鍵值存儲引擎如下：

　　以下是在鍵值存儲進行預計算時得到的數(shù)據(jù)：

從上述的結果我們可以看出，即使是使用了鍵值存儲，在對數(shù)據(jù)進行查詢時依舊很慢。

10.Column stores

另外一個方式就是，也是非常流行的技術，就是范圍掃描。關于范圍掃描的理念就是主間直是井號，對維度和特性進行分類，這種問題方式關于性能方面的問題。首先需要預計算的時間，這個掃描也是很花時間的。所以現(xiàn)在有些人仍然用鍵值存儲方式加速查詢速度，但是今年來突然出現(xiàn)了一種列存儲的技術，馬上就變得十分流行。你可以存儲并且掃描你的數(shù)據(jù)，然后把這些數(shù)據(jù)進行列存儲，根據(jù)查詢的關鍵字，電腦可以快速查詢各個列，這樣的話你就可以在不同的列當中創(chuàng)造不同的關鍵字，以及指標。這是性能查詢方面非常大的進步。

　　11.Druid

下面我給大家介紹一下Druid，它是一種列存儲的方式，一種交互式操作系統(tǒng)，它會以列的形式來存儲數(shù)據(jù)，它十分擅長于對數(shù)據(jù)進行并發(fā)的讀取，而且也可以實現(xiàn)低延時的查詢，在事件創(chuàng)建的毫秒內(nèi)就可以被查詢到。

12.面對如此多的選擇，我們究竟選擇哪一個呢?

現(xiàn)在大數(shù)據(jù)非常復雜，我們在評價不同技術的時候應該首先考慮的是這個技術是不是真正解決了我們的問題，其次技術是否得到了積極快速的發(fā)展，是不是有新技術的加入提升了新的功能。在不同的技術之間可能差別不是很大，我們可以隨便選某一種技術來為我所用。但在未來我們可能是會有更加集中化，一體化的技術出現(xiàn)。

現(xiàn)在我要給大家介紹一下未來的發(fā)展趨勢，在未來幾年當中將會出現(xiàn)的一些技術。

我覺得開源大數(shù)據(jù)項目幾乎已經(jīng)達到了飽和點，可能是大數(shù)據(jù)當中一旦出現(xiàn)一個問題，大概就會同時出現(xiàn)五個解決這個問題的項目，索引很多問題都可以被快速的解決。

在最近幾年中很多人都特別地注重流計算，流計算已經(jīng)變得越來越流行了，在過去幾年當中我們也看到很多人注意到內(nèi)存計算，因為內(nèi)存變得越來越便宜，在很多的系統(tǒng)當中內(nèi)存計算可能會成為大數(shù)據(jù)處理方面的一個標配。

現(xiàn)在這些大數(shù)據(jù)的技術還是比較新的技術，還需要一些時間才會出現(xiàn)共同的標準。但是我覺得在不久的將來，我們很快就會出現(xiàn)大數(shù)據(jù)方面通用的標準。

我不相信有單一的一種技術會解決所有的問題，我覺得有很多不同的數(shù)據(jù)就需要有很復雜的大數(shù)據(jù)庫來處理。但是我覺得未來的開源大數(shù)據(jù)的堆棧包括以下幾個部分，其中必須要有一個處理單元，要有一個儲存單元，當然肯定要有查詢單元，沒有查詢單元就沒有快速的目標的實現(xiàn)了。

在數(shù)據(jù)提交方面，Kafka已經(jīng)達到了這個標準，對于流處理方面Spark已經(jīng)成為了標準的工具，我覺得Druid查詢方面也做得很好。

所以基礎設施的架構也會不斷成熟，不斷地改善。在我們的架構不斷變得穩(wěn)定之后，會出現(xiàn)很多的應用，我們現(xiàn)在已經(jīng)看到一些可視化的工具，以及虛擬現(xiàn)實的工具已經(jīng)應用到了開源數(shù)據(jù)。

在未來幾年當中還會有更多的開源數(shù)據(jù)。在虛擬現(xiàn)實之外，架構和設施穩(wěn)定了，可以做很多很酷的事情，比如可以更多研究AR，更多研究深度學習，人工智能，這都是建立基礎網(wǎng)絡，基礎系統(tǒng)上的未來發(fā)展，這也是非常流行的趨勢。我覺得現(xiàn)在IT社區(qū)會變得越來越龐大。

人物名片：Fangjin Yang 是 Druid 項目聯(lián)合發(fā)起人、核心開發(fā)者，Imply 聯(lián)合創(chuàng)始人。Imply 是位于美國舊金山的一家技術創(chuàng)業(yè)公司。Fangjin 之前曾在 Metamarkets 和 Cisco 等公司任高級工程師。加拿大滑鐵盧大學電氣工程專業(yè)本科，計算機工程專業(yè)碩士。

整理：劉繼偉，本文整理自QCon北京Fangjin Yang的英文主題演講。