疫情静默10天完成ETL工作概念理解（经验总结篇）

        对于零基础刚入行出去面试ETL工程师、BI工程师，面对面试官的问题，如果回答的不伦不类不专业，容易路出马脚、容易淘汰、容易被认定为新手。今天抛开业务不谈，纯粹的谈谈我对ETL工作概念的理解，深度理解ETL概念细节及在BI项目中的作用。让你在与面试官聊ETL这个话题时能够侃侃而谈，表现出你的专业性获得面试官的认可【特别是你面试BI、ETL工程师，当面试官抛出一个话题 你对ETL是如何理解的？】。此文5000字。此文算不上非常专业至少能帮助面试者在面试过程中回答ETL这个话题有内容聊，内容有点多如果有错误的地方请多多包涵。

 

         ETL是将业务系统的数据经过抽取、清洗、转换之后加载到数据仓库的过程，⽬的是将企业中的分散、零乱、标准不统⼀的数据整合到⼀起，为企业的决策提供分析依据。ETL是BI项⽬重要的⼀个环节。通常情况下，在BI项⽬中ETL会花掉整个项⽬⾄少2/3的时间,ETL设计的好坏直接关系到BI项⽬的成败。

下图解释了为什么要进行ETL工作

         ETL的设计分三部分：数据抽取、数据的清洗转换、数据的加载。在设计ETL的时候我们也是从这三部分出发。数据的抽取是从各个不同的数据源抽取到ODS(Operational Data Store，操作型数据存储)中——这个过程也可以做⼀些数据的清洗和转换)，在抽取的过程中需要挑选不同的抽取⽅法，尽可能的提⾼ETL的运⾏效率。ETL三个部分中，花费时间最长的是“T”(Transform，清洗、转换)的部分，⼀般情况下这部分⼯作量是整个ETL的2/3【致命点就是转换逻辑需求人说不明白，缺少能把业务口径和技术口径统一的大佬，也就是说即懂业务又懂技术，当然这部分有可能超出了ETL工程师的能力范围，大部分ETL工程师估计就是工具人，按照项目经理或需求分析师写好的文档做就行了】。数据的加载⼀般在数据清洗完了之后直接写⼊DW(DataWarehousing，数据仓库)中去。

 

         ETL的实现有多种⽅法，常⽤的有三种。⼀种是借助ETL⼯具(如Oracle的OWB、SQL Server 2016的商业智能组件之一SSIS服务、Informatic、kettle等)实现【只有kettle是开源免费的所以是最流行最多公司使用的ETL工具】，⼀种是SQL⽅式实现【存储过程】，另外⼀种是ETL⼯具和SQL相结合【工具内绑定SQL】。前两种⽅法各有各的优缺点，借助⼯具可以快速的建⽴起ETL⼯程，屏蔽了复杂的编码任务【这是相对的用谁用的多，谁的维护成本就高，就看对哪一种熟练程度比较高一些】，提⾼了速度，降低了难度，但是缺少灵活性。SQL的⽅法优点是灵活，提⾼ETL运⾏效率，但是编码复杂，对技术要求⽐较⾼。第三种是综合了前⾯⼆种的优点，会极⼤地提⾼ETL的开发速度和效率【这要求ETL工具和SQL都非常熟练】。（ETL的实现方法，没有权威机构定义有多少种，而我这里的分法也只是在使用上做一些区分）

 

⼀、数据的抽取（Extract）

　　这⼀部分需要在调研阶段做⼤量的⼯作，⾸先要搞清楚数据是从⼏个业务系统中来,各个业务系统的数据库服务器运⾏什么DBMS,是否存在⼿⼯数据，⼿⼯数据量有多⼤，是否存在⾮结构化的数据等等，当收集完这些信息之后才可以进⾏数据抽取的设计。【其中最重要的是调研是业务部门说系统有数据，其实有时是没有的，所以必须要求IT确认，这也是避免真正做ETL时没有数据的尴尬】

　　1、对于与存放DW的数据库系统相同的数据源处理⽅法

