申明：文中涉及到的图片均为原创，未经授权，不得使用。

公众号原文链接：
数据平台初试（架构篇）——平台架构演化
​
本文主要介绍数据采集平台的三种架构设计，以支撑不同数据量的采集。之前监控大屏中曾出现了三张不同时间段的统计图，下面再看看这三张图：


三张图，不同的时间段，对应的日采集数据量分别在10万，30万，110万，这三个数值，是每日采集数据量的极大值，在2020伊始，平台日采集量在10W量级，两周之后达到了30W+，而在1月31日当天，数据量爆发式的达到了110W+。接下来分别对这三个场景下的平台架构做简单的介绍。

石器时代

第一张图，日采集数据量10W+，此时平台还未稳定，采集数据需要手工提交，平台采集效率较低，没有多节点支撑。此时，平台不需要做特别的性能优化，数据采集下来之后直接解析入库。存在的问题是目前平台处于开发初期，更新较快，需要手工提交任务，或者手工采集，需要人工维护整个平台的运行，人走则停。此时采集数据类型已经满足业务需求，但是由于无法实现自动化处理，效率较低。需要将手工处理设计为自动化处理，增加多节点采集数据。该设计将数据量从0拉升到了十万，随后平台进入青铜时代。

青铜时代

日采集数据量30W，此时已解决了以上提出的问题，任务处理自动化，采集器实现了分布式处理，多台模拟器同时运行，此时平台已经趋于稳定，形成了固定模式的系统架构，如下图：

由上图可知，采集数据加入了简单的缓存机制，采集器与解析器相对分离，采集器专注于互联网数据的采集，而解析器专注于在缓存中获取数据之后进行解析，解析完成后将结构化数据入库，该设计在初期运行稳定，采集速度也较快，数据库每天能稳定增加30W数据。

问题的出现：在平稳运行一段时间后，系统开始出现延时，最明显的现象就是监控大屏出现线程阻塞。自此，平台开始占用机器额外内存，此时采集器并不知道下游的解析器无法完成解析任务，采集器还是会源源不断的将数据采集回来放入缓存中，随着内存的增大，机器性能降低，为了避免陷入恶性循环，不得不将采集器关闭，等待解析器慢慢将堆积的数据取走。由于该问题的出现，日采集数据达到极限，无法再往上增长。

排查：此时总数据量在300W，后经排查，存在的问题如下：

1.数据入库之前，由于为了避免数据重复，做了一个存在性校验，由于前期未考虑数据暴增问题，在数据库表结构设计时存在一定缺陷，导致此处需要走一步存在性校验，影响入库性能。

2.机器地理位置缺陷：由于机器是分几次购买的，而且主要依赖于优惠政策，所以导致几个机器不在同一地区。在入库过程中，数据需要网络传输，由于网络延时，入库过程及其缓慢，导致整个数据堆积。该问题经有限优化，堆积数据得到一定缓解。

随着总数据量的提升，问题依然存在，而且堆积不断增多，单位时间入库数据量不断减少，急需新的设计介入，对平台做一次大型升级。该设计将数据量从十万拉升到了400W，随后平台进入电气时代。

电气时代

由于以上两个问题的不断升级，机器资源无法更换，只能在软件层面不断提升性能，经过排查和研究，需要解决的问题如下：

1.入库之前不做存在性校验，但是不能导致数据重复
2.机器分散，在入库过程中网络延时较大
3.在数据高峰，阻塞过高，使得机器内存占用过大

针对以上问题，经过研究，得到了解决方案：
1.入库直接判断主键是否存在，存在则更新，不存在则插入。该操作需要修改原数据库表结构设计。
2.减少网络传输次数。该操作通过批处理可解决，每次入库1000条等类似措施。
3.数据高峰阻塞过高，内存占用多。将阻塞的数据不放在内存，直接写入硬盘。

根据以上三点，新的设计图如下：

根据设计图可以看出来，主要做的改进在两块，一块是在采集器后面加入了kafka，采集器采集到数据后，短暂放入缓存队列，再批量放入kafka，解决了采集器一侧的数据堆积问题。第二部分是整个解析器，重新构造json解析器，由原来的python切换为java，支持分布式解析，速度提升3倍左右，解决了解析器部分的阻塞，即使在数据高峰，数据也会顺序写入硬盘，不会使内存占用过多。第三部分是解析器后面的数据入库逻辑，加入了缓存队列和批处理，大大节省了网络延时，一次网络延时将入库1000条数据，其他时间机器资源就可以执行其他操作。第四部分提升是数据库中表结构的修改，不再使用自增ID，目前直接使用采集到的ID，可以直接判断数据是否在库中存在。

该设计在升级完成后的第一天测试，10个小时数据量就达到了53W，远远超过之前24小时采集到的34W数据，而第二天性能测试，开启两台模拟器采集数据，15小时采集111W数据，远远超出第一代架构设计。目前还没有进行更持久的测试，根据性能测试当天的表现，平台性能远没有达到饱和，测试使用的服务端机器为1核2G内存，部署了kafka和解析器，监控大屏。采集器为本地笔记本拖两台模拟器。预测平台解析能力能拖4台模拟器，日采集数据量极大值能超过200W，曾经也出现过一个小时采集30W数据的极端环境，平台依然平稳运行，升级之后平台总体性能基本满意。目前该设计已经投入使用，也是真正能上生产环境的第一个架构设计，截止目前，该设计将数据量从400W拉升到了1000W，并将继续增长，期待未来的表现。

未来时代

目前的设计，理论上能将数据量拉升到几千万，此后，虽然平台支持横向扩展，但是数据库需要寻找新方案实现，继续使用mysql则需要分库分表，目前的定位是，当未来数据爆炸的时候，存储库由mysql切换为HBase，再设置索引到内存数据库，提升查询速度。整个设计图如下：

一款来自未来的设计，该设计全部支持分布式集群环境架构，所有组件支持横向扩展，在未来，该架构设计将打造大规模数据采集与存储平台，投入使用之后将可以通过简单的配置扩展机器资源，满足中期平台的业务扩张，该设计计划将平台数据由千万级别拉升到十亿乃至于百亿级别。

以上就是目前采集平台的架构设计演化史，简单分享出来，可以给正在摸索的朋友一个参考。喜欢的朋友欢迎点赞收藏订阅，能点个关注就更好啦，我将不定时更新一些文章，公众号和其他平台不经常登录，如有需要，可以给我留言或者添加我的公众号同名微信“SPWanderer”，备注“交流”即可。

往期回顾

数据可视化大屏的价值——从超市实时营业额作战平台说起
实时大屏如何支撑海量数据处理——超市实时监控大屏V2.x
数据平台初试（技术篇）——抖音数据采集（初级版）
数据平台初试（技术篇）——抖音数据采集（高级版）
数据平台初试（产品篇）——监控大屏初露面