数据中心建设方案（简版）

技术建议书

企业数据中心系统平台

技术方案建议书

第1页共51页

技术建议书

i

技术建议书

第1章 总体建设方案

1.1 总体建设思路

图、数据中心构建思路图

按照对数据中心的理解，完整的数据中心应该具备IT基础设施（主机、存储、网络）、企业级ETL平台、数据存储中心、数据共享服务、应用层、统一门户、数据管控平台。

第2页共51页

技术建议书

1.2 功能框架

图、功能框架

系统功能框架分为企业级ETL平台、存储与计算中心、服务层、应用层、统一门户、统一平台管控。

企业级ETL平台：

负责企业数据中心数据采集、加工、汇总、分发的过程，完成企业级数据标准化、集中化，实现数据脉络化、关系化，实现统一的数据处理加工，包括：非实时数据处理和实时数据处理，提供数据抽取、数据转换、数据加载、数据汇总、数据分发、数据挖掘等能力。

存储与计算中心：

建立统一的数据中心数据模型，以及统一的数据存储与计算，具体提供关系数据库、分布式非关系数据库、分布式文件、分布式计算，实现统一的数据存储与计算。

数据共享服务：

第3页共51页

技术建议书

通过数据服务标准化开放访问，帮助企业IT建设中，应用和数据分离，引入更多的应用开发商，促进应用的百花齐放和应用的专业性；基于标准化接口，实现对标签、客户视图、指标等数据查询API封装，实现与周边系统实时互动，体现数据价值，减少数据冗余，保证数据安全，保证数据的一致性。

应用层：

应用层的应用使用服务层提供的各种数据服务。本期应用层包括：经分应用、流量运营、ESOP应用、VGOP应用、指标库、流量运营战略地图、掌上分析、自助业务分析、区域洞察、渠道运营、自助分析、客户标签库、实时营销、LTE互联网管控策略。

统一门户：

提供统一域名分配、负载均衡、鉴权管理、统一管控平台接入、应用注册、应用发布、应用访问数据信息等功能，同时提供数据中心被应用访问的频次，被应用访问的数据范围，提供数据资产的评估，为应用上下线和数据开放提供依据。

统一平台管控：

面向开发人员、运维人员实现数据、应用、资源的统一管控，包括：数据资产管控、开发管理、监控管理、调度管理、系统管理、安全管理。

1.3 技术架构

图、技术架构

第4页共51页

技术建议书

系统技术架构分为数据采集、计算存储服务、数据共享服务、平台管控。采用Hadoop云技术，可以满足计算能力线性扩展、多租户能力、数据汇总能力；批处理场景采取Hadoop的Map/Reduce、Hive或者Spark来完成；流式数据处理，采用Esper计算引擎实现。

数据采集：

采用Flume计算框架，实现文件和消息采集与解析；采用流式爬虫、中文分词、图片识别技术，实现互联网网页信息实时采集；采用FTP文件方式实现对数据文件的采集；采用Socket消息方式实现对消息数据的采集；采用sqoop方式实现将数据库数据装载到HDFS文件系统。

计算存储服务：

采用Hadoop中HDFS文件系统提供统一的大数据数据存储，满足全量数据留存；基于Yarn提供跨平台的资源管理，满足资源的统一调度与管理；采用Hadoop实现非实时ETL，实现海量数据的批处理，主要处理ODS层->DWD层->DW层->ST层的数据处理；视业务数据情况部分DW层->ST层的数据处理采用Spark计算框架实现；采用Esper和rabbitmq支撑流数据处理与复杂事件处理；利旧DB2提供ST层数据的存储与计算，支持高并发的指标级数据共享。

数据共享：

数据开放共享采用基于HTTP协议REST风格的OpenAPI完成同步处理与基于消息队列（MQ）完成异步处理，实现类SOA面向服务的架构体系。支持OAuth提供一个安全的、开放而又简易的授权协议。数据共享服务部署在集群环境中以应对高并发的访问请求，并实现集群的负载均衡。

统一平台管控：

采用Java EE技术，通过MVC模式（Model View Controller，是模型－视图－控制器）把业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。

第5页共51页

技术建议书

1.4 数据流图

Mc信令（实时）数据通过Socket消息适配模块接入至Esper计算引擎进行实时处理，向应用提供事件API服务，支撑实时营销应用；后期如Gn信令、LTE信令也提供实时数据，可满足基于Gn信令、LTE信令的实时处理。

除Mc信令（实时）数据外，Gn信令、Mc信令、自有业务订购与使用行为等数据通过

非实时ETL方式装载到Hadoop的HDFS文件系统，实现全量数据留存；由Hive承担主库的职能，实现海量数据的批处理，承载ODS->DWD->DW->ST各层数据处理，其中DW层部分数据提供给Spark，由Spark完成数据处理工作。

对外数据服务可以由不同种类的API来完成：

1、 针对诸如客户统一视图、客户标签库的数据探索查询服务：将数据加载到Spark的

RDD中，通过API将数据共享出去；

2、 针对诸如客户标签信息查询、客户详单查询类的数据查询服务（特点是通过一个Key

来查询数据）：将数据加载到Hbase中，通过API将数据共享出去；

3、 针对诸如指标数据查询、KPI数据查询服务（特点是高并发、多维度的数据查询）：

将数据加载到DB2数据库（利旧）中，通过API将数据共享出去； 4、 针对多租户的数据共享服务，详见5.3章节；

第6页共51页

技术建议书

第2章 企业ETL数据处理平台

2.1 功能框架

根据数据中心的建设需求，企业级的ETL平台实现统一的数据采集、转换、加载、处理以及统一调度、管控等功能。这里的ETL指的是广义的ETL，具备以下的特点：

? 统一数据获取接入，支持B域数据、M域数据、O域数据或其他外部数据统一接入

数据中心平台。

? 支持结构化和非结构化数据采集、加工；对非结构化数据要实现从非结构化到结构

化的处理过程。