　　这⼀类数据源在设计上⽐较容易。⼀般情况下，DBMS(SQLServer、Oracle、MySql)都会提供数据库链接功能，在DW数据库服务器和原业务系统之间建⽴直接的链接关系就可以写Select 语句直接访问。

　　2、对于与DW数据库系统不同的数据源的处理⽅法

　　对于这⼀类数据源，⼀般情况下也可以通过ODBC的⽅式建⽴数据库链接——如SQL Server和Oracle之间【不同的ETL工具使用的链接驱动不一样，例如：使用ETL工具SSIS ，SQLServer 链接 Oracle 有两种驱动一种是ODBC、一种是OLEDB；他们有一个专业的名词叫数据接口技术。而使用ETL工具kettle，大多数情况下使用的链接驱动是JDBC，这与工具的开发语言有关kettle是使用java开发的工具】。如果不能建⽴数据库链接，可以有两种⽅式完成，⼀种是通过⼯具将源数据导出成.txt或者是.xls⽂件，然后再将这些源系统⽂件导⼊到ODS中【如果业务系统是从外部采购的，有可能供应商不会开发数据库的访问，不得已才使用这种导出的方法】。另外⼀种⽅法是通过程序接⼝来完成。【写程序接口来实现数据抽取，这种难度比使用ETL工具提升了几个量级，也需要专业的程序员来完成】

    3、对于⽂件类型数据源(.txt,.xls)，可以培训业务⼈员利⽤数据库⼯具将这些数据导⼊到指定的数据库，然后从指定的数据库中抽取。或者还可以借助⼯具实现。【市面上有两种实现方法一种是开发一个WEB端让业务人员从web页面导入数据库，另一种是指定一个服务器目录文件夹让业务人员把文件放到文件夹下面使用ETL工具去读取文件夹内的文件内容写入数据库】

　　4、增量更新的问题

　　对于数据量⼤的系统，必须考虑增量抽取。⼀般情况下，业务系统会记录业务发⽣的时间，我们可以⽤来做增量的标志,每次抽取之前⾸先判断ODS中记录最⼤的时间，然后根据这个时间去业务系统取⼤于这个时间所有的记录。利⽤业务系统的时间戳，⼀般情况下，业务系统没有或者部分有时间戳。【有两种情况，一种是业务系统的数据已经定性不会在更改，如某个销售记录已经归档也就是这条销售记录已经走到最后一个环节这里按天增量就可以了；另一种是业务记录还在中间环节，可以后退也可以前进，销售记录状态不是最后一个环节随时会变更记录，这里又有两种情况，一种如果要计算两种状态之间的间隔时间就得使用拉链表，同一条记录状态一变就保存一条新的数据行，另一种如果不进行其他业务计算只统计最新状态就可以按照昨天的最大时间戳来增量】

 

⼆、数据的清洗转换（Cleaning、Transform）

⼀般情况下，数据仓库分为ODS、DW两部分。通常的做法是从业务系统到ODS做清洗，将脏数据和不完整数据过滤掉，在从ODS到DW的过程中转换，进⾏⼀些业务规则的计算和聚合。【这个在概念上是对的，但是要考虑工作的实际情况，如果从业务系统到ODS就做清洗，写的复杂SQL会在业务系统上执行，严重的影响业务系统的性能，甚至会拖垮业务系统；所以一般情况从业务系统到ODS只进行一对一抽数不做清洗规则】

　　1、 数据清洗

　　数据清洗的任务是过滤那些不符合要求的数据，将过滤的结果交给业务主管部门，确认是否过滤掉还是由业务单位修正之后再进⾏抽取。不符合要求的数据主要是有不完整的数据、错误的数据、重复的数据三⼤类。【这三类问题一般由一种新型职业数据治理工程师来解决，但是大多数情况企业都是让BI项目来倒逼企业业务系统的规范】

