如何分析數(shù)據(jù)虛擬化引擎openLooKeng

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

大數(shù)據(jù)分析的現(xiàn)狀及問題

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

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

人們?yōu)榱私鉀Q各種各樣的數(shù)據(jù)管理系統(tǒng)的數(shù)據(jù)孤島問題，針對(duì)不同的業(yè)務(wù)應(yīng)用又發(fā)明了專題數(shù)據(jù)倉庫，但隨著業(yè)務(wù)應(yīng)用的增多，日益增多的專題數(shù)據(jù)倉庫又變成了數(shù)據(jù)孤島。所以英勇的“屠龍勇士”隨著時(shí)間的流逝都不可避免的會(huì)變成“惡龍”嗎？是否有一種系統(tǒng)架構(gòu)簡(jiǎn)潔、編程入口統(tǒng)一、系統(tǒng)集成度好的解決方案呢？也許今天，我們是時(shí)候回到最初的起點(diǎn)，來從頭看看大數(shù)據(jù)數(shù)據(jù)分析的另一種范式了。

數(shù)據(jù)虛擬化引擎openLooKeng：我們不搬運(yùn)數(shù)據(jù)，我們是數(shù)據(jù)的”連接器“

所以當(dāng)我們回頭來看數(shù)據(jù)倉庫碰到的各種各樣的問題的時(shí)候，聰明的您很容易發(fā)現(xiàn)，數(shù)據(jù)倉庫這個(gè)”屠龍勇士“之所以逐漸變成“惡龍”是因?yàn)樗?strong>不停的搬運(yùn)數(shù)據(jù)，搬運(yùn)數(shù)據(jù)正是導(dǎo)致數(shù)據(jù)倉庫的建立與分析過程繁重、費(fèi)時(shí)、昂貴的“元兇”。既然搬運(yùn)數(shù)據(jù)導(dǎo)致了這些問題，那么讓我們回到大數(shù)據(jù)分析的出發(fā)點(diǎn)，考慮下“林中的另一條路”，而這條路正是openLooKeng正在走的變數(shù)據(jù)搬運(yùn)為數(shù)據(jù)連接的路。

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

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

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

openLooKeng的統(tǒng)一SQL入口，豐富的南向數(shù)據(jù)源生態(tài)，一定程度上解決了以往跨源查詢架構(gòu)復(fù)雜、編程入口太多、系統(tǒng)集成度差的問題，實(shí)現(xiàn)了數(shù)據(jù)從“搬運(yùn)”到“連接”的模式轉(zhuǎn)換，方便了用戶快速實(shí)現(xiàn)海量數(shù)據(jù)的價(jià)值變現(xiàn)。

openLooKeng的關(guān)鍵特性

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

專為海量數(shù)據(jù)設(shè)計(jì)的內(nèi)存計(jì)算框架

openLooKeng從一誕生便是針對(duì)TB甚至PB級(jí)海量數(shù)據(jù)的查詢分析任務(wù)而設(shè)計(jì)的，其對(duì)于Hadoop文件系統(tǒng)具有天然的親和性，其SQL on Hadoop的分布式處理架構(gòu)，采用了存儲(chǔ)與計(jì)算分離的設(shè)計(jì)理念，可方便的實(shí)現(xiàn)計(jì)算或存儲(chǔ)節(jié)點(diǎn)的水平擴(kuò)展。同時(shí)openLooKeng內(nèi)核采用基于內(nèi)存的計(jì)算框架，所有數(shù)據(jù)的處理都在內(nèi)存中以并行的流水線式作業(yè)完成，可提供秒級(jí)到分鐘級(jí)的查詢時(shí)延響應(yīng)。

ANSI SQL2003語法的支持

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

通過openLooKeng的統(tǒng)一SQL入口，可實(shí)現(xiàn)對(duì)底層各種數(shù)據(jù)源SQL方言的屏蔽，用戶無需再關(guān)心底層數(shù)據(jù)源的SQL方言便可獲取到該數(shù)據(jù)源的數(shù)據(jù)，方便了用戶消費(fèi)數(shù)據(jù)。

多種多樣的數(shù)據(jù)源 Connector

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

跨DC的跨域DataCenter Connector

