etl工程师和数据分析师的区别

etl工程师和数据分析师的区别,第1张

二者主要负责的工作内容不同。

etl工程师主要负责数据的接入,清洗,入库,能够保证业务人员使用。数据分析师主要负责数据监控,异动归因,以及数据的其他问题。

ETL工程师又叫数据库工程师。ETL工程师的主要工作内容有:从事系统编程、数据库编程与设计。数据分析师指的是不同行业中,专门从事行业数据搜集、整理、分析,并依据数据做出行业研究,评估和预测的专业人员。

对于做过 BI 开发的朋友,ETL 并不陌生,只要涉及到数据源的数据抽取、数据的计算和处理过程的开发,都是 ETL,ETL 就这三个阶段,Extraction 抽取,Transformation 转换,Loading 加载。

从不同数据源抽取数据 EXTRACTION ,按照一定的数据处理规则对数据进行加工和格式转换 TRASFORMATION,最后处理完成的输出到目标数据表中也有可能是文件等等,这个就是 LOADING。

再通俗一点讲,ETL 的过程就跟大家日常做菜一样,需要到菜市场的各个摊位买好菜,把菜买回来要摘一下,洗一洗,切一切最后下锅把菜炒好端到饭桌上。菜市场的各个摊位就是数据源,做好的菜就是最终的输出结果,中间的所有过程像摘菜、洗菜、切菜、做菜就是转换。

在开发的时候,大部分时候会通过 ETL 工具去实现,比如常用的像 KETTLE、PENTAHO、IBM DATASTAGE、INFORNAICA、微软 SQL SERVER 里面的 SSIS 等等,在结合基本的 SQL 来实现整个 ETL 过程。

也有的是自己通过程序开发,然后控制一些数据处理脚本跑批,基本上就是程序加 SQL 实现。

哪种方式更好,也是需要看使用场景和开发人员对那种方式使用的更加得心应手。我看大部分软件程序开发人员出身的,碰到数据类项目会比较喜欢用程序控制跑批,这是程序思维的自然延续。纯 BI 开发人员大部分自然就选择成熟的 ETL 工具来开发,当然也有一上来就写程序脚本的,这类 BI 开发人员的师傅基本上是程序人员转过来的。

用程序的好处就是适配性强,可扩展性强,可以集成或拆解到到任何的程序处理过程中,有的时候使用程序开发效率更高。难就难在对维护人员有一定的技术要求,经验转移和可复制性不够。

用 ETL 工具的好处,第一是整个 ETL 的开发过程可视化了,特别是在数据处理流程的分层设计中可以很清晰的管理。第二是链接到不同数据源的时候,各种数据源、数据库的链接协议已经内置了,直接配置就可以,不需要再去写程序去实现。第三是各种转换控件基本上拖拉拽就可以使用,起到简化的代替一部分 SQL 的开发,不需要写代码去实现。第四是可以非常灵活的设计各种 ETL 调度规则,高度配置化,这个也不需要写代码实现。

所以在大多数通用的项目中,在项目上使用 ETL 标准组件开发会比较多一些。

ETL 从逻辑上一般可以分为两层,控制流和数据流,这也是很多 ETL 工具设计的理念,不同的 ETL 工具可能叫法不同。

控制流就是控制每一个数据流与数据流处理的先后流程,一个控制流可以包含多个数据流。比如在数据仓库开发过程中,第一层的处理是ODS层或者Staging 层的开发,第二层是DIMENSION维度层的开发,后面几层就是DW 事实层、DM数据集市层的开发。通过ETL的调度管理就可以让这几层串联起来形成一个完整的数据处理流程。

数据流就是具体的从源数据到目标数据表的数据转换过程,所以也有 ETL 工具把数据流叫做转换。在数据流的开发设计过程中主要就是三个环节,目标数据表的链接,这两个直接通过 ETL 控件配置就可以了。中间转换的环节,这个时候就可能有很多的选择了,调 SQL 语句、存储过程,或者还是使用 ETL 控件来实现。

有的项目上习惯使用 ETL 控件来实现数据流中的转换,也有的项目要求不使用标准的转换组件使用存储过程来调用。也有的是因为数据仓库本身这个数据库不支持存储过程就只能通过标准的SQL来实现。

我们通常讲的BI数据架构师其实指的就是ETL的架构设计,这是整个BI项目中非常核心的一层技术实现,数据处理、数据清洗和建模都是在ETL中去实现。一个好的ETL架构设计可以同时支撑上百个包就是控制流,每一个控制流下可能又有上百个数据流的处理过程。之前写过一篇技术文章,大家可以搜索下关键字 BIWORK ETL 应该在网上还能找到到这篇文章。这种框架设计不仅仅是ETL框架架构上的设计,还有很深的ETL项目管理和规范性控制器思想,包括后期的运维,基于BI的BI分析,ETL的性能调优都会在这些框架中得到体现。因为大的BI项目可能同时需要几十人来开发ETL,框架的顶层设计就很重要。

