从数据架构的进化史,谈谈FineBI的分布式引擎

楼主
我是社区第70621位番薯,欢迎点我头像关注我哦~
      近期看到很多企业在设计自己的数据平台,以及选型一些数据分析工具,正好拜读了数据仓库之父的《数据架构:大数据、数据仓库以及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都要去看“蜘蛛网”了。还有索引、结果表、分区分表等等黑科技来保证每次查旬需扫描的数据量最小,解决数据库性能问题,~^o^~。

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


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


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

     无论是以什么架构存在,数据展示的需求都必不可少。分析工具选择必不可少,要在以上阶段以一款工具涵盖,那必然需要一款既可以做敏捷数据集市建模,又可以做数据展示分析的工具来处理。这种工具可对业务数据进行简单、快速整合,实现敏捷建模节省时间,并且需要可以大幅提升数据的展示速度。可对接前端的数据分析展示层,实现自由数据展示与OLAP分析。FineBI与其高性能数据引擎在以上几个阶段均可在不同程度解决很多场景。

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

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

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

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

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


编辑于 2018-8-15 17:49  
编辑于 2018-8-15 17:51  
编辑于 2018-8-15 18:00  
分享扩散:

沙发
发表于 2018-8-16 09:29:13
5.0中,这个分布式引擎会会直接替换finedirect,还是会与finedirect共存?
板凳
发表于 2018-8-16 09:46:40
传说哥 发表于 2018-8-16 09:29
5.0中,这个分布式引擎会会直接替换finedirect,还是会与finedirect共存?

共存呀,放一起了。抽取数据(分布式引擎)与实时数据(FineDirect)还可以互相转换。
编辑于 2018-8-16 09:48  
地板
发表于 2019-3-17 11:18:13
帆软产品解决的是展现这层的需求.对于ETL和DW这两方面.有什么解决方案吗?
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

返回顶部 返回列表