參加人數: 約100人以上
心得一: 關貿團隊分享Impala使用經驗
- 簡報提到Impala有個metadata模組, 可以讓impalad直接存取node OS的file system block?! 個人是認為應該是Hive metastore的Table/SerDe Location mapping資訊預先暫存在impalad, 省去query execution time訪問Hive MetaStore Server的動作, 存取資料時還是由impalad向NN取得HDFS block location, 再向DN發出short circuit read請求直接讀取OS file內容, 也就是說Impala底層還是需要像HDFS/HBase的分散式儲存服務, 而不是直接存取cluster node的OS file system.
- 安全性問題: 與關貿團隊, Jazz, Takeshi討論後覺得Kerberos的導入/建置/維運/整合仍然是管理者的挑戰. 其實在一份由Cloudera 工程師 Patrick Angeles在2014/02發表的簡報就提到這個觀點(Security Configuration is a PITA, Do only what you really need). 目前我是這麼認為的: 如果你是在一個安全的環境(公司內部), 其實有很多手法都可以保證Hadoop叢集的安全; 若是在一個公開的環境(EC2/hicloud), 或許Kerberos就成為一個不得不採取的手法. 但是Kerberos的目的是確保Hadoop叢集內部節點間的安全, 若是要與外部系統整合的話應該還有其他方式, 像Hortonwork就提出Knox專案, 而Cloudera在Hue就區分為用戶身分鑑別(in-DB或LDAP)與叢集節點身分鑑別(Kerberos)兩種模式. 目前看到像是Hive(Using LDAP Authentication with HS2), Impala(LDAP username/password authentication in JDBC/ODBC), 甚至像是Oozie(Enabling Your AltKerberosAuthenticationHandler Subclass on Oozie Web UI)都可能採用LDAP當作前端用戶身分鑑別機制.
- Parquet檔案格式: 優點很多, 但是需要付出成本: 轉換原始來源檔案. 第一直覺是採用Impala, 如果轉檔動作是Daily-based的話應該就沒問題, 白日高峰期間Impala提供查詢, 夜晚離峰時間Impala執行轉檔. 但是如果資料匯入頻率是hourly-based呢? 個人認為Impala的Scheduling機制應該沒做到很複雜, 所以Impala在進行轉檔時就有可能影響查詢的SLA. 這個時候Hive就派上用場, 只要作一些設定就可以讓Hive將原始檔案轉成Parquet格式. 這樣只需配置部分的資源給Hive+MR進行ETL轉換, 而Impala仍可支持Interactive query.
- 記憶體限制: 到底Impala的記憶體限制是什麼呢? 根據Cloudera簡報說明: Impala does not “spill” to disk -- pipelines are in-memory; Operators’ mem usage need to fit within the memory limit. 所以要取決於每個impalad在執行該operator時所需的記憶體容量, 官方是建議每個node配128GB, 不過這可能不是一般企業能玩得起的, 所以還是回到個人的觀點: 現階段Hive與Impala應該是處於互補態勢. 不過如何讓前端工具能夠無縫整合使用Hive/Impala, 那可能就需要一套DAL Middleware來幫忙了. 淘寶有套TDDL就是提供類似的功能, 而中移動大雲的HugeTable則是這個概念的實作.
心得二: 亦思科技HareDB: SQL on HBase
- 能夠發現台灣公司能夠投注這麼多人力與資源在Hadoop相關專案, 真的是讓人很感動的 事情. 雖然如此個人還是會從商業利益的角度來探討HareDB的產品定位. 就目前看來支援SQL query仍是HareDB的最重要/主要的功能, 而這個功能其實正是目前國際大廠戰火最激烈的區塊. HareDB能夠在眾多解決方案中脫穎而出, 還是要走利基市場, 發展獨特且無法取代功能與產品?
- 由於HBase有著single-row transaction的限制, 如果有一套產品能夠支援Transaction block on HBase(cross tables/rows), 而用Impala來支持Real-time query/join/aggregation, 那就真的是太棒了. 不過這真的不是一件容易的事情, so當做作是異想天開吧 !
心得三: 趨勢科技Network Traffic Search using Apache HBase
- 使用Flume收集rsyslog的過程中, Evans的作法是先setup一台rsyslog server收集所有log存在本機端磁碟目錄, 然後透過rotate方式將log file移至另一個目錄, 然後經由Spooling Directory Source機制由Flume agent將資料向後傳送.
- 傳送過程為確保穩定性, 採用file channel.
- 由於raw data最終需存入兩個HBase Table(為優化查詢rowkey值並不同), 因此會有兩個Channel/Sink. 這樣會衍生寫入資料一致性的問題, 未來規劃採用Coprocessor來解決. 個人是想像可能作法是: 寫入Table A時使用prePut將資料寫入Table B, 若B成功則繼續寫入A, 若B失敗則取消寫入A.
心得四: Tez的前景
- 根據Takeshi的說法, Tez相對於Impala擁有以下幾個優勢
- Tez是DAG執行框架, 因此相較Impala有更多的應用. 例如Tez可以執行既有的Pig程式
- Tez耗用資源比Impala較少(尤其是記憶體), 這對企業而言應該是蠻重要的考量
- 個人也是蠻支援上述兩個觀點, 不過覺得還是有幾個需要觀察的地方
- 記憶體管理: Impala最讓人頭痛的地方就是不支援spill, 個人覺得Tez應該會支援這個部分, 畢竟MR1已有這個功能, 差別只是在於實際運作的效率. 但是在MR1如果programmer的程式本身沒有寫好仍會拋出OOME! 相較之下我是比較喜歡Spark RDD, 讓框架來進行large dataset的管理與操作.
- 最佳化引擎: 如果順利的話Pig/Hive的code應該可以在Tez執行, 不過我覺得Optimization部分應該還是需要改寫. 舉例來說Hive的Shuffle/Broadcast/Short-Merge Bucket Join算法在MR1實作應該是需要進行不少的修改, 才能充分發揮Tez的優點吧!
- 穩定性: 畢竟Tez釋出才不到半年, 應該也沒有實際上線系統.
- 綜合以上觀點, 個人覺得Tez應該還是列在待觀察名單, 自己應該還是按照既定規劃繼續K "Pragrammin in Scala", 並開始找環境實際操作Spark Example.
