如何分析數據虛擬化引擎openLooKeng

今天就跟大家聊聊有關如何分析數據虛擬化引擎openLooKeng，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。

大數據分析的現狀及問題

21世紀是信息爆炸的世紀，隨著IT技術的飛速發展，越來越多的應用源源不斷的產生數以億計的數據。在過去的近一個世紀里，科學家與工程師發明了各種各樣的數據管理系統來存儲與管理各種各樣的數據：關系型數據庫、NoSQL數據庫，文檔數據庫、Key-value數據庫，對象存儲系統等等。形態多樣的數據管理系統為企業組織在管理數據上帶來便利的同時，隨之而來的是管理與充分利用這些數據系統存儲的數據的難題。無論是關系型數據庫中的PostgreSQL或者MySQL，抑或是Hadoop體系下的Hive或者HBase，這些目前業界通用的數據管理系統都有自成體系的一套SQL方言。數據分析師想要分析某一種數據管理系統的數據，就得熟練掌握某一種SQL方言；為了對不同數據源進行聯合查詢，那么就得在應用程序邏輯中使用不同的客戶端去連接不同的數據源，整個分析過程架構復雜，編程入口多，系統集成困難，這對于涉及海量數據的數據分析師而言這樣的分析過程十分痛苦。

為了解決多數據源形成的數據孤島的聯合查詢問題，業界正在廣泛使用數據倉庫這一解決方案。數據倉庫在過去的數年里快速發展，它通過抽取（Extract）、轉換（Transform）、加載（Load）各種各樣數據源中的數據，經過ETL這一整套流程，將加工后的數據集中保存在專題數據倉庫中，供數據分析師或用戶使用。但隨著數據規模的進一步增長，不得不指出的是，業界已經逐漸認識到將數據搬運到數據倉庫的過程是昂貴的，除了數據倉庫的硬件或軟件的成本，維護與更新整個ETL邏輯系統的人力成本也逐漸成為數據倉庫的重要開銷之一。數據倉庫ETL流程同時也是笨重且耗時的，為了獲取到想要的數據，數據分析師或用戶不得不妥協于數據倉庫T+1的數據分析模式，想要快速進行業務分析探索對于數據分析師來說一直是一個待解的難題。

人們為了解決各種各樣的數據管理系統的數據孤島問題，針對不同的業務應用又發明了專題數據倉庫，但隨著業務應用的增多，日益增多的專題數據倉庫又變成了數據孤島。所以英勇的“屠龍勇士”隨著時間的流逝都不可避免的會變成“惡龍”嗎？是否有一種系統架構簡潔、編程入口統一、系統集成度好的解決方案呢？也許今天，我們是時候回到最初的起點，來從頭看看大數據數據分析的另一種范式了。

數據虛擬化引擎openLooKeng：我們不搬運數據，我們是數據的”連接器“

所以當我們回頭來看數據倉庫碰到的各種各樣的問題的時候，聰明的您很容易發現，數據倉庫這個”屠龍勇士“之所以逐漸變成“惡龍”是因為它在不停的搬運數據，搬運數據正是導致數據倉庫的建立與分析過程繁重、費時、昂貴的“元兇”。既然搬運數據導致了這些問題，那么讓我們回到大數據分析的出發點，考慮下“林中的另一條路”，而這條路正是openLooKeng正在走的變數據搬運為數據連接的路。

簡明扼要的講，openLooKeng數據虛擬化引擎分析數據的方式是通過各種各樣的數據源Connector連接到各個數據源系統，用戶在發起查詢時，通過各個Connector實時的去獲取數據并進行高性能的計算，從而在秒級或分鐘級內得到分析結果。這與以往的數據倉庫通過T+1的ETL數據搬運過程處理好數據再給用戶使用的方式有很大差異。

與以往數據分析師需要學習各種各樣的SQL方言不同的是，現在數據分析師只需要熟練掌握ANSI SQL2003語法。而各種各樣的數據管理系統在SQL標準上的差異則由openLooKeng作為中間層進行了屏蔽，用戶不用再學習各種SQL方言，這些繁雜的SQL方言轉換的工作都將由openLooKeng來完成。通過將用戶從各種各樣的SQL方言中“解放”出來，用戶可以專注于構建高價值的業務應用查詢分析邏輯，這些分析邏輯形成的無形資產往往才是企業商業智能的核心，openLooKeng正是出于幫助用戶快速構建高價值的業務分析邏輯這一目的來構建自己的整個技術架構的。由于無需搬運數據，用戶的分析查詢靈感可以快速的使用openLooKeng進行驗證，從而達到比以往T+1的數據倉庫分析處理過程更快的分析效果。