? 支持数据采集、转换、加载等关键,.数据处理过程，实现企业数据的标准。 ? 从周期上，支持批量的数据采集，实时的数据采集

? 满足数据中心数据加工，处理以及对外提供数据分发、同步

? 支持全过程的数据稽核。包括事前、事中、事后的稽核方式。以及灵活的稽核规则

管理，算法管理

? 全过程的可视化开发配置管理。通过可视化的开发配置，测试和部署上线。

? 全过程元数据管理。重点要实现事前的元数据管理。管理的内容包括：支持数据模

型、数据流程、转换规则、数据关系和转换映射规则。

企业级的ETL平台产品DACP可以很好支持上述的关键功能特点。

第7页共51页

技术建议书

第3章 数据存储层

3.1 总体概述

Mc信令（实时）数据通过Socket消息适配模块接入至Esper计算引擎进行实时处理，向应用提供事件API服务，支撑实时营销应用；后期如Gn信令、LTE信令也提供实时数据，可满足基于Gn信令、LTE信令的实时处理。

除Mc信令（实时）数据外，Gn信令、Mc信令、自有业务订购与使用行为等数据通过

非实时ETL方式装载到Hadoop的HDFS文件系统，实现全量数据留存；由Hive承担主库的职能，实现海量数据的批处理，承载ODS->DWD->DW->ST各层数据处理，其中DW层部分数据提供给Spark，由Spark完成数据处理工作。

3.2 存储规划

ODS层 Hive 3+1月 Hbase 3+1月 db2 -- 第8页共51页

技术建议书

DWD层 DW层 ST层 客户标签/视图 指标 6+1月 12+1月 36月 3月 3+1月 -- -- -- 12+1月 -- -- -- 36月 -- 永久 3.3 模型设计

数据模型设计按照层次，主题的数据模型设计的思路。系统根据模型设计会自动转成hadoop上存储。层次、主题映射到相应的目录。

3.4 模型规范化管理

3.4.1 分层规范

依据数据仓库建模理论，结合实际经验，数据计算平台承载数据模型分为四层：ODS、DWD、DW和ST，即接口层、存储层、汇总层、应用层。

模型分层说明：

接口层：ODS模型的数据结构与业务系统接口文件结构保持一致，接口层的数

第9页共51页

技术建议书

据在数据计算平台进行暂存。

存储层：即明细数据层，是数据计算核心层数据模型之一，用于存放由清洗、转换层来的数据或者接口层直接来的数据，其设计目标是为后续的汇总数据层和信息子层提供数据基础。

汇总层：即轻度汇总数据层，也是数据计算核心层数据模型之一，该层实现对主题内的数据做轻量汇总。设计目标是为应用层提供足够灵活、方便的基础数据，并保证从该层获取数据是性能最优。

应用层：在汇总数据层之上，数据按照应用需求做数据聚合，生成相关应用所需数据的数据层。应用数据层是面向应用的，但是也不是每个应用都在应用数据层对应一个表，对应用要在数据应用层中进行整合。

3.4.2 表命名规范

OMG标准化组织建议，采用5分段的命名规范：如下

3.4.3 字段命名规范

建立字段的命名规范，并固化为domain类型，指导模型设计字段命名。当有变更，可以做到跨平台的统一建模。

第10页共51页

技术建议书

3.4.4 模型版本管理

第11页共51页

技术建议书

第4章 数据开放服务层

4.1 建设目标

? 通过数据服务标准化开放访问，帮助企业IT建设中，应用和数据分离，引入更多

的应用开发商，促进应用的百花齐放和应用的专业性。

? 基于标准化接口，实现对标签、客户视图、指标等数据查询API封装，实现与周

边系统实时互动，体现数据价值，减少数据冗余，保证数据安全，保证数据的一致性。

? 对于详单级数据，支持通过文件或授权的方式共享给周边系统。

? 通过统一的技术平台框架，制定企业数据标准体系规范，基础数据采集处理，加工

汇总，可以引入多家厂商或多租户进行标准化开发。 要实现上述目标，需要解决的关键问题： 1） 需要什么样平台功能？ 2） 开放的对象。给谁开放？

3） 开放什么内容。包含两部分，基础数据的集成开发的开放和应用访问层数据开放。 4） 开放的安全保障机制

5） 如何保证开放对象开发提交的结果的规范化、质量。 6） 开放平台运营的组织结构和流程制度。

4.2 概述

要满足建设目标的要求，数据服务开放的整个功能框架如下：

第12页共51页

技术建议书

4.2.1 开放对象

示例说明如下 开放对象 多租户 说明 通过授权的机制，给租户开放通过sql查询数据能力，租户可以在此基础上汇总加工自己私有的数据 使用形式 SQL，进行数据处理 相关数据 在保障数据安全性、数据可控性的前提下，将Hive仓库的ODS、DWD、DW各层的开放授权给数据处理开放给租户。 客户视图，汇总模型等 指标类数据 信令位置信息等 ESOP，VGOP 手机经分 实时营销 通过文件接口将数据分发给对端系统，满足其数据分析需求 通过在线同步API调用的方式获取数据 客户端通过事件注册的方式监听服务接口，当服务满足触发条件是主动通知监听客户端 文件 开放API 消息服务 4.2.2 开放共享方式

共享方式 文件接口 说明 数据中心将数据主动导出文件，发送给数据需求方 通过API查询获取结果数据，即查即用，不落地。按查询数据对象粒度分为三 应用场景示例 1、boss的互动接口 2、即席查询临时周期性生成数据 开放API 第13页共51页

技术建议书

类： 1）ST表查询 1、通过对发布的数据模型发起LSQL进行查询获取数据 2、如手机经分查询指标，原来是通过接口表导入数据，可以通过API来查询数据 API 定期数据同步。如将用户行为汇总数据定期同步到经营分析系统 2）指标类查询 3）单用户清单信息查询 将数据中心的数据分发到目标数据库。数据分发 需求方提出申请审批通过后，系统通过分发平台定期将数据分发到目标库 业务分析人员通过封装好的数据模型即席查询 和提供在线即席查询分析工具，进行查询分析获取数据 临时统计，临时取数 适合于系统之间的实时协助，如用户事件信消息服务 通过消息传递数据。 息。需求方作为消息的消费者，同时传递消息事件和内容 4.3 多租户管理

