揭秘白条数据架构演变历程

第一次演变

时间：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 一般不存在丢数据的问题。

• 易扩展性，不针对业务(无业务侵入)，只针对数据库。

• 支持无限扩容，海量数据。

总结

白条大数据平台诞生之初正是互联网行业的高速发展期，经历这些年的发展，取得了很大的进步，从草根走向专业，从弱小走向规模，从分散走向统一，从杂乱走向规范。 本文主要讲述了几年来白条大数据平台架构演进的过程，技术架构单独拿出来看我认为没有绝对的好与不好，需要要放在彼时的背景下来看，要考虑业务的时效价值、团队的规模和能力、环境基础设施等等方面。 架构演进的生命周期适时匹配好业务的生命周期，才能发挥最好的效果。