讓我們站得更高一點來看，既然openLooKeng可以通過Connector連接到關系型數據庫、NoSQL數據庫等數據管理系統，那么可不可以將openLooKeng自身也作為一個Connector呢？答案是肯定的。當我們將openLooKeng自身也作為一個數據源提供給另一個openLooKeng集群時，可以得到這樣的好處：之前由于跨地域或者跨DC的網絡帶寬或者時延限制，導致的多個數據中心之間的數據要實現實時聯邦查詢基本上是不可用的，而現在openLooKeng集群1將本地數據進行計算后將結果再傳遞給openLooKeng集群2進行進一步分析，避免了大量原始數據的傳輸，從而規避了跨域跨DC查詢的網絡問題。

openLooKeng的統一SQL入口，豐富的南向數據源生態，一定程度上解決了以往跨源查詢架構復雜、編程入口太多、系統集成度差的問題，實現了數據從“搬運”到“連接”的模式轉換，方便了用戶快速實現海量數據的價值變現。

openLooKeng的關鍵特性

也許在看了上面的介紹之后，您已經迫不及待的想知道openLooKeng能在哪些場景下使用了，從而來解決目前業務應用的痛點問題。但在繼續介紹openLooKeng適用的業務場景之前，讓我們先來看看openLooKeng的一些關鍵特性，以便于您更深入的理解openLooKeng為什么適合這些業務場景，甚至您也可以基于openLooKeng的這些能力進一步探索更多的業務場景。

專為海量數據設計的內存計算框架

openLooKeng從一誕生便是針對TB甚至PB級海量數據的查詢分析任務而設計的，其對于Hadoop文件系統具有天然的親和性，其SQL on Hadoop的分布式處理架構，采用了存儲與計算分離的設計理念，可方便的實現計算或存儲節點的水平擴展。同時openLooKeng內核采用基于內存的計算框架，所有數據的處理都在內存中以并行的流水線式作業完成，可提供秒級到分鐘級的查詢時延響應。

ANSI SQL2003語法的支持

openLooKeng支持ANSI SQL2003語法，用戶使用openLooKeng語法進行查詢時，無論底層數據源是RDBMS還是NoSQL 或者其他數據管理系統，借助openLooKeng的Connector框架，數據可以依然存放在原始的數據源中，從而實現數據“0搬遷”的查詢。

通過openLooKeng的統一SQL入口，可實現對底層各種數據源SQL方言的屏蔽，用戶無需再關心底層數據源的SQL方言便可獲取到該數據源的數據，方便了用戶消費數據。

多種多樣的數據源 Connector

正如數據管理系統的多種多樣一樣，openLooKeng針對這些數據管理系統開發了多種多樣的數據源Connector，包括RDBMS（Oracle Connector、HANA Connector等），NoSQL（Hive Connector、HBase Connector等），全文檢索數據庫（ElasticSearch Connector等）。openLooKeng可以通過這些多樣的Connector方便的獲取到數據源數據，從而進一步進行基于內存的高性能聯合計算。

跨DC的跨域DataCenter Connector

openLooKeng不僅提供跨多種數據源聯合查詢的能力，還將跨源查詢的能力進一步延伸，開發了跨域跨DC查詢的DataCenter Connector。通過這個新Connector可以連接到遠端另外的openLooKeng集群，從而提供在不同數據中心間協同計算的能力。 其中的關鍵技術如下：

并行數據訪問：worker可以并發訪問數據源以提高訪問效率， 客戶端也可以并發從服務端獲取數據以加快數據獲取速度。

數據壓縮：在數據傳輸期間進行序列化之前，先使用GZIP壓縮算法對數據進行壓縮，以減少通過網絡傳輸的數據量。

跨DC動態過濾：過濾數據以減少從遠端提取的數據量，從而確保網絡穩定性并提高查詢效率。

高性能的查詢優化技術

openLooKeng在內存計算框架的基礎上，還利用許多查詢優化技術來滿足高性能的交互式查詢的需要。

• 索引

  openLooKeng提供基于Bitmap Index、Bloom Filter以及Min-max Index等索引。通過在現有數據上創建索引，并且把索引結果存儲在數據源外部，在查詢計劃編排時便利用索引信息過濾掉不匹配的文件，減少需要讀取的數據規模，從而加速查詢過程。

• Cache

  openLooKeng提供豐富多樣的Cache，包括元數據cache、執行計劃cache、ORC行數據cache等。通過這些多樣的cache，可加速用戶多次對同一SQL或者同一類型SQL的查詢時延響應。

• 動態過濾

  所謂的動態過濾是指是在運行時（run time）將join一側表的過濾信息的結果應用到另一側表的過濾器的優化方法，openLooKeng不僅提供了多種數據源的動態過濾優化特性，還將這一優化特性應用到了DataCenter Connector，從而加速不同場景關聯查詢的性能。

