郭斯傑：重新思考流計算時代的分散式儲存

　　 導語：本文根據郭斯傑老師於第十屆中國系統架構師大會(SACC 2018)的現場演講《從檔案儲存，物件儲存到流儲存 - 重新思考流計算時代的分散式儲存》內容整理而成。

　　 講師介紹：

　　 郭斯傑 ，Streamlio的聯合創始人之一。Streamlio是一家專注於構建下一代流計算基礎設施的初創公司。他也是Apache BookKeeper的PMC主席，Apache Pulsar的PMC成員。在創立Streamlio之前，他是Twitter訊息團隊的技術負責人。

　　 演講正文：

　　大家好，我今天主要分享的是在流計算時代，關於分散式儲存的一些思考。自我介紹一下，我是一個開源愛好者，我主要參與的兩個開源社群，Pulsar，一個雅虎開源的下一代流資料平臺;然後BookKeeper，一個分散式的日誌儲存系統。在這之前我在Hadoop也做了一些跟Hive、HBase相關的工作。

　　我目前在矽谷的一家創業公司叫Streamlio，顧名思義，Streamlio其實是由三個單詞構成的，就是Stream、ml加IO。所以意圖很明顯，我們主要是做跟流相關的基礎架構，未來我們可能會在基於流的基礎架構之上再去做一些ml相關的事情。和流相關的基礎機構包括訊息中介軟體、儲存、還有計算。在加入Streamlio之前，我在Twitter待了五年，主要負責整個Twitter的訊息中介軟體平臺以及資料庫複製，包括跨機房複製相關的基礎設施。在Twitter之前的話，我是在雅虎做了三年多的時間，然後是華中科大畢業的，後來在中科院計算所讀的研究生。

　　 一、背景介紹

　　我的題目其實是關於“實時時代”，或者說“流計算時代”，對於分散式系統我們應該怎麼去考量?我們先看一下，八九十年代，我們最開始儲存資料無外乎兩種辦法，一個是用資料庫，另外一種就是以檔案的方式進行儲存。當你想去存一些資料時，基本上考量的就是這兩個事情。後來慢慢演化出了很多分散式資料庫、分散式檔案系統。隨著網際網路的到來，資料量越來越大，沒辦法用傳統的技術、本地檔案系統、或者是網路檔案系統去存大量資料，沒有辦法在原來的Oracle裡面去存資料。因此就演化出了所謂的“神一般的存在”，就是Hadoop。其實Hadoop的整個生態的話是起源於Google的GFS和MapReduce這套系統，基本上現在大家說大資料，開源社群就一個東西，Hadoop，基本上所有網際網路公司都會有一套Hadoop的系統。

　　整個Hadoop的生態，其實是為批次大資料而存在的。隨著雲時代的到來，像AWS開始把Hadoop放到雲上去，作為產品去賣，然後google也會有各種類似的一系列產品，這其實就是為批次以及大資料產生的一套自己的生態，而這個生態的基礎，基本上是圍繞分散式檔案系統去做的儲存。

　　這是批次時代。批時代的到來，很多其實是Google主導，它主要是搜尋引擎的應用，對時延的要求性不是很高，可以15分鐘跑一個任務，去全網抓一些網頁進行索引。

　　但是隨著一些新興企業的產生，包括比如說像Twitter、Facebook這些社交媒體，會有大量實時產生的資料，就包括使用者發的推特，然後你投遞的廣告以及移動網際網路的興起，會有大量移動端的資料，這個資料的到來就產生了另外一個概念叫做“流”。所謂“流”，它的誕生基本上是因為，雖然我有Hadoop，但是我的時延通常是幾分鐘甚至小時以上的。

　　這個是因為在批次時代，它整個計算模型就是一個批處理的模型，所有的資料採集都是透過一個批次的任務，比如說每5分鐘、每15分鐘寫成一堆檔案，拿著這個檔案提交給計算引擎去處理。隨著應用發生變化，這時候你需要處理的響應時間會變得更長。所以在這個情況下，誕生了Storm + Kafka這種特殊的模式。這種模式最開始變得流行，是由Twitter帶起來的。因為Twitter整個的產品定位，相當於每個人都是往Twitter上發訊息，然後每個人都從Twitter上接受訊息，整個的訊息的投遞、傳送都是實時的，整個Twitter的業務是圍繞“實時”構建的。

