企业数据中台建设方案

企业数据中台建设方案

采购人名称：______________

项目名称：_____________

系统项目串号：______________

供应商名就______________

目录

第一章数据中台必须具备4个核心能力................................1

1.1.汇聚整合...................................................1

1.2.提纯加工...................................................2

1.3.服务可视化（数据资产服务化能力）...........................2

第二章全量数据采集................................................2

2.1.数据采集方式...............................................2

2.2.全量数据库.................................................4

2.2.1.全量数据库创建标准...................................4

2.2.2.数据可视化应用.......................................12

数据中台是一套可持续“让企业的数据用起来”的机制，一种战略选择和

组织形式，是依据企业特有的业务模式和组织架构，通过有形的产品和实施方

法论支撑，构建一套持续不断把数据变成资产并服务于业务的机制。

数据中台将采集企业的业务、设备相关数据，按照统一数据体系进行数据

的建模和萃取，生成不同的数据域，包含人员域、车辆域等多种数据域，通过

企业的数据服务中心实现企业数据交换的统一管理、集中控制。通过统一的数

据调用接口，供各个前端应用使用数据，形成数据环流，降低跨系统数据交换

的复杂性，提高企业数据交换的及时性、准确性和完整性。

第一章数据中台必须具备4个核心能力

数据中台需要具备数据汇聚整合、数据提纯加工、数据服务可视化、数据

价值变现4个核心能力，让企业员工、客户、伙伴能够方便地应用数据。

1.1.汇聚整合

数据丰富和完善：多样的数据源进行合并和完善

管理易用：可视化任务配置、丰富的监控管理功能

数据集成运营：数据接入、转换、写入或缓存内部来源的各来源数据

数据目录与治理：用户可以方便定位所需数据，理解数据（技术/业务治

理）

数据安全：确保数据的访问权限

数据可用：用户可简便、可扩展的访问异构数据，可用性和易用性高

部署灵活：本地、公有云、私有云等多种署方式

第1页

1.2.提纯加工

完善的安全访问控制

完善的数据质量保障体系

规范的、紧密结合业务的可扩展的标签体系

面向业务主题的资产平台

智能的数据映射能力，简化数据资产生成

1.3.服务可视化（数据资产服务化能力）

提供自然语言等人工智能服务

提供丰富的数据分析功能

提供友好的数据可视化服务

便捷、快速的服务开发环境，方便业务人员开发数据应用

提供实时流数据分析

提供预测分析、机器学习等高级服务

第二章全量数据采集

对企业已实现的招商一体化平台、政策采编推荐平台、企业企业服务平台、

金融撮合服务平台、IOT物联网平台相关数据通过API对接、ETL采集等多

种方式实现业务数据采集工作。

2.1.数据采集方式

方式一：读备份库

第2页

为了不影响业务系统的正常运行，可以采用读备份库的数据，这样能够及时

获取数据进行一些分析工作，但是有些从业务也会读取备份数据库，还需要考虑

一致性和可用性问题。

方式二：埋点(pingback)

可以在前端APP上记录用户点击，滑动速度，停留时间，进入的时间段，最

后看的新闻等等信息，这些可以通过网络传输将埋点信息记录下来，用于数据分

析。但是这种方式有可能会对业务系统代码具有一定的侵入性，同时工作量也比

较大，存在一定的安全隐患。

方式三：发送消息的方式

上述埋点的方式在业务系统繁忙的情况下，会对数据采集系统产生大量的请

求，如果数据处理不及时会把数据采集服务打垮，同时为了解耦，这里可以引入

消息中间件，如果对时效性要求较高，可以采用推模式对数据采集系统进行推送,

如果时效性不是很高，可以采用定时任务拉取数据，再进行分析。

同时可以多个系统订阅消息中间件中不同Topic的数据，可以对数据进行重

用，后端多个数据分析系统之间互不影响，减轻了从业务系统采集多份数据的压

力。

方式四：读取MySQL中的binlog

MySQL会把数据的变更(插入和更新)保存在binlog中，需要在my.ini

中配置开启，因此采用kafka订阅binlog,会将DB中需要的字段抓取出来，保

存在备份库中，进行数据分析，工作量较小，安全稳定。

第3页

2.2.全量数据库

在数据中台中实现对平台应用数据、企业数据、业务操作数据、设备数据、

日志数据等，定义各维度与业务场景的数据存储全量库，实现全数据存储于输出,

同时实现数据治理工作。

创建中台应用数据、企业数据、业务操作数据、设备数据、日志数据等库表

结构。

2.2.1.全量数据库创建标准

1）命名规范

a.总命名规范

＞不得使用数据库保留关键字，以及php^ava等常用语言的保留关键字，

或者可能成为关键字的单词作为完整命名。（对于一些疑似关键字的单词，可以

在后面加一个下划线来避免，例如“key_”）o

