博客
关于我
关于数据、数据流、数据管道的一些看法(一)
阅读量:718 次
发布时间:2019-03-21

本文共 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/

你可能感兴趣的文章
MySQL主从、环境搭建、主从配制
查看>>
Mysql主从不同步
查看>>
mysql主从同步及清除信息
查看>>
MySQL主从同步相关-主从多久的延迟?
查看>>
mysql主从同步配置方法和原理
查看>>
mysql主从复制 master和slave配置的参数大全
查看>>
MySQL主从复制几个重要的启动选项
查看>>
MySQL主从复制及排错
查看>>
mysql主从复制及故障修复
查看>>
MySQL主从复制的原理和实践操作
查看>>
webpack loader配置全流程详解
查看>>
mysql主从复制,读写分离,半同步复制实现
查看>>
MySQL主从失败 错误Got fatal error 1236解决方法
查看>>
MySQL主从架构与读写分离实战
查看>>
MySQL主从篇:死磕主从复制中数据同步原理与优化
查看>>
mysql主从配置
查看>>
MySQL之2003-Can‘t connect to MySQL server on ‘localhost‘(10038)的解决办法
查看>>
MySQL之CRUD
查看>>
MySQL之DML
查看>>
Mysql之IN 和 Exists 用法
查看>>