介紹

從高層的角度來看，許多數(shù)據(jù)和分析解決方案已經(jīng)以相同的方式構(gòu)建了許多年。 簡(jiǎn)而言之，它由各種集成過程組成，可將所有數(shù)據(jù)加載到一個(gè)中央位置，這是即將到來的數(shù)據(jù)建模和分析用例的唯一事實(shí)來源。 雖然在較早的日子里，這些中心位置大多是昂貴的且不靈活的緊密耦合的硬件/軟件系統(tǒng)，但如今通常會(huì)利用云和分布式架構(gòu)，包括計(jì)算和存儲(chǔ)的分離。 然而，盡管近年來取得了巨大的技術(shù)進(jìn)步，但集中數(shù)據(jù)的整體方法仍然是最有效地利用其數(shù)據(jù)并進(jìn)行適當(dāng)?shù)臄?shù)據(jù)管理的最明顯方法。

集權(quán)

那么，這種集中化方法有什么問題呢?首先它與分布式查詢引擎有什么關(guān)系?

首先，沒有什么可反對(duì)的。事實(shí)上，恰恰相反，在一個(gè)地方以清晰，新鮮的狀態(tài)構(gòu)建包含所有數(shù)據(jù)的海量數(shù)據(jù)倉(cāng)庫(kù)或數(shù)據(jù)湖通常是確保一致性的唯一方法，因此每個(gè)人使用相同的定義。在這方面，尤其是云數(shù)據(jù)湖服務(wù)，例如Microsoft的Azure Data Lake Storage或Amazon Web Service的S3，通過啟用集中化的更多優(yōu)勢(shì)而呈現(xiàn)出有趣的變化，這歸因于其非常靈活且廉價(jià)的方式來存儲(chǔ)大量任何類型的數(shù)據(jù)。

注意事項(xiàng)

但是，有很多原因使集中所有數(shù)據(jù)變得越來越困難。數(shù)據(jù)源的數(shù)量正在增長(zhǎng)，滿足依賴該數(shù)據(jù)的越來越多的不同業(yè)務(wù)領(lǐng)域所需的數(shù)據(jù)集的多功能性也在不斷增長(zhǎng)。通常，與靜態(tài)預(yù)建數(shù)據(jù)集相反，業(yè)務(wù)用戶越來越接近需要更高靈活性的數(shù)據(jù)。高級(jí)分析用例也是如此，通常需要對(duì)原始和未轉(zhuǎn)換的數(shù)據(jù)應(yīng)用方法。而且，在某些情況下，由于任何內(nèi)部或外部法規(guī)，甚至禁止組織遷移數(shù)據(jù)。在其他情況下，在集中式數(shù)據(jù)之上仍然存在管道，可將其進(jìn)一步加載到任何下游系統(tǒng)中，以滿足所有分析要求。反過來，這甚至可能導(dǎo)致與傳統(tǒng)本地系統(tǒng)相同的鎖定。或集中數(shù)據(jù)不足以證明所涉及的工作合理的用例，或者數(shù)據(jù)太大而移動(dòng)所需的時(shí)間太長(zhǎng)的用例。依此類推…

那么在這種情況下該怎么辦?

聯(lián)邦

如今，在分析解決方案及其數(shù)據(jù)管理方面有很多選擇。不僅包括其報(bào)價(jià)的不同提供商，而且種類繁多的技術(shù)都勢(shì)不可擋，技術(shù)進(jìn)步的步伐比以往更快。也沒有一個(gè)明確的贏家，他們無疑將幫助將更多的數(shù)據(jù)卡路里轉(zhuǎn)化為有用的東西，這毫無疑問。但是，基于SQL的分布式查詢引擎確實(shí)確實(shí)存在明顯的趨勢(shì)，有助于應(yīng)對(duì)數(shù)據(jù)爆炸。這也證實(shí)了現(xiàn)有數(shù)據(jù)和分析服務(wù)提供商的產(chǎn)品陣容及其最新發(fā)展。他們都試圖無縫集成那些具有成本效益的云存儲(chǔ)，并允許使用完全一樣的查詢引擎在其上進(jìn)行交互式SQL查詢。因此，它們可以填補(bǔ)上述缺失的空白，并允許成熟的企業(yè)通過保持核心事實(shí)，在保持組織和平臺(tái)穩(wěn)定性的同時(shí)實(shí)現(xiàn)擴(kuò)展的大數(shù)據(jù)功能。

