數據虛擬化引擎openLooKeng介紹

大數據分析的現狀及問題

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

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

人們爲了解決各類各樣的數據管理系統的數據孤島問題，針對不一樣的業務應用又發明了專題數據倉庫，但隨着業務應用的增多，日益增多的專題數據倉庫又變成了數據孤島。因此英勇的「屠龍勇士」隨着時間的流逝都不可避免的會變成「惡龍」嗎？是否有一種系統架構簡潔、編程入口統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在探索跨域跨DC的交互式查詢場景上有了必定的進展。展望將來，還有很多問題須要咱們去驗證和解決，好比除了交互式分析場景，如何解決openLooKeng在流處理和批處理上的問題？用戶還須要什麼樣的數據源Connector？衷心期待廣大用戶和開發者加入到openLooKeng開源社區中來，攜手開發openLooKeng項目，解決更多的用戶問題，讓大數據更簡單。

• • •

openLooKeng是一款開源的高性能數據虛擬化引擎，提供統一SQL接口，具有跨數據源/數據中心分析能力，爲大數據用戶提供極簡的數據分析體驗。歡迎加入openLooKeng社區，一塊兒作點有意思的事兒，讓大數據更簡單！

openLooKeng開源社區官方網站: https://openlookeng.io/zh-cn/

openLooKeng代碼倉地址: https://gitee.com/openlookeng