openLooKeng不僅提供跨多種數(shù)據(jù)源聯(lián)合查詢的能力，還將跨源查詢的能力進(jìn)一步延伸，開發(fā)了跨域跨DC查詢的DataCenter Connector。通過這個(gè)新Connector可以連接到遠(yuǎn)端另外的openLooKeng集群，從而提供在不同數(shù)據(jù)中心間協(xié)同計(jì)算的能力。 其中的關(guān)鍵技術(shù)如下：

并行數(shù)據(jù)訪問：worker可以并發(fā)訪問數(shù)據(jù)源以提高訪問效率， 客戶端也可以并發(fā)從服務(wù)端獲取數(shù)據(jù)以加快數(shù)據(jù)獲取速度。

數(shù)據(jù)壓縮：在數(shù)據(jù)傳輸期間進(jìn)行序列化之前，先使用GZIP壓縮算法對(duì)數(shù)據(jù)進(jìn)行壓縮，以減少通過網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)量。

跨DC動(dòng)態(tài)過濾：過濾數(shù)據(jù)以減少從遠(yuǎn)端提取的數(shù)據(jù)量，從而確保網(wǎng)絡(luò)穩(wěn)定性并提高查詢效率。

高性能的查詢優(yōu)化技術(shù)

openLooKeng在內(nèi)存計(jì)算框架的基礎(chǔ)上，還利用許多查詢優(yōu)化技術(shù)來滿足高性能的交互式查詢的需要。

• 索引

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

• Cache

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

• 動(dòng)態(tài)過濾

  所謂的動(dòng)態(tài)過濾是指是在運(yùn)行時(shí)（run time）將join一側(cè)表的過濾信息的結(jié)果應(yīng)用到另一側(cè)表的過濾器的優(yōu)化方法，openLooKeng不僅提供了多種數(shù)據(jù)源的動(dòng)態(tài)過濾優(yōu)化特性，還將這一優(yōu)化特性應(yīng)用到了DataCenter Connector，從而加速不同場(chǎng)景關(guān)聯(lián)查詢的性能。

• 算子下推

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

高可用特性

• HA AA雙活

  openLooKeng引入了高可用的AA特性，支持coordinator AA雙活機(jī)制，能夠保持多個(gè)coordinator之間的負(fù)載均衡，同時(shí)也保證了openLooKeng在高并發(fā)下的可用性。

• Auto-scaling

  openLooKeng的彈性伸縮特性支持將正在執(zhí)行任務(wù)的服務(wù)節(jié)點(diǎn)平穩(wěn)退服，同時(shí)也能將處于不活躍狀態(tài)的節(jié)點(diǎn)拉起并接受新的任務(wù)。openLooKeng通過提供“已隔離”與“隔離中”等狀態(tài)接口供外部資源管理者（如Yarn、Kubernetes等）調(diào)用，從而實(shí)現(xiàn)對(duì)coordinator和worker節(jié)點(diǎn)的彈性擴(kuò)縮容。

openLooKeng的常見應(yīng)用場(chǎng)景

通過上述對(duì)openLooKeng關(guān)鍵特性的介紹，想必您的腦海中已經(jīng)浮現(xiàn)出了不少openLooKeng的應(yīng)用場(chǎng)景，下面讓我們一起來看看它在現(xiàn)實(shí)業(yè)務(wù)的應(yīng)用場(chǎng)景吧。

高性能的交互式查詢場(chǎng)景

openLooKeng基于內(nèi)存的計(jì)算框架，充分利用內(nèi)存并行處理、索引、Cache、分布式的流水線作業(yè)等技術(shù)手段來快速的進(jìn)行查詢分析，可以處理TB甚至PB級(jí)的海量數(shù)據(jù)。以往使用Hive、Spark甚至Impala來構(gòu)建查詢?nèi)蝿?wù)的交互式分析應(yīng)用系統(tǒng)都可以使用openLooKeng查詢引擎來進(jìn)行換代升級(jí)，從而獲取更快的查詢性能。

跨源異構(gòu)的查詢場(chǎng)景

正如前文所述，RDBMS、NoSQL等數(shù)據(jù)管理系統(tǒng)在客戶的各種應(yīng)用系統(tǒng)中廣泛使用；為了處理這些數(shù)據(jù)而建立起來的Hive或者M(jìn)PPDB等專題數(shù)據(jù)倉庫也越來越多。而這些數(shù)據(jù)庫或者數(shù)據(jù)倉庫往往彼此孤立形成獨(dú)立的數(shù)據(jù)孤島，數(shù)據(jù)分析師常?？嘤冢?/p>