＞如无特殊说明，名称必须用英文字母开头，采用有特征含义的单词或缩

写，单词中间用分割，且只能由英文字母、数字和下划线组成，不能用双

引号包含。

＞除数据库名称长度为1至8个字符，其余（包括表、字段、索引等）不超

过30个字符，Databaselink名称也不要超过30个字符。（30并不是凭空想象

出来的，而是参考了Oracle的限制）

b.表名

建议以2-3字项目名称为前缀开头，紧跟2-5个字符（英文字母或数字，但不

第4页

得全是数字）的模块名，最后跟上当前表的含义的单词（1-3个单词，用下划线

连接），例如：SQ_SYS_CAR,SQ是项目名称的缩写，SYS是模块名称的缩写,

CAR表示当前表的具体含义。

特别强调：项目名称和模块名用简写（建议长度为2-5个字符），而表含义

的名称，可简写、也可以不简写，但是都不能超过3个单词，例如下面两个反面

例子：

>ABF_SUPERVISION_USER,问题：模块名称似乎比较长，建议控制

在2-5个字符，缩写为ABF_SUPV_USER;

>ABF_SYS_USER_MANAGE_ORG_ROLE,问题：除去前缀

ABF_SYS_,表含义（USER_MANAGE_ORG_ROLE）超过了3个单词。

2）字段名

a.表的字段数不超过50个。

b,类型：各表之间相同含义的字段，类型定义要完全相同（包括精度、默

认值等）；

c.命名：

>字段名无单词数的限制，但是名字的字符长度应该符合上面的“总命名

规范”。

>字段命名及其注释，要做到清楚、无歧义。

3）主键名

前缀为PK_。以PK_+表名+主键字段名构成。如果复合主键的构成字段较多,

则只包含第一个字段。表名可以去掉前缀。例如PK_SYS_CAR」D。

第5页

4）外键名

前缀为FK_。以FK_+外键表名+主键表名+外键字段名构成。表名可以

去掉前缀。例如

FK_SYS_USR_SYS_CAR_IDO

5）普通索引

前缀为IDX_。以IDX_+表名+索引字段名构成。如果复合索引的构成字段较

多，则只包含第一个字段，并添加序号。表名可以去掉前缀。例如

IDX_SYS_CAR_DINO

6）主键索引

前缀为IDX_PK一。以IDX_PK_+表名+索引字段名构成。表名可以去掉前缀。

例如

IDX_PK_SYS_CAR_IDO

7）唯一索引

前缀为IDX_UK一。以IDX_UK_+表名+索引字段名构成。表名可以去掉前缀。

例如IDX_UK_SYS_CAR_DINo

8）外键索引

前缀为以表名+外键字段名构成。表名可以去掉前缀。

IDX_FK_OIDX_FK_+

例如IDX_FK_SYS_CAR」D。

9）Oracle序列

前缀为SEQ_o以SEQ.+“序列业务名称”构成。如果“序列业务名称”就

是某个表名，则使用表的全名，不可去掉前缀。例如SEQ_SQ_SYS_CAR。

a.表设计规范

采用UTF8字符集。

第6页

对于数据量可能很大的表（超过2000万），采用分库/分表/分区表，横向拆

分控制单表容量。

必须为表、字段等添加注释。

遵守数据的设计规范3NF规定。

表内的每一个记录都只能被表达一次。

表内的每一个记录都应该被唯一的标识（有唯一键）。

表内不应该存储依赖于其他键的非键信息。

反范式化冗余字段使用规范考虑具体使用场景，当SQL关连查询比较频繁,

或涉及到4张以上表时可考虑采用冗余字段。

必须设置唯一主键，尽量使用自增id作为主键。

建议主键为数字类型，且为递增顺序，主键不表示任何业务含义，严禁数据

量大的表使用UUID/MD5作为主键。

不使用数据库外键，由程序保证。

MySQL:使用InnoDB存储引擎。

数据库和表字符集类型统一（utf8mb4-UTF-8Unicode）,排序规则统

一（utf8mb4_unicode_ci）;建表语句中强制指定字符集；

自增字段类型必须是整型，使用BIGINT类型。并且自增字段必须是主键或

者是主键的一部分。

b.字段设计规范

凡是可能被索引的字段，必须定义为NOTNULL,可以设置default值；

非负值的数字统一使用unsigned（无符号）类型存储？

第7页

>大对象字段：

通常情况下，禁止使用LOB类型保存大文本、图片和文件，建议使用其他方

式存储(例如文件系统，数据库只保存其地址信息)。

MySQL:尽量不要使用TEXT数据类型，mysql的varchar类型支持65535

字节，满足大多数场景，仅当字符数特别大时，才考虑text类型；

禁止使用enum,对于boolean类型或者表示简单状态的字段，MySQL用