4.3.1 概述

采用多租户的思路，将数据能力和数据平台数据处理能力按需、可控的进行开放，在保障数据安全性、数据可控性的前提下，通过标准化封装的数据操作，可视化开发工具开放给业务运营部门，由其自行进行数据操作开发。

使用企业级数据中心提供统一开发平台来实现多租户数据开发，其功能结构如下图：

第14页共51页

技术建议书

系统包括两部分：开发管控和技术平台。通过这两部分互相配合实现系统开发能力的开放。

这种模式下需要解决的关键问题包括如下：如何进行资源控制，数据权限管理，跨系统之间的数据交互，自动调度运行，元数据管理。

4.3.2 角色功能

系统管理员：对开发团队进行管理，数据权限和系统资源的分配、审批。 1、设置开发团队使用资源和账号

2、对开发团队提出的数据权限申请进行审批授权

3、表的敏感级别和敏感字段。不同团队对同一数据安全级别可以不一样

4、对开发团队上线进行审批。检查性能，开发规范的满足情况，调度申请周期是否合理

5、对开发团队数据导出安全进行审计

租户开发：使用统一的技术架构和开发工具，在可以使用的数据的基础，加工出私有数据

1、查看详细的数据结构

2、新申请数据权限，如果需要新的数据，可以进行申请，由管理员审批后就可以使用 3、数据加工开发，进行数据汇总、关联查询，数据导出等类型数据数据加工开发 4、临时上线、正式上线。

5、对其所开发的程序数据运行情况监控。

4.3.3 统一开发平台技术详解

4.3.3.1 租户用户管理

? 租户与系统用户映射

通过映射开发管理平台帐号及执行平台帐号，以租户的方式实现用户及用户组管理，以达到资源管控及数据权限控制的目的。

如下图,在管控平台进行开发团队的管理和对应账号的设置，在数据平台完成对租户的资源、权限进行控制。

第15页共51页

技术建议书

每个开发团队根据需要指定其在hadoop或关系数据库上的执行账号。在数据平台上实现账号的权限、资源的控制。

在查询或运行某个数据处理任务时，用其对应的账号进行执行。从而实现对开发团队开发运行的任务资源、权限的控制。

在管理平台新建租户的账号或数据权限变更时，管理平台根据配置参数，实时调用OCDC的相关API自动进行授权、修改、创建账号。

4.3.3.2 系统计算资源分配控制

在管控平台统一对租户进行计算资源的分配，分配完的参数部署到hadoop或关系数据库，实现控制。

实现资源控制，包括两部分：hadoop上的资源分配和关系数据库的资源分配（DB2）。

? Hadoop计算资源控制

要实现计算资源的控制，hadoop需要OCHadoop3.2以上，安装安全组件（sentry） 计算资源控制原理

资源池跟系统的账号相关。一个系统账号只能属于一个资源池，YARN支持采用资源池方式对系统用户进行CPU，内存的运行控制。

资源池控制参数：

独占资源：最小分配的资源。系统确保此用户有最小的资源。 共享资源：系统空闲时可以使用的最大资源 其中单位：虚拟的cpu核和内存单位。

如何设置租户的资源参数，是一个需要不断根据运行情况进行优化的过程。

注：Spark同hadoop的资源管理

第16页共51页

技术建议书

? DB2资源控制

要实现DB2的资源控制，要求：DB2 9.5 版本。目前db2的版本已经满足，需要开通WLM的生效参数。

在DB29.5版本推出了工作负载管理WLM(参考附录，不用额外收费),但只能限制CPU数量。控制参数如下：

参数名 min softmax 说明 分配给某个服务类的最小资源百分比。缺省值为 0。 在有冲突的情况下（这里可以理解为资源紧张时），服务类可获得的最少资源比例。在没有冲突的情况下，服务类可获得的资源可以超过该值设定的比例。缺省值 100 在没有冲突的情况下，服务类可获得的最大资源比例。缺省值为 100 hardmax 4.3.3.3 系统存储资源分配

Hadoop存储资源控制，每个租户独立一个文件跟目录，设置文件目录大小； db2的存储资源控制，对每个租户独立一个表空间，设置表空间大小；

说明：hadoop存储控制采用的是操作系统的目录大小的控制。缺陷是无法高度自动共享可用空间。即一个目录大小分配出去之后，意味其就占有了这个空间。因此一般做法是由小到大慢慢分配空间。

4.3.3.4 数据权限分配与控制

在开发管理平台进行对数据权限的分配。根据分配的结果在数据平台进行授权、回收等操作。

数据权限的控制包括：表级权限控制和字段级的权限控制：

? 表级权限分配：系统根据分配的结果，产生授权或权限回收的脚本到db2，hadoop

进行执行完成权限控制。

注：在管理平台分配的是逻辑模板表，数据平台控制的是实际的表。因此有一个模块专门按模板表的权限规则转换为物理表的授权脚本执行。

? 字段级权限分配：在表级授权的基础上，对表的字段的权限进行授权分配。由于目

前db2，hadoop不能直接实现对字段级的权限控制。所以我们采用两种方式实现这个功能：

方式1：建立视图，过滤掉没有权限的字段，然后将视图授权给相关账号。实现字

第17页共51页

技术建议书

段级的权限控制。

方式2：通过应用级的控制。通过开发人员编写的sql语句解析，分析其查询中所用到的字段，如果字段超出权限范围，则给出提示，不允许执行。 资源控制手段列表：

