全自动文章采集网源码2020(建设实时的大数据收集体系(2013-2014)(组图))

　　全自动文章采集网源码2020(建设实时的大数据收集体系(2013-2014)(组图))

　　作者魏晨是爱奇艺云平台大数据采集业务负责人。2014年加入爱奇艺云平台，具有一定的大数据生产/采集/传输/分析经验。

　　大数据是近年来互联网行业最热门、使用频率最高的技术术语。它的应用和影响甚至已经远远超出互联网行业，渗透到社会和日常生活的各个领域。海量数据，尤其是用户数据，本身已经成为企业和社会关注的重要战略资源，成为大家争夺的焦点。就像农业时代的土地和工业时代的能源一样，数据是未来互联网人工智能时代最重要的基础生产资料。

　　那么，这些海量数据是从哪里来的呢？

　　从内容上看，互联网企业的大数据主要来自海量用户行为和程序行为所产生的记录。通过构建强大的数据采集系统，企业可以实时、高效地对所有用户行为/服务器程序行为进行采集、汇总、清理、过滤，供后续数据分析和挖掘使用。

　　构建实时大数据采集系统对于一些大型用户，尤其是用户长期使用产品的大型互联网公司来说，是一个非常大的技术挑战。爱奇艺就是一个典型的例子。目前，爱奇艺的用户和机器在峰值时每秒产生超过1000万行日志，每天产生的总日志数据超过3000亿行。这个数据量表的概念是什么？如果日志以 5 号尺寸逐行打印，则纸的高度足以每小时绕地球一圈。

　　

　　爱奇艺的实时大数据采集系统就是为应对这种海量数据采集场景而设计的。提供千万级QPS级实时采集能力，采集爱奇艺所有用户行为日志。和后台服务器程序日志，为爱奇艺的各种数据产品提供最重要的数据源支持。

　　七七千里，非一日之功。爱奇艺的实时大数据采集系统也经历了长期的发展和迭代。

　　第一代数据采集系统（2013-2014)

　　初始数据采集系统主要围绕早期简单大数据场景的需求设计，如用户数据统计、产品运营报表分析等。

　　对于用户数据的统计需求，第一步是通过用户终端中嵌入代码的方式，通过HTTP请求将用户的使用行为发布到后台Nginx服务器，并让Nginx服务器记录用户的使用详情通过打印日志的产品。信息。这些 Nginx 日志会定期汇总、整理并上传到 HDFS，用于后续的大数据分析和报表计算。

　　

　　图 1：第一代用户数据采集 架构

　　第一代数据采集解决方案的主要缺点是数据从生产到消费的高延迟。用户在客户端的行为触发HTTP投递后，上传到HDFS大约需要10到15分钟。在这样的数据采集方案下，只能满足实时性要求不高的业务方的需求，比如统计昨天的用户数据、绘制运营报表等。

　　对于一些有实时性要求的大数据场景，比如可以根据用户的历史行为，对用户进行画像，做出精准的内容和广告推荐。在这种旧的采集机制下，推荐内容是基于对用户前天行为的分析，用户的实时操作和行为无法体现在他的产品体验中。从这个角度来看，正是缺乏实时数据采集限制了推荐产品从源头上所能达到的效果。

　　第二代数据采集系统（2015-2016)

　　随着公司业务的不断发展，对数据采集系统提出了新的要求。首先是需要一个更快的实时数据采集解决方案，可以做到秒级延迟。另外，在数据源方面，除了采集用户数据外，还需要增加对机器日志分析的支持采集。后台机器的程序日志数据可以帮助各个技术团队完成技术故障报警、故障诊断排查、性能指标统计等需求。经过开发迭代，第二代实时数据采集系统如下：

　　

　　图2：用户数据采集+程序日志采集

　　引入实时数据采集后，业务方在使用数据的形式上有了灵活的选择。比如在各种报表监控和统计场景中，可以通过实时数据统计，绘制实时报表，观察实时趋势；次日，即可离线计算HDFS数据，获得准确结果。实时数据和离线数据同时使用，离线数据的计算结果作为实时数据统计结果的修正和补充（业内俗称大数据处理的Lambda架构）。

　　更重要的是，实时数据源的提供为基于用户大数据分析的产品设计带来了新的思路。例如，可以利用实时的采集数据计算内容和广告的推荐，触发算法推荐，让用户上一时刻的操作行为快速反映到下一时刻的产品体验上。再比如安全风控环节。根据实时用户行为日志，可以立即*敏*感*词*一些正在进行安全威胁操作的账号和IP，并快速拦截。

　　在第二代数据采集系统中，我们引入了实时数据采集器Apache Flume和分布式消息队列Kafka。社区开源的 Apache Flume 支持通过自定义脚本监控日志文件，并将监控日志文件实时写入 Kafka 消息队列。下面是一个基于 Flume 的*敏*感*词*文件的例子。

　　

