数据库治理之冷热数据分离

优质博文:IT-BLOG-CN

一、背景

随着机票业务的快速发展,订单量持续增长对业务性能带来影响,需要进行冷热数据分离。目前机票订单模块主要使用Mysql(InnoDB)作为数据库存储,历史订单信息状态修改频率低并占用大量数据库存储空间,期望历史数据与生产最新的数据进行分离,当前数据库保留最近一个月的数据作为热库,历史交易存在另一个库作为冷库。减少因在线存储空间不足扩容导致停服不可用的时长。

如何判断一个数据是冷数据还是热数据?
需要根据自己业务系统来区分了,一般而言是根据主表中的一个或者多个字段进行标识区分,比如订单的时间,这个是时间维度,可以将3个月之前的数据定义为冷数据,最近3个月的数据定义为热数据。当然也可以是状态维度,比如订单的状态,已完结的订单定义为冷数据,未完结的订单定义为热数据。同样的也可以将时间维度和状态维度组合起来,比如下单时间大于3个月且订单状态为已完结的定义为冷数据,反则为热数据。

我的冷热数据怎么拆分的:已过起飞时间 + 订单状态=“完成”的数据都是冷数据,其余为热数据。

二、方案选型

业务代码修改

这种方案是在业务代码层面判断是否进行冷热数据分离,对代码的侵入性比较高,在数据修改时触发冷热分离。因机票QPS很高,如果更新状态时,需要进行进行冷热数据分离,删除热库中的数据,并将数据写入冷库中,需要使用到分布式事务。会增加系统和数据库的压力。不适用

监听binlog日志

需要监听binlog日志的方式进行触发,当订单状态修改了,则触发冷热分离。比较适合实时性要求高的系统,这里虽然不会影响业务的响应时间。但是冷热数据分离的操作实时操作的,会给数据库造成压力。不适用,但是有用

怎么读取binlog中的内容,我们通过公司内部开发的DRC服务,这里简单看下重要流程:
【1】在pom.xml中添加MySQL Binlog Connector Java的依赖

<dependency>
    <groupId>com.github.shyiko</groupId>
    <artifactId>mysql-binlog-connector-java</artifactId>
    <version>0.25.0</version>
</dependency>
### 数据治理平台的技术架构 #### 架构概述 数据治理平台的技术架构旨在提供一套完整的解决方案来管理和优化企业内部的数据资产。该架构不仅涵盖了数据的采集、存储、处理和分析,还涉及到了数据质量控制、元数据管理以及安全合规等多个方面[^2]。 #### 主要组成部分 ##### 1. 数据源接入层 负责从不同类型的源头获取原始数据,支持多种协议接口(如APIs, FTP/SFTP等),并能够对接主流数据库管理系统(DBMS)。此部分需具备良好的扩展性和兼容性以适应不断变化的企业需求[^1]。 ##### 2. 存储管理层 采用分布式文件系统或对象存储服务作为底层基础设施,确保大规模非结构化/半结构化数据的有效保存;同时利用关系型数据库或其他NoSQL数据库用于结构化信息持久化。此外,在这一层次上还需要考虑冷热分离策略以便于提高访问效率降低运营成本[^3]。 ##### 3. 数据加工计算层 通过批流一体的方式对流入系统的各类数据进行清洗转换操作,去除噪声点填补缺失值,并按照既定规则完成聚合汇总工作形成可供进一步挖掘的基础素材集。ETL工具链在这里扮演着重要角色,而Spark Streaming/Flink这样的实时流引擎则可以满足低延迟场景下的即时响应要求。 ##### 4. 质量监控评估层 建立全面的质量管理体系,定义清晰可量化的目标指标体系(KPIs),定期开展审计活动检验各项任务执行情况是否达到预期标准。针对发现的问题及时发出预警通知相关人员采取纠正措施直至恢复正常状态为止。 ##### 5. 安全权限管控层 遵循最小授权原则授予用户适当的操作权限范围内的资源访问权能防止越权行为发生造成敏感资料泄露风险事件的发生。加密传输通道保护静态动态两态下个人信息隐私不被窃取篡改破坏。 ##### 6. 应用展示交互层 最终呈现给终端用户的界面应当简洁直观易于理解和使用,无论是BI报表还是可视化仪表盘都应力求做到精准传达核心要点帮助决策者迅速做出判断下达指令。 ```python # Python伪代码示例:构建简单的ETL流程 def etl_process(): raw_data = extract_from_source() # 提取原始数据 cleaned_data = transform(raw_data) # 清洗转换逻辑 load_to_destination(cleaned_data) # 加载到目标位置 etl_process() ```
评论 15
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

程序猿进阶

千言万语都不及一句“谢谢”

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值