背景
Facebook是一家數據驅動的公司。 數據處理和分析是Facebook爲10億多活躍用戶開發和交付產品的核心所在。 我門擁有世界上最大的數據倉庫之一，存儲了大約 300PB 以上的數據。 這些數據被一系列不同種類的程序所使用， 包括傳統的數據批處理程序、基於圖論的數據分析［1］、機器學習、和實時性的數據分析。
分析人員、數據科學家和工程師需要處理數據、分析數據、不斷地改善我們的產品， 對於這些人來說， 提高數據倉庫的查詢性能是非常重要的。在一定時間內能夠運行更多的查詢並且能夠更快地獲得查詢結果能夠提高他們的工作效率。
Facebook數據倉庫中的數據存儲在幾個大型的Hadoop HDFS的集羣上。 Hadoop MapReduce［2］和Hive被設計爲用於進行大規模、高可靠性的計算，而且這些技術都被優化爲用來提高整體系統的吞吐量。但是當我們的數據倉庫增長到PB級別，並且我們的需求進一步提升的時候， 我們就非常需要一個在數據倉庫上工作的，能夠提供低延遲的交互式查詢系統。
在2012年秋天，Facebook 數據基礎設施（Data Infrastructure）部門的一支團隊開始爲我們的數據倉庫的用戶解決這個問題。我們評估了一些外部項目， 發現這些項目或者是太不成熟，或者就是不能滿足我們在靈活性和規模性上的要求。 所以我們決定開始搭建Presto，一個嶄新的能夠在PB級別的數據上進行交互式查詢的系統。
在這篇文章中，我們將簡單地介紹Presto的架構、現狀和前景。
架構
Presto是一個分佈式SQL查詢引擎， 它被設計爲用來專門進行高速、實時的數據分析。它支持標準的ANSI SQL，包括複雜查詢、聚合（aggregation）、連接（join）和窗口函數（window functions)。
下面的架構圖中展現了簡化的Presto系統架構。客戶端（client）將SQL查詢發送到Presto的協調員（coordinator）。協調員會進行語法檢查、分析和規劃查詢計劃。計劃員（scheduler）將執行的管道組合在一起， 將任務分配給那些裏數據最近的節點，然後監控執行過程。 客戶端從輸出段中將數據取出， 這些數據是從更底層的處理段中依次取出的。
Presto的運行模型和Hive或MapReduce有着本質的區別。Hive將查詢翻譯成多階段的MapReduce任務， 一個接着一個地運行。 每一個任務從磁盤上讀取輸入數據並且將中間結果輸出到磁盤上。 然而Presto引擎沒有使用MapReduce。它使用了一個定製的查詢和執行引擎和響應的操作符來支持SQL的語法。除了改進的調度算法之外， 所有的數據處理都是在內存中進行的。 不同的處理端通過網絡組成處理的流水線。 這樣會避免不必要的磁盤讀寫和額外的延遲。 這種流水線式的執行模型會在同一時間運行多個數據處理段， 一旦數據可用的時候就會將數據從一個處理段傳入到下一個處理段。 這樣的方式會大大的減少各種查詢的端到端響應時間。
Presto系統是用Java來實現的， 主要原因是Java的開發效率高，且擁有非常好的生態環境， 並且很容易同Facebook數據基礎設施的其他Java應用進行集成。Presto會將查詢計劃中的一部分動態地編譯成JVM字節代碼，並讓JVM優化和生成原生的機器代碼。 通過謹慎地使用內存和數據結構，Presto避免了通常Java程序會碰到的內存分配和垃圾收集（Java garbage collection）的問題。（在後一篇文章中， 我們會分享一些在開發高性能Java系統的時候的一些提示和技巧，以及我們在搭建Presto系統時的一些經驗教訓。）
擴展性是在設計Presto時的另一個要點。在項目的早期階段， 我們就意識到出了HDFS之外，大量數據會被存儲在很多其他類型的系統中。 其中一些是像HBase一類的爲人熟知的系統，另一類則是象Facebook New Feed一樣的定製的後臺。Presto設計了一個簡單的數據存儲的抽象層， 來滿足在不同數據存儲系統之上都可以使用SQL進行查詢。存儲插件（連接器,connector）只需要提供實現以下操作的接口， 包括對元數據（metadata）的提取，獲得數據存儲的位置，獲取數據本身的操作等。除了我們主要使用的Hive/HDFS後臺系統之外， 我們也開發了一些連接其他系統的Presto 連接器，包括HBase，Scribe和定製開發的系統。
（譯者注：Scribe是Facebook的開源項目，可以實時的將大量服務器產生的日誌文件彙總到文件系統中， 詳見：https://github.com/facebook/scribe）
（譯者注： 從目前的信息來看，Presto的架構在分佈式處理數據的方式和基於MapReduce 2.0的HorntonWorks的Stinger有着很大的不同，可能會比較接近於Google的Dremel或者Cloudera的Impala。 ）
現狀
正如上面所介紹的， Presto的開發是從2012年的秋天開始的。 在2013年早期的時候我門的第一個生產系統開始運行。 在2013年春天的時候這個系統推廣到了Facebook的整個公司。從那是起， Presto成爲了公司內在數據倉庫上進行交互式分析的主要系統。 它被部署到了多個不同的地區，而且我們成功地將一個集羣擴展到了1000個節點。 超過1000名以上的員工在日常工作中使用這個系統， 他們每天在一個PB的數據上會運行超過30,000個查詢。
Presto在CPU的性能和主要的查詢性能上比Hive/MapReduce要好10倍以上。它目前支持ANSI SQL的大部分操作， 包括連接、 左／右外連接、 子查詢、以及通用的聚合和標量函數， 同時也包含了一些近似的去重（使用了 HyperLogLog）和近似的百分數（基於quantile digest算法,）計算。目前階段的主要限制是在表連接時候的大小限制以及唯一鍵值和羣組的基數（cardinality of unique keys/groups）。目前系統沒有能力將查詢結果回寫到特定的表中（目前查詢結果會直接通過流輸出的方式返回給客戶端）。
（譯者注：對大數據進行特定操作的時候會用到一些使用統計方法的近似算法。HyperLogLog算法時用來估計大量數據中特定值出現次數的，具體可以看這篇博文。Quantile Digest算法及具體應用可以看這篇博文。）
展望
我們在積極努力地擴展Presto的功能以及提供性能。 在接下來的幾個月中，我們會去除查詢中連接和聚合的大小限制，同時我們將提供將查詢結果寫入輸出表的功能。 我們同時在開發一個查詢加速器。主要是設計一種爲查詢處理優化的新的數據格式來避免不必要的數據轉換。 這些新的特性會將後臺數據倉庫中經常使用的數據集合緩存起來， 系統會有效地使用這些緩存數據來加速查詢的速度，而不需要讓用戶知道緩存機制的存在。 我們同時也在開發一個高性能的HBase連接器（HBase connector）。
開源
2013年6月的Analytics @ WebScale大會上， 我們第一次介紹了Presto。在那之後，它吸引了許多外界對它的關注。在最近的幾個月中， 我們已經將Presto的源代碼和可執行包發佈給了一些外界的公司。他們已經在他們自己的環境中成功地進行了部署和測試的工作， 並且給了我們很好的反饋。
今天我們非常高興宣佈我們將Presto變成開源項目。 你可以在以下的網站上找到源代碼和文檔。 我將非常樂意從你這裏瞭解到你的用例，以及Presto可以怎樣幫到你的交互式分析。
Preston 官網：http://prestodb.io/
Preston Github 主頁：https://github.com/facebook/presto
Facebook數據基礎設施的Presto團隊由以下成員組成， Martin Traverso, Dain Sundstrom, David Phillips, Eric Hwang, Nileema Shingte 以及Ravi Murthy.
鏈接
[1] Scaling Apache Giraph to a trillion edges.
[2] Under the hood: Scheduling MapReduce jobs more efficiently with Corona
[3] Video of Presto talk at Analytics@Webscale conference, June 2013