1数据架构设计(数据架构组)

1.1概述

1.1.1总体描述

相对于业务架构和应用架构,数据架构在总体架构中处于基础和核心地位。因为信息系统支撑下的海关业务运作状况,是通过信息系统中的数据反映出来的,数据信息系统管理的重要资源。因此构建海关的IT总体架构时,首先要考虑数据架构对当前业务的支持。理想的IT总体架构规划逻辑上是数据驱动的,即:首先根据业务架构分析定义数据架构;然后根据数据架构结合业务功能定义应用架构;最后根据应用架构与数据架构的定义,来设计技术架构。

1.1.2数据架构蓝图

1.1.2.1逻辑蓝图

图:数据架构总体逻辑蓝图

数据架构的六个统一,即统一数据规划、统一存储、统一计算、统一服务、统一接入、统一数据治理。

1.1.2.2物理蓝图

图4-1-1

l通过万兆连接核心交换区,实现网络高速交换,确保可靠性

l各服务器均双线连接数据区核心交换机,消除单点故障

l结构清晰,层次分明

1.1.3设计原则

1、整体性原则

共享服务平台必须根据统一的总体方案的统筹规划,按总署、直属海关、隶属海关的功能划分实行多级部署,同时按照职责分工进行建设和管理,保证三个层级的部署构成一个整体,各部分通信畅顺,信息共享,形成一个全国性的共享服务平台。

2、标准化原则

总署统一制定信息资源共享服务的技术标准、通信协议标准、数据交换报文标准,提供数据访问功能、基本业务逻辑处理功能的标准组件。系统的开发、集成按照规定的标准进行,保证海关共享服务平台的结构一致性和技术规范性。

3、安全与效率并重原则

总结和汲取超大业务量海关的成功经验,采取充分足够的技术手段和管理制度,在保证共享服务平台与海关业务应用系统之间高速的数据交换,在保证共享服务平台良好运行效率的同时,保证海关业务运行网和业务管理网的信息安全和运行安全。

系统设计方面要充分考虑共享服务平台数据量大、负荷高等因素,严格控制程序流程设计、严把程序编制质量、同步制定配套的系统运行管理办法,确保共享服务平台运行的高效性和稳定性。

4、系统功能与职责分工相适应原则

平台多方共建,发挥各方面的积极性,信息系统、业务系统与业务管理或操作运行的主体之间的关系和分工必须明确。

5、一致性原则

共享服务平台在体系架构上必须与金关业务解决方案的框架保持一致,在系统开发建设的设备选型、开发技术、认证授权、门户框架、数据定义、参数管理、通信协议、网络结构、安全运维等方面必须与金关总体技术方案保持一致,保证共享服务平台成为现代海关综合管理系统的有机组成部分。

注:整体统筹原则

数据层和应用层解耦

数据的高可靠

服务的高可用

1.1.4设计目标

“信息资源体系建设”是一项长期工程,是支撑海关各个业务条线之间实现充分协作信息共享基础架构。将确保金关工程二期在海关信息资源开发利用方面抓住数据一致性、规范性等数据质量源头建设,形成统一顶层设计,做到海关信息资源一盘棋,数据统一管控,统一开发利用,促进海关信息共享、业务协作效率和科学决策水平的更高提升。

总体目标主要包括以下五个方面内容:

1、实现信息资源整合

信息资源规划的一项很重要的目标就是要解决目前信息系统建设中的重复建设问题,达到信息系统的整合和集约,信息资源规划是信息系统顶层设计的一部分,能够从整体上对信息资源进行设计,并能够提供信息系统建设的标准和规范,这样信息系统就能够以此为标准,进行适时、适度、逐步整合,最终达到消除冗余,集约良性发展的效果。

2、提高技术响应速度

业务需求的变化和技术的响应速度之间一直是一对矛盾,信息资源规划通过对信息系统,尤其是信息资源架构进行科学设计,可以增强信息资源架构的稳定性,当业务需求变化时,可以通过很少的数据结构和程序变动就能够满足业务需求,这样不但提高了技术响应速度,而且能够增强系统的稳定性,降低故障率。

3、实现信息共享

信息资源规划通过建设信息共享服务平台,实现了数据的集中存储和计算,并实现了对外统一的服务接口,不论是对于海关内部的信息共享需求,还是外部的数据共享需求;不论是直接面向用户的共享查询,还是面向应用系统的数据服务,都可以通过数据服务共享平台解决。

4、实现大数据分析

海关要实现智能海关,必须实现海关信息系统的物联化、互联化、智能化,而最重要的就是智能化,即通过大数据分析,为海关准确决策提供信息支持。信息资源规划通过设计和实现数据共享服务平台,引入并行数据库、分布式数据库等大数据存储和计算技术,能够解决海关的大数据分析问题,达到数据用得好、决策准的业务目标。

5、提升数据质量

信息资源规划通过设定标准规范、业务管理流程,能够规范数据的定义、存储、使用、传输、交换,使得数据采集更加规范、数据传输更加准确高效,数据使用更加安全方便,通过各种管理流程和规范,能够大幅提升数据质量。

1.2数据定义

1.2.1总体描述

数据的基本结构分三个层次,反映了观察数据的三种不同角度。

(1)概念数据层。它是数据的整体逻辑表示。指出了每个数据的逻辑定义及数据间的逻辑联系,是存贮记录的集合。它所涉及的是数据所有对象的逻辑关系,而不是它们的物理情况。

(2)物理数据层。它是物理存贮设备上实际存储的数据的集合。这些数据是原始数据,是用户加工的对象,由内部模式描述的指令操作处理的位串、字符和字组成。

(3)逻辑数据层。它是用户所看到和使用的数据,表示了一个或一些特定用户使用的数据集合,即逻辑记录的集合。

                                                                     数据建模

1.2.2业务域

根据目前海关不同的网络,运行网、管理网和接入网以及总署和直属的这种物理关系,梳理出每个域中业务情况和相互的关联关系划分出不同的业务域。

海关目前的现状梳理出来的业务域有: 公共域、首长决策域、公共办公域、业务管理域、综合保障域和内部监控

公共域:

1)公共时间域

2)公共金融域

3)公共位置域

4)公共人员域

5)公共机构域

6)公共参数域

首长决策:

1)署长办公

公共办公:

1)办公

2)国际事务

业务管理:

1)政法

2)关税

3)监管

4)物流

5)加贸

6)稽查

7)缉私

8)统计

综合保障:

1)科技

2)财务

3)关务保障

4)人事

内部监控

1)督查审计

2)监察

根据业务 划分核心数据和非核心数据。

1.2.3概念模型设计

概念数据模型是最终用户对数据存储的看法,反映了最终用户综合性的信息需求,它以数据类的方式描述企业级的数据需求,数据类代表了在业务环境中自然聚集成的几个主要类别数据。

概念数据模型的内容包括重要的实体及实体之间的关系。在概念数据模型中不包括实体的属性,也不用定义实体的主键。这是概念数据模型和逻辑数据模型的主要区别。概念数据模型的目标是统一业务概念,作为业务人员和技术人员之间沟通的桥梁,确定不同实体之间的最高层次的关系。

根据业务域的划分,梳理跨业务域的端到端的业务流程,从而梳理出大的对象之间的关系和小的业务流程。

例如,用户(user)E-R图

1.2.4逻辑模型设计

逻辑数据模型反映的是系统分析设计人员对数据存储的观点,是对概念数据模型进一步的分解和细化。

逻辑数据模型是根据业务规则确定的,关于业务对象、业务对象的数据项及业务对象之间关系的基本蓝图。 逻辑数据模型的内容包括所有的实体和关系,确定每个实体的属性,定义每个实体的主键,指定实体的外键,需要进行范式化处理。  

逻辑数据模型的目标是尽可能详细的描述数据,但并不考虑数据在物理上如何来实现。逻辑数据建模不仅会影响数据库设计的方向,还间接影响最终数据库的性能和管理。如果在实现逻辑数据模型时投入得足够多,那么在物理数据模型设计时就可以有许多可供选择的方法。

解决端到端的业务流程梳理出大量的小流程和对象关系,进一步梳理出各个业务域的业务对象及其行为和属性。

1.2.5物理模型设计

物理数据模型是在逻辑数据模型的基础上,考虑各种具体的技术实现因素,进行数据库体系结构设计,真正实现数据在数据库中的存放。

 物理数据模型的内容包括确定所有的表和列,定义外键用于确定表之间的关系,基于用户的需求可能进行发范式化等内容。在物理实现上的考虑,可能会导致物理数据模型和逻辑数据模型有较大的不同。

物理数据模型的目标是指定如何用数据库模式来实现逻辑数据模型,以及真正的保存数据。

常用的设计范式,以及对于数据量大的业务,在数据模型层面不处理表之间的主外键之间的关系。

主要将逻辑模型的各个业务对象及之间的关系,以表、主外键及关联表的方式表示。针对各个逻辑模型勾勒出各个域的ER模型。

1.3数据分布

1.3.1总体描述

将数据物理分布式处理方式逐步转为集中式处理方式,本节主要描述数据在各个业务子系统之间的逻辑分布,以及数据物理分布。

1.3.2逻辑分布

1.3.3物理分布

数据存放:

集中存放+灾备?分布式主从模式?分布式无中心化?

数据:核心交易:商用关系DB+小机集群?分析:newSQL+小机集群?低价值密度的大规模数据:No SQL+大规模普通机器集群

据地理分布:交易数据集中存放+灾备;其他管理支持类应用数据可三中心分别存放?

1.4数据分类

1.4.1总体描述

数据分类是企业数据的组成部分,其目的是为了满足各种数据需求对数据组织的要求,根据数据内容的属性或特征,将信息按一定的原则和方法进行区分和归类,并建立起一定的分类体系,为数据的合理分布提供决策依据,以便管理和使用数据信息。

