本文围绕数据采集为讨论主题，从三个方面——业务流程梳理、原型注意点、项目上线后复盘总结进行了分享。

随着数据量的不断增速，数据价值也逐渐被很多公司所关注，尤其是偏重于业务型的企业，大量数据的产生，在未被挖掘整合的过程中通常被看作是一堆无效且占用资源的；但一旦被发掘，数据的价值将无可估量。尤其像电商，银行，服务行业等等。近段时间有幸参与负责了一个大数据项目，今天主要对采集系统做一次简单的复盘：

数据采集系统故名思意就是将数据从数据源采集到能够支撑大数据架构环境中，从而实现数据的采集以便后期对数据的二次加工建立数据仓库。

一、业务流程梳理

在业务流程梳理的过程中，我们先预设个场景，如：

当公司运营人员提出一个订单转化率的需求，作为产品人员，首先要确定分析订单转化率与哪些因素有关，最终确定从用户下单，支付这两个环节中分析，如当月有多少用户提交了订单，之后有多少用户确认了订单，有多少用户最终支付订单等；最终呈现了漏斗形的分析主题；因此分析时就需要确定所需要的这些数据要从哪些表获取，都需要获取哪些数据，获取到后要采集存储到哪个数据仓库的表中，最终被使用到。

因此从上面的例子中我们可以从以下几点思考业务流程：

1. 确定主题，确定主题模型；
2. 确定表和数据口径；
3. 确定需要与目标的映射关系；
4. 确定表与口径需要从哪些源下获取，以及如何数据更新的频率等；

从以上几点我们可以看出，第一点主题模型我们今天不做过多的介绍，着重从2~4点分析可以将采集系统划分为数据源配置、表结构的管理、源表管理、映射配置和采集任务管理几大模块。

• 数据源管理包括新增，编辑，删除等；
• 表结构管理包括表结构的批量导入，查看等；因为采集过程中表是要参与映射的，结构一旦导入是不允许修改的，以免影响后面的采集配置文件的输出。
• 映射配置主要是配置表与表，字段与字段的映射关系，过滤条件与增量的设置。作为采集的配置模板使用；为什么不是在之前就与数据源关联的目的是因为解耦表与数据源的关系，方便于后期的扩展和用户易用性。
• 采集任务管理主要是建立源与源之间采集过程以及任务的执行情况。

二、原型注意点

1. 数据源管理

数据源一般会分为很多种类型，因此，我们需要建立数据源类型；如ORECAL、mysql、hive等。

添加数据源时，对于所填写内容的校验一般会根据需要来决定，需要填写的字段大致包括源名称，服务器，端口，用户名，密码等。

2. 表管理

表结构的获取一般会有两种方式，一种是通过连接数据库获取，一种是本地保存，直接从本地获取。具体使用哪种方式根据实际情况来决定。如果是用的第二种，则需要将表结构整理预先导入系统，以便后期使用。

hive的表结构有一些特殊，比一般数据库的表结构多几列，如：分列名称，分区值等。

3. 映射配置

映射配置主要是确定源表和目标表，同时建立字段映射关系；亦可设置过滤条件，数据采集的周期配置设置等。

4. 任务管理

主要是建立源与表，源与源的关系；同时可以对任务的执行周期来进行设置；任务配置的过程中，可以是以目标源为维度，亦可以以目标表为维度建立任务，同时可对历史任务进行监测。

三、项目上线后复盘总结

1. 需求方面

采集系统在理解前期，产品和研发考虑的点有所不同，导致原型、规则在评审后的开发初期有一些小的改动，不过整体需求上还算可以接受。

2. 交互方面

由于是B端的后台系统，一般会选用一套共用的的系统框架，因此在出具需求的过程中，只着重说明了需要注意的交互方式，一些共用的交互方式并未做过多的说明；因此在交互这多了很多的沟通成本。

3. 项目执行

整体进度还好，不过由于一些组件的提前打包定义，导致在开发过程中有些不能满足需求，耽搁了一些进度。

4. 个人方面

对数据仓库的了解和认识上有所提升，对SQL的学习也算是一次巩固，同时在做的过程中对自己以前遇到过的数据需求也有了一些新的思考思路和总结复盘。总之是收获满满。

#专栏作家#

简之箐（微信公众号：简之箐），人人都是产品经理专栏作家，5年互联网产品经理，曾担任医药产品经理和电商产品经理，经历主导过电商平台的系统整合规划。

本文原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自 Pexels，基于 CC0 协议