数据采集平台2.0架构设计横空出世

　　

数据采集平台2.0架构设计横空出世

　　抖音、快手data采集、短视频监控大屏、data采集视化大屏

　　本文介绍了data采集-data采集控大屏过程中必不可少的神器。如果想了解data采集过程中的一些技术，请参考我的其他文章文章，文末有两个数据链接采集文章。

　　如需data采集interface SDK，请点击查看接口文档

　　先看下面三张图：

　　

　　

　　

　　三张图，在不同的时间段，对应的采集日数据量分别为10万、30万、110万。我不断刷新我设置的单日采集数据量记录。有些人可能会好奇。为什么采集最近两天收到的数据量激增？偷偷告诉大家，这两天是新架构设计完成后开始测试的两天。首日轻松达到53W数据，突破此前极值。数值几乎翻了一倍，第二天就突破了100W。因此，前槽是新架构开发和测试的时间。图片来自data采集monitoring大屏，完整图如下：

　　

　　从上面的截图可以看出，目前数据平台采集总共有近700W的数据，采集每天的数据已经达到110W以上，每天的处理任务量已经达到30W或者更多，可以查看不同业务渠道采集接收到的不同数据量。建设这块大屏的初衷，是为了监控采集平台的数据各方面的表现。在优化采集平台性能的同时，监控大屏也在不断优化自身性能，占用的平台资源越来越少。最大的优化是每日采集数据量统计图。随着数据量的不断增加，不仅平台压力越来越重，监控大屏的性能也越来越差，统计的阻塞次数也越来越多。这个块号监控内存中线程的阻塞情况。算了，如果这个数字越来越大，最直接的后果就是崩溃了。每天的数据量还在增加，业务在不断扩大，硬件资源这么多。迫切需要寻找新的解决方案。在这个场景下，data采集平台2.0架构设计横空出世，解决了所有拥塞问题，每日采集数据量从30万增加到110万，理论值从50万增加到 160 万。 data采集平台2.0架构设计为未来数据爆炸预留空间，支持分布式横向扩展。这样，随着未来数据的增长，升级变得非常简单。下一篇文章主要介绍这款大屏。

　　监控大屏介绍

　　监控画面主要采用数据可视化技术对采集平台进行监控，定期刷新平台运行数据。通过这个监控画面，发现了平台的死锁问题。当时问题很隐蔽，平台没有报错，数据还在不断增加。隔着大屏幕，我发现数据增长变慢了一些。有几个表在数据库中没有数据。后来开始排查，发现了一个平台死锁问题。如果问题没有被发现，后续的损失将变得无法控制。大屏监控功能如下：

　　1.每日采集数据量：计算采集每天最近收到的平台数据量，判断一段时间内平台的健康状况和负载。可以根据该指标制定性能测试计划。

　　

　　2.每台主机执行的任务统计：统计当前小时每台机器执行的任务数，以确定每台机器的性能和资源分配。

　　

　　3.全网数据量：统计整个平台的实时数据量，判断平台压力，判断是否需要升级新架构。

　　

　　4.当前时间采集数据量：统计当前小时各表添加的数据量，监控各类型数据是否正确存入数据库。

　　

　　5.全网数据分布：统计平台上所有表的数据量，确定每个表的压力，为后续的分库分表提供依据。

　　

　　6.Blocking count statistics：统计一个主机中每个程序阻塞的线程数，以判断每台机器的性能。阻塞的越多，占用的内存越多，最终会导致机器崩溃。理想情况下，这是空白的，即程序没有被阻塞。

　　

　　7.各种任务的执行次数：统计不同类型、不同状态的任务数，判断平台执行任务的速度和准确性。

　　

　　8.采集速度监控，使用仪表盘监控当前实时数据采集速度和监控过程中出现的采集速度峰值，判断平台实时效率.

　　

　　通过以上八部分实时数据，可以监控采集平台运行状态的全部数据。目前，大屏已经运行了两个多月。以下是一些常见的问题案例：

　　案例 1

　　如下图，有1440个任务要执行，16个任务正在执行，主机执行任务统计图为空，超过1分钟没有刷新数据。

　　

　　分析：任务无法执行，当前小时内没有任务完成

　　原因和解决方案：

　　1.任务复杂，短时间内无法完成（几乎不可能出现这种情况）

　　2.程序挂了，任务无法执行。需要重启程序

　　3.内存不足，程序自动结束。需要重启程序

　　4.机器坏了。需要重启机器。

　　案例 2

　　如下图所示，丢弃的任务数量猛增。

　　

　　分析：大量任务已达到最大重试次数，或出现大量重置用户

　　原因和解决方案：

　　1. 有大量重置用户。检查是否有大量重置用户。如果是这样，请不要处理它。平台会定期处理此类数据，您只需等待20分钟。

　　2.界面已被官方重新抓取，采集不再可用。需要升级采集代码，优化采集策略。

　　案例 3

　　如下图所示，当前时间采集数据量中，只有一两张表采集有数据，而且很长时间没有新增表。

　　

　　分析：当前数据库中没有其他表有数据

　　原因和解决方案：

　　1.当前指向采集time，只有采集指定了数据的类型。正常，不需要处理。

　　2.其他类型的数据解析时出错。查看数据是否有过长的数据，出现空数据，导致分析失败。比如前段时间采集重置用户时，导致解析器报错，现在适配。

　　3.历史数据已经有采集有的数据，没有添加数据。正常，不需要处理。

　　4.Individual 表锁表。需要排查数据库，杀死死锁进程。

　　案例 4

　　如下图所示，每台机器的整体阻塞比较高

　　

　　分析：这部分统计每台机器上每种程序的阻塞情况

　　原因和解决方案：

　　1.同一个任务阻塞高。任务代码性能不足，代码性能需要升级

　　2.同一台机器上不同任务的阻塞度很高。机器硬件不足，需要减少任务量或提升机器性能。

　　案例 5

　　如下图所示，机器处理任务参差不齐，部分机器“偷懒”。

　　

　　分析：该机器执行的任务明显少于其他机器

　　原因和解决方案：

　　1.机器的硬件性能低于其他机器。升级机器，使用相同配置的机器。

　　2.这台机器的加工任务比较复杂。优化任务获取策略，随机获取不同类型的任务

　　3.本机进程挂起。机器上运行的进程需要重新启动。

　　案例 6

　　大屏数据更新正常，处理任务正常，但数据增量慢。

　　分析：数据增长缓慢，但处理任务速度正常，怀疑是不是数据丢失造成的

　　原因和解决方案：

　　1.有未解析的数据，跳过。需要调查未处理数据的类型。

　　2.lock 表。需要手动释放锁，修改代码，所有写操作使用主键ID

　　以上是过去两个月左右看到的一些常见案例。此类问题被大监控屏幕抛出并解决。