|
|
|
# 数据生产基本指南 （未完）
|
|
|
|
本流程规范了数据团队数据相关工作。为日常数据工作提供指导，以期提高工作效率及工作成果的质量。
|
|
|
|
以下内容均来自对日常工作的不断总结。
|
|
|
|
|
|
|
|
|
|
|
|
## 流程
|
|
|
|
### 1. 业务逻辑分析
|
|
|
|
主要是分析数据在业务层面的逻辑模型。应至少包含以下几个方面：
|
|
|
|
1. 产生数据的业务流程、状态变化等。需要参考官方来源、竞品网站。了解数据的变化模式，包括静态数据、动态数据。静态数据指的是产生之后不会更新的数据，例如：裁判文书、招投标公告等；动态数据指的是需要更新最新状态的数据，比如工商、失信、商标等
|
|
|
|
2. 专业名词、术语含义，专业解释与实际数据使用之间的差异
|
|
|
|
3. 数据逻辑模型定义：数据实体及其关系
|
|
|
|
4. 数据中所涉及的企业主体，及角色
|
|
|
|
5. 数据达到使用要求所必不可少的字段及字段的获取方法（直接获取或通过技术手段获取）
|
|
|
|
|
|
|
|
### 2. 来源数据分析
|
|
|
|
这里所说的来源数据是指我们可获得的最初始的数据：如爬取的数据、采购的数据等。通过此步骤主要是分析来源数据与前一步骤所确定的理想逻辑模型间的差距及映射。
|
|
|
|
1. 来源数据与理想逻辑模型之间的字段差异
|
|
|
|
2. 来源数据融合进自有数据的可行性，每条数据唯一键的设计差异
|
|
|
|
3. 来源数据本身的数据质量，使用该数据源是否会污染自有数据的质量
|
|
|
|
3. 来源数据是否可作为线索提供给爬虫更新自有数据
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### 3. 表设计
|
|
|
|
结合前两步结果，设计最终使用的表的设计。在设计中需要从以下几个方面考虑：
|
|
|
|
|
|
|
|
1. 区分数据唯一性的字段设计，唯一键的设计要兼容多种数据源
|
|
|
|
1. 表中的数据项如何被更新，完全覆盖更新还是有条件的更新
|
|
|
|
2. 该数据需要支持的主要查询模式，根据查询模式设计索引
|
|
|
|
3. 更新设计。防止出现回滚更新的辅助字段设计
|
|
|
|
4. 每条数据要有入库时间、最后更新时间、更新数据的来源标示、数据有效性状态、数据展示状态等
|
|
|
|
5. 增量数据提取设计，包括新增数据和更新数据
|
|
|
|
|
|
|
|
### 4. 清洗流程设计
|
|
|
|
1. 存量数据清洗方式。
|
|
|
|
|
|
|
|
>存量数据存在于关系型数据库，可通过data_pump,consumer等工具清洗入新库，根据存量数据量大小及清洗数据的时间复杂度等选择流程模式，模式有：
|
|
|
|
|
|
|
|
>* sql_reader -> cleaning_filter -> sync_writer
|
|
|
|
|
|
|
|
>* sql_reader -> cleaning_filter -> csv_writer, load data infile to table
|
|
|
|
|
|
|
|
>* sql_reader -> csv_writer, csv_reader -> cleaning_filter -> sync_writer （数据量大或清洗过程需要时间较长）
|
|
|
|
|
|
|
|
>* sql_reader -> kafka_writer, consumer -> udm ... -> sync_udm （数据量大或清洗过程需要时间较长）
|
|
|
|
|
|
|
|
>存量数据存在于文件，且需要简单的去重合并，通过hadoopstreaming处理成csv文件，再通过data_pump，mysqlimport等工具入库
|
|
|
|
|
|
|
|
>存量数据存在于文件，且清洗逻辑复杂，不建议（禁止？）使用project-ic中的warehousing流程处理
|
|
|
|
|
|
|
|
>通过data_pump从数据库或文件读数据必须设置offset，以防中断后从头开始
|
|
|
|
|
|
|
|
2. 增量例行方案
|
|
|
|
3. 数据清洗流程中的校验点
|
|
|
|
|
|
|
|
|