1.4.2分类原则

在数据分类时遵循以下原则:

·数据分类需要满足各种数据需求对数据组织的要求,即数据分类应该独立于具体的数据模型;

·数据分类应有利于数据的维护和扩充。

1.4.3分类内容

金关工程二期综合考虑海关应用系统所产生的数据属性、应用性质、处理方式、使用范围等因素对数据进行分类,同时考虑对数据进行生命周期管理和数据质量管理;海关数据可以从业务、生命周期及数据特点进行分类。

1、按照业务,海关的数据分为数据管理类(N)、业务基础类(Y)、业务处理类(Y)、业务管理类(N)、业务应用类(N)、业务分析类(N)六类数据。

业务数据分类

核心和非核心数据与上面业务域数据之间的对应关系

·数据管理类数据,此类数据包含动态数据仓库、数据抽取分发、数据质量监控、统一数据加工、数据生命周期管理中的数据。

·业务基础类数据,此类数据包含商品条码、企业信息基础、多维、公安信息资源、案件信息服务资源、自动许可证联网核查、联网核销、原产地证书联网共享、加工贸易多方联网、GIS应用、核心系统参数、海关情报信息采集、海关情报移动支持的数据。

·业务处理类数据,此类数据包含报关单、免税品、行邮、关税电子、外单位信息资源、加贸手册、加贸账册、互联网信息资源、智能卡口、核心系统基本通关、核心系统辅助通关、核心系统备案的数据。

·业务管理类数据,此类数据包含减免税管理、原产地管理、价格管理、业务数据管理、机动巡查、值班、预案、移动应用、海关特殊监控区域、保税监管场所、保税综合管理、批量复审、海关情报业务管理、海关情报境外执法合作、执法规范化业务执法、执法规范化辅助办案、执法规范化职能管理的数据。

·业务应用类数据,此类数据包括缉私监控指挥、企业信息应用、归类风险监控、审单执法、企业综合资信、数据交换、应急指挥、海关情报预警监测的数据。

·业务分析类数据,此类数据包含决策分析、风险数据、物流链监控分析、专家会诊审单、数据信息管理的数据。

2、按照数据来源以及服务对象,海关数据可分为对外交换数据、生产数据、共享数据、决策支持数据、元数据五类。

·对外交换数据,此类数据包括物流舱单、国外海关、电商订单、互联网舆情、政务公开等数据。

·生产数据,此类数据包括报关单、证件核销、税收、减免税、证件监管、加贸手册、加贸合同、加贸单耗、风险布控、风险查验、行政办公等数据。

·共享数据,此类数据包括企业主数据、商品主数据、公共业务通关、公共业务企管数据。

·决策支持数据,此类数据包括数据仓库、数据集市、业务报表、分析报告等数据。

·元数据,此类数据包括技术元数据、数据模型、指标体系、标准化等数据。

3、按照生命周期,海关数据可以分为“生产数据(核心,非核心)”、“分析数据”、“归档数据”三类。

4、按照数据本身的特点,海关数据可以分为结构化数据和非结构化数据,结构化数据主要是应用系统生成的存储在关系数据库中的数据,数据具有明显的共性结构特点。非结构化数据主要指一些文本、图片、图像、视频、音频等数据。

对于某一种数据(维度中的1个格子)对应一种存储技术。

1.5数据接入

1.5.1总体描述

数据统一接入层主要目的是解耦应用系统和数据存储之间的关系,本部分主要描述应用系统和关系型数据库之间的解耦,应用与其他类型的存储之间的关系在本章的其他小节来描述。其整体架构如下图所示:

上层为应用系统;下层为关系数据存储。中间层为统一接入平台。一般的应用开发,应用层直接通过数据的驱动直接访问关系数据库进行数据的存取。在我们的数据架构中增加了一层统一接入层,其目的主要解决:

1、提供统一的访问服务。

2、对应用来说,屏蔽了数据库本身的差异,数据库对应用来说只是服务。

3、提供了服务的高可用,上层应用无需关心下层存储的可用性问题,JDS层会做自动的主备切换,防止单点故障。

4、提供了数据的高可靠,上层应用无需关心下层存储数据的可靠性问题,存储层会自动做好数据的自动全量及增量备份工作。并在需要的时候可以快速从备份恢复数据。

5、支持数据的自动拆分,可应对海量数据的存储及高性能访问场景,对上层应用拆分逻辑完全透明,应用使用标准客户端即可使用。

6、数据存储自动扩容,应用无需关心底层存储的容量问题,一键进行数据的迁移及扩容工作。

7、整体系统运维的自动化智能化管理,运维成本低。

1.5.2统一访问服务

统一访问服务主要是为上层应用提供一个透明访问代理层,应用无需关心底层存储细节及产品类型,统一访问服务层帮助应用抽象出了一个统一入口,屏蔽掉了底层的不同存储产品带来的复杂性。并同时实现了高性能具备过载保护及容灾功能的接入服务,应用通过软负载均衡设备来接入服务,软负载均衡设备会实现多个接入节点的状态监测,故障剔除等工作。同时接入服务层提供了过载熔断等保护功能,保护后端代理的存储节点的稳定和安全。

1.5.3处理引擎

1.5.3.1SQL解析模块

处理引擎会进行SQL请求的拦截和处理,并根据路由信息对SQL语句进行修改或拆分,如果涉及多个节点,则会将拆分后的SQL请求并行发送到不同的物理实例上,并等待结果返回,在查询结果返回后,接入层会进行结果集的合并和计算,最终返回给客户端,整个过程对客户端完全透明。

1.5.3.2数据分片

数据分片模块可以将数据按照应用指定的规则进行水平切分,解决容量和访问量的问题,即可以不使用任何高端存储设备,只用普通x86机器完成很多高端存储才能达到的存储能力和访问能力。降低海关业务整体的硬件成本。数据可以根据海关各子业务的访问规则进行灵活配置,灵活扩展。

1.5.3.3数据路由

海关各业务针对各自访问规则进行了数据水平切分和分片后,引擎层逻辑会通过具体的访问规则将实际的访问请求路由到指定分片。路由规则的存储是在元数据管理模块中,并推送给逻辑处理引擎。逻辑处理引擎会本地存储路由规则,正常的访问流程在逻辑引擎本地查询相关规则即可,无需访问远端的元数据管理模块。

1.5.3.4结果集处理

数据进行了分片并路由到指定后端存储节点后,会在远端的存储节点执行,并将数据返回给逻辑引擎,由于数据可能已经被水平拆分过,所以有可能会涉及到多个远端的存储节点,即多个远端节点的数据需要进行结果集的汇总和再计算工作,比如order by或者group by等语句的执行,需要在逻辑引擎中进行结果的缓存和计算工作,这部分逻辑集成在了逻辑引擎内部,对业务端是完全无感知的。

1.5.3.5数据扩容

虽然我们可以按照业务类型预先对数据的容量和访问量做好规划并进行数据的水平切分和路由,但是通常我们预先规划的容量是未必完全合适的,这个时候我们可能需要对数据进行再次水平切分进行扩容迁移等操作,这个过程需要统一接入管理平台与逻辑引擎共同完成,逻辑引擎负责线上路由切换的一部分,并通过一些手段完成多个逻辑处理引擎节点之间的同步问题,保障数据的可靠性和一致性。

1.5.3.6备份管理

备份管理主要保障数据的高可靠。数据的高可靠是通过系统后台自动定时全量及增量备份数据到云存储端来完成的。全量备份及增量备份的间隔时间通过管理系统可以灵活配置,全量备份采用快照机制不会对线上访问造成任何影响,增量备份通过数据库binlog完成。

1.5.4数据驱动层

数据驱动层会对涉及的所有物理节点进行管理,能够方便灵活的配置物理节点信息,动态增减机器规模。并对节点进行实时监控和检测,剔除故障节点,保障业务使用的稳定性.

1.5.4.1故障切换

故障切换模块保障服务的高可用性,这是通过底层存储数据库的主备切换来完成,系统会监控所有管理的数据库实例,发现某个实例异常或故障后,会自动将访问切换到从库上,并通过数据库的半同步机制来保障数据在切换过程中是完全没有任何数据丢失的。

1.5.4.2协议适配

由于海关业务可能会涉及不同种类的数据库存储节点,针对这种情况可以通过单独的协议适配模块进行协议的转换。对上层业务使用标准SQL语句或者其它具体某种

数据库方言均可正常访问。

1.5.5统一接入管理平台

统一接入管理平台主要进行整体接入系统的一些管理工作,比如元数据的存储,监控检测机制,自动化运维模块等。

1.5.5.1配置数据管理

配置数据管理主要存储整体接入系统的一些配置信息,比如集群数据库的一些参数组配置,安全组配置等信息,可以方便的完成集群中部分机器的一些特殊定制配置等需求,给整体系统带来比较大的灵活型。

1.5.5.2应用系统管理

应用系统管理模块对接入的应用和业务进行统一管理。主要包括应用具体的一些接入信息配置,包括应用独立的一些配置数据,注册信息,访问用户权限和角色等。

1.5.5.3逻辑与物理节点管理

统一管理模块会对整个集群的所有物理节点和逻辑节点进行管理,物理节点涉及所有机器的配置信息,运行中的动态负载信息,状态信息等。逻辑节点是暴露给业务使用的一些抽象的逻辑库和逻辑表,并对此进行具体的逻辑到物理节点的映射工作。该模块也是配合路由规则管理模块协同工作的。

1.5.5.4路由规则管理

路由规则即具体分片规则信息,该信息通过统一接入管理平台来进行存储和管理,并通过统一管理平台与逻辑引擎进行交互。业务的路由规则录入与变更首先会通过统一管理平台的管理端界面进行录入和修改,统一管理平台会将变更信息推送给所有的逻辑引擎。并通过内部加锁等机制完成各逻辑节点更新的一致性问题。

