数据采集—不同类型数据采集的技术方案

数据采集到底是什么？——从入门到理解全景

一 什么是数据采集

数据采集，泛指把分散的原始数据“拿到手里”的过程，它包括数据获取、传输、校验等一系列步骤，是数据分析/数据系统的基础。
从技术角度看：
📍目标：把业务和行为事件转化成可供分析的数据
📍 来源：客户端行为、服务端事件、业务数据库、第三方系统等
📍 核心：不遗漏重要事件、确保数据准确、支持后续分析

二 主要采集的技术类型和技术方案

1.客户端数据采集——行为埋点

在客户端（Web 页面、小程序、App等）上采集用户行为数据，行业术语叫 “埋点”。

为什么要采集客户端数据？

用户行为是业务分析的基础，比如：

• 点击按钮
• 浏览页面
• 输入搜索关键字
  这些都是用户真实行为，需要准确捕获。

客户端埋点可以在用户使用客户端的过程中，一个行为发生或者属性变化的现场就完成数据的采集，是一个从逻辑上非常直观的采集方式，因此也成为了当前用户行为和用户属性数据采集的主流方案。

客户端埋点属于业务数据采集的最前端，也是行业最普遍的方式。

常见埋点技术方案

在采集用户行为数据方面，客户端 SDK 提供了自动化采集数据的“全埋点”模式和需要手动写代码进行设置的“代码埋点”两种模式

全埋点的优势是无需开发，会自动采集一些预制的属性和事件，非常适合于项目的快速启动。而代码埋点相比全埋点，采集的属性和事件都可以预定义，但是需要写一部分的代码。从我们过往的工程实践经验来看，通常情况下，采用全埋点加代码埋点结合的方式是一个比较好的方案。即在全埋点的基础上，对于部分信息密度比较高的用户行为，采用代码埋点的方式进行采集。

• 手动代码埋点
  即在业务代码里明确写下采集逻辑：

track("button_click", {
  page: "order",
  button: "submit"
});

优点：

• 参数明确
• 数据语义清晰

缺点：

• 开发成本高
• 埋点代码散在业务逻辑里不易维护
  
  

为了避免阻塞客户端的使用，埋点的数据是需要本地缓存然后异步传输的。由于客户端数据的采集需要通过公网进行传输，所以强烈建议采用 HTTPS 作为传输协议。

客户端采集的天生问题

在公网传输中，虽然已经采用了类似于本地缓存、批量压缩等各种技术手段，但依然难以保证数据的 100% 准确。因此对于那些非常强调数据准确性的应用，它所需要的一些关键数据，应该考虑直接采集服务端日志或者业务数据库中的数据等方式。

客户端采集存在一些挑战，它并不是“完美方案”：
📌 丢失数据
比如网络断开、用户关闭页面、浏览器限制采集行为，这些都会导致数据丢失。
📌 浏览器安全策略影响
例如跨域、隐私设置可能阻止采集。
📌 与业务真相有差距
比如用户点击后未完成支付，可能看不到完整业务意图。

因此，客户端埋点的维护工作反而是具有相当挑战的。一个好的实践是，在组织内部，应该将埋点视作是开发工作的一部分，而不是一种额外的负担。埋点应该贯穿在整个开发流程之中。

• 在技术设计环节，就要充分考虑关于埋点变更部分的内容。
• 在开发自测环境，埋点也应该与常规的业务代码得到同等对待。
• 在测试环境，测试工程师也同样需要测试埋点的正确性。
• 上线变更后，对于埋点的确认也需要作为上线验收的一个环节。

客户端采集适合用于补充行为分析，但不能作为业务数据唯一来源。

2.服务端采集 —— 业务事件采集

相对于客户端，服务端主要是指我们部署在内网的，负责接收客户端请求进行业务逻辑处理的模块。服务端埋点通常情况下会作为客户端埋点的补充。对于部分质量要求非常高的数据，服务端埋点可以走内网传输，准确率能得到更好的保障。同时，有时候也会有部分信息在客户端拿不到，在服务端进行埋点也是唯一的选择。

通常情况下，不建议服务端直接把数据往后传输，而是建议先把数据落地到日志文件，然后再采集日志的增量。一方面是数据先落盘，相当于有一个冗余的备份；另一方面，数据采集本身也并不值得同步的网络传输开销，不应该影响服务端的性能。

为什么服务端采集重要

服务端事件来自业务系统的“核心逻辑点”，因此其可靠性远高于客户端。
举例：
当订单支付成功时，后台系统会记录订单状态变更，这种数据采集方式常见于：

{
  "event": "order_paid",
  "order_id": "20250101",
  "user_id": "U123",
  "amount": 199.00
}

这种数据不是“用户行为”，而是“业务事实”。

服务端采集的优势

• 可靠性高：不易丢失
• 不依赖客户端环境
• 可作为分析体系中的“权威数据源”

与客户端采集搭配使用，是比较推荐的方案。

3.业务数据库数据采集

Apache SeaTunnel 就是一个非常好用的业务数据库的数据集成产品。基于 SeaTunnel，我们可以更多地关注于业务数据库中的数据内容，而不需要再去重新进行工具层面的开发。

而要进行数据库的数据采集，通常需要考虑以下几个关键方面。

首先是全量采集还是增量采集。全量采集适合数据量较小或首次同步场景。增量采集通过 CDC（Change Data Capture）技术，只同步变更数据，效率更高。在日常实践中，对于比较小的，或者说更新比例比较大的表，我们采用全量采集覆盖数据的方案。而对于比较大的，或者更新比例不大的表，我们一般在初始全量采集之后，采用增量采集的方案。

