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

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

本文介绍在数据采集过程当中不可或缺的一枚神器——数据采集监控大屏，若是想了解数据采集过程当中的一些技术，欢迎查阅个人另外几篇文章，文末附有两篇数据采集文章的连接。先看下面三张图：



三张图，不一样的时间段，对应的日采集数据量分别在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