數(shù)據(jù)虛擬化

分布式查詢引擎背后的基本思想無非就是數(shù)據(jù)虛擬化以及創(chuàng)建抽象層的嘗試，該抽象層提供了跨不同數(shù)據(jù)源的數(shù)據(jù)訪問。與傳統(tǒng)的數(shù)據(jù)虛擬化軟件(鏈接服務(wù)器，DBLink等)的區(qū)別在于，您可以橫向擴(kuò)展方式一起查詢關(guān)系和非關(guān)系數(shù)據(jù)，以提高查詢性能。因此，分布式一詞不僅指查詢本身，還指計(jì)算和存儲(chǔ)。它們基本上是針對(duì)密集型OLAP查詢而設(shè)計(jì)的，因此在性能方面并不是那么脆弱和不一致。

Hadoop上的SQL

用于此目的的技術(shù)最初或仍然經(jīng)常被稱為基于Hadoop的SQL-on-Hadoop，它依賴于MPP(大規(guī)模并行處理)引擎。它允許使用熟悉的類似于SQL的語言查詢和分析存儲(chǔ)在HDFS(Hadoop分布式文件系統(tǒng))上的數(shù)據(jù)，以隱藏MapReduce / Tez的復(fù)雜性，并使數(shù)據(jù)庫(kù)開發(fā)人員更易于訪問。 Hive可以說是Hadoop上的第一個(gè)SQL引擎，并且由于多年來的發(fā)展已被證明具有非常強(qiáng)大的功能，因此Hive仍被廣泛用于批處理式數(shù)據(jù)處理。 Hive將SQL查詢轉(zhuǎn)換為多個(gè)階段，并將中間結(jié)果存儲(chǔ)到磁盤中。同時(shí)，在Hadoop生態(tài)系統(tǒng)中原生開發(fā)了其他專用工具，例如Impala，還支持將HBase用作數(shù)據(jù)源。與Hive相比，它利用了內(nèi)存和緩存技術(shù)，與長(zhǎng)期運(yùn)行的批處理作業(yè)相比，它更適合用于交互式分析-此類別中的另一個(gè)示例是SparkSQL。所有這些都需要預(yù)先完成的元數(shù)據(jù)定義，也稱為讀取模式，例如視圖或外部表。此定義存儲(chǔ)在集中存儲(chǔ)中，例如Hive metastore。

SQL-on-Anything

隨著技術(shù)的發(fā)展，需要更多的開放性，并且不嚴(yán)格與Hadoop捆綁在一起，而是以松散耦合的方式支持許多其他種類的其他數(shù)據(jù)庫(kù)。這樣，查詢引擎無需大量的先決條件和準(zhǔn)備工作即可在大量數(shù)據(jù)上實(shí)現(xiàn)即插即用發(fā)現(xiàn)。此外，還提供了標(biāo)準(zhǔn)ANSI SQL作為接口，使數(shù)據(jù)分析人員和開發(fā)人員可以更輕松地訪問它。同時(shí)，不再需要預(yù)先定義架構(gòu)，某些引擎甚至可以通過下推查詢(例如Drill)在原始存儲(chǔ)層自動(dòng)解析它。該領(lǐng)域的另一個(gè)開拓性工具是Presto，它甚至可以查詢來自Kafka和Redis的實(shí)時(shí)流數(shù)據(jù)。 Presto是Facebook專門為滿足此需求而開發(fā)的一種內(nèi)存中分布式SQL查詢引擎，可在不同的數(shù)據(jù)集中進(jìn)行交互式分析。對(duì)于Netflix，Twitter，Airbnb或Uber等公司而言，這對(duì)于他們的日常業(yè)務(wù)至關(guān)重要，否則它們將無法處理和分析PB級(jí)的數(shù)據(jù)。 Presto可以與許多不同的BI工具一起使用，包括Power BI，Looker，Tableau，Superset或任何其他符合ODBC和JDBC的工具。在這種情況下，" SQL-on-Anything"這個(gè)名字終于首次被創(chuàng)造出來。