1.5.5.5扩容迁移管理

扩容迁移功能是通过统一接入平台来完成的和发起的,监控系统会检测所有物理节点的使用情况,包含数据量和访问量的信息,根据系统当前负载情况判断是否需要进行迁移和扩容工作。当需要进行此项工作时,统一平台会发起迁移任务,迁移任务交由一个工作节点进行线下的物理数据迁移,待到达指定阈值时会通知逻辑引擎进行相关路由的锁定与切换工作,完成迁移和扩容的过程。

1.5.5.6备份管理

备份管理模块会统一调度和进行所管理物理节点的数据全量备份与增量备份工作,具体备份的时间与间隔通过统一平台的管理界面进行配置。全量备份通过操作系统的块设备的快照机制完成,对业务访问无任何感知和影响。增量备份通过数据库的binlog来完成。所有备份文件统一上传至统一存储模块。需要时可以完成快速恢复和容灾。

1.5.5.7接入层节点的水平扩展与容灾

接入层本身单个节点可以提供每秒10W级的高性能访问,可以根据业务访问量的需求或者容灾的考虑来动态增减节点,由于接入层节点是完全无状态的所以动态增减并不会影响上面的应用,上面的应用可以通过类似LVS或者HA的方式来统一访问接入层节点,HA软件会自动对接入层节点进行状态检测,并剔除故障的接入层节点对上层应用无感知。加入新的接入节点对上层应用同样是无感知的。

1.5.5.8存储层

存储层主要解决下列问题:

1.服务的高可用

2.数据的高可靠

3.自动化运维管理

自动化运维平台提供灵活方便的用户管理操作入口,系统基本无需专人运维,大部分的工作是自动化的,一小部分工作通过人员确认一键完成。

1.5.5.9配置数据管理

集群路由和分配以及扩容迁移等信息全部存储在中心节点Manager中,所有路由变更等配置信息统一通过Manager来完成,Manager节点会自动同步路由变更信息给所有的接入节点,并保障接入节点对变更信息的一致性问题,即所有接入节点在任意时刻看到的路由信息都是完全一致的,Manager与接入节点之间通过路由版本号信息来保障这一点。

元数据管理通过主备方式来进行容灾,主节点故障,从节点自动接管工作,对应用完全无影响。

1.5.5.10数据无缝迁移扩容

数据达到一定容量后,通过Transfer模块可以进行自动无缝扩容和迁移工作,迁移模块会分成线上和线下两部分完成,首先进行线下的全量数据及部分增量数据的迁移,待线下数据迁移达到指定阈值后,会进行线上的最后一部分数据追赶及路由切换等工作,应用的访问最终会自动被切换到新的实例上。

迁移过程中会多次对数据进行校验,保障数据迁移的准确性。

1.5.6分布式缓存

分布式缓存出于如下考虑,首先是缓存本身的水平线性扩展问题,其次是缓存大并发下的本身的性能问题,再次避免缓存的单点故障问题(多副本和副本一致性)。分布式缓存的核心技术包括首先是内存本身的管理问题,包括了内存的分配,管理和回收机制。其次是分布式管理和分布式算法,其次是缓存键值管理和路由。

1.5.6.1技术架构

1.5.6.2支持数据类型

提供如下形式的数据:

Key/Value、Set、List、Map、Object

数据之间支持排序和集合运算

1.5.6.3缓存服务

主要包括可分为以下几类: 

1) 页面缓存 

2) 应用对象缓存

3) 状态缓存

4) 分析计算缓存

5)事务处理

1.6数据存储

1.6.1总体描述

本章描述对核心数据,非核心数据等各类不同种类数据的数据处理系统,以及数据存储系统的架构实现。

根据下列数据分类以及各类数据特点制定数据存储的架构方式。

图4-6-1:各种分类维度下的数据分类

1.6.2技术实现

按照不同数据分类下的数据特征(包括数据量,数据价值,以及结构化特征),使用不同的数据存储架构实现数据这些数据的存储和管理。

图4-6-2:各种数据存储架构总览

1.6.2.1核心数据存储架构

 1)数据库管理系统

在采用Oracle11g RAC的基础上,对需要加速的数据处理,通过内存数据库技术融合,以提高系统对核心数据的处理性能。

2)数据存储系统

磁盘阵列:采用SAS盘,支持RAID0.1.5.

    SAN交换机:采用FC协议,SAN采用8Gbps/4Gbps 的带宽。

图4-6-3:核心数据存储架构

表4-6-1 SAN与NAS存储服务的比较

存储层在修改一下,再细分层,各种技术之间的优势(比如SAN,NAS的选择的分析比较)。

1.6.2.2非核心数据存储架构

  1)数据库管理系统

采用MySql Cluster的开源集群数据库处理技术。

  2)数据存储系统

磁盘阵列:采用SAS盘,支持RAID0.1.5.

    SAN交换机:采用FC协议,SAN采用8Gbps/4Gbps 的带宽。

存储技术:通过分层关系描述

图4-6-4:非核心数据存储架构

1.6.2.3分析型数据存储架构

  1)数据库管理系统

采用商用的MPP分布数据库(如Gbase),和Hadoop开源并行数据处理平台的混搭技术。

  2)数据存储系统

   x86 PC服务器上本地磁盘:采用SAS盘,支持24个磁盘(600G),RAID0.1.5.

   MPP网络:采用基于万兆以太网或Infiniband的高速网络。

图4-6-5:分析数据存储架构

1.6.2.4非结构化数据存储架构

  1)数据库管理系统

采用基于Hadoop的开源并行数据处理平台的非结构化数据存储技术。

  2)数据存储系统

  x86 PC服务器上本地磁盘:采用SAS盘,支持24个磁盘(600G),RAID0.1.5.

  Hadoop网络:采用基于万兆以太网或Infiniband的高速网络。

图4-6-6:非结构化数据存储架构

1.7数据计算

1.7.1总体描述

本章描述数据层面上的数据计算架构。从数据层,可以将数据计算分成实时性的流处理模型,和以MapReduce和OLAP多维分析计算为代表的批处理。

1.7.2批处理

满足非实时数据处理业务场景,将批量数据以任务的方式进行处理,并以异步方式提交计算结果,典型场景包括:数据挖掘模型计算、指标引擎计算、OLAP多维分析计算、MapReduce批处理等。

