数据中心建设方案简版.docx

企业数据中心系统平台
技术方案建议书

第1章 总体建设方案
1.1 总体建设思路
图、数据中心构建思路图
按照对数据中心的理解,完整的数据中心应该具备IT基础设施（主机、存储、网络)、企业级ETL平台、数据存储中心、数据共享服务、应用层、统一门户、数据管控平台。
1.2 功能框架
图、功能框架
系统功能框架分为企业级ETL平台、存储与计算中心、服务层、应用层、统一门户、统一平台管控.
企业级ETL平台：
负责企业数据中心数据采集、加工、汇总、分发的过程,完成企业级数据标准化、集中化，实现数据脉络化、关系化，实现统一的数据处理加工，包括：非实时数据处理和实时数据处理，提供数据抽取、数据转换、数据加载、数据汇总、数据分发、数据挖掘等能力.
存储与计算中心：
建立统一的数据中心数据模型，以及统一的数据存储与计算，具体提供关系数据库、分布式非关系数据库、分布式文件、分布式计算，实现统一的数据存储与计算。
数据共享服务：
通过数据服务标准化开放访问，帮助企业IT建设中,应用和数据分离，引入更多的应用开发商，促进应用的百花齐放和应用的专业性；基于标准化接口，实现对标签、客户视图、指标等数据查询API封装，实现与周边系统实时互动,体现数据价值，减少数据冗余,保证数据安全，保证数据的一致性。
应用层：
应用层的应用使用服务层提供的各种数据服务。本期应用层包括：经分应用、流量运营、ESOP应用、VGOP应用、指标库、流量运营战略地图、掌上分析、自助业务分析、区域洞察、渠道运营、自助分析、客户标签库、实时营销、LTE互联网管控策略。
统一门户：
提供统一域名分配、负载均衡、鉴权管理、统一管控平台接入、应用注册、应用发布、应用访问数据信息等功能，同时提供数据中心被应用访问的频次，被应用访问的数据范围,提供数据资产的评估，为应用上下线和数据开放提供依据。
统一平台管控:
面向开发人员、运维人员实现数据、应用、资源的统一管控，包括:数据资产管控、开发管理、监控管理、调度管理、系统管理、安全管理。
1.3 技术架构
图、技术架构
系统技术架构分为数据采集、计算存储服务、数据共享服务、平台管控.采用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，是模型－视图－控制器）把业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时,不需要重新编写业务逻辑。
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章节；
第2章 企业ETL数据处理平台
2.1 功能框架
根据数据中心的建设需求，企业级的ETL平台实现统一的数据采集、转换、加载、处理以及统一调度、管控等功能。这里的ETL指的是广义的ETL，具备以下的特点:
Ø 统一数据获取接入，支持B域数据、M域数据、O域数据或其他外部数据统一接入数据中心平台。
Ø 支持结构化和非结构化数据采集、加工;对非结构化数据要实现从非结构化到结构化的处理过程.
Ø 支持数据采集、转换、加载等关键 ,。数据处理过程,实现企业数据的标准.
Ø 从周期上，支持批量的数据采集，实时的数据采集
Ø 满足数据中心数据加工，处理以及对外提供数据分发、同步
Ø 支持全过程的数据稽核.包括事前、事中、事后的稽核方式.以及灵活的稽核规则管理，算法管理
Ø 全过程的可视化开发配置管理。通过可视化的开发配置,测试和部署上线。
Ø 全过程元数据管理。重点要实现事前的元数据管理。管理的内容包括:支持数据模型、数据流程、转换规则、数据关系和转换映射规则。
企业级的ETL平台产品DACP可以很好支持上述的关键功能特点。
第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 存储规划

