數據引擎查詢原理及應用

極牛技術實踐分享活動
極牛技術實踐分享系列活動是極牛聯合頂級VC、技術專家，爲企業、技術人提供的一種系統的線上技術分享活動。
每期不一樣的技術主題，和行業專家深度探討，專一解決技術實踐難點，推進技術創新，每週三20點正式開課。歡迎各個機構、企業、行業專家、技術人報名參加。

嘉賓介紹
付力力，前百度大數據部資深工程師，神策數據聯合創始人&架構師，熟悉海量數據處理、數據倉庫、大規模OLAP分析等領域。

基本概念

數據查詢引擎是大數據處理架構的核心組件之一，一般是面向數據應用層的直接接口。下面是一個比較典型的數據金字塔的架構圖：

數據查詢引擎並無嚴格的定義，不過通常來講一個典型的數據查詢引擎都會有如下幾個特色：

1) 能夠訪問結構化數據
2) 提供 SQL 或者類 SQL 的查詢接口
3） 返回結構化的查詢結果

不過雖然都叫查詢引擎，不一樣查詢引擎的特性倒是千差萬別的，各自適用的場景也不太同樣。

這個圖是一個比較典型的用戶行爲分析場景下使用查詢引擎的架構圖

通常咱們會從如下幾個指標來評價一個查詢引擎的特徵和它適用的場景。

1) 可擴展性：是單機仍是分佈式？
2) 支持的數據量級：支持幾個 GB，仍是數百 TB？
3) 支持的數據格式：要求特定格式，仍是能夠適應各類格式？
4) 響應時間：毫秒？秒級？分鐘？
5) 查詢能力：徹底 SQL 支持？仍是部分支持？或者是徹底不支持？

可是基本上不存在一個查詢引擎能在以上全部的指標上都作到最好，通常仍是須要根據具體的需求來選擇。

一般來講，使用查詢引擎的應用場景主要有如下兩個大的類別：

第一類是數據處理類應用。

好比對數據進行格式轉換、按條件抽取數據、作各類數據預處理等。對於這類應用來講，輸出的數據量可能和輸入是同等數量級，甚至更大；而且運行的時間也比較長，例如在小時級甚至天級。

第二類是統計分析類，好比計算網站/App 的訪問量、留存率等等。

這類應用輸出的結果每每是須要直接展現給終端用戶看的，因此一般都比較小，通常在 MB 或者 KB 級別，多數時候可能就是幾個數字。並且此類應用一般都要求交互式響應，好比在幾秒或者最多幾分鐘就返回查詢結果。

因此很是明顯，以上兩大類需求點對於查詢引擎的要求實際上是很不同的。在實際使用上，咱們須要根據更加具體的應用場景來選擇合適的數據查詢引擎。

主流查詢引擎的特色和比較

01 | Hive

首先來看看 Hive，Hive 出現的時間比較早，應該是目前使用範圍最廣的數據查詢引擎之一了。Hive 最大的特色是靈活性：它支持標準的 SQL、支持多種數據格式（文本、ORCFile、Parquet）、支持多種存儲引擎（HDFS/HBase）等等，甚至在執行層面，還支持多種執行引擎（MapReduce/Tez/Spark）。

缺點也很明顯，就是執行性能比較通常。緣由之一是它很難針對各類狀況作針對性的優化。

可是 Hive 能夠說是一個比較純粹的查詢引擎，它自己不包含執行層和存儲層，因此具備很高的適應性，能夠在各類環境下運行。因此 Hive 一般適合數據處理類的應用，好比最多見的是作一些ETL。一樣是作ETL，相比寫MapReduce或者Spark會簡單不少。並且由於執行依然是MapReduce等引擎，因此穩定性也比較好，適合長時間運行。可是對於交互式的分析就不太合適，好比一個簡單的COUNT(*)可能要執行數分鐘。

02 | Impala

接下來咱們看看 Impala，這也是一個出現頻率比較高的查詢引擎。

這個是Impala的架構圖，能夠看到Impala是對Hive有一些模塊上的依賴，它複用了Hive的元數據。

簡單的說，就是能夠直接查詢Hive裏的表。它在查詢功能上的支持和 Hive 比較相似，包括對各類SQL語法的支持。不過 Impala 最大的特色是有本身的 MPP 架構的執行層，而不是依賴於 MapReduce或者Spark之類的，因此查詢性能比Hive要高不少。固然，Impala 對資源，尤爲是內存的需求也比較高。並且它的容錯性不如 Hive，使用不當的話很容易掛掉。準確的說是容錯性不如 MapReduce/Spark，好比容易超內存。因此對於長時間的查詢是不太合適的，好比不適合用來作ETL。極可能一個查詢跑了一個小時，而後最後關頭掛掉了，又得從頭開始執行。可是它很是適合統計分析類的應用，能夠作到秒級響應。尤爲是配合Parquet的列式存儲，能夠達到很高的查詢性能。