　　所以在這種情況下，誕生了一個所謂的——基本上大家在做流的時候，不可避免地會認識到的一個東西，叫Storm。因為Storm是一個流計算的框架，但是你的儲存本質上還是檔案，也就是說我的資料的採集還是以5分鐘、15分鐘進來。但它不能真正意義上發揮流計算的潛質，所以在這種情況下，你需要的是一個新型的面向流的儲存系統。

　　在那個情況下，基本上大家都是用訊息中介軟體，因此也是在這樣的背景下，Kafka與Storm很天然的一個整合，讓整個系統變成了流計算的一個事實規範。所以在這種情況下，就衍生出了後面更多的一些流計算框架，比如說Flink，以及Hadoop演化出來的Spark，Spark再繼續做Spark Streaming，最後整個計算生態就變得百花爭豔。

　　但是這種情況下，假如我有一個批處理的資料，還有一個流處理的資料，這時候我們會發現在整個公司內部的資料架構，其實變成了兩個部分，兩個相互隔離的資料孤島。其中一個資料孤島是流資料孤島(Streaming Data Silo)，就是說完全是為了Streaming Data去做的一套架構，另外一個資料孤島是批次資料孤島(Batch Data Silo)，也就是為了批次計算構建的一套獨立系統。Streaming Data的話，你通常可以看到你需要一個訊息中介軟體，類似於Kafka或者ACTIVEMQ，然後在上面可以跑流計算的一個引擎。在Batch的話，基本上還HDFS或者其他的分散式檔案系統;在雲上的話，可能就是物件儲存如S3，GCS等類似的物件儲存，這上面你可能需要有MapReduce或者是一個類似Hive的資料倉儲。但它其實是相互隔離的一個狀態。

　　這個隔離會帶來一個問題，你的兩個資料其實是相互分離的。分離帶來的問題是，我需要學兩套API，需要兩套叢集去存放資料，然後圍繞這個生態圈，需要兩套工具去管理這些資料。

　　怎麼去解決出現的情況，在Twitter最開始提出的一個架構叫Lambda，意思是說，我有兩層，一層是批處理層，就跑我的全量資料，包括MapReduce、包括Spark，但是因為它是批處理，時延是相對比較大的。這時我為了快，再加一個加速層。加速層的是怎麼工作的?我的所有資料是透過訊息中心進來，基本上是以流的方式進到計算引擎，然後拿一個流處理的計算引擎去做處理，處理完了以後，產生的是一個增量的結果，然後把這兩個結果做整合，提供給最終的使用者。

　　所以Lambda的架構，其實只是把這兩個Data Silo在最終的結果端做了一個彙總，讓使用者看起來是一個統一體。但實際上，你最開始的資料進來，會被分流到兩個不同的系統裡面去，一個是所謂的訊息中介軟體，一個是檔案系統或者物件儲存。你整個業務的代價、機房的開銷、硬體設施的代價、維護人員代價，其實都是雙倍的。所以在這種情況下，我們發現Lambda會變得越來越重，因為隨著資料量變得越來越大，本質上是沒法使用Lambda支撐更大的業務。

　　所以在這種情況下，就有人提出了Kappa的概念。它的概念其實很簡單，就是所有的資料都以日誌的方式存進來，因為日誌它其實是一個append-only的儲存。存進來了以後，日誌本身上它具有流的一個特性，然後所有的訪問都是以追尾讀的方式去讀，所以它可以做到訊息中間間的低時延。那就可以把所有資料存起來，當你需要回放歷史資料時，還可以做相應的批處理。