　　(1)不完整的数据：这⼀类数据主要是⼀些应该有的信息缺失，如供应商的名称、分公司的名称、客户的区域信息缺失、业务系统中主表与明细表不能匹配等。对于这⼀类数据过滤出来，按缺失的内容分别写⼊不同Excel⽂件向客户提交，要求在规定的时间内补全。补全后才写⼊数据仓库。

    (2)错误的数据：这⼀类错误产⽣的原因是业务系统不够健全，在接收输⼊后没有进⾏判断直接写⼊后台数据库造成的，⽐如数值数据输成全⾓数字字符、字符串数据后⾯有⼀个回车操作、⽇期格式不正确、⽇期越界等。这⼀类数据也要分类，对于类似于全⾓字符、数据前后有不可见字符的问题，只能通过写SQL语句的⽅式找出来，然后要求客户在业务系统修正之后抽取。⽇期格式不正确的或者是⽇期越界的这⼀类错误会导致ETL运⾏失败，这⼀类错误需要去业务系统数据库⽤SQL的⽅式挑出来，交给业务主管部门要求限期修正，修正之后再抽取。

　　(3)重复的数据：对于这⼀类数据——特别是维表中会出现这种情况——将重复数据记录的所有字段导出来，让客户确认并整理。

　　数据清洗是⼀个反复的过程，不可能在⼏天内完成，只有不断的发现问题，解决问题。对于是否过滤，是否修正⼀般要求客户确认，对于过滤掉的数据，写⼊Excel⽂件或者将过滤数据写⼊数据表，在ETL开发的初期可以每天向业务单位发送过滤数据的邮件，促使他们尽快地修正错误,同时也可以做为将来验证数据的依据。数据清洗需要注意的是不要将有⽤的数据过滤掉，对于每个过滤规则认真进⾏验证，并要⽤户确认。【目前国内在BI项目中发现异常数据，基本都是采用人工干预修正，而不是自动修正】

 

         2、 数据转换

　　数据转换的任务主要进⾏不⼀致的数据转换、数据粒度的转换，以及⼀些业务规则的计算。

　　(1)不⼀致数据转换：这个过程是⼀个整合的过程，将不同业务系统的相同类型的数据统⼀，⽐如同⼀个供应商在结算系统的编码是XX0001,⽽在CRM中编码是YY0001，这样在抽取过来之后统⼀转换成⼀个编码。【在OneData体系中的OneService、OneID，统一编码是OneID】【随着数据治理的流行，主数据、参考数据的概念在企业慢慢得到认可，处理不一致的数据有专业人士来解决对于ETL工程师来说是一件好事也是一件坏事。好事是主数据和参考数据规范了企业的数据标准业务系统越来越完善，ETL工作越来越简单。坏事是当数据治理达到一定程度ETL工程师的地位和价值会被大打折扣，依赖性会逐步减少】

　　(2)数据粒度的转换：业务系统⼀般存储⾮常明细的数据，⽽数据仓库中数据是⽤来分析的，不需要⾮常明细的数据。⼀般情况下，会将业务系统数据按照数据仓库粒度进⾏聚合。【数据粒度的确认一般在数据仓库设计的时候进行，通常采用维度建模的四个步骤：1、选择业务过程，2、声明粒度，3、确认维度，4、确认事实。根据经验来看通常采用最小粒度的数据作为数据仓库的基础，才能避免未来业务不断变化的坑】

　　(3)业务规则的计算：不同的企业有不同的业务规则、不同的数据指标，这些指标有的时候不是简单的加加减减就能完成，这个时候需要在ETL中将这些数据指标计算好了之后存储在数据仓库中，以供分析使⽤。【在数据仓库分层中最小粒度的数据存在DW，而不同主题和深加工的指标通常存储在数据集市中。如果企业有成熟的指标体系和明确的指标计算口径……】

 

三、ETL⽇志、警告发送

　　1、 ETL⽇志分为三类。

       第⼀类是执⾏过程⽇志，这⼀部分⽇志是在ETL执⾏过程中每执⾏⼀步的记录，记录每次运⾏每⼀步骤的起始时间，影响了多少⾏数据，流⽔账形式。

       第二类是错误⽇志，当某个模块出错的时候写错误⽇志，记录每次出错的时间、出错的模块以及出错的信息等。

         第三类⽇志是总体⽇志，只记录ETL开始时间、结束时间是否成功信息。如果使⽤ETL⼯具,ETL⼯具会⾃动产⽣⼀些⽇志，这⼀类⽇志也可以作为ETL⽇志的⼀部分。

