大数据编程技术-从理论到实践 课件 第5章 数据采集与预处理

数据采集与预处理《大数据编程技术》第五章授课教师|计算机学院目录CONTENTSPART01数据采集PART02数据预处理PART03本章小结PART01数据采集概述PART02分布式协调服务ZookeeperPART03消息队列KafkaPART04日志采集Flume5.1数据采集(DataCollection)01.用户行为数据(UserBehaviorData)•定义：指用户在使用产品或服务过程中产生的各类交互痕迹与操作记录，是用户与平台接触的“数字足迹”。

•常见类型：页面浏览记录、点击跳转行为、搜索关键词、停留时长、收藏与分享动作、购买/下单路径、设备型号与IP地理位置等。

•价值与挑战：能直观反映用户偏好与体验痛点，是优化产品功能、制定精准营销策略的核心依据；但通常数据量大、格式多样且分散，对采集与处理系统的吞吐量要求较高。02.业务数据(BusinessData)•定义：由企业核心业务系统产生的结构化数据，直接反映企业的运营状态与经营成果。

•常见类型：订单交易数据、客户信息（CRM）、库存与供应链数据、财务报表数据、生产制造流程记录、服务工单数据等。

•价值与挑战：具备极高的商业分析价值，用于监控业务KPI、辅助战略决策与风险控制；通常存储于企业数据库中，需注意数据的准确性、一致性及安全合规性。用户行为数据采集：定义与重要性▍什么是用户行为数据？用户行为数据是指用户在使用移动端APP或桌面端PC与企业客户端应用交互过程中，所产生的各类交互动作与路径数据，本质上是用户留下的“数字足迹”。▍常见的数据类型有哪些？覆盖了用户从“接触”到“转化”的全链路动作，典型的包括：页面浏览(PV/UV)、按钮点击、功能停留时长、内容评论、内容点赞、商品/内容收藏、分享转发以及交易支付等关键行为。▍数据如何存储与生成？这些数据随用户的每一次交互不间断地实时生成，并通常以非结构化的形式存储在服务器的日志文件（LogFiles）中，后续可通过ETL工具进行清洗与结构化处理。▍核心商业价值它是企业数字化运营的基石，能帮助产品团队优化体验、运营团队洞察用户偏好、管理层制定精准业务决策，同时为日活、转化率、留存率等所有业务统计指标提供最底层的数据支撑。5.1数据采集(DataCollection)5.1数据采集(DataCollection)🛡️采集面临的挑战•数据源分散：日志分布在多台服务器上，极易出现数据丢失，采集难度大。•数据质量风险：海量数据可能存在损坏、格式不一致、重复等问题，影响后续分析。•预处理需求高：采集时需兼顾初步清洗与分类，对系统吞吐量有要求。⚙️架构解决方案：Flume+Kafka+Flume1.采集层(Flume)：监控多台服务器的日志目录，支持断点续传，确保数据不丢失。2.缓冲层(Kafka)：作为高吞吐消息中间件，起到削峰填谷作用，解耦上下游系统。3.存储层(Flume+HDFS)：从Kafka实时消费数据，并将清洗后的数据持久化写入HDFS集群。三种主流埋点模式对比01.代码埋点(Code-basedTracking)方式：开发人员在应用代码的关键业务节点手动插入埋点SDK函数，触发数据上报。

优点：对埋点时机和上报内容有极强的精准控制力，灵活性高，能适应复杂的业务逻辑。

缺点：开发和维护的人力投入大，每增加或修改埋点都需重新发版，更新成本高且周期长。02.可视化埋点(VisualTracking)方式：通过可视化的配置工具，在页面上直接选择需要追踪的元素（如按钮、链接）并配置事件，无需编写代码即可完成埋点。

优点：业务人员无需依赖研发即可自主完成埋点，大幅降低沟通成本，埋点效率较高。

缺点：仅支持界面元素的点击、展示等通用行为，难以覆盖复杂的非界面逻辑场景，灵活度受限。03.全埋点/无埋点(Auto-tracking/No-code)方式：在应用初始化时预先嵌入采集SDK，自动捕获并上报用户的所有交互行为，如点击、滑动、页面浏览等，无需手动配置。

优点：一次接入即可获取全量用户行为数据，回溯性强，避免遗漏关键数据，无需频繁变更配置。