控制项目 表级权限 字段级权限 资源-CPU 资源-内存 资源-存储 db2 通过db2的权限管理，通过脚本实现数据权限的分配 通过视图 通过wlm进行设置 无法实现 每个租户独立一个表空间，设置表空间大小 每个租户在数据主机上建立文件目录，存放源代码，可执行程序 hadoop 通过kerbors的权限管理，通过脚本实现数据权限的分配 通过视图 通过YARN资源池进行控制 通过YARN资源池进行控制 每个租户独立一个文件跟目录，设置文件目录大小 每个租户在数据主机上建立文件目录，存放源代码，可执行程序 系统文件目录 4.3.3.5 租户的数据开发过程

1. 查看数据字典

开发人员可以查看到所有的数据字典。查看内容包括数据表名，中文名称，描述信息，存储位置、数据结构。通过调用基础平台的元数据实现数据字典查看。

2. 开发界面

通过开发平台配置数据处理流程，可支持库内与库外、云平台与关系数据库的混搭数据处理，示例如下：

上述的处理流程实现：在hadoop上对ods_cdr通过sql脚本汇总dw_cdr，再通过数据分发到db2上的dw_cdr_yyyymmdd表上。

开发人员需要对输出表dw_cdr设置表结构，sql处理汇总处编写sql脚本。

在一个处理的任务流程中，节点包括数据节点，数据函数节点拼接起来的一个处理流程。 其中数据处理函数节点包括：Sql，tcl，java，shell，数据分发，数据加载，数据导出，ftp、创建表，删除表等。

第18页共51页

技术建议书

3. 测试

在界面上可以立即执行某个节点或整个处理流程，执行过程和日志信息会实时输出到前台界面进行查看。如下示意图：

4. 上线

开发人员在界面上直接提交上线。包括临时上线和正式上线两种。临时上线需要开发人员填写生效的开始日期，结束日期，调度周期。

正式上线，系统管理管理员会进行审批。审批的项目包括：程序名称，表名是否规范，字段名称和中文信息是否完整。

在上线时，系统会自动将程序代码、数据结构从开发环境的配置信息部署到生产环境下。 5. 运行

程序上线后，调度平台就会根据程序数据依赖关系自动进行调度。

如果是临时上线的只有调度运行在有效期内的程序才会被调度执行。程序开发人员可以申请延长有效期或申请固定上线。

4.3.3.6 调度执行

多租户调度使用平台提供的统一调度功能，实现过程如下：

第19页共51页

技术建议书

1. 调度运行

依据输入表关系，根据数据关系实现正确调度依赖运行。对租户的临时程序调度时，只会调度在有效期的程序才会调度。

2. SQL脚本执行

开发人员开发好的SQL脚本，可以到多个数据平台上运行，系统需要进行正确选择投入到相应的数据平台运行。

a) 开发人员可以指定节点运行的数据库，如下图

b) 系统会对开发人员的编写的sql进行解析，获取其依赖的输入表和输出表。再

跟元数据进行对比自动选择相应数据库。选择策略如下：

所有输入表都在同一个库 输入表分布在两个库 如果涉及到的表涉及到两个库都存在 则选择那个库 系统给出错误提示。建议其采用数据同步再进行开发。 如果有关联表，则跟着关联表同个库，否则优先选择大数据平台。 3. 跨数据平台命令的运行

比如：如何实现在hadoop平台执行汇总数据，导入到db2，在进行汇总。

Server端在读取这个一个处理任务时，将命令发送汇总命令给hadoop Agent执行，然后在发送命令给hadoop Agent进行分发到db2，然后在发送命令给db2 agent进行数据处理。

第20页共51页

技术建议书

第5章 应用开发与部署

5.1 应用开发流程

应用层的所有业务应用具备与底层数据松耦合特性，通过接口层提供的各种数据接口，向业务人员或第三方厂商提供开放API服务。根据不同的应用场景，通过对相应的API进行选择和组合，从而快速生成所需要的业务应用，以满足对应用的快速开发、部署、上线的能力。

对于应用的开发可通过两种方式进行实现：

1、 数据中心平台内应用开发：通过数据中心提供的应用开发平台直接进行应用开发，

开发平台提供高效的可视化开发界面，包括对各类API可以追根溯源，展现详细API元数据信息等。同时对应用设计、应用开发、应用测试、应用上线、应用下线进行全流程、全生命周期的开发管控。此类开发场景主要适用于不具备硬件资源的用户（如业务部门开发人员）进行应用开发。

2、 数据中心平台外应用开发：通过Http协议数据服务接口，直接调用数据中心服务

层中的各类API服务，通过开发编写相应的计算过程形成对应的业务应用。此类开发场景主要适用于具备硬件资源（如第三方厂商）的用户进行应用开发。

5.2 应用部署建议

本期从外部系统接入8类数据源，所有清单数据在企业数据中心进行基础汇总，提供数据、存储和API接口服务能力，供14类应用调用。

第21页共51页

技术建议书

标签库应用：所有标签数据计算、存储在数据中心，标签结果数据在HIVE和HBASE分别存储一份数据，HIVE上存储的数据通过Spark的RDD对外提供“根据标签查用户群”API，HBASE上存储的数据对外提供“根据号码查标签信息”API。

指标库：所有指标计算、存储在数据中心，结果数据存储在RDB，通过“KPI查询”API对外提供服务。

掌上经分应用支撑：掌上经分需要的KPI由经分提供，改为由数据中心“KPI查询”API提供。

实时营销支撑：将MC位置信令事件集成到数据中心，由数据中心提供消息事件给实时营销平台。

LTE互联网管控策略（PCC）、自有业务分析平台、区域价值洞察：对于这些规划中的系统，建议采用多租户的方式，在企业数据中心完成数据处理和存储都在数据中心，应用通过调用API获取数据。

经分系统一经接口、MIS接口、财务报表、ESOP、VGOP、战略地图、渠道运营平台、所需的数据源，统一由数据中心将DWD、DW层数据分发文件给各系统，由应用系统自行进行数据加工及展现。

经分其他应用（除去一经接口、MIS接口、财务报表）：数据处理和存储都在数据中心，ST层数据保存在db2。

第22页共51页

技术建议书

第6章 统一门户

6.1 概述