Hive
Hbase
db2
ODS层
3+1月
3+1月
——
DWD层
6+1月
--
--
DW层
12+1月
——
—-
ST层
36月
—-
36月
客户标签/视图
3月
12+1月
—-
指标
3+1月
——
永久
3.3 模型设计
数据模型设计按照层次，主题的数据模型设计的思路。系统根据模型设计会自动转成hadoop上存储。层次、主题映射到相应的目录.
3.4 模型规范化管理
3.4.1 分层规范
依据数据仓库建模理论，结合实际经验，数据计算平台承载数据模型分为四层：ODS、DWD、DW和ST,即接口层、存储层、汇总层、应用层。
模型分层说明：
接口层：ODS模型的数据结构与业务系统接口文件结构保持一致，接口层的数据在数据计算平台进行暂存。
存储层：即明细数据层,是数据计算核心层数据模型之一，用于存放由清洗、转换层来的数据或者接口层直接来的数据，其设计目标是为后续的汇总数据层和信息子层提供数据基础。
汇总层:即轻度汇总数据层,也是数据计算核心层数据模型之一，该层实现对主题内的数据做轻量汇总。设计目标是为应用层提供足够灵活、方便的基础数据，并保证从该层获取数据是性能最优.
应用层：在汇总数据层之上，数据按照应用需求做数据聚合，生成相关应用所需数据的数据层。应用数据层是面向应用的,但是也不是每个应用都在应用数据层对应一个表,对应用要在数据应用层中进行整合。
3.4.2 表命名规范
OMG标准化组织建议，采用5分段的命名规范：如下
3.4.3 字段命名规范
建立字段的命名规范，并固化为domain类型，指导模型设计字段命名。当有变更，可以做到跨平台的统一建模.
3.4.4 模型版本管理
第4章 数据开放服务层
4.1 建设目标
l 通过数据服务标准化开放访问，帮助企业IT建设中，应用和数据分离，引入更多的应用开发商，促进应用的百花齐放和应用的专业性。
l 基于标准化接口，实现对标签、客户视图、指标等数据查询API封装，实现与周边系统实时互动，体现数据价值，减少数据冗余，保证数据安全，保证数据的一致性。
l 对于详单级数据，支持通过文件或授权的方式共享给周边系统。
l 通过统一的技术平台框架，制定企业数据标准体系规范，基础数据采集处理，加工汇总,可以引入多家厂商或多租户进行标准化开发。
要实现上述目标，需要解决的关键问题：
1） 需要什么样平台功能？
2） 开放的对象。给谁开放？
3） 开放什么内容.包含两部分，基础数据的集成开发的开放和应用访问层数据开放。
4） 开放的安全保障机制
5） 如何保证开放对象开发提交的结果的规范化、质量。
6） 开放平台运营的组织结构和流程制度。
4.2 概述
要满足建设目标的要求，数据服务开放的整个功能框架如下：
4.2.1 开放对象
示例说明如下
开放对象
说明
使用形式
相关数据
多租户
通过授权的机制,给租户开放通过sql查询数据能力，租户可以在此基础上汇总加工自己私有的数据
SQL，进行数据处理
在保障数据安全性、数据可控性的前提下，将Hive仓库的ODS、DWD、DW各层的开放授权给数据处理开放给租户。
ESOP，VGOP
通过文件接口将数据分发给对端系统，满足其数据分析需求
文件
客户视图，汇总模型等
手机经分
通过在线同步API调用的方式获取数据
开放API
指标类数据
实时营销
客户端通过事件注册的方式监听服务接口，当服务满足触发条件是主动通知监听客户端
消息服务
信令位置信息等
4.2.2 开放共享方式
共享方式
说明
应用场景示例
文件接口
数据中心将数据主动导出文件,发送给数据需求方
1、boss的互动接口
2、即席查询临时周期性生成数据
开放API
通过API查询获取结果数据，即查即用，不落地。按查询数据对象粒度分为三类：