總結一下，Impala和Hive的區別主要是在於執行層，所以也形成了它們兩個應用場景上的差別。

還有一個 Presto，Facebook開源的。由於它在總體架構、思路都和 Impala 比較像，這裏就再也不細說。

03 | Spark SQL

接下來，咱們再看一下最近比較火的 Spark SQL。

Spark SQL是Spark生態的一部分，它最大的特色是基於 Spark的引擎來執行，也所以能夠和 Spark 的其它計算方式無縫融合。它也複用了Hive的元數據、UDF之類的資源。

Spark SQL最大的特色是能夠在原有的Spark代碼裏使用SQL來進行中間數據的處理，不少時候能夠簡化複雜的數據處理流。

Spark SQL 的適用範圍相對比較廣。數據處理類確定是它的強項，而它在查詢響應時間上也比 Hive 要強很多，某些場景下也接近Impala，所以也能夠用於某些在線分析的場合。

它如今的主要缺點是成熟度通常，不過最近發展很快。Spark SQL對內存的消耗也相對會比較大，相比Hive。Impala/Spark SQL都兼容和複用了Hive的一部分組件。這個緣由之一也是由於Hive推出時間早、使用範圍廣，因此兼容Hive能夠很大程度上下降使用門檻。

04 | Druid

而後再看看 Druid，這也是最近很火的一個開源組件。

準確的說 Druid 並非一個查詢引擎，它是一個完整的數據庫，包含了查詢引擎。不過 Druid 並不支持 SQL，而是使用了 JSON 來進行查詢描述，暫時也不支持複雜的 JOIN 類的查詢。可是，Druid 經過預聚合和索引提供了高 QPS、低延時的查詢能力，很是適合在線報表類的應用。

這是Druid的數據流圖，能夠看到Druid並不依賴Hive或者HDFS，而是有本身的查詢引擎和存儲引擎，也不像Hive/Impala之類的支持多種數據格式，而是必須導入轉換爲它本身的存儲格式。

和 Druid 相似的產品還有Pinot，可是成熟度和流行成都目前都不如 Druid。這裏也再也不細講。

上面就是幾個我比較瞭解的主流查詢引擎的簡單介紹。能夠看到，不一樣查詢引擎的架構、指標特性都有很大的區別。

典型場景應用

接下來咱們再來看看在幾種典型的應用場景下，應該選用什麼樣的數據查詢引擎。

場景一：假設有一個小規模的數據應用，整體數據量在幾十GB或者更低。

在這種場景下，咱們不太建議用任何複雜的開源方案，而是直接使用成熟的分析型數據庫，例如 Vertica、Greeplum、Redshift 等等等等。這些數據庫無論在功能的完善程度、系統的穩定性，仍是在查詢優化上都已經作的很是好了，不須要從頭開始踩坑。固然它們的主要缺點是須要先進行 ETL 入庫，也就是須要導入數據，這個可能會消耗一些資源和時間。可是若是數據量不大，這一點也徹底不是問題，並且導入以後會更方便管理。好比能夠任意的增刪改查。固然，使用這類數據庫在規模大了以後，擴展性和成本上會出現比較多的問題，所以通常只適合小規模的應用。

場景二：假設是一個典型的大規模數據倉庫，數據量可能在幾十TB或者更大，數據源也是很是多樣化，可能有各類不一樣格式的文本數據，也有各類二進制數據。

由於數據源的多樣性，對於數據的需求也會是很是多樣化的，好比即有數據預處理，也有統計分析或者更進一步的數據挖掘需求。並且不一樣數據之間還須要很是方便的互相引用。

通常來講，在這樣一個大規模數據量的場景下，首先須要儘可能避免的就是ETL的成本。好比咱們不能由於要進行一次偶然的數據查詢，就須要把數百 TB 的數據進行一次高成本的 ETL，這個資源消耗是很是大的，而是但願想查的時候隨時能夠直接查。爲了解決這個問題，首先咱們可使用 HDFS 來進行統一的數據存儲，先解決存儲層的問題，這樣不管是什麼數據均可以直接訪問到。而後再配合 Hive 或 SparkSQL 解決數據處理類應用的問題，對於統計分析類應用，則可使用 Impala 或 Presto 解決。主要是由於這裏提到的幾個查詢引擎均可以很好的支持 HDFS 上的多種數據格式，能夠很好的避免沒必要要的數據遷移和 ETL 開銷。並且，這些數據也能夠很容易的和MapReduce、Spark之類的計算進行進一步的融合，具備很高的靈活性，而不僅是侷限在某個具體的數據存儲裏。

