你可能據說過Apache Tez，它是一個針對Hadoop數據處理應用程序的新分佈式執行框架。可是它究竟是什麼呢？它的工做原理是什麼？哪些人應該使用它，爲何？若是你有這些疑問，那麼能夠看一下Bikas Saha和Arun Murthy提供的呈現「Apache Tez: 加速Hadoop查詢處理」，在這個呈現中他們討論了Tez的設計，它的一些突出亮點，同時還分享了經過讓Hive使用Tez而不是MapReduce而得到的一些初始成果。html
Tez是Apache最新的支持DAG做業的開源計算框架，它能夠將多個有依賴的做業轉換爲一個做業從而大幅提高DAG做業的性能。Tez並不直接面向最終用戶——事實上它容許開發者爲最終用戶構建性能更快、擴展性更好的應用程序。Hadoop傳統上是一個大量數據批處理平臺。可是，有不少用例須要近乎實時的查詢處理性能。還有一些工做則不太適合MapReduce，例如機器學習。Tez的目的就是幫助Hadoop處理這些用例場景。express
Tez項目的目標是支持高度定製化，這樣它就可以知足各類用例的須要，讓人們沒必要藉助其餘的外部方式就能完成本身的工做，若是 Hive和 Pig 這樣的項目使用Tez而不是MapReduce做爲其數據處理的骨幹，那麼將會顯著提高它們的響應時間。Tez構建在YARN之上，後者是Hadoop所使用的新資源管理框架。apache
設計哲學
Tez產生的主要緣由是繞開MapReduce所施加的限制。除了必需要編寫Mapper和Reducer的限制以外，強制讓全部類型的計算都知足這一範例還有效率低下的問題——例如使用HDFS存儲多個MR做業之間的臨時數據，這是一個負載。在Hive中，查詢須要對不相關的key進行屢次shuffle操做的場景很是廣泛，例如join - grp by - window function - order by。api
Tez設計哲學裏面的關鍵元素包括：緩存
- 容許開發人員（也包括最終用戶）以最有效的方式作他們想作的事情
- 更好的執行性能
Tez之因此可以實現這些目標依賴於如下內容：性能優化
- 具備表現力的數據流API——Tez團隊但願經過一套富有表現力的數據流定義API讓用戶可以描述他們所要運行計算的有向無環圖 （DAG）。爲了達到這個目的，Tez實現了一個結構化類型的API，你能夠在其中添加全部的處理器和邊，並可視化實際構建的圖形。
- 靈活的輸入—處理器—輸出（Input-Processor-Output）運行時模型——能夠經過鏈接不一樣的輸入、處理器和輸出動態地構建運行時執行器。
- 數據類型無關性——僅關心數據的移動，不關心數據格式（鍵值對、面向元組的格式等）。
- 動態圖從新配置
- 簡單地部署——Tez徹底是一個客戶端應用程序，它利用了YARN的本地資源和分佈式緩存。就Tez的使用而言，你不須要在本身的集羣上部署任何內容，僅須要將相關的Tez類庫上傳到HDFS上，而後使用Tez客戶端提交這些類庫便可。
你甚至能夠在你的集羣上放置兩份類庫。一份用於產品環境，它使用穩定版本供全部的生產任務使用；另外一份使用最新版本，供用戶體驗。這兩份類庫相互獨立，互不影響。session
- Tez可以運行任意MR任務，不須要作任何改動。這樣可以讓那些如今依賴於MR的工具實現分佈遷移。
接下來讓咱們詳細地探索一下這些表現力豐富的數據流API——看看咱們可使用它們作些什麼？例如，你可使用MRR模式而不是使用多個MapReduce任務，這樣一個單獨的map就能夠有多個reduce階段；而且這樣作數據流能夠在不一樣的處理器之間流轉，不須要把任何內容寫入HDFS（將會被寫入磁盤，但這僅僅是爲了設置檢查點），與以前相比這種方式性能提高顯著。下面的圖表闡述了這個過程：架構
第一個圖表展現的流程包含多個MR任務，每一個任務都將中間結果存儲到HDFS上——前一個步驟中的reducer爲下一個步驟中的mapper提供數據。第二個圖表展現了使用Tez時的流程，僅在一個任務中就能完成一樣的處理過程，任務之間不須要訪問HDFS。app
Tez的靈活性意味着你須要付出比MapReduce更多的努力才能使用它，你須要學習更多的API，須要實現更多的處理邏輯。可是這還好，畢竟它和MapReduce同樣並非一個面向最終用戶的應用程序，其目的是讓開發人員基於它構建供最終用戶使用的應用程序。框架
以上內容是對Tez的概述及其目標的描述，下面就讓咱們看看它實際的API。
Tez API
Tez API包括如下幾個組件：
- 有向無環圖（DAG）——定義總體任務。一個DAG對象對應一個任務。
- 節點（Vertex）——定義用戶邏輯以及執行用戶邏輯所需的資源和環境。一個節點對應任務中的一個步驟。
- 邊（Edge）——定義生產者和消費者節點之間的鏈接。
邊須要分配屬性，對Tez而言這些屬性是必須的，有了它們才能在運行時將邏輯圖展開爲可以在集羣上並行執行的物理任務集合。下面是一些這樣的屬性：
- 數據移動屬性，定義了數據如何從一個生產者移動到一個消費者。
- 調度（Scheduling）屬性（順序或者並行），幫助咱們定義生產者和消費者任務之間應該在何時進行調度。
- 數據源屬性（持久的，可靠的或者暫時的），定義任務輸出內容的生命週期或者持久性，讓咱們可以決定什麼時候終止。
若是你想查看一個API的使用示例，對這些屬性的詳細介紹，以及運行時如何展開邏輯圖，那麼能夠看看Hortonworks提供的這篇文章。
運行時API基於輸入—處理器—輸出模型，藉助於該模型全部的輸入和輸出都是可插拔的。爲了方便，Tez使用了一個基於事件的模型，目的是爲了讓任務和系統之間、組件和組件之間可以通訊。事件用於將信息（例如任務失敗信息）傳遞給所需的組件，將輸出的數據流（例如生成的數據位置信息）傳送給輸入，以及在運行時對DAG執行計劃作出改變等。
Tez還提供了各類開箱即用的輸入和輸出處理器。
這些富有表現力的API可以讓更高級語言（例如Hive）的編寫者很優雅地將本身的查詢轉換成Tez任務。
Tez調度程序
在決定如何分配任務的時候，Tez調度程序考慮了不少方面，包括：任務位置需求、容器的兼容性、集羣可利用資源的總量、等待任務請求的優先級、自動並行化、釋放應用程序再也不使用的資源（由於對它而言數據並非本地的）等。它還維護着一個使用共享註冊對象的預熱JVM鏈接池。應用程序能夠選擇使用這些共享註冊對象存儲不一樣類型的預計算信息，這樣以後再進行處理的時候就能重用它們而不須要從新計算了，同時這些共享的鏈接集合及容器池資源也能很是快地運行任務。
若是你想了解更多與容器重利用相關的信息，那麼能夠查看這裏。
擴展性
整體來看，Tez爲開發人員提供了豐富的擴展性以便於讓他們可以應對複雜的處理邏輯。這能夠經過示例「Hive是如何使用Tez的」來講明。
讓咱們看看這個經典的TPC-DS查詢模式，在該模式中你須要將多個維度表與一個事實錶鏈接到一塊兒。大部分優化器和查詢系統都能完成該圖右上角部分所描述的場景：若是維度表較小，那麼能夠將全部的維度表與較大的事實表進行廣播鏈接，這種狀況下你能夠在Tez上完成一樣的事情。
可是若是這些廣播包含用戶自定義的、計算成本高昂的函數呢？此時，你不可能都用這種方式實現。這就須要你將本身的任務分割成不一樣的階段，正如該圖左邊的拓撲圖所展現的方法。第一個維度表與事實表進行廣播鏈接，鏈接的結果再與第二個維度表進行廣播鏈接。
第三個維度表再也不進行廣播鏈接，由於它太大了。你能夠選擇使用shuffle鏈接，Tez可以很是有效地導航拓撲。
使用Tez完成這種類型的Hive查詢的好處包括：
- 它爲你提供了全面的DAG支持，同時會自動地在集羣上完成大量的工做，於是它可以充分利用集羣的並行能力；正如上面所介紹的，這意味着在多個MR任務之間不須要從HDFS上讀/寫數據，經過一個單獨的Tez任務就能完成全部的計算。
- 它提供了會話和可重用的容器，所以延遲低，可以儘量地避免重組。
使用新的Tez引擎執行這個特殊的Hive查詢性能提高將超過100%。
路線圖
- 更加豐富的DAG支持。例如，Samza是否可以使用Tez做爲其底層支撐而後在這上面構建應用程序？爲了讓Tez可以處理Samza的核心調度和流式需求開發團隊須要作一些支持。Tez團隊將探索如何在咱們的DAG中使用這些類型的鏈接模式。他們還想提供更好的容錯支持，更加有效地數據傳輸，從而進一步優化性能，而且改善會話性能。
- 考慮到這些DAG的複雜度沒法肯定，須要提供不少自動化的工具來幫助用戶理解他們的性能瓶頸。
總結
Tez是一個支持DAG做業的分佈式執行框架。它可以垂手可得地映射到更高級的聲明式語言，例如Hive、Pig、Cascading等。它擁有一個高度可定製的執行架構，於是咱們可以在運行時根據與數據和資源相關的實時信息完成動態性能優化。框架自己會自動地決定不少棘手問題，讓它可以順利地正確運行。
使用Tez，你可以獲得良好的性能和開箱即用的效率。Tez的目標是解決Hadoop數據處理領域所面對的一些問題，包括延遲以及執行的複雜性等。Tez是一個開源的項目，而且已經被Hive和Pig使用。