#數據技術選型#即席查詢Shib+Presto，集羣任務調度HUE+Oozie

鄭昀 建立於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-