完整的采集神器( 数据采集平台2.0架构设计为将来的数据暴增预留了160万)

　　完整的采集神器(

数据采集平台2.0架构设计为将来的数据暴增预留了160万)

　　抖音，快手数据采集，短视频监控大屏

　　本文介绍了数据采集-数据采集监控大屏过程中不可缺少的神器，如果想了解数据采集过程中的一些技术，请参考我的补充几篇文章，文末有两个数据链接采集文章。先看下面三张图：

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

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

　　监控大屏介绍

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

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

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

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

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

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

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

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

　　8.采集速度监控，利用仪表盘实时监控当前数据采集速度，以及监控过程中采集速度峰值，以判断平台的实时效率。

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

　　情况1

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

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

　　原因及解决办法：

　　1. 任务复杂，短时间内无法完成（这几乎是不可能的）

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

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

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

　　案例二

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

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

　　原因及解决办法：

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

　　2.界面被官方重新抓取，采集没有更多数据。需要升级采集代码，优化采集策略。

　　案例3

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

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

　　原因及解决办法：

　　1.目前是定向采集时间，只有采集指定类型的数据。正常，没必要处理。

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

　　3. 历史数据已经收录了采集的数据，没有添加数据。正常，没必要处理。

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

　　案例四

　　如下图，每台机器整体拥塞比较高

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

　　原因及解决办法：

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

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

　　案例5

　　如下图所示，机器加工任务参差不齐，有的机器“偷懒”。

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

　　原因及解决办法：

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

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

　　3.机器进程假死。机器上运行的进程需要重新启动。

　　案例6

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

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

　　原因及解决办法：

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

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

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

　　更多抖音、快手、小红书数据实时采集接口请查看文档：TiToData