可以停止搞 ETL 了吗?

来源:QQ快报
责任编辑:王亮
字体:

作者:Alex Woodie是IT外媒Datanami的执行总编

尽管近年来我们在数据科学和高级分析领域已取得了进步,但许多项目仍然有赖于源自上世纪80年代的一项技术:提取、转换和加载(ETL)。不可思议的是,无论这三个字母如何让数据架构师不寒而栗,但我们似乎无力超越它。有没有什么办法或技术可以让我们摆脱ETL的弊端?

在考虑有可能接替ETL的技术之前,不妨看看这项技术的起源。由于上世纪八九十年代许多公司在生产数据库中积累了越来越多的事务型数据,它们意识到需要专门的商业智能(BI)系统用于分析和报告。从许多方面来看,BI正是企业资源规划(ERP)的基础。

数据仓库有多个用途。首先,除了核心生产系统外,它还为结合和分析来自多个来源的数据提供了一个多功能的场所。它还避免了影响幕后支持ERP系统及底层关系数据库的服务器。数据仓库还充当了分析员研读数据和尝试新想法的环境。

由于BI项目的数据来自多个来源,包括联机事务处理(OLTP)系统、营销及客户关系管理系统,或甚至从第三方数据代理商购买而来,公司企业需要更多量身定制的数据库软件,这类软件是为处理数据类型和工作负载而专门设计的。从Arbor Software的Essbase开始,涌现出了一类新的多维数据库,以支持联机分析处理(OLAP)工作负载。

但是,将这种丰富的OLTP和客户数据迁移到OLAP系统并非简单的任务。生产数据库以不同的方式存储数据,对于必须精心映射到数据仓库的列有特殊的命名约定(尤其要强调的是,映射起来“很痛苦”)。一些源系统甚至不是关系数据库,而是专有的大型机文件系统或平面文件存储方法,它们更是提高了要求。而除了事务数据外,还有时间序列数据和地理数据,所有这些数据都必须加以处理(整形和改动),才能符合所选择的模式(schema)。

将所有这些数据转换成数据仓库中一致可用的格式仍然是一项繁重的工作。许多公司雇用大批专家和顾问来编写和维护自定义ETL脚本,这些脚本可以将数据处理成数据仓库中使用的特定模式。每当源数据库表或文件有所改变,下游ETL脚本都需要调整,以确保数据仓库继续提供相同的结果。首席财务官们(CFO)睡觉都会梦到大把花钱,但没有人听到他们无声的尖叫。

除了ETL的维护噩梦外,它的批处理特性是另一个大缺点,在注重实时性的当下尤其如此。更新数据仓库中数千乃至数百万个表的ETL作业通常在夜间运行,生产在夜间处于暂停状态。其他时候,公司每天运行多个ETL作业,希望能够为不断针对数据仓库执行各种SQL查询的分析员提供更新颖、更宝贵的洞察力。

尽管许多公司在ETL上花了大量的时间和金钱,仍遇到大问题。为确保只有干净准确的数据通过ETL管道传输实施了精心设计的流程,但这些流程不尽如人意、不准确,脏数据淹没了数据仓库。许多人快速完成大任务,但是在数据定义方面让不同的利益相关者意见一致导致了“真相的多个版本”综合症。数据还会随着时间的推移而漂移,导致分析查询的结果发生偏差,并使与较早时期的比较不太准确。

ETL痛苦、烧钱还容易失败,那么我们对此该如何是好?事实上,许多公司已采取了各种方法来解决这一难题。下面是有望绕过ETL的四个方法。

合并OLTP和OLAP

如果ETL是贵公司赖以生存的基础,可以开始修复它的一个方法是,在同一个系统上运行所有东西。这种方法的最佳例子是SAP的HANA,它起初是一种超快速的内存分析数据库,此后发展成为ERP Business Suite方面的核心事务数据库。据说这家德国软件巨头在一个相对微不足道的系统上运行其整个业务:OTP和OLAP。虽然它没有完全杜绝对ETL的需要,但最大限度地缩小了可能出错的范围。

两个数据库合并为一个(图片来源:Dima Zel / Shutterstock)

今天许多新的横向扩展型关系数据库也提倡以一种“集事务和分析性能于一体”(translytical)的方法合并运营操作和分析操作,以缩短获取洞察力的时间。Aersospike、MemSQL、Splice Machine和VoltDB等供应商结合集群架构和内存处理,实现非常快速的SQL查询处理,快得足以支持Web和移动应用程序,并对它们进行实时分析(但不一定是针对EPR之类的核心业务应用程序)。

市场研究公司Forrester的两位分析师Noel Yuhanna和Mike Gualtieri早在2015年就写道:“传统的[ETL]流程无法支持实时变更。集事务和分析性能于一体的流程克服了这个挑战,它针对关键业务数据提供了实时可信的视图,确保信息源准确,从而保证数据在整个组织的一致性。”