缺点：数据采集量巨大，包含大量无效的低价值信息，增加数据存储与清洗的成本。5.1数据采集(DataCollection)公共信息与行为日志分类一个典型的用户行为日志通常由两部分核心信息构成，通过对这两类数据的结构化记录与分析，可还原用户的完整行为路径：▌一、公共信息数据（每条日志的通用基础信息）包含用户身份标识（用户ID）、设备物理信息（机型/系统/分辨率）、用户所处地理位置（城市/经纬度）、流量来源渠道以及当前使用的应用版本等基础维度，用于定位行为主体与环境。▌二、用户行为日志数据（记录具体交互动作）●页面浏览记录：记录用户对页面的访问路径、单次停留时长、进出页面来源与去向等信息，反映用户的浏览偏好。●关键动作记录：精准捕获收藏、评论、加购、下单、分享等核心业务操作，是衡量用户转化的重要依据。●内容曝光记录：记录广告位、推荐商品、活动弹窗等元素在用户端的展示次数与时长，用于评估内容分发效率。●应用启动记录：追踪应用的启动入口（冷启动/热启动）、启动加载耗时等，用于优化产品性能体验。●异常错误记录：记录用户操作过程中遇到的崩溃、接口报错等异常信息，为技术侧修复问题提供数据支撑。5.1数据采集(DataCollection)业务数据采集：为何需要采集？▍什么是业务数据？•定义：企业在处理实际业务过程中产生的数据，例如用户注册、商品购买、订单提交、支付结算等核心记录。•存储方式：通常存储在MySQL、Oracle等关系型数据库中，属于高度结构化数据。▍直接在业务库分析的三大弊端1.设计目标冲突：业务数据库专为在线交易(OLTP)优化，侧重高频读写与事务一致性；而非面向复杂查询与聚合的在线分析(OLAP)。2.严重拖累系统性能：海量数据的复杂统计查询会瞬间占用大量CPU与IO资源，直接导致线上业务系统响应变慢，甚至引发宕机风险。3.数据安全风险：直接开放生产环境数据库权限给分析人员，极易导致敏感的用户隐私、交易数据泄露或误操作。➤结论：业务数据必须经过采集、清洗、整合后，加载到独立的“数据仓库”中进行分析处理。5.1数据采集(DataCollection)业务数据采集策略：全量抽取vs.增量抽取▍全量抽取(FullLoad)📌定义：一次性将数据源中的所有数据完整地抽取出来，覆盖目标端原有数据。🎯适用场景：系统迁移、数据仓库初始化、历史数据归档，或数据量较小、更新频率极低的静态表。🛠️推荐工具：本书采用Sqoop进行关系型数据库与Hadoop生态间的批量全量抽取。▍增量抽取(IncrementalLoad)📌定义：仅捕获并抽取自上次同步以来发生变化的数据（包括新增、修改、删除操作），避免重复处理全量数据。🎯适用场景：高并发、数据频繁更新的核心业务表（如订单、交易、用户行为日志），要求准实时或周期性同步。🛠️推荐方案：使用Maxwell解析MySQLBinlog捕获变更→发送至Kafka做消息缓冲→由Flume消费并写入数仓。5.1数据采集(DataCollection)5.2数据预处理01.预处理的必要性(Necessity)•采集到的原始数据往往存在“脏乱差”问题：如缺失值、重复记录、格式不一致、逻辑错误、噪声数据等。

•若直接使用低质量数据进行分析，将导致“垃圾进，垃圾出”的结果，严重影响模型的准确性和决策的可靠性。02.核心目标(CoreObjectives)•将“脏”数据转化为高质量的“干净”数据，提升数据的可用性和价值。

•统一数据标准，让数据结构、格式和语义满足后续分析或建模的需求，降低算法处理难度。03.常见预处理任务(CommonTasks)•数据清洗：处理缺失值、去除重复项、纠正逻辑错误、平滑噪声数据。

•数据集成与转换：合并多源异构数据，统一数据格式与量纲（如归一化/标准化），进行离散化或特征编码。

•数据归约：在保持数据核心特征的前提下，通过降维、采样等方式减少数据规模，提升处理效率。数据质量的第一道防线▍核心逻辑：GarbageIn,GarbageOut原始业务数据往往存在大量噪声、异构格式、信息缺失或重复冗余等问题。若跳过预处理直接输入模型，不仅会消耗大量计算资源，更会导致分析结果偏差，甚至得出完全错误的结论。▍预处理目标将原始“粗矿”数据转化为结构统一、质量可信、适应计算框架的高价值数据集，最大化挖掘数据潜在价值，确保后续分析与建模的准确性与稳定性。▍四大关键任务●数据清洗：识别并处理缺失值、异常值、重复数据，消除数据中的“噪声”。●数据集成：将分散在多个数据源（如数据库、日志、Excel）中的数据整合到统一的存储或视图中。●数据转换：通过规范化、离散化、特征编码等方式，将数据转化为适合算法模型的格式。●数据规约：在保留核心信息的前提下，通过降维、采样等手段减少数据规模，提升计算效率。5.2数据预处理四类常见脏数据的处理方法数据清洗是数据预处理中最基础且耗时的环节，旨在提升数据质量。我们主要针对以下四类“脏数据”进行针对性处理：●处理缺失值：可根据业务场景选择不同策略，包括直接删除无效记录、使用均值/中位数/众数进行统计填充、利用插值法推算缺失值，或通过机器学习模型预测填充。●处理异常值(离群点)：常用Z-score标准化法判断数值偏离程度，或利用IQR四分位距法定位极端值；也可结合箱线图等可视化手段直观观察并识别异常数据。●处理重复值：通过检查数据记录的完全一致性或关键键（Key）字段，精准识别并删除重复冗余的记录，确保数据唯一性。●处理不一致数据：重点解决数据格式混乱（如多种日期书写格式）和逻辑矛盾问题（如年龄为负数、数值单位不统一），实现数据格式的标准化与逻辑校验。5.2数据预处理数据集成：合并多源异构数据▍什么是数据集成？将来自多个异构数据源（如各类关系型/非关系型数据库、日志文件、第三方API接口等）的数据，经过一系列处理后合并到一个统一的数据存储或视图中，以支持后续的分析与应用。▍集成过程中的主要挑战●模式集成难题：不同数据源的结构（Schema）定义往往存在差异，字段名、数据类型或表结构难以直接对齐。●数据冗余风险：不同数据源可能存储了指向同一业务实体的重复信息，造成存储空间浪费且增加数据管理难度。●数据值冲突：针对同一个现实世界的实体（如同一个用户），不同来源记录的属性值（如电话号码、地址）可能不一致，需要进行判断和统一。▍应对挑战的核心方法●实体识别(EntityIdentification)：通过匹配算法（如基于规则、机器学习），精准识别分散在不同数据源中指向“同一个对象”的多条记录。●冲突检测与解决：建立冲突检测机制发现不一致数据，并制定清洗规则（如依据数据源可信度、数据更新时间等）解决冲突，确保数据一致性。5.2数据预处理五种关键的数据转换方法数据转换是改变数据形态以适配分析模型、提升挖掘效率的关键步骤，主要包含以下核心技术手段：●平滑(Smoothing)：通过算法去除数据中的随机噪声，使得数据变化趋势更加清晰，提高分析结果的准确性。●聚集(Aggregation)：对数据进行汇总或聚合操作，例如按时间周期（天/月/年）或业务维度（区域/类别）计算统计指标，降低数据粒度。●数据泛化(Generalization)：利用概念分层技术，将底层的细节数据抽象为更高层次的概念，如将具体的街道地址泛化为城市或省份，以支持宏观分析。●规范化(Normalization)：将不同量纲、不同取值范围的数据按比例缩放，统一落入特定的区间（如0-1或-1-1），消除特征间的数值差异对算法的影响。●属性构造(AttributeConstruction)：基于现有数据的属性，通过逻辑运算或数学变换创建新的、更具业务解释性或预测能力的特征。5.2数据预处理在保持数据完整性的前提下简化数据🎯核心目的：得到一个比原始数据规模小得多，但仍能产生相同（或几乎相同）分析结果的精简数据集，从而显著提升分析效率。📊维度规约(DimensionalityReduction)：指减少数据集中属性（特征）的数量，降低数据维度。常用方法包括：主成分分析(PCA)、特征选择(FeatureSelection)等。🔢数值规约(NumerosityReduction)：指用更小的数据表示形式来替换原始数据。常用方法包括：直方图、聚类、抽样、参数回归等。💡总结：通过减少“列”或“行”的冗余，在保留核心信息的同时降低计算复杂度。5.2数据预处理5.3数据采集概述核心目标与关键要素▌核心目标从海量异构数据源中，通过标准化的采集手段高效提取有效信息，并进行初步的清洗与转换，最终整合为可支撑上层分析应用的高价值数据集。▌主要数据类型①用户行为日志数据：用户与App、Web端等客户端交互产生的埋点数据，通常以非结构化形式存储在服务器的日志文件中。②企业核心业务数据：在企业ERP、CRM、订单系统等业务流程中产生的结构化数据，主要存储在MySQL、Oracle等关系型数据库中。▌面临的主要挑战●来源多样且异构：数据可能来自日志、数据库、API、IoT设备等多种渠道，格式与标准不统一，整合难度大。●规模呈指数级增长：随着业务扩展，数据量往往呈TB/PB级爆发，对采集系统的吞吐能力提出极高要求。●数据质量参差不齐：原始数据普遍存在高噪声、重复、缺失、格式错误等问题，严重影响后续分析的准确性。5.3用户行为数据采集流程Flume+Kafka+Flume架构解析针对海量的用户行为日志，我们采用Flume→Kafka→Flume→HDFS的经典架构，实现了从数据源到存储层高效、高可靠的数据流转。•采集层Flume：部署于各业务服务器节点，实时监控日志目录，支持断点续传机制，保障源数据不丢失。

•Kafka消息队列：作为高吞吐的缓冲层，有效削峰填谷，解决采集速度与处理速度不匹配的问题，提升系统稳定性。

•消费层Flume：从Kafka集群消费数据，并按业务规则聚合后，最终将日志文件写入HDFS进行分布式持久化存储。5.3数据埋点方式主流数据埋点三种方式对比01.代码埋点(CodeTracking)方式：在应用代码中手动插入埋点SDK函数，触发特定用户行为时执行函数以记录数据。适用场景：业务逻辑复杂，需要对特定事件、特定参数进行精准控制和收集的场景，如付费转化、关键业务操作等。02.可视化埋点(VisualTracking)方式：通过可视化配置平台，在产品界面上直接点击选择需要埋点的UI元素，无需编写代码即可完成埋点规则配置。适用场景：业务运营人员或数据分析师主导的常规点击、浏览类埋点需求，可实现快速上线与灵活变更，降低开发成本。03.全埋点/无埋点(Auto-Tracking)方式：在应用中预先集成全埋点SDK，自动捕获并上报用户的所有点击、页面浏览、滑动等行为数据，无需人工逐个配置。适用场景：需要全面还原用户画像与行为路径，或对未来分析需求不确定、需要留存海量原始行为数据以备灵活查询的场景。5.3用户行为日志内容日志构成的两大维度01.公共信息数据(CommonContext)记录所有日志共通的基础环境与身份信息，为行为数据提供上下文支撑，是每条日志的“标配字段”。包含：用户唯一标识(UserID)、IP地理位置、设备型号/操作系统/屏幕分辨率、流量来源渠道、App版本号/小程序平台信息等。02.用户行为日志数据(BehaviorLogs)记录用户在产品中产生的各类具体交互与状态变化，是还原用户路径、分析产品功能价值的核心依据。包含：页面浏览记录(PV/UV)、关键按钮点击/操作动作、内容/广告曝光记录、应用冷/热启动记录、接口调用错误与崩溃记录等。5.3业务数据采集▌为何需要采集到数据仓库？•性能隔离：将分析查询与业务系统分离，避免复杂的报表计算拖慢核心交易流程。•数据一致性：打破数据孤岛，整合分散在CRM、ERP等不同业务系统中的异构数据。•分析友好：通过数仓建模，构建星型/雪花模型，让数据结构更适合多维分析和即席查询。▌核心采集策略•全量抽取(InitialLoad)：一次性抽取全量历史数据，适用于数仓初始化阶段。常用工具：Sqoop。•增量抽取(IncrementalLoad)：仅同步新增或变化的数据，保障时效性。典型链路：Maxwell(Binlog)→Kafka→Flume→HDFS。5.4分布式协调服务Zookeeper▌核心定位(CorePositioning)Zookeeper是一个高性能、高可用的分布式协调服务，专为大型分布式系统设计。它通过一个简单的树形结构命名空间（Znode），为分布式应用提供统一的服务入口，是构建可靠分布式架构的基础组件。▌关键价值(KeyValue)主要解决分布式环境下的两大核心难题：数据一致性维护与系统高可用性保障。它通过原子广播机制（ZAB协议）确保集群中各节点数据的一致性，同时支持快速的故障检测与主节点自动选举（LeaderElection），保障服务不中断。▌典型应用场景(TypicalScenarios)作为大数据生态圈的“基石”，被广泛集成于各类核心组件中：

•服务注册与发现：Dubbo、Kafka等组件通过它管理服务地址列表。

•分布式锁：HBase、HadoopYARN利用它实现分布式环境下的资源互斥访问。

•配置中心：集中管理分布式系统的关键配置，实现配置的动态同步与更新。定义与核心特性▌什么是Zookeeper？一个为分布式应用提供高效、可靠的协调服务的分布式协调系统，本质上是GoogleChubby的开源实现，常被视为分布式系统的“大脑”。▌六大核心特性●数据一致性：采用ZAB(ZookeeperAtomicBroadcast)协议，严格保证集群中所有节点数据的强一致性。●高可用性：基于主备复制架构，只要集群中半数以上节点存活，服务即可正常对外提供，具备故障自动恢复能力。●高性能：核心数据存储于内存中，并针对读写场景做了大量优化，可支撑高并发的读请求，满足高吞吐需求。●顺序性：为每一次数据更新操作分配一个全局唯一且严格递增的事务ID(zxid)，保证所有事务操作的全局顺序性。●原子性：分布式事务的原子性保障，所有复杂的更新操作要么全部成功并应用到所有节点，要么全部失败，不存在中间状态。●实时性：通过Watcher（事件监听器）机制，客户端能实时感知到数据节点的变化并接收通知，延迟通常在毫秒级。5.4分布式协调服务ZookeeperZookeeper工作原理一、集群角色分工与协作•Leader：集群的核心，处理所有事务性请求，负责发起投票并决定事务的提交，保证数据一致性。•Follower：处理客户端非事务性请求，转发事务请求给Leader，并参与投票过程，是集群高可用的基础。•Observer：仅同步Leader数据，不参与选举和投票，用于扩展读取能力，分担非事务性请求压力。二、数据结构：树形Znode📂层级结构：采用类似文件系统的目录树结构，每个节点被称为“Znode”，路径是其唯一标识（如/app/lock）。🔖节点类型：支持持久节点（重启不丢失）、临时节点（会话断开即删除）、有序节点（自动添加递增序号）等类型，灵活适应不同场景。5.4分布式协调服务ZookeeperZookeeper选举与Watch机制▍选举机制(FastLeaderElection)确保集群在Leader故障后快速选出新Leader，投票需超过集群半数节点同意。●全新集群选举：主要依据服务器ID(SID)，ID数值越大者胜出。●非全新集群选举：优先级：逻辑时钟(Epoch)>事务ID(ZXID)>服务器ID(SID)。▍Watch机制(数据发布/订阅核心)实现分布式系统中数据的发布/订阅，让客户端感知节点数据变化。●核心特点：异步通知、一次性触发、轻量级、先注册再触发。●运行原理：客户端注册Watcher→服务器存储Watcher→节点变化触发事件→服务器异步通知客户端。5.4分布式协调服务Zookeeper5.5消息队列KafkaMessageQueueKafka：大数据的“实时数据总线”•核心定义：由Apache开源的高吞吐量、分布式、基于发布/订阅模式的消息队列系统(MQ)，专为处理流式数据设计。•关键特性：支持百万级每秒的消息吞吐，通过磁盘顺序读写与多副本机制保证数据持久性；采用分区架构实现水平扩展，兼具高并发与高可用性。•核心角色：在大数据生态中承担“中枢神经”的作用，连接业务日志、IoT数据、数据库变更等上游数据源，将数据实时分发给下游的流计算(Flink/Spark)、数仓、监控告警等系统。•典型价值：实现业务系统间的解耦，在秒杀、大促等场景下有效削峰填谷，确保后端服务稳定性；同时支撑实时推荐、实时风控等对时效性要求极高的业务场景。核心概念与价值Kafka是一个基于Zookeeper的开源分布式流处理平台，专为实时数据管道设计，能够实现统一、高通量、低延迟的消息发布与订阅。▌核心作用：解决数据流转的关键痛点●业务解耦：引入异步通信机制，将上下游业务系统分离，提升系统维护性与扩展性。●削峰填谷：充当分布式缓冲层，平滑突发的流量洪峰，保护后端服务稳定性。●数据持久化：将消息可靠持久化到磁盘，配合多副本机制，确保数据传输过程中“零丢失”。▌主要特点：构建高性能流处理基石✅高吞吐量：单机可轻松支撑每秒百万级的消息处理能力。✅低延迟：端到端延迟可控制在毫秒级，满足实时计算需求。✅分布式架构：天然支持水平扩展，适应业务规模增长。✅高可靠性：多副本冗余存储，保障服务高可用。5.5消息队列Kafka核心概念解析●Producer(生产者)：向Kafka集群发布消息的客户端应用程序，负责消息的生产和发送。●Consumer(消费者)：从Kafka集群订阅并拉取消息进行处理的客户端，是消息的最终使用者。●Broker：Kafka集群中的独立服务器节点，负责存储消息并处理客户端的读写请求。●Topic：消息的逻辑分类容器，生产者将消息发送到特定Topic，消费者订阅Topic消费消息。●Partition：Topic的最小存储与并行处理单元，一个Topic可切分为多个Partition，实现负载均衡。●Replication(副本)：Partition的冗余备份机制，用于在节点故障时保障数据不丢失和服务的高可用性。●Offset(偏移量)：消息在Partition中的唯一递增序号，消费者通过记录Offset来追踪自己的消费进度。●ConsumerGroup(消费者组)：一组消费者的逻辑集合，组内消费者共同消费一个Topic，保证同一条消息只被组内一个消费者处理。5.5消息队列KafkaKafka常用集群命令行操作Kafka提供了丰富的Shell脚本工具来管理集群和数据，以下是最常用的操作命令：●创建Topic：kafka-topics.sh--create--topicmy_topic--partitions3--replication-factor2（指定分区数与副本因子，副本因子不能超过Broker数量）●查看Topic列表：kafka-topics.sh--list（列出当前集群中所有已创建的Topic）●启动命令行生产者：kafka-console-producer.sh--topicmy_topic（进入交互模式，直接输入消息内容并回车发送）●启动命令行消费者：kafka-console-consumer.sh--from-beginning--topicmy_topic（--from-beginning表示从头开始消费，否则只消费启动后的新消息）●删除Topic：kafka-topics.sh--delete--topicmy_topic（删除指定Topic及其中的所有数据，生产环境操作需谨慎）5.5消息队列Kafka5.6日志采集Flume▌核心定位ApacheFlume是一个分布式、可靠且高可用的海量日志聚合、采集与传输系统，专为大数据场景下的流式数据接入设计，是构建大数据平台“数据管道”的关键组件。▌核心架构与特点1.灵活的组件化模型：基于“Source（数据源采集）→Channel（数据缓冲通道）→Sink（数据落地/转发）”的三层组件模型，支持灵活组合与扩展，适配不同业务场景。2.高可靠性与容错：Channel支持内存、文件或Kafka等持久化方式，确保节点故障时数据不丢失；支持水平扩展以应对海量数据吞吐。3.广泛的生态适配：可对接多种数据源（如服务器日志文件、Kafka、RPC接口等），并将数据发送至HDFS、HBase、Elasticsearch、Kafka等主流大数据存储与分析平台。▌典型应用场景适用于海量业务日志（如电商、社交、游戏平台）的实时采集与汇聚，为离线数仓建设、实时计算分析（如Flink流处理）提供稳定、高效的基础数据支撑。5.6日志采集Flume什么是Flume？Flume是一个高可用、高可靠、分布式的海量日志采集、聚合和传输系统，能够高效地将不同来源的海量数据传输到一个集中式数据存储系统中。核心架构与数据载体•Agent(JVM进程)：包含Source(采集数据)、Channel(缓冲队列，保证可靠性)、Sink(传输数据到目的地)三大核心组件。

•Event：数据在Flume内部传输的基本单元，由Headers(K-V属性)和Body(二进制数据)组成。五种典型拓扑结构Flume的灵活性体现在其支持多种Agent组合方式，以满足不同的数据采集与传输需求，常见的拓扑结构主要有以下五种：1.简单结构：由单个Agent