抖音、快手数据采集，短视频监测大屏
本文介绍在数据采集过程中不可或缺的一枚神器——数据采集监控大屏，如果想理解数据采集过程中的一些技术，欢送查阅我的另外几篇文章，文末附有两篇数据采集文章的链接。先看上面三张图：
三张图，不同的时间段，对应的日采集数据量别离在 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. 机器宕机。须要重启机器。
案例 2
如下图，抛弃工作暴增。
解析：大量工作已达到重试最大次数，或者呈现大量已重置用户
起因及解决方案：
1. 呈现大量已重置用户。查看是否真的呈现了大量重置用户，如的确如此，可不解决，平台会定时解决该类数据，只需期待 20 分钟即可。
2. 接口被官网反爬，采集不到数据了。须要降级采集代码，优化采集策略。
案例 3
如下图，以后工夫采集数据量中，只有一两个表采集到数据且长时间没有新表退出。
解析：其余表在以后工夫都没有数据入库
起因及解决方案：
1. 以后为定向采集工夫，只采集指定类型的数据。失常，无需解决。
2. 其余类型的数据解析过程出错。检查数据，查看是否会有超长数据，空数据呈现，导致解析失败。如：后期采集到重置用户时，导致解析器报错，现已适配。
3. 历史数据中曾经存在了采集过的数据，数据没有新增。失常，无需解决。
4. 个别表锁表。须要排查数据库，杀死死锁过程。
案例 4
如下图，各机器整体阻塞较高
解析：该局部统计每个机器下面每一类程序的阻塞状况
起因及解决方案：
1. 同一工作阻塞较高。该工作代码性能有余，须要降级代码性能
2. 同一机器不同工作阻塞较高。该机器硬件有余，须要缩小任务量或者降级机器性能。
案例 5
如下图，机器解决工作不均匀，有机器“偷懒”。
解析：该机器执行工作绝对其余机器显著偏少
起因及解决方案：
1. 机器硬件性能较其余机器低。降级机器，应用雷同配置机器。
2. 该机器解决工作较简单。优化取工作策略，不同类型工作随机获取
3. 该机器的过程假死。须要重启该机器上运行的过程。
案例 6
大屏数据更新失常，解决工作失常，然而数据增量较慢。
解析：数据增长较慢，然而解决工作速度失常，应该狐疑是否是因为丢数据引起
起因及解决方案：
1. 有数据未解析，间接跳过。须要排查未解决数据的类型。
2. 锁表。须要手动开释锁，批改代码，所有的写操作均用主键 ID
以上为这两个多月工夫中，见过的一些常见案例，此类问题均由该监控大屏抛出，并以解决。
更多抖音，快手，小红书数据实时采集接口，请查看文档：TiToData