首先，介紹兩個(gè)使用案例。

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

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

Small Data Analytics

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

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

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

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

The rise of Hadoop

1.history of Hadoop

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

2005年初，雅虎啟動(dòng)了Nutch項(xiàng)目，同時(shí)，Nutch項(xiàng)目的開發(fā)者在Nutch上有了一個(gè)可工作的MapReduce應(yīng)用，到當(dāng)年年中，所有主要的Nutch算法被移植到使用MapReduce和HDFS來運(yùn)行。

在2006年2月，他們從Nutch轉(zhuǎn)移出來成為一個(gè)獨(dú)立的Lucene子項(xiàng)目，稱為Hadoop。大約在同一時(shí)間，Doug Cutting加入雅虎。Yahoo提供一個(gè)專門的團(tuán)隊(duì)和資源將Hadoop發(fā)展成一個(gè)可在網(wǎng)絡(luò)上運(yùn)行的系統(tǒng)。

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

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

2.Early Open Source Stacks

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

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

3.Rise of Open Source Data Infrastructure

當(dāng)一項(xiàng)技術(shù)變得被廣泛采納的時(shí)候，那么他的局限性也變得眾所周知了，Hadoop也不例外,下文羅列了Hadoop的部分缺點(diǎn)

1)、快速查詢;

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

3)、流處理;

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

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

Data Infrastructure Space Today

1.Modern Open Source Stacks

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

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

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

這里有很多的不同技術(shù)，有很多技術(shù)都是彼此競(jìng)爭(zhēng)關(guān)系，我沒有時(shí)間給大家做逐一贅述，也不能夠進(jìn)一步詳細(xì)介紹每個(gè)技術(shù)是什么。但是我希望給大家提供簡(jiǎn)介，幫助大家了解這些技術(shù)是做什么的，以及整個(gè)構(gòu)架是什么樣的。

2.Data Delivery

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

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

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

現(xiàn)在Kafka逐步變成了這個(gè)領(lǐng)域的標(biāo)準(zhǔn)。

　　3.Storage

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

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

4.Processing

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

5.Stream Processing

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

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

　　6.Batch Processing

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

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

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

　　7.Querying

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

8.SQL-on-Hadoop

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

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

9.Key/Value Stores

另一種加速查詢速度的方法就是要把資料庫進(jìn)行優(yōu)化，這樣就能夠打造一種非?？焖俚牟樵兊募軜?gòu)。它可以支持非?？焖俚牟檎遥部梢赃M(jìn)行快速的寫入，我們有很多時(shí)間序列的數(shù)據(jù)庫都有鍵值存儲(chǔ)。

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

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

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

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

10.Column stores

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

　　11.Druid

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

12.面對(duì)如此多的選擇，我們究竟選擇哪一個(gè)呢?

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

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

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

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

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

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

在數(shù)據(jù)提交方面，Kafka已經(jīng)達(dá)到了這個(gè)標(biāo)準(zhǔn)，對(duì)于流處理方面Spark已經(jīng)成為了標(biāo)準(zhǔn)的工具，我覺得Druid查詢方面也做得很好。

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

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