准确的来说,商业智能BI不仅仅包含前端可视化分析、报表展现的能力,更包含了底层数据仓库的建设过程。

Gartner 在上世纪九十年代就已经提到了商业智能 Business Intelligence,它更多的认为BI是一种数据类的技术解决方案,将许多来自不同企业业务系统的数据提取有分析价值的数据进行清洗、转换和加载,就是抽取Extraction、转换 Transformation、加载Loading 的ETL过程,最终合并到一个数据仓库中,按照一定的建模方式例如Inmon 的3NF 建模、Kimball 的维度建模或者两者都有的混合式架构模型,最终在这个基础上再利用合适的分析展现工具来形成各种可视化的分析报表为企业的管理决策层提供数据决策支撑。

所以,可以从这里能够看到数据仓库Data Warehouse 的位置是介于可视化报表和底层业务系统数据源之间的这一层,在整个BI项目解决方案中起到的是一个承上启下的作用。所以,BI在前端可视化分析层面要玩出各类精彩的动作,没有数据仓库这个核心力量的支撑是很难做到的。

那大家也会问到,市面上不是有很多直接链接数据源就可以拖拉拽分析的BI工具产品吗,不也一样可以做BI分析报表吗?这种独立的、单独的面向前端的BI分析工具,他们更多的定位是部门级和个人级的BI 分析工具,对于深层次的需要复杂数据处理、集成、建模等很多场景是无法解决的。最好的方式就是底层构建一套完整的数据仓库,把很多分析模型标准化,再利用这些前端BI分析工具结合起来,这样才能真正的把前端BI分析能力给释放出来。

很多企业认为只要买一个前端BI分析工具就可以解决企业级的BI所有问题,这个看法实际上也不可行的。可能在最开始分析场景相对简单,对接数据的复杂度不是很高的情况下这类BI分析工具没有问题。但是在企业的BI项目建设有一个特点,是一个螺旋式上升的建设过程。因为对接的业务系统可能会越来越多,分析的深度和广度会越来越多,数据的复杂度也会越来越有挑战性,这个时候没有一个很好的数据仓库架构支撑,光靠前端BI分析工具基本上是无法搞定的。

所以在企业中,我们需要明确我们的BI建设是面向企业级的还是个人和部门的分析工作。如果是个人数据分析师,使用这类前端BI分析工具就足够了。如果是需要构建一个企业级的BI项目,就不能只关注前端可视化分析能力这个层面,更应该关注到底层数据架构的构建,也就是数据仓库这个层面。

E L 是Expression Language的缩写,目的是为了使JSP写起来更加简单。表达式语言的灵感来自于 ECMAScript 和 XPath 表达式语言,它提供了在 JSP 中简化表达式的方法。它是一种简单的语言,基于可用的命名空间(PageContext 属性)、嵌套属性和对集合、 *** 作符(算术型、关系型和逻辑型)的访问符、映射到 Java 类中静态方法的可扩展函数以及一组隐式对象。EL 提供了在 JSP 脚本编制元素范围外使用运行时表达式的功能。脚本编制元素是指页面中能够用于在 JSP 文件中嵌入 Java 代码的元素。它们通常用于对象 *** 作以及执行那些影响所生成内容的计算。JSP 20 将 EL 表达式添加为一种脚本编制元素。

ETL

ETL:Extract-Transform-Load的缩写,数据抽取(Extract)、转换(Transform)、装载(Load)的过程。

DW:Data Warehousing,根据BillInmon的定义,“数据仓库是面向主题的、集成的、稳定的、随时间变化的,主要用于决策支持的数据库系统”。

Metadata:元数据。描述数据的数据,指在数据仓库建设过程中所产生的有关数据源定义,目标定义,转换规则等相关的关键数据。

2、 ETL是数据仓库建立的核心过程

数据仓库系统先天不足,是在业务系统的基础上发展而来的,其内部存储的数据来自于事务处理的业务系统和外部数据源。而企业内各源数据缺少统一的标准,因企业的业务系统是在不同时期、不同背景、面对不同应用、不同开发商等各种客观前提下建立的,其数据结构、存储平台、系统平台均存在很大的异构性。因而其数据难以转化为有用的信息,原始数据的不一致性导致决策时其可信度的降低。

ETL是BI/DW的核心和灵魂,按照统一的规则集成并提高数据的价值,是负责完成数据从数据源向目标数据仓库转化的过程,是实施数据仓库的重要步骤。如果说数据仓库的模型设计是一座大厦的设计蓝图,数据是砖瓦的话,那么ETL就是建设大厦的过程。在整个项目中最难部分是用户需求分析和模型设计,而ETL规则设计和实施则是工作量最大的,其工作量要占整个项目的60%-80%,这是国内外从众多实践中得到的普遍共识。

