作者：Shirish Joshi 譯者：平川 譯文來源：InfoQ 原文來源：TowardsDataScience

數(shù)據(jù)量的增加推動了技術的更新和范式的變化。與此同時，SQL 仍然是主流。隨著數(shù)據(jù)的增長和復雜性的增加，SQL 比以往任何時候都更適合分析和轉換數(shù)據(jù)湖中的數(shù)據(jù)。本文探討了如何將 SQL 用于數(shù)據(jù)湖和新的數(shù)據(jù)生態(tài)系統(tǒng)。

本文要點：隨著數(shù)據(jù)的增長和復雜性的增加，SQL 比以往任何時候都更適合分析和轉換數(shù)據(jù)湖中的數(shù)據(jù)。
 

記得 NoSQL 嗎?

NoSQL 數(shù)據(jù)庫的出現(xiàn)帶來了巨大的可伸縮性和簡單性。

如果我們必須高速處理大量的數(shù)據(jù)，我們會被告知 NoSQL 是唯一的出路。供應商一直在喋喋不休地討論 SQL 和中間件代碼之間的阻抗失配問題。

現(xiàn)在我們發(fā)現(xiàn)，大多數(shù) NoSQL 供應商在花了幾年時間來貶低連接之后，都引入了 SQL 層。一些供應商還引入了 SQL 方言，使情況變得更糟。

在 NoSQL 上引入這個 SQL 層似乎是出于對新一代數(shù)據(jù)庫的恐懼，比如谷歌 Spanner，以及提供 JSON、XML 作為一等數(shù)據(jù)類型的數(shù)據(jù)庫供應商。

Hadoop 呢?

Hadoop 為開發(fā)人員提供了 map-reduce 接口，這帶來了一些巨大的進步，但同時也帶來了很多問題(見 DeWitt 和 Stonebraker 的文章 MapReduce：一次大倒退)。

在 Hadoop 上使用 map-reduce 處理數(shù)據(jù)還有很多需要改進的地方。性能調(diào)優(yōu)、數(shù)據(jù)傾斜處理、獲得最佳吞吐量，所有這些都需要太多的裸機代碼更改。

人們嘗試了多種受 SQL 啟發(fā)的方法：

Apache Pig：類 SQL 語法、FOREACH 代替 FROM、GENERATE 代替 SELECT;

Hive: 用于 SQL-in-Hadoop 的類 MySQL 語法、將 SQL 轉換為 map-reduce;

Drill、Impala、Presto 和 Pivotal 的 HAWQ：SQL-on-Hadoop，繞過 map-reduce;

Spark SQL：SQL on Spark;

Apache Phoenix：SQL on HBase;

Hadoop 作為已有 DB 的外部表：Oracle Big Data SQL、Teradata SQL-H。

經(jīng)過多年的“大數(shù)據(jù)時代”，以及一些 Hadoop 的兼并和破產(chǎn)，我們現(xiàn)在看到了這些技術的幸存者。Hadoop 技術現(xiàn)在更多地存在云中，而不是在本地環(huán)境中�，F(xiàn)在，在組織中已經(jīng)不經(jīng)�？吹酵暾�的 Cloudera 或 HortonWorks 棧了。相反，少數(shù)幾種技術蓬勃發(fā)展，現(xiàn)在已廣泛用于云數(shù)據(jù)棧。

數(shù)據(jù)湖上的 SQL

Stonebraker 很久以前就指出，數(shù)據(jù)庫的性能問題和可伸縮性與 SQL 關系不大，而更多地與數(shù)據(jù)庫本身的設計有關( NoSQL 的討論與 SQL 無關)。

SQL 的最大優(yōu)點是它提供了熟悉性和分析數(shù)據(jù)的表達能力。SQL 的健壯性以關系代數(shù)和集合理論為基礎。

對于數(shù)據(jù)湖，我們可以看到以下這些技術。

Hive 元數(shù)據(jù)存儲是人們喜愛的數(shù)據(jù)目錄。

在 SQL 層，Presto 作為一個查詢層脫穎而出，并在 Amazon Athena、Google Cloud DataProc、Qubole 中得到了廣泛應用。

Spark 和 Spark SQL 的應用也很廣泛。

Hadoop 文件系統(tǒng)(HDFS)用的不那么多了，云存儲(Azure Blob、谷歌云存儲、AWS S3)更受歡迎，CSV、Avro 和 Parquet 文件格式也更受歡迎了。

云數(shù)據(jù)倉庫和數(shù)據(jù)湖

在原始文件系統(tǒng)上存儲的經(jīng)濟性推動了數(shù)據(jù)湖的創(chuàng)建。SQL 被用于分析數(shù)據(jù)。

Amazon RedShift Spectrum 可以查詢 S3 數(shù)據(jù)。

Snowflake DB 可以使用 VARIANT 列在數(shù)據(jù)庫中存儲 XML、JSON 或 ORC 數(shù)據(jù)，還可以使用外部表指向 S3 中的數(shù)據(jù)。

外部表還支持谷歌 BigQuery 和 Azure SQL 數(shù)據(jù)倉庫。

SQL 和 ELT (提取 加載 轉換)

數(shù)據(jù)處理的ELT(提取 加載 轉換)范式將數(shù)據(jù)轉換步驟放在最后。首先從源系統(tǒng)提取數(shù)據(jù)并將其加載到數(shù)據(jù)庫中。

舊的ETL方法 RBAR(逐行處理)與關系數(shù)據(jù)庫執(zhí)行的基于集合的處理形成了直接的對比，而基于集合的處理構成了 SQL 的基礎。

在ELT中，我們現(xiàn)在從源數(shù)據(jù)庫中提取數(shù)據(jù)并將其放入數(shù)據(jù)湖中。

SQL 轉換在云數(shù)據(jù)倉庫或使用 Presto 完成，并將轉換后的數(shù)據(jù)加載到目標表。

通過 GoldenGate、AWS DMS，或者使用 Workato/Jitterbit/StitchData 等工具或 Kafka 等健壯的事件管道，一點點地向數(shù)據(jù)湖或數(shù)據(jù)倉庫輸送數(shù)據(jù)。將源系統(tǒng)和加載區(qū)域之間的轉換最小化。然后使用 SQL 將這些數(shù)據(jù)轉換并加載到倉庫和分析層。

ELT工具鏈使用 DAG(有向無環(huán)圖)工具，如 Apache AirFlow 和無服務器函數(shù)，而不是舊的ETL工具鏈中類似 AutoSys 這樣的調(diào)度器。

DBT 是在轉換領域流行的另一個工具。像 FiveTran 和 Matillion 這樣的云數(shù)據(jù)處理工具也使用 SQL 和 ELT。Domo 序列化 SQL 來創(chuàng)建轉換管道。Looker 基于 LookML 生成 SQL。

原文鏈接

https://towardsdatascience.com/data-lakes-and-sql-49084512dd70

標簽： 數(shù)據(jù)湖 SQL

版權申明：本站文章部分自網(wǎng)絡，如有侵權，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權歸原作者所有，如需使用，請與原作者聯(lián)系。