数据挖掘模型计算,可以依靠传统的自我编程实现,但受限于开发水平和开发时间要求,且性能也常常不如商业工具强劲和稳定。目前在中国市场上最为流行的三大数据挖掘软件(SAS公司的Enterprise Miner、IBM公司的Intelligent Miner和SPSS公司的Clementine。在选择合适的数据发掘工具产品时,需要考虑以下几点:数据挖掘是短期使用还是长期行为,数据挖掘经验和水平,数据状态,预算和性能要求。

指标引擎计算与OLAP多维分析计算,可以通过关系型数据库计算引擎,在库内实现。考虑数据量级和计算性能,建议使用完全并行的MPP + Shared Nothing架构数据库产品,由许多松耦合的处理单元组成,以保证每一个节点(node)都是独立的、自给的、节点之间对等,而且整个系统中不存在单点瓶颈,具有非常强的扩展性。技术要求:

1、支持X86 PCserver以及虚拟化环境运行,具有低成本优势;

2、采用列存储和高效透明压缩技术,降低I/O,提高存储能力;

3、具有基于全部字段,自动建立粗粒度智能索引,快速过滤数据包,提高查询性能;

4、具有多种数据分布算法策略,确保数据均匀分布在集群节点上,提高整体批量计算性能;

5、利用多核CPU,多个I/O通道等硬件资源,具有并行加载,并行计算与并行导出等场景的良好性能;

6、具有多种OLAP函数,支持动态hash join,静态hash join等智能算法适配功能,满足强一致性关联要求;

图 2 静态hash join技术

图 3 动态hash join技术

具有高并发特点,有效支撑自助查询等大规模查询服务和批量调度任务;

8、具有线性扩展能力,硬件扩容与计算能力近似线性增长关系。

MapReduce是一种编程模型,用于大规模数据集(大于1TB)的并行运算。概念"Map(映射)"和"Reduce(规约)",主要思想,都是从函数式编程语言里借来的,还有从矢量编程语言里借来的特性。当前的实现是指定一个Map(映射)函数,用来把一组键值对映射成一组新的键值对,指定并发的Reduce(规约)函数,用来保证所有映射的键值对中的每一个共享相同的键组。

实现过程:一个代表客户机在单个主系统上启动的 MapReduce应用程序称为 JobTracker。类似于 NameNode,它是 Hadoop 集群中惟一负责控制 MapReduce应用程序的系统。在应用程序提交之后,将提供包含在 HDFS 中的输入和输出目录。JobTracker 使用文件块信息(物理量和位置)确定如何创建其他 TaskTracker 从属任务。MapReduce应用程序被复制到每个出现输入文件块的节点。将为特定节点上的每个文件块创建一个惟一的从属任务。每个 TaskTracker 将状态和完成信息报告给 JobTracker。

1.7.3流式处理

满足实时处理业务场景,实现数据的实时,高效处理计算。典型产品包括:storm,S4,StreamBase等。

非实时计算几乎都基于MapReduce计算框架,但MapReduce并不是万能的。对于搜索等应用环境中的某些现实问题,MapReduce并不能很好地解决问题。

商用搜索引擎,像Google、Bing和Yahoo!等,通常在用户查询响应中提供结构化的Web结果,同时也插入基于流量的点击付费模式的文本广告。为了在页面上最佳位置展现最相关的广告,通过一些算法来动态估算给定上下文中一个广告被点击的可能性。上下文可能包括用户偏好、地理位置、历史查询、历史点击等信息。一个主搜索引擎可能每秒钟处理成千上万次查询,每个页面都可能会包含多个广告。为了及时处理用户反馈,需要一个低延迟、可扩展、高可靠的处理引擎。然而,对于这些实时性要求很高的应用,尽管MapReduce作了实时性改进,但仍很难稳定地满足应用需求。因为Hadoop为批处理作了高度优化,MapReduce系统典型地通过调度批量任务来操作静态数据;而流式计算的典型范式之一是不确定数据速率的事件流流入系统,系统处理能力必须与事件流量匹配,或者通过近似算法等方法优雅降级,通常称为负载分流(load-shedding)。当然,除了负载分流,流式计算的容错处理等机制也和批处理计算不尽相同。

最近Facebook在Sigmod 11上发表了利用HBase/Hadoop进行实时数据处理的论文,通过一些实时性改造,让批处理计算平台也具备实时计算的能力。这类基于MapReduce进行流式处理的方案有三个主要缺点。

·将输入数据分隔成固定大小的片段,再由MapReduce平台处理,缺点在于处理延迟与数据片段的长度、初始化处理任务的开销成正比。小的分段会降低延迟,增加附加开销,并且分段之间的依赖管理更加复杂(例如一个分段可能会需要前一个分段的信息);反之,大的分段会增加延迟。最优的分段大小取决于具体应用。

·为了支持流式处理,MapReduce需要被改造成Pipeline的模式,而不是Reduce直接输出;考虑到效率,中间结果最好只保存在内存中等。这些改动使得原有的MapReduce框架的复杂度大大增加,不利于系统的维护和扩展。

·用户被迫使用MapReduce的接口来定义流式作业,这使得用户程序的可伸缩性降低。

综上所述,流式处理的模式决定了要和批处理使用非常不同的架构,试图搭建一个既适合流式计算又适合批处理计算的通用平台,结果可能会是一个高度复杂的系统,并且最终系统可能对两种计算都不理想。

数据分析系统整体组成示意图

上图从整个分析系统的架构角度,给出了实时计算子系统所处的位置。实时计算系统和批处理计算系统同属于计算这个大的范畴,批处理计算可以是MapReduce、MPI、SCOPE等,实时计算可以是S4、Storm等,批处理和实时都可以或不依赖统一的资源调度系统。另外,计算系统的输入、输出,包括中间过程的输入、输出,都与存储系统交互,可以是块存储系统HDFS,也可以是K-V存储系统Hypertable等。计算层的上层是数据仓库,或者直接和用户交互,交互方式可以是SQL-like或者MR-like等。

Storm

Storm是一个分布式的、容错的实时计算系统,遵循Eclipse Public License 1.0,Storm可以方便地在一个计算机集群中编写与扩展复杂的实时计算,Storm之于实时处理,就好比Hadoop之于批处理。Storm保证每个消息都会得到处理,而且它很快——在一个小集群中,每秒可以处理数以百万计的消息。可以使用任意编程语言来做开发。主要商业应用及案例:Twitter
Storm的优点
1. 简单的编程模型。类似于MapReduce降低了并行批处理复杂性,Storm降低了进行实时处理的复杂性。
2. 服务化,一个服务框架,支持热部署,即时上线或下线App.
3. 可以使用各种编程语言。你可以在Storm之上使用各种编程语言。默认支持Clojure、Java、Ruby和Python。要增加对其他语言的支持,只需实现一个简单的Storm通信协议即可。
4. 容错性。Storm会管理工作进程和节点的故障。
5. 水平扩展。计算是在多个线程、进程和服务器之间并行进行的。
6. 可靠的消息处理。Storm保证每个消息至少能得到一次完整处理。任务失败时,它会负责从消息源重试消息。
7. 快速。系统的设计保证了消息能得到快速的处理,使用ZeroMQ作为其底层消息队列。
8. 本地模式。Storm有一个“本地模式”,可以在处理过程中完全模拟Storm集群。这让你可以快速进行开发和单元测试。

Storm架构

Storm集群由一个主节点和多个工作节点组成。主节点运行了一个名为“Nimbus”的守护进程,用于分配代码、布置任务及故障检测。每个工作节点都运行了一个名为“Supervisor”的守护进程,用于监听工作,开始并终止工作进程。Nimbus和Supervisor都能快速失败,而且是无状态的,这样一来它们就变得十分健壮,两者的协调工作是由Zookeeper来完成的。ZooKeeper用于管理集群中的不同组件,ZeroMQ是内部消息系统,JZMQ是ZeroMQMQ的Java Binding。有个名为storm-deploy的子项目,可以在AWS上一键部署Storm集群.

Storm的一些常用应用场景

1.流聚合流聚合把两个或者多个数据流聚合成一个数据流 — 基于一些共同的tuple字段。

2.批处理有时候为了性能或者一些别的原因, 你可能想把一组tuple一起处理, 而不是一个个单独处理。

3.BasicBolt
1). 读一个输入tuple
2). 根据这个输入tuple发射一个或者多个tuple
3). 在execute的方法的最后ack那个输入tuple
遵循这类模式的bolt一般是函数或者是过滤器, 这种模式太常见,storm为这类模式单独封装了一个接口: IbasicBolt

4.内存内缓存+Fields grouping组合在bolt的内存里面缓存一些东西非常常见。缓存在和fields grouping结合起来之后就更有用了。比如,你有一个bolt把短链接变成长链接(bit.ly, t.co之类的)。你可以把短链接到长链接的对应关系利用LRU算法缓存在内存里面以避免重复计算。比如组件一发射短链接,组件二把短链接转化成长链接并缓存在内存里面。

5.计算top N
比如你有一个bolt发射这样的tuple: "value", "count"并且你想一个bolt基于这些信息算出top N的tuple。最简单的办法是有一个bolt可以做一个全局的grouping的动作并且在内存里面保持这top N的值。这个方式对于大数据量的流显然是没有扩展性的, 因为所有的数据会被发到同一台机器。一个更好的方法是在多台机器上面并行的计算这个流每一部分的top N, 然后再有一个bolt合并这些机器上面所算出来的top N以算出最后的top N。

这个模式之所以可以成功是因为第一个bolt的fields grouping使得这种并行算法在语义上是正确的。用TimeCacheMap来高效地保存一个最近被更新的对象的缓存

6.用TimeCacheMap来高效地保存一个最近被更新的对象的缓存有时候你想在内存里面保存一些最近活跃的对象,以及那些不再活跃的对象。 TimeCacheMap 是一个非常高效的数据结构,它提供了一些callback函数使得我们在对象不再活跃的时候我们可以做一些事情.

7.分布式RPC:CoordinatedBolt和KeyedFairBolt
用storm做分布式RPC应用的时候有两种比较常见的模式:它们被封装在CoordinatedBolt和KeyedFairBolt里面. CoordinatedBolt包装你的bolt,并且确定什么时候你的bolt已经接收到所有的tuple,它主要使用Direct Stream来做这个.
KeyedFairBolt同样包装你的bolt并且保证你的topology同时处理多个DRPC调用,而不是串行地一次只执行一个。

S4

S4是一个通用的、分布式的、可扩展的、分区容错的、可插拔的流式系统。基于S4框架,开发者可以轻松开发面向持续流数据处理的应用。

S4的设计特点有以下几个方面。

·Actor Model

为了能在普通机型构成的集群上进行分布式处理,并且集群内部不使用共享内存,S4架构采用了Actor模式,这种模式提供了封装和地址透明语义,因此在允许应用大规模并发的同时,也提供了简单的编程接口。S4系统通过处理单元(Processing Elements,PEs)进行计算,消息在处理单元间以数据事件的形式传送,PE消费事件,发出一个或多个可能被其他PE处理的事件,或者直接发布结果。每个PE的状态对于其他PE不可见,PE之间唯一的交互模式就是发出事件和消费事件。框架提供了路由事件到合适的PE和创建新PE实例的功能。S4的设计模式符合封装和地址透明的特性。

·Decentralized and Symmetric Architecture

除了遵循Actor模式,S4也参照了MapReduce模式。为了简化部署和运维,从而达到更好地稳定性和扩展性,S4采用了对等架构,集群中的所有处理节点都是等同的,没有中心控制。这种架构将使得集群的扩展性很好,处理节点的总数理论上无上限;同时,S4将没有单点容错的问题。
Pluggable Architecture
S4系统使用Java开发,采用了极富层次的模块化编程,每个通用功能点都尽量抽象出来作为通用模块,而且尽可能让各模块实现可定制化。

·Partial Fault-Tolerance

基于Zookeeper服务的集群管理层将会自动路由事件从失效节点到其他节点。除非显式保存到持久性存储,否则节点故障时,节点上处理事件的状态会丢失。

·Object Oriented

节点间通信采用“Plain Old Java Objects”(POJOs)模式,应用开发者不需要写Schemas 或用哈希表来在节点间发送Tuples。

S4的功能组件分3大类,Clients、Adapters和PNode Cluster,图2显示了S4系统框架。

Yahoo! S4流式系统框架结构图

S4提供Client Adapter,允许第三方客户端向S4集群发送事件和接收事件。Adapter实现了基于JSON的API,支持多语言实现的客户端驱动。

Client通过Driver组件与Adapter进行交互,Adapter也是一个Cluster,其中有多个Adapter结点,Client可以通过多个Driver与多个Adapter进行通信,这样可以保证单个Client在分发大数据量时Adapter不会成为瓶颈,也可以确保系统支持多个Client应用并发执行的快速、高效和可靠性。