　　图3：基于Flume-Kafka的实时数据采集架构

　　引入开源Flume和Kafka后，数据采集系统在一定程度上满足了部分业务的实时数据需求。但随着data采集业务规模的不断扩大，新的问题不断暴露出来，主要表现在以下几个方面：

　　1.不同的业务日志采集需要定义不同的采集脚本和Flume采集配置。当业务发展到一定规模时，维护和管理成本是巨大的。

　　2.对实时采集配置的任何修改都必须伴随着大型在线集群Flume重启等运维操作。

　　3.Apache Flume 自身的功能限制无法满足灵活的业务需求，比如按比例随机采样、数据处理、数据格式转换等。

　　第三代数据采集系统（2016-2017)

　　2016年以来，随着公司业务的不断规模化和多元化，产生了更多新的大数据业务需求，也带来了更高的运维和管理负担。因此，数据采集 的自动化、规模化和可管理性变得更加重要。同时，不断增长的大数据业务场景对数据质量提出了更高的要求。业务组要使用的数据是经过清洗、处理和筛选，直接符合业务场景的数据，而不是采集的原创空白数据。此外，业务对数据源的需求也更加广泛​​，需要支持数据库产品中的binlog日志采集和类Docker弹性容器中的日志数据采集。

　　在这些新需求的推动下，爱奇艺的大数据采集系统也在进一步迭代：

　　

　　图4：新版大数据实时采集系统

　　新的数据采集系统有三个主要变化：

　　1.data采集的流程自动化程度高，大大降低了人工运维成本。

　　2.数据采集的目标形式（离线HDFS和实时Kafka）可以独立于数据源。对于数据的消费者来说，数据的来源是黑匣子。

　　3.提供原创采集 数据和经过处理、清理和过滤的数据。

　　为了实现这些变化，技术上有两大突破，下面将分别介绍。

　　1.自研实时数据采集客户端Venus-Agent

　　2.通过Apache Flink实现数据的实时处理层

　　技术突破1

　　数据采集客户端 Venus-Agent

　　在设计第三代数据采集系统的过程中，我们首先考虑的是数据采集工作的自动化。大量的开源软件，包括Apache Flume，都是通过读取本地配置文件来启动的。我们最初尝试通过改造 Flume 源代码来集中管理所有 采集 客户端的配置，让管理员可以有一个统一的入口来管理所有数据源的 采集 配置。

　　在沿着这个思路改造 Flume 源码的过程中，我们发现了 Apache Flume 本身的一些设计缺陷和健壮性问题。另外，由于开源 Flume 版本变化较慢，在一些复杂的业务场景中（比如类似 Docker 的弹性资源池），Flume 甚至无法满足基础数据 采集 的需求。我们最终决定只模仿Apache Flume的功能框架，重新开发一套新的数据实时采集客户端Venus-Agent。

　　重新设计的数据采集客户端Venus-Agent相比传统的Apache Flume采集有几大变化：

　　变更一：不再使用tail命令或脚本来监控固定文件，而是直接通过INode号锁定需要采集的文件。在选择采集文件时，通过定期检查采集配置和检测文件目录，实时更新采集文件列表。

　　基于这种变化，我们在各种极端情况下实现了 data采集。尤其是像Docker这样的弹性容器环境，当用户申请的容器数量增加或减少时，容器上的日志采集也可以同步伸缩。弹性资源池的用户只需要关心自己应用容器的扩容和缩容，不需要关心扩容后新增容器中的日志采集问题。下图是类Docker弹性容器资源池场景下，Venus-Agent支持log采集随着容器扩容或缩容同步变化。

　　

　　图 5：弹性容器资源池中的日志采集

　　第二大变化是：

　　变化2：实时记录每个文件采集的进度Offset，即使出现网络抖动/后端Kafka故障/采集进程挂起等异常情况，异常恢复后，Venus-Agent仍然可以将之前的Offset记录位置继续到采集，以防止消息丢失。

　　通过添加这个特性，我们大大提高了数据的鲁棒性采集。使 采集 客户端能够抵抗一定程度的边缘情况风险。如果发生小风险事件，采集 会中断，原创 采集 文件上的偏移量会停止移动。当故障异常恢复时，Venus-Agent可以自动沿着之前的Offset记录位置继续向下采集，保证数据不丢失。

　　

　　图 6：通过 Offset 提高 data采集 的健壮性

　　第三个也是最关键的变化：

　　变化3：所有客户端数据采集的配置由远程统一平台保存管理。采集客户端通过定时心跳的方式从后端拉取最新配置，实时生效。

　　

　　图 7：客户端从后端系统拉取 采集 配置

