第一次演变
时间:2014.1~2015.5
目的:解决核心和非核心业务系统对关键数据库的访问;提供一个分库分表后白条数据汇总平台;满足财务结算、运营系统、客服系统对白条的数据查询(非核心业务不对主业务库做相关的数据处理)。
白条业务系统(贷、分期、还、逾、退)所生产的数据信息通过 MQ 异步将数据信息更新到 solr 集群中,solr 集群将数据表信息和 collection 进行一一对应,collection 里做 shard(针对不同表的数据 shard 的个数也不一样) 来分散数据的存储。使用 solr+hbase 做为介质,solr 做表里需要查询字段的索引,hbase 做全量数据存储。
1 Solr+hbase 数据架构
2 Solr+hbase 架构的优缺点
优点
数据写入 solr 中,少量数据(>30 亿)性能非常好,通过 solr 进行 shard 部署。
对实时性不是非常高的业务,直接可以查询 solr,减少到核心业务库的压力。
缺点
大数据量的写入及查询慢。
当有节点挂了,经常需要重启整体集群来保证集群稳定性。
solr 扩展性复杂,业务侵入性大。
第二次演变
时间:2015.6~2016.5
目的:随着业务增加,数据量不断的呈几何倍的增涨,对数据质量及完整性的要求越来越高;结算人员需导入及导出大量线上数据作为结算处理,solr+hbase 已满足不了,由此产生了白条 mongodb 的数据架构。
白条 mongodb 数据架构是引进 nosql 将业务产生的数据信息存入 mongodb,使用 mongodb 集群来按月来分表,mongodb 集群分为 3 个 mongos 、3 个 config、3 个 replica set,replica set 里也采用分片来分散数据的存储,通过 mongos 和应用系统进行数据交互。
1 白条 mongdb 数据架构
2 白条 mongdb 数据架构优缺点
优点:
通过按月来进行分表存储,只查询近一个月的热点数据,速度非常快,性能高。
非结构化数据存储,没有固定的表结构,不用为了修改表结构而进行数据迁移。
缺点:
业务侵入性大,只要有数据更新,就需要在业务里做代码逻辑处理,耦合度太高,复杂。
数据量在>60 亿,mongodb 架构非常适合。
mongdb 比较耗内存,热点数据都放在内存里,以内存换取时间性能。
mongodb 容量问题,单台服务器的硬盘容量是固定的,业务成倍扩增长,数据量也增长非常迅速,当超过整个集群的容量时,扩容非常麻烦。因此在做 mongodb 架构时需要考虑数据量问题,复制集扩展难度大。
第三次演变
时间:2016.10~2017.6
目的:还是业务迅速发展,数据量暴涨(60 亿+),对数据的质量及完整性的要求越来越高,业务查询量大, mongodb 经常被容量问题所困惑,有性能问题影响。并为财务、运营、客服、对账内部提供高安全、高可靠、高性能的服务
白条大数据平台,通过使用 dbrep 组件,模拟 mysql 的 slave 的方式,实时获取增量 binlog,通过解析 binglog,采集数据库变动内容,并将变动内容以 json 格式存储到(kafka)消息系统,消费端通过分布式来消费 kafka 中的消息数据信息,将消息数据按指定的 ES 索引列往 ES 里写入,并写入到 Hbase 大数据平台,大数据平台内部提供高安全、高可靠、高性能的服务。
1 白条大数据平台架构
Dbrep 是基于 kafka、zookeeper、flume 搭建的准实时数据同步系统,其主要涉及以下几大模块。
Dbrep-node:是 dbrep 的运行容器,根据配置,其上可以运行 dbrep 提供的各种 agent 组件,如数据采集、数据落库等常用数据同步组件。
Dbrep-consumer:以嵌入的方式运行在用户应用程序上,根据配置从消息中间件订阅消息,并交给用户相应的处理器进行处理。
Dbrep-console:dbrep 配置管理控制台,负责 node 和 consumer 具体配置信息的配置,及状态监控,异常告警等基础功能。
ZK 集群:存储 dbrep 基本配置,以及 dbrep 各节点间状态协调。
KAFKA 集群:存储数据变动记录。
2 大数据平台架构的优势
数据实时性强,通过 binlog 做 mysql 的 slave 基本是秒级数据同步。
数据完整性高,准确性高,mysql 的 binlog 一般不存在丢数据的问题。
易扩展性,不针对业务(无业务侵入),只针对数据库。
支持无限扩容,海量数据。
总结
白条大数据平台诞生之初正是互联网行业的高速发展期,经历这些年的发展,取得了很大的进步,从草根走向专业,从弱小走向规模,从分散走向统一,从杂乱走向规范。 本文主要讲述了几年来白条大数据平台架构演进的过程,技术架构单独拿出来看我认为没有绝对的好与不好,需要要放在彼时的背景下来看,要考虑业务的时效价值、团队的规模和能力、环境基础设施等等方面。 架构演进的生命周期适时匹配好业务的生命周期,才能发挥最好的效果。
评论