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

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

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

Small Data Analytics

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

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

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

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

The rise of Hadoop

1.history of Hadoop

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

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

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

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

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

2.Early Open Source Stacks

早期的應用都是直接現將數據存儲到數據庫中，應用/用戶直接/間接從數據庫中獲取所需數據。

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

3.Rise of Open Source Data Infrastructure

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

1)、快速查詢;

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

3)、流處理;

4)、內存計算

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

Data Infrastructure Space Today

1.Modern Open Source Stacks

當下的數據處理模型如下圖所示：

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

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

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

2.Data Delivery

第一類技術是數據傳輸系統，數據傳輸系統他們主要負責把事件從一個位置進一步運輸到另外一個位置，所以我們可能會產生一些數據的，比如說把數據進一步傳到整個數據系統。數據傳輸系統他們主要專注于短期儲存，這些系統通常會和數據流來打交道。這些系統可以分為不同的類別，每個系統都有不同的框架和不同的關鍵點傳輸數據。

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

MQ是提取數據的系統，不完全一樣，這兩個架構有些不同，不同的架構，不同的結構可以產生不同范圍，不同規模的表現性能，以提升不同的操作性能。

現在Kafka逐步變成了這個領域的標準。

　　3.Storage

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

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

4.Processing

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

5.Stream Processing

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

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

　　6.Batch Processing

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

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

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

　　7.Querying

最后一個環節要說的是查詢環節，查詢環節目前是最大的一個環節，而且是最先進的一種數據查詢。這種查詢技術的目的就是為了快速，我們如何來利用查詢技術呢?我們要輸入一個查詢的命令，然后把這個命令進行處理，把輸出的數據放到查詢環節當中以便用戶隨時查詢，這就需要我們對數據進行預處理，然后把預處理數據放到存儲器當中，然后再送到查詢處理器當中以便查詢。

8.SQL-on-Hadoop

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

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

9.Key/Value Stores

另一種加速查詢速度的方法就是要把資料庫進行優化，這樣就能夠打造一種非常快速的查詢的架構。它可以支持非常快速的查找，也可以進行快速的寫入，我們有很多時間序列的數據庫都有鍵值存儲。

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

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

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

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

10.Column stores

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

　　11.Druid

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

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

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

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

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

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

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

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

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

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

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

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

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