全量同步
数据初始化装载的时候,一定使用的是全量同步的方式。
全量同步数据时,如果数据量过大,会导致 ETL 流程非常慢,甚至周期会长达几个月。对于结构化数据,常用工具采用的是 JDBC 的方式直接连接到数据库进行抽取,所以会对数据库端带来极大的负载和压力,降低数据库端的稳定性。当然 JDBC 方案如果可行,那它是最简单的方式。如果存在风险,或者周期过长,可以采用抽取数据库日志的方式,这种架构需要数据库开放相应的功能,并且使用特定工具来进行;但它的抽取速度极快,而且不会对数据库端带来压力;如 Oracle 采用的是 OGG 方式,而 MySQL、SQL Server 等使用 CDC 方式。
对于非结构化、半结构化数据,因为本身并没有结构化数据复杂,所以全量同步会非常容易,依靠抽取工具自带的功能即可完成快速初始化状态工作。
除了第一次数据装载,之后每日的数据更新推荐使用增量同步方式。但在实际场景中,因为业务、技术原因,每天给到的数据只能是当日全量的数据,那当然也可以选择全量的方式对数据进行更新。在这种方式中,新的全量数据可以直接覆盖掉历史数据;如果担心数据丢失的话,可以创建时间分区,每天保存最新的全量版本,保留较短周期。虽然全量更新带来了计算量的增加,但相对于增量技术,它是最容易实现的一种方式。
增量同步
在数据规模巨大的情况下,第一次数据以全量方式同步到数据仓库后,之后的数据可以使用增量采集的方式进行。
对于结构化数据,增量数据采集方式推荐对数据库日志进行抽取,因为数据库日志是顺序追加的,对某个时间点后的数据变动会更容易追踪,如 Oracle 提供的 OGG 方式,开源的 CDC 技术,它是增量同步的一种通用的解决方案;当然也可以直接对数据库使用 JDBC 方式进行抽取,此时数据需要有 create_time 和 update_time 字段,以便使用 SQL 筛选新增和修改的数据。但日志抽取的方式,速度更快,对数据库影响也最少。
对于非结构化、半结构化数据,增量抽取则更为简单,一般的抽取工具都自带数据监控功能,可以实时将变动的数据进行抽取、
获取到增量数据之后,传统数据整合方案中,大多使用 merge 方式(update + insert)。但主流大数据平台并不支持 update 操作(数据更新意味着随机读写,而在分布式、强调分区容错性的大数据平台中,代价会非常大);所以一般会采用全外连接 + 数据全量覆盖的方式。