数据中台
数据中台( Data Centered Platform ) 是现代化管理数据方案, 在常规后台和数据库之中追加层数据处理层;
也就是废除常规 Web <-> DB 架构演变成 Web <-> Center <-> DB 中间做数据清理.
这样相比常规架构有以下好处:
- 隔离子业务直接访问数据库, 保证数据安全性
- 统一数据获取入口, 打通业务平台直接让多套系统统一
- 避免重复的数据筛选工作, 直接请求通用中心获取数据
- 数据中间层方便数据高效筛选和获取
- 减少运维管理成本, 多套系统和数据库集中在单套分布式服务器
项目架构演变路程:
- 项目立项: 单套后台系统和单数据库提供服务, 没有太复杂的角色权限,
运维|运营共用管理中心 - 项目发展: 数据量暴涨并且单库单表开始无法承载, 需要分库分表和后台执行常驻任务清洗数据
- 项目成熟: 角色细分,
运营|运维|渠道商|客服等业务拆分出来做复杂权限操作和查询, 还需要大量数据筛选统计
这样构建的好处就是避免业务碎片化, 比如需要知道客服业务需要去登录 XXX客户中心, 需要渠道业务需要去登录 YYY渠道中心,
诸如此类多系统在新人理解业务时候带来思维凌乱的问题, 每个系统可能业务相同但是有好几份代码.
比如 A 中心本身代码有查询用户数据功能, B 中心也有类似业务但是实现的是另外代码业务, 后面扩展 C 中心也类似
当然也不是提倡什么业务一开始就直接采用这种复杂架构方式, 因为本身设计这种架构对于开发人员来说需要很深厚的技术功底, 同时也要对线上业务有比较深入接触才能知道对应架构痛点.
对于项目初期盲目采用数据中台架构会导致项目更加混乱, 项目初期数据量级本身没达到要这样处理的地步
项目迈入成熟阶段比较明显的特征就是获取效率越来越低下, 且业务开始有数据主体关联( 渠道 - 用户 开始建立强关联 ).
刚开始筛选过滤数据统计数据还能依靠后台跑脚本重新落地数据库新表来查询获取, 但是后续业务扩展出来就开始混乱, 因为成熟项目后续统计业务可能不止简单几张汇总, 最低也会设计十几种跨越最少三个月数据统计汇总情况.
还有数据导出业务再也不能采用数据直接导出情况, 而是应该采用任务队列在后台运行导出生成文件发送给用户引导下载,
否则有的数据量能够直接撑爆数据库直接爆 OOM 错误导致数据库瘫痪.
现有数据中台业务有比较常规 ClickHourse 的数据仓库情况和 Neo4j 强关联数据汇总, 可以按照自身需要来区分选择,
主要就是要思考该更好对数据进行关联和聚合从而更快响应用户查询, 如果需要用户耗费十几秒才能获取想要的数据那么这时候很可能错过很多机会.
时间就是金钱, 值得用空间去换取从而节约时间消耗
数据占用空间庞大确实是问题, 但是可以依靠抛弃过期数据来优化处理, 但是如果查询汇总|导出缓慢很可能错过大量市场机会; 比如当天游戏开服时候需要看到留存统计确认数据买量的情况, 这时候每时每刻都是烧钱导入玩家用户, 所以会后台频繁接受市场运营数据获取情况, 从而需要按照汇总数据不同情况来及时调整游戏内部活动情况.