企业数据中心统一门户的建设是为了降低系统使用人员访问数据中心的难度，提高系统的易用性，并且实现数据中心的资源有机整合和统筹管理。

1. 数据开放服务门户：对于数据开放服务提供开发者门户，含有数据服务授权申请、

开发者帮助文档、服务注册、创建、注销等。

2. 管控平台门户：对整个数据中心管控平台使用者门户，系统管理、运维调度、质量

监控等。

3. 应用使用门户：对于应用使用者的门户，支持多租户应用、第三方应用的集成统一

呈现。

6.2 门户功能框架

统一门户功能框架如下图所示

门户功能框架包括门户接入、门户功能两部分；通过功能适配到角色工作台形成不同的角色视图。

? 门户接入：主要负责企业数据中心用户访问渠道的接入管理；接入应用的日志管理、

负载均衡与访问授权。

? 门户功能：包括角色工作台、认证管理、权限管理、用户管理、流程审批、数据开

发、应用开发、数据授权、运维监控、多租户管理等界面。

第23页共51页

技术建议书

第7章 管控平台

7.1 概述

7.2 元数据管理

7.2.1 功能框架

元数据管理是需要将各系统的信息、设计工具信息、生产平台信息，进行收集管理，统

一管理。提供一个视图，以帮助使用人员了解系统的数据分布、数据关系、业务规则、指标口径等。元数据包括：系统类元数据、技术类元数、管理类元数据。

总体功能框架图

第24页共51页

技术建议书

针对数据中心的要求，元数据管理需要具备的关键的特性如下： 1） 要求提供标准化的应用开发工具，满足在不同平台上的开发需求 2） 100%的ETL开发、数据模型开发、应用开发能基于开发工具实现

3） 95%以上的元数据能自动采集、解析与管理，元数据的范围包括但不局限于数据结构、数

据词典、字段维度、程序映射逻辑、数据生命周期等 4） 多租户的统一元数据管理

7.2.2 基于元数据的应用开发工具

提供统一的应用开发工具，完成高效应用的开发，并可以自动完成应用元数据的采集。提供诸如数据展示包括报表工具，仪表盘分析等工具如 1、 支持常见的各种报表样式

2、 支持常见各种分析图，同时支持图表组合分析

3、 支持各种数据源方式

第25页共51页

技术建议书

支持oracle，db2,mysql等常见的关系型数据库 支持gp，gbase等mpp数据库

支持hdfs，hbase等大数据平台提供数据 支持webservice获取数据

7.2.3 基于元数据的数据开发工具

采用元数据驱动(MDA)设计理念，去规划元数据对象的创建、运行、评估、维护各环节节。屏蔽大数据平台差异性，统一模型设计、统一程序开发，将元数据融入到开发各个环节，利于管理。

? 数据模型设计

支持IDE数据模型设计，同时支持模型设计工具power design、Erwin批量导入功能。 提供数据周期、数据表级字段级铭感设置、字段口径定义。

? 数据流程设计

设计程序输入表和输出表的元数据信息。 ? 程序开发

根据设计的内容转换成开发内容。开发人员就可以在此基础上进行开发。 提供各个接入平台统一封装函数，降低开发难度

? 数据质量控制

1.常规检查。包括及时性，运行状态，运行时长，处理记录数等进行常规检查。 2.对程序日志进行稽核。包括单步的处理时长，记录数的波动等

3.对程序的目标表启动检查。检查目标的统计指标值，关键字段维度、层次间数据的一致性进行检查

? 提供程序界面测试功能

对开发内容进行测试和调优，检查质量规范，性能，质量是否满足期望 发布应用到正式运行环境

元数据收集存储： ? 程序的基本信息。包括程序的名称，中文名称，备注，周期，层次，主题，创建人，

开发人员

? 程序的处理步骤信息。包括程序步骤编号，调用函数，执行脚本 ? 程序输入输出关系。输入模型，输出模型 程序的字段映射规则。输入模型到输出模型的转换规则

第26页共51页

技术建议书

7.2.3.1 数据流设计

设计数据模型，设置数据存储周期，敏感级别，数据模型数据流设计，支持模型字段映射关系设计

1. 数据流程设计

设计程序输入表和输出表.输入表可以是文件，也可以是远程数据库上的某个表。目标表可以是文件也可以是远程目标数据库上的表。

2. 数据模型设计

对输入表和输出表，进行表结构的设计。包括表的基本信息，存储信息和表的关系。根据不同的存储类别，会有设计参数上的差异。

3. 转换映射规则设计

根据表的关系和表模型信息，进行转换映射。映射规则包括合并，拆分，规则转换，函数转换等常见的操作

第27页共51页

技术建议书

7.2.3.2 可视化程序开发

? 统一封装的函数库，屏蔽底层差异性，通过类sql编写，或函数调度，实现跨平台统一

开发。根据数据仓库处理过程抽象出5大类通用函数库，统一调用参数接口，开发人员针对不同不平台实现无差异的开发。如将某类数据文件加载到数据库中，开发人员只要指定数据文件路径和目标表。系统执行时如果是要入库到DB2调用DB2的命令，如果是Hadoop平台，调用Hadoop的命令。

? 通过可视化的流程界面，拖拽方式实现对函数的编排，对每个节点函数编写参数，实现

数据加工功能。降低开发难度。开发时候，对函数进行编排，填写节点函数参数。实现一个具体的数据处理过程

第28页共51页

技术建议书

? 支持多种脚本开发，提供基于web脚本开发工具编写如tcl、python开发程序；能够从

开发的脚本中自动解析建立元数据：输入表和输出表的关系；脚本类的开发工具，集成了开发，测试，上线集成操作。同时将函数库，数据模型统一进行集成；

7.2.4 关键技术说明

7.2.4.1 前向元数据管理

1、在开发过程中通过IDE工具产生结构化的元数据信息。

第29页共51页

技术建议书

2、在上线时，对元数据内容进行稽核检查，保证元数据信息的完整性，合理性。通过统一的上线作为管理的控制点。每个团队提交要上线的内容，存到统一元数据库进行标准化检查稽核。