记录⽇志的⽬的是随时可以知道ETL运⾏情况，如果出错了，可以知道哪⾥出错。

以上三类在我的工具内均已实现，虽然面向的ETL工具是SSIS，但是如果切换到kettle应该也不难。

 

    2、 警告发送

　　如果ETL出错了，不仅要形成ETL出错⽇志，⽽且要向系统管理员发送警告。发送警告的⽅式多种，⼀般常⽤的就是给系统管理员发送邮件，并附上出错的信息，⽅便管理员排查错误。【具体实现方式可以看这里 BI数据工程师--20、任务调度执行结果邮件通知 】

　　ETL是BI项⽬的关键部分，也是⼀个长期的过程，只有不断的发现问题并解决问题，才能使ETL运⾏效率更⾼，为BI项⽬后期开发提供准确与⾼效的数据。

         后记做数据仓库系统，ETL是关键的⼀环。说⼤了，ETL是数据整合解决⽅案，说⼩了，就是导数据的⼯具。回忆⼀下⼯作这么长时间以来，处理数据迁移、转换的⼯作倒还真的不少。但是那些⼯作基本上是⼀次性⼯作或者很⼩数据量。可是在数据仓库系统中，ETL上升到了⼀定的理论⾼度，和原来⼩打⼩闹的⼯具使⽤不同了。究竟什么不同，从名字上就可以看到，⼈家已经将导数据的过程分成3个步骤，E、T、L分别代表抽取、转换和装载。其实ETL过程就是数据流动的过程，从不同的数据源流向不同的⽬标数据。但在数据仓库中，ETL有⼏个特点，

       ⼀是数据同步，它不是⼀次性倒完数据就拉到，它是经常性的活动，按照固定周期运⾏的，甚⾄现在还有⼈提出了实时ETL的概念。

       ⼆是数据量，⼀般都是巨⼤的，值得你将数据流动的过程拆分成E、T和L。【如果实在是太大了就的采用大数据 ELT , 也就是先加载在转换】

 

现在有很多成熟的⼯具提供ETL功能，且不说他们的好坏。从应⽤⾓度来说，ETL的过程其实不是⾮常复杂，这些⼯具给数据仓库⼯程带来和很⼤的便利性，特别是开发的便利和维护的便利。但另⼀⽅⾯，开发⼈员容易迷失在这些⼯具中。举个例⼦，VBA、Python、c#、SQL是都是⾮常简单的语⾔并且也是⾮常易⽤的编程⼯具，上⼿特别快，但是真正的⾼⼿有多少？微软设计的产品通常有个原则是“将使⽤者当作傻⽠”，在这个原则下，微软的东西确实⾮常好⽤，但是对于开发者，如果你⾃⼰也将⾃⼰当作傻⽠，那就真的傻了。ETL⼯具也是⼀样，这些⼯具为我们提供图形化界⾯，让我们将主要的精⼒放在规则上，以期提⾼开发效率。从使⽤效果来说，确实使⽤这些⼯具能够⾮常快速地构建⼀个job来处理某个数据，不过从整体来看，并不见得他的整体效率会⾼多少。问题主要不是出在⼯具上，⽽是在设计、开发⼈员上。他们迷失在⼯具中，没有去探求ETL的本质。可以说这些⼯具应⽤了这么长时间，在这么多项⽬、环境中应⽤，它必然有它成功之处，它必定体现了ETL的本质。如果我们不透过表⾯这些⼯具的简单使⽤去看它背后蕴涵的思想，最终我们作出来的东西也就是⼀个个独⽴的job，将他们整合起来仍然有巨⼤的⼯作量。⼤家都知道“理论与实践相结合”，如果在⼀个领域有所超越，必须要在理论⽔平上达到⼀定的⾼度。

最后最近一个月我把我构思出来的工具应用到工作中，发现确实提升了效率，但是离我设想的《低代码数仓开发平台》还有很远很远的路程要走。

在使用过程中拍了张照片纪念一下（下图）