ETL见解

在做BI的项目之前，也经常写procedure、function来实现客户提出的一些处理数据的需求，简单或复杂一般取决于业务逻辑，procedure一般也都是独立的个体，不像现在做的项目，除了业务逻辑之外，处理数据的整个过程也有一个较清晰的流程，就像ETL定义的一样：Extraction-Transformation-Loading即数据抽取、转换、装载，步骤基本就是这样。这些步骤可以借助于工具例如DataStage、ODI、Informatic、Kettle等来可视化处理，也可以写procedure结合function来完成。具体用哪种方法，还要看项目的具体情况，比方说最现实的一个问题是客户是不是出钱买工具，如果没有的话估计开发方也不会承受这个费用，这时要么用开源的etl工具，要么就是写procedure，但是在用开源的etl工具时要对这个软件有相当的把握，知道有哪些bug,不然在运行的时候忽然出现了问题，再去查资料找原因，严重的话就会涉及到商务的问题吧。其实自己做的第一个项目就是这样的状况，但是为了最后的调度方便，还是结合了procedure和开源的etl工具kettle来共同完成其功能，整体效果还算理想。

深入理解了etl的步骤之后，发现整天写procedure过于繁琐，且给后来维护人员带来一定的难度，而是用工具对开发和维护人员的要求相对要低一些，对后期的接手人员以及交接工作带来方便。

无论是使用工具还是写procedure其实对内在的开发思想都得心中有数，特别对于数据量较大或业务逻辑较为复杂的项目，性能也是一个要考虑的重要因素，否则在时间窗口之内对etl处理会形成较大压力，一般这些是在设计阶段就考虑到的。所以对etl设计人员的大局观有相当的要求。

之前的一个项目，刚开始是架构设计人员在现场做指导，大致开发框架基本已经完工，部分的etl的mapping也已经形成，所以开发还是比较顺利，随着项目进度的不断深入，客户的需求也在不断的变化，这个时候架构人员又从项目中抽调出去，弄得没有太多经验的我有点力不从心。因为需求的不断变更，之前写好的很多的procedure要返工，同时还要同步更新相应的文档，真是举步维艰。这个时候体会到了需求分析人员和设计人员在etl的过程中才是至关重要的一环，这也是后来我们在部门讨论中经常提到的在项目开始的时候要找咨询公司进驻项目的原因。需求搞不定而进行的开发让我们这些etl人员心理总是很忐忑，而这些压力也总是由etl人员在顶，也就是说，如果前台展示的结果恰好符合客户的需求，那么受到表扬的肯定是前台开发人员，如果效果不理想，那就是提供的数据不到位或不准确，这就是我们etl人员的悲哀。etl人员在要求需要明确的想法比其他步骤都更为强烈，经常的改动会打消我们的士气。所以明确的需求和详细的设计在etl开发中是至关重要的。

开发初期，etl开发人员也要吃透设计人员设计的精神，因为设计人员和开发人员一般都是以文档的形式进行接口对接，这个时候开发人员如果对文档中某些不理解的地方一定要和设计人员沟通，弄懂为什么这么设计，对后续的开发又会有哪些影响以及对最终的结果又有哪些意义。不然到最后的测试阶段会痛苦的接受自己所种下的果子。其实也有不少地方需要和客户去确认的地方，确认的时候尽量还是让需求人员或设计人员去确认，毕竟他们考虑的比较全面，etl开发人员很容易从技术的角度去考虑问题。

需求明确之后，开发就是一个相对容易的过程，这个时候也会碰到与设计不符的情况，因为客户的BI系统一般是在之前的oltp系统的基础上抽取的数据，所以他们的oltp系统情况只有在开发的时候乃至测试的时候会把真正的问题给暴露出来。出现这些问题的时候开发人员还是比较反感的，可能会埋怨设计人员考虑的不够周到等，其实这些问题都是etl开发中经常碰到的问题，我们要客观的正视这些问题，这是开发的一部分。发现困难并解决困难本身也能给自己带来很多的收获。开发过程中要严格遵守开发规则，例如命名方式、注释粒度等。

在etl过程中最重要的也是最容易出问题的算式清洗部分了，毕竟客户的源数据不是那么干净；以下是一些常见的清洗情况：

空值处理，可捕获字段空值，进行加载或替换为其他含义数据，并可根据字段空值实现分流加载到不同目标库。

规范化数据格式，可实现字段格式约束定义，对于数据源中时间、数值、字符等数据，可自定义加载格式。

拆分数据，依据业务需求对字段可进行分解。

验证数据正确性，可利用Lookup及拆分功能进行数据验证。

数据替换，对于因业务因素，可实现无效数据、缺失数据的替换。

为了能更好地实现ETL，结合查询资料感觉在实施ETL过程中应注意以下几点：

　　第一，如果条件允许，可利用数据中转区对运营数据进行预处理，保证集成与加载的高效性；

　　第二，如果ETL的过程是主动“拉取”，而不是从内部“推送”，其可控性将大为增强；

　　第三，ETL之前应制定流程化的配置管理和标准协议；

第四，关键数据标准至关重要。

开发完成后要有严格测试，确保项目在正式库上运行之前搞定已经清楚的问题。这时etl开发人员就要和前台人员紧密配合达到这一效果。测试的时候会有一部分开发中没有暴露的问题出现，修改的时候就要全面考虑了，是不是影响其他模块，毕竟这个时候已经是一个整体了，否则就会改了这边，那边又出问题了。

最后就是定时的调度，在时间窗口内要确保能够完成这些调度，并且尽量减少人为的交互，多做判断，自动处理。这点在第一个项目中深有体会。