上一篇Tajo--一個分布式數據倉庫系統（概述）廢話了一通，下面介紹一下Tajo的體系結構、以及官方的實驗成果吧
一、體系架構
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 系統
目前還沒有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
目前的版本沒有對表做partition，后續會參照hive的方式對表進行分區分表。