3、 ETL过程的主要目的

就是以最小代价(包括对日常 *** 作的影响和对技能的要求) 将针对日常业务 *** 作的数据转化为针对数据仓库而存储的决策支持型数据。

ETL服务器是数据仓库中的重要组成部分,其英文名Extract, Transform, Load(提取、转换、加载)缩写的首字母也代表了其主要功能。ETL服务器的作用可以概括如下:

数据提取(Extract):ETL服务器负责从不同的数据源中提取数据,例如关系型数据库、文件、Web服务、第三方数据等。数据提取需要考虑到数据的有效性、完整性、一致性和准确性等方面。

数据转换(Transform):ETL服务器负责对提取的数据进行清洗、校验、去重、转换、合并和计算等 *** 作,以满足数据仓库的数据质量和分析需求。数据转换需要考虑到数据格式、数据类型、数据结构、数据粒度等方面。

数据加载(Load):ETL服务器负责将经过转换后的数据加载到数据仓库中,以供后续的数据分析、数据挖掘和决策支持等应用。数据加载需要考虑到数据的性能、可用性、安全性和完整性等方面。

总之,ETL服务器在数据仓库中的作用是将分散、异构、复杂的数据源整合成一致、可信、易用的数据集合,为企业决策提供高质量、可靠、及时的数据支持。

1 、简介

DataPipeline :隶属于北京数见 科技 有限公司,是一家企业级批流一体数据融合服务商和解决方案提供商,国内实时数据管道技术的倡导者。

通过平台和技术为企业客户解决数据准备过程中的各种痛点,帮助客户更敏捷、更高效、更简单地实现复杂异构数据源到目的地的实时数据融合和数据管理等综合服务。

从而打破传统 ETL 给客户灵活数据应用带来的束缚,让数据准备过程不再成为数据消费的瓶颈。

Kettle:是一款国外开源的ETL工具,纯java编写,可以在Windows、Linux、Unix上运行,数据抽取高效稳定。Kettle 中文名称叫水壶,该项目的主程序员MATT 希望把各种数据放到一个壶里,然后以一种指定的格式流出。

Informatica:是全球领先的数据管理软件提供商。

在如下Gartner魔力象限位于领导者地位:数据集成工具魔力象限、数据质量工具魔力象限、元数据管理解决方案魔力象限、主数据管理解决方案魔力象限、企业级集成平台即服务(EiPaaS)魔力象限。

Talend :是数据集成解决方案领域的领袖企业,为公共云和私有云以及本地环境提供一体化的数据集成平台。Talend的使命是致力于帮助客户优化数据,提高数据可靠性,把企业数据更快地转化为商业价值。

以此为使命,Talend的解决方案将数据从传统基础架构中解放出来,提高客户在业务中的洞察力,让客户更早实现业务价值。

DataX :是阿里巴巴集团内被广泛使用的离线数据同步工具 / 平台,实现包括 MySQL、Oracle、SqlServer、Postgre、HDFS、Hive、ADS、HBase、TableStore(OTS)、MaxCompute(ODPS)、DRDS 等各种异构数据源之间高效的数据同步功能。开源地址:>

设置一个job将数据从不同源数据库整合到数据仓库。job用的login是exec\ssisjob,而源数据库用一个sql server login。 因此想要job顺利运行,必须将密码存在etl 连接管理器conncetion manager中。

图一

然而,密码属于敏感信息, SSIS默认不存储敏感信息。 因此我们需要更改设置。在Control Flow空白处单击鼠标,在属性栏可看到如下选项。

图二

你会发现,没有一个选项真正符合要求。EncryptSensitiveWithUserName要求你更改是的login和job运行的login一致。为了克服这个问题,不二选择用package configuration。

在设置configuration时,你会有多种形式选择,不二在这里选择数据库方式,考虑到方便修改等问题。

图三

单击下一步后,选择connection string的password密码属性。

完成confogiration设置后,请务必确认package的安全属性设置是DoNotSaveSensitive,否则job还是无法正常运行。

当你设置好所有packages的configuration和属性后,查看你所设置的表,可以看到所有的密码都是****星星。在表中用最简单的update语句修改成真正的密码即可。

此方法只需一次修改数据库中的密码,只要源数据库密码不变,就不需要更多更改了

以上就是关于etl工程师和数据分析师的区别全部的内容,包括:etl工程师和数据分析师的区别、什么是ETL调度系统、BI,数据仓库,ETL,大数据开发工程师有什么区别等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!

欢迎分享,转载请注明来源:内存溢出

原文地址:https://54852.com/sjk/9380063.html

(0)
打赏 微信扫一扫微信扫一扫 支付宝扫一扫支付宝扫一扫
上一篇 2023-04-27
下一篇2023-04-27

发表评论

登录后才能评论

评论列表(0条)

    保存