在Adapter中,真正与Client交互的是其Stub组件,该组件实现了管理Client与Adapter之间通过TCP/IP协议进行通信的功能。GenericJsonClientStub这个类支持将事件在Client与Adapter之间以JSON的形式转换,从而支持更多种类型的Client应用。不同的Client可以配置不同的Stub来与Adapter进行通信,用户可以定义自己的Stub来实现自己想要的业务逻辑,这样也使得Client的行为更加多样性、个性化。

StreamBase

StreamBase是IBM开发的一款商业流式计算系统,在金融行业和政府部门使用,其本身是商业应用软件,但提供了Develop Edition。相对于付费使用的Enterprise Edition,前者的功能更少,但这并不妨碍我们从外部使用和API接口来对StreamBase本身进行分析。

StreamBase使用Java开发,IDE是基于Eclipse进行二次开发,功能非常强大。StreamBase也提供了相当多的Operator、Functor以及其他组件来帮助构建应用程序。用户只需要通过IDE拖拉控件,然后关联一下,设置好传输的Schema并且设置一下控件计算过程,就可以编译出一个高效处理的流式应用程序了。同时,StreamBase还提供了类SQL语言来描述计算过程。

StreamBase组件交互图

StreamBase Server是节点上启动的管理进程,它负责管理节点上Container的实例,每个Container通过Adapter获得输入,交给应用逻辑进行计算,然后通过Adapter进行输出。各个Container相互连接,形成一个计算流图。

Adapter负责与异构输入或输出交互,源或目的地可能包括CSV文件、JDBC、JMS、Simulation(StreamBase提供的流产生模拟器)或用户定制。每个StreamBase Server上面都会存在一个Sytsem Container,主要是产生系统监控信息的流式数据。

HA Container用于容错恢复,可以看出它实际包含两个部分:Heartbeat和HA Events,其中HeartBeat也是Tuple在Container之间传输。在HA方案下,HA Container监控Primary Server的活动情况,然后将这些信息转换成为HA Events交给StreamBase Monitor来处理。

Monitor就是从System Container和HA Container中获取数据并且进行处理。StreamBase认为HA 问题应该通过CEP方式处理,也就是说如果哪个部件出现问题,就肯定会反映在System Container和HA Container的输出流上面,然后 Monitor通过复杂事件处理这些Tuples的话就能够检测到机器故障等问题,并作出相应处理。

StreamBase提出了以下4种模板策略来解决容错问题。

·Hot-Hot Server Pair Template

Primary Server和Secondary Server都在同时计算,并且将计算结果交给下游。优点是Primary Server如果故障的话那么Secondary Server依然工作,几乎没有任何切换时间;并且下游只需要选取先到来的Tuple就可以处理了,保证处理速度最快;缺点是浪费计算和网络资源。

·Hot-Warm Server Pair Template

Primary Server和Secondary Server都在同时计算,但只有Primary Server将计算结果交给下游。优点是如果Primary Server故障,Secondary Server可以很快切换,而不需要任何恢复状态的工作。相对于Hot-Hot方式时间稍微长一些,但没有Hot-Hot那么耗费网络资源,同时也浪费了计算资源。

·Shared Disk Template

Primary Server在计算之后,将计算的一些中间关键状态存储到磁盘、SAN(Storage Area Network)或是可靠的存储介质。如果Srimary Server故障,Secondary Server会从介质中读取出关键状态,然后接着继续计算。优点是没有浪费任何计算和网路资源,但恢复时间依赖状态的量级而定,相对于前两种,恢复时间可能会稍长。

·Fast Restart Template

这种方案限定了应用场景,只针对无状态的应用。对于无状态的情况,方案可以非常简单,只要发现Primary Server故障,Secondary Server立即启动,并接着上游的数据流继续计算即可。

Borealis

Borealis是Brandeis University、Brown University和MIT合作开发的一个分布式流式系统,由之前的流式系统Aurora、Medusa演化而来。目前Borealis系统已经停止维护,最新的Release版本停止在2008年。

Borealis具有丰富的论文、完整的用户/开发者文档,系统是C++实现的,运行于x86-based Linux平台。系统是开源的,同时使用了较多的第三方开源组件,包括用于查询语言翻译的ANTLR、C++的网络编程框架库NMSTL等。

Borealis系统的流式模型和其他流式系统基本一致:接受多元的数据流和输出,为了容错,采用确定性计算,对于容错性要求高的系统,会对输入流使用算子进行定序。

Borealis的系统架构图

·Query Processor(QP)是计算执行的地方,是系统的核心部件,其大部分功能继承自Aurora。

·I/O Queues将数据流导入QP,路由Tuples到其他节点或客户端程序。

·Admin模块用来控制本地的QP,例如建立查询、迁移数据流图片段,该模块也会同Local Optimizer协作优化现有数据流图。

·Local Optimizer职责包括本地调度策略、调整Operator行为、超载后丢弃低价值元组等。

·Storage Manager模块用于存储本地计算的状态数据。

·Local Catalog存储本地数据流图和元数据,可以被本地所有组件访问。

·Borealis Node还有彼此通信的模块用于执行协作任务。

·Neighborhood Optimizer使用本地和邻居节点来优化节点间的负载均衡或shed load。

·High Availability (HA)模块相互监测,发现对方故障时及时代替对方。

·Local Monitor收集本地性能相关统计数字报告给本地和Neighborhood Optimizer。

·Global Catalog为整个数据流计算提供了一个逻辑上的完整视图。

除作为基本功能节点外,Borealis Server也可以被设计成一个协作节点来执行全局的系统监控和其他优化任务,比如全局的负载分布和Global Load Shedding,因此Borealis实际上提供了完整的3级监控和优化(Local、Neighborhood、Global)。

负载均衡方面,Borealis提供了动态和静态两种部署机制。

·Correlation-based Operator Distribution

通过分析不同Operators和Nodes间的负载变化的关系,决定和动态调整Operatpr的部署,使之达到负载均衡。

·Resilient Operator Distribution Algorithm

该算法的目标是提供一种静态的Operator部署方案,该方案能够在不需要重新调整的情况下处理最大可能的输入速度变化范围。

由于动态调整需要时间和消耗,前者适用于负载变化持续时间较长的系统;而后者则能处理较快较短的负载峰值。在实现上前者使用相关系数作为节点关联度指标,并通过贪婪算法将NP问题转化为多项式求解;而后者在部署前计算完毕,保证系统能够容忍负载峰值。该算法在线性代数上建模,包括Operator Ordering、Operator Assignment两个阶段。

Borealis通过四种容错机制来满足用户需求。

·Amnesia Backup

备机发现主机故障,立即从一个空的状态开始重做。

·Passive Standby

主机处理,备机待命,主机按周期做Checkpoint,主机故障后切换到备机,重放Checkpoint和数据流,对于不确定性计算可以很好地支持,缺点是恢复时间较长。

·Active Standby

主备机同时计算,主机故障时直接切换到备机,不支持不确定性计算,浪费计算资源,不过恢复时间几乎没有。

·Upstream Backup

通过上游备份来容错,故障时从上游重放数据即可,恢复时间最长,不过最节省资源。

除此之外,Borealis还提供了更高级的容错机制Rollback Recovery,它是一种基于副本在节点失效、网络失效或网络分区时的故障恢复机制,在尽量减少系统不一致的情况下,尽可能地保证系统的可用性。该机制允许用户定义一个阈值来在一致性和可用性之间做一个平衡。当系统数据恢复后,系统支持重新计算输出正确的结果,保证最终一致性。该机制使用了Data-serializing Operator(SUnion)来确保所有的副本处理同样顺序的数据。当失效恢复后,通过Checkpoint/Redo、Undo/Redo来实现恢复重放。

小结

storm

Yahoo! S4的最新版本是Alpha version v0.3.0,动态负载均衡和在线服务迁移等重要功能都尚未实现,不过其代表性的3个特点值得学习,Actor模式、非中心化的对称结构及可插入式的架构。

StreamBase是有着功能强大的IDE并且支持控件式的方法来搭建应用程序,同时还提供了高级语言来搭建应用程序的方法。由于是商业产品,其用户接口的精彩设计值得借鉴,同时其可组合的HA方案也是亮点之一。
    Borealis是学术界研究的重要产出,它对新一代的流式系统涉及的诸多方面,如系数据模型、负载管理、高可用性、可扩展性都作了全面和翔实的研究,一方面系统变得强大、先进,另一方面使得系统也变得臃肿、复杂。这套系统的许多策略都值得我们学习,可以应用于不同的流式计算场景。

1.8数据服务

1.8.1总体描述

数据服务主要解决将企业的资源信息共享出来,能够为企业服务,但是企业信息多样化,某一个团队很难理解企业所有的业务信息,因此数据服务平台提供一个开放的开发服务平台,用户可以在数据服务平台创建相关的主题域,做与其业务相关的主题分析而无需平台的运维和开发人员参与。

本平台主要有数据服务层、平台服务层和数据接入层。数据服务层主要是对外提供数据服务;平台服务层提供对元数据的管理、数据的开发和数据服务的接口的实现;底层接口层因数据平台本身不产生原始数据,原始数据来源于数据计算模块,将数据计算的结果导入到数据平台,数据平台在此数据做相关的分析之后提供给用户,或者用户直接在此平台做数据的开发分析。

1.8.2数据访问接口

目前对外提供的数据服务的方式主要有两类:

1.图形表格的方式

2.接口API的方式

两类方式服务接口针对不同的用户使用需求,对同一份数据使用者可以通过API的方式获取数据或者通过图表的方式直接将相关的图表信息嵌入到应用之中。

1.8.3数据服务管理

1.8.3.1数据管理

1.8.3.1.1数据字典

可以根据表名、字段名、表描述、字段描述快速定位到表,便于查看数据表信息,支持模糊查询。

1.8.3.1.2数据申请