上线时检查的内容：程序需要提交的内容：程序本身的信息和程序输出表的信息。

第30页共51页

技术建议书

7.2.4.2 多租户的元数据管理

? 每个开发团队输出到不同的开发目录。内容包括现有的数据字典、业务口径、程序代码等。

这些输出到同一的元数据中心，进行统一的标准化和规范化检查

? 统一的标准与规范，统制定基本的规范和标准，不管哪个开发小组开发的内容必须满足这

些基本的标准。

7.3 流程管理

通过流程管理实现对数据处理过程的统一管控，并提供一系列工具实现数据处理过程可

视化、可管控，它包括对系统资源、软件资源、业务应用、参与人员等各种资源统一管理，综合监控平台，随时重现大数据环境中各个组成部分相互依赖,为各级IT管理人员提供从资源规划、资源收集、性能分析、故障定位与处理、统计分析、知识沉淀与管理过程的支持

7.3.1 流程引擎

流程管理集成自有轻量型流程引擎来完成各类流程快速配置开发。功能如下：

1、流程的建模和实现

在流程定义、执行、管理控制等阶段，业务和IT人员的高度一致 流程运行，以及整体性能查看和监控可视化 提供灵活的手段实现流程的修改和演进

支持流程模式以及部门协同，支持流程中的附件添加和查看

自带的业务规则和决策表支持分支选择，路由到特定用户、用户组、角色、投票规

第31页共51页

技术建议书

则、例外和事件处理、服务水平监控规则等 2、流程仿真、优化和分析 3、 开发管控、版本控制 4、 流程评估和监控分析

7.4 作业任务管理

通过元数据获取作业输入表作为作业启动的前置条件 1、通过数据流程设计来确定数据关系 2、人工进行修改作业输入、输出 3、支持手工设置前置作业

作业任务资源占用类型评估

采集程序的历史运行时长，处理记录数等关键指标，支持系统自动测算和人工指定，对程序的资源占用类型分为三类：

1、高：运行时长特别长，处理记录数比较多

2、中：处理记录数相对较小，处理步骤多，时间较长。 3、低：运行时间很短的程序 作业任务静态优先级

按照应用的重要性，根据血缘分析，寻找路径上的所有处理任务。 1、重要越高的应用，其路径上的节点的任务优先级越高。 2、人工进行修改维护

第32页共51页

技术建议书

7.5 数据管理

7.5.1 数据生命周期管理

7.5.1.1 上线

不管通过什么方式完成开发，上线必须保证数据的相关的信息完整性，合理性。由数据管理员负责对上线要素信息的检查。保证在上线时信息要素被正确保存，以作为后续使用。 ? 上线检查基本信息要素

权限信息要素：

存储信息要素：

数据关系要素：

? 表的基本信息检查

第33页共51页

技术建议书

? 表结构

? 表存储信息设置

第34页共51页

技术建议书

? 系统规范性自动检测

7.5.1.2 数据监控

7.5.1.2.1 存储策略情况

检查表的实际存储情况和规划存储周期情况进行对比，发现规划与实际的差距，查找原因。为下期扩容做准备。

7.5.1.2.2 安全漏洞检测

安全策略管理：对数据加密的密钥管理，敏感数据定义，账号权限，离线数据终端的注册等。

安全策略检测：对安全策略是否实施到位进行自动检测。如敏感信息是否有加密，账号的权限是否超出范围。

第35页共51页

技术建议书

安全审计监控：对数据所有的使用日志进行审计，是否涉及到敏感数据非法使用。

7.5.1.2.3 存储空间监控

检查文件空间，表空间等信息是否满足生产的要求。

7.5.1.3 数据评估

7.5.1.3.1 数据价值评估

功能说明：对数据价值成本进行评估，对数据存储、处理、应用进行优化。 评估算法： 科目 前台应用使用次数 支持kpi，指标统计的个数 分发给外部系统接口可数据 价值 外部应用调用次数 存储成本 计算成本 开发成本 运维成本 成本项目 管理成本分摊 应用场景:

分摊方法 应用的点击次数平均分摊给应用链路上的所有表 KPI应用次数平均分摊给KPI的统计表链路上的所有表 (分发给外部表，平均分摊给分发接口表链路上的所有表)*加权系数 (外部应用调用表次数平均分摊给应用表链路上的所有表)*加权系数 表的大小*(存储扩容的投资总额/总空间大小) 处理表数据总时长*(主机扩容的投资总额/所有程序的运行总时长) 表的字段数*(每年新业务开发费用/表的总字段数据) 维护费用/表的总数 管理总成本/表的总数 第36页共51页

技术建议书

7.5.1.3.2 数据重要性评估

从表的在数据使用过程中和数据应用中对表的重要性进行评估，输出表重要性级别。

7.5.1.3.3 存储周期评估

包括存储规则的配置示例如下：

数据内容 集团建议数据保存周期 第37页共51页

技术建议书

用户资料及接触记录 在线存储：三年 近线存储：永久保存（Hadoop Erasure Code) 在线存储：一年 近线存储：三年（Hadoop Erasure Code) 在线存储：一个月 近线存储：六个月（Hadoop Erasure Code) 在线存储：永久保存 各类话单 信令和日志 各类汇总数据

存储周期的计算，计算表到期时间。如果到期了，则这个表可以进行删除或转储。

7.5.1.3.4 时效性评估

通过对数据关系的分析，发现孤立表或无效表。

根据表名判断此表大约含义，建表日期、状态日期，表内数据时间等判断此表最后更新时间。

第38页共51页

技术建议书

通过数据的使用日志，对孤立表和无效表进行判断是否有使用

如果满足以上3点，就可以判断此表无使用和处理.就可以进行下线处理。

7.5.1.3.5 冗余数据评估

系统中存在着大量的冗余的数据。比如从清单上的进行汇总的表就非常多，这些汇总表中有些存在相识性，这就造成了大量的冗余数据，这些大量的冗余数据，一方面给数据的精确性和可靠性将带来影响，同时也影响着数据库的性能。