1)ST表查询
1、通过对发布的数据模型发起LSQL进行查询获取数据
2）指标类查询
2、如手机经分查询指标，原来是通过接口表导入数据，可以通过API来查询数据
3）单用户清单信息查询
API
数据分发
将数据中心的数据分发到目标数据库。需求方提出申请审批通过后，系统通过分发平台定期将数据分发到目标库
定期数据同步。如将用户行为汇总数据定期同步到经营分析系统
即席查询
业务分析人员通过封装好的数据模型和提供在线即席查询分析工具，进行查询分析获取数据
临时统计，临时取数
消息服务
通过消息传递数据。
适合于系统之间的实时协助，如用户事件信息。需求方作为消息的消费者，同时传递消息事件和内容
4.3 多租户管理
4.3.1 概述
采用多租户的思路，将数据能力和数据平台数据处理能力按需、可控的进行开放，在保障数据安全性、数据可控性的前提下，通过标准化封装的数据操作，可视化开发工具开放给业务运营部门，由其自行进行数据操作开发。
使用企业级数据中心提供统一开发平台来实现多租户数据开发，其功能结构如下图：
系统包括两部分：开发管控和技术平台.通过这两部分互相配合实现系统开发能力的开放。
这种模式下需要解决的关键问题包括如下：如何进行资源控制，数据权限管理，跨系统之间的数据交互,自动调度运行，元数据管理。
4.3.2 角色功能
系统管理员：对开发团队进行管理，数据权限和系统资源的分配、审批.
1、设置开发团队使用资源和账号
2、对开发团队提出的数据权限申请进行审批授权
3、表的敏感级别和敏感字段。不同团队对同一数据安全级别可以不一样
4、对开发团队上线进行审批。检查性能，开发规范的满足情况，调度申请周期是否合理
5、对开发团队数据导出安全进行审计
租户开发：使用统一的技术架构和开发工具，在可以使用的数据的基础，加工出私有数据
1、查看详细的数据结构
2、新申请数据权限，如果需要新的数据，可以进行申请，由管理员审批后就可以使用
3、数据加工开发，进行数据汇总、关联查询，数据导出等类型数据数据加工开发
4、临时上线、正式上线。
5、对其所开发的程序数据运行情况监控。
4.3.3 统一开发平台技术详解
4.3.3.1 租户用户管理
n 租户与系统用户映射
通过映射开发管理平台帐号及执行平台帐号，以租户的方式实现用户及用户组管理，以达到资源管控及数据权限控制的目的.
如下图，在管控平台进行开发团队的管理和对应账号的设置，在数据平台完成对租户的资源、权限进行控制。
每个开发团队根据需要指定其在hadoop或关系数据库上的执行账号。在数据平台上实现账号的权限、资源的控制。
在查询或运行某个数据处理任务时，用其对应的账号进行执行。从而实现对开发团队开发运行的任务资源、权限的控制。
在管理平台新建租户的账号或数据权限变更时,管理平台根据配置参数，实时调用OCDC的相关API自动进行授权、修改、创建账号。
4.3.3.2 系统计算资源分配控制
在管控平台统一对租户进行计算资源的分配，分配完的参数部署到hadoop或关系数据库,实现控制。
实现资源控制，包括两部分： hadoop上的资源分配和关系数据库的资源分配（DB2）.
n Hadoop计算资源控制
要实现计算资源的控制，hadoop需要OCHadoop3.2以上,安装安全组件（sentry)
计算资源控制原理
资源池跟系统的账号相关。一个系统账号只能属于一个资源池,YARN支持采用资源池方式对系统用户进行CPU,内存的运行控制。
资源池控制参数：
独占资源：最小分配的资源.系统确保此用户有最小的资源。
共享资源：系统空闲时可以使用的最大资源
其中单位:虚拟的cpu核和内存单位.
如何设置租户的资源参数,是一个需要不断根据运行情况进行优化的过程。
注：Spark同hadoop的资源管理
n DB2资源控制
要实现DB2的资源控制，要求：DB2 9.5 版本。目前db2的版本已经满足,需要开通WLM的生效参数。
在DB2 9.5版本推出了工作负载管理WLM(参考附录，不用额外收费)，但只能限制CPU数量。控制参数如下：
参数名
说明
min
分配给某个服务类的最小资源百分比.缺省值为 0。
softmax
在有冲突的情况下（这里可以理解为资源紧张时），服务类可获得的最少资源比例.在没有冲突的情况下，服务类可获得的资源可以超过该值设定的比例。缺省值 100
hardmax
在没有冲突的情况下，服务类可获得的最大资源比例。缺省值为 100
4.3.3.3 系统存储资源分配
Hadoop存储资源控制，每个租户独立一个文件跟目录，设置文件目录大小；
db2的存储资源控制,对每个租户独立一个表空间,设置表空间大小；
说明：hadoop存储控制采用的是操作系统的目录大小的控制。缺陷是无法高度自动共享可用空间。即一个目录大小分配出去之后，意味其就占有了这个空间。因此一般做法是由小到大慢慢分配空间.
4.3.3.4 数据权限分配与控制
在开发管理平台进行对数据权限的分配.根据分配的结果在数据平台进行授权、回收等操作。
数据权限的控制包括：表级权限控制和字段级的权限控制：
l 表级权限分配：系统根据分配的结果，产生授权或权限回收的脚本到db2，hadoop进行执行完成权限控制.
注：在管理平台分配的是逻辑模板表，数据平台控制的是实际的表。因此有一个模块专门按模板表的权限规则转换为物理表的授权脚本执行。
l 字段级权限分配：在表级授权的基础上，对表的字段的权限进行授权分配。由于目前db2，hadoop不能直接实现对字段级的权限控制。所以我们采用两种方式实现这个功能：
方式1：建立视图，过滤掉没有权限的字段，然后将视图授权给相关账号。实现字段级的权限控制。
方式2：通过应用级的控制。通过开发人员编写的sql语句解析，分析其查询中所用到的字段，如果字段超出权限范围，则给出提示，不允许执行。
资源控制手段列表：
控制项目
db2
hadoop
表级权限
通过db2的权限管理，通过脚本实现数据权限的分配
通过kerbors的权限管理，通过脚本实现数据权限的分配
字段级权限
通过视图
通过视图
资源-CPU
通过wlm进行设置
通过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、创建表,删除表等。
3. 测试
在界面上可以立即执行某个节点或整个处理流程,执行过程和日志信息会实时输出到前台界面进行查看.如下示意图:
4. 上线
开发人员在界面上直接提交上线。包括临时上线和正式上线两种。临时上线需要开发人员填写生效的开始日期,结束日期,调度周期。
正式上线，系统管理管理员会进行审批。审批的项目包括：程序名称,表名是否规范，字段名称和中文信息是否完整。
在上线时,系统会自动将程序代码、数据结构从开发环境的配置信息部署到生产环境下。
5. 运行
程序上线后,调度平台就会根据程序数据依赖关系自动进行调度。
如果是临时上线的只有调度运行在有效期内的程序才会被调度执行。程序开发人员可以申请延长有效期或申请固定上线。
4.3.3.6 调度执行
多租户调度使用平台提供的统一调度功能，实现过程如下:
1. 调度运行
依据输入表关系，根据数据关系实现正确调度依赖运行.对租户的临时程序调度时，只会调度在有效期的程序才会调度。
2. SQL脚本执行
开发人员开发好的SQL脚本，可以到多个数据平台上运行，系统需要进行正确选择投入到相应的数据平台运行。
a) 开发人员可以指定节点运行的数据库，如下图
b) 系统会对开发人员的编写的sql进行解析，获取其依赖的输入表和输出表。再跟元数据进行对比自动选择相应数据库。选择策略如下:
所有输入表都在同一个库
则选择那个库
输入表分布在两个库
系统给出错误提示.建议其采用数据同步再进行开发。
如果涉及到的表涉及到两个库都存在
如果有关联表，则跟着关联表同个库，否则优先选择大数据平台。
3. 跨数据平台命令的运行
比如：如何实现在hadoop平台执行汇总数据,导入到db2，在进行汇总。
Server端在读取这个一个处理任务时，将命令发送汇总命令给hadoop Agent执行,然后在发送命令给hadoop Agent进行分发到db2，然后在发送命令给db2 agent进行数据处理.
第5章 应用开发与部署
5.1 应用开发流程
应用层的所有业务应用具备与底层数据松耦合特性，通过接口层提供的各种数据接口，向业务人员或第三方厂商提供开放API服务。根据不同的应用场景，通过对相应的API进行选择和组合,从而快速生成所需要的业务应用,以满足对应用的快速开发、部署、上线的能力。
对于应用的开发可通过两种方式进行实现：
1、 数据中心平台内应用开发：通过数据中心提供的应用开发平台直接进行应用开发，开发平台提供高效的可视化开发界面，包括对各类API可以追根溯源，展现详细API元数据信息等。同时对应用设计、应用开发、应用测试、应用上线、应用下线进行全流程、全生命周期的开发管控.此类开发场景主要适用于不具备硬件资源的用户（如业务部门开发人员）进行应用开发。
2、 数据中心平台外应用开发：通过Http协议数据服务接口，直接调用数据中心服务层中的各类API服务，通过开发编写相应的计算过程形成对应的业务应用.此类开发场景主要适用于具备硬件资源（如第三方厂商）的用户进行应用开发.
5.2 应用部署建议
本期从外部系统接入8类数据源,所有清单数据在企业数据中心进行基础汇总，提供数据、存储和API接口服务能力，供14类应用调用。
标签库应用:所有标签数据计算、存储在数据中心,标签结果数据在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.
第6章 统一门户
6.1 概述
企业数据中心统一门户的建设是为了降低系统使用人员访问数据中心的难度，提高系统的易用性,并且实现数据中心的资源有机整合和统筹管理。
1. 数据开放服务门户:对于数据开放服务提供开发者门户，含有数据服务授权申请、开发者帮助文档、服务注册、创建、注销等。
2. 管控平台门户：对整个数据中心管控平台使用者门户，系统管理、运维调度、质量监控等。
3. 应用使用门户：对于应用使用者的门户,支持多租户应用、第三方应用的集成统一呈现。
6.2 门户功能框架
统一门户功能框架如下图所示
门户功能框架包括门户接入、门户功能两部分；通过功能适配到角色工作台形成不同的角色视图。
Ø 门户接入：主要负责企业数据中心用户访问渠道的接入管理；接入应用的日志管理、负载均衡与访问授权。
Ø 门户功能：包括角色工作台、认证管理、权限管理、用户管理、流程审批、数据开发、应用开发、数据授权、运维监控、多租户管理等界面。
第7章 管控平台
7.1 概述
7.2 元数据管理
7.2.1 功能框架
元数据管理是需要将各系统的信息、设计工具信息、生产平台信息，进行收集管理，统一管理。提供一个视图，以帮助使用人员了解系统的数据分布、数据关系、业务规则、指标口径等。元数据包括：系统类元数据、技术类元数、管理类元数据。
总体功能框架图
针对数据中心的要求，元数据管理需要具备的关键的特性如下：
1） 要求提供标准化的应用开发工具，满足在不同平台上的开发需求
2） 100％的ETL开发、数据模型开发、应用开发能基于开发工具实现
3） 95%以上的元数据能自动采集、解析与管理,元数据的范围包括但不局限于数据结构、数据词典、字段维度、程序映射逻辑、数据生命周期等
4） 多租户的统一元数据管理
7.2.2 基于元数据的应用开发工具
提供统一的应用开发工具,完成高效应用的开发，并可以自动完成应用元数据的采集。提供诸如数据展示包括报表工具，仪表盘分析等工具如
1、 支持常见的各种报表样式
2、 支持常见各种分析图，同时支持图表组合分析
3、 支持各种数据源方式
支持oracle，db2，mysql等常见的关系型数据库
支持gp，gbase等mpp数据库
支持hdfs，hbase等大数据平台提供数据
支持webservice获取数据
7.2.3 基于元数据的数据开发工具
采用元数据驱动（MDA）设计理念，去规划元数据对象的创建、运行、评估、维护各环节节。屏蔽大数据平台差异性，统一模型设计、统一程序开发，将元数据融入到开发各个环节，利于管理.
Ø 数据模型设计
支持IDE数据模型设计，同时支持模型设计工具power design、Erwin批量导入功能。
提供数据周期、数据表级字段级铭感设置、字段口径定义。
Ø 数据流程设计
设计程序输入表和输出表的元数据信息。
Ø 程序开发
根据设计的内容转换成开发内容。开发人员就可以在此基础上进行开发。
提供各个接入平台统一封装函数，降低开发难度
Ø 数据质量控制
1。常规检查.包括及时性，运行状态，运行时长，处理记录数等进行常规检查。
2。对程序日志进行稽核。包括单步的处理时长，记录数的波动等
3。对程序的目标表启动检查。检查目标的统计指标值，关键字段维度、层次间数据的一致性进行检查
Ø 提供程序界面测试功能
对开发内容进行测试和调优，检查质量规范，性能，质量是否满足期望
发布应用到正式运行环境
元数据收集存储：
Ø 程序的基本信息。包括程序的名称,中文名称，备注,周期，层次，主题，创建人，开发人员
Ø 程序的处理步骤信息。包括程序步骤编号,调用函数，执行脚本
Ø 程序输入输出关系。输入模型,输出模型
程序的字段映射规则。输入模型到输出模型的转换规则
7.2.3.1 数据流设计
设计数据模型，设置数据存储周期，敏感级别，数据模型数据流设计,支持模型字段映射关系设计
1. 数据流程设计
设计程序输入表和输出表.输入表可以是文件，也可以是远程数据库上的某个表.目标表可以是文件也可以是远程目标数据库上的表。
2. 数据模型设计
对输入表和输出表，进行表结构的设计。包括表的基本信息,存储信息和表的关系.根据不同的存储类别，会有设计参数上的差异。
3. 转换映射规则设计
根据表的关系和表模型信息，进行转换映射。映射规则包括合并，拆分，规则转换,函数转换等常见的操作
7.2.3.2 可视化程序开发
Ø 统一封装的函数库,屏蔽底层差异性，通过类sql编写,或函数调度，实现跨平台统一开发。根据数据仓库处理过程抽象出5大类通用函数库，统一调用参数接口，开发人员针对不同不平台实现无差异的开发。如将某类数据文件加载到数据库中，开发人员只要指定数据文件路径和目标表.系统执行时如果是要入库到DB2调用DB2的命令，如果是Hadoop平台,调用Hadoop的命令。
Ø 通过可视化的流程界面,拖拽方式实现对函数的编排，对每个节点函数编写参数，实现数据加工功能。降低开发难度。开发时候,对函数进行编排,填写节点函数参数。实现一个具体的数据处理过程
Ø 支持多种脚本开发，提供基于web脚本开发工具编写如tcl、python开发程序；能够从开发的脚本中自动解析建立元数据:输入表和输出表的关系；脚本类的开发工具，集成了开发,测试，上线集成操作。同时将函数库，数据模型统一进行集成；
7.2.4 关键技术说明
7.2.4.1 前向元数据管理
1、在开发过程中通过IDE工具产生结构化的元数据信息。
2、在上线时,对元数据内容进行稽核检查,保证元数据信息的完整性，合理性.通过统一的上线作为管理的控制点.每个团队提交要上线的内容，存到统一元数据库进行标准化检查稽核。
上线时检查的内容：程序需要提交的内容：程序本身的信息和程序输出表的信息。
7.2.4.2 多租户的元数据管理
Ø 每个开发团队输出到不同的开发目录。内容包括现有的数据字典、业务口径、程序代码等.这些输出到同一的元数据中心，进行统一的标准化和规范化检查
Ø 统一的标准与规范，统制定基本的规范和标准，不管哪个开发小组开发的内容必须满足这些基本的标准。
7.3 流程管理
通过流程管理实现对数据处理过程的统一管控，并提供一系列工具实现数据处理过程可视化、可管控,它包括对系统资源、软件资源、业务应用、参与人员等各种资源统一管理,综合监控平台,随时重现大数据环境中各个组成部分相互依赖，为各级IT管理人员提供从资源规划、资源收集、性能分析、故障定位与处理、统计分析、知识沉淀与管理过程的支持
7.3.1 流程引擎
流程管理集成自有轻量型流程引擎来完成各类流程快速配置开发.功能如下:
1、流程的建模和实现
在流程定义、执行、管理控制等阶段,业务和IT人员的高度一致
流程运行，以及整体性能查看和监控可视化
提供灵活的手段实现流程的修改和演进
支持流程模式以及部门协同，支持流程中的附件添加和查看
自带的业务规则和决策表支持分支选择,路由到特定用户、用户组、角色、投票规则、例外和事件处理、服务水平监控规则等
2、流程仿真、优化和分析
3、 开发管控、版本控制
4、 流程评估和监控分析
7.4 作业任务管理
通过元数据获取作业输入表作为作业启动的前置条件
1、通过数据流程设计来确定数据关系
2、人工进行修改作业输入、输出
3、支持手工设置前置作业
作业任务资源占用类型评估
采集程序的历史运行时长，处理记录数等关键指标，支持系统自动测算和人工指定，对程序的资源占用类型分为三类：
1、高：运行时长特别长，处理记录数比较多
2、中：处理记录数相对较小,处理步骤多,时间较长。
3、低：运行时间很短的程序
作业任务静态优先级
按照应用的重要性，根据血缘分析，寻找路径上的所有处理任务。
1、重要越高的应用，其路径上的节点的任务优先级越高.
2、人工进行修改维护
7.5 数据管理
7.5.1 数据生命周期管理
7.5.1.1 上线
不管通过什么方式完成开发,上线必须保证数据的相关的信息完整性，合理性。由数据管理员负责对上线要素信息的检查。保证在上线时信息要素被正确保存，以作为后续使用。
Ø 上线检查基本信息要素
权限信息要素：
存储信息要素：
数据关系要素：
Ø 表的基本信息检查
Ø 表结构
Ø 表存储信息设置
Ø 系统规范性自动检测
7.5.1.2 数据监控
7.5.1.2.1 存储策略情况
检查表的实际存储情况和规划存储周期情况进行对比,发现规划与实际的差距，查找原因。为下期扩容做准备。
7.5.1.2.2 安全漏洞检测
安全策略管理:对数据加密的密钥管理,敏感数据定义,账号权限,离线数据终端的注册等。
安全策略检测：对安全策略是否实施到位进行自动检测。如敏感信息是否有加密，账号的权限是否超出范围。
安全审计监控：对数据所有的使用日志进行审计，是否涉及到敏感数据非法使用。
7.5.1.2.3 存储空间监控
检查文件空间，表空间等信息是否满足生产的要求。
7.5.1.3 数据评估
7.5.1.3.1 数据价值评估
功能说明：对数据价值成本进行评估，对数据存储、处理、应用进行优化。
评估算法：