　　在計算引擎上，因為你的資料表徵變成一份了，你的計算引擎、API就可以統一起來，所以這也是後來為什麼那麼多計算框架在做批、流一體。比如Flink既可以支援批，也可以支援流。其實都在做一個事情，就是要讓API在處理批跟處理流上是統一的，只需要學一個計算框架、一套API，就能做原來的兩件事情。

　　Kappa這個架構是很好的一個想法，但要真正做到真正意義上的Kappa，你不能拿一個訊息中心間去做一個Kappa。因為訊息中介軟體基本上是為訊息，就是你的尾端資料去做設計的，所以它基本上沒有考慮儲存方面的一些特性。所以我們認為在批、流一體的時代，當你需要去做批、流一體化的計算時，其實是需要一個真正意義上的流儲存。

　　流儲存的意思就是，你的資料可以透過流的一個或者append-only log的方式去表徵。你最新的資料被append到log裡面以後，它其實是作為我們通常意義上說的流計算的尾端資料進行處理，但你的資料被append之後會慢慢累加，就會變成你的歷史資料。當你需要去做全量計算，需要回溯到7天前、30天前這樣一個處理歷史資料的時候，你可以進行相應的回溯。所以我們認為Kappa是你做批、流一體的一個正確基礎，但是我們需要為Kappa去做一個真正意義上的流儲存。所以我們streamlio大部分創始團隊都是來自於Twitter、雅虎原來做訊息中介軟體跟流計算的，所以我們一直在琢磨一個事情，就是說我們怎麼去做真正的流儲存。

　　 二、關於Apache Pulsar

　　接下來，主要分享我們正在做的一些工作，然後我會回過頭來怎麼看我們做的工作是怎麼對映到現在針對於批、流一體的計算方式下的一個考量。

　　我們先來看一個特點，什麼叫流儲存?流儲存，它其實兩個單詞，一個stream，一個是storage。Stream代表了它的訪問模式，就是在資料寫入以後，我的消費者或者我的讀者，是立馬可見的，不需要等經過比如5分鐘的批處理，等檔案全部寫完了以後，才能提交到執行引擎去處理。通常stream的一個介面，就是傳統意義上的消費訂閱模式，就是說我的資料生產到這個stream裡面之後，我的訂閱者、消費者就立馬可見。

　　Storage的意思是跟傳統意義上storage類似，它本質上是一個分散式儲存，它需要保證我能夠可靠穩定地儲存資料，不丟資料，而且無論我什麼時候再去訪問這個資料，我的架構上都有能力把這個資料給存下來。因為我們剛才一直在說的就是所謂的大資料，有大量的資料要算，所以這個東西必須是水平可擴充套件的，並且是高吞吐的。

　　所以我們圍繞一個開源的專案叫Apache Pulsar來做這個事情。Pulsar是什麼呢?其實最簡單的、最容易理解的是，我們通常來說這個事情的話，我們會把它放到訊息佇列裡面，就跟大家知道的Kafka、ACTIVE MQ、RabbitMQ都是在一個space裡面，但是它不同的地方是什麼?就是說Pulsar在整個設計上，並不只是一個簡簡單單的訊息佇列，我們通常用一句話來概括Pulsar是什麼，“Flexible Pub/Sub messaging backed by durable log/stream storage”，它其實有兩層意思，就是說你是一個面向訊息或者面向流的訊息系統，但是這個訊息系統可以提供低延時地消費你的資料的能力，但是你的底層是以一個這種持久化的append-only的日誌或者流的儲存，作為分散式儲存的一個支撐。

　　在解釋這個事情之前，我大概介紹一下這個專案。這個專案是在2012年雅虎內部啟動，然後經過了無數的迭代以後，在2016年9月把它貢獻、開源出來。在開源不到一年之後，去年6月份，把它捐獻給Apache軟體基金會，今年的9月它正式成為頂級專案。在雅虎的Github上我們做了22個releases，然後把Pulsar捐獻給軟體基金會之後不到一年的時間，我們做了9個釋出，基本上是不到一個半月有一次釋出，目前是相對比較活躍的一個專案。

　　 Pulsar與傳統訊息系統的不同

