报表平台系统架构

浏览: 9764

贾岩:

兄弟们。。。第一个话题涉及管理方面多一点,因为当你做了很多年项目,回过头看,就全理解的。新人对我们讲解的,可能还不是很理解,这个需要项目一点点积累的。大家注意,打起精神,第一个话题不理解没关系,做项目慢慢学,第二个话题我认为大家都应该学, 都应该知道的。因为我们在做项目,做开发,做分析时,我们最好去了解我们的结构是怎么样的,有人愿意一辈子低头做自己的开发吗?我相信没多少吧,所以,做好眼前事,还要抬起头,纵观全局。做好人生规划,少不了要学习,所以我们要知道你做的事情,做的开发,是处于项目哪个,部分,哪个阶段,将来做管理,还是咨询,你都要从大局出发,所以系统结构,所有人必须要知道。现在开始架构方面的讲解,先来看张图:

Clipboard Image.png


这是张硬件结构图,一般集团,还是非集团性,物理结构都是双机,单机风险比较大。根据结构复杂度而分,这个图是ORACLE单独放在了一个服务器了,也有和ETL放在一起的。因项目而议,除了应用服务器,还会有一个单独的磁盘阵列,通过这些都是服务器的管理员来负责。

Clipboard Image.png

这个就是一个典型数据平台结构,每个层次使用的软件可能不同,但是结构基本都是一致的。数据平台,借助统一的运行环境对来自不同业务应用的数据依靠统一的开发路线进行抽取、转换和加载,加工形成企业数据仓库和并根据具体的业务需求形成相应的数据集市,在数据集市的基础上进行更高级的业务分析应用,同时将各种来源的数据转化成实用的业务信息,为企业提供完整的数据支撑,实现企业数据的构建、保存、更新、集成、分发与共享。

企业数据平台为企业信息门户提供展现的内容,两级数据平台通过数据交换平台实现级联,可以通过应用集成平台实现各业务系统间的集成。

大家看前面的展示层,有些可能用COGNOS 或者BIEE展示,有些是开发门户,将COGNOS 或者BIEE开发的报表嵌套进去的。所以大家重要的是理解结构。

Clipboard Image.png

这个是一个逻辑架构图,他包含了一个集团省级,总部之间的关系。也许地市级别有时是一个单独的,独立的小系统,但是省级,本部,结构基本一致,重点是数据的交换功能。

1.           数据获取与交换的实现

各种数据源进入数据平台的数据缓冲区有两种方式,即利用ETL工具提供的功能获取数据,和利用数据交换平台提供的数据交换服务进行交换,下面将具体说明。

l  ETL处理的实现

省级公司集中的业务系统的数据、地市分布的业务系统数据、和外部数据,可以经过抽取(Extract)进入数据缓冲区,再经过转换(Transition)和清洗(Cleansing),然后加载(Loading)到数据仓库。

进行转换的目的在于解决源数据可能存在的数据不一致现象,对抽取的源数据根据数据模型的要求,进行数据的转换、清洗、拆分、汇总等处理,保证来自不同系统、不同格式的数据的一致性和完整性。因为当源数据进行抽取后,如果不进行一致性转换,会造成数据无法加载或加载后无法使用。

进行清洗的目的在于检测并删除或改正将装入数据仓库的“脏数据”,使源数据元素化、标准化、并消除重复记录。

l  数据交换服务处理的实现

数据交换服务存在以下应用场景:

a) 省级公司数据平台与总部公司总部纵向数据交换、省级公司数据平台与其他机构的外部系统的数据交00换,通过数据交换平台提供的数据交换服务进行实时和非实时交换。

b) 有些准备进入到ODS缓冲区中的数据,包括省级集中业务系统的数据、地市分布的业务系统数据、和外部数据,当无法使用ETL工具获取时,也可以通过数据交换平台提供的数据交换服务进行数据交换的方式,完成采集后,加载并存储到数据仓库中。

2.        ODS区内的数据处理

在图中,ODS区包括数据缓冲区和统一数据视图区。

