一文读懂数据架构的进化史

  发布时间:   文章分类:数据库 浏览数: 13

文章来源: bigdata.51cto.com/art/201808/5......

近期看到很多企业在设计自己的数据平台,以及选型一些数据分析工具,正好拜读了数据仓库之父的《数据架构:大数据、数据仓库以及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分析恰好也有,简单处理整合展示一站式解决。

以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 Coder·码农网

码农可能感兴趣的文章:

本文永久链接:www.codercto.com/a/23185.html

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。

相关码农书籍:
Dive Into Python

Dive Into Python

Mark Pilgrim / Apress / 19 July, 2004 / $39.99

Dive Into Python 是为有经验的程序员编写的一本 Python 书。

相关码农工具:
RGB转16进制工具

RGB转16进制工具

RGB HEX 互转工具

URL 编码/解码

URL 编码/解码

URL 编码/解码

SHA 加密

SHA 加密

SHA 加密工具