　　那我說了那麼多，它跟傳統的訊息系統不同的地方是什麼?首先是因為是訊息系統，那不可避免地要跟傳統的訊息系統做對比。它在應用層面上其實是做了一個資料消費模型的統一，既支援傳統的佇列，也支援高效能的流的處理。這是從API的角度來說。但我們其實更關注的是分散式儲存，它跟傳統的訊息系統不一樣的地方是，傳統的訊息系統其實是面對訊息資料去做的，所以它其實沒所謂儲存的概念。但是在Pulsar裡面，我們其實是把儲存跟計算分離，但計算更多的是強調messaging的那一塊。

　　我們把這兩個分離了以後，同時把傳統訊息中介軟體使用的一個物理分割槽的模型，變成了一個更多分散式系統用的分片模型，那這樣的話可以打造出一個既有實時訊息系統的streaming的一個API，然後你又能夠有一層是可提供無限儲存的一個儲存系統。

　　 靈活統一的訊息模型：佇列+流

　　我簡單說一下佇列加流的模型，基本上在流計算裡面都不可避免要用訊息中介軟體，那訊息中介軟體無外乎就是生產者、消費者，然後中間加一個topic，或者是consumer group和subscription這樣的概念。

　　不一樣的地方是，像Kafka這樣的一個訊息中介軟體，它更多的是面向流去做設計的。像傳統的ACTIVE MQ以及阿里的RocketMQ，更多的是面向佇列去做設計，這時候Pulsar其實是在這上面做了一個統一。統一的意思是，我的生產者都往一個地方去發訊息，這個訊息的載體叫topic，但是我允許在topic上有不同的訂閱模式。所謂的訂閱模式，它處理的場景是不一樣的，可以是順序消費的streaming的模式，可以是共享消費的佇列模式。

　　舉三個簡單的例子，第一個我們叫獨佔式訂閱，就是對於一個topic的一個流，只有一個消費者去消費，那麼所有的消費都是順序的，這時候我可以做很高的吞吐。

　　另外一種災備式訂閱，其實是獨佔式的一個延伸，相當於有兩個消費者或多個消費者，都想消費這個topic，但是在某一個時間段只有一個活躍的消費者，這個消費者可以源源不斷的去消費，其他人只是他的一個災備。如果活躍的消費者down掉了以後，其他消費者就可以立馬接管，保證整個的處理是相對特別快的。

　　另外一個方式，更多的是線上業務、訂單業務、通知系統裡面會用的共享式訂閱，就是說對同一個topic，我可能不需要不在乎序，這時候我可以加無限個消費者去擴充套件消費能力，這些訊息以共享的方式分發給不同的消費者。

　　這是Pulsar在所謂的API模型上做的一個統一，但這只是給大家一個簡單的一個概念，最主要的地方是，它其實是把傳統的訊息系統跟傳統的分散式檔案系統或者分散式儲存系統做了一個整合。

　　 儲存與計算分離

　　另外提出的一個概念其實很簡單，就是儲存跟計算分離。分離的意思是說我有兩層，一層是儲存層，可以無限擴容，存很多資料;有一層是所謂的訊息層，就是傳統意義上的Broker，我可以提供很多低時延的訊息投遞，還有讀尾端的資料。

　　分層以後帶來的一個好處是，每一層都可以獨立擴充套件，比如當我需要更大的儲存的時候，我可以只加儲存節點。當我需要更多的消費者，需要更多人去讀這個資料的時候，只需要加我的更多Broker就行了。分層以後還有一個好處是，我的Broker變成了沒有狀態，沒有狀態了以後，做一些容錯、擴容就會變得特別簡單，不需要搬很多的資料。