另一家市场研究公司Gartner支持一种名为混合事务分析(HTAP)的类似方法,HTAP完成了同一项任务的大部分工作。NoSQL数据库供应商Couchbase凭借用于查询JSON数据的嵌入式SQL++引擎支持这种方法,亚马逊现在也亦步亦趋。

尝试一下ELT

ETL的一个流行变种是换一下处理顺序。不是在ETL过程的当中进行所有重要的数据转换,而是在数据加载到数据仓库之后进行转换,ELT由此而来。这种方法在较现代的数据湖当中大受欢迎;在现代数据湖中,数据语义和模式的执行不如在传统数据仓库中那么严格(如果它们执行的话)。

ELT在Hadoop当中颇受欢迎,客户可以快速存储大量原始数据,然后在以后运行大量批量转换作业,准备好数据供下游处理所用,包括SQL分析和机器学习。

如果你的数据工程师在使用Apache Spark为下游数据科学和分析工作负载开发数据转换管道,你会感到惊讶!他实际上在编写ELT作业,这是Spark最主要的使用场景之一。2017年,Spark背后的公司Databricks推出了Delta,这基本上是ELT和数据转换即服务。ELT方法还与一些NoSQL数据库结合使用。

实时数据流ETL

Lambda架构由速度层和批处理层组成

一些公司不是以批处理方式事后转换数据,而是采用了数据流ETL方法,即数据到达时不断加以处理和改进。这种方法可能不适用于传统的ERP类型数据,但它对于处理来自Web和移动应用程序的不断增长的数据量(基本上是时间序列数据)而言却变得绝对必不可少。

通过数据到达时直接处理数据,开发人员可以避免需要单独的ETL阶段来处理数据。这实际上是Apache Storm的开发者Nathan Marz早在2011年从理论上说明的Lambda架构,其中速度层(Storm)快速处理数据,但可能不是百分之百准确,而批处理层(Hadoop)会在以后修复任何错误。

Apache Kafka的共同开发者Jay Kreps在酝酿Kappa架构时想到了类似的解决方案,Kappa架构是一种简化版本的Lambda,不包括单独的速度层和批处理层。相反,Kafka在处理实时生成的流式事件数据方面起到了关键作用。

直接数据映射

尽量避免ETL的另一个方法名为直接数据映射,即源数据直接在其所在的位置查询,而不是将其移动到数据仓库。这是Incorta力挺的方法,几年前Oracle前高管Osama Elkady创办了这家公司。

Incorta的直接数据映射方法仍然要求用户将数据移动到数据湖,比如HDFS、S3或Azure Data Lake,数据在数据湖中作为高度压缩的Parquet文件存储起来。但通过在“提取”步骤和“加载”步骤之间注入元数据标签,该方法可以让客户跳过“转换”步骤。

Elkady告诉IT外媒Datanami:“Incorta只是想说,如果我们将数据按原状加载到另一个仅用于分析的数据库,会怎样?如果我们按原状获取数据,而不必对数据进行扁平处理,又会怎样。查询时间从几小时缩短至几秒。”

Incorta的方法大有希望,最近完成3000万美元的C轮融资足以说明这一点。这家硅谷公司吸引了多个大客户,包括苹果、博通和星巴克,星巴克使用其软件来加快店内销售分析。Elkady说:“如果他们无法实时查看运营数据,无论是生产业务、还是零售业务还是仓库管理,都会给客户带来数百万美元的损失。”

对ETL而言没有灵丹妙药,也无法完全避开ETL带来的痛苦。除非我们拥有完全融合的系统都使用相同的一致数据格式,否则将来仍需要获取来自某个地方的数据,针对目的地准备好数据,然后加载数据。不过借助一番创造力,替代方法表明:新的数据转换方法有助于消除ETL带来的一些痛苦。

请注意:本文转载自QQ快报,并不代表本网赞同其观点,版权归原作者所有,本网不承担任何责任,特此声明。

根据您访问的内容,您可能还对以下内容感兴趣,希望对您有帮助:

会话“ReadyBoot”已停止,原因是存在以下错误: 0xC0...

答:你好,ReadyBoot是其实是一个日志信息,当位于C:\Windows\Prefetch\ReadyBoot文件夹中的ReadyBoot.etl这个日志文件大小已经到达20M的时候,就可能会产生这个错误。 你可试试在“控制面板”/“管理工具”/“性能监视器”中展开数据收集器集,点击启动事...

声明:以上内容由用户提供,并不代表本网赞同其观点。如有任何不妥,请与不良与违法信息举报中心联系:513175919@qq.com

www.book1234.com true http://www.book1234.com/q/20190910/20190910A0REOB00.html report 26999
娱乐时尚
科技资讯
历史文化
真视界
旅游美食
精彩图文
我爱我车
母婴健康
关于本站 | 广告服务 | 手机版 | 商务合作 | 免责申明 | 招聘信息 | 联系我们
Copyright © 2004-2018 book1234.com All Rights Reserved. 布客网 版权所有
京ICP备10044368号-1 京公网安备11010802011102号