建站
咨詢
售后
建站咨詢
新聞中心
今天就跟大家聊聊有關(guān)如何分析數(shù)據(jù)虛擬化引擎openLooKeng，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。
成都創(chuàng)新互聯(lián)主營武定網(wǎng)站建設(shè)的網(wǎng)絡(luò)公司,主營網(wǎng)站建設(shè)方案,app開發(fā)定制,武定h5小程序定制開發(fā)搭建,武定網(wǎng)站營銷推廣歡迎武定等地區(qū)企業(yè)咨詢
大數(shù)據(jù)分析的現(xiàn)狀及問題
21世紀是信息爆炸的世紀，隨著IT技術(shù)的飛速發(fā)展，越來越多的應(yīng)用源源不斷的產(chǎn)生數(shù)以億計的數(shù)據(jù)。在過去的近一個世紀里，科學家與工程師發(fā)明了各種各樣的數(shù)據(jù)管理系統(tǒng)來存儲與管理各種各樣的數(shù)據(jù)：關(guān)系型數(shù)據(jù)庫、NoSql數(shù)據(jù)庫，文檔數(shù)據(jù)庫、Key-value數(shù)據(jù)庫，對象存儲系統(tǒng)等等。形態(tài)多樣的數(shù)據(jù)管理系統(tǒng)為企業(yè)組織在管理數(shù)據(jù)上帶來便利的同時，隨之而來的是管理與充分利用這些數(shù)據(jù)系統(tǒng)存儲的數(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方言；為了對不同數(shù)據(jù)源進行聯(lián)合查詢，那么就得在應(yīng)用程序邏輯中使用不同的客戶端去連接不同的數(shù)據(jù)源，整個分析過程架構(gòu)復(fù)雜，編程入口多，系統(tǒng)集成困難，這對于涉及海量數(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ī)模的進一步增長，不得不指出的是，業(yè)界已經(jīng)逐漸認識到將數(shù)據(jù)搬運到數(shù)據(jù)倉庫的過程是昂貴的，除了數(shù)據(jù)倉庫的硬件或軟件的成本，維護與更新整個ETL邏輯系統(tǒng)的人力成本也逐漸成為數(shù)據(jù)倉庫的重要開銷之一。數(shù)據(jù)倉庫ETL流程同時也是笨重且耗時的，為了獲取到想要的數(shù)據(jù)，數(shù)據(jù)分析師或用戶不得不妥協(xié)于數(shù)據(jù)倉庫T+1的數(shù)據(jù)分析模式，想要快速進行業(yè)務(wù)分析探索對于數(shù)據(jù)分析師來說一直是一個待解的難題。
人們?yōu)榱私鉀Q各種各樣的數(shù)據(jù)管理系統(tǒng)的數(shù)據(jù)孤島問題，針對不同的業(yè)務(wù)應(yīng)用又發(fā)明了專題數(shù)據(jù)倉庫，但隨著業(yè)務(wù)應(yīng)用的增多，日益增多的專題數(shù)據(jù)倉庫又變成了數(shù)據(jù)孤島。所以英勇的“屠龍勇士”隨著時間的流逝都不可避免的會變成“惡龍”嗎？是否有一種系統(tǒng)架構(gòu)簡潔、編程入口統(tǒng)一、系統(tǒng)集成度好的解決方案呢？也許今天，我們是時候回到最初的起點，來從頭看看大數(shù)據(jù)數(shù)據(jù)分析的另一種范式了。
數(shù)據(jù)虛擬化引擎openLooKeng：我們不搬運數(shù)據(jù)，我們是數(shù)據(jù)的”連接器“
所以當我們回頭來看數(shù)據(jù)倉庫碰到的各種各樣的問題的時候，聰明的您很容易發(fā)現(xiàn)，數(shù)據(jù)倉庫這個”屠龍勇士“之所以逐漸變成“惡龍”是因為它在不停的搬運數(shù)據(jù)，搬運數(shù)據(jù)正是導(dǎo)致數(shù)據(jù)倉庫的建立與分析過程繁重、費時、昂貴的“元兇”。既然搬運數(shù)據(jù)導(dǎo)致了這些問題，那么讓我們回到大數(shù)據(jù)分析的出發(fā)點，考慮下“林中的另一條路”，而這條路正是openLooKeng正在走的變數(shù)據(jù)搬運為數(shù)據(jù)連接的路。
簡明扼要的講，openLooKeng數(shù)據(jù)虛擬化引擎分析數(shù)據(jù)的方式是通過各種各樣的數(shù)據(jù)源Connector連接到各個數(shù)據(jù)源系統(tǒng)，用戶在發(fā)起查詢時，通過各個Connector實時的去獲取數(shù)據(jù)并進行高性能的計算，從而在秒級或分鐘級內(nèi)得到分析結(jié)果。這與以往的數(shù)據(jù)倉庫通過T+1的ETL數(shù)據(jù)搬運過程處理好數(shù)據(jù)再給用戶使用的方式有很大差異。
與以往數(shù)據(jù)分析師需要學習各種各樣的SQL方言不同的是，現(xiàn)在數(shù)據(jù)分析師只需要熟練掌握ANSI SQL2003語法。而各種各樣的數(shù)據(jù)管理系統(tǒng)在SQL標準上的差異則由openLooKeng作為中間層進行了屏蔽，用戶不用再學習各種SQL方言，這些繁雜的SQL方言轉(zhuǎn)換的工作都將由openLooKeng來完成。通過將用戶從各種各樣的SQL方言中“解放”出來，用戶可以專注于構(gòu)建高價值的業(yè)務(wù)應(yīng)用查詢分析邏輯，這些分析邏輯形成的無形資產(chǎn)往往才是企業(yè)商業(yè)智能的核心，openLooKeng正是出于幫助用戶快速構(gòu)建高價值的業(yè)務(wù)分析邏輯這一目的來構(gòu)建自己的整個技術(shù)架構(gòu)的。由于無需搬運數(shù)據(jù)，用戶的分析查詢靈感可以快速的使用openLooKeng進行驗證，從而達到比以往T+1的數(shù)據(jù)倉庫分析處理過程更快的分析效果。
讓我們站得更高一點來看，既然openLooKeng可以通過Connector連接到關(guān)系型數(shù)據(jù)庫、NOSQL數(shù)據(jù)庫等數(shù)據(jù)管理系統(tǒng)，那么可不可以將openLooKeng自身也作為一個Connector呢？答案是肯定的。當我們將openLooKeng自身也作為一個數(shù)據(jù)源提供給另一個openLooKeng集群時，可以得到這樣的好處：之前由于跨地域或者跨DC的網(wǎng)絡(luò)帶寬或者時延限制，導(dǎo)致的多個數(shù)據(jù)中心之間的數(shù)據(jù)要實現(xiàn)實時聯(lián)邦查詢基本上是不可用的，而現(xiàn)在openLooKeng集群1將本地數(shù)據(jù)進行計算后將結(jié)果再傳遞給openLooKeng集群2進行進一步分析，避免了大量原始數(shù)據(jù)的傳輸，從而規(guī)避了跨域跨DC查詢的網(wǎng)絡(luò)問題。
openLooKeng的統(tǒng)一SQL入口，豐富的南向數(shù)據(jù)源生態(tài)，一定程度上解決了以往跨源查詢架構(gòu)復(fù)雜、編程入口太多、系統(tǒng)集成度差的問題，實現(xiàn)了數(shù)據(jù)從“搬運”到“連接”的模式轉(zhuǎn)換，方便了用戶快速實現(xiàn)海量數(shù)據(jù)的價值變現(xiàn)。
openLooKeng的關(guān)鍵特性
也許在看了上面的介紹之后，您已經(jīng)迫不及待的想知道openLooKeng能在哪些場景下使用了，從而來解決目前業(yè)務(wù)應(yīng)用的痛點問題。但在繼續(xù)介紹openLooKeng適用的業(yè)務(wù)場景之前，讓我們先來看看openLooKeng的一些關(guān)鍵特性，以便于您更深入的理解openLooKeng為什么適合這些業(yè)務(wù)場景，甚至您也可以基于openLooKeng的這些能力進一步探索更多的業(yè)務(wù)場景。
專為海量數(shù)據(jù)設(shè)計的內(nèi)存計算框架
openLooKeng從一誕生便是針對TB甚至PB級海量數(shù)據(jù)的查詢分析任務(wù)而設(shè)計的，其對于Hadoop文件系統(tǒng)具有天然的親和性，其SQL on Hadoop的分布式處理架構(gòu)，采用了存儲與計算分離的設(shè)計理念，可方便的實現(xiàn)計算或存儲節(jié)點的水平擴展。同時openLooKeng內(nèi)核采用基于內(nèi)存的計算框架，所有數(shù)據(jù)的處理都在內(nèi)存中以并行的流水線式作業(yè)完成，可提供秒級到分鐘級的查詢時延響應(yīng)。
ANSI SQL2003語法的支持
openLooKeng支持ANSI SQL2003語法，用戶使用openLooKeng語法進行查詢時，無論底層數(shù)據(jù)源是RDBMS還是NoSQL 或者其他數(shù)據(jù)管理系統(tǒng)，借助openLooKeng的Connector框架，數(shù)據(jù)可以依然存放在原始的數(shù)據(jù)源中，從而實現(xiàn)數(shù)據(jù)“0搬遷”的查詢。
通過openLooKeng的統(tǒng)一SQL入口，可實現(xiàn)對底層各種數(shù)據(jù)源SQL方言的屏蔽，用戶無需再關(guān)心底層數(shù)據(jù)源的SQL方言便可獲取到該數(shù)據(jù)源的數(shù)據(jù)，方便了用戶消費數(shù)據(jù)。
多種多樣的數(shù)據(jù)源 Connector
正如數(shù)據(jù)管理系統(tǒng)的多種多樣一樣，openLooKeng針對這些數(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ù)，從而進一步進行基于內(nèi)存的高性能聯(lián)合計算。
跨DC的跨域DataCenter Connector
openLooKeng不僅提供跨多種數(shù)據(jù)源聯(lián)合查詢的能力，還將跨源查詢的能力進一步延伸，開發(fā)了跨域跨DC查詢的DataCenter Connector。通過這個新Connector可以連接到遠端另外的openLooKeng集群，從而提供在不同數(shù)據(jù)中心間協(xié)同計算的能力。 其中的關(guān)鍵技術(shù)如下：
并行數(shù)據(jù)訪問：worker可以并發(fā)訪問數(shù)據(jù)源以提高訪問效率， 客戶端也可以并發(fā)從服務(wù)端獲取數(shù)據(jù)以加快數(shù)據(jù)獲取速度。
數(shù)據(jù)壓縮：在數(shù)據(jù)傳輸期間進行序列化之前，先使用GZIP壓縮算法對數(shù)據(jù)進行壓縮，以減少通過網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)量。
跨DC動態(tài)過濾：過濾數(shù)據(jù)以減少從遠端提取的數(shù)據(jù)量，從而確保網(wǎng)絡(luò)穩(wěn)定性并提高查詢效率。
高性能的查詢優(yōu)化技術(shù)
openLooKeng在內(nèi)存計算框架的基礎(chǔ)上，還利用許多查詢優(yōu)化技術(shù)來滿足高性能的交互式查詢的需要。
索引
openLooKeng提供基于Bitmap Index、Bloom Filter以及Min-max Index等索引。通過在現(xiàn)有數(shù)據(jù)上創(chuàng)建索引，并且把索引結(jié)果存儲在數(shù)據(jù)源外部，在查詢計劃編排時便利用索引信息過濾掉不匹配的文件，減少需要讀取的數(shù)據(jù)規(guī)模，從而加速查詢過程。
Cache
openLooKeng提供豐富多樣的Cache，包括元數(shù)據(jù)cache、執(zhí)行計劃cache、ORC行數(shù)據(jù)cache等。通過這些多樣的cache，可加速用戶多次對同一SQL或者同一類型SQL的查詢時延響應(yīng)。
動態(tài)過濾
所謂的動態(tài)過濾是指是在運行時（run time）將join一側(cè)表的過濾信息的結(jié)果應(yīng)用到另一側(cè)表的過濾器的優(yōu)化方法，openLooKeng不僅提供了多種數(shù)據(jù)源的動態(tài)過濾優(yōu)化特性，還將這一優(yōu)化特性應(yīng)用到了DataCenter Connector，從而加速不同場景關(guān)聯(lián)查詢的性能。
算子下推
openLooKeng通過Connector框架連接到RDBMS等數(shù)據(jù)源時，由于RDBMS具有較強的計算能力，一般情況下將算子下推到數(shù)據(jù)源進行計算可以獲取到更好的性能。openLooKeng目前支持多種數(shù)據(jù)源的算子下推，包括Oracle、HANA等，特別地，針對DC Connector也實現(xiàn)了算子下推，從而實現(xiàn)了更快的查詢時延響應(yīng)。
高可用特性
HA AA雙活
openLooKeng引入了高可用的AA特性，支持coordinator AA雙活機制，能夠保持多個coordinator之間的負載均衡，同時也保證了openLooKeng在高并發(fā)下的可用性。
Auto-scaling
openLooKeng的彈性伸縮特性支持將正在執(zhí)行任務(wù)的服務(wù)節(jié)點平穩(wěn)退服，同時也能將處于不活躍狀態(tài)的節(jié)點拉起并接受新的任務(wù)。openLooKeng通過提供“已隔離”與“隔離中”等狀態(tài)接口供外部資源管理者（如Yarn、Kubernetes等）調(diào)用，從而實現(xiàn)對coordinator和worker節(jié)點的彈性擴縮容。
openLooKeng的常見應(yīng)用場景
通過上述對openLooKeng關(guān)鍵特性的介紹，想必您的腦海中已經(jīng)浮現(xiàn)出了不少openLooKeng的應(yīng)用場景，下面讓我們一起來看看它在現(xiàn)實業(yè)務(wù)的應(yīng)用場景吧。
高性能的交互式查詢場景
openLooKeng基于內(nèi)存的計算框架，充分利用內(nèi)存并行處理、索引、Cache、分布式的流水線作業(yè)等技術(shù)手段來快速的進行查詢分析，可以處理TB甚至PB級的海量數(shù)據(jù)。以往使用Hive、Spark甚至Impala來構(gòu)建查詢?nèi)蝿?wù)的交互式分析應(yīng)用系統(tǒng)都可以使用openLooKeng查詢引擎來進行換代升級，從而獲取更快的查詢性能。
跨源異構(gòu)的查詢場景
正如前文所述，RDBMS、NoSQL等數(shù)據(jù)管理系統(tǒng)在客戶的各種應(yīng)用系統(tǒng)中廣泛使用；為了處理這些數(shù)據(jù)而建立起來的Hive或者MPPDB等專題數(shù)據(jù)倉庫也越來越多。而這些數(shù)據(jù)庫或者數(shù)據(jù)倉庫往往彼此孤立形成獨立的數(shù)據(jù)孤島，數(shù)據(jù)分析師常?？嘤冢?/p>
查詢各種數(shù)據(jù)源需要使用不同的連接方式或者客戶端，以及運行不同的SQL方言，這些不同導(dǎo)致額外的學習成本以及復(fù)雜的應(yīng)用開發(fā)邏輯
如果不將各種數(shù)據(jù)源的數(shù)據(jù)再次匯聚到一起，則無法對不同系統(tǒng)的數(shù)據(jù)進行聯(lián)邦查詢
使用openLooKeng可實現(xiàn)RDBMS、NoSQL等數(shù)據(jù)庫以及Hive或MPPDB等數(shù)據(jù)倉庫的聯(lián)合查詢，借助openLooKeng的跨源異構(gòu)查詢能力，數(shù)據(jù)分析師可實現(xiàn)海量數(shù)據(jù)的分鐘級甚至秒級查詢分析。
跨域跨DC的查詢場景
對于省-市、總部-分部這樣兩級或者多級數(shù)據(jù)中心的場景，用戶常常需要從省級（總部）數(shù)據(jù)中心查詢市級（分部）數(shù)據(jù)中心的數(shù)據(jù)，這種跨域查詢的主要瓶頸在于多個數(shù)據(jù)中心之間的網(wǎng)絡(luò)問題（帶寬不足、時延大、丟包等），從而導(dǎo)致查詢時延長、性能不穩(wěn)定等。
openLooKeng專為這種跨域查詢設(shè)計了跨域跨DC的解決方案DataCenter Connector，通過openLooKeng集群之間傳輸計算結(jié)果的方式，避免了大量原始數(shù)據(jù)的網(wǎng)絡(luò)傳輸，規(guī)避了帶寬不足、丟包等帶來的網(wǎng)絡(luò)問題，一定程度上解決了跨域跨DC查詢的難題，在跨域跨DC的查詢場景有較高的實用價值。
計算存儲分離的場景
openLooKeng自身是不帶存儲引擎的，其數(shù)據(jù)源主要來自各種異構(gòu)的數(shù)據(jù)管理系統(tǒng)，因而是一個典型的存儲計算分離的系統(tǒng)，可以方便的進行計算、存儲資源的獨立水平擴展。openLooKeng存儲計算分離的技術(shù)架構(gòu)可實現(xiàn)集群節(jié)點的動態(tài)擴展，實現(xiàn)不斷業(yè)務(wù)的資源彈性伸縮，適合于需要計算存儲分離的業(yè)務(wù)場景。
快速進行數(shù)據(jù)探索的場景
如前文所述，客戶為了查詢多種數(shù)據(jù)源中的數(shù)據(jù)，通常的做法是通過ETL過程建立專門的數(shù)據(jù)倉庫，但這樣帶來昂貴的人力成本、ETL時間成本等問題。對于需要快速進行數(shù)據(jù)探索而不想構(gòu)建專門的數(shù)據(jù)倉庫的客戶，將數(shù)據(jù)復(fù)制并加載到數(shù)據(jù)倉庫的做法顯得既費時又費力，而且還可能得不到用戶想要的分析結(jié)果。
openLooKeng可通過標準語法定義出一個虛擬的數(shù)據(jù)集市，結(jié)合跨源異構(gòu)的查詢能力連接到各個數(shù)據(jù)源，從而在這個虛擬的數(shù)據(jù)集市語義層定義出用戶需要探索的各種分析任務(wù)。使用openLooKeng的這種數(shù)據(jù)虛擬化能力，客戶可快速的建立起基于各種數(shù)據(jù)源的探索分析服務(wù)，而無需構(gòu)建復(fù)雜的、專門的數(shù)據(jù)倉庫，從而節(jié)約人力與時間成本，對于想快速進行數(shù)據(jù)探索從而開發(fā)新業(yè)務(wù)的場景使用openLooKeng是最佳的選擇之一。
看完上述內(nèi)容，你們對如何分析數(shù)據(jù)虛擬化引擎openLooKeng有進一步的了解嗎？如果還想了解更多知識或者相關(guān)內(nèi)容，請關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝大家的支持。
分享題目：如何分析數(shù)據(jù)虛擬化引擎openLooKeng
文章分享：http://fisionsoft.com.cn/article/ijihsj.html