　　在儲存層，其實是用了另外一個專案叫Apache BookKeeper。它本質上一個專門針對分散式日誌的儲存系統。它的定位很簡單，就是一個強一致的系統，是一個刷盤落盤的持久化儲存，能保證即使落盤，我也能做到低延時跟高吞吐。它的設計會在可用性上做很多的文章，保證一些讀寫高可用。給大家一個大概的概念，BK可以做什麼?BK最開始的一個主要應用場景是HDFS NameNode，它做的是NameNode的HA，就是說NameNode會有一個added log，它其實是整個HDFS的靈魂，就是說你所有對HDFS的Metadata的修改，都會落到added log裡面進去。BookKeeper最開始出現就是為了解決HDFS NameNode HA的問題，但後來慢慢就衍生成了一個通用的分散式日誌儲存系統。

　　它最主要的兩個應用場景，我們概括出來，一個的是資料庫，另外一個就是訊息或者是流。BookKeeper用在資料庫，主要介紹兩個，一個是Twitter內部有Key Value儲存Manhattan，BookKeeper作為Manhattan的transaction log去實現Manhattan Key Value的強一致性。另外一個是，Salesforce拿Salesforce來做一個類似於Amazon Aurora的一個NewSQL的資料庫。所以這就是BookKeeper在資料庫的應用場景，我們可以注意到BookKeeper在這裡面其實是整個資料庫的transaction log，基本上就是append-only的工作負載。

　　另外一個場景是訊息，基本上Twitter跟雅虎都是拿BookKeeper作為整個訊息平臺的儲存。訊息基本上也是append-only的工作負載，我之所以一直強調append-only是因為，BookKeeper的整個設計，就是為了日誌或者為流誕生的。

　　 分片儲存

　　這給大家做一個簡單的介紹，Pulsar的底層用的是一個面向流和麵向日志的一個分散式儲存系統，Pulsar圍繞BookKeeper去構建訊息中介軟體，或者是我們叫流儲存的一個概念的話，它在傳統意義上的這種topic分割槽上做了一個概念，就是說我的分割槽不再是一個物理的分割槽，其實是一個邏輯上的分割槽。

　　邏輯上的分割槽的意思是，我可以無窮無盡地往分割槽上追加資料、寫資料。但是在底層，我會把邏輯上的分割槽切成不同的分片，分片會均勻打散，儲存到底層的一個儲存系統裡面。基本上HDFS或者其他的分散式檔案系統都是這樣的一個思路，所以它本質上就是用分散式儲存來做訊息系統，或者是做流儲存的一個思路。

　　我們剛才說了分層跟分片的概念，為什麼我們說分層分片特別重要，它其實解決了很多可用性、容錯、包括運維過程中的一些問題。我舉兩個例子，一個是關於容錯，一個是關於擴容。

　　容錯方面的話，因為它其實是分成兩層了，有一層是Broker，另外一層是儲存節點。Broker失效了以後，其實它會很簡單，因為記得所有的資料其實存在儲存節點上，Broker本身是沒有任何狀態沒有儲存任何資料的，它只擁有一個分割槽的所有權。所有權的意思是，我可以提供分割槽的一個寫服務，當它失效的時候，我只需要把所有權從失效的Broker換到其他線上的一些Broker就可以了，你的整個的流量、你的消費者、消費的資料都可以轉到新的Broker上繼續處理，所以基本上，基本在毫秒級別就可以完成。

　　BookKeeper的容錯上，其實跟傳統的分散式檔案系統是類似的，因為是計算跟儲存分離了以後，你的儲存基本上是被Broker層給隱藏了，所有的生產者、消費者都是跟Broker打交道，所以當你一個儲存節點掛掉的時候，你的應用端其實是沒有任何感知的，而整個失效恢復都是由儲存節點在後臺進完成。

　　舉個最簡單的例子(如下圖)，在Bookie 2上，就是第二個儲存節點上，我的Segment 4掛了或者整個第二個節點掛掉了以後，我Segment 4的副本資料從3變成2，為了保證資料可用性，需要把副本的數量從2調回到3。這時候後臺有一個自動恢復機制，從第三個儲存節點跟第四個儲存節點，把Segment 4的資料重新複製到第一個儲存節點上，從而保證資料有副本。所以這個是Bookie的容錯，它整個容錯會使你的應用端變的相對更能容忍失效的發生。