可以通过这个页面对数据主题进行申请,需要填写相关的申请目的、理由,并可以上传PRD、MRD。目前对上传文件格式限制是:doc,docx,ppt,pptx。同一时间,只允许提交一个申请,需要等待审核完成后(不论是否通过)才能进行下一次的申请。

申请提交完毕后,运营人员在管理平台,进行审核,确定是否开放权限,给予审核意见。

1.8.3.2数据开发

数据集市中的内容多样化,内容从业务的角度来说是多样的,不同的主题域有不同的分析方法和分析手段。因此在基于各个业务会有相应的分析模型。数据开发为不同的业务分析员提供了通用的分析平台。因此需要对开发的平台程序进行管理。本章节主要介绍:目录管理、程序管理、数据库表管理。

1.8.3.2.1目录管理

当用户登录平台之后,进入数据开发模块,用户需要在该平台开发程序,首先要在平台能够管理自己的程序,因此在本模块提供了类似操作系统管理其文件的方式来管理用户程序。

在目录管理功能部分,提供用户能够创建目录、修改目录名称、删除目录和移动目录的功能。

创建目录是在目录结构中增加一个新目录。当用户登录系统之后,用户希望在哪里创建目录,选择进入某个目录,在该目录下用户可以创建新的目录,当前目录与创建的新目录是父子关系,创建目录包括目录的名称。

修改目录是修改某一目录的名称。当用户登录系统之后,用户希望休改哪个目录名称,选择要修改的目录之后,可以直接修改。修改目录仅仅修改目录的名称,其父目录和包含的子目录、文件与其关系不变。

删除目录是删除一个空的用户目录。当用户登录系统之后,用户选择希望删除的目录,可以进行删除目录操作。待删除的目录不能包含有文件或者子目录,否则不允许删除,把待删除目录包含的子目录和文件移动到别的目录下之后才能进行删除操作。

目录移动是将一个源目录移动到一个目标目录。当用户登录系统之后,用户选择希望移动的源目录和目标 目录之后,用进行移动目录操作,用户将源目录下的所有的子目录和文件都移动到目标目录上。

1.8.3.2.2程序管理

因为数据服务本身能够提供的数据功能是有限的,或者说只是能够提供一些很通用的功能,更多的业务相关的功能需要业务开发人员来开发。因此,数据服务更多的是提供一个开放的平台,允许用户在该平台做相应的主题域的数据开发来满足业务的需要。程序管理主要包含程序创建、程序删除、程序内容修改、程序名称修改、程序文件移动和程序试运行等方面在创建管理和试运行改程序。

1)程序创建

程序创建是用户根据业务的要求,创建某个业务主题的程序,提取与其业务相关的数据。用户登录系统之后,用户可以选择某个目录,当用户确定要在该目录下创建程序之后,用户可以操作创建程序,用户可以输入程序的名称和一个可以编辑程序的数据输入框,创建的程序一般为比较简单的脚本,比如:SQL脚本、groovy脚本和R语言脚本。当用户编辑完脚本之后,保存即完成用户程序的开发。

2)程序删除

程序删除是删除用户已经开发好的程序,一般程序发布之后就不能删除了,发布作为一种契约,一旦发布成功,就同意对外提供服务了。用户登录系统之后,找到希望删除的程序,进行删除操作即可以。

3)程序内容修改

程序内容修改是因为程序在运行的过程中有bug或者是业务的变更,要求程序做相应的修改来满足业务的要求。用户登录系统之后,选择某个程序之后,用户即可以对程序进行修改,修改完成之后保存即可。用户对同一程序内容的修改次数是多次的。

4)程序名称修改

程序名称修改是修改程序的名称,在程序开发的时候给程序起名,但是在后来的业务讨论的过程中发现该程序名并不能准确的表达该程序实际的功能,因此需要修改该程序名称。当用户登录到该平台之后,找到要修改的程序之后,可以直接修改其名称。在同一个目录下不能有相同的文件名称。

5)程序文件移动

程序文件移动是为了程序管理的方便,程序文件能够移动到不通的目录下。当用户登录到平台之后,用户选着要移动的文件然后将其移动到目标目录上即可。

程序执行是程序开发完成之后,可以随时执行,但是这个执行需要人工触发才能执行。当用户登录到平台之后,用户选择其要执行的文件,触发 该文件的执行操作即可。

1.8.3.2.3数据表管理

数据表在整个数据服务平台中为用户提供一个自己建模的工具,为用户能够独立分析其业务提供了方便的手段。用户建表从数据相对于数据服务平台出入来说,用户可以建表将用户关心的数据导入到数据平台与其他的数据一起分析;用户也可以建立一个模型将程序处理的结果放置在中间表中,方便用户的访问。

数据表管理主要有如下功能:数据表创建、数据表查询和数据表删除功能。用户操作的数据表是用户创建的数据表和经过授权能够做DDL操作的数据表。

1)数据表创建

用户了方便其分析业务,创建与其主题域相关的事实表是维表来适应业务的分析而创建相应的表。用户登录系统之后用户可以操作创建用户表格。创建用户表格需要满足如下基本属性要求:

1、表的名称,表名称不能重复

2、表所在的主题域

3、表中数据保存的时间

4、表的描述信息,

表的字段属性信息:

1、字段的名称

2、字段的数据类型

3、字段的描述。

将相关的信息填写完整之后,保存即该表创建成功,如若保存失败则该表创建失败。需要重新创建。

2)数据表查询

数据表查询是用户能够根据一定的条件查询其有权限能够看到的表结构信息。当用户登录到数据服务平台之后,能够看到其有权限的数据模型的详细信息。默认的数据表分类为公共的和自己创建的两类数据表。数据表的查询默认是查询出数据的列表,数据查询查询条件输入数据表的名称可做模糊查询。

3)数据表删除

数据表删除是用户删除其编写错误或者不在使用的数据表。当用户登录到数据服务平台之后,通过查询可定位用户想删除的数据表。用户能够删除的数据表是用户自己创建的数据表格,其他的表格用户有权限查看,但是没有权限操作。

1.8.3.3数据服务管理

用户在数据开发模块开发出很多程序,这些程序如何在数据服务平台运行,用户如何获取程序运行的结果,或者用户开发出的程序需要多个程序进行编排之后才能满足业务的要求。

在数据服务模块主要将用户程序发布为服务并且能对这些服务进行管理和编排。本章节主要的功能,程序列表,任务管理和服务管理。服务是对外提供用户希望的信息,信息由任务按照一定的策略运行的结果。数据结果是从原始的信息经过用户的程序进行逻辑处理的结果。

本章后续部分按照程序管理,任务管理和服务管理来完成后续小节的编写。

1.8.3.3.1程序列表

程序列表是是对上述章节开发的程序进行集中的展现和管理,查看各个程序的状态比如是否以及部署成功。

主要根据一定的条件查询用户的程序情况,查询条件一般有程序的名称、程序的发布时间段和程序的发布状态。可以定位用户关心的程序。了解其关系的程序的状态,如程序分类、程序接入的数据表、程序的部署状态是否需要部署后者直接作为一个任务使用。

1.8.3.3.2任务管理

任务管理主要是对编写的程序进行部署管理,上线、下线、审核及运行情况的监控。总的来说主要是程序的部署,部署情况和运行情况。

1)任务创建

任务创建是将程序部署为按照一定的策略运行的任务。当程序部署为任务时,需要有审核,只有审核通过之后,任务才能够根据其策略变成一个可以执行的任务,否者一直处于一个待审核的任务。

一个程序发布为一个任务需要的条件:

i.任务名称

ii.运行策略

iii.关联程序

iv.依赖的任务

v.数据结果

任务的创建者将其中的条件填写完成之后,提交部署即为一个待审核的任务。此时用户等待审核通过即可。

2)任务列表

任务列表主要列出用户相关的任务或者是该用户有权限的任务,列出任务的目的主要是对静态任务进行操作。

列出任务的相关信息:

i.任务名

ii.称任务ID

iii.关联程序

iv.产出的结果表

v.任务提交时间

vi.分类

vii.状态

viii.操作

主要的操作有任务审核,所谓的审核主要是审核发布的程序及其相关数据的审核,程序所关联的数据是否能够开放,如果不能开放,需要修改程序,再次审核。

审核通过的任务试运行,当程序审核通过之后,用户可以试运行该任务,主要是用户手工触发,看看任务在生产环境下是否能够正常运行以及任务的运行结果是否正确,如果任务试运行通过之后,以后任务可以按照其策略来运行。

对于按照策略运行的任务用户可以对其管理,比如对任务进行上下线管理,在某个时间段可能不需要某个任务的运行,因此用户可以对该任务进行下线操作。对下线的任务,用户可以恢复为上线运行状态。

主要操作如下:

i.编辑任务

ii.删除任务

iii.上线任务

iv.查看审核未通过原因

v.停止部署

vi.下线任务

vii.任务详情

viii.所依赖的任务

1.8.3.3.3运行任务管理

任务运行管理主要是对运行态的任务进行管理,一般来说,一个任务的运行的时间可能会运行的时间较长,当发现其中的原始的数据出现异常的是否,需要对运行的任务进行停止器运行等等操作。

首先,需要根据一定的条件找到正在运行的任务,一个任务可能会有多人运行实例,查询条件:

i.任务名称模糊查询

ii.任务开始运行时间(时间范围)

查询出来的任务列表:

i.任务名称    

ii.任务ID 任

iii.务实例ID   

iv.运行开始时间   

v.运行结束时间   

vi.运行状态    

vii.操作

运行态的任务支持:

任务支持重跑功能

可查看任务日志内容

可查看任务依赖关系运行情况

1.8.3.4服务管理

服务管理主要是将运行的结果以服务的方式开发给用户,无论我们的服务的个数如何多总之永远也不会满足用户服务的要求,因此我们是否能够定义一个或者几个服务,通过一个标示来确定用户请求的数据。

