Tajo采用了Master-Worker架構(下圖虛線框目前還在計劃中)，Master-Worker-Client之間的RPC通信是使用Protocol buffer + Netty來實作的，具體如下：
（1） TajoMaster：為用戶端提供查詢服務和管理各個QueryMaster（也可以說是 Tajo Worker），解析Query并協調QueryMaster，目前還内置了catalog伺服器。大緻可以分為四個元件：Cluster Manager、Catalog、Global Query Engine以及History Manager。
Catalog 的工作是管理諸如tables、schemas、 partitions，functions，indices及statistics等各種metadata。這些中繼資料資訊一般都是Global Query Engine來操作，為了低延遲考慮跟hive一樣都是存在RDBMS（目前支援Derby和MySQL），預設是儲存在内置的Derby資料庫中。後面 可能會考慮使用hive的HCatalog來完成這塊功能。
Cluster Manager 主要是管理叢集中各個節點之間的通信資訊及資源（記憶體/CPU/Disk）資訊，每個節點定期發送資源資訊，交給Master來管理将用于查詢計劃的配置設定等，這一塊是依賴Yarn的ResourceManager來管理。
Global Query Engine 當一條query送出到master，GQE就會依據表的metadata以及叢集資源資訊（依賴于Catalog和Cluster Manager兩個子產品提供的資訊）生成一個全局的查詢計劃。對于一個分布式執行環境，全局的查詢計劃将會被分片，劃分成各個查詢單元配置設定給各個worker去執行，在這些worker執行過程中GQE會監控每一個查詢單元的運作狀況并實時去優化和容錯。在這一塊目前的文法解析是用ANTLR 4生成AST（抽象文法樹），這個以後可能會使用Tenzing的SQL Query Engine。
History Manager 收集各個query job狀态資訊包括查詢語句，劃分的查詢單元等，通過web ui（預設端口号：26080）可以查詢。
（2） QueryMaster：負責一個query的解析、優化與執行，它參與多個task runner worker協同工作，完成一個query的計算。每個Query Master可以生成多個TaskRunner來執行master的查詢單元，這些task runner都是由yarn中的NodeManager來管理。
（3） Tajo Worker 每個節點就是一個worker角色，每個worker包含存儲子產品管理和一個Local模式的Query Engine，這個local模式的Query Engine就是來接受master配置設定的查詢單元。每個查詢單元包含一個邏輯查詢計劃和一個分片（輸入資料關系的資訊塊），在執行過程中worker定期向master彙報查詢進度和資源資訊，master可以很靈活地面對非異常的錯誤。
圖 1 Tajo體系架構
如圖1所示，Tajo采用傳統資料庫技術開發了SQL解析器，包括SQL解析、生成查詢計劃、優化查詢計劃、執行查詢技術等。但與傳統的資料庫技術 不同，Tajo最終執行查詢技術時借鑒了MapReduce的設計思想，它将查詢計劃轉化為一系列任務，這樣，執行查詢計劃實際上就是執行這些任務，而每 一個任務就是一個計算機關，同時Map Task和Reduce Task一樣。
Tajo定義了一套類SQL的查詢語言（Tajo Query Language TQL），支援大多數的DML，如：select, from, where, join, group-by, order-by, union, and cube。TQL支援可以用兩種變量來表示Scala value（應該是一種記憶體對象）和Temporary table, 可以為它們指派。這種特性，可以讓使用者很容易地處理複雜查詢中間結果是生成Scala value還是臨時表。處理流程和Tenzing都差不多，都是先生成查詢計劃，然後再分到各個worker上去執行，都省去了hive在map之後對生 成的資料進行shuffle和sort的過程，而且對無需寫檔案的中間結果支援直接放記憶體中交給下一個流程去處理，這應該就是它性能高出hive的主要優 化吧。
将一個查詢語句解析成若幹個底層的實體執行計劃有以下幾個步驟，如下圖所示。首先是Global Query Engine将語句轉化成一個抽象文法樹AST（使用Antlr 4實作）并且編譯成一個邏輯計劃。根據catalog中的資訊，查詢優化器使用基于cost的算法（貪婪方式）處理join找到一種最優的邏輯計劃等同于 原始的查詢計劃，同時使用基于規則的算法處理其他方式，最終會生成一種優化後的全局查詢計劃。下一步就是将全局查詢計劃劃分成若幹個查詢單元送出到 worker上去執行。
圖 2查詢轉化流程圖
針對執行過程中的輸入輸出，Tajo提供了一系列的Scanners和Appenders。Scanner負責從HDFS或者本地讀取資料，而 Appender将資料寫入HDFS或者本地磁盤。目前版本支援csv和基于行的二進制檔案格式，系統設計的時候開放了Scanner和Appender 接口，使用者可以針對不同的檔案格式自定義Scanner和Appender來應對不同的應用場景。
Tajo的容錯機制是與MapReduce中的容錯類似，将失敗的任務配置設定給其他的worker，也就是說，當master檢測到一個查詢單元失敗了就會将該查詢單元配置設定到其他的worker節點重新執行。與
作者在一次官方的演講中彙報了tajo-0.8 vs. Impala1.1.1 vs.hive0.10的比較結果。
實驗資料：TPC-H 資料集 100G
硬體裝置：10G network、6 cluster nodes、each machine: Intel Xeon CPU E5 2640 2.5GHZ x 4，64G記憶體，6 SATA2 磁盤。
圖 3 tajo vs. impala vs. hive結果對比圖
下面介紹一下目前還存在哪些問題：
目前還沒有metric系統，系統監控和狀态資訊還不能很好地收集
對于錯誤處理機制還不夠健全，一個query job挂了之後，中間的工作目錄還有job都不能很好地退出。Master不能處理down的worker等等。
Java Api、系統使用文檔、支援的SQL示例、代碼壓根就沒有什麼注釋，也沒有什麼trouble shotting之類的，不過在jira上還是能及時得到回複的。
目前社群活躍度太低，發展狀況還是不錯的，一直再更新，不斷會有其他業餘的加入。前景個人感覺還是良好的，是死是活還要看Tajo的造化了。
根據官方文檔和jira上總結了一下Tajo幾個核心子產品未來的發展規劃（部分屬于個人的一點點看法）：
目前是tajo自開發的catalog管理伺服器，分為catalog client和catalog server兩個子產品。目前支援Derby和MySQL資料存儲，後續會支援對PostgresQL的支援。開發計劃中會将Hive的HCatalog集 成進來，來做Tajo的資料表和存儲管理服務。
Tajo目前是以hdfs作為主要存儲子產品，對于一個資料倉庫系統來說，應該支援各種各樣的存儲資料源，下一個開發計劃會支援HBase和其他的資料源。
Tajo自己開發的SQL執行引擎包括SQL解析成抽象文法樹（AntLR 4）、生成執行計劃、執行計劃的優化器、代價評估等子產品。目前支援絕大部分的SQL92的操作，以後會考慮Tenzing的實作方案，支援更多的資料源。
目前的版本沒有對表做partition，後續會參照hive的方式對表進行分區分表。
本文轉自二郎三郎部落格園部落格，原文連結：http://www.cnblogs.com/haore147/p/5105252.html，如需轉載請自行聯系原作者