Apache Tez 瞭解

標籤：目標   sam   避免   gray   中間   持久性   不同類   style   pad   

你可能聽說過Apache Tez，它是一個針對Hadoop資料處理應用程式的新分布式執行架構。但是它到底是什麼呢？它的工作原理是什嗎？哪些人應該使用它，為什嗎？如果你有這些疑問，那麼可以看一下Bikas Saha和Arun Murthy提供的呈現“Apache Tez: 加速Hadoop查詢處理”，在這個呈現中他們討論了Tez的設計，它的一些突出亮點，同時還分享了通過讓Hive使用Tez而不是MapReduce而獲得的一些初始成果。

Tez是Apache最新的支援DAG作業的開源計算架構，它可以將多個有依賴的作業轉換為一個作業從而大幅提升DAG作業的效能。Tez並不直接面向終端使用者——事實上它允許開發人員為終端使用者構建效能更快、擴充性更好的應用程式。Hadoop傳統上是一個大量資料批處理平台。但是，有很多用例需要近乎即時的查詢處理效能。還有一些工作則不太適合MapReduce，例如機器學習。Tez的目的就是協助Hadoop處理這些用例情境。

 

Tez項目的目標是支援高度定製化，這樣它就能夠滿足各種用例的需要，讓人們不必藉助其他的外部方式就能完成自己的工作，如果 Hive和 Pig 這樣的項目使用Tez而不是MapReduce作為其資料處理的骨幹，那麼將會顯著提升它們的回應時間。Tez構建在YARN之上，後者是Hadoop所使用的新資源管理架構。

設計哲學

Tez產生的主要原因是繞開MapReduce所施加的限制。除了必須要編寫Mapper和Reducer的限制之外，強制讓所有類型的計算都滿足這一範例還有效率低下的問題——例如使用HDFS儲存多個MR作業之間的臨時資料，這是一個負載。在Hive中，查詢需要對不相關的key進行多次shuffle操作的情境非常普遍，例如join - grp by - window function - order by。

 

Tez設計哲學裡面的關鍵元素包括：

• 允許開發人員（也包括終端使用者）以最有效方式做他們想做的事情
• 更好的執行效能

Tez之所以能夠實現這些目標依賴於以下內容：

• 具有表現力的資料流API——Tez團隊希望通過一套富有表現力的資料流定義API讓使用者能夠描述他們所要運行計算的有向非循環圖 （DAG）。為了達到這個目的，Tez實現了一個結構化類型的API，你可以在其中添加所有的處理器和邊，並可視化實際構建的圖形。
• 靈活的輸入—處理器—輸出（Input-Processor-Output）運行時模型——可以通過串連不同的輸入、處理器和輸出動態地構建運行時執行器。
• 資料類型無關性——僅關心資料的移動，不關心資料格式（索引值對、面向元組的格式等）。
• 動態圖重新設定
• 簡單地部署——Tez完全是一個用戶端應用程式，它利用了YARN的本地資源和分布式緩衝。就Tez的使用而言，你不需要在自己的叢集上部署任何內容，僅需要將相關的Tez類庫上傳到HDFS上，然後使用Tez用戶端提交這些類庫即可。

  你甚至可以在你的叢集上放置兩份類庫。一份用於產品環境，它使用穩定版本供所有的生產任務使用；另一份使用最新版本，供使用者體驗。這兩份類庫相互獨立，互不影響。

• Tez能夠運行任意MR任務，不需要做任何改動。這樣能夠讓那些現在依賴於MR的工具實現分布遷移。

接下來讓我們詳細地探索一下這些表現力豐富的資料流API——看看我們可以使用它們做些什嗎？例如，你可以使用MRR模式而不是使用多個MapReduce任務，這樣一個單獨的map就可以有多個reduce階段；並且這樣做資料流可以在不同的處理器之間流轉，不需要把任何內容寫入HDFS（將會被寫入磁碟，但這僅僅是為了設定檢查點），與之前相比這種方式效能提升顯著。下面的圖表闡述了這個過程：

第一個圖表展示的流程包含多個MR任務，每個任務都將中間結果儲存到HDFS上——前一個步驟中的reducer為下一個步驟中的mapper提供資料。第二個圖表展示了使用Tez時的流程，僅在一個任務中就能完成同樣的處理過程，任務之間不需要訪問HDFS。

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串連池。應用程式可以選擇使用這些共用註冊Object Storage Service不同類型的預計算資訊，這樣之後再進行處理的時候就能重用它們而不需要重新計算了，同時這些共用的串連集合及容器池資源也能非常快地運行任務。

如果你想瞭解更多與容器重利用相關的資訊，那麼可以查看這裡。

擴充性

總體來看，Tez為開發人員提供了豐富的擴充性以便於讓他們能夠應對複雜的處理邏輯。這可以通過樣本“Hive是如何使用Tez的”來說明。

讓我們看看這個經典的TPC-DS查詢模式，在該模式中你需要將多個維度資料表與一個事實表串連到一起。大部分最佳化器和查詢系統都能完成該圖右上方部分所描述的情境：如果維度資料表較小，那麼可以將所有的維度資料表與較大的事實表進行廣播串連，這種情況下你可以在Tez上完成同樣的事情。

但是如果這些廣播包含使用者自訂的、計算成本高昂的函數呢？此時，你不可能都用這種方式實現。這就需要你將自己的任務分割成不同的階段，正如該圖左邊的拓撲圖所展示的方法。第一個維度資料表與事實表進行廣播串連，串連的結果再與第二個維度資料表進行廣播串連。

第三個維度資料表不再進行廣播串連，因為它太大了。你可以選擇使用shuffle串連，Tez能夠非常有效地導航拓撲。

使用Tez完成這種類型的Hive查詢的好處包括：

• 它為你提供了全面的DAG支援，同時會自動地在叢集上完成大量的工作，因而它能夠充分利用叢集的並行能力；正如上面所介紹的，這意味著在多個MR任務之間不需要從HDFS上讀/寫資料，通過一個單獨的Tez任務就能完成所有的計算。
• 它提供了會話和可重用的容器，因此延遲低，能夠儘可能地避免重組。

使用新的Tez引擎執行這個特殊的Hive查詢效能提升將超過100%。

路線圖

• 更加豐富的DAG支援。例如，Samza是否能夠使用Tez作為其底層支撐然後在這上面構建應用程式？為了讓Tez能夠處理Samza的核心調度和流式需求Team Dev需要做一些支援。Tez團隊將探索如何在我們的DAG中使用這些類型的串連模式。他們還想提供更好的容錯支援，更加有效地資料轉送，從而進一步最佳化效能，並且改善會話效能。
• 考慮到這些DAG的複雜度無法確定，需要提供很多自動化的工具來協助使用者理解他們的效能瓶頸。

總結

Tez是一個支援DAG作業的分布式執行架構。它能夠輕而易舉地映射到更進階的聲明式語言，例如Hive、Pig、Cascading等。它擁有一個高度可定製的執行架構，因而我們能夠在運行時根據與資料和資源相關的即時資訊完成動態效能最佳化。架構本身會自動地決定很多棘手問題，讓它能夠順利地正確運行。

使用Tez，你能夠得到良好的效能和開箱即用的效率。Tez的目標是解決Hadoop資料處理領域所面對的一些問題，包括延遲以及執行的複雜性等。Tez是一個開源的項目，並且已經被Hive和Pig使用。

 

Apache Tez 瞭解