基於sql的查詢引擎簡介，包括指向資料倉儲和資料湖的鏈結
從高層的角度來看，許多資料和分析解決方案已經以相同的方式構建了許多年。 簡而言之，它由各種整合過程組成，可將所有資料載入到乙個**位置，這是即將到來的資料建模和分析用例的唯一事實**。 雖然在較早的日子裡，這些中心位置大多是昂貴的且不靈活的緊密耦合的硬體/軟體系統，但如今通常會利用雲和分布式架構，包括計算和儲存的分離。 然而，儘管近年來取得了巨大的技術進步，但集中資料的整體方法仍然是最有效地利用其資料並進行適當的資料管理的最明顯方法。
那麼，這種集中化方法有什麼問題呢？首先它與分布式查詢引擎有什麼關係？
首先，沒有什麼可反對的。事實上，恰恰相反，在乙個地方以清晰，新鮮的狀態構建包含所有資料的海量資料倉儲或資料湖通常是確保一致性的唯一方法，因此每個人使用相同的定義。在這方面，尤其是雲資料湖服務，例如microsoft的azure data lake storage或amazon web service的s3，通過啟用集中化的更多優勢而呈現出有趣的變化，這歸因於其非常靈活且廉價的方式來儲存大量任何型別的資料。
但是，有很多原因使集中所有資料變得越來越困難。資料來源的數量正在增長，滿足依賴該資料的越來越多的不同業務領域所需的資料集的多功能性也在不斷增長。通常，與靜態預建資料集相反，業務使用者越來越接近需要更高靈活性的資料。高階分析用例也是如此，通常需要對原始和未轉換的資料應用方法。而且，在某些情況下，由於任何內部或外部法規，甚至禁止組織遷移資料。在其他情況下，在集中式資料之上仍然存在管道，可將其進一步載入到任何下游系統中，以滿足所有分析要求。反過來，這甚至可能導致與傳統本地系統相同的鎖定。或集中資料不足以證明所涉及的工作合理的用例，或者資料太大而移動所需的時間太長的用例。依此類推…
那麼在這種情況下該怎麼辦？
如今，在分析解決方案及其資料管理方面有很多選擇。不僅包括其**的不同提供商，而且種類繁多的技術都勢不可擋，技術進步的步伐比以往更快。也沒有乙個明確的贏家，他們無疑將幫助將更多的資料卡路里轉化為有用的東西，這毫無疑問。但是，基於sql的分布式查詢引擎確實確實存在明顯的趨勢，有助於應對資料**。這也證實了現有資料和分析服務提供商的產品陣容及其最新發展。他們都試圖無縫整合那些具有成本效益的雲儲存，並允許使用完全一樣的查詢引擎在其上進行互動式sql查詢。因此，它們可以填補上述缺失的空白，並允許成熟的企業通過保持核心事實，在保持組織和平台穩定性的同時實現擴充套件的大資料功能。
分布式查詢引擎背後的基本思想無非就是資料虛擬化以及建立抽象層的嘗試，該抽象層提供了跨不同資料來源的資料訪問。與傳統的資料虛擬化軟體(鏈結伺服器，dblink等)的區別在於，您可以橫向擴充套件方式一起查詢關係和非關係資料，以提高查詢效能。因此，分布式一詞不僅指查詢本身，還指計算和儲存。它們基本上是針對密集型olap查詢而設計的，因此在效能方面並不是那麼脆弱和不一致。
用於此目的的技術最初或仍然經常被稱為基於hadoop的sql-on-hadoop，它依賴於mpp(大規模並行處理)引擎。它允許使用熟悉的類似於sql的語言查詢和分析儲存在hdfs(hadoop分布式檔案系統)上的資料，以隱藏mapreduce / tez的複雜性，並使資料庫開發人員更易於訪問。 hive可以說是hadoop上的第乙個sql引擎，並且由於多年來的發展已被證明具有非常強大的功能，因此hive仍被廣泛用於批處理式資料處理。 hive將sql查詢轉換為多個階段，並將中間結果儲存到磁碟中。同時，在hadoop生態系統中原生開發了其他專用工具，例如impala，還支援將hbase用作資料來源。與hive相比，它利用了記憶體和快取技術，與長期執行的批處理作業相比，它更適合用於互動式分析-此類別中的另乙個示例是sparksql。所有這些都需要預先完成的元資料定義，也稱為讀取模式，例如檢視或外部表。此定義儲存在集中儲存中，例如hive metastore。
隨著技術的發展，需要更多的開放性，並且不嚴格與hadoop**在一起，而是以鬆散耦合的方式支援許多其他種類的其他資料庫。這樣，查詢引擎無需大量的先決條件和準備工作即可在大量資料上實現即插即用發現。此外，還提供了標準ansi sql作為介面，使資料分析人員和開發人員可以更輕鬆地訪問它。同時，不再需要預先定義架構，某些引擎甚至可以通過下推查詢(例如drill)在原始儲存層自動解析它。該領域的另乙個開拓***是presto，它甚至可以查詢來自kafka和redis的實時流資料。 presto是facebook專門為滿足此需求而開發的一種記憶體中分布式sql查詢引擎，可在不同的資料集中進行互動式分析。對於netflix，twitter，airbnb或uber等公司而言，這對於他們的日常業務至關重要，否則它們將無法處理和分析pb級的資料。 presto可以與許多不同的bi工具一起使用，包括power bi，looker，tableau，superset或任何其他符合odbc和jdbc的工具。在這種情況下，" sql-on-anything"這個名字終於首次被創造出來。
資料湖引擎的技術方法沒有太大不同。畢竟，它僅僅是資料虛擬化和合併來自不同**的資料。它們通常在提供更多有關資料建模，資料轉換，資料行數和資料安全性的功能方面有所不同。通常，它們也更趨向於雲，並且可能會認為它們同時具有豐富的使用者介面，從而為非技術使用者帶來了一種資料自助服務理念。這種方法可以充分利用公共雲中的資料集中性，並且由於雲的**彈性而可以以較低的成本進行互動式分析，而沒有任何鎖定風險。 data lake engines也不一定支援更多的資料來源，但是由於延遲到來，它們可以從頭開始利用最新技術。例如，databricks最近發布了sql analytics，該資料庫由其delta引擎提供支援，可直接查詢資料湖上的delta lake表。此外，它為資料瀏覽提供了sql本機介面，並且儀表板可以彼此共享。在這方面，另乙個非常有前途的工具也是我最喜歡的工具之一是dremio，它基本上是開源的，但是得到了同名公司的支援，該公司提供了具有一些附加功能的商業化企業版。
與傳統的多層體系結構相反，dremio正在bi工具和查詢的資料來源系統之間建立直接的橋梁。幕後使用的主要技術是drill，arrow，calcite和parquet。這種組合提供了適用於各種資料來源的無模式sql，以及具有下推功能的柱狀記憶體分析執行引擎，並且可以輕鬆實現查詢以提高查詢效能。順便說一句，arrow被視為記憶體分析的事實上的標準。
最後，是否在物理上集中資料完全取決於用例，此類引擎通過查詢資料實際存在的位置為您提供了替代解決方案。 同樣，即使這樣的查詢引擎似乎可以適應所有解決方案，但仍然存在無法即時解決的用例，仍然需要資料整合過程和適當的資料建模，更不用說 基於微服務架構的時間資料。 還需要注意的是，較早的分布式查詢引擎不會像hive那樣迅速消失，它們在已經存在的許多現有資料體系結構中都無法很好地發揮作用，並且與大多數最新技術無縫整合。 讓我們來看看未來會怎樣。
sql 分布式查詢
遠端鏈結伺服器機器名 roy 例項名 roy sql2005de 登陸名 sa 密碼 test2005 建立鏈結伺服器 exec master.dbo.sp addlinkedserver server n roy lnk srvproduct n provider n sqloledb datas...
SQL分布式查詢
測試檔案內容 e module test.xls job desc job id max lvl min lvl 記錄一 1.0 11.0 11.0 記錄二 2.0 22.0 22.0 記錄三 3.0 33.0 33.0 記錄四 4.0 44.0 44.0 e module temp.mdb檔案jo...
sql分布式查詢
建立鏈結伺服器 exec sp addlinkedserver itsv sqloledb 192.168.0.88 exec sp addlinkedsrvlogin itsv false null user emenudata2fortesting sa exec sp addlinkedser...