場景三：咱們來看看比較典型的用戶行爲分析類型的應用。

這類應用的特色是：要分析的數據裏包含時間維度、而且有可能有額外的數百個不一樣的維度，並且對於分析靈活性的要求很高，同時查詢的模式也並不固定。

好比這是一個典型的用戶行爲分析的數據表，每一行表明一個用戶的行爲。

這類應用要求單次分析的響應時間不能太長，否則無法作到交互式的分析體驗。因此，使用 Impala/Presto 是比較合適的，由於它們即有比較高的查詢性能，又支持包括 JOIN 在內的各類複雜查詢，同時配合列存還能最大程度的減小 IO 開銷。

不過，對於大時間跨度的複雜查詢，可能仍是會存在查詢時間較長的問題。這種時候通常能夠經過預聚合、抽樣等手段來進行進一步的優化。並且分析類的應用對於響應時間並無那麼敏感，一個複雜的查詢跑幾分鐘仍是能夠接受的。

場景四：運維監控類/廣告統計類的需求。

這類應用和用戶行爲分析類有點相似，可是最大的區別是，它們在維度和查詢模式上都一般比較固定，好比都是按小時/天/月來聚合查看各類監控指標的曲線。

可是對查詢頻率和響應時間的要求則比較高，通常都須要秒級。這種場景下，使用 Druid 這種能夠預聚合的查詢引擎是比較合適的。通過預聚合以後，100G的數據可能只有1G或者更小，在進行比較粗粒度（例如按天）的查詢時，能夠達到很是高的性能。

經常使用優化方案

首先是數據預聚合，前面也屢次提到過。這是一種很是常見的優化手段，能夠有效的減小查詢掃描的數據量。

雖然 Druid 是內置直接支持預聚合，可是不表明其它查詢引擎不能使用預聚合。不過預聚合是須要在消耗額外的計算資源的，同時也可能還會帶來更大的維護成本。任何查詢引擎均可以使用預聚合的方案來優化性能，不過如何合理的建立、選擇和使用聚合表，仍是比較困難的。若是用很差極可能起到副作用。

另一種常見的優化手段是進行數據抽樣。

也就是以犧牲必定的數據準確性的方式來減小對資源的消耗，同時優化查詢的響應時間。數據抽樣在數據量很是大的時候是很划算的一種作法，尤爲是在目前存儲資源很便宜、計算比較昂貴的狀況下。可是具體如何進行數據抽樣一般仍是由業務決定，不能一律而論。好比通常作用戶行爲分析就按用戶ID來進行抽樣是比較合適的。不過大部分查詢引擎並不支持原生的抽樣功能。若是想要實現準確、快速的數據抽樣，一般須要存儲端的配合，可能須要進行深度的定製修改。

最後是數據索引的優化，這個是傳統數據庫的常見優化手段，不過在大數據查詢引擎裏也可使用的。

使用索引能夠實現針對某些維度的快速篩選，固然同時也會帶來的額外的計算和存儲成本，並且不是任何查詢模式都能命中索引，一般只是針對特定業務需求的優化。不少優化手段可能須要對查詢引擎自己作改動才能實現的，這個時候使用開源組件就會體現出比較大的優點。

Q&A：

Q1：瞭解數據查詢引擎的工做原理對咱們的業務能夠有什麼幫助？
A1：主要是在面對不一樣需求的時候應該如何選擇合適的查詢引擎來做爲技術選型，好比作網站流量分析、廣告統計、運維分析等等。

Q2：大家的產品Sensors Data用了什麼數據查詢引擎，和Google Analytics、Mixpanel的方案有什麼差別嗎，爲何？
A2：Sensors Data主要是用了Impala，不過單機版也支持其它的查詢引擎。GA的實時計算報表部分應該用的他們內部的引擎（和對外的big query是一套架構）。Sensors Analytics和Mixpanel總體架構和思路上應該仍是比較像的，都是以實時分析爲主，不過Mixpanel是純SaaS，具體實現咱們也不清楚。

本次分享來自於極牛技術實踐分享系列活動。 更多技術乾貨關注微信公衆號「極牛」。