一、OLAP與Impala簡介
1. OLAP簡介
OLAP是Online Analytical Processing的縮寫，意為聯機分析處理。此概念最早是由關系數據庫之父E.F.Codd於1993年提出，至今已有20多年。OLAP允許以一種稱為多維數據集的結構，訪問業務數據源經過聚合和組織整理的後數據。以此為標準，OLAP作為單獨的一類產品同聯機事務處理(OLTP)得以明顯區分。
在計算領域，OLAP是一種快速應答多維分析查詢的方法，也是商業智能的一個組成部分，與之相關的概念還包括數據倉庫、報表系統、數據挖掘等。數據倉庫用於數據的存儲和組織，OLAP集中於數據的分析，數據挖掘則致力於知識的自動發現，報表系統則側重於數據的展現。OLAP從數據倉庫中的集成數據出發，構建面向分析的多維數據模型，再使用多維分析方法從多個不同的視角對多維數據進行分析比較，分析活動以數據驅動。
通過使用OLAP工具，用戶可以從多個視角交互式地分析多維數據。OLAP由三個基本的分析操作構成：合並(上卷)、下鉆和切片。合並是指數據的聚合，即數據可以在一個或多個維度上進行累積和計算。例如，所有的營業部數據被上卷到銷售部門以分析銷售趨勢。下鉆是一種由匯總數據向下瀏覽細節數據的技術，比如用戶可以從產品分類的銷售數據下鉆查看單個產品的銷售數據。切片則是這樣一種特性，通過它用戶可以獲取OLAP立方體中的特定數據集合，並從不同的視角觀察這些數據。這些觀察數據的視角又叫做維度(例如通過經銷商、日期、客戶、產品或區域等等，查看同一銷售數據)。
OLAP系統的核心是OLAP立方體(或稱為多維立方體或超立方體)。它由被稱為度量的數值事實組成，這些度量被維度劃分歸類。一個OLAP立方體的例子如下圖所示，數據單元位於立方體的交叉點上，每個數據單元跨越產品、時間、位置等多個維度。通常使用一個矩陣接口操作OLAP立方體，例如電子表格程序的數據透視表，可以按維度分組執行聚合或求平均值等操作。立方體的元數據一般由關系數據庫中的星型模式或雪花模式生成，度量來自事實表的記錄，維度來自維度表。
OLAP分析所需的原始數據量是非常龐大的。一個分析模型，往往會涉及數千萬或數億條數據，甚至更多，而分析模型中包含多個維度數據，這些維度又可以由用戶作任意的組合。這樣的結果就是大量的實時運算導致過長的響應時間。想象一個1000萬條記錄的分析模型，如果一次提取4個維度進行組合分析，每個維度有10個不同的取值，理論上的運算次數將達到10的12次方。這樣的運算量將導致數十分鐘乃至更長的等待時間。如果用戶對維組合次序進行調整，或增加、或減少某些維度的話，又將是一個重新的計算過程。
從上面的分析中可以得出結論，如果不能解決OLAP運算效率問題的話，OLAP將只會是一個沒有實用價值的概念。在OLAP的發展歷史中，常見的解決方案是用多維數據庫代替關系數據庫設計，將數據根據維度進行最大限度的聚合運算，運算中會考慮到各種維度組合情況，運算結果將生成一個數據立方體，並保存在磁盤上。用這種以空間換時間的預運算方式提高OLAP的速度。那麽，在大數據流行的今天，又有什麽產品可以解決OLAP的效率問題呢?且看Hadoop生態圈中適合做OLAP的組件——Impala。
2. Impala簡介
(1)Impala什麽是
Impala是一個運行在Hadoop之上的大規模並行處理(MPP)查詢引擎，提供對Hadoop集群數據的高性能、低延遲的SQL查詢，使用HDFS作為底層存儲。它是基於Google Dremel的開源實現。對查詢的快速響應使交互式查詢和對分析查詢的調優成為可能，而這些在針對處理長時間批處理作業的SQL-on-Hadoop傳統技術上是無法完成的。
Impala與Hive元數據存儲數據庫相結合，在這兩個組件之間共享數據庫表，並且Impala與HiveQL的語法兼容。因此既可以使用Impala也可以使用Hive進行建立表、發布查詢、裝載數據等操作。Impala可以在已經存在的Hive表上執行交互式實時查詢。
(2)為什麽要使用Impala
Impala可以使用SQL訪問存儲在Hadoop上的數據，而傳統的MapReduce則需要掌握Java技術。Impala還提供SQL直接訪問HDFS文件系統、HBase數據庫系統或Amazon S3的數據。Impala在Hadoop生態系統之上提供並行處理數據庫技術，允許用戶執行低延遲的交互式查詢。Impala大都能在幾秒或幾分鐘內返回查詢結果，而相同的Hive查詢通常需要幾十分鐘甚至幾小時完成。Impala的實時查詢引擎非常適合對Hadoop文件系統上的數據進行分析式查詢。由於Impala能實時給出查詢結果，使它能夠很好地與Pentaho、Tableau這類報表或可視化工具一起使用(這些工具已經配備了Impala連接器，可以從GUI直接執行可視化查詢)。Impala與Hadoop生態圈相結合，內置對所有Hadoop文件格式(ORC、Parquet等等)的支持。這意味著可以使用Hadoop上的各種解決方案存儲、共享和訪問數據，同時避免了數據豎井，並且降低了數據遷移的成本。Impala缺省使用Parquet文件格式，這種列式存儲對於典型數據倉庫場景下的大查詢是最優的。 Impala之所以使用Parquet文件格式，最初靈感來自於Google 2010年發表的Dremel論文，文中論述了對大規模查詢的優化。Parquet是一種列式存儲，它不像普通數據倉庫那樣水平存儲數據，而是垂直存儲數據。當查詢在數值列上應用聚合函數時，這種存儲方式將帶來巨大的性能提升。原因是只需要讀取文件中該列的數據，而不是像Hive需要讀取整個數據集。Parquet文件格式支持高效的壓縮編碼方式(例如Hadoop和Hive缺省使用的snappy壓縮)，Parquet文件也可用Hive和Pig處理。
(3)適合Impala的使用場景
需要低延遲得到查詢結果。快速分析型查詢。實時查詢。需要多次處理相同類型的查詢。 總而言之，Impala非常適合OLAP類型的查詢需求。
(4)Impala架構
Impala架構圖如下所示。
Impala服務器是一個分布式、大規模並行處理(MPP)數據庫引擎。它由不同的守護進程組成，每種守護進程運行在Hadoop集群中的特定主機上。其中Impalad、Statestored、Catalogd三個守護進程在其架構中扮演主要角色。
Impala守護進程
Impala的核心組件是一個運行在集群中每個數據節點上的守護進程，物理表現為impalad進程。該進程讀寫數據文件，接收從impala-shell命令行、Hue、JDBC、ODBC提交的查詢請求，將查詢工作並行分布到集群的數據節點上，並將查詢的中間結果返回給中心協調節點。
可以將查詢提交至任意一個數據節點上運行的Impala守護進程，此守護進程實例擔任該查詢的協調器，其它節點提交部分中間結果返給協調器，協調器構建查詢的最終結果集。當在試驗環境使用impala-shell命令行運行SQL時，出於方便性，通常總是連接同一個Impala守護進程。而在生產環境負載的集群中，可以采用循環的方式，通過JDBC或ODBC接口，將每個查詢輪流提交至不同的Impala守護進程，已達到負載均衡。
Impala守護進程持續與statestore進行通信，以確認每個節點健康狀況以及是否可以接收新的任務。
當集群中的任何Impala節點建立、修改、刪除任何類型的對象，或者通過Impala處理一個insert或load data語句時，catalogd守護進程(Impala 1.2引入)都會發出廣播消息。Impala守護進程會接收這種從catalogd守護進程發出的廣播消息。這種後臺通信減少了對refresh或invalidate metadata語句的需要，而在Impala 1.2版本前，這些語句被用於在節點間協調元數據信息。
Impala Statestore
叫做statestore的Impala組件檢查集群中所有數據節點上Impala守護進程的健康狀況，並將這些信息持續轉發給每個Impala守護進程。其物理表現為一個名為statestored的守護進程，該進程只需要在集群中的一臺主機上啟動。如果Impala守護進程由於硬件、軟件、網絡或其它原因失效，statestore會通知所有其它的Impala守護進程，這樣以後的查詢就不會再向不可到達的節點發出請求。
statestore的目的只是在發生某種錯誤時提供幫助，因此在正常操作一個Impala集群時，它並不是一個關鍵組件。即使statestore沒有運行或者不可用，Impala守護進程依然會運行，並像通常一樣在它們中分法任務。 這時如果一個Impala守護進程失效，僅僅是降低了集群的魯棒性。當statestore恢復可用後，它會重建與Impala守護進程之間的通信並恢復監控功能。
在Impala中，所有負載均衡和高可用的考慮都是用於Impala守護進程的。statestored和catalogd進程沒有高可用的需求，因為這些進程即使出現問題也不會引起數據丟失。當這些進程由於所在的主機停機而變成不可用時，可以這樣處理：先停止Impala服務，然後刪除Impala StateStore和Impala Catalog服務器角色，再在另一臺主機上添加這兩個角色，最後重啟Impala服務。
Impala Catalog服務
稱為Catalog服務的Impala組件將Impala SQL語句產生的元數據改變轉發至集群中的所有數據節點。其物理表現為一個名為catalogd的守護進程，該進程只需要在集群中的一臺主機上啟動，而且應該與statestored進程在同一臺主機上。
由於catalog服務的存在，當通過執行Impala語句而改變元數據時，不需要再發出refresh或invalidate metadata語句。然而，當通過Hive執行建立表、裝載數據等操作後，在一個Impala節點上執行查詢前，仍然需要先發出refresh或invalidate metadata語句。例如，通過Impala執行的create table、insert或其它改變表或改變數據的操作，無需執行refresh and invalidate metadata語句。而如果這些操作是用過Hive執行的，或者是直接操縱的HDFS數據文件，仍需執行refresh and invalidate metadata語句(只需在一個Impala節點執行，而不是全部節點)。
缺省情況下，元數據在Impala啟動時異步裝載並緩存，這樣Impala可以立即接收查詢請求。如果想讓Impala等所有元數據裝載後再接收查詢請求，需要設置catalogd的配置選項load_catalog_in_background=false。
(4)開發Impala應用
Impala SQL方言
Impala的核心開發語言是SQL，也可以使用Java或其它語言，通過JDBC或ODBC接口與Impala進行交互，許多商業智能工具都使用這種方式。對於特殊的分析需求，還可以用C++或Java編寫用戶定義的函數(UDFs)，補充SQL內建的功能。
Impala的SQL方言與Hive組件(HiveQL)在語法上高度兼容。正因如此，對於熟悉Hadoop架構上SQL查詢的用戶來說，Impala SQL並不陌生。當前，Impala SQL支持HiveQL語句、數據類型、內建函數的一個子集。Impala還包含一些附加的符合工業標準的內建函數，用於簡化從非Hadoop系統移植SQL。
對於具有傳統數據庫或數據倉庫背景的用戶來說，下面關於SQL方言的內容應該是非常熟悉的：
包含where、group by、order by、with等子句的select語句(Impala的with子句並不支持遞歸查詢)，連接操作，處理字符串、數字、日期的內建函數、聚合函數、子查詢、in和between這樣的比較操作符等。這些select語句與SQL標準是兼容的。分區表在數據倉庫中經常使用。把一個或多個列作為分區鍵，數據按照分區鍵的值物理分布。當查詢的where子句中包含分區鍵列時，可以直接跳過不符合過濾條件的分區，這也就是所謂的“分區消除”。例如，假設有10年的數據，並且查詢語句中有類似where year = 2015、where year > 2010、where year in (2014, 2015)的where子句，則Impala跳過所有不匹配年份的數據，這會大大降低查詢的I/O數量。在Impala 1.2及其以上版本中，UDFs可以在select和insert...select語句中執行定制的比較和轉換邏輯。
如果對Hadoop環境不夠熟悉但具有傳統數據庫或數據倉庫背景，需要學習並實踐一下Impala SQL與傳統SQL的不同之處：
Impala SQL專註於查詢而不是DML，所以沒有提供update或delete語句。對於沒用的陳舊數據，典型的做法是使用drop table或alter table ... drop partition語句直接刪除，或者使用 insert overwrite語句將老數據替換掉。在Impala中，所有的數據創建都是通過insert語句，典型情況是通過查詢其它表批量插入數據。insert語句有兩種插入數據的方式，insert into在現有數據上追加，而insert overwrite則會替換整個表或分區的內容(效果就像先truncate table再insert一樣)。Impala沒有insert ... values的插入單行的語法。比較常見的情況是，在其它環境建立表和數據文件，然後使用Impala對其進行實時查詢。相同的數據文件和表的元數據在Hadoop生態圈的不同組件之間共享。例如，Impala可以訪問Hive裏的表和數據，而Hive也可以訪問在Impala中建立的表及其數據。許多其它的Hadoop組件可以生成Parquet和Avro格式的文件，Impala也可以查詢這些文件。Hadoop和Impala的關註點在大數據集上的數據倉庫型操作，因此Impala包含一些對於傳統數據庫應用系統非常重要的SQL方言。例如，可以在create table語句中指定分隔符，通過表讀取以逗號和tab做分隔的文本文件。還可以建立外部表，在不遷移和轉換現有數據文件的前提下讀取它們。impala讀取的大量數據可能不太容易確定其長度，所以不能強制字符串類型數據的長度。例如，可以定義一個表列為string類型，而不是象char(1)或varchar(64)限制字符串長度。(在Impala 1.2及其以後版本中，可以使用char和varchar類型限制字符串長度。)
Impala編程接口
可以通過下面的接口連接Impala，並向Impala守護進程提交請求。
impala-shell命令行接口Hue基於web的用戶界面JDBCODBC 使用這些接口，可以在異構環境下使用Impala，如在非linux平臺上運行的JDBC、ODBC應用，還可以使用JDBC、ODBC接口將Impala和商業智能工具結合使用。
每個impalad守護進程運行在集群中的不同節點上，監聽來自多個端口的請求。來自impala-shell和Hue的請求通過相同的端口被路由至impalad守護進程，而JDBC和ODBC的請求發往不同的impalad監聽端口。
(5)Impala與Hadoop生態圈
Impala可以利用Hadoop生態圈中許多熟悉的組件，並且可以和這些組件交換數據，即可作為生產者也可作為消費者，因此可以靈活地加入到ETL管道中。
Impala與Hive
Impala的一個主要目標是讓SQL-on-Hadoop操作足夠快，以吸引新的Hadoop用戶，或開發Hadoop新的使用場景。在實際中，許多Hadoop用戶使用Hive來執行長時間運行的、面向批處理的SQL查詢，而Impala可以利用這些已有的Hive架構。Impala將它的表定義存儲在一個傳統的mysql或PostgreSQL數據庫中，這個數據庫被稱為metastore，而Hive也將其元數據存儲在同一個的數據庫中。通過這種方式，只要Hive表定義的文件類型和壓縮算法為Impala所支持，所有列的數據類型也是Impala所支持的類型，Impala就可以訪問它。
Impala最初被設計成致力於提高查詢的性能，這就意味著在Impala裏，select語句能夠讀取的數據的類型比insert語句能夠插入的數據的類型要多Impala可以讀取使用Hive裝載的Avro、RCFile或SequenceFile文件格式的數據。
Impala查詢優化器也可以利用表和列的統計信息。在Impala 1.2.2版本前，使用Hive裏的analyze table語句收集這些信息，在Impala 1.2.2及其更高版本中，使用Impala的compute stats語句收集信息。compute stats更靈活也更簡單，並且不需要再impala-shell和Hive shell之間來回切換。
Impala的元數據和元數據存儲
前面討論Impala如何與Hive一起使用時提到，Impala使用一個叫做metastore的數據庫維護它的表定義信息。同時Impala還跟蹤其它數據文件底層特性的元數據，如HDFS中數據塊的物理位置信息。
對於一個有很多分區或很多數據的大表，獲取它的元數據可能很耗時，有時需要花上幾分鐘的時間。因此每個Impala節點都會緩存這些元數據，當後面再查詢該表時，就可以復用緩存中的元數據。
如果表定義或表中的數據更新了，集群中所有其它的Impala守護進程在查詢該表前， 都必須能收到最新的元數據，並更新自己緩存的元數據。在Impala 1.2或更高版本中，這種元數據的更新是自動的，由catalogd守護進程為所有通過Impala發出的DDL和DML語句進行協調。
對於通過Hive發出的DDL和DML，或者手工改變了HDFS文件的情況，還是需要在Impala中使用refresh語句(當新的數據文件被加到已有的表上)或invalidate metadata語句(新建表、刪除表、執行了HDFS的rebalance操作，或者刪除了數據文件)。invalidate metadata語句獲取metastore中存儲的所有表的元數據。如果能夠確定在Impala外部只有特定的表被改變，可以為每一個受影響的表使用refresh 表名，該語句只獲取特定表的最新元數據。
Impala與HDFS
Impala使用分布式文件系統HDFS作為主要的數據存儲介質。Impala依賴HDFS提供的冗余功能，保證在單獨節點因硬件、軟件或網絡問題失效後仍能工作。Impala表數據物理表現為HDFS上的數據文件，這些文件使用常見的HDFS文件格式和壓縮算法。
Impala與Hbase
除HDFS外，HBase也是Impala數據存儲介質的備選方案。HBase是建立在HDFS之上的數據庫存儲系統，不提供內建的SQL支持。許多Hadoop用戶使用HBase存儲大量的稀疏數據。在Impala中可以定義表，並映射為HBase中等價的表，通過這種方式就可以使用Impala查詢HBase表的內容，甚至可以聯合Impala表和HBase表執行關聯查詢。
Tags: 關系數據庫 Online 經銷商 立方體 數據源
文章來源：