其次是实时采集还是批量采集。实时采集能够秒级感知数据变化，适合时效性要求较高的业务。批量采集按固定时间间隔执行，适合对实时性要求不高的分析场景。不太推荐对于数据库中的表的内容采用实时采集的方案。如果下游实时的数据应用真的强依赖数据库中的实时内容变更，那么更应该考虑在数据库的上游，例如业务模块中实时采集日志。

第三是数据探查。在很多情况下，由于历史间隔、组织或者人员变动等原因，我们对于数据库中某些表的某些字段，具体是什么含义可能并不清楚。因此，相比较技术挑战，进行数据探查，充分了解业务数据库的数据内容反而是更具挑战性的。

数据探查核心要弄明白表字段的含义、数据的分布、空值和异常值等代表的数据质量，同一个字段在不同表格中的一致性等。这里面需要非常细致地与业务团队进行沟通，产出并且维护好一份数据字典。

第四是数据库的变更。如果因为业务方的变更，导致数据库中的字段、内容、数值分布、关联关系等发生变更，而数据采集方不知晓，则会直接影响数据质量。为了应对这个问题，一方面是需要建立比较好的沟通协作机制；另一方面，在技术上，也可以增加各种监控项，当上游数据表发生变更时，及时将问题暴露出来。

除了要采集关系型数据库中的数据表，很多时候我们也需要采集在已有的数据仓库、数据湖中的数据，SeaTunnel 同样提供了很好的工具支持，需要遵循的原则也都是一样的。

刚刚介绍的埋点和数据表的采集，都是采集我们自己系统的数据。而在实践中，我们很多时候还需要采集第三方数据。

4.第三方数据采集 —— 接口对接 & API 取数

第三方是一个非常广泛的概念。对于电商企业来说，他们需要能够获取支付系统、物流系统、第三方 CRM 等系统的数据。对于游戏公司来说，他们想要采集用户在游戏论坛中的评论信息。这些不归属于我们的数据，都可以称作第三方数据。

与自有业务系统相比，第三方系统的数据采集面临着更多的技术挑战和业务约束。在北美比较成熟的 SaaS 生态下，有类似于 Fivetran 这样的自动数据集成公司，帮忙完成了常见的系统数据集成。同时，北美 SaaS 生态本身相对而言也比较看重互相之间的数据联通，在 API 等方面都有很好的设计。

而在国内，则会面临更大的挑战，我们不得不针对不同的第三方系统单独开发数据采集方案。而在开发数据采集方案时，有一些共性问题需要注意。

首先是合规。一定是要在第三方服务允许的前提下，使用合法合规的方式来采集数据。如果是我们自己购买的第三方开发的 CRM 系统，那么我们当然可以采集数据。或者如果是支付系统允许我们获取的数据，那么采集也没有任何问题。但是，类似于在 Spider 声明中明确禁止却依然去用各种手段抓取网页，或者说明明没有提供数据接口，但是我们依然用 hack 的方式去抓取数据的情况，则应该避免。

其次是要注意数据的一致性。 由于无法直接访问第三方系统的底层数据存储，我们往往需要依赖其提供的增量数据接口或时间戳字段来实现增量同步。这就要求我们建立完善的数据校验机制，通过 checksum、数据量对比等方式确保数据传输的完整性和准确性。

第三是稳定性和容错处理。第三方系统的可用性往往不在我们的控制范围内，网络波动、系统维护、接口变更都可能导致数据采集中断。因此，我们需要设计鲁棒的重试机制、熔断保护和降级方案，确保采集任务的稳定运行。同时，建立完善的监控告警体系，及时发现和处理异常情况。

最后是成本控制与效率优化。许多第三方系统按 API 调用次数或数据传输量收费，这就要求我们一方面是根据数据应用的需要，只采集需要采集的数据；另一方面则是在保证数据时效性的前提下，通过批量请求、智能缓存、压缩传输等手段降低采集成本。

第三方数据只做参考或补充，不可作为主数据源

三 总结

数据类型	采集方式	推荐技术方案	核心优势	主要挑战	适用场景
用户行为数据	客户端埋点	通用埋点 SDK 全埋点 + 代码埋点	现场采集，逻辑直观 覆盖多种客户端 自动化程度高	公网传输准确性 跨角色协作维护 版本迭代管理	Web / App / 小程序 用户行为分析 精细化运营
服务端行为数据	服务端埋点	服务端埋点 SDK Fluentd / Filebeat	内网传输准确性高 可采集客户端无法获取的信息 数据可落盘备份	与业务开发强耦合 性能影响控制 日志格式标准化	关键业务流程 高质量数据需求 服务端专属信息
业务数据库数据	数据库采集	Apache SeaTunnel CDC 技术	工具成熟开源 支持全量 / 增量 多种数据库兼容	数据探查理解 上游变更感知 数据一致性保证	订单 / 商品 / 用户信息 关系型数据分析 业务系统集成
第三方系统数据	API / 接口采集	定制化接口开发 批量请求优化	数据来源丰富 业务价值补充 生态数据整合	合规性要求 稳定性控制 成本控制	支付 / 物流 / CRM 外部数据补充 生态系统集成

📌 数据采集是数据分析首要的一环，合理地组织采集体系，才能保证后续分析的正确性。
📌 数据来源不同，采集方式也不同，组合使用才是一个成熟方案。
📌 每一种采集方式有其适用场景，也有自己的局限。