鄭昀 創建於2014/10/30 最後更新於2014/10/31
一）選型：Shib+Presto
應用場景：即席查詢（Ad-hoc Query）
1.1.即席查詢的目標
使用者是產品/運營/銷售運營的數據分析師；要求數據分析師掌握查詢SQL查詢腳本編寫技巧，掌握不同業務的數據存儲在不同的數據集市裏；不管他們的計算任務是提交給 數據庫 還是 Hadoop，計算時間都可能會很長，不可能在線等待；所以，使用者提交了一個計算任務（PIG/SQL/Hive SQL），控制檯告知任務已排隊，給出大致的計算時間等友情提示， 這些作業的權重較低，使用者和管理員可以查看排隊中的計算任務，包括已執行任務的執行時間、運行時長和運行結果；當計算任務有結果後，控制檯界面有通知提示，或者發郵件提示，使用者可以在線查看和下載數據。
1.2.即席查詢的當下技術選型
圖形交互界面：Shib；
數據查詢引擎：Facebook Presto。
1.3.爲什麼要更換數據查詢引擎？
基於 MapReduce 的 Hadoop 適合數據批處理，但不適合即席查詢場景。基於 InnoDB/MyISAM 存儲引擎的 MySQL 自然也不適合。當然我們也觀察過 InfiniDB/InfoBright 這種列式存儲數據庫引擎（仍基於MySQL），它們更適合基本不再變更的歷史 歸檔數據，所以不太適合電商應用場景。
我們的鷹眼（Tracing）項目就曾折翼在即時查詢上，後端的 HBase 扛不住在大數據量下的實時插入和查詢。
『Hive 更適合於長時間的批處理查詢分析，Impala、Shark、Stinger和Presto 適用於實時交互式SQL查詢，它們給數據分析師提供了快速實驗、驗證想法的大數據分析工具。所以可以先使用 Hive 進行數據轉換處理，之後使用這四個系統中的一個在 Hive 處理後的結果數據集上進行快速的數據分析。
Impala、Shark、Stinger和Presto四個系統都是類SQL實時大數據查詢分析引擎，但是它們的技術側重點完全不同。而且它們也不是爲了替換Hive而生，Hive 在做數據倉庫時是非常有價值的。這四個系統與Hive都是構建在Hadoop之上的數據查詢工具，各有不同的側重適應 面，但從客戶端使用來看它們與Hive有很多的共同之處，如數據表元數據、Thrift接口、ODBC/JDBC驅動、SQL語法、靈活的文件格式、存儲 資源池等。』——《開源大數據查詢分析引擎現狀，2014》
最終我們選擇了 Presto。
FaceBook於2013年11月份開源了Presto，一個分佈式SQL查詢引擎，它被設計爲用來專門進行高速、實時的數據分析。它支持標準的ANSI SQL，包括複雜查詢、聚合（aggregation）、連接（join）和窗口函數（window functions)。Presto設計了一個簡單的數據存儲的抽象層，來滿足在不同數據存儲系統（包括HBase、HDFS、Scribe等）之上都可以使用SQL進行查詢。
Presto 簡化的架構如下圖1所示，客戶端將 SQL 查詢發送到 Presto 的協調器。協調器會進行語法檢查、分析和規劃查詢計劃。調度器將執行的管道組合在一起，將任務分配給那些離數據最近的節點，然後監控執行過程。客戶端從輸 出段中將數據取出，這些數據是從更底層的處理段中依次取出的。
Presto 的運行模型與 Hive 有着本質的區別。Hive 將查詢翻譯成多階段的 Map-Reduce 任務，一個接着一個地運行。 每一個任務從磁盤上讀取輸入數據並且將中間結果輸出到磁盤上。然 而 Presto 引擎沒有使用 Map-Reduce。它使用了一個定製的查詢執行引擎和響應操作符來支持SQL的語法。除了改進的調度算法之外，所有的數據處理都是在內存中進行的。不 同的處理端通過網絡組成處理的流水線。這樣會避免不必要的磁盤讀寫和額外的延遲。這種流水線式的執行模型會在同一時間運行多個數據處理段，一旦數據可用的 時候就會將數據從一個處理段傳入到下一個處理段。
這樣的方式會大大的減少各種查詢的端到端響應時間。
同時，Presto 設計了一個簡單的數據存儲抽象層，來滿足在不同數據存儲系統之上都可以使用 SQL 進行查詢。存儲連接器目前支持除 Hive/HDFS 外，還支持 HBase、Scribe 和定製開發的系統。
圖1. Presto架構
1.4.在HUE和Shib之間選擇了後者
HUE 大家可能都聽說過。Shib 相對陌生一些，它是這麼介紹自己的：WebUI for query engines: Hive and Presto。
潘高鋒介紹了二者的優缺點。
HUE
開發語言：Python
優 點：Hue 是一個能夠與 Apache Hadoop 交互的 Web 應用程序。一個開源的 Apache Hadoop UI。我們已經在生產環境使用Hue了，而且Hue在管理Hbase/Pig/Hive方面有很大的優勢，它還附帶了一個Oozie的應用程序，用於創建 和監控工作流程 。
缺點：Hue 是一個比較重的工具，改動起來涉及的東西會比較多，而且以後每次升級都可能會導致我們改動的功能要再修改 。
Shib
開發語言：Nodejs
優點：Shib 通過簡單的配置就可以直接操作 hive 和 presto。代碼量比較小，修改起來工作量少很多 。
缺點：對 Nodejs 不熟悉，有學習成本 。
最後我們選定了代碼量和開發量相對較少的 Shib 。
1.5.即席查詢的界面展示
登錄 shib 後，選擇數據倉庫 presto-wowo_dw。編寫 sql 的時候，可以把表結構的提示框移到一邊，邊寫邊參照，如下圖所示。
圖2 邊查詢邊看數據結構
由於所有的查詢都是異步的，所以可以在“我的查詢”列表中看到自己的查詢語句的執行狀態和執行結果，這樣不用自己在一直在查詢界面等待了，如下圖所示。
圖3 我的查詢
還可以把自己常用的查詢語句保存到“書籤”裏，這是一個很實用的功能。
接下來就可以開發SQL查詢結果站內通知機制以及更復雜的用戶訪問權限控制機制了。
二）選型：HUE+Oozie
應用場景：Hadoop集羣計算任務調度和管理平臺。
2.1.數據平臺跑數據所面對的困難
電商數據平臺的報表維度有很多種，有總體簡報角度、運營角度、媒體投放角度等，也可以有商品、商戶、用戶、競品等維度，還有日報、週報和月報之分。所以對 應了很多個計算任務。每一個計算任務可以視爲一個工作流，畢竟計算過程是很複雜的、一環套一環。那麼 HUE+Oozie 就是可視化管理和調度這些工作流的。
沒有 Oozie 之前是什麼樣？
一，計算腳本被配置爲定時任務，跑飛了只能從海量日誌中大海撈針，不知道斷在哪兒，只能手動清數據從頭再跑。任務計算時間特別長，不知道當前跑到哪一步了，還需要多久能跑完。
二，難以精確控制任務A跑完了才能跑任務B，只能在不同定時任務之間留足夠長的時間間隔，缺乏彈性。
2.2.Oozie是什麼
Oozie是一種 Java Web 應用程序，它運行在 Tomcat 中，並使用數據庫來存儲以下內容：工作流定義、當前運行的工作流實例(包括實例的狀態和變量)。
我們最欣賞它的三點：
- Oozie允許失敗的工作流從任意點重新運行，這對於處理工作流中由於前一個耗時活動而出現瞬態錯誤的情況非常有用。
- 工作流執行過程可視化。
- 工作流的每一步的日誌、錯誤信息都可以點擊查看，並實時滾動，便於排查問題。
2.3.還是看截圖吧
先選擇HUE導航欄上的“Oozie Editor/Dashboard”，看到默認面板：
圖5 oozie默認面板
點擊某個工作流，進入詳情頁：
圖6 工作流詳情頁
一個工作流的定義如下圖7所示，XML格式的 hPDL。hPDL是一種很簡潔的語言，只會使用少數流程控制和動作節點。控制節點會定義執行的流程，幷包含工作流的起點和終點（start、end和 fail節點）以及控制工作流執行路徑的機制（decision、fork和join節點）。
圖7 工作流定義
現在，數據平臺的各種計算任務都遷移到 Oozie 中，按照 hPDL 語言格式一一重新定義。
三）總結一下數據中心的各種技術選型
羅列如下，不再解釋：
Apache Hadoop/Hive/HBase
Apache Pig
Flume/Kafka/Storm/Sqoop/awk
Facebook Presto
MySQL
HUE/Shib
Oozie
-over-