數(shù)據(jù)湖引擎

數(shù)據(jù)湖引擎的技術(shù)方法沒有太大不同。畢竟，它僅僅是數(shù)據(jù)虛擬化和合并來自不同來源的數(shù)據(jù)。它們通常在提供更多有關(guān)數(shù)據(jù)建模，數(shù)據(jù)轉(zhuǎn)換，數(shù)據(jù)行數(shù)和數(shù)據(jù)安全性的功能方面有所不同。通常，它們也更趨向于云，并且可能會(huì)認(rèn)為它們同時(shí)具有豐富的用戶界面，從而為非技術(shù)用戶帶來了一種數(shù)據(jù)自助服務(wù)理念。這種方法可以充分利用公共云中的數(shù)據(jù)集中性，并且由于云的價(jià)格彈性而可以以較低的成本進(jìn)行交互式分析，而沒有任何鎖定風(fēng)險(xiǎn)。 Data Lake Engines也不一定支持更多的數(shù)據(jù)源，但是由于延遲到來，它們可以從頭開始利用最新技術(shù)。例如，Databricks最近發(fā)布了SQL Analytics，該數(shù)據(jù)庫(kù)由其Delta引擎提供支持，可直接查詢數(shù)據(jù)湖上的Delta Lake表。此外，它為數(shù)據(jù)瀏覽提供了SQL本機(jī)接口，并且儀表板可以彼此共享。在這方面，另一個(gè)非常有前途的工具也是我最喜歡的工具之一是Dremio，它基本上是開源的，但是得到了同名公司的支持，該公司提供了具有一些附加功能的商業(yè)化企業(yè)版。

與傳統(tǒng)的多層體系結(jié)構(gòu)相反，Dremio正在BI工具和查詢的數(shù)據(jù)源系統(tǒng)之間建立直接的橋梁。幕后使用的主要技術(shù)是Drill，Arrow，Calcite和parquet。這種組合提供了適用于各種數(shù)據(jù)源的無模式SQL，以及具有下推功能的柱狀內(nèi)存分析執(zhí)行引擎，并且可以輕松實(shí)現(xiàn)查詢以提高查詢性能。順便說一句，Arrow被視為內(nèi)存分析的事實(shí)上的標(biāo)準(zhǔn)。

結(jié)論

最后，是否在物理上集中數(shù)據(jù)完全取決于用例，此類引擎通過查詢數(shù)據(jù)實(shí)際存在的位置為您提供了替代解決方案。 同樣，即使這樣的查詢引擎似乎可以適應(yīng)所有解決方案，但仍然存在無法即時(shí)解決的用例，仍然需要數(shù)據(jù)集成過程和適當(dāng)?shù)臄?shù)據(jù)建模，更不用說 基于微服務(wù)架構(gòu)的時(shí)間數(shù)據(jù)。 還需要注意的是，較早的分布式查詢引擎不會(huì)像Hive那樣迅速消失，它們?cè)谝呀?jīng)存在的許多現(xiàn)有數(shù)據(jù)體系結(jié)構(gòu)中都無法很好地發(fā)揮作用，并且與大多數(shù)最新技術(shù)無縫集成。 讓我們來看看未來會(huì)怎樣。