作者｜Hiro
作者介绍
Hiro，爱奇艺助理研究员，从2014年至今一直参与爱奇艺直播业务研发。主要负责直播业务后端，直播风控，直播大数据平台等。对于直播行业，有自己独到的思考与探索。
请输入标题 abcdefg
导 读
2016年被称为“互联网直播元年”，从技术和内容上来说，直播早已不是什么新鲜事。直播行业火热同时，也面临着严峻的安全问题。
直播平台由于其业务的多样性，包含了各种打赏，免费奖励，直播间人气造假等牟利点。在利益的驱使与直播平台的博弈中，黑产从野蛮粗暴的刷机行为，慢慢演变成低频分散的拟人行为，真假莫辨。
1
生长-直播平台的风险
爱奇艺奇秀直播（以下简称奇秀），于2014年上线。经历了黑产从无到有，从小量到爆发的各阶段，促使我们构建起针对直播业务的风控安全体系。
总结下来奇秀黑产最鲜明的特征是：挂号 + 抢红包。
特征 1：挂号
通过外挂连接直播聊天室，伪造房间人气。峰值期间有超过 85%的在线用户为挂号用户。我们通过聊天室日志分析，对挂号问题重点打击。目前比例控制在合理范围内：10%~30%。某宝上搜索奇秀外挂软件，也从”一把抓”到目前的“踪迹难寻”。
（图1某挂号软件截图）
特征 2：抢红包
红包是大户对其他用户打赏的一种道具，红包里包含有价的货币与礼物。上线初期，有超过 50%的红包被黑产抢到，而普通用户基本无法抢到。同时部分违规主播的收益绝大多数来自红包黑产，也揭露出主播在风险监管上的盲区。通过大数据关联与聚类分析，目前黑产抢到红包比例控制在3%以内。
（图2 黑产红包流向）
2
势在必行 - 直播风控系统
形式险峻，为此奇秀技术团队自研了基于直播业务的风控系统。
涉及的技术主要分两大块：实时拦截系统（Pluto冥王星）+ 大数据分析系统（Mars火星）。
直播业务的特点也融入到两大系统中。例如，用户行为的特征工程，直播场景下可以将直播流与聊天室行为作为特征向量。主播收入分析，结合直播资金来源链路统计。目前 Pluto实时拦截请求量日均突破 1 亿，Mars 大数据分析数据量日均超过 10 亿，涉及的黑产账号突破 1000 万。
3
时拦截系统 Pluto（冥王星）
针对直播业务的实时互动特性，我们设计了实时拦截系统Pluto。首先通过业务离线数据分析与训练，定制 Pluto 初步拦截策略。业务方在敏感接口调用实时拦截服务，同时上传实时数据，并对黑产拦截和惩罚。实时数据会进一步循环提供策略调整，达到一个良性循环。
目前实时系统针对指定业务的平均拦截率超过 30%，针对抢红包的实时拦截率超过 85%。
（图 3pluto 架构示意图）
Pluto接入方式
由于直播业务的多样性，Pluto提供了多种接入方式。目前支持 3 种接入方式：API 接入、日志接入、MQ 接入。各有优劣，但本质上还是需要业务方把尽可能准确的数据投递给 Pluto。常用的参数包含user-agent、platform、指纹信息等。
接入方式
描述
使用场景
API接入
http接口，实时调用并返回结果。有代码侵入，同时要求业务做好超时与降级。
充值、消费、红包
日志接入
一般是指nginx日志，有一定的延时性，无代码侵入。处理结果异步推送到业务MQ或者DB。
直播间访问，列表展示
MQ接入
订阅业务已有MQ Topic，有一定的延时性，无代码侵入。处理结果异步推送到业务MQ或者DB。
榜单计算，聊天室连接
Pluto决策系统
决策系统采用过滤器链模式来拦截请求，每个请求通过决策中心调度到多个过滤器分别处理。过滤器链，简而言之就是将复杂的风控拦截规则拆分成多个 filter。
风控系统采用过滤器链模式设计的好处：各个过滤器职责分离，降低系统的耦合度。
决策系统支持异步、多线程、线程池化，数据库连接池化，将请求分发到各个 Service 中去处理。单个业务点支持多种规则决策，同时决策的调整可以保证 3 秒内推送上线。
一些典型的过滤器有：
过滤器
规则
描述
APS
请求量拦截
令牌桶算法演变实现。
例如，1分钟允许请求10次，超过阈值拦截。
Cooltime
冷却时间拦截
漏洞算法演变实现。
例如，请求间隔10秒，超过阈值拦截。
Whitelist
业务白名单
结合业务场景配置白名单
例如，主播、大户等加入白名单，不做拦截处理
Blacklist
业务黑名单
核心拦截器
将日志实时采集到大数据分析系统Mars，计算完成后产出到对应业务的blacklist中。
…
……
……
Pluto作为一个强劲的实时拦截系统，可以支持 10 亿/天调用量，拦截量突破 1 亿/天，平均耗时小于 10ms。同时Pluto也起到了承上启下的作用，为大数据分析系统 Mars 采集数据并接入 Mars 分析结果。
4
大数据分析系统Mars（火星）
在Pluto上线初期，简单的aps、cooltime策略已经可以拦截大部分黑产。但好景不长，黑产已经意识到简单的频率规则，并开始试验我们的阈值。接着开始往低频化拟人化发展，单从频率上已经无法直接识别用户与黑产。由此，我们意识到构建大数据平台的重要性。
Mars 的架构可以简单概括为：数据，计算，产出。
（图 4 Mars 架构示意图）
Mars 数据
数据采集前会做简单的数据清洗，清洗完成再经由 Kafka下发到 Spark、Hadoop、Elasticsearch这3条通道。Spark作为近实时计算，Hadoop作为离线计算与存储，Elasticsearch 提供实时热数据查询。目前 Mars 数据量突破 20 亿/天，并在持续增长中。
直播业务场景复杂，数据采集依赖业务方配合。在现实场景中，我们遇到过各种奇葩情况，比如参数丢失、参数混淆、各端数据不一致等。针对数据采集有几个建议提供给大家：
1
优先服务端抓取
客户端投递会受网络等情况影响，产生数据丢失，同时容易将参数暴露给用户。之前某业务将IP参数投递，造成 IP 的伪造。
2
务必保留原始日志
Flume、 Logstash等Log系统已经相对成熟，但是理论上还是会存在日志丢失的情况。业务本地日志务必要保留一定周期。
3
Elasticsearch 不是万能的
ELK 作为日志通用解决方案，被大量互联网公司使用。但是不建议将Elasticsearch作为大数据永久存储和复杂的业务查询计算，生产中应当配合 Hadoop、Spark等大数据系统组合使用。
Mars计算
由于黑产行为越来越接近正常用户，Mars计算的核心目标就是：识别异常行为用户。由于黑产的行为是通过程序来模拟的，存在一定的相似性。借助大数据平台与分析算法，能将黑产用户有效抓到。
Mars 常用工具如下：
分类
规则
描述
离线计算
Hive /
Impala
Hive分析10GB级数据需要分钟级，一般用作每日汇总、长期数据对比。
Cooltime
Spark
Spark分析10GB级数据仅几秒钟，一般用作实时性高的场景，如注册分析，红包分析。
Mars 常用算法如下：
类别
描述
关联性分析
应用场景：
抢红包风控，通过关联抢红包的上下游业务，有效控制黑产比例＜3%
聚类分析
应用场景：
挂号风控，挂号的用户特征比较清晰，会有明显的城市、账号的聚集情况。
Mars案例：异常主播分析
前文提到，奇秀黑产的特征之一就是抢红包。红包转化为场内货币后，资金最终消费到了违规主播身上。通过对黑产的行为聚类，并对主播异常收入关联，我们自研了一套主播异常收入分析引擎。上线初期就能准确识别到违规主播收入超过 10 万人民币，效果显著。
（图 5异常主播分析）
1
聚类分析
通过多个不同的维度，做 K-means聚类分析，同时结合已有的黑产用户库做交叉比配。来确定抢红包的黑产用户。
2
关联分析
追踪黑产用户送礼的主播去向、家族去向，若大量礼物送给了同一个主播或同一个家族，则需要进一步关联明确。
3
数据产出
如果主播半个月异常收入占总收入比例超过设定阈值，则输出违规主播收入，运营确认后可以冻结主播收益。
Mars 作为风控接入背后的大数据系统，后续会发挥更大的作用。针对风控的分析也向着算法化、智能化、实时化演进。
5
总结
以上是奇秀技术团队对于直播业务风控的一些探索，奇秀风控系统也从单纯的频次限制向智能化演进。在黑与白的较量中，永远没有终结这个说法。技术团队一时的懈怠，就很有可能让黑产趁虚而入。