tinyint,Oracle用NUMBER(l)

建议字段notnull,根据业务要求来设置默认值(例如默认为0)o

对于boolean类型，以1代表是(true),0代表否(false)。

对于状态类型，注释中应该注明每一种状态的含义，例如“0：编辑中，1：

审核中，2:已完成”。

>数字、小数类型：

对于数字、小数类型，不得使用VACHAR等字符串类型来保存，应该使用

相应精度的数字、小数类型。

尽量确保数值型列都有默认值

对于Oracle,确定好Number的精度。

对于MySQL,选好数字类型：

TINYINT>SMALLINT〉MEDIUMINT〉INT>BIGINT>DECIMAL(存储空间逐

渐变大，而性能却逐渐变小)，超过tinyint(256)但不超过65536的使用

smallint;当该字段超过42亿时，才使用bigint;

>时间类型标准:

第8页

对于Oracle,有两种时间类型：DATE和TIMESTAMP,DATE的精度只

保存到秒，例如“2013-1L0211:16:36"，而TIMESTAMP精度更高可以保存

小数秒，例如“2013-11-0311:16:36.000000”。有时候,DATE只保存到秒，

不足够区别出两个事件哪个先发生，这时建议使用TIMESTAMP类型。

MySQL:存储年使用year类型，存储日期使用date类型，使用精确时间戳

(精确到秒)尽量使用timestamp类型，因为timestamp使用4字节，

datetime使用8字节，它们的区别：TIMESTAMP值不能早于1970或晚于2037

(,1970-01-0100:00:01'UTCto'2038-01-1903:14:07'UTC)。

必须使用intunsigned存储IPV4;

>一些常见字段的命名统一

为了规范命名，并结合一般命名习惯，指定如下几个字段定义(以Oracle为

例)：

ID编号NUMBER(22)(Integer)

Create-By创建人NUMBER(22)(Integer)

Create_Time创建时间TIMESTAMP-默认为系统当前时间

Update_By修改人NUMBER(22)(Integer)

Update_Time修改时间TIMESTAMP-默认为系统当前时间

其他参考命名：

Code.编码VARCHAR2(30)

Level.层级NUMBER(1或2)

Delete_Status删除标志NUMBER(l)-1:表示已经删除，默认为0:表

第9页

示未删除

Description.描述或备注VARCHAR2（200）

c.索引规范

复合索引的字段数不能超过5个。

单表的索引数量尽量控制在5个以内。

联合索引的字段排列顺序以去重后字段的数值的个数大小排序先后顺序。比

如表mk_task有id,name,id有50000个独立值，name有5000个独立值，那

么，顺序是id在name前面，建立的索引是idx_id_name。

Orderby、distinct、groupby后的字段尽量建立索引。

update,delete的where尽量使用有索引的字段或主键。

超过20字节的varchar字段建议用前缀索引，禁止对字符串长度超过50个

字符的列创建索引。

不建议在低基数列上创建索引，例如“性别”歹I」；

合理创建联合索引（避免冗余），（a,b,c）相当于（a）、（a、b）、（a、

b、c）o

长文本类型字段（例如Text）不能使用索引。

d.其他问题

主键ID建议使用分布式全局唯一递增IDo

禁止使用存储过程、视图、事件、触发器、数据库自带的分区表。

临时库、表名必须以“tmp_日期”为后缀，如当日创建多个，则在日期后

增加数字后缀;

第10页

备份库、表必须以“bak_日期”为后缀，如当日创建多个，则在日期后增加

数字后缀；

＞主题数据库设计与分析

设计企业企业服务主题、产业服务主题、综合安防主题三大主题，存储指定

业务场景的主题业务数据库。基于三大主题数据，按照主题域实现数据分析与

治理服务，并根据数据可视化应用的数据展示维度输出数据API服务。

企业服务主题：主要包括租赁服务、招商服务、金融服务等内容。

产业服务主题：主要是包括供应商对接、产业规划等。

综合安防主题：主要包括安全监控、门禁卡、人员黑白名单、车辆黑白名单

等。

＞主题的输出标准我们通过RESTAPI标准进行设计提供开放数据

REST全称是RepresentationalStateTransfer,中文意思是表述性状态

转移（注：通常译为表征性状态转移）。它首次出现在2000年RoyFielding

的博士论文中，RoyFielding是HTTP规范的主要编写者之一。

RoyFielding在论文中提到：“我这篇文章的写作目的，就是想在符合架

构原理的前提下，理解和评估以网络为基础的应用软件的架构设计，得到一个功

能强、性能好、适宜通信的架构。REST指的是一组架构约束条件和原则。”

如果一个架构符合REST的约束条件和原则，我们就可以称之为RESTful架

构。

通俗地讲：RESTful就是客户端与服务器进行数据交互的一种规范，而且是

当今绝大多数开发者都在遵循的规范。