a) 统一数据视图区主要保存各个业务应用系统中的关键数据,并为以后搭建的业务应用系统提供全局的数据逻辑视图和数据存储平台。并且也可以实现实时监控功能。

b)  数据缓冲区暂存由ETL获取的数据,这些数据经过转换和清洗后加载到数据仓库中。数据缓冲区是为了保证数据移动的顺利进行而开设的阶段性数据存储空间,需要进入数据仓库的各个业务系统的数据首先直接快速传输到数据缓冲区,再从数据缓冲区经过清洗、转换、映射等复杂的数据移动处理转移到目标数据仓库中。

从省级公司数据平台数据处理的角度,数据缓冲区是存放各业务系统的原始数据和各个异构系统转入的原始数据,对数据缓冲区的数据进行清洗和过虑,然后面向主题、按数据模型存放数据仓库。

3.        数据仓库区和数据集市区的数据处理

经过清洗、整合后的数据进入数据仓库。数据集市对数据仓库中的基础数据进行逐次聚合,形成目标数据供前端数据应用或展现。数据集市根据省级公司的具体应用需要和数据量建立。

各部门业务应用的数据首先被存储在数据仓库,从数据仓库经过数据集市,细节数据逐步演变为轻度综合和高度综合的数据,其实质是对OLTP系统产生的历史数据进行整合、存储、处理、统计、分析,从而获取关于历史的、目前的、和未来的知识,从而获取信息、支持决策与管理的应用模式。

4.        BI应用的实现

数据仓库、数据集市的数据可以应用于报表、即席查询和OLAP展现;也可以应用于数据挖掘。这些数据应用的数据处理和前端展现主要是通过相应的BI工具完成的。这些BI工具软件的SERVER端部署在APPLICATIONSERVER上。

用户使用BI工具客户端经过门户登陆统后,访问BI工具SERVER端,完成访问请求。BI应用与PORTAL集成时,需要重点考虑单点登陆和访问权限集成的实现。系统级访问权限由门户系统控制;数据级范围权限由BI工具与数据库系统共同实现。

这是整个结构每个环节的一个说明。其实对于一个庞大的集团性的企业来说,这么大的结构,需要主要谈的就是信息安全,信息安全其实说起来话题也不小,包含技术协议,网络安全,数据库安全等方面,但是对于我们做系统的来说,其实主要涉及的层面,就是权限控制及门户集成的操作。

信息安全目标与原则:

q    “进不来”

使用访问控制机制,阻止非授权用户进入网络,“进不来”

q    “拿不走”

使用授权机制,实现对用户的权限控制,即不该拿走的,“拿不走”; 

q    “看不懂”

使用加密机制,确保信息不暴漏给未授权的实体或进程,即“看不懂”;

q    “改不了”

使用数据完整性鉴别机制,保证只有得到允许的人才能修改数据,而其它人“改不了”;

q    “走不脱”

使用审计、监控、防抵赖等安全机制,使得攻击者、破坏者、抵赖者"走不脱"。

集团数据平台建立完成后,信息的安全控制尤为重要,其实可以通过门户来进行权限的控制,以及数据的访问控制,另外也可以通过报表应用的权限,对数据信息的权限进行控制与授权。

企业门户是一种能够为从事各种类型工作的用户提供全面的服务支持,一个为消除信息孤岛、构建知识管理体系、提高决策支持能力的全新信息化平台。依靠此平台,可以轻松的将分散的信息资源和内容整合到一起。

企业门户系统提供统一的信息访问渠道(单点登录);提供基于角色和权限的个性化的信息、知识、服务和应用,不仅可以集成信息资源,也可以集成企业应用;也可以采用不同的模式来进行访问,模式很多,我只是列举一下而已,大家仅作参考。

1、省公司建设实体门户,地市公司全部建设虚拟门户。在地市公司部署独立的访问控制。用户与身份维护工作均集中在省公司,如下图所示

Clipboard Image.png

2、省公司和地市公司均建立实体门户和独立的目录系统。用户与身份维护均在地市进行。

