数据湖和SQL并不矛盾
作者:Shirish Joshi 译者:平川 译文来源:InfoQ 原文来源:TowardsDataScience
数据量的增加推动了技术的更新和范式的变化。与此同时,SQL 仍然是主流。随着数据的增长和复杂性的增加,SQL 比以往任何时候都更适合分析和转换数据湖中的数据。本文探讨了如何将 SQL 用于数据湖和新的数据生态系统。
本文要点:随着数据的增长和复杂性的增加,SQL 比以往任何时候都更适合分析和转换数据湖中的数据。
记得 NoSQL 吗?
NoSQL 数据库的出现带来了巨大的可伸缩性和简单性。
如果我们必须高速处理大量的数据,我们会被告知 NoSQL 是唯一的出路。供应商一直在喋喋不休地讨论 SQL 和中间件代码之间的阻抗失配问题。
现在我们发现,大多数 NoSQL 供应商在花了几年时间来贬低连接之后,都引入了 SQL 层。一些供应商还引入了 SQL 方言,使情况变得更糟。
在 NoSQL 上引入这个 SQL 层似乎是出于对新一代数据库的恐惧,比如谷歌 Spanner,以及提供 JSON、XML 作为一等数据类型的数据库供应商。
Hadoop 呢?
Hadoop 为开发人员提供了 map-reduce 接口,这带来了一些巨大的进步,但同时也带来了很多问题(见 DeWitt 和 Stonebraker 的文章 MapReduce:一次大倒退)。
在 Hadoop 上使用 map-reduce 处理数据还有很多需要改进的地方。性能调优、数据倾斜处理、获得最佳吞吐量,所有这些都需要太多的裸机代码更改。
人们尝试了多种受 SQL 启发的方法:
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。
经过多年的“大数据时代”,以及一些 Hadoop 的兼并和破产,我们现在看到了这些技术的幸存者。Hadoop 技术现在更多地存在云中,而不是在本地环境中。现在,在组织中已经不经常看到完整的 Cloudera 或 HortonWorks 栈了。相反,少数几种技术蓬勃发展,现在已广泛用于云数据栈。
数据湖上的 SQL
Stonebraker 很久以前就指出,数据库的性能问题和可伸缩性与 SQL 关系不大,而更多地与数据库本身的设计有关( NoSQL 的讨论与 SQL 无关)。
SQL 的最大优点是它提供了熟悉性和分析数据的表达能力。SQL 的健壮性以关系代数和集合理论为基础。
对于数据湖,我们可以看到以下这些技术。
Hive 元数据存储是人们喜爱的数据目录。
在 SQL 层,Presto 作为一个查询层脱颖而出,并在 Amazon Athena、Google Cloud DataProc、Qubole 中得到了广泛应用。
Spark 和 Spark SQL 的应用也很广泛。
Hadoop 文件系统(HDFS)用的不那么多了,云存储(Azure Blob、谷歌云存储、AWS S3)更受欢迎,CSV、Avro 和 Parquet 文件格式也更受欢迎了。
云数据仓库和数据湖
在原始文件系统上存储的经济性推动了数据湖的创建。SQL 被用于分析数据。
Amazon RedShift Spectrum 可以查询 S3 数据。
Snowflake DB 可以使用 VARIANT 列在数据库中存储 XML、JSON 或 ORC 数据,还可以使用外部表指向 S3 中的数据。
外部表还支持谷歌 BigQuery 和 Azure SQL 数据仓库。
SQL 和 ELT (提取 加载 转换)
数据处理的ELT(提取 加载 转换)范式将数据转换步骤放在最后。首先从源系统提取数据并将其加载到数据库中。
旧的ETL方法 RBAR(逐行处理)与关系数据库执行的基于集合的处理形成了直接的对比,而基于集合的处理构成了 SQL 的基础。
在ELT中,我们现在从源数据库中提取数据并将其放入数据湖中。
SQL 转换在云数据仓库或使用 Presto 完成,并将转换后的数据加载到目标表。
通过 GoldenGate、AWS DMS,或者使用 Workato/Jitterbit/StitchData 等工具或 Kafka 等健壮的事件管道,一点点地向数据湖或数据仓库输送数据。将源系统和加载区域之间的转换最小化。然后使用 SQL 将这些数据转换并加载到仓库和分析层。
ELT工具链使用 DAG(有向无环图)工具,如 Apache AirFlow 和无服务器函数,而不是旧的ETL工具链中类似 AutoSys 这样的调度器。
DBT 是在转换领域流行的另一个工具。像 FiveTran 和 Matillion 这样的云数据处理工具也使用 SQL 和 ELT。Domo 序列化 SQL 来创建转换管道。Looker 基于 LookML 生成 SQL。
原文链接
https://towardsdatascience.com/data-lakes-and-sql-49084512dd70
时间:2020-01-11 23:13 来源: 转发量:次
声明:本站部分作品是由网友自主投稿和发布、编辑整理上传,对此类作品本站仅提供交流平台,转载的目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,不为其版权负责。如果您发现网站上有侵犯您的知识产权的作品,请与我们取得联系,我们会及时修改或删除。
相关文章:
- [数据挖掘]MySQL vs Redis,新时代王者的较量
- [数据挖掘]在复杂条件搜索上,为什么MySQL只能被ES吊打?
- [数据挖掘]MySQL 8.0的Public Key Retrival错误,毫无规律可言怎么
- [数据挖掘]50年长盛不衰,SQL为什么如此成功?
- [数据挖掘]吊打MySQL,MariaDB到底强在哪?
- [数据挖掘]50年长盛不衰,SQL为什么如此成功?
- [数据挖掘]为什么阿里不建议MySQL使用text类型?
- [数据挖掘]“MySQL Analytics Engine”来了
- [数据挖掘]惊了! MySQL 热冷数据分离设计还能这样!
- [数据挖掘]MySQL 的慢 SQL 该怎么优化?
相关推荐:
网友评论: