本文共 1173 字，大约阅读时间需要 3 分钟。

在提升一个高度，站在CDO的角度，我们更关注数据流是否能及时传导到各种目的地，而不是具体使用哪种数据库。关键在于数据必须通过管道加工处理，并提供验证机制来确保计算数据的准确性。因此，传统ETL工具可能已经无法满足现代企业的需求。

业务部门数据源于历史原因，使用的关系型数据库种类繁多：ORACLE、SQL SERVER、MYSQL、MONGODB、甚至PostgreSQL。如何在大数据平台上整合这些数据库中的部分数据，用一个统一的数据流将其输送到目标目的地？这需要一个高效的数据交换中心。

另一个挑战是业务数据库设计初期未考虑ETL抽取场景。大量数据在没有时间字段的情况下，如何识别增量数据？而且，当数据量达到上百GB时，抽取增量数据的效率和准确性更是一项难题。

目前业务部门的需求更加多元化：业务数据更新后，通常要求在1个小时内传递到数据部门进行处理，而最终生成DATAVIEW。同时，业务部门的分析人员技能多样，有的精通T-SQL，有的擅长PL/SQL，甚至只有JAVA技能。这使得数据的目的地和处理方式变得多样化。

更复杂的问题是数据库更新：由于ORACLE被逐渐替代为PostgreSQL，需要进行灰度发布。当前规则是实时同步ORACLE与PostgreSQL，并在上线后清除ORACLE数据。然而，这种方式存在数据同步延迟、准确性问题以及数据提取对业务系统造成负担的风险。

这样的问题不仅关系到数据获取质量，更会引发业务系统投诉和运维痛点。当降低指标时，背锅自然就集中在数据获取环节的运维小组。此外，数据传输过程中还可能面临安全性审批问题，这在快速变化的市场环境下效率低下，无疑会导致数据过时。

因此，我们需要一个能够支持多种数据源和目的地的数据获取平台，具备以下关键特征：

1、数据可实时获取，通过一条统一的数据流将业务数据（如水流）顺畅输送至各个目的地。

2、支持ORACLE、PostgreSQL、SQL SERVER、MYSQL、MONGODB等多种数据库以及传统大数据软件的联接。

3、能够在数据流转过程中进行轻量化的数据变换，剔除冗余数据，并在源端对数据进行截止控制。

4、部署方便，不需要在数据源端安装额外软件。

5、自动化ETL和数据调度流程，将数据传输一致性隐藏起来，避免传统ETL的复杂调度问题。

这样的解决方案有吗？抱歉，貌似没有。但很高兴地，我们可以基于各数据库底层原理，利用其特性（如ORACLE的重存序列、SQL SERVER的CDC、二进制日志、PostgreSQL的WAL、MONGODB的OPLOG）设计自定义数据获取工具来实现这些能力。

在中国市场，已经有一些高科技企业实现了类似的功能，将静止的数据库业务数据转变为实时流，将数据索取者的获得和数据提供者的轻松统一。这些企业的成功经验值得深入研究。

转载地址：http://qgqez.baihongyu.com/