以下是我在2017 ES 廣州 meetup的分享

ppt：https://elasticsearch.cn/slides/11#page=22

摘要

ES最多使用的場景是搜索和日誌分析，然而ES強大的實時索引查詢、全文檢索和聚合能力也能成為數據倉庫與OLAP場景的強力支持。本次分享將為大家帶來數說故事如何借助ES和Hadoop生態在不同的數據場景下構建起數據倉庫能力。

背景

數說故事主要業務為數據商業智能分析，涉及業務包括數字營銷、數據分析洞察、消費者連接，同時我們還擁有自己的數據源。

目前我們內部有3種主要取數方式，一種是基於HBase的大規模導出，通俗來說就是Scan HBase掃表，一般用來處理需要全表數據做離線處理的需求。第二種是先從ES query出ID，然後再從HBase get數據，這裏ES被當做了HBase的索引層，這種取數方式在我們的業務中用的最多。之所以不從ES取數，一方面是由對ES負擔壓力比較大，另一方面是無法存放較長的字段。第三種與全量數據庫無太多關系，主要涉及業務層面，比如對已有的ES小庫做打標簽或者ETL操作，然後進行轉化寫入另一個庫，類似數據倉庫中將工作表提取出來，然後轉換寫入另一個表。

Gaia

Gaia需要解決的問題主要有四點。

• 一是構建Hive on HBase/ ES/Banyan（對於三種取數模式）的能力，由於Banyan是基於ES索引，所以它在構建時要做的事情與ES差不多。
• 二是對不同存儲的查詢條件優化，在MySQL中使用where條件查詢之所以會很快，是因為MySQL已經幫你建立的索引。對應到NoSQL中其實也是一樣的，如果where條件沒有與索引層建立好關系，select查詢就會觸發全表掃描，造成很大的負擔。
• 三是提供ES特有的查詢支持。
• 四是提供拓展性的SQL表達能力。

StorageHandler

在介紹如何構建Hive on ES/Banyan之前，要先講一下StorageHandler，它是Hive對接外部存儲的核心類，主要功能有三個：InputFormat / OutputFormat（如何讀寫）、MetaHook（如何讀寫Hive元數據）、Predicate Pushdown（下推優化、分解條件）。
這三個功能中InputFormat在做兩件事，首先是InputSplit——按片分割，利用preference制定shard做到並行讀取，第二個是RecordReader——內部先scroll一批數據，然後一直調next到當前數據為空時，scroll新一批數據。

下推優化

StorageHandler的下推優化在數據庫中是一個比較重要的概念，它涉及到了Sargable和謂語下推兩個概念。Sargable的全稱是Search ARGument ABLE，即SQL中可利用數據庫自身索引優勢對查詢條件進行執行性能優化。一般來說可以優化的為SQL中的WHERE條件，ORDER BY , GROUP BY, HAVING 等有時候可Sargable，當然情況並非絕對，主要還是和實際數據庫的支持有關。謂語下推是在實際數據讀取和SQL實際執行之前預先執行條件語句進行預處理和過濾。
接下來所講的就是下推優化的具體實現。
首先從StorageHandler中獲取到ExprNodeDesc結點樹對象，再基於該對象構建通用的結點樹。這一步是可行的過程，一般可以直接基於Hive的原生對象實現，但是我們想要更加定制化的操作以及同時支持HBase和ES不同的存儲，所以還是將它給抽了出來。
第二步是自頂向下查詢可優化的操作符並進行優化，數據存儲的時候已經預先定義好了可優化的操作符。在遇到不可優化的操作符時，會出現兩種情況。如果邏輯連接符是AND則跳過當前節點並繼續優化兄弟節點，若果是OR則放棄優化。
最後一步是將可優化的結點樹轉為存儲可支持的查詢條件（ES Query、HBase Filter等）。
（Hive的源碼對象）
在有了構建能力之後，還需要支持ES特有的查詢。之所以要怎麽做，是由於像es_match、es_matchphrase之類的，如果是在ES的場景下很好實現，但是要用代碼實現不僅麻煩而且性能很低。最後我們經過考慮，決定對他們的支持不做具體實現，只是返return true，只用來做下推查詢。

ES自動建表

在有很多小表的情況下，如果用戶借助數參建表，每次需要使用create table還要寫入眾多字段。數據和mapping都在的情況下，還要使用這種方式實在是過於繁瑣。所以我們給Gaia新增了一個新的特性——ES自動建表，只需要指定es.nodes和es.resource，就可以讀取mapping以及數據抽樣檢查，最後生成完整的create table語句。它的實現是基於SemanticAnalyzerHook 攔截 ASTNode語法樹，再讀取ES mapping，重寫 CREATE 語句。

Gaia-優勢

從業務層面來看Gaia減少了寫代碼的開銷和出錯率，是更友好的篩選取數工具，同時也為後續的數據分析提供了基礎。對平臺方來說最重要的是有統一管控計算資源以及審計的能力。

Cube

數說立方(Cube) 是數說故事自研的基於ES的OLAP產品，可提供非技術人員自由的導入數據、維度透視、統計分析等功能。
ES為Cube提供了幾點優勢。一是即席查詢，可以實時查詢且靈活度高，只需要索引字段而不用預計算出維度表。二是占用空間小，由於使用ES索引代替維度表，所以空間的開銷得以減小。三是全文檢索支持，lucene支持。

ES相關技術點

這裏先講下使用Es-hadoop過程中的一些經驗。

• 建議使用lasted stable的es-hadoop版本，因為舊版本還是有些隱性BUG，而新版代碼更加清晰，對舊版也有很好的兼容。
• 使用時註意一些特殊字段(suggest, array,nested等) ，可能會有坑或不兼容等。比如某個舊版本中在識別到suggest後，就不會再去掃描後續字段。

Es-hadoop還支持跨版本ES的讀寫。在ES5的時候es-rest被獨立出來，用來提供客戶端統一接口讀寫不同版本ES的能力。
Cube通過Schema識別實現了ES表的自動導入，這裏主要遇到的問題是ES的數組字段不易識別，因此我們對導入的庫做了抽樣數據然後進行schema調整。
用戶導入的表可能包含眾多字段，這就出現了一個問題，即什麽樣的數據字段可以成為維度。對此除了在產品層面提供給用戶配置之外，我們還希望能夠進行自動識別。因此用到了Cardinality查詢，識別字段的基數，然後設定閥值過濾。

以上為全部分享內容，謝謝大家

2017 ES GZ Meetup分享：Data Warehouse with ElasticSearch in Datastory