　　另外一個好處是，擴容會變得特別簡單，相當於只需要追加新的儲存節點。追加新的儲存節點的話，所有的Broker就能發現儲存節點被新加進來了，當我需要繼續寫新的資料的時候，我會開新的Segment，新的Segment就會自然而然地落到新的儲存節點，整個擴容就會自動、平滑、均勻地擴散到整個叢集裡面。這就是分層架構帶來的一些容錯和運維上的好處。

　　下面是一個示意圖，傳統的訊息中介軟體基本上都是基於物理分割槽去做的，因為它其實不是為了所謂的流儲存去做設計的，它的設計理念就是，我只需要保證我的資料儲存在一段時間內，我的訊息消費完了就可以了。物理分割槽帶來的問題是，資料跟儲存節點是強繫結的，對於一個分割槽，是沒辦法增長到比儲存節點更大容量的，這時候其實不適合用來做流儲存或者是長遠的一個儲存。

　　另外一個問題是，如果要做容錯恢復，或者說做擴容的時候，會涉及到一個問題，因為我的物理分割槽其實是跟儲存節點強繫結，強繫結帶來問題是，如果要做負載均衡，要容錯，這時候需要把物理分割槽重新複製到新的儲存節點上，整個複製的過程其實是一個特別消耗頻寬的過程。

　　但是Pulsar的做法不一樣，它把物理分割槽變成了一個邏輯分割槽。邏輯分割槽以後，整個分割槽的容量不再受限於單臺機器，而是整個叢集，這樣的話你能做到真正意義上的流儲存。邏輯分割槽以後，其實是把儲存跟計算相互分離，這時候你的失效的處理會變得相對快速，然後沒有痛點，然後你在每一層都可以做獨立的擴充套件。

　　舉一個最簡單的例子或更形象的一個例子，大家可以看下面這兩張圖，就是說你分割槽模型的話，所有分割槽的資料只能落在某一個儲存節點上，你只能在這個節點上無限增長，但是它會有個頂，到了那個頂了以後，沒有辦法繼續儲存你的資料了。但是這種邏輯分割槽和分片的模型，其實是把你的資料切成不同的小的粒度，均勻打散到整個儲存空間裡面進去。這時候你其實能做到真正意義上的流儲存，因為可以無窮無盡地存資料流。

　　 為什麼要引入流儲存?

　　儲存其實都是有一定限度的，而且很多情況下的話，已經有了HDFS，我在雲上已經有太多的物件儲存，有太多的檔案系統儲存，這時候我這些系統已經跑得好好的了，為什麼還要引入一個新的系統?這個時候我們其實在想，我們做流儲存的真正目的，並不是要再造一個儲存系統，而是說我們要在整個資料的抽象上能做到統一，透過流的方式既能表徵我的實時資料，也能表徵我的歷史資料，那這個時候我們完全可以利用已有的雲端儲存，或者更廉價的儲存去存已經變老的一些資料。

　　因為我們其實是一個分片模型，分片模型帶來的好處是，能夠很自然地知道我的資料什麼時候變老，當資料變老的時候，可以很容易地把整個資料解除安裝到廉價儲存裡面。但是從應用端來看，整個的資料還是以流的介面、流的表徵方式去表達。你在編寫計算的時候，不用去區分，你需要訪問的是到訊息佇列裡面去算實時計算，還是到HDFS裡面去算實時計算，只需要透過統一的一個API就可以做批、流一體的計算，所以這就是我們圍繞Pulsar，圍繞流的模型以及分片模型做的一個事情。

　　因為我們覺得在批、流一體的計算時代，你的資料如果還是以不同的方式去表徵的話，其實還是存在這種所謂的冗餘、資料複製、資料重複，然後兩個資料來源之間不一致的問題，透過流的方式可以統一地表達相應的資料。

　　 三、例子-互動式查詢

