SQL on Hadoop 的真相(2)

景公發表於2015-05-28

這是一組系列部落格,目的是詳盡介紹 SQL-on-Hadoop 。該系列的第一篇會介紹一些儲存引擎和線上事務處理(簡稱 OLTP )相關話題,這一篇將介紹聯機分析處理(簡稱 OLAP ),第三篇將介紹對 Hadoop 引擎改造以及在相關替代產品中如何選型等話題。

資料處理與聯機分析處理 ( OLAP )

聯機分析處理是那些為了支援商業智慧,報表和資料探勘與探索等業務而開展的工作。這類工作的例子有零售商按地區和季度兩個維度計算門店銷售額,銀行按語言和月份兩個維度計算手機銀行裝機量,裝置製造商定位有哪些零部件的故障率比期望值高,以及醫院研究有哪些事件會引起高危嬰兒緊張等。

如果原始資料來源於 OLTP 系統,典型的做法是將這些資料拷貝到 OLAP 資料庫中,再進行這類“離線”分析任務的處理,這麼做有很多原因,但考慮最多的還是效能因素。

假設一下,如果一個實體店使用他們的事務處理系統來承擔資料分析工作,這種情況下分析師提交的粗暴查詢就可能會實實在在地影響並拉低門店對於那些已經記錄在冊等待結算的訂單結算率。另外用於事務中的查詢型別從根本上就不同於資料分析類查詢。

事務系統典型的查詢是基於某個獨立的實體,比如某一個客戶或某一個使用者。例如當一個線上零售網站建立一個交易訂單狀態頁時,資料的查詢是針對某一個客戶已經提交的特定訂單。然而在資料分析的用例中,分析師最感興趣的卻是那些根據時間維度劃分查詢本身已跨越了訂單或使用者資料的彙總資訊。就如前面提到的那樣,根據區域和季度兩個維度統計的門店銷售額會查詢給定時間段內所有訂單資料。

行動之前還有最後一個注意要點,本篇中的資料庫並不提供傳統關係型資料庫使用者所期望的那類增刪改操作。與事務系統不同的是,分析型別的查詢主要是那些涉及到數百萬甚至數億行資料的 SELECT 查詢。分析型資料庫的優化也主要圍繞著這類負載進行,而這些優化措施卻會導致針對小批量資料的增刪改操作執行起來代價昂貴。

即便這類資料庫在介面和語義方面都與關係型資料庫不同,但他們也確實提供了增加行 ( INSERT ),更新行( UPDATE )和刪除行( DELETE )操作的功能支援。有些讀者或許正在問 Hive 系統裡最近新增加的 “ ACID ” 相關的問題,容後詳稟。

在 Hive 系統的 “ACID” 功能之外,處理更新操作有兩種方式可選,一種是使用資料所在的 HBase 系統本身提供的更新功能。儘管 HBase 經常主要用於 OLTP 業務,但有些 OLAP 系統會使用 HBase 來儲存一些小表,典型的稱為維度表,這類表需要週期性地更新。第二種處理更新操作的方式是執行一次合併操作。

從一個 ETL 開發者角度出發,一個合併過程會引入額外工作量。因此有個問題一定會被問到,那就是既然 HBase 系統已經提供了更新功能,那這類合併工作就不是必須的,那為什麼不直接都用 HBase 呢?原因是掃描查詢的處理效能,如果要在基於尾部追加模式的 HDFS 檔案系統提供隨機更新的功能,HBase 就得在它讀取每一行時都做少量的合併操作,這個架構決定了能提供較高的寫和隨機讀效能,但與 HDFS 相比,只能提供較差的掃描查詢和順序讀操作效能。這樣一來 HBase 就只能用於儲存那些需要頻繁更新的小表場合;

這個領域包含幾個子目錄:

  • Apache Hive
  • Dremel clones
  • Spark SQL

Apache Hive

本專案最初由臉譜公司建立,Hive 是第一個基於 Hadoop 之上的 SQL 引擎,且至今仍是最成熟的。Hive 原先是構建在MapReduce之上的,也曾經被改造過以便執行在 Apache Tez 上,現在正在進行的是為適應 Apache Spark 而進行的改造,基於 Spark 的Hive 改造被稱為是最後的工作,但不能與 Spark 專案上的其他 SQL 支援專案相互混淆,關於 Spark 上的其他 SQL 支援專案我會再找個合適時機進行討論。

到目前為止,Hive 擁有最完整的 SQL 功能支援,並且也是擁有最多貢獻者的專案,幾乎所有的 Hadoop 使用者都會部署Hive,同時幾乎 Hadoop 上其他 SQL 引擎使用者也都會部署 Hive ,事實上大多數 SQL 引擎都以這種或那種方式依賴於Hive 。

大多數 Hadoop 贊助商,包括 Cloudera 和 Hortonworks,都一致認同 Hive 是唯一有能力處理大批量任務和整合多種非標準資料格式的元件。Hortonworks 與 Cloudera 意見相左的地方在於對 Hive 的效能評價,Clourdera 覺得 Hive 的效能簡直不能與 Dremel clones 相比,而 Hortonworks 則覺得 Hive 可以和 Dremel Clones 一較高下。

Dremel Clones

就像開源界一樣,谷歌內部也創立了多個 SQL 引擎,他們有一個類似於 Hive 的 SQL 引擎叫 Tenzing,還有另外一個系統叫 Dremel。Hive 的創立者 Facebook 公司也建立了一個 Dremel 的克隆版本叫 Presto。

Cloudera Impala 和 Apache Drill 是最傑出的兩個 Dremel 克隆版本,Cloudera 將 Impala 市場定位為最成熟的開源 Dremel 分支,Impala 在2013年年中釋出 GA 版本,MapR 是 Drill 背後的主要贊助商,他把 Drill 的市場角色定位為最靈活的 Dremel 分支, Impala 能滿足在 Hive 系統中儲存後設資料表的需求,而 Drill 可以直接查詢 JSON 和自定義格式檔案,比如 Apache Parquet 和 Avro 檔案格式等。

Spark SQL

儘管有 Hadoop 上有其他多個 SQL 引擎,但 Spark SQL 卻有著對其感興趣的最廣泛受眾。Spark SQL 是 Spark 引擎上的榜眼,而狀元是 Shark, Shark 因為顧及 Spark SQL 和 Hive on Spark 專案,Shark 目前已經終止開發,與 Shark 專案曾近是加州伯克利大學的一個研究專案不同,Spark SQL 和 Hive on Spark 已經在 Spark 贊助商們的支援下建立了各自的開源專案;

基於 Spark 的 Hive 可以簡單地說成是前端是 Hive 後端是 Spark ,基於 MR 或 Tez 的 Hive 既有使用者可以在原系統與 Hive on Spark 系統之間輕鬆切換,切換工作僅僅只需要簡單地修改下配置引數。

Spark SQL 是一個完整的新引擎,今天的 Spark SQL 對那些希望把 SQL 嵌入到他們的 Scala,Java 或者 Python 程式的Spark 開發者而言是最有用的,但 Spark SQL 的主要贊助商 Databricks 對 Spark SQL 還有著更大的雄心,並指望將 Spark SQL 的使用範圍擴充套件到非 Spark 開發者中去;

相關文章