您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 订阅
  捐助
一文读懂数据架构的进化史
 
作者:风语辰
  1148  次浏览      15
 2020-5-7 
 
编辑推荐:
文章主要介绍了数据架构得业务数据库,中间库,完善数据仓库(DW),完善数仓+数据集市(Data Mart)等相关内容。
本文来自于百家号,由火龙果软件Anna编辑、推荐。

近期看到很多企业在设计自己的数据平台,以及选型一些数据分析工具,正好拜读了数据仓库之父的《数据架构:大数据、数据仓库以及Data Vault》一书,有些许感触,就来聊一下个人思考吧。

首先从企业信息化发展阶段时,数据平台结构的程度来看。个人依照企业信息化,将数据平台阶段划分为:只有业务数据库——>中间库——>完善数据仓库(DW)——>数据集市(Data Mart),顺序与阶段并不绝对正确,可能有组合,可能所在阶段不完全一致。以下先看各个数据平台阶段特点,再看对应阶段数据分析工具选型的考虑吧。

1.业务数据库

一个企业IT信息化建设最初的阶段,业务库中数据量不大,要分析展示下数据情况啦,不慌,问题不大,这时候OLTP结构下也可以写写SQL快速展现,随便玩玩office工具也没问题。

但是随着时间的推移,各种问题开始出现:

(1)查询和写入频率越来越高,高频write和和长时间read冲突越来越严重。而数据分析要耗费大量计算资源,不能动不动挂业务系统吧。

(2)数据量越来越大,历史业务数据啦,新业务数据激增啦,第一要务就是要解决业务应用效率问题了,谁管数据分析里的问题呢。

(3)业务越来越多,表结构越来越复杂。业务系统数量的越来越多,导致数据孤岛开始形成。

这种情况下,企业面临数据展示与数据平台建设的阶段了要怎么处理。这种情况下要做数据分析就麻烦了,要人为去各个系统取数,人力是一个方面。各个系统口径命名啥都有差异,人为的处理出错率高就是另一方面。

2.中间库

由于上述问题,就要引入中间库来处理。左图结构解决了高频write和read冲突问题,以及单数据库服务器性能问题,顺手也搞定了数据备份。这种情况下呢简单查询还是可以的,但是在转换聚合等需要多表关联、以及大数据量等业务复杂度高的情况下,其处理性能就不容乐观了。

此时就开始考虑可以利用空闲时间的服务器性能来做预先处理呢。右图这种T+n的预处理离线计算的架构就出现了,引入独立的任务调度和计算引擎:计算压力可以交给数据库处理,也可交给ETL处理,展现性能初步解决。

但是这种情况下,数据库表结构实在太过复杂,每做一个分析,就要理一次业务逻辑、写一段sql,还没法进行历史追溯,以及数据整理成果的复用,so sad。

那有没有理一次之后,后续能够省点事的方式呢?这时候数仓的概念就可以使用上了。

3.完善数据仓库(DW)

把业务库数据整理成星型结构,保证了事实的积累和维度的追溯。自由选择需要的维度和相关事实进行筛选计算,麻麻再也不用担心每次写sql都要去看“蜘蛛网”了。还有索引、结果表、分区分表等等黑科技来保证每次查旬需扫描的数据量最小,解决数据库性能问题。

当然这种架构方式的缺点也很明显,不是企业内一致的数据(多系统,多主题数据不一致),就会产生信息孤岛。当然,如果客户企业就是很小,就一个系统,不用整合,一个数据集市足以的情况下采用这种方式也可以。常见情况是会在各个独立的DW间建立一些对照表,可实现数据交换。如果多个DW间没有物理隔绝,也可以形成EDW。

4.完善数仓+数据集市(Data Mart)

为了实现各个业务系统取数分析,或者做更多操作,就实现中心数据仓库EDW从各个源系统收集数据,再将数据提供给各个数据集市和挖掘仓库使用。这也被称为企业信息工厂架构(CIF),一般情况下,大型企业会花费许多精力实现这类架构。

业务复杂度的提高与数据量级的增大以及对这些数据的应用,促成了各个大数据平台的繁荣,这个放到另一篇文章陈述。