　　做流儲存有什麼好處呢?舉一個最簡單的例子，就是我們在Pulsar上面做的另外一個事情叫互動式查詢。有時候很多應用場景，不僅僅只是想查7天前或者1天前的資料，可能是想把我7天前的資料，再加上這1小時的資料一起查，這個時候業務系統很難辦，因為你7天前的資料在HDFS裡面，你這1小時的資料在你的Kafka或者是各種MQ裡面，你沒辦法把兩個資料串在一起查。

　　但是透過流儲存的方式，我們其實可以很容易做到這一點。因為你整個流表徵的是，歷史資料跟實時資料，其實在統一的一個資料抽象裡面，你的資料只要進到流裡面，就是可以查的。這種互動式查詢，具有傳統意義上，像Hive這種互動式SQL能帶來的一個複雜性，就是我可以寫很複雜的SQL的查詢，然後我同時還具有streaming SQL的實時性，但它不能完全等同streaming circle，更多的是說我編寫了一條SQL，我讓它不斷的在那跑，然後它吐結果。互動式查詢更多的是說，我一旦有一個需求，需要查我的歷史資料加實時資料的時候，這個時候叫互動式的查詢。

　　我們在Pulsar裡面做的一個事情叫，我們沒有再去造一個SQL的輪子，而是用Facebook的Presto做了一個深度的開發。為什麼我們用Presto，因為它本質上是一個純的SQL查詢引擎，它不帶自己的儲存節點，但它有自己的一個runtime，所以你可以執行相應的一個SQL查詢。而且它可以查詢不同的資料來源，就是說如果你的業務是在已經在HDFS，你不想動了，但是你新的業務跑在Pulsar上，然後你想把這兩部分的資料進行一個join或者是關聯查詢，這時候Pulsar可以支援不同的資料來源進行查詢，這時候不需要你把所有的資料都導到Pulsar裡面再進行一個查詢。

　　它的實現其實相對特別簡單，就像我剛才說的，整個的資料它是一個流，流被切成了不同的分段，不同的分段其實儲存在不同的儲存節點上，即使最尾端的分段，其實只要資料寫進來了，就可以讀。所以當你做SQL查詢的時候，你的訪問不再是受限於分割槽的數量，就是說，不再是當只有五個分割槽時，併發度只能是五。因為整個的分割槽是個邏輯分割槽，你的分片可能是一百個分片，這時候如果一百個儲存節點，甚至是一百個執行節點，併發度就可以是一百，整個SQL查詢的執行效率就會特別高，因為它是以分片為粒度，而不再是以分割槽為粒度。

　　所以就像上圖展示的，它實現的是一個多對多的資料訪問，這個資料訪問是因為Pulsar本質上是一個分散式的儲存系統，它是一個分片儲存，所以你整個的Presto的worker可以併發訪問同一個分割槽的不同分片。我們其實在整個流裡面第一次去加了時間索引，根據你的寫入時間，就PublishTime快速定位分片，我們可以根據PublishTime快速做定位，然後我們就能知道要讀哪些分片，不需要進行全掃描。

　　 四、總結

　　總結一下我的分享，我們發現，在計算趨於批、流一體化的這種大浪潮下，所有的Spark、Flink、Beam……的API其實都是批、流一體。在這個時候，我們發現你的資料表徵其實還是分散的，就是說你的實時資料、流資料還是以訊息的方式去表徵。你的歷史資料是以檔案系統或者是物件儲存去表徵，但是你會發現這部分資料它其實是同一部分資料。就是說你的訊息跟你最後的檔案系統，它們其實表彰的是同一部分資料。這個資料它只是一枚硬幣的兩面，你的流計算，是處理硬幣的一面，然後你的批計算是處理硬幣的另外一面。其實本質上在資料表徵態的話，它不應該分開。流是原始資料最自然的一種表徵，因為你所有的資料流進來，會不斷的追加到流裡面，其實不需要進行任何的一個轉換，所以流是能夠很自然地把所有的實時資料跟歷史資料都儲存下來。我們認為在實時時代，你需要有一個流儲存作為資料的分散式儲存，然後去實現真正意義上的批、流的一體化。

　　以上是我今天的分享，當然可能大家會有不認同流儲存的概念，歡迎提意見。