伴随前台业务系统的微服务化，各微应用的数据存储于各自微服务里，使得各业务系统之间数据的关联分析、数据的全生命周期的分析愈发困难。这往往逼迫各互联网公司大量使用MQ作为微服务数据承接通道，通过实时的关联或在各自微服务里做一个数据镜像，以便实现数据的全链路分析。这样做带来些许问题，如:1、大量使用MQ造成企业级别网络带宽消耗过高，网络的抖动，MQ两端的异常会造成难以恢复的数据质量问题。2、企业内数据MQ的开放，各部门按需接入数据，造成大量数据的重复接入，数据烟囱，指标统计口径不一致的问题屡屡发生。3、微服务架构的应用难以承担极大数据量的计算能力，这需要将微服务更细化的拆分，为优化微服务架构研发往往绞尽脑力去想更新的三字码新建新微服务，上线后还可能出现各类OOM问题。从长期规划看，大数据的计算不应当由业务微服务应用去完成。--我的观点
个人认为，DT时代的到来，就决定了软件架构的变化，也会垂直影响到软件研发角色和分工的变化。多年前一个软件工程师要身兼数职，会前端，后端、数据库、甚至会PS，"全栈工程师"好像挺香喷喷的，然而到了如今更多的技术到来，大数据、人工智能、区块链、数据中台等等，"全栈"貌似已经没那么重要了，尤其在互联网公司可以看到一定有人是专门做前端的，与此同时可以看到很多企业设立了"数据组"这个部门，业务开发与数据开发的岗位需要隔离开来，将“数据的实时计算、离线计算”等纯数据的工作交给数据组，将前端应用、分析、标签等能力交给业务组或许是更好的分工吧。轻量化业务应用，把数据计算单元交给数据开发工程师吧，让企业内的分工更纯粹吧。--我的呼声
数据组的工作包括几个部分，采集数据，建设数据，用好数据，管理数据，今天我想说一下第一个部分采集数据，即"数据集成"。数据集成是将源端数据通过集成到数仓里。源端数据很多种，Dataworks支持了很多如mysql、oracle、datahub等，数据同步方式也分离线同步、实时同步。数据合并也分增量、全量。数据存储分2块，一块在数仓的，如maxcompute的快照表、拉链表、极限存储表等，一块是给业务应用的，如rds、adb等。数据集成部分是数仓的基础，怎么玩转数据集成，需要结合企业的实际需求思考，我打算从这几个方面介绍：
1、数据集成的技术选型。
2、数据集成之离线全量+实时增量ETL详解。
3、数据集成之数据同步。（实时同步、离线同步）
4、数据集成之数据合并与存储。（合并方式、全量表、增量表、增量镜像表、流水表；）
5、数据集成的存储规划。（生命周期）
6、数据集成之超级大表。（订单表）
7、数据集成之数据漂移。
8、数据集成实战案例。（代码）
喜欢的朋友请帮忙点赞，谢谢大家！
