BI项目中ETL设计与思考
　ETL是将业务系统的数据经过抽取、清洗转换之后加载到数据仓库的过程，目的是将企业中的分散、零乱、标准不统一的数据整合到一起，为企业的决策提供分析依据。ETL是BI项目重要的一个环节。通常情况下，在BI项目中ETL会花掉整个项目的1/3的时间,ETL设计的好坏直接关接到BI项目的成败。
　　ETL的设计分三部分：数据抽取、数据的清洗转换、数据的加载。在设计ETL的时候我们也是从这三部分出发。数据的抽取是从各个不同的数据源抽取到ODS(OperationalDataStore，操作型数据存储)中——这个过程也可以做一些数据的清洗和转换)，在抽取的过程中需要挑选不同的抽取方法，尽可能的提高ETL的运行效率。ETL三个部分中，花费时间最长的是“T”(Transform，清洗、转换)的部分，一般情况下这部分工作量是整个ETL的2/3。数据的加载一般在数据清洗完了之后直接写入DW(DataWarehousing，数据仓库)中去。
　　ETL的实现有多种方法，常用的有三种。一种是借助ETL工具(如Oracle的OWB、SQLServer2000的DTS、SQLServer2005的SSIS服务、Informatic等)实现，一种是SQL方式实现，另外一种是ETL工具和SQL相结合。前两种方法各有各的优缺点，借助工具可以快速的建立起ETL工程，屏蔽了复杂的编码任务，提高了速度，降低了难度，但是缺少灵活性。SQL的方法优点是灵活，提高ETL运行效率，但是编码复杂，对技术要求比较高。第三种是综合了前面二种的优点，会极大地提高ETL的开发速度和效率。
　　一、数据的抽取
　　这一部分需要在调研阶段做大量的工作，首先要搞清楚数据是从几个业务系统中来,各个业务系统的数据库服务器运行什么DBMS,是否存在手工数据，手工数据量有多大，是否存在非结构化的数据等等，当收集完这些信息之后才可以进行数据抽取的设计。
　　1、对于与存放DW的数据库系统相同的数据源处理方法
　　这一类数据源在设计上比较容易。一般情况下，DBMS(SQLServer、Oracle)都会提供数据库链接功能，在DW数据库服务器和原业务系统之间建立直接的链接关系就可以写select语句直接访问。
　　2、对于与DW数据库系统不同的数据源的处理方法
　　对于这一类数据源，一般情况下也可以通过ODBC的方式建立数据库链接——如SQLServer和Oracle之间。如果不能建立数据库链接，可以有两种方式完成，一种是通过工具将源数据导出成.txt或者是.xls文件，然后再将这些源系统文件导入到ODS中。另外一种方法是通过程序接口来完成。
　　3、对于文件类型数据源(.txt,.xls)，可以培训业务人员利用数据库工具将这些数据导入到指定的数据库，然后从指定的数据库中抽取。或者还可以借助工具实现，如SQLServer2005的SSIS服务的平面数据源和平面目标等组件导入ODS中去。
　　4、增量更新的问题
　　对于数据量大的系统，必须考虑增量抽取。一般情况下，业务系统会记录业务发生的时间，我们可以用来做增量的标志,每次抽取之前首先判断ODS中记录最大的时间，然后根据这个时间去业务系统取大于这个时间所有的记录。利用业务系统的时间戳，一般情况下，业务系统没有或者部分有时间戳。
　　二、数据的清洗转换
　　一般情况下，数据仓库分为ODS、DW两部分。通常的做法是从业务系统到ODS做清洗，将脏数据和不完整数据过滤掉，在从ODS到DW的过程中转换，进行一些业务规则的计算和聚合。
　　1、数据清洗
　　数据清洗的任务是过滤那些不符合要求的数据，将过滤的结果交给业务主管部门，确认是否过滤掉还是由业务单位修正之后再进行抽取。不符合要求的数据主要是有不完整的数据、错误的数据、重复的数据三大类。
　　(1)不完整的数据：这一类数据主要是一些应该有的信息缺失，如供应商的名称、分公司的名称、客户的区域信息缺失、业务系统中主表与明细表不能匹配等。对于这一类数据过滤出来，按缺失的内容分别写入不同Excel文件向客户提交，要求在规定的时间内补全。补全后才写入数据仓库。
　　(2)错误的数据：这一类错误产生的原因是业务系统不够健全，在接收输入后没有进行判断直接写入后台数据库造成的，比如数值数据输成全角数字字符、字符串数据后面有一个回车操作、日期格式不正确、日期越界等。这一类数据也要分类，对于类似于全角字符、数据前后有不可见字符的问题，只能通过写SQL语句的方式找出来，然后要求客户在业务系统修正之后抽取。日期格式不正确的或者是日期越界的这一类错误会导致ETL运行失败，这一类错误需要去业务系统数据库用SQL的方式挑出来，交给业务主管部门要求限期修正，修正之后再抽取。
　　(3)重复的数据：对于这一类数据——特别是维表中会出现这种情况——将重复数据记录的所有字段导出来，让客户确认并整理。
　　数据清洗是一个反复的过程，不可能在几天内完成，只有不断的发现问题，解决问题。对于是否过滤，是否修正一般要求客户确认，对于过滤掉的数据，写入Excel文件或者将过滤数据写入数据表，在ETL开发的初期可以每天向业务单位发送过滤数据的邮件，促使他们尽快地修正错误,同时也可以做为将来验证数据的依据。数据清洗需要注意的是不要将有用的数据过滤掉，对于每个过滤规则认真进行验证，并要用户确认。
　　2、数据转换
　　数据转换的任务主要进行不一致的数据转换、数据粒度的转换，以及一些商务规则的计算。
　　(1)不一致数据转换：这个过程是一个整合的过程，将不同业务系统的相同类型的数据统一，比如同一个供应商在结算系统的编码是XX0001,而在CRM中编码是YY0001，这样在抽取过来之后统一转换成一个编码。
　　(2)数据粒度的转换：业务系统一般存储非常明细的数据，而数据仓库中数据是用来分析的，不需要非常明细的数据。一般情况下，会将业务系统数据按照数据仓库粒度进行聚合。
　　(3)商务规则的计算：不同的企业有不同的业务规则、不同的数据指标，这些指标有的时候不是简单的加加减减就能完成，这个时候需要在ETL中将这些数据指标计算好了之后存储在数据仓库中，以供分析使用。
　　三、ETL日志、警告发送
　　1、ETL日志
　　ETL日志分为三类。一类是执行过程日志，这一部分日志是在ETL执行过程中每执行一步的记录，记录每次运行每一步骤的起始时间，影响了多少行数据，流水账形式。一类是错误日志，当某个模块出错的时候写错误日志，记录每次出错的时间、出错的模块以及出错的信息等。第三类日志是总体日志，只记录ETL开始时间、结束时间是否成功信息。如果使用ETL工具,ETL工具会自动产生一些日志，这一类日志也可以作为ETL日志的一部分。记录日志的目的是随时可以知道ETL运行情况，如果出错了，可以知道哪里出错。
　　2、警告发送
　　如果ETL出错了，不仅要形成ETL出错日志，而且要向系统管理员发送警告。发送警告的方式多种，一般常用的就是给系统管理员发送邮件，并附上出错的信息，方便管理员排查错误。
　　ETL是BI项目的关键部分，也是一个长期的过程，只有不断的发现问题并解决问题，才能使ETL运行效率更高，为BI项目后期开发提供准确的数据。
TechTarget中国原创内容，原文链接：
没有更多推荐了，ETL讲解（很详细！！！）
ETL是将业务系统的数据经过抽取、清洗转换之后加载到数据仓库的过程，目的是将企业中的分散、零乱、标准不统一的数据整合到一起，为企业的决策提供分析依据。&ETL是BI项目重要的一个环节。 通常情况下，在BI项目中ETL会花掉整个项目至少1/3的时间,ETL设计的好坏直接关接到BI项目的成败。&&&&&&&
　　ETL的设计分三部分：数据抽取、数据的清洗转换、数据的加载。在设计ETL的时候我们也是从这三部分出发。数据的抽取是从各个不同的数据源抽取到ODS(Operational Data Store，操作型数据存储)中&&这个过程也可以做一些数据的清洗和转换)，在抽取的过程中需要挑选不同的抽取方法，尽可能的提高ETL的运行效率。ETL三个部分中，花费时间最长的是&T&(Transform，清洗、转换)的部分，一般情况下这部分工作量是整个ETL的2/3。数据的加载一般在数据清洗完了之后直接写入DW(Data Warehousing，数据仓库)中去。
　　ETL的实现有多种方法，常用的有三种。一种是借助ETL工具(如Oracle的OWB、SQL Server 2000的DTS、SQL Server2005的SSIS服务、Informatic等)实现，一种是SQL方式实现，另外一种是ETL工具和SQL相结合。前两种方法各有各的优缺点，借助工具可以快速的建立起ETL工程，屏蔽了复杂的编码任务，提高了速度，降低了难度，但是缺少灵活性。SQL的方法优点是灵活，提高ETL运行效率，但是编码复杂，对技术要求比较高。第三种是综合了前面二种的优点，会极大地提高ETL的开发速度和效率。
　　一、 数据的抽取（Extract）
　　这一部分需要在调研阶段做大量的工作，首先要搞清楚数据是从几个业务系统中来,各个业务系统的数据库服务器运行什么DBMS,是否存在手工数据，手工数据量有多大，是否存在非结构化的数据等等，当收集完这些信息之后才可以进行数据抽取的设计。
　　1、对于与存放DW的数据库系统相同的数据源处理方法
　　这一类数据源在设计上比较容易。一般情况下，DBMS(SQLServer、Oracle)都会提供数据库链接功能，在DW数据库服务器和原业务系统之间建立直接的链接关系就可以写Select 语句直接访问。
　　2、对于与DW数据库系统不同的数据源的处理方法
　　对于这一类数据源，一般情况下也可以通过ODBC的方式建立数据库链接&&如SQL Server和Oracle之间。如果不能建立数据库链接，可以有两种方式完成，一种是通过工具将源数据导出成.txt或者是.xls文件，然后再将这些源系统文件导入到ODS中。另外一种方法是通过程序接口来完成。
　　3、对于文件类型数据源(.txt,.xls)，可以培训业务人员利用数据库工具将这些数据导入到指定的数据库，然后从指定的数据库中抽取。或者还可以借助工具实现。
　　4、增量更新的问题
　　对于数据量大的系统，必须考虑增量抽取。一般情况下，业务系统会记录业务发生的时间，我们可以用来做增量的标志,每次抽取之前首先判断ODS中记录最大的时间，然后根据这个时间去业务系统取大于这个时间所有的记录。利用业务系统的时间戳，一般情况下，业务系统没有或者部分有时间戳。
二、数据的清洗转换（Cleaning、Transform）
　　一般情况下，数据仓库分为ODS、DW两部分。通常的做法是从业务系统到ODS做清洗，将脏数据和不完整数据过滤掉，在从ODS到DW的过程中转换，进行一些业务规则的计算和聚合。
　　1、 数据清洗
　　数据清洗的任务是过滤那些不符合要求的数据，将过滤的结果交给业务主管部门，确认是否过滤掉还是由业务单位修正之后再进行抽取。
不符合要求的数据主要是有不完整的数据、错误的数据、重复的数据三大类。
　　(1)不完整的数据：这一类数据主要是一些应该有的信息缺失，如供应商的名称、分公司的名称、客户的区域信息缺失、业务系统中主表与明细表不能匹配等。对于这一类数据过滤出来，按缺失的内容分别写入不同Excel文件向客户提交，要求在规定的时间内补全。补全后才写入数据仓库。
　　(2)错误的数据：这一类错误产生的原因是业务系统不够健全，在接收输入后没有进行判断直接写入后台数据库造成的，比如数值数据输成全角数字字符、字符串数据后面有一个回车操作、日期格式不正确、日期越界等。这一类数据也要分类，对于类似于全角字符、数据前后有不可见字符的问题，只能通过写SQL语句的方式找出来，然后要求客户在业务系统修正之后抽取。日期格式不正确的或者是日期越界的这一类错误会导致ETL运行失败，这一类错误需要去业务系统数据库用SQL的方式挑出来，交给业务主管部门要求限期修正，修正之后再抽取。
　　(3)重复的数据：对于这一类数据&&特别是维表中会出现这种情况&&将重复数据记录的所有字段导出来，让客户确认并整理。
　　数据清洗是一个反复的过程，不可能在几天内完成，只有不断的发现问题，解决问题。对于是否过滤，是否修正一般要求客户确认，对于过滤掉的数据，写入Excel文件或者将过滤数据写入数据表，在ETL开发的初期可以每天向业务单位发送过滤数据的邮件，促使他们尽快地修正错误,同时也可以做为将来验证数据的依据。数据清洗需要注意的是不要将有用的数据过滤掉，对于每个过滤规则认真进行验证，并要用户确认。
　　2、 数据转换
　　数据转换的任务主要进行不一致的数据转换、数据粒度的转换，以及一些商务规则的计算。
　　(1)不一致数据转换：这个过程是一个整合的过程，将不同业务系统的相同类型的数据统一，比如同一个供应商在结算系统的编码是XX0001,而在CRM中编码是YY0001，这样在抽取过来之后统一转换成一个编码。
　　(2)数据粒度的转换：业务系统一般存储非常明细的数据，而数据仓库中数据是用来分析的，不需要非常明细的数据。一般情况下，会将业务系统数据按照数据仓库粒度进行聚合。
　　(3)商务规则的计算：不同的企业有不同的业务规则、不同的数据指标，这些指标有的时候不是简单的加加减减就能完成，这个时候需要在ETL中将这些数据指标计算好了之后存储在数据仓库中，以供分析使用。
三、ETL日志、警告发送
　　1、 ETL日志
　　ETL日志分为三类。
一类是执行过程日志，这一部分日志是在ETL执行过程中每执行一步的记录，记录每次运行每一步骤的起始时间，影响了多少行数据，流水账形式。
一类是错误日志，当某个模块出错的时候写错误日志，记录每次出错的时间、出错的模块以及出错的信息等。
第三类日志是总体日志，只记录ETL开始时间、结束时间是否成功信息。如果使用ETL工具,ETL工具会自动产生一些日志，这一类日志也可以作为ETL日志的一部分。
记录日志的目的是随时可以知道ETL运行情况，如果出错了，可以知道哪里出错。
　　2、 警告发送
　　如果ETL出错了，不仅要形成ETL出错日志，而且要向系统管理员发送警告。发送警告的方式多种，一般常用的就是给系统管理员发送邮件，并附上出错的信息，方便管理员排查错误。
　　ETL是BI项目的关键部分，也是一个长期的过程，只有不断的发现问题并解决问题，才能使ETL运行效率更高，为BI项目后期开发提供准确与高效的数据。
&&&&&做数据仓库系统，ETL是关键的一环。说大了，ETL是数据整合解决方案，说小了，就是倒数据的工具。回忆一下工作这么长时间以来，处理数据迁移、转换的工作倒还真的不少。但是那些工作基本上是一次性工作或者很小数据量。可是在数据仓库系统中，ETL上升到了一定的理论高度，和原来小打小闹的工具使用不同了。究竟什么不同，从名字上就可以看到，人家已经将倒数据的过程分成3个步骤，E、T、L分别代表抽取、转换和装载。
其实ETL过程就是数据流动的过程，从不同的数据源流向不同的目标数据。但在数据仓库中，
ETL有几个特点，
一是数据同步，它不是一次性倒完数据就拉到，它是经常性的活动，按照固定周期运行的，甚至现在还有人提出了实时ETL的概念。
二是数据量，一般都是巨大的，值得你将数据流动的过程拆分成E、T和L。
&&&&现在有很多成熟的工具提供ETL功能，且不说他们的好坏。从应用角度来说，ETL的过程其实不是非常复杂，这些工具给数据仓库工程带来和很大的便利性，特别是开发的便利和维护的便利。但另一方面，开发人员容易迷失在这些工具中。举个例子，VB是一种非常简单的语言并且也是非常易用的编程工具，上手特别快，但是真正VB的高手有多少？微软设计的产品通常有个原则是&将使用者当作傻瓜&，在这个原则下，微软的东西确实非常好用，但是对于开发者，如果你自己也将自己当作傻瓜，那就真的傻了。ETL工具也是一样，这些工具为我们提供图形化界面，让我们将主要的精力放在规则上，以期提高开发效率。从使用效果来说，确实使用这些工具能够非常快速地构建一个job来处理某个数据，不过从整体来看，并不见得他的整体效率会高多少。问题主要不是出在工具上，而是在设计、开发人员上。他们迷失在工具中，没有去探求ETL的本质。可以说这些工具应用了这么长时间，在这么多项目、环境中应用，它必然有它成功之处，它必定体现了ETL的本质。如果我们不透过表面这些工具的简单使用去看它背后蕴涵的思想，最终我们作出来的东西也就是一个个独立的job，将他们整合起来仍然有巨大的工作量。大家都知道&理论与实践相结合&，如果在一个领域有所超越，必须要在理论水平上达到一定的高度.
阅读(...) 评论()技术总结和分享
Hadoop目前只是“穷人的ETL”
虽然企业部署Hadoop大数据系统的最终目的是进行“性感”的分析应用，但是大多数企业距离这一目标还很远很远。
根据IDC发布的Hadoop-MapReduce软件生态系统预测报告，Hadoop市场正在以60%的年复合增长率高速扩张。但是该报告也揭示了一个让人吃惊的事实，作为大数据分析应用的代名词，Hadoop的流行其实与数据分析无关。实际上大多数采用Hadoop的公司都没有将Hadoop用于大数据分析，而是把Hadoop作为一种廉价的海量存储和ETL（抽取、转换、加载）系统。
虽然被打上了“大数据分析工具”的标签，但在大多数企业眼里，Hadoop是“穷人的ETL”。目前确实有个别企业将Hadoop用于运行激动人心的分析工作，但这只是个案。Cloudera曾提出：Transform、Active
Archive和Exploration，但是业内人士分析，目前至少有75%的部署Hadoop的企业还都只是停留在前两个模式中：将Hadoop作为廉价的ETL方案，或者用作垃圾数据填埋场(编者注：离线历史数据仓库，存储海量的价值较低的历史数据，例如淘宝光棍节的交易数据)。
Hadoop之路
Hadoop诞生已经7年了，但是Hadoop在企业中的应用还有很长的路要走。451研究所的分析师Matt Aslett在Hadoop峰会上的演讲指出，企业采用Hadoop需要经历三个发展阶段，从一开始用来存储海量数据，到对数据进行处理和转换，到最终开始分析这些数据。我们还处于Hadoop市场和技术生命周期的早期阶段，Rainstor的调查显示，即使是最高级的Hadoop用户，也认为Hadoop最大的挑战是时间（26%）和编程（25%）。根据Gartner的调查，目前只有6%的企业开始部署大数据项目，企业还需要更多成功案例指路，同时也需要更多时间消化相关技术。
没有更多推荐了，提供企业信息化整体解决方案
BI、数据仓库、ETL、大数据开发工程师有什么区别？
BI、数据仓库、ETL、大数据开发工程师有什么区别？
| 作者： |
09:39:02| 阅读 0次
概述：就拿ETL过程来说吧，你要把原始数据从各种数据库、各种服务器的不同业务日志归一化到同一类格式，要约定好分隔符，然后导入到分布式文件系统HDFS，甚至你还要和业务系统定义数据格式出规范，数据收集完
就拿ETL过程来说吧，你要把原始数据从各种数据库、各种服务器的不同业务日志归一化到同一类格式，要约定好分隔符，然后导入到分布式文件系统HDFS，甚至你还要和业务系统定义数据格式出规范，数据收集完
一味的解释 数据仓库 概念可能没意思，我们从不同角色出发吧
老板 ：我是一家手机公司的老板，今天要向去董事局汇报，我要准备一份介绍过去三年的用户增长、用户留存、用户活跃度、手机里面每个APP使用率等情况的报表，假如下面没我下面没有BI，那我肯定就蒙逼了。。
： 我是一名非技术BI，我天天看竞品的分析报告，看双十一销量，看各种评论，知道自己的产品有哪些短板有哪些长处，我分析南北地域差异，国内外客户喜好，总之我在手机领域有着很强的行业解读能力和数据解读能力，我可以画出非常漂亮的图表和PPT。今天老板让我出一份报表，我还要去刷脸找ETL工程师帮我跑出这次报告的数据，基于这份数据我要给出一定的解读，为啥这个月手机卖得不如上个月，为啥用户流失越来越严重等等都是我要去做的。
: 我是食物链最底层的苦逼ETL工程师，我会写shell、我会搭hadoop/hive/hbase、会写超复杂逻辑的sql，今天那个不会自己计算数据的BI又让我跑几个数据，我本想让她提需求流程的，但她说这是老板要的，要加急处理，我只能放下手头的活儿给她跑数据了，花了半个小时把数据跑好给她，希望能就这么交差吧。
如果你以为我每天就做这点事那你就错了，我平时的工作可不仅仅就是完成上面交给我的任务哦，我还负责数据ETL过程、数据建模、定时任务的分配等等，每件事都可以拿出来写本书。
就拿过程来说吧，你要把原始数据从各种数据库、各种服务器的不同业务日志归一化到同一类格式，要约定好分隔符，然后导入到分布式文件系统HDFS，甚至你还要和业务系统定义数据格式出规范，数据收集完，你还得出中间表，数据过滤，格式统一，ID统一，维度统一，通过不同的数据现象进行数据，完了，你就得出一些日报周报之类的数据了，这时候你要按照需求把数据组织成一定的格式然后导Mysql、或者HBASE等等。
总之你就是需要把数据各种收集、各种处理、然后各种导入导出，是不是很有意思?
不过这些数据仓库都非常初级，其中ETL工程师可发挥的空间太多了
1、正常情况下，老板 && BI && ETL 出一份报告，这中间能否BI直接去计算数据?sql太复杂，那么可不可以一切数据标签化，BI甚至老板要什么就选什么?
2、可以把数据收集自动化、可以规范业务日志格式、可以将一切都配置化，但是这些都是基于N+1的，也就是说今天的发生了什么一定要到明天才能看到，那么有没有一个系统能把数据分析做到实时或者准实时?参考双十一大屏，马总要是到12号才能知道成交了多少笔不劈了那帮做数据的才怪。
3、目前绝大部分分析系统都基于离线计算(HADOOP/ODPS)，那这里有个问题了，运营或BI想看个数据还得你离线慢腾腾跑完才能看到，那么有没有一个系统可以支持你再大的数据量，再复杂的逻辑，毫秒出数据?
我没有提到的还有算法工程师、大数据运维等等，数据仓库的概念很广很大，但在大数据应用面前也不值一提。
如果把数据价值分层，这里分层的办法很多，我只列举一种方法，有人分过5层
第一层: 为老板提供决策支持，例如传统的财务报表
第二层: 为运营提供决策支持，例如数据化非常彻底的淘宝运营们
第三层: 为产品提供支持，例如有产品经理们会拿着报表天天看研究自己的某一个按钮摆放位置对不对
第四层：数据用于生产，比如直接对接广告系统产生收益，比如直接对接推荐系统为用户推荐商品，实现千人千面，再比如利用手机APP直接为不同用户push消息
第五层：大数据交换，数据产生直接受益
大部分公司能做到前两个层次就已经很不错了，如果能做到第三层，就已经很牛逼，做到第四第五层次，国内互联网公司不超过2家，大数据应用太大了，不知从何说起，以后聊吧。
详情请咨询！
客服热线：023-
慧都控件｜提供软件技术整体解决方案
云集全球三千余款优秀控件、软件产品，提供行业领先的咨询、培训与开发服务
企业QQ：｜电话：023-
服务与支持
重庆 / 023-
北京 / 010-
400-700-1020
慧都科技有限公司 版权所有 Copyright 2003-
400-700-1020
<input type="hidden" id="url" value=""/>