• 算子下推

  openLooKeng通過Connector框架連接到RDBMS等數據源時，由于RDBMS具有較強的計算能力，一般情況下將算子下推到數據源進行計算可以獲取到更好的性能。openLooKeng目前支持多種數據源的算子下推，包括Oracle、HANA等，特別地，針對DC Connector也實現了算子下推，從而實現了更快的查詢時延響應。

高可用特性

• HA AA雙活

  openLooKeng引入了高可用的AA特性，支持coordinator AA雙活機制，能夠保持多個coordinator之間的負載均衡，同時也保證了openLooKeng在高并發下的可用性。

• Auto-scaling

  openLooKeng的彈性伸縮特性支持將正在執行任務的服務節點平穩退服，同時也能將處于不活躍狀態的節點拉起并接受新的任務。openLooKeng通過提供“已隔離”與“隔離中”等狀態接口供外部資源管理者（如Yarn、Kubernetes等）調用，從而實現對coordinator和worker節點的彈性擴縮容。

openLooKeng的常見應用場景

通過上述對openLooKeng關鍵特性的介紹，想必您的腦海中已經浮現出了不少openLooKeng的應用場景，下面讓我們一起來看看它在現實業務的應用場景吧。

高性能的交互式查詢場景

openLooKeng基于內存的計算框架，充分利用內存并行處理、索引、Cache、分布式的流水線作業等技術手段來快速的進行查詢分析，可以處理TB甚至PB級的海量數據。以往使用Hive、Spark甚至Impala來構建查詢任務的交互式分析應用系統都可以使用openLooKeng查詢引擎來進行換代升級，從而獲取更快的查詢性能。

跨源異構的查詢場景

正如前文所述，RDBMS、NoSQL等數據管理系統在客戶的各種應用系統中廣泛使用；為了處理這些數據而建立起來的Hive或者MPPDB等專題數據倉庫也越來越多。而這些數據庫或者數據倉庫往往彼此孤立形成獨立的數據孤島，數據分析師常常苦于：

• 查詢各種數據源需要使用不同的連接方式或者客戶端，以及運行不同的SQL方言，這些不同導致額外的學習成本以及復雜的應用開發邏輯

• 如果不將各種數據源的數據再次匯聚到一起，則無法對不同系統的數據進行聯邦查詢

使用openLooKeng可實現RDBMS、NoSQL等數據庫以及Hive或MPPDB等數據倉庫的聯合查詢，借助openLooKeng的跨源異構查詢能力，數據分析師可實現海量數據的分鐘級甚至秒級查詢分析。

跨域跨DC的查詢場景

對于省-市、總部-分部這樣兩級或者多級數據中心的場景，用戶常常需要從省級（總部）數據中心查詢市級（分部）數據中心的數據，這種跨域查詢的主要瓶頸在于多個數據中心之間的網絡問題（帶寬不足、時延大、丟包等），從而導致查詢時延長、性能不穩定等。

openLooKeng專為這種跨域查詢設計了跨域跨DC的解決方案DataCenter Connector，通過openLooKeng集群之間傳輸計算結果的方式，避免了大量原始數據的網絡傳輸，規避了帶寬不足、丟包等帶來的網絡問題，一定程度上解決了跨域跨DC查詢的難題，在跨域跨DC的查詢場景有較高的實用價值。

計算存儲分離的場景

openLooKeng自身是不帶存儲引擎的，其數據源主要來自各種異構的數據管理系統，因而是一個典型的存儲計算分離的系統，可以方便的進行計算、存儲資源的獨立水平擴展。openLooKeng存儲計算分離的技術架構可實現集群節點的動態擴展，實現不斷業務的資源彈性伸縮，適合于需要計算存儲分離的業務場景。

快速進行數據探索的場景

如前文所述，客戶為了查詢多種數據源中的數據，通常的做法是通過ETL過程建立專門的數據倉庫，但這樣帶來昂貴的人力成本、ETL時間成本等問題。對于需要快速進行數據探索而不想構建專門的數據倉庫的客戶，將數據復制并加載到數據倉庫的做法顯得既費時又費力，而且還可能得不到用戶想要的分析結果。

openLooKeng可通過標準語法定義出一個虛擬的數據集市，結合跨源異構的查詢能力連接到各個數據源，從而在這個虛擬的數據集市語義層定義出用戶需要探索的各種分析任務。使用openLooKeng的這種數據虛擬化能力，客戶可快速的建立起基于各種數據源的探索分析服務，而無需構建復雜的、專門的數據倉庫，從而節約人力與時間成本，對于想快速進行數據探索從而開發新業務的場景使用openLooKeng是最佳的選擇之一。

看完上述內容，你們對如何分析數據虛擬化引擎openLooKeng有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。