科目
分摊方法
价值
前台应用使用次数
应用的点击次数平均分摊给应用链路上的所有表
支持kpi，指标统计的个数
KPI应用次数平均分摊给KPI的统计表链路上的所有表
分发给外部系统接口可数据
（分发给外部表，平均分摊给分发接口表链路上的所有表）＊加权系数
外部应用调用次数
（外部应用调用表次数平均分摊给应用表链路上的所有表）*加权系数
成本项目
存储成本
表的大小*（存储扩容的投资总额/总空间大小)
计算成本
处理表数据总时长＊(主机扩容的投资总额/所有程序的运行总时长）
开发成本
表的字段数＊（每年新业务开发费用/表的总字段数据)
运维成本
维护费用/表的总数
管理成本分摊
管理总成本/表的总数
应用场景：
7.5.1.3.2 数据重要性评估
从表的在数据使用过程中和数据应用中对表的重要性进行评估，输出表重要性级别。
7.5.1.3.3 存储周期评估
包括存储规则的配置示例如下：
数据内容
集团建议数据保存周期
用户资料及接触记录
在线存储：三年
近线存储：永久保存(Hadoop Erasure Code）
各类话单
在线存储：一年
近线存储:三年（Hadoop Erasure Code)
信令和日志
在线存储：一个月
近线存储：六个月(Hadoop Erasure Code)
各类汇总数据
在线存储：永久保存
存储周期的计算，计算表到期时间。如果到期了,则这个表可以进行删除或转储。
7.5.1.3.4 时效性评估
通过对数据关系的分析，发现孤立表或无效表.
根据表名判断此表大约含义,建表日期、状态日期，表内数据时间等判断此表最后更新时间.
通过数据的使用日志，对孤立表和无效表进行判断是否有使用
如果满足以上3点，就可以判断此表无使用和处理.就可以进行下线处理。
7.5.1.3.5 冗余数据评估
系统中存在着大量的冗余的数据。比如从清单上的进行汇总的表就非常多，这些汇总表中有些存在相识性，这就造成了大量的冗余数据，这些大量的冗余数据,一方面给数据的精确性和可靠性将带来影响，同时也影响着数据库的性能.
要解决这个问题有两个环节：发现冗余数据和冗余进行消除合并。
7.5.1.3.6 数据关系评估
数据关系的类别可以分为以下几种：
l 主外键关系。由上线时进行登记.
l 参考关系。主要描述实体表与维度表的关系.在上线时登记。
l 输入与输出.通过元数据解析建立.
l 历史拍照.通过处理程序解析发现建立。
l 冗余备份。从目的可以划分为:分工提速、转储优化、应用分流、数据统计临时备份.
系统根据以上的关系类别,通过相识表的发现分析，自动建立数据之间的关系。
7.5.1.4 数据优化
7.5.1.4.1 优化策略
类别
条件
优化策略
执行策略
下线清理
1、表满足存储评估的到期条件
2、同时满足数据在各个已经同步到位
清理或转储
自动执行
下线清理
1、满足时效性分析发现的无效表
清理
人工确认
性能优化
1、发现高查询使用的表
转存高端设备或内存数据
人工确认
冗余消除
1、发现相似表或冗余表
数据合并
人工确认
冗余字段
1、发现抽取过多的字段但没有使用到
优化抽取策略