要解决这个问题有两个环节：发现冗余数据和冗余进行消除合并。

输入分析的起始表表名，业务主键查找分析起始表的后续所有表计算表的粒度层级计算表的相关性判断表是否冗余和可合并的记录冗余表信息输出冗余表和合并建议 7.5.1.3.6 数据关系评估

数据关系的类别可以分为以下几种：

? 主外键关系。由上线时进行登记。

? 参考关系。主要描述实体表与维度表的关系。在上线时登记。 ? 输入与输出。通过元数据解析建立。 ? 历史拍照。通过处理程序解析发现建立。

? 冗余备份。从目的可以划分为：分工提速、转储优化、应用分流、数据

统计临时备份。

系统根据以上的关系类别，通过相识表的发现分析，自动建立数据之间的关系。

7.5.1.4 数据优化

7.5.1.4.1 优化策略

类别 条件 1、表满足存储评估的到期条件 2、同时满足数据在各个已经同步到位 1、满足时效性分析发现的无效表

优化策略 执行策略 下线清理 下线清理

清理或转储 清理 自动执行 人工确认 第39页共51页

技术建议书

转存高端设备或内存数据 数据合并 优化抽取策略 性能优化 冗余消除 冗余字段 1、发现高查询使用的表 1、发现相似表或冗余表 1、发现抽取过多的字段但没有使用到 人工确认 人工确认 人工确认 7.5.1.4.2 优化执行

多系统协同生命周期管理：可以制定在不同的库不同存储策略,如最近数据和历史数据分布策略；

自动管理与手工管理：支持系统自动管理，自动清理，同时对一些重点的表进行手工审批管理；

7.5.1.5 数据下线

对满足下线的表的进行数据下线。

7.5.1.5.1 预下线

为了安全起见，对重要的表、不确定的冗余表等，可以先预下线，再下线。 将表的权限都收回，确保所有的使用者都无法使用此表。 标识此表状态为：预下线状态。

过了预下线期限后，就可以执行下线的操作了。

如果此期间，有人提出需要此表，就可以进行回退，恢复权限配置、状态。

7.5.1.5.2 下线分析

对下线的表，删除表，同时需要清理数据、程序。

系统根据元数据信息自动分析给出，此表的独有程序和输入表。这些表和程序就是要下线的内容。

第40页共51页

技术建议书

7.5.1.5.3 下线

根据这些表独有的程序和输入表，从后台调度系统停止移除相关的程序，清理的独有表的数据。完成下线工作。

7.5.2 数据质量管理

数据质量管理的总体目标：常态化、体系化、标准化、自动化的全面数据质量管理，以达到数据质量控制的全面性、可控性、可度量性、可迅速定位和有效解决。通过流程制度建设、质量评估体系建设、质量检测IT平台建设实现TDQM(Total Data Quality Manage)，即企业级全面数据质量管理。

提供数据质量稽核规则统一配置，并支持对质量规则的定义和任意节点的附加。

根据时间发生的顺序，可分为事前质量检查、事中运行监控、事后归纳总结，并能对各

过程中所产生事件及信息形成告警信息，通过短信、彩信、邮件的形式进行发送。

从上表格中可以看出在经分的日常生产中产生的问题大部分都可以上线前的严格控制来避免，这说明了数据质量的重要性。

第41页共51页

技术建议书

7.5.2.1 质量规则定义

支持质量规则的增、删、改、查操作。支持定义元数据对象的质量规则，如接口质量规则，程序质量规则，数据模型质量规则，指标质量规则，报表质量规则。

稽核对象模板配置是会对需要稽核对象的基本信息，包括稽核对象的基础实体配置，稽核所需要的数据实体，对象的稽核结果汇总及详细信息。

7.5.2.2 质量规则附加

支持将质量规则根据相关性附加到各个节点，分别进行不同类别的质量规则检查。

第42页共51页

技术建议书

在点击编辑后编辑规则的详细配置，平台提供十多种的检查函数 函数名称 变量定义 数组比较 脚本规则 字符串比较 函数说明 增加变量定义,如增加sql变量,在引用是$tabinfo.dataname 比较单列数组是否一样 如：1000<=新增用户数<100000;如果指标计算结果为0,则告警。 如：是否通过SQL解析建立映射关系;检查是否存在没有与任何数据处理过程建立数据处理关系的数据实体 跨库字符串比较 非空检查 数值比较 跨库数值比较 值域检查 时间比较 数组属性对比 选择某个参数，此参数不能为空 选择数值进行比较，比较参数可以是sql语句，也可以是常量或变量 进行多库之间的数值比较 判断某个值是否在指定范围之内 判断某个时间是否在指定时间之前,每日7:30,每月3日5:00之前,5:00,M3 取数组中某个时间的所有属性值跟指定时间的所有属性值进行对比,先要确保数组定义中包含时间字段和对比时间的数据 数组维度波动对比 数组分量与总量波动对比 相关性比较 相关性对比，取相关对象的指标值范围波动检查 取数组中某个时间的所有属性值跟指定时间的所有属性值进行对比,先要确保数组定义中包含时间字段和对比时间的数据 总体波动与成员波动的允许范围 满足约定条件，得到预订的结果,注意：else没有条件时写成{} 第43页共51页

技术建议书

静态表属性变动检查 静态表属性波动检查 SQL脚本 按SQL语句返回检查结果，如果结果集为空则检查通过，否则不通过 检查成员自身的波动率范围 检查新增或减少的成员或当新增或减少的成员占比大于指定范围时告警

7.5.2.3 事前质量检查

上线前检查

在开发阶段定义好各元数据对象的质量规则，在上线时，调用检查规则对上线的指标进行检查是否满足质量的规则，在一开始规避一些常见的错误。

源系统变更检查

A、表结构变更监控：

对表中字段的变更、增加、删除时产生的变化进行监控（如BOSS上线对表进行了修改）。能够跟接口程序结合起来，当字段变更时，能够判断出对应接口的对应接口号和对应接口文件哪个字段发生了变更。