无论是以什么架构存在,数据展示的需求都必不可少。分析工具选择必不可少,要在以上阶段以一款工具涵盖,那必然需要一款既可以做敏捷数据集市建模,又可以做数据展示分析的工具来处理。这种工具可对业务数据进行简单、快速整合,实现敏捷建模节省时间,并且可以大幅度提升数据的展示速度,可对接前端的数据分析展示层,实现自由数据展示与OLAP分析,典型如各类BI分析工具。

数据分析也很考验分析工具数据读取、运算的性能,但拥有大数据量计算引擎的BI分析工具并不多。像FineBI与其高性能数据引擎在以上几个阶段均可在不同程度解决很多场景。

(1)业务数据库阶段,此阶段已经陈述过,重点问题就是计算性能影响大,以及数据孤岛问题。建立数仓的过程相对敏捷数据集市而言,时间还是久的。这个时候就看看建立个常规意义的数仓和数据展示需求谁更紧急啦,或者可能有的也没建数据平台的意识也说不准。此时快速的数据展示需求,就可以通过将数据放到FineBI的数据引擎中支撑实现。

(2)中间库与完善数仓阶段,此阶段其实主要就是计算性能问题了,用户的数据量级也一定挺大了。正好借助于FineBI的分布式引擎,完成数据加速计算工作。此引擎属hadoop生态,核心计算引擎利用的spark,借助了alluxio作为内存加速计算,处理了大数据计算问题,也很好阐释了“大数据”。这个在接下来的文章中也会说到,这里先埋个伏笔,暂不赘述。

此阶段呢,肯定有一些响应时间要求较高的展示需求,多次作业同步可能带来延迟影响。而FineBI的引擎扩展了kettle的插件,实现数据可以直接load到引擎中,倒是将麻烦的作业处理工作解决了。

(3)完善数仓+数据集市阶段,这种阶段数据平台建设已经很完善了,各业务部门数据量级,业务复杂度都很高。

底层技术上虽然数据集市是建立在集成的中心数据仓库EDW上,但是这些数据集市之间还是不能进行数据交换的,大家建立的方法和ETL程序都会不同,各个数据集市之间的数据不见得的是一致,且平台架构超级复杂,扩展以及再为各业务部门设计计算层结果表之类都相对麻烦。此时可考虑部分需整合数据放到敏捷数据集市处理,可直接对接的再直接对接处理。FineBI的引擎恰好都满足这样的场景需求,前端OLAP分析恰好也有,简单处理整合展示一站式解决。

 

   
1148 次浏览       15
相关文章

企业架构、TOGAF与ArchiMate概览
架构师之路-如何做好业务建模?
大型网站电商网站架构案例和技术架构的示例
完整的Archimate视点指南(包括示例)
相关文档

数据中台技术架构方法论与实践
适用ArchiMate、EA 和 iSpace进行企业架构建模
Zachman企业架构框架简介
企业架构让SOA落地
相关课程

云平台与微服务架构设计
中台战略、中台建设与数字商业
亿级用户高并发、高可用系统架构
高可用分布式架构设计与实践
最新课程计划
信息架构建模(基于UML+EA)3-21[北京]
软件架构设计师 3-21[北京]
图数据库与知识图谱 3-25[北京]
业务架构设计 4-11[北京]
SysML和EA系统设计与建模 4-22[北京]
DoDAF规范、模型与实例 5-23[北京]
 
最新文章
架构设计-谈谈架构
实现SaaS(软件及服务)架构三大技术挑战
到底什么是数据中台?
响应式架构简介
业务架构、应用架构与云基础架构
最新课程
软件架构设计方法、案例与实践
从大型电商架构演进看互联网高可用架构设计
大型互联网高可用架构设计实践
企业架构师 (TOGAF官方认证)
嵌入式软件架构设计—高级实践
更多...   
成功案例
某新能源电力企业 软件架构设计方法、案例与实践
中航工业某研究所 嵌入式软件开发指南
某轨道交通行业 嵌入式软件高级设计实践
北京 航天科工某子公司 软件测试架构师
北京某领先数字地图 架构师(设计案例)
更多...