• 查詢各種數(shù)據(jù)源需要使用不同的連接方式或者客戶端，以及運(yùn)行不同的SQL方言，這些不同導(dǎo)致額外的學(xué)習(xí)成本以及復(fù)雜的應(yīng)用開發(fā)邏輯

• 如果不將各種數(shù)據(jù)源的數(shù)據(jù)再次匯聚到一起，則無法對(duì)不同系統(tǒng)的數(shù)據(jù)進(jìn)行聯(lián)邦查詢

使用openLooKeng可實(shí)現(xiàn)RDBMS、NoSQL等數(shù)據(jù)庫以及Hive或MPPDB等數(shù)據(jù)倉庫的聯(lián)合查詢，借助openLooKeng的跨源異構(gòu)查詢能力，數(shù)據(jù)分析師可實(shí)現(xiàn)海量數(shù)據(jù)的分鐘級(jí)甚至秒級(jí)查詢分析。

跨域跨DC的查詢場(chǎng)景

對(duì)于省-市、總部-分部這樣兩級(jí)或者多級(jí)數(shù)據(jù)中心的場(chǎng)景，用戶常常需要從省級(jí)（總部）數(shù)據(jù)中心查詢市級(jí)（分部）數(shù)據(jù)中心的數(shù)據(jù)，這種跨域查詢的主要瓶頸在于多個(gè)數(shù)據(jù)中心之間的網(wǎng)絡(luò)問題（帶寬不足、時(shí)延大、丟包等），從而導(dǎo)致查詢時(shí)延長(zhǎng)、性能不穩(wěn)定等。

openLooKeng專為這種跨域查詢?cè)O(shè)計(jì)了跨域跨DC的解決方案DataCenter Connector，通過openLooKeng集群之間傳輸計(jì)算結(jié)果的方式，避免了大量原始數(shù)據(jù)的網(wǎng)絡(luò)傳輸，規(guī)避了帶寬不足、丟包等帶來的網(wǎng)絡(luò)問題，一定程度上解決了跨域跨DC查詢的難題，在跨域跨DC的查詢場(chǎng)景有較高的實(shí)用價(jià)值。

計(jì)算存儲(chǔ)分離的場(chǎng)景

openLooKeng自身是不帶存儲(chǔ)引擎的，其數(shù)據(jù)源主要來自各種異構(gòu)的數(shù)據(jù)管理系統(tǒng)，因而是一個(gè)典型的存儲(chǔ)計(jì)算分離的系統(tǒng)，可以方便的進(jìn)行計(jì)算、存儲(chǔ)資源的獨(dú)立水平擴(kuò)展。openLooKeng存儲(chǔ)計(jì)算分離的技術(shù)架構(gòu)可實(shí)現(xiàn)集群節(jié)點(diǎn)的動(dòng)態(tài)擴(kuò)展，實(shí)現(xiàn)不斷業(yè)務(wù)的資源彈性伸縮，適合于需要計(jì)算存儲(chǔ)分離的業(yè)務(wù)場(chǎng)景。

快速進(jìn)行數(shù)據(jù)探索的場(chǎng)景

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

openLooKeng可通過標(biāo)準(zhǔn)語法定義出一個(gè)虛擬的數(shù)據(jù)集市，結(jié)合跨源異構(gòu)的查詢能力連接到各個(gè)數(shù)據(jù)源，從而在這個(gè)虛擬的數(shù)據(jù)集市語義層定義出用戶需要探索的各種分析任務(wù)。使用openLooKeng的這種數(shù)據(jù)虛擬化能力，客戶可快速的建立起基于各種數(shù)據(jù)源的探索分析服務(wù)，而無需構(gòu)建復(fù)雜的、專門的數(shù)據(jù)倉庫，從而節(jié)約人力與時(shí)間成本，對(duì)于想快速進(jìn)行數(shù)據(jù)探索從而開發(fā)新業(yè)務(wù)的場(chǎng)景使用openLooKeng是最佳的選擇之一。

看完上述內(nèi)容，你們對(duì)如何分析數(shù)據(jù)虛擬化引擎openLooKeng有進(jìn)一步的了解嗎？如果還想了解更多知識(shí)或者相關(guān)內(nèi)容，請(qǐng)關(guān)注億速云行業(yè)資訊頻道，感謝大家的支持。