第44页共51页

技术建议书

B、字段维值监控：

字段维值主要将一个表的某个字段的不同值的数量和值的大小与之前的快照进行对比，可发现值的数目或者值的大小的变化情况。

C、业务规则监控：

检查逻辑上的合理性，如成为大客户时间必须晚于开户时间，状态在用的号码必须是唯一的。

7.5.2.4 事中运行监控

运行过程监控：

对运行过程的对象设置质量规则，在运行过程中及时调用这些规则对运行结果第一时间进行稽核，以及时发现问题。

发现问题后，及时展示监控到的当前告警信息，并将错误信息发送至告警集中管理。 可以对告警进行定位分析、相似问题分析、转问题单或解除（误报的告警信息）。 业务指标监控

将指标的管理进行集中化、标准化、管理体系化和检查自动化。

1）指标界面监控框架分级：支持将指标的监控展示框架分为四级框架 L0：总体状况 L1：详细列表 L2：告警点明细 L3：告警点表现

2）表现形式分类：不同类型的最优表现形式，以求明确表现出检测的内容问题所在

如提供如下形式：基本数值和规则检查、指标趋势波动分析、指标对比检查分析、成员占比变化异常分析、指标相关性检查分析、维度成员排名变化异常分析等。

稽核结果展示

根据稽核对象模板配置展示展现稽核结果：

第45页共51页

技术建议书

问题定位处理

支持针对一个有问题的指标，利用元数据的血缘分析寻找出指标处理路径上的程序、接口节点，在根据每个处理过程节点的质量监控检测,发现有问题的处理环节，以帮助快速定位，能帮助运维人员快速处理。

7.5.2.5 事后归纳总结

1）支持质量知识库中知识条目的增、删、改、查操作。

2）支持将生产系统运行过程产生的问题、人员报告数据质量问题、维护发现的问题、用户投诉报障的问题经过处理过程转到知识库，对问题的原因和解决方法进行分类，便于将来人员学习参考。

3）支持按周期形成质量分析报告，包括由变更引起的质量问题和影响，以及问题处理的情况等内容。

4）支持针对数据完整性、数据唯一性、数据合法性、编码检查、统计口径形成数据源

第46页共51页

技术建议书

质量评估报告。

5）支持跨系统数据一致性进行比较核对。核对方法包括：指标核对、总量核对和分量核对，核对的目标可以对一致性进行检查，也可以找出问题发生的源头。

7.6 监控管理

监控管理提供设备、平台、业务层面全方位的监控能力，提供故障的及时发现、及时告警能力及优化诊断能力，通过对告警、性能数据的集中采集、处理和展现，实现对基础设施的综合监视；支持对集群各节点的存储和计算资源进行可视化展现，如机架、网络拓扑图、网段、服务器配置等；支持对集群各节点资源使用情况进行可视化展现，如数据块数、Job的运行数目、节点健康状态，支持周期性健康状况巡检。支持将产生的告警通过邮件或短信的方式通知给运维人员，也支持将监控生成的监控数据和监控告警通过系统间接口提供给外部系统。

通过采集各系统性能信息、应用模块日志信息实现监控信息实时的汇聚、评估、展示和告警提示。对于系统运行的异常表现进行预警，能够实时产生趋势性能分析报告、统计报告、TOP-N报告和历史报告，为优化系统性能和解决故障提供分析依据。监控指标项如下：

7.6.1 运行监控

通过下图查看数据在不同平台，以及层次、主题上的数据分布

第47页共51页

技术建议书

7.6.2 关键指标监控

1) 采集方式

支持多种方式的信息采集。包括通过Agent、数据查询、日志监控、消息服务等多种方式进行实时的信息采集。 2) 采集内容

各类IT 资源的配置数据、性能数据、告警数据进行采集，自动地将服务器、网络设备、应用系统等基本配置信息自动导入管控平台中，确保配置管理系统中的数据与实际生产环境一致，为支持IT服务流程管理以及IT信息资产管理提供基础信息服务提供保障 3) 稽核与评估

系统预定义了多种稽核算法，同时也支持自定义的稽核算法 检查方法 数值检查 检查描述 适用场景 指标数值与阈值上下限的比较,阈值可以手工录入经验值主要适用变化趋势平或采用n个周期内指标的最大最小值作为阈值的上下限，稳的业务关键指标 需要考虑周末和节假日对指标的影响等 波动检查包括同比波动检查和环比波动检查，先计算指标的同比或环比波动率，然后与预定的波动率上下限（阈值）如业务发展类指标、用进行比较，阈值可以手工录入经验值或采用n个周期内指户数类指标等 标的最大最小值作为阈值的上下限，需要考虑周末和节假日对指标的影响等 波动检查 需要进行相关性检查通过对若干个指标值的简单四则运算（加、减、乘、除），平衡性检查 的指标，如日指标汇总来检验各个指标间潜在的平衡或其他比较关系 与月指标的平衡检查 加权波动检查 通过对单个指标的基础检查结果和影响因素的加权计算分析，综合检查指标的波动和变化情况 定义相关性指标,和指标相关系数,如正强相关，负相关,定义两个指标当前值是否满足相关性的特点 主要用于考察多个指标之间的逻辑关系是否符合规律,如量收匹配的问题 如用户数在boss的值，在仓库底层的值,在应用汇总表值，在前台应关联性检查 一致性检查 计算一个指标在不同的采集计算点的值是否一致 第48页共51页

技术建议书

用1，应用2中的值是否一致 直接对某个值进行评判或是否在允许的取值范围内容进行评判 值域评判 4) 监控结果全面实时展示

能够实时展示全部的实时的信息，可以让运维监控人员一目了然看到系统各模块运行的进度、质量和告警。

5) 问题分析

系统支持对问题进行定位分析和影响分析。 6) 告警信息的分发

第49页共51页

本文来源：https://www.bwwdw.com/article/as3p.html