数据服务中有一个很大的特点,绝大多数情况下,用户是只是查询其中的数据,因此可以设计固定的服务,通过接口的Id标示来区分数据。类似于同一个服务,针对不同的数据有不同的实现方式。下面部分从接口管理来说明.

1)接口创建和发布

当任务发布成功,并且上线运行之后,仅是将需要的数据每天按时的计算出来,并保存在目标模型中,需要一个数据接口来进行读取、调用,才能被APP所使用。

接口创建是绑定接口和其相关数据的过程,主要有接口名称、接口相关的参数、接口描述及接口的标示,当接口相关的参数输入之后保存,只有接口发布之后才生产接口标示,应用通过此标示来访问相应的数据。

功能:

当接口相关的数据填入之后,可以做快速测试。

当接口相关的数据填入之后,可提交发布。如有信息不确定,则可以保存,后续编辑。发布成功之后则可以在APP中调用。

2)接口列表

   对已开发的数据接口进行管理,数据接口有未发布、已上线、已下线三个状态。接口列表主要是查询到该用户自己创建的接口或者有权限的接口,默认情况按照时间顺序倒序列出。可以按照接口的名称或者发布的时间查询。

列表展示的数据属性:

i.接口名称

ii.接口标示

iii.接口结果表

iv.接口申请时间

v.操作

未发布:在数据接口开发界面点击保存后变为未发布状态,或在已下线状态进行停止部署状态变为未发布状态。此状态可以进行编辑修改、详情查看、发布部署、删除操作。

已上线:在数据接口开发界面点击提交发布进入已上线状态,在未发布状态进行发布操作进入已上线状态,在已下线状态进行上线操作变为已上线状态。此状态可以进行下线操作,详情查看操作。

已下线:在上线状态的任务,进行下线操作后变为已下线状态。此状态可以进行停止部署、删除、上线操作。

1.8.4基础服务

基础服务主要从技术层面讲述,平台如何支持用户的多样的需求。主要从图形工具、程序执行框架、服务发布框架、流程引擎等几个方面描述。

1)图形工具

主要是在数据服务层,如何将用户的数据转换成一个柱状图、饼状图、折线图或者是一个数据表格的形式。

对该技术的要求,平台能够提供各类图形或者报表的模版,根据用户提供的数据并且选择其中的摸个模版,比如折线图模版这时候数据就会和模版结合产生一个该数据的折线图。

主要技术是展现和数据的分离,比如目前表常用的是Flex开发一些图像模版,把数据以XML格式、JSON格式输入给该图形模版,即可以出现相应的图形。

2)程序执行框架

流程执行框架主要在平台服务层中使用,平台提供一个用户数据开发功能,当用户在数据服务平台开发一个程序或者在外部开发一个程序之后,需要在数据服务平台执行,并将执行的结果保存在中间表中。

     比如,用户开发一个程序,如SQL脚本、Groovy脚本或者是一个外部的Java程序的jar包。需要数据服务平台提供SQL脚本执行的环境;Groovy脚本执行的环境来编译和运行Groovy脚本程序;需要Java Classload容器来来加载Java的jar包并且能够执行Java程序。

3)服务发布框架

服务发布框架主要在平台服务层中使用,用户开发完程序之后,并且在数据服务平台发布成功作为一个可以执行的任务,其按策略执行的结果保存在数据服务平台的结果表中,如何将该表中的数据以服务的形式发布出来,用户在APP中可以使用该程序。

1.8.5底层接口层

数据服务平台在前面讲过平台本身不收集原始的数据,只是将数据计算平台的数据

1.8.6事务处理类数据服务

1.8.7分析类数据服务

1.8.7.1报表

采用四种形式的报表为高层领导提供辅助决策支持,监控运营状况,提高分析、决策效率,合理预算,减少失误:

1.列表式报表

报表内容按照表头顺序平铺式展示,便于查看详细信息。一般基础信息表可以用列表式体现。多用于展示客户名单、产品清单、物品清单、订单、发货单等单据或当日工作记录,当日销售记录等记录条数比较少的数据。

2.摘要式报表

使用频率最高的一种报表形式,多用于数据汇总统计。如按人员汇总回款额、客户数等;按日期分组汇总应收额、回款额等。.摘要式报表和列表式报表唯一的差别是多了数据汇总的功能。

3.矩阵式报表

主要用于多条件数据统计。如:按照客户所有人和客户所属地区两个值汇总客户数量。矩阵式报表只有汇总数据,但是查看起来更清晰,更适合在数据分析时使用。

4.钻取式报表 - 多维报表

是改变维的层次,变换分析的粒度。它包括向上钻取和向下钻取。例如对于各地区各年度的销售情况,可以生成地区与年度的合计行,也可以生成地区或者年度的合计行。

报表分析架构

将多个业务系统中数据在数据仓库中集中后,需要按照一定的逻辑进行数据的再组织,这个组织的依据就是主题。即按照不同的粒度和归类来分析数据,将原有的报表式分析转化为维度模型,多角度化分析。

可以把决策者关注的关键指标作为事实表的量度。申报人、申报日期等则是观察这些量度的视角,把它们作为维度,形成一个星形结构的模型。照此建立的数据仓库可以汇总各个层次管辖的申报人的缴税情况等,也可以从税管员、税种等角度按照各种层次进行分析汇总。

决策部门可以从多维分析(需要、方式、机遇、风险等)和纳税管理当中各项关键指标(KPI)做出分析与评估,以便于为管理投入赢得最大的回报。

1.8.7.2数据统计、挖掘

数据统计、挖掘是指从数据中心的大量数据中揭示出隐含的、先前未知的并有潜在价值的信息的非平凡过程。

数据统计、挖掘是一种决策支持过程,它主要基于人工智能、机器学习、模式识别、统计学、数据库、可视化技术等,高度自动化地分析企业的数据,做出归纳性的推理,从中挖掘出潜在的模式,帮助决策者调整管理策略,减少风险,做出正确的决策。

最常用的数据统计、挖掘分析包括分类、预测、聚类分析以及序列分析等。预测是通过分类或估值起作用的,也就是说,通过分类或估值得出模型,该模型用于对未知变量的预言。预言其目的是对未来未知变量的预测,这种预测是需要时间来验证的,即必须经过一定时间后,才知道预言准确性是多少。

计算预测期的税收预测值,并进行细致、深入的统计分析,使用的方法包括:平均速度外推预测法、加权平均外推法、一元线性回归预测法、多元线性回归预测法、非线性预测法、时间序列预测法、混合模型预测等。根据税收数据的特点,也可以采用分类预测的方法:可以对各税种进行单独的收入预测,再综合为总收入的预测值;也可以对各行业的税收收入进行预测,再综合为总收入的预测值;或者对各类重点户的税收收入进行预测,再综合为总收入的预测值等等。

通过税收计划管理可以监控全年各时间段的税收,了解税收完成情况,及时掌握实际情况与计划分解值之间的差异,并进行进度汇总。

1.8.8数据共享服务

1.8.9数据交换服务

1.8.10元数据服务

1.8.10.1支撑架构

1.8.10.2提供服务

存取服务:

集成服务:

分析服务:

1.8.11主数据服务

1.8.11.1支撑架构

主数据服务架构

1.8.11.2提供服务

1.9数据治理

1.9.1数据治理体系

数据治理是指将零散数据变为统一数据,将具有很少或没有组织和流程的数据变为企业范围内的综合数据、将数据从混乱状况变为井井有条的一个过程。这个过程实际是上形成一种体系,这一体系的目的是整合IT与业务部门的知识和意见,通过一个类似于监督委员会或项目小组的虚拟组织对企业的信息化建设进行全方位的监管,这一组织的基础是企业高层的授权和业务部门与IT部门的建设性合作。从范围来讲,数据治理涵盖了从前端事务处理系统、后端业务数据库到终端的数据分析,从源头到终端再回到源头形成一个闭环负反馈系统。

数据治理体系建设的目的,是建立数据拥有者、使用者、数据以及支撑系统之间的和谐互补关系,从全机构视角协调、统领各个层面的数据管理工作,确保内部各类人员能够得到及时、准确的数据支持和服务。通常认为,数据治理至少应当涵盖如下功能域:信息资源目录管理、主数据管理、元数据管理、数据质量管理、数据标准管理以及数据生命周期管理。

数据治理体系在数据架构中的定位:

数据治理体系中各功能之间逻辑关系如下图所示:

1.9.2信息资源目录管理

信息资源目录是对信息主体结构的描述,应用于信息资源的采集、加工、存储、保护和使用等过程。需要通过信息资源目录实现对信息资源的发现、获取、导航、定位、分发等功能,以支持各业务部门之间信息资源的交换与共享。

信息资源目录以元数据为核心,以政务分类表和主题词表为控制词表,对信息资源进行网状组织,满足从分类、主题、应用等多个角度对信息资源进行管理、识别、定位、发现、评估与选择的工具。建立信息资源目录体系将便于掌握信息资源的分布状况,实现对信息资源建设的统一规划。基于海关信息资源积累成果,对其现状架构进行全面梳理、分析和优化,采纳“业务域-实体-数据元”三级目录模式,建立形成海关信息资源管理“统一底账”。

系统功能架构

1、信息资源的分析功能。用户分析,提供者、管理着、使用者三类用例分析,规划、编目、注册、发布、查询、维护六类其中编目十分重要,需结合不同的信息资源分类方式进行分析,如按业务体系分类、按组织结构分类、按数据来源分类、按使用角色和用途分类、按数据格式分类等。

2、信息资源的管理功能。

(1)创建目录树:创建不同分类目录树的基本结构。

(2)目录结构维护:添加目录条目、添加子树、目录变更等