Clipboard Image.png

3、其中门户也可以对于应用,分析等功能进行集成,进行权限进行控制。这里涉及到单点登录,用户同步等技术功能。

Clipboard Image.png

每种安全机制的建立,都是根据项目实际情况设计的。因为都各有弊端,有些成本可能会高一些。我大概就讲这些,主要是架构方面,需要大家仔细体会。


老头子:

感谢@贾岩的分享 , 我这边很简单,一共3张图:
1. 数据架构 
2. 技术架构 
3. 应用架构

【内心独白】(每次都很简单,是不是太不走心了)


Clipboard Image.png

第一张图是数据架构图,自己画比较粗糙,大家见谅!图里的EDW没有详细画出具体的分层,可以参考之前岩哥的图。

第二个图:技术架构

Clipboard Image.png

画了下需要搭建BI平台常用的一些技术能力,可以自下而上的看。这几年BI开始受到移动互联网的影响 ,都开始玩手机了,所以企业也会有移动BI这方面的需求。大致分了传统关系型数据库、非关系型数据、数据仓库、数据挖掘、以及传统BI所需的技术实现。

最后一张应用架构,一把来说应用架构是根据业务来画的,我这里只是举个栗子,大家根据实际业务来理解。

Clipboard Image.png

应用是直接面对业务的,也是BI价值体现的直接方式,和春宇说的现在企业过于看重数据仓库的建设一样,其实企业精力放到ETL上,从我的经验来看是由于数据仓库建设实在不易,所以不断的完善、加强、修复,导致了少部分企业忽略了前台应用

传统行业BI的企业架构大同小异,抓住精髓即可。

我就到这儿吧,我还是喜欢和大家互动环节,我一个人讲话我自己会睡着的,嘿嘿。

BAO胖子

1. 访问层
    最常见的:Portal(在线访问)
    其他如: Email(离线访问,比如发alert, 发export 文件,日报之类)
    目前最火的:ipad, mobile, 当然也可以-微信
    其他系统的接口:提供web service,对接其他系统,提供相应信息,这种应用相对不多。

这部分,Portal是最常见的,一般都是用java之类,定制开发的,这里需要说明的是,很多企业级架构,是包含多种报表工具的。因为报表工具各有所长Cognos、

Bo、BIEE算同类报表工具,Tableau, Qlikview又是另外一种,实际上是满足不同人群的需求。Portal可以作为一个壳,把所有的不同的工具纳入其中。

2. 应用层
   按报表类型的分类:Dashboard, Ad-hoc, 固定报表,Alert, OLAP,KPI,高级分析(Data Mining)之类。
   按业务分类: Finance, HR, SCM, CRM等等。

3. 产品层(技术层)
   常用的报表工具,为了Developer设计的,固定报表为主的报表: Cognos, BO, BIEE等等。
   为了分析而生的,高级分析为主的报表: Qlikview, Tableau等。
  具体区别,请参见:http://www.flybi.net/blog/rayshawn/542

4. 数据安全层
    与各类LDAP,ActiveDirectory之类的接口,包括企业内部和企业外部。
    行级数据限制接口,一般在报表逻辑中实现。

还有很多安全相关的内容,此处暂不做赘述。
5. 数据访问层
   多种数据库,Oracle, Teradata, DB2,各类Data Mart, DW, Cube之类。

统一化的平台大致分这么五层,这是我的理解。 

推荐 1
本文由 天善智能 创作,采用 知识共享署名-相同方式共享 3.0 中国大陆许可协议 进行许可。
转载、引用前需联系作者,并署名作者且注明文章出处。
本站文章版权归原作者及原出处所有 。内容为作者个人观点, 并不代表本站赞同其观点和对其真实性负责。本站是一个个人学习交流的平台,并不用于任何商业目的,如果有任何问题,请及时联系我们,我们将根据著作权人的要求,立即更正或者删除有关内容。本站拥有对此声明的最终解释权。

1 个评论

good,赞作者,求加微信

要回复文章请先登录注册