　　在新版本的Venus-Agent采集客户端中，我们实现了采集配置的远程集中管理，为我们在数据的运维管理上带来了很大的好处采集@ > 业务。方便的。比如修改数据的采集配置、改变数据的采集目标等一系列常用操作，都可以由用户在后台的网页上进行操作系统。当页面修改采集配置时，经过一个心跳间隔后，部署在日志服务器上的采集客户端会通过心跳拉取最新的数据采集配置，它会占用立即生效。新的 采集

　　如下图所示，在新Venus-Agent上线后的第二季度，单季度新增采集机器数超过了Apache Flume部署机器总数采集在过去的一年里。

　　

　　图8：Venus-Agnet自动化管理提升业务推广效率

　　技术突破2

　　实时数据筛选处理模块

　　随着实时业务的不断发展，越来越多的团队提出了数据处理和清洗的需求。以用户行为实时数据采集为例，在旧的实践中，往往会直接向业务部门提供一个庞大而全面的Kafka数据流，包括所有用户行为数据。业务部门自行进行过滤和清洗，过滤掉一小部分自身业务所需的数据。这种粗放的数据供应方式，使得各条业务线在实时数据分析过程中反复消耗大量计算资源。最初为了解决这个问题，提出了两个临时解决方案。

　　临时解决方案1：

　　按日志内容中的特定字段进行拆分和过滤

　　解析采集接收到的数据流后，根据特定字段的值进行区分，将数据发送到多个不同的Kafka topic（这个方案相当于Apache Flume中的Selector机制）。该方案可以用下图简单描述。

　　

　　图 9：根据指定字段的值拆分和过滤数据流

　　该方案的主要问题是，面对日益复杂的互联网数据分析需求，经常会出现多个团队所需的数据在维度上相交的情况，需要多个团队复用。例如：

　　1.某商家需要爱奇艺苹果iPhone用户播放行为数据

　　2.B服务需要爱奇艺用户在北京联通网络环境下的游戏行为数据

　　3.C业务需要用户在爱奇艺*敏*感*词*频道的播放行为数据

　　三个团队的数据需求重叠。对于爱奇艺用户行为的原创采集原创数据流，要产生和处理上述三个业务所需的指定数据流，显然直接按字段拆分的方法是无法实现的。

　　旧方案2：

　　重复采集+ 分别过滤和处理

　　为了解决上述方案遇到的维度冲突问题，我们不得不在部分商家的采集链接中多次重复采集原创数据来处理上述维度冲突问题。在最初的 Apache Flume 时代，这些重复的 采集 + 重复过滤甚至是用脚本完成的。下图是一个示例：

　　

　　图 10：在 Apache Flume 上

　　传递脚本 采集 并过滤数据示例

　　从2015年到2016年，我们在生产环境中大量使用了这个方案，很快就遇到了一个瓶颈，就是这些用于过滤和过滤数据的grep/awk脚本消耗了打印日志的在线机器上的数据。CPU 资源。当每台机器上运行几十个这样的 grep/awk 脚本时，CPU 达到了瓶颈，以后不能再添加脚本了。这个瓶颈限制了我们实时数据生产规模的扩大，拖累了各个团队实时计算业务的发展速度。我们决心将数据的处理、清洗、过滤与采集端分离，使用专用的数据处理层进行处理，并保证数据处理层的吞吐能力可横向扩展。

　　当前实时数据采集+处理计划结构如下：

　　1.设计两层Kafka结构，第一层Kafka接收采集端上传的原创全量数据。

　　2.使用Flink实时计算集群进行数据处理和计算

　　3.Flink 层计算逻辑全部存储在后端管理系统中。在 Flink 实时计算任务中，数据筛选/处理/过滤的逻辑是通过定时心跳从后端管理系统获取的。在 Flink 任务中实时生效。

　　

　　在这个方案中，无论各个团队需要的数据处理逻辑多么复杂多样，数据筛选的维度是否有冲突，都可以在 Flink 实时计算层进行处理。同时，由于 Flink 的计算处理逻辑全部从后台系统拉取，数据处理的逻辑变得非常容易管理，管理员可以在后台系统轻松查看所有实时数据处理逻辑；面对业务需求的变化，只有实时计算集群上的 Flink 任务才能自动获取新的数据处理逻辑并实时生效。

　　4.结束

　　爱奇艺大数据采集系统，从一个简单的统计场景开始，不断向实时、*敏*感*词*、自动化系统转型，发展成为支持千万级QPS峰值的系统，日数据吞吐量超过1000万。3000亿条海量数据实时采集系统。随着未来大数据产品的不断多样化，以及各种大数据应用和人工智能战略的不断推进，新的数据需求也将推动这一架构体系的不断优化和调整。

　　在未来的互联网时代，数据量和数据质量将直接影响各种上层商业智能分析、算法参数调优、AI机器学习等数据产品的结果。打造快速、高效、稳定、可靠的数据采集系统，是公司未来大数据和人工智能战略发展最重要的基础技术保障。