时间: 2020-09-03 00:08:26 人气: 2276 评论: 0
数据量的增加推动了技术的更新和范式的变化。与此同时,SQL仍然是主流。随着数据的增长和复杂性的增加,SQL比以往任何时候都更适合分析和转换数据湖中的数据。本文探讨了如何将SQL用于数据湖和新的数据生态系统。本文要点:随着数据的增长和复杂性的增加,SQL比以往任何时候都更适合分析和转换数据湖中的数据。
本文最初发布于TowardsDataScience,经原作者授权由InfoQ中文站翻译并分享。
NoSQL数据库的出现带来了巨大的可伸缩性和简单性。
如果我们必须高速处理大量的数据,我们会被告知NoSQL是唯一的出路。供应商一直在喋喋不休地讨论SQL和中间件代码之间的阻抗失配问题。
现在我们发现,大多数NoSQL供应商在花了几年时间来贬低连接之后,都引入了SQL层。一些供应商还引入了SQL方言,使情况变得更糟。
在NoSQL上引入这个SQL层似乎是出于对新一代数据库的恐惧,比如谷歌Spanner,以及提供JSON、XML作为一等数据类型的数据库供应商。
Hadoop为开发人员提供了map-reduce接口,这带来了一些巨大的进步,但同时也带来了很多问题(见DeWitt和Stonebraker的文章MapReduce:一次大倒退)。
在Hadoop上使用map-reduce处理数据还有很多需要改进的地方。性能调优、数据倾斜处理、获得最佳吞吐量,所有这些都需要太多的裸机代码更改。
人们尝试了多种受SQL启发的方法:
经过多年的“大数据时代”,以及一些Hadoop的兼并和破产,我们现在看到了这些技术的幸存者。Hadoop技术现在更多地存在云中,而不是在本地环境中。现在,在组织中已经不经常看到完整的Cloudera或HortonWorks栈了。相反,少数几种技术蓬勃发展,现在已广泛用于云数据栈。
Stonebraker很久以前就指出,数据库的性能问题和可伸缩性与SQL关系不大,而更多地与数据库本身的设计有关(NoSQL的讨论与SQL无关)。
SQL的最大优点是它提供了熟悉性和分析数据的表达能力。SQL的健壮性以关系代数和集合理论为基础。
对于数据湖,我们可以看到以下这些技术。
在原始文件系统上存储的经济性推动了数据湖的创建。SQL被用于分析数据。
Amazon RedShift Spectrum可以查询S3数据。
Snowflake DB可以使用VARIANT列在数据库中存储XML、JSON或ORC数据,还可以使用外部表指向S3中的数据。
外部表还支持谷歌BigQuery和Azure SQL数据仓库。
数据处理的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
-深蓝源码网-www.69shenlan.com