1.ETL名词解释
- 英文缩写
Extract-Transform-Load ，用来描述将数据从来源端经过抽取（extract）、转换（transform）、加载（load）至到目的端（一般指的是数据仓库）的过程。
- 目的
一般企业按照组织架构设置不同部门，而且部门为了提供自我智能化运转会建立自己的自动化系统。那么站在企业领导层或者决策部门的角度，面对不同数据模型系统的数据给公司决策和战略发展计划带来很大的困难，也增加了很多的风险性。基于此，将企业中零碎、分散、杂乱的数据整合到一起，然后为企业的决策提供分析依据。
2. 先看看涉及数据库的两个关键名词
- OLTP
全称On-Line Transaction Processing，联机事务处理或在线事务处理。举个简单的例子，银行转账业务，整个流程很清晰。但是，不幸的是网络波动超时，导致交易失败，那么需要将对这个转账业务做回滚，恢复涉及的两个账户的状态。类似上述银行转账这种对实时性要求极高的系统，我们简称为OLTP。
- OLAP
全称On-Line Analytical Processing，联机分析处理。比如一个周期内公司需要统计销售的报表，那么需要将所有商品的数据捞取，然后加上一定规则的业务逻辑处理形成报表。类似于这种侧重于分析的系统，简称为OLAP
目前我们使用的关系型数据库，支持OLTP。比如oracle、mysql、最近很火的postgreSQL等，具备事务回滚操作，这些已经满足大部分需求。而OLAP涉及大批量数据操作且准实时的要求，是很多系统都面临的一个问题。目前来说，有了分布式数据库，比如Nosql、DRDS等这些是很适合使用的。因此为了让业务系统OLTP具备分析OLAP功能现在做法是，把OLTP与OLAP分开，独立运营。通过ETL将OLTP数据提取到OLAP数据库中，这样将业务系统与分析系统隔离，实现业务功能与技术上的一种平衡。
3.ETL设计
分为三个部分，数据提取-->数据清洗与转换-->数据加载。
- 数据提取
从各个不同的数据源抽取到ODS（Operational Data Store， 操作型数据存储）中。这个过程就是将一个企业不同组织架构中的不同系统数据建立数据通信，然后按照统一的rest接口去获取数据。这个过程我理解的是，将不同数据模型的数据提取出来统一处理，变成我们可以操作的数据源。
但是问题来了，数据源存储系统各式各样。比如：mysql、oracle、sql server或者内存库等。那么分为以下几类：
1> 数据源存储与数据仓库存储方式相同
这个一般可以通过数据库的数据驱动（服务）建立链接。这里不建议做全量数据库数据同步，问题不在全量导入，而是在系统生产运行中会实时变更数据，还要做数据变更同步，这个开发代价是有点大的。
建议将数据源系统作为实时访问数据库，当然在不影响系统使用性能前提下（目前数据库产品应该都可以满足我们这个需求）。不过需要我们在逻辑设计上要精巧，避免大批量、请求次数过多等问题，对于后续处理是很有好处的，应该在设计开发最初就考虑到，以规避问题。
个人建议最优方案，第一步利用第三方数据迁移工具（效率和安全性很高）做一个整体库数据迁移，建立自己的数据仓库。然后基于侧做数据的清理和转化，到最后的数据分析等；第二步定期同步数据。因为在获取了99%+的存量数据时，剩下的变更数据对与我们的数据分析影响不大，但是为了准确性，我们定期自动做一次全量同步。
2> 数据源存储与数据仓库存储方式不同
建议对数据库组件接口做一个公共封装；再次方案是存入文件系统。
3> 其他数据存储方式
自己封装接口或者利用第三方工具实现导入。
- 数据清洗与转换
根据前期市场调研，分析业务，形成核心业务文档。基于此对提取的做一些处理，清理垃圾数据、填充缺省值等操作。数据清洗这部分其实python中pandas、numpy等结合起来很好解决。
但是数据转化这部分还是很麻烦的。麻烦的地方主要是需求太多、太灵活，无法形成公共模块。比如空值处理、规范化数据格式、拆分数据、验证数据合法性、数据替换、实现数据规则过滤、数据排序、数据类型统一转换等等。转化方案一般有两个：
1> 开发公共接口
通过代码提取数据，然后按照需求做转化。这个可以灵活支撑需求，并且性能可控（可通过增加配置去解决性能）。
2> 利用数据库本身处理
mysql和oracle都支持存储过程，这个开发过程很简单。但是会影响数据库性能！
数据库核心目的是做数据存储的，一直认为不要把计算和处理能力交给数据库。但是大多数银行、电信运营商等这些系统都大量使用了存储过程，导致的就是数据库的性能大大下降。因此在框架设计之初就应该规避这个问题，多搬几块儿砖就能解决的事儿，益处非凡，后边产品扩展和优化就会尝到甜头。
- 数据加载
按照前两步，将加工的数据存入数据仓库。