大数据时代,数据架构的演绎发展历程

 

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

大数据时代,数据架构的演绎发展历程_第1张图片


  1.业务数据库

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

大数据时代,数据架构的演绎发展历程_第2张图片


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

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

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

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

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

  2.中间库

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

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

大数据时代,数据架构的演绎发展历程_第3张图片


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

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

  3.完善数据仓库(DW)

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

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

大数据时代,数据架构的演绎发展历程_第4张图片


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

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

大数据时代,数据架构的演绎发展历程_第5张图片


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

  无论是以什么架构存在,数据展示的需求都必不可少。分析工具选择必不可少,要在以上阶段以一款工具涵盖,那必然需要一款既可以做敏捷数据集市建模,又可以做数据展示分析的工具来处理。这种工具可对业务数据进行简单、快速整合,实现敏捷建模节省时间,并且可以大幅度提升数据的展示速度,可对接前端的数据分析展示层,实现自由数据展示与OLAP分析,典型如各类BI分析工具。
  数据分析也很考验分析工具数据读取、运算的性能,但拥有大数据量计算引擎的BI分析工具并不多。像FineBI与其高性能数据引擎在以上几个阶段均可在不同程度解决很多场景。
  (1)业务数据库阶段,此阶段已经陈述过,重点问题就是计算性能影响大,以及数据孤岛问题。建立数仓的过程相对敏捷数据集市而言,时间还是久的。这个时候就看看建立个常规意义的数仓和数据展示需求谁更紧急啦,或者可能有的也没建数据平台的意识也说不准。此时快速的数据展示需求,就可以通过将数据放到FineBI的数据引擎中支撑实现。
  (2)中间库与完善数仓阶段,此阶段其实主要就是计算性能问题了,用户的数据量级也一定挺大了。正好借助于FineBI的分布式引擎,完成数据加速计算工作。此引擎属hadoop生态,核心计算引擎利用的spark,借助了alluxio作为内存加速计算,处理了大数据计算问题,也很好阐释了“大数据”。这个在接下来的文章中也会说到,这里先埋个伏笔,暂不赘述。
  此阶段呢,肯定有一些响应时间要求较高的展示需求,多次作业同步可能带来延迟影响。而FineBI的引擎扩展了kettle的插件,实现数据可以直接load到引擎中,倒是将麻烦的作业处理工作解决了。

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

 

你可能感兴趣的:(大数据)