不知道开发同学有没有遇到过类似的需求：同一类数据在多个系统中，想要获取所有的信息，就得不断调整多个系统的接口；业务复杂，一个需求需要关联几张表甚至几十张表才能得到想要的结果；系统分库分表，但需要对所有数据进行统计。那么如何满足这样的需求呢？我们选择了“通过ETL提前进行数据集成”这个选项。什么是ETL说到ETL，很多开发伙伴可能有些陌生，更多时候ETL用在大数据、数据分析等相关岗位；我也是在近几年的工作中接触到ETL，现在的项目对ETL的依赖比较多，可以说是项目的重要组成部分。ETL是三个词的缩写：Extraction：抽取，抽取；就是从数据库中取出数据；改造：变换；包括但不限于：数据筛选和验证、数据关联、数据内容和结构修改、计算、统计等；装载：装载；将处理后的数据保存到目标数据库中。从这三个词，我们基本可以理解ETL的作用：将各个业务系统的数据进行抽取、清洗、转换后，将处理后的数据放入数据库（数据仓库）；、杂乱、不统一的数据融合在一起。场景我接触过的项目，使用ETL工具有几种场景：1.报表和BI系统：公司建设初期，业务和系统比较少，一个数据库就可以搞定;随着公司业务的增多，业务系统拆分成很多系统；随着数据量的不断增加，当单个系统的数据增加到一定程度时，也做分库分表；这个时候，领导和业务人员在使用数据进行分析的时候，数据源可能是多个系统的多个表。这时候想通过一个复杂的SQL来尝试得到结果是非常困难的；通常公司会建立一个数据仓库，通过ETL工具将数据提取到数据仓库中。然后拟合并显示数据。2、跨系统的数据处理或查询：我们目前公司有上百个业务系统。由于业务流程的复杂性，前端系统在进行业务操作时，在交易正式提交之前，会有很多业务验证；例如查询客户在X系统的交易历史，Y系统的交易历史，Z系统的交易历史；那么需要分别调用X、Y、Z系统的接口，这对前端系统是非常不友好的，那么通常的解决方案是什么？方案A：创建一个中间服务，中间服务调用X、Y、Z系统的接口，客户端直接调用中间服务；该方案只是将前端要做的事情交给了中间服务；方案B：整合X、Y、Z系统，建设服务中心；这个方法很好，但是难度极大。对于很多公司来说，不说将X、Y、Z三个系统集成到一个中台系统中，就是??其中之一。重建系统本身非常困难；方案C：将X、Y、Z三个系统中需要的数据通过ETL抽取加工成数据仓库，对外提供服务；该系统最大的优势在于在不改造X、Y、Z三个系统的前提下，可以实现跨系统查询。我们在C方案的基础上又进了一步，就是对登陆后的数据进行处理，将需要跨表联动的数据提前存储在MongoDB中，对外提供查询服务；这样，多表关联查询就变成了单表查询。吐数据VS抽取数据继续上面第二个例子中的C方案，可能有同学会有疑问：数据抽取，需要抽取哪些数据？为什么不让这些系统把数据吐出来呢？答案也很简单，“有时候，数据可能吐不出来”。MySQL数据库导出数据有比较成熟的中间件，比如Canal，可以通过监听Mysql的binlog日志来获取数据。Binlog设置为行模式，可以获取每条新增、删除、修改的日志，还可以获取修改前后的数据；其他的商业数据库，比如Oracle，DB2等，我也查阅了相关资料，也有触发机制，可以在数据发生变化时得到通知，比如调用一个程序将数据发送到消息中队列，其他程序监听消息队列进行后续处理。不管是哪种类型的数据库，这种“吐数据”方案对基础设施的要求都比较高，对原有系统有一定的侵入性；因此，我们采用了一种对原有系统侵入性较小的方案：主动抽取数据。ETL方案优缺点1.优点是侵入性小。数据源系统只需要开启数据库的访问权限即可。有权限的数据库用户；支持Mysql、DB2、Oracle等不同类型数据源的数据抽取，通过ETL即可轻松完成；数据集成，将来自不同业务系统的相同数据进行集成，比如有的系统M/F表示男和女，有的系统中1/0表示男和女，ETL抽取处理后转化为统一编码；2.一个致命的缺点是数据提取和处理有一定的延迟，需要根据业务场景进行评估。接受这种延迟；可能会受到源数据库表结构变化的影响；如果源数据库中的表没有时间戳，或者时间戳不准确，那么增量抽取就会变得困难；需要招ETL开发岗位，从我目前的经验来看，并不是特别好招。
