数据云存储服务

ICS01.
040.
03A12DB3308浙江省衢州市地方标准DB3308/T050—2018政务服务数据仓建设规范2018-09-11发布2018-10-11实施衢州市质量技术监督局发布DB3308/T050—2018I目次前言.
II1范围.
12规范性引用文件.
13术语和定义.
14基本原则与要求.
35数据架构.
36建设要求.
37数据开发.
6DB3308/T050—2018II前言本标准按照GB/T1.
1-2009给出的规则起草.
本标准由衢州市行政服务中心管理办公室提出并归口.
本标准起草单位:衢州市行政服务中心管理办公室、浙江衢时代大数据科技有限公司、浙报浙数文化集团股份有限公司、浙江省方大标准信息有限公司、衢州市质量技术监督检测中心(衢州市标准化研究院).
本标准主要起草人:洪寒月、李文阳、袁琼、李靖翔、楚龙、叶华飞、何琳、潘旭峰、张理敏、祁劲松.
DB3308/T050—20181政务服务数据仓建设规范1范围本标准规定了衢州政务服务数据仓的基本要求、数据架构、建设要求、数据开发等内容.
本标准适用于衢州政务服务数据仓的建设.
2规范性引用文件下列文件对于本文件的应用是必不可少的.
凡是注日期的引用文件,仅所注日期的版本适用于本文件.
凡是不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件.
GB/T21062.
3政务信息资源交换体系第3部分:数据接口规范GB/T20270信息安全技术网络基础安全技术要求GB/T20271信息安全技术信息系统通用安全技术要求GB/T28452信息安全技术应用软件系统通用安全技术要求GB/T29765信息安全技术数据备份与恢复产品技术要求与测试评价方法《浙江政务服务网技术规范第二部分数据交换技术规范》《浙江政务服务网技术规范第三部分数据交换信息规范》《浙江省公共数据共享交换技术规范(试行)》3术语和定义下列术语和定义适用于本文件.
3.
1云平台具有提供云服务器、开放结构化数据服务,开放缓存服务等服务的能力,用于相关配套系统的部署.
同时云平台还需拥有提供云数据库、分布式关系型数据库服务以及基于开放存储服务构建的大数据平台的能力,便于在整体的建设过程中,根据数据的规模按需进行技术选型.
3.
2云数据库具有多重安全防护措施和完善的性能监控体系,并提供专业的数据库备份、恢复及优化方案的一种即开即用、稳定可靠、可弹性伸缩的在线数据库服务.
3.
3开放存储服务云平台提供的海量、安全和高可靠的云存储服务.
3.
4DB3308/T050—20182分布式关系型数据库服务水平拆分、可平滑扩缩容、可读写分离的在线分布式数据库服务.
3.
5开放结构化数据服务构建在云平台分布式系统之上的NoSQL数据服务,以实例和表的形式组织数据,通过数据分片和负载均衡技术,实现规模上的无缝扩展.
3.
6开放缓存服务在线缓存服务,为热点数据的访问提供高速响应.
3.
7元数据描述数据的数据,对数据及信息资源的描述性信息.
3.
8数据映射给定两个数据模型,在模型之间建立起数据元素的对应关系的过程.
3.
9维度表维度属性的集合.
3.
10事实表数据仓结构中的中央表,包含联系事实与维度表的数字度量值和键.
3.
11主题在较高层次上将企业信息系统中的数据进行综合、归类和分析利用的一个抽象概念.
3.
12数据源提供某种所需要数据的载体.
3.
13政务服务数据仓政务服务运行过程中,为各类应用系统提供所有类型、海量数据支持的数据集合与战略集合.
4基本原则与要求4.
1基本原则DB3308/T050—20183文件命名习惯等保持统一,编制符合"统一性"原则,包括但不限于:模型层次命名、主题域命名、数据模型命名、工作流任务命名等的统一性,还包括开发过程以及问题处理方式的统一性.
4.
2基本要求规范数据仓的开发过程,降低开发难度,保障开发质量,避免因开发不规范问题导致的重复开发以及返工等问题.
5数据架构数据仓的建设是一个整体性工作,数据从产生到入库的整体环节应尽量遵循数据架构图进行建设,各环节采用一套标准.
数据仓建设数据架构图如下图1所示.
图1数据仓建设数据架构图6建设要求6.
1部署环境选型政务服务数据仓整体相关建设内容应统一基于衢州市政务云平台进行构建.
6.
2数据仓模型层次政务服务数据仓模型层次表如表1所示.
DB3308/T050—20184表1数据仓模型层次表分层名英文全称中文名层次定义ADSApplicationDataSummary应用数据层实现功能:该层为应用数据层,根据业务需求组织数据,该层定期需要定期review,将公共指标沉淀到DWS中.
数据来源范围:DWS、DWD.
数据存储时长:根据业务需求状况保留.
DWSDataWarehouseSummary基础标签层实现功能:该层为基础标签层,主要有统计汇总或算法产生的基础数据标签,按不同维度进行统计,主要操作包括基于业务整合、关联计算得到的明细数据;着力公共指标、排序聚合得到的汇总数据.
数据来源范围:DWD、ODS.
数据存储时长:根据业务需求状况保留.
DWDDataWarehouseDetail基础数据层实现功能:该层为基础数据层,主要操作包括数据清洗、数据过滤、数据历史变更记录等.
数据来源范围:此层数据来源于ODS.
数据存储时长:根据业务需求状况保留.
ODSOperationalDataStore源数据接入层实现功能:业务源系统数据接入到此层,此层数据不做任何加工,禁止重复进入.
数据来源范围:业务源系统.
数据存储时长:永久.
DIMDimension公共维表实现功能:该层为公共维表层,该层独立于DWD、DWS、ADS,为DWD、DWS、ADS提供维度字段说明.
数据来源范围:ODS.
数据存储时长:根据业务需求状况保留.
6.
3主题域划分6.
3.
1政务服务数据仓逻辑模型的设计采用自顶而下的方法,将需求涉及范围内的业务对象从高度概括的概念层次归类,再针对各个主题设计实体关系图.
由于主题域的划分与实际需求存在较强关联且存在迭代的情况,故仅就部分主题域以示列出,作为相关建设的参考,如表2所示.
表2数据仓系统主题域示例表主题中文名英文全称英文简称物理表前缀城**通T***cTctc城**疗M**hMhmh城**育C**eCeceDB3308/T050—20185表2数据仓系统主题域示例表(续)主题中文名英文全称英文简称物理表前缀市**理C*zCzcz6.
3.
2数据仓系统主题域细化划分示例如表3所示.
表3数据仓系统主题域细化示例表主题中文名英文全称英文简称物理表前缀所属父主题基**息B**cBasbas城**通定**息G**mGpsgps城**通地**置L**nLocloc城**通交**件E**tEvtevt城**通交**制C**lCtlctl城**通交**行O**nOptopt城**通6.
4数据模型命名数据模型命名形式及规则如表4所示.
表4数据模型命名规则表序号类型命名形式规则说明1ODS层实体/表名ods__1.
命名内容采用英文简称或拼音;2.
使用英文小写字母,单词或拼音词组之间用下划线分开,总长度建议不超过30个字符;2DIM域实体/表名dim_1.
命名内容采用英文简称或拼音;2.
使用英文小写字母,单词或拼音词组之间用下划线分开,总长度建议不超过30个字符;3临时表命名TMP__[XX]1.
以TMP打头,中间为该事实表的名称2.
以XX结尾,XX为从01~99的数字;DB3308/T050—20186表4数据模型命名规则表(续)序号类型命名形式规则说明4ADS层实体/表名ads____[B]1.
命名内容采用英文简称或拼音;2.
使用英文小写字母,单词或拼音词组之间用下划线分开,总长度建议不超过30个字符;3.
B为可选项,区分更新周期,若为'd'则表示为日表,'w'则表示为周表,'m'则表示为月表;'y'表示年分区;'p'则表示为不规则周期表;'A':表示汇总表(无分区,或每个分区都为全量数据)5DWD层实体/表名dwd____[B]1.
命名内容采用英文简称或拼音;2.
使用英文小写字母,单词或拼音词组之间用下划线分开,总长度建议不超过30个字符;3.
B为可选项,区分更新周期,若为'd'则表示为日表,'w'则表示为周表,'m'则表示为月表;'y'表示年分区;'p'则表示为不规则周期表;'A':表示汇总表(无分区,或每个分区都为全量数据)6DWS层实体/表名dws____[B]1.
命名内容采用英文简称或拼音;2.
使用英文小写字母,单词或拼音词组之间用下划线分开,总长度建议不超过30个字符;3.
B为可选项,区分更新周期,若为'd'则表示为日表,'w'则表示为周表,'m'则表示为月表;'y'表示年分区;'p'则表示为不规则周期表;'A':表示汇总表(无分区,或每个分区都为全量数据)6.
5前置数据仓建设6.
5.
1政务服务数据仓在实际建设过程中,为避免对数据源形成强干扰,以及多源复杂情况下数据迁移工作需要的考虑,一般不会采取直联生产环境的方式将数据源的数据获取到政务服务数据仓.
因此需要建立至少一个前置数据仓(一般为传统关系型数据库),作为数据迁移进仓整体传输过程的前置节点.
6.
5.
2相关前置数据仓的建设内容应主要参考政务服务数据仓ODS层进行设计与建设,以减少后续数据迁移入库的工作量.
7数据开发7.
1数据维度DB3308/T050—201877.
1.
1应合并来自不同数据源的数据,每个维度进行标准化、统一化,在数据仓中为每个维度建立一致性的标准,记录在维度表中,并通过元数据与数据映射组合的方式进行描述,方便后续的数据交叉探查等工作.
7.
1.
2应为每个维度建立标准化的编码方式,以及数据格式.
7.
1.
3应在建立标准化的编码方式后,将各源系统中数据中的维度数据进行关联转换,将不同数据源标识同一事物的不同属性值进行统一.
7.
1.
4对于不同系统的不同维度,创建维度的映射关系表,将其映射到标准化后的维度上.
7.
2数据格式在ODS层实施过程中,需要将各源系统的数据格式进行统一.
统一的数据格式示例如表5所示.
表5数据格式统一示例表格式类型统一格式示例日期yyyyMMdd,默认为1900010120151212时间HHmmss,默认为000000121314字符串去除头尾空格,去除回车,默认为NULLTrim('政务服务')整型默认为0(可根据具体业务类型调整),双精度默认保留4位小数位(可根据具体业务调整)7.
3文件组织方式7.
3.
1根据主题域的不同,在数据开发/手动任务中,分别建立相对应的文件层级目录,文件夹名称即为数据层级/主题域/数据库对象的描述信息,叶子节点为数据库对象的名称作为文件的名称,原则上数据开发与手动任务目录下的文件组织形式应保持一致.
文件组织方式如图2所示.
图2文件组织方式图7.
3.
2数据库对象的DDL语句,根据数据表的归属情况,在手动任务中,在相应的文件夹下创建DDL脚本.
7.
3.
3需要进行数据初始化的数据表,应在手动任务中,创建相应的SQL脚本文件.
DB3308/T050—201887.
3.
4正式的生产任务的名称与数据库对象名称一致.
7.
4数据接入应按《浙江政务服务网技术规范第二部分数据交换技术规范》与《浙江政务服务网技术规范第三部分数据交换信息规范》规定执行.
7.
5数据共享应按《浙江省公共数据共享交换技术规范(试行)》规定执行.
7.
6数据接口应按GB/T21062.
3的规定执行.
7.
7数据安全应按GB/T20270、GB/T20271、GB/T28452的规定执行.
7.
8数据备份应按GB/T29765的规定执行.