(3)叶节点管理:将叶结点的元数据导入到系统中,系统对文件进行解析,创建元数据与叶结点的关联,可将元数据赋予叶结点。如果叶结点不存在,系统可进根据目录条目的规则和元数据自动建立叶节点,如果叶节点已存在则覆盖或保留。

(4)同义词管理

(5)目录管理节点维护:主要用于维护中央地址路由目录服务器中当前数据节点下属的分中心节点的路由信息,包括节点目录服务器的网络地址、节点标识、节点的挂接点(父节点)标识、节点的地理位置信息等。

3、信息资源的目录服务。信息资源目录服务可以分为3个服务,分别为目录传输、目录数据管理和目录内容发布。

4、信息资源的安全控制

(1)授权访问。实现授权访问功能,权限是指目录的访问级别,只有在被授予相应的权限后,用户才能够查看资源目录的内容,不同的角色看到的和可操作的内容各不相同。

(2)访问审计。实现访问审计功能,记录用户对资源目录的访问情况,包括哪些用户访问了目录,进行了哪些操作,查看了哪些信息等。

1.9.3主数据管理

主数据是指描述核心业务实体的数据,如客户、机构、员工、产品等。这些数据变化相对缓慢并通常在企业内跨业务重复使用。主数据管理适用于管理、协调、监控与企业主要业务实体相关联的主数据的一系列规则、技术、应用、策略和程序。

海关主数据包括两类,一类是海关业务基础数据,具有更新周期相对缓慢而使用周期相对较长、被跨业务部门共享使用、从源应用系统集成而来、现势性要求高、非交易记录数据等特点,如海关注册企业、海关商品信息、海关关员、海关报关员、运输工具等。一类是海关参数数据,是海关所有应用系统的值域字典数据,如海关机构代码。

主数据管理的功能包括:主数据采集、主数据订阅管理、主数据维护、主数据变更管理、主数据版本管理、主数据查询、主数据统计分析、规则管理、运行监控、配置管理。

1.9.4元数据管理

元数据管理:元数据是指关于数据的数据,即对数据的描述信息。根据其属性的不同,元数据可分为技术元数据和业务元数据。元数据管理是元数据的定义、收集、管理和发布的方法、工具及流程的集合,通过完成对相关业务元数据及技术元数据的集成及应用,提供数据路径、数据归属信息,并对业务术语、文档进行集中管理,借助变更报告、影响分析以及业务术语管理等应用,以此保证数据的完整性、控制数据质量、减少业务术语歧义和建立业务人员之间、技术人员之间,以及双方的沟通平台。

元数据管理包括元数据采集、元数据维护、元数据变更管理、元数据质量管理、元数据版本管理、标准术语管理、元数据查询、元数据统计、血缘分析、影响分析、差异分析、元数据架构模型管理和接口服务等功能。

元数据驱动的全生命周期管理是支持业务建模、分析、设计、开发、测试、组装、发布、部署、运行监控等应用开发过程的。实现各种管理工具、设计器、监控工具,以及软件配置管理。采用模型驱动开发的方式,通过上一阶段的输出与下一阶段的输入结合起来,通过可视化的设计器或工具将开发过程串接起来,大大降低了开发的难度,并降低各个阶段之间的鸿沟以及不一致性。

元数据模型描绘出业务的原始状态,业务信息的载体就是最基本的数据实体,建立实体把所有业务信息的含义清晰的展现在用户面前,再通过描述实体的操作来表达业务功能,灵活的信息描述让企业信息可扩展可配置,并且实体间是支持多种聚合的复杂关系。业务对象元模型按照模块-组件-实体三层关系进行组织。

图4-9-4元数据框架图

上图所示实体模型存储在元数据仓库中,元数据框架支持访问服务、开发服务、管理服务,支持建模开发工具整合与适配其它系统模型数据。元数据提供统一的查询服务使所有应用清楚的使用统一的实体,基于元数据的访问及持久化让信息的保存查询更加方便透明,通过元数据生成相关代码及数据库脚本加快了开发,使平台上的开发者只需要关注业务逻辑,让业务与技术分离。

1.9.5生命周期管理

在数据的整个生命周期中,不同的数据需要不同水平的性能、可用性、保护、迁移、保留和处理。通常情况下,在其生命周期的初期,数据的生成和使用都需要利用高速存储,并相应地提供高水平的保护措施,以达到高可用性和提供相当等级的服务水准。随着时间的推移,数据的重要性会逐渐降低,使用频率也会随之下降。伴随着这些变化的发生,我们就可以将数据进行不同级别的存储,为其提供适当的可用性、存储空间、成本、性能和保护,并且在整个生命周期的不同阶段都能对数据保留进行管理。

随着海关科技信息化建设的深入开展,各种电子信息系统不断上线运行,越来越多的通关管理、政务管理通过电子化手段实现,电子数据成了最宝贵的财富。伴随海关信息化的深入和发展,信息资源在为提升海关的服务能力、管理能力提供强有力支持的同时,其自身也变得越来越庞大,不仅难于管理,而且给系统的稳定运行带来了阻碍。为了更好的管理、利用、存放电子数据,需要对数据实施生命周期管理,依据数据的价值与应用的性质将数据进行划分,分别制定相应的管理策略,并建立配套的管理制度,解决目前海关信息系统数据管理策略单一所带来的各种问题,进一步提升系统性能、降低运维成本,为保障海关信息系统的高效、稳定运行提供数据基础。

信息资源规模庞大、难以管理的现象在金关一期的通关管理系统中体现得最为突出,同时在电子口岸也积累大量的海关预录入数据以及与各部委的交换数据。因此金关二期建设中将首先对通关管理系统的数据实施生命周期管理,将数据划分为在线数据、近线数据、历史数据、归档数据,依据数据的价值,制定不同的管理策略,更加有效的利用存储空间,避免由于数据量过大引起通关管理系统的性能问题,提高通关管理系统的可用性,降低异地容灾备份的难度,减小高端设备的不断增长,解决运行管理问题。然后,以此为基础,建立起海关数据生命周期管理框架,推动海关各信息系统对数据进行科学、有效的管理,提高信息管理能力。

数据生命周期管理主要包括如下功能:

对数据实施生命周期管理,将数据划分为在线数据、近线数据、历史数据、归档数据,并制定配套的管理制度。

1.9.6数据质量管理

数据质量管理是指对支持业务需求的数据进行全面质量管理,通过数据质量相关管理办法、组织、流程、评价考核规则的制定,及时发现并解决数据质量问题,提升数据的完整性、及时性、准确性及一致性,提升业务价值。

通过数据质量管理,保证数据的完整、准确、合法,并能够和运行监控平台结合,及时发现异常数据,及时处理。

数据质量管理主要由数据质量检测规则设置、异常数据处理和数据质量检控报告等功能组成。

1.10数据安全

1.10.1总体描述

信息系统安全架构分为两个方面:管理要求和技术要求。

管理要求分为:安全管理制度,安全管理机构,系统建设管理和系统运维;

技术要求分为:物理安全,网络安全,主机安全,应用安全和数据安

数据安全贯穿数据整个生命周期,其安全问题涉及数据整个数据生命周期的管理过程。对企业而言所有的数据在其生命周期中都应当被有效地管理,通过必要控制手段清晰地界定避免内部非授权的访问,并指定完善的数据备份、恢复策略、删除策略,保证数据的安全性。

数据安全的内容可以简化为保密性、完整性和可用性。其中包括数据本身的安全,即利用现代密码技术对数据进行主动保护,如数据保密、保证数据完整性等等。同时还包括数据防护的安全,即利用技术手段对数据进行保护,如磁盘阵列、数据备份、异地容灾等等。

数据安全特性与技术

1.10.2安全审计

数据安全审计是对每个用户在计算机系统上的操作做一个完整的记录,以备用户违反安全规则的事件发生后,有效地追查责任。安全审计需要对关键性数据的操作访问进行详细的记录,并支持违规事件的告警通知等服务。

1.10.3访问控制

访问控制是信息安全保障机制的前提和基础,是实现数据保密性和完整性的必要手段。访问控制通过限制访问主体(或称为发起者,是一个主动的实体,如用户,进程,服务等)对访问客体(需要保护的资源,如文件,系统等)访问权限的方法,是资源在合理范围内使用。

1.10.4数据加密

加密是一个过程,使数据只对正确的接收者可读,其他用户看到的是杂乱无序的数据。只能使用相应的密钥解密之后才能显示出数据本来内容。以此达到保护数据不被非法人窃取、阅读的目的。

1.10.5数据迁移

一方面不再频繁访问的历史数据占据了大量的存储空间,影响系统的响应时间和性能,无形中增加企业成本。另一方面,这些数据对企业仍具有价值甚至是宝贵资产,同时受法律、法规、规章要求需要企业存储关键数据。由于企业应用场景不同,数据迁移归档策略也不相同。

1.10.6备份恢复

为了很好地保护企业的重要数据,除了做好在线数据的存储管理外,还应该有一个良好的数据备份管理策略。主要包括以下内容:备份类型的选择(全备份、增量备份、差分备份)、备份窗口选择、确定存储介质保存时间、计算所需存储介质数量、备份介质的管理等等。

1.11检查点说明

1.12新技术列表及应用场景分析

邮件通关系统:接收外部邮件数据,分析处理后进入数据库的邮件包库中,邮件数量大,需要通过数据库集群RAC保证数据库连接的高可用性,同时为减少数据库的压力,引入可水平扩展的分布式缓存系统。邮件通关系统作为核心系统的数据存入结构化交易型事务型数据库中,对于分析型应用,通过批量并行处理的方式,将数据从交易型数据库中抽取到大数据分析型数据库中,以便于海量数据的高效分析及数据展示。