我们可以不再使用ETL了吗?
副问题[/!--empirenews.page--]
连年来,我们在数据科学和高级说明方面取得了一些前进,但很多项目如故回收20世纪80年月的遗留技能:萃取(extract)、转置(transform)和加载(load),也就是我们所说的ETL。这让数据架构师感想无比头疼,但我们好像又无法逾越它,那有什么要领能改变这个排场吗? 在研究ETL的取代者之前,让我们先看看这项技能的发源。上世纪80年月和90年月,跟着企业在出产数据库中蕴蓄了越来越多的事宜性数据,它们意识到必要专门的贸易智能(BI)体系来举办说明和陈诉。在很多方面,BI将“p”从头放到了企业资源筹划(ERP)中。 数据客栈有多种用途。起首,除了焦点出产体系之外,它还为毗连和说明来自多个源的数据提供了一个通用的位置。它还停止了影响支持出产ERP体系的处事器及其底层相关数据库。数据客栈是说明师研究数据和实行新设法的有用本领。 因为BI项目标数据未来自于各类来历——包罗在线事宜处理赏罚(OLTP)体系、市场营销和客户相关打点,乃至是从第三方数据署理哪里购置。因此公司必要更多专为处理赏罚数据范例和事变负载而定制的数据库软件。从Arbor Software的Essbase开始,呈现了一种新的多维数据库,用于支持在线说明处理赏罚(OLAP)事变负载。 可是将这些富厚的OLTP和客户数据迁徙到OLAP体系中并不是一项简朴的使命。出产数据库以差异的方法存储数据,对必需艰辛映射到数据客栈的列行使非凡的定名约定。个中一些源体系乃至不是相关数据库,而是专有的大型机文件体系或平面文件存储,这越发大了难度。除了事宜性数据之外,尚偶然刻序列和地理数据,全部这些数据都必需颠末调解,以顺应所选择的模式。 将全部这些数据转换为数据客栈中同等且可用的名目如故是一项难题的使命。公司雇佣大量的专家和参谋来编写和维护定制的ETL剧本,这些剧本可以将数据敲入数据客栈中行使的特定模式。无论何时变动源数据库表或文件,下流ETL剧本都必要举办调解,以确保数据客栈继承提供沟通的数据。 除了ETL的维护恶梦之外,它的批处理赏罚特征是另一个很大的弱点,尤其是在只存眷当下的情形中。更新数据客栈中成千上万个表的ETL功课凡是在夜间运行,此时出产处于搁浅状态。其他时辰,公司天天运行多个ETL功课,但愿为不绝行使各类SQL查询会见数据客栈的说明师提供更奇怪、更有洞察力的看法。 尽量在ETL上耗费了大量时刻和款子,公司如故会碰着很大的题目。为了确保干净精确的数据通过ETL达到,而且防备垃圾数据填满数据客栈,应该拟定具体的流程。许多人都能敏捷完成大使命,可是当涉及到数据界说时,会有很大的坚苦。数据也会跟着时刻的推移而改变,影响说明查询的功效,使其与早期较量不再那么精确。 ETL的行使既疾苦又昂贵且轻易失败,但我们能做些什么呢?究竟上,很多公司已采纳各类要领来办理这一困难。以下是停止ETL的四种也许要领。 1. 归并OLTP和OLAP 假如ETL是您的疾苦之源,那么可以停止它的一种要领是在沟通的体系上运行全部内容。这种要领最好的例子是SAP的HANA,它最初是一个超快的内存说明数据库,此刻已经生长为ERP营业套件方面的焦点事宜数据库。听说,这家德国软件巨头的整个营业包罗OTP和OLAP都在一个相对较小的体系上运行。它并没有完全消除对ETL的需求,可是它最小化了也许堕落的范畴。 现在,很多新的扩展相关数据库还倡导行使“translytical”要领归并操纵和说明操纵,以加速处理赏罚时刻。像Aersospike、MemSQL、Splice Machine和VoltDB这样的供给商,将集群架构和内存处理赏罚团结起来,以支持很是快速的SQL查询处理赏罚,足以支持Web和移动应用措施并对它们举办及时说明(但不必然是像ERP这样的焦点营业应用措施)。 Forrester说明师Noel Yuhanna和Mike Gualtieri在2015年暗示传统的ETL流程无法实现及时变动。Translytical降服了这一挑衅,为要害营业数据提供了及时、靠得住的视图,确保信息来历精确以及整个组织的同等性。 Garter支持一种相同于殽杂事宜说明(HTAP)的要领。 NoSQL数据库供给商Couchbase通过其嵌入式SQL ++引擎支持这种要领用于查询JSON数据,亚马逊也是云云。 2. 给ELT一个机遇 ETL中一个受接待的转折是改变处理赏罚次序。不是在ETL进程中举办全部重要的数据转换,而是在将其加载到数据客栈之后再举办转换——因此是ELT而不是ETL。这种要领在更当代的数据湖中很风行,在当代数据湖中,数据语义和模式不像在传统数据客栈中那样严酷执行(假如它们被逼迫执行的话)。 ELT在Hadoop中很受接待,在Hadoop中,客户可以快速地存储大量原始数据,然后在稍后运行大量批处理赏罚事变,为后续处理赏罚(包罗SQL说明和呆板进修)筹备数据。 假如您的数据工程师正在行使Apache Spark为下流数据科学和说明事变负载开拓数据转换管道,那么您必然会大吃一惊。由于他现实上是在编写ELT事变,这是Spark最大的用例之一。Spark背后的Databricks公司于2017年推出了Delta,可以说是ELT和数据转换即处事。ELT要领也用于一些NoSQL数据库。 3.及时流式ETL 一些公司回收的是流式ETL要领,而不是过后批量转换数据,即数据达到现场后不绝举办处理赏罚和细化。这种要领也许不合用于传统的ERP数据,但对付处理赏罚不绝增添的Web和移动应用措施数据(本质上是时刻序列)来说,它也许是绝对须要的。 通过在数据达到时直接处理赏罚数据,开拓职员可以停止在一个单独的ETL阶段来处理赏罚数据。本质上说,这就是Apache Storm的建设者Nathan Marz在2011年提出的Lambda架构,个中一个加快层 (Storm)可以快速处理赏罚数据,但也许不是100%精确,而批处理赏罚层 (Hadoop)可以在稍后修复任何错误。 Apache Kafka的连系创作者Jay Kreps在构想Kappa架构时也想到了相同的办理方案,这是Lambda的一个精简版本,不包括单独的加快和批处理赏罚层。相反,Kafka在流媒体变乱数据天生进程中饰演着焦点脚色。 4. 直接数据映射 (编辑:湖南网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |