尧图网站建设 
简介这份PDF文档面向HPC与数据中心网络运维工程师、架构师及网络技术学习者聚焦如何借助Network Telemetry打破传统监控的“网络黑盒”。内容围绕INT带内遥测与gRPC主动推送两大技术路线剖析TCP Incast微突发、交换机缓存不足丢包、端到端时延定位等典型运维难题并给出整网流量可视化的整体解决思路。资源包共1个PDF文件约603KB篇幅精炼适合作为技术方案速查与原理梳理的参考材料。目前已有320人学习下载。读者可从中系统理解Telemetry相较SNMP、NetFlow、sFlow在时效性与数据规范性上的差异掌握gRPC上报Buffer Usage、CPU、Memory的交互机制以及INT在报文路径中逐跳插入MetaData、实现秒级故障定位的完整流程为精细化网络运维与持续优化提供可落地的技术支撑。1. 网络遥测到底解决什么问题从 SNMP 轮询到毫秒级流采样传统网络运维靠 SNMP 轮询和 NetFlow 采样轮询周期动辄 5 分钟采样比常见 1:1000。链路真出微突发时这些手段基本是黑匣子——你知道带宽被打满了但不知道是哪条流、哪个应用、哪个 TCP 会话干的。网络遥测Network Telemetry要解决的就是这个粒度问题把设备内部的转发状态、队列深度、时延分布以秒级甚至亚秒级精度推送到采集端而不是等运维去“问”。这套东西适合谁一是手里有可编程交换机或支持 gRPC 的园区/数据中心设备、想把故障定位从“猜”变成“查”的运维二是做网络可观测性平台、需要把 INT 或 gRPC 遥测数据接进现有监控栈的工程师。它不要求你重写整个网络但要求你接受一个前提遥测是推模式采集端得先准备好接收和存储。2. 遥测数据怎么从设备里出来INT、gRPC 与推送模型的选型逻辑2.1 带内遥测 INT 与带外 gRPC 的分工网络遥测落地时第一个要做的选型不是“用哪个工具”而是“数据从哪条路径出来”。常见做法分两条路带内遥测INTIn-band Network Telemetry和带外遥测gRPC Telemetry / gNMI。INT 的思路是让业务报文自己携带转发路径上的元数据。报文经过每台可编程交换机时交换机把入端口、出端口、队列深度、时间戳写进报文头部的 INT 元数据栈最后一跳或接收端把元数据剥离并上报。它的优势是测量对象就是真实业务流能抓到微突发和逐跳时延代价是需要可编程数据面P4 或厂商等价能力且元数据会占用报文开销。gRPC 遥测走的是带外通道。设备按周期或事件触发把接口计数、队列统计、流表状态通过 gRPC 推给采集器。它不依赖可编程数据面主流厂商的中高端设备基本都支持落地门槛低。缺点是它测的是设备视角的聚合状态不是逐包路径微突发场景下不如 INT 直接。我一般会这样分工需要逐跳定位和微突发分析时上 INT需要设备级健康度、接口趋势和告警联动时用 gRPC 遥测。两者不互斥采集端统一收就行。2.2 用 gNMI Subscribe 拉通第一条遥测流下面这段是 gNMI Subscribe 的最小可用示例用 Python 的 grpcio 直接订阅接口计数器。实际项目里你可能会用 pygnmi 或厂商 SDK但先手写一次能帮你理解订阅模式。import grpc import gnmi_pb2 import gnmi_pb2_grpc # 设备 gRPC 端口常见 57400 或 9339以设备实际配置为准 TARGET 10.0.0.1:57400 USERNAME telemetry PASSWORD telemetry def build_subscribe_request(): # 订阅路径接口计数器不同厂商 YANG 模型路径不同 path gnmi_pb2.Path( elem[gnmi_pb2.PathElem(nameinterfaces), gnmi_pb2.PathElem(nameinterface), gnmi_pb2.PathElem(namestate), gnmi_pb2.PathElem(namecounters)] ) subscription gnmi_pb2.Subscription( pathpath, modegnmi_pb2.SubscriptionMode.SAMPLE, sample_interval1000000000 # 1 秒单位纳秒 ) subscribe_list gnmi_pb2.SubscriptionList( subscription[subscription], modegnmi_pb2.SubscriptionList.Mode.STREAM, encodinggnmi_pb2.Encoding.JSON ) return gnmi_pb2.SubscribeRequest(subscribesubscribe_list) def main(): # 生产环境应使用 TLS 证书这里用 insecure 仅用于内网验证 channel grpc.insecure_channel(TARGET) stub gnmi_pb2_grpc.gNMIStub(channel) metadata [(username, USERNAME), (password, PASSWORD)] responses stub.Subscribe(build_subscribe_request(), metadatametadata) for resp in responses: # resp.update 里是本次采样值resp.sync_response 表示订阅已同步 if resp.HasField(update): print(resp.update) if __name__ __main__: main()逻辑说明SubscriptionMode.SAMPLE表示按固定周期采样适合计数器类数据如果要做事件触发改成ON_CHANGE。sample_interval设 1 秒是折中值设到 100 毫秒以下要先确认设备 CPU 和采集端写入能力。Encoding.JSON便于调试生产环境可换PROTO降低带宽。参数说明TARGET的端口不是统一的华为、思科、Arista 各有默认值必须以设备grpc配置为准。metadata里的认证方式也因厂商而异有的用 username/password有的用 token。第一次跑不通先确认设备侧 gRPC 服务已 enable再用grpcurl做连通性验证。2.3 采集端要准备什么时序库与流式管道遥测数据推过来之后采集端不能只打印。常见做法是 gRPC 采集器 → 消息队列 → 时序数据库。消息队列用 Kafka 或 NATS时序库用 Prometheus远程写、VictoriaMetrics 或 ClickHouse。选型看数据形态纯计数器走 Prometheus 生态最顺带 INT 元数据的逐跳记录更适合 ClickHouse因为要按流维度做聚合查询。这里有个容易忽略的点遥测数据的标签基数。接口计数器如果按interface queue flow打标签基数会爆炸。我一般会把高基数维度放到日志或 ClickHouse 表里Prometheus 只保留设备、接口、方向三个标签。3. 把 INT 元数据接进分析管道从 P4 解析到流级聚合3.1 INT 元数据栈的字段与解析INT 元数据通常包含交换机 ID、入端口、出端口、队列 ID、队列深度、链路时延、时间戳。不同实现P4 INT、厂商私有 INT字段顺序和位宽不同解析前必须拿到对应的头格式定义。下面是一个简化的 INT 元数据解析示例假设每跳 12 字节switch_id(4) ingress_port(2) egress_port(2) queue_depth(2) timestamp(2)。import struct # 每跳 12 字节按大端解析 HOP_FORMAT !IHHHH HOP_SIZE struct.calcsize(HOP_FORMAT) def parse_int_metadata(raw_bytes): hops [] offset 0 while offset HOP_SIZE len(raw_bytes): switch_id, in_port, out_port, queue_depth, ts struct.unpack( HOP_FORMAT, raw_bytes[offset:offset HOP_SIZE] ) hops.append({ switch_id: switch_id, in_port: in_port, out_port: out_port, queue_depth: queue_depth, timestamp: ts }) offset HOP_SIZE return hops # 示例两跳元数据 raw bytes.fromhex(000000010001000200030004000000020005000600070008) for hop in parse_int_metadata(raw): print(hop)逻辑说明!IHHHH中!表示网络字节序I是 4 字节无符号整数H是 2 字节。实际 INT 头可能还有hop_count和instruction_mask需要按你的 P4 程序或厂商文档调整。解析出来的queue_depth是瞬时值要结合时间戳算队列变化率才有意义。参数说明HOP_SIZE必须和头格式严格一致差一个字节后面全错位。timestamp如果是设备本地时钟跨设备比较前要做时钟同步否则时延计算会出负值。3.2 流级聚合把逐跳数据变成可查询的视图逐跳元数据本身很碎运维要看的是“哪条流在哪个队列上排队”。常见做法是在采集端按五元组聚合计算每条流的路径、最大队列深度、逐跳时延。-- ClickHouse 表结构存储 INT 逐跳记录 CREATE TABLE int_hops ( flow_id String, src_ip String, dst_ip String, src_port UInt16, dst_port UInt16, switch_id UInt32, in_port UInt16, out_port UInt16, queue_depth UInt16, ts DateTime64(6) ) ENGINE MergeTree() ORDER BY (flow_id, ts); -- 查询每条流的最大队列深度和路径跳数 SELECT flow_id, max(queue_depth) AS max_queue, count(DISTINCT switch_id) AS hop_count FROM int_hops WHERE ts now() - INTERVAL 5 MINUTE GROUP BY flow_id ORDER BY max_queue DESC LIMIT 20;逻辑说明ORDER BY (flow_id, ts)让同一流的记录物理相邻查询快。max_queue能直接暴露微突发——如果某条流的队列深度在 5 分钟内冲到很高而平均带宽不高基本就是微突发。参数说明ts用DateTime64(6)保留微秒INT 时间戳精度通常够用。flow_id建议用五元组哈希避免字符串过长。如果数据量很大按天分区。3.3 采集频率与数据量的平衡INT 逐包上报数据量极大。全量开启在 10G 链路上可能直接打爆采集端。常见做法是采样按 1:100 或 1:1000 采样 INT或者只对特定 ACL 匹配的流开启 INT。gRPC 遥测则相反可以全量开因为它是聚合值。我一般会先开 gRPC 遥测做基线发现某条链路或某个应用异常后再对该流开启 INT 做精细定位。这样既控制数据量又保留定位能力。4. 避坑与排查遥测落地时最容易翻车的五个点4.1 订阅建了但收不到数据现象gNMI Subscribe 返回成功但一直没有 update。原因通常是路径写错或设备侧没有对应数据。不同厂商 YANG 模型路径差异很大interfaces/interface/state/counters在有的设备上是interfaces/interface/statistics。解决先用gnmi_capabilities查设备支持的模型再用gnmi_get手动读一次路径确认有数据后再订阅。4.2 INT 元数据解析错位现象解析出来的 switch_id 是天文数字端口号也对不上。原因是头格式假设错了比如实际有 4 字节的instruction_mask而你没跳过。解决抓一个真实 INT 报文用 Wireshark 的 INT 解析器对照字段偏移或者直接看 P4 程序里的int_header定义。别靠猜。4.3 采集端磁盘被写满现象遥测跑了一周时序库磁盘告警。原因是高基数标签或未做降采样。解决Prometheus 侧配置metric_relabel_configs丢掉不需要的标签ClickHouse 侧建 TTL 或物化视图做分钟级降采样。INT 逐跳数据保留 24 小时原始、7 天聚合通常够用。4.4 时间戳不同步导致时延为负现象逐跳时延算出来是负数。原因是设备时钟没同步或者 INT 时间戳单位不统一有的用纳秒有的用微秒。解决全网开 NTP 或 PTP采集端解析时统一转成微秒。如果设备不支持高精度时钟INT 时延只能看相对趋势不能看绝对值。4.5 gRPC 连接被设备限速或断开现象订阅跑一段时间后断开重连也失败。原因是设备对 gRPC 会话数或 CPU 有保护采样间隔太短会触发限速。解决把sample_interval从 100 毫秒放宽到 1 秒减少订阅路径数量或者改用ON_CHANGE模式只推变化。设备侧也要确认 gRPC 的max-sessions配置。5. 用遥测数据做故障定位一个微突发的排查习惯微突发是遥测最能体现价值的场景。传统监控看到的是 5 分钟平均带宽 40%但业务已经卡了。用遥测你能看到 100 毫秒内队列深度冲到 90%。我的习惯是三步第一步gRPC 遥测发现某接口out_queue_depth在特定时间点有尖峰第二步对该接口开启 INT 采样按五元组聚合找出贡献最大的流第三步用 INT 逐跳数据看这条流在哪个交换机、哪个出端口开始排队定位到具体设备。验证方法在实验环境用tc或pktgen构造微突发对比遥测数据和实际丢包。如果遥测显示的队列深度峰值和tc统计对不上先查采样率再查时间戳对齐。一个具体技巧INT 元数据里的queue_depth是瞬时值单看一个点没意义。我一般会在采集端做 10 毫秒窗口的滑动平均再取窗口内最大值。这样既能过滤毛刺又不会漏掉真实微突发。最后说个血泪教训遥测不是开得越多越好。我早期在一个园区网全量开 INT结果采集端 CPU 跑满反而丢了关键告警。后来改成按需开启、分层采集才稳定下来。先想清楚你要回答什么问题再决定采什么数据。希望帮到你。本文还有配套的精品资源点击获取 网络遥测实战：从SNMP轮询到INT与gRPC毫秒级流采样
简介这份PDF文档面向HPC与数据中心网络运维工程师、架构师及网络技术学习者聚焦如何借助Network Telemetry打破传统监控的“网络黑盒”。内容围绕INT带内遥测与gRPC主动推送两大技术路线剖析TCP Incast微突发、交换机缓存不足丢包、端到端时延定位等典型运维难题并给出整网流量可视化的整体解决思路。资源包共1个PDF文件约603KB篇幅精炼适合作为技术方案速查与原理梳理的参考材料。目前已有320人学习下载。读者可从中系统理解Telemetry相较SNMP、NetFlow、sFlow在时效性与数据规范性上的差异掌握gRPC上报Buffer Usage、CPU、Memory的交互机制以及INT在报文路径中逐跳插入MetaData、实现秒级故障定位的完整流程为精细化网络运维与持续优化提供可落地的技术支撑。1. 网络遥测到底解决什么问题从 SNMP 轮询到毫秒级流采样传统网络运维靠 SNMP 轮询和 NetFlow 采样轮询周期动辄 5 分钟采样比常见 1:1000。链路真出微突发时这些手段基本是黑匣子——你知道带宽被打满了但不知道是哪条流、哪个应用、哪个 TCP 会话干的。网络遥测Network Telemetry要解决的就是这个粒度问题把设备内部的转发状态、队列深度、时延分布以秒级甚至亚秒级精度推送到采集端而不是等运维去“问”。这套东西适合谁一是手里有可编程交换机或支持 gRPC 的园区/数据中心设备、想把故障定位从“猜”变成“查”的运维二是做网络可观测性平台、需要把 INT 或 gRPC 遥测数据接进现有监控栈的工程师。它不要求你重写整个网络但要求你接受一个前提遥测是推模式采集端得先准备好接收和存储。2. 遥测数据怎么从设备里出来INT、gRPC 与推送模型的选型逻辑2.1 带内遥测 INT 与带外 gRPC 的分工网络遥测落地时第一个要做的选型不是“用哪个工具”而是“数据从哪条路径出来”。常见做法分两条路带内遥测INTIn-band Network Telemetry和带外遥测gRPC Telemetry / gNMI。INT 的思路是让业务报文自己携带转发路径上的元数据。报文经过每台可编程交换机时交换机把入端口、出端口、队列深度、时间戳写进报文头部的 INT 元数据栈最后一跳或接收端把元数据剥离并上报。它的优势是测量对象就是真实业务流能抓到微突发和逐跳时延代价是需要可编程数据面P4 或厂商等价能力且元数据会占用报文开销。gRPC 遥测走的是带外通道。设备按周期或事件触发把接口计数、队列统计、流表状态通过 gRPC 推给采集器。它不依赖可编程数据面主流厂商的中高端设备基本都支持落地门槛低。缺点是它测的是设备视角的聚合状态不是逐包路径微突发场景下不如 INT 直接。我一般会这样分工需要逐跳定位和微突发分析时上 INT需要设备级健康度、接口趋势和告警联动时用 gRPC 遥测。两者不互斥采集端统一收就行。2.2 用 gNMI Subscribe 拉通第一条遥测流下面这段是 gNMI Subscribe 的最小可用示例用 Python 的 grpcio 直接订阅接口计数器。实际项目里你可能会用 pygnmi 或厂商 SDK但先手写一次能帮你理解订阅模式。import grpc import gnmi_pb2 import gnmi_pb2_grpc # 设备 gRPC 端口常见 57400 或 9339以设备实际配置为准 TARGET 10.0.0.1:57400 USERNAME telemetry PASSWORD telemetry def build_subscribe_request(): # 订阅路径接口计数器不同厂商 YANG 模型路径不同 path gnmi_pb2.Path( elem[gnmi_pb2.PathElem(nameinterfaces), gnmi_pb2.PathElem(nameinterface), gnmi_pb2.PathElem(namestate), gnmi_pb2.PathElem(namecounters)] ) subscription gnmi_pb2.Subscription( pathpath, modegnmi_pb2.SubscriptionMode.SAMPLE, sample_interval1000000000 # 1 秒单位纳秒 ) subscribe_list gnmi_pb2.SubscriptionList( subscription[subscription], modegnmi_pb2.SubscriptionList.Mode.STREAM, encodinggnmi_pb2.Encoding.JSON ) return gnmi_pb2.SubscribeRequest(subscribesubscribe_list) def main(): # 生产环境应使用 TLS 证书这里用 insecure 仅用于内网验证 channel grpc.insecure_channel(TARGET) stub gnmi_pb2_grpc.gNMIStub(channel) metadata [(username, USERNAME), (password, PASSWORD)] responses stub.Subscribe(build_subscribe_request(), metadatametadata) for resp in responses: # resp.update 里是本次采样值resp.sync_response 表示订阅已同步 if resp.HasField(update): print(resp.update) if __name__ __main__: main()逻辑说明SubscriptionMode.SAMPLE表示按固定周期采样适合计数器类数据如果要做事件触发改成ON_CHANGE。sample_interval设 1 秒是折中值设到 100 毫秒以下要先确认设备 CPU 和采集端写入能力。Encoding.JSON便于调试生产环境可换PROTO降低带宽。参数说明TARGET的端口不是统一的华为、思科、Arista 各有默认值必须以设备grpc配置为准。metadata里的认证方式也因厂商而异有的用 username/password有的用 token。第一次跑不通先确认设备侧 gRPC 服务已 enable再用grpcurl做连通性验证。2.3 采集端要准备什么时序库与流式管道遥测数据推过来之后采集端不能只打印。常见做法是 gRPC 采集器 → 消息队列 → 时序数据库。消息队列用 Kafka 或 NATS时序库用 Prometheus远程写、VictoriaMetrics 或 ClickHouse。选型看数据形态纯计数器走 Prometheus 生态最顺带 INT 元数据的逐跳记录更适合 ClickHouse因为要按流维度做聚合查询。这里有个容易忽略的点遥测数据的标签基数。接口计数器如果按interface queue flow打标签基数会爆炸。我一般会把高基数维度放到日志或 ClickHouse 表里Prometheus 只保留设备、接口、方向三个标签。3. 把 INT 元数据接进分析管道从 P4 解析到流级聚合3.1 INT 元数据栈的字段与解析INT 元数据通常包含交换机 ID、入端口、出端口、队列 ID、队列深度、链路时延、时间戳。不同实现P4 INT、厂商私有 INT字段顺序和位宽不同解析前必须拿到对应的头格式定义。下面是一个简化的 INT 元数据解析示例假设每跳 12 字节switch_id(4) ingress_port(2) egress_port(2) queue_depth(2) timestamp(2)。import struct # 每跳 12 字节按大端解析 HOP_FORMAT !IHHHH HOP_SIZE struct.calcsize(HOP_FORMAT) def parse_int_metadata(raw_bytes): hops [] offset 0 while offset HOP_SIZE len(raw_bytes): switch_id, in_port, out_port, queue_depth, ts struct.unpack( HOP_FORMAT, raw_bytes[offset:offset HOP_SIZE] ) hops.append({ switch_id: switch_id, in_port: in_port, out_port: out_port, queue_depth: queue_depth, timestamp: ts }) offset HOP_SIZE return hops # 示例两跳元数据 raw bytes.fromhex(000000010001000200030004000000020005000600070008) for hop in parse_int_metadata(raw): print(hop)逻辑说明!IHHHH中!表示网络字节序I是 4 字节无符号整数H是 2 字节。实际 INT 头可能还有hop_count和instruction_mask需要按你的 P4 程序或厂商文档调整。解析出来的queue_depth是瞬时值要结合时间戳算队列变化率才有意义。参数说明HOP_SIZE必须和头格式严格一致差一个字节后面全错位。timestamp如果是设备本地时钟跨设备比较前要做时钟同步否则时延计算会出负值。3.2 流级聚合把逐跳数据变成可查询的视图逐跳元数据本身很碎运维要看的是“哪条流在哪个队列上排队”。常见做法是在采集端按五元组聚合计算每条流的路径、最大队列深度、逐跳时延。-- ClickHouse 表结构存储 INT 逐跳记录 CREATE TABLE int_hops ( flow_id String, src_ip String, dst_ip String, src_port UInt16, dst_port UInt16, switch_id UInt32, in_port UInt16, out_port UInt16, queue_depth UInt16, ts DateTime64(6) ) ENGINE MergeTree() ORDER BY (flow_id, ts); -- 查询每条流的最大队列深度和路径跳数 SELECT flow_id, max(queue_depth) AS max_queue, count(DISTINCT switch_id) AS hop_count FROM int_hops WHERE ts now() - INTERVAL 5 MINUTE GROUP BY flow_id ORDER BY max_queue DESC LIMIT 20;逻辑说明ORDER BY (flow_id, ts)让同一流的记录物理相邻查询快。max_queue能直接暴露微突发——如果某条流的队列深度在 5 分钟内冲到很高而平均带宽不高基本就是微突发。参数说明ts用DateTime64(6)保留微秒INT 时间戳精度通常够用。flow_id建议用五元组哈希避免字符串过长。如果数据量很大按天分区。3.3 采集频率与数据量的平衡INT 逐包上报数据量极大。全量开启在 10G 链路上可能直接打爆采集端。常见做法是采样按 1:100 或 1:1000 采样 INT或者只对特定 ACL 匹配的流开启 INT。gRPC 遥测则相反可以全量开因为它是聚合值。我一般会先开 gRPC 遥测做基线发现某条链路或某个应用异常后再对该流开启 INT 做精细定位。这样既控制数据量又保留定位能力。4. 避坑与排查遥测落地时最容易翻车的五个点4.1 订阅建了但收不到数据现象gNMI Subscribe 返回成功但一直没有 update。原因通常是路径写错或设备侧没有对应数据。不同厂商 YANG 模型路径差异很大interfaces/interface/state/counters在有的设备上是interfaces/interface/statistics。解决先用gnmi_capabilities查设备支持的模型再用gnmi_get手动读一次路径确认有数据后再订阅。4.2 INT 元数据解析错位现象解析出来的 switch_id 是天文数字端口号也对不上。原因是头格式假设错了比如实际有 4 字节的instruction_mask而你没跳过。解决抓一个真实 INT 报文用 Wireshark 的 INT 解析器对照字段偏移或者直接看 P4 程序里的int_header定义。别靠猜。4.3 采集端磁盘被写满现象遥测跑了一周时序库磁盘告警。原因是高基数标签或未做降采样。解决Prometheus 侧配置metric_relabel_configs丢掉不需要的标签ClickHouse 侧建 TTL 或物化视图做分钟级降采样。INT 逐跳数据保留 24 小时原始、7 天聚合通常够用。4.4 时间戳不同步导致时延为负现象逐跳时延算出来是负数。原因是设备时钟没同步或者 INT 时间戳单位不统一有的用纳秒有的用微秒。解决全网开 NTP 或 PTP采集端解析时统一转成微秒。如果设备不支持高精度时钟INT 时延只能看相对趋势不能看绝对值。4.5 gRPC 连接被设备限速或断开现象订阅跑一段时间后断开重连也失败。原因是设备对 gRPC 会话数或 CPU 有保护采样间隔太短会触发限速。解决把sample_interval从 100 毫秒放宽到 1 秒减少订阅路径数量或者改用ON_CHANGE模式只推变化。设备侧也要确认 gRPC 的max-sessions配置。5. 用遥测数据做故障定位一个微突发的排查习惯微突发是遥测最能体现价值的场景。传统监控看到的是 5 分钟平均带宽 40%但业务已经卡了。用遥测你能看到 100 毫秒内队列深度冲到 90%。我的习惯是三步第一步gRPC 遥测发现某接口out_queue_depth在特定时间点有尖峰第二步对该接口开启 INT 采样按五元组聚合找出贡献最大的流第三步用 INT 逐跳数据看这条流在哪个交换机、哪个出端口开始排队定位到具体设备。验证方法在实验环境用tc或pktgen构造微突发对比遥测数据和实际丢包。如果遥测显示的队列深度峰值和tc统计对不上先查采样率再查时间戳对齐。一个具体技巧INT 元数据里的queue_depth是瞬时值单看一个点没意义。我一般会在采集端做 10 毫秒窗口的滑动平均再取窗口内最大值。这样既能过滤毛刺又不会漏掉真实微突发。最后说个血泪教训遥测不是开得越多越好。我早期在一个园区网全量开 INT结果采集端 CPU 跑满反而丢了关键告警。后来改成按需开启、分层采集才稳定下来。先想清楚你要回答什么问题再决定采什么数据。希望帮到你。本文还有配套的精品资源点击获取