浅谈数据仓库架构设计

简介: 简单的比较了一下数据中台架构与数据仓库、BI、DSS之间的关系,并对比了一下Bill Inmon和Ralph Kimball架构的差异。

1. 数据中台与DW/BI/DSS

   个人认为数据中台本质上是一种新的适配大数据技术发展的新的“数据仓库-决策支持(商业智能)”架构。这个架构是构建在传统的架构基础之上,对传统架构的一种新的发展。

   数据中台从企业的视角出发,要求企业在构建数据仓库到决策支持系统的过程中构建一个服务型的架构。数据中台希望构建在数据仓库基础上的决策支持系统的建设能更加迅速敏捷,缩短业务需求实现过程中的数据开发过程的时间。数据中台把应用的共性需求沉淀在中台,做厚数据服务层,这样应用前台在构建的时候可以大幅度的利用已沉淀在中台的各种能力,可以做到快速搭建,形成大中台小前台的层次架构。

1.1. 数据仓库(DW)/商务智能(BI)/决策支持(DSS)

   数据仓库之父比尔·恩门(Bill Inmon)在1991年出版的“Building the Data Warehouse” (《建立数据仓库》)一书中所提出的定义被广泛接受,数据仓库是一个面向主题的(Subject Oriented)、集成的(Integrate)、相对稳定的(Non-Volatile)、反映历史变化(Time Variant)的数据集合,用于支持管理决策。

   数据仓库是一个过程而不是一个项目;数据仓库是一个环境,而不是一件产品。数据仓库提供用户用于决策支持的当前和历史数据,这些数据在传统的操作型数据库中很难或不能得到。数据仓库技术是为了有效的把操作形数据集成到统一的环境中以提供决策型数据访问,的各种技术和模块的总称。所做的一切都是为了让用户更快更方便查询所需要的信息,提供决策支持。

   商业智能(Business Intelligence,简称:BI),又称商业智慧或商务智能,指用现代数据仓库技术、线上分析处理技术、数据挖掘和数据展现技术进行数据分析以实现商业价值。

   决策支持系统(Decision Support System)是一个基于计算机用于支持业务或组织决策活动的信息系统。 DSS服务于组织管理、运营和规划管理层(通常是中级和高级管理层),并帮助人们对可能快速变化并且不容易预测结果的问题做出决策。决策支持系统可以全计算机化、人力驱动或二者结合。

   从概念上来讲,BI与DSS都是一组概念的概括性的总称,可以有很多定义。从历史沿革上来说,先有的决策支持系统,利用计算机来辅助人做决策。后续商务智能的发展,为决策支持提供了数据分析预测的能力,商务智能(BI)提供的数据分析能力是现代决策支持系统(DSS)的基石。

(概念引用:商务智能与分析-决策支持系统)

image.png

1.2. 先贤的一些词汇与观点的争议

   数据仓库行业内容的两位观点部分相左的先贤,分别是Bill Inmon与Ralph Kimball。

1.2.1. 定义与用词

   在数据仓库支撑的分析型系统的用词上:

Bill Inmon-数据仓库是体系结构设计环境的核心,是决策支持系统处理的基础。(The data warehouse is the heart of the architected environment, and is the foundation of all DSS processing. )

Ralph Kimball-数据仓库和商业智能(Data Warehousing and Business Intelligence, DW/BI)系统

   显然BI与DSS是有区别的,但是DW无疑是可以支撑BI和DSS。BI是手段是能力,而DSS是BI的目标。

   在数据仓库的定义上,因为Bill Inmon是数据仓库之父,他对数据仓库的定义获得了广泛的认可。而Ralph Kimball并未对数据仓库概念有单独的定义,但是从架构与实现上来看,其实还是有区别的。

1.2.2. 架构设计

   在数据仓库架构的设计上:

   Bill Inmon - 全局视角,要先构建企业级数据仓库,然后再基于企业级数据仓库之上去构建数据集市。数据的整合是的企业对数据有一个真正企业范围级的观察,业务分析人员是从整体而不是局部进行数据分析。

   数据仓库前期的需求是不明确的,业务人员是先要看到数据再去构建探索真实需求,所以数据仓库是不断的迭代构建。采用3RD模型来构建一个企业级的业务模型,确保数据的完整性与一致性。

   Ralph Kimball -需求视角,以业务需求驱动,面向分析。事实要构建在最细的粒度上,不同的业务需求之间靠一致性维度来确保数据的一致性。

  • DW/BI架构

image.png

  • 辐射状企业信息工厂(CIF)

image.png

  • 混合辐射状企业信息工厂与KimBall架构

image.png

   从上面几张图上我们可以看到,之所以在Kimball的书中会有与Inmon组合的混合架构,是因为这几张架构图中的层次基本是一致的。而Kimball架构中并未去描述如何去做数据的规范化、完整性、一致性,只是要去做,而Inmon的架构中恰好可以实现这个部分。对于后面数据展现区的数据模型,又都一致的认为是以维度模型来建模。

   从实际构建方式上来看,Bill Inmon架构强调数据仓库应该是统一构建,业务模型是企业级的。这个出发点是更具有宏观意义,假设企业有30个交易系统,建设的时候就需要都纳入需求分析范围,然后按需分阶段完成企业级的数据仓库模型。Ralph Kimball架构强调以业务需求为导向,构建维度模型,后续的需求只要确保整个企业范围内一致性维度,就可以构建更加高效的数据仓库。Ralph Kimball认为Bill Inmon的架构太过于庞大,可能会让企业投入巨大但是看不到回报。而Bill Inmon则认为维度模型构建的数据仓库,很容易变成松散的多个不一致的数据集市。虽然Ralph Kimball也强调独立集市架构是不可取的。

   其实综合实践与现实中数据仓库的案例来看,在以Teradata\IBM\Oracle等公司构建的企业级的数据仓库架构,全部都是以Bill Inmon的架构来构建了一个3RD的企业级的数据仓库模型,并且在一些规模宏大的银行、保险、电信等行业取得了比较巨大的成功。尤其是国内Teradata的金融模型,几乎占据了国内全部的大银行、保险机构的市场。而Ralph Kimball的架构,在银行、电信、零售电商等行业也是受到了广泛的好评。

   这两种架构各有千秋,各有侧重。并且从两位先贤相互指责的问题来看,问题都是真实存在的。Ralph Kimball架构虽然强调不能建设成独立集市架构,要采用全局一致性维度,但是,业务部门分头建设且以需求为导向的结构,很容易失控就走成独立集市架构。Bill Inmon的架构因为有一层数据仓库层,从机能上就会去协调,避免这种情况的产生。但是Bill Inmon的架构,因为构建投入巨大,也只是在金融业获得了巨大的成功。在一些业务相对简单规模不大的客户场景中,因为交易型系统本身就是3RD模型,所以,本身并没有需求再去构建一个数据仓库的3RD模型,ODS系统就基本替代的这一层。

   在数据集市、数据应用的分析型场景中,Ralph KimballBill Inmon都应该使用维度模型来构建。

1.3. 综合的选择

   从Bill Inmon与Ralph Kimball的书中,我们可以看到两位先贤的观点。个人认为在不同的场景可以有不同的选择,在业务复杂、业务变化不频繁、数据仓库上游的交易型系统特别多、能接受足够长时间大投入的企业级数仓建设的场景,Inmon的架构(或者说是CIF与DW/BI混合架构)显然是更好的选择,这种架构更加宏观,且具有企业级视角,只有在这种视角下才能实现数据中台的设计目标。而在业务模型简单、业务变化频繁、难以接受企业级架构构建的时间成本的场景,最好使用DW/BI架构。

   如果可以放眼眼前的数据仓库的案例,就会发现这是一种比较现实的选择。

image.png

相关实践学习
简单用户画像分析
本场景主要介绍基于海量日志数据进行简单用户画像分析为背景,如何通过使用DataWorks完成数据采集 、加工数据、配置数据质量监控和数据可视化展现等任务。
SaaS 模式云数据仓库必修课
本课程由阿里云开发者社区和阿里云大数据团队共同出品,是SaaS模式云原生数据仓库领导者MaxCompute核心课程。本课程由阿里云资深产品和技术专家们从概念到方法,从场景到实践,体系化的将阿里巴巴飞天大数据平台10多年的经过验证的方法与实践深入浅出的讲给开发者们。帮助大数据开发者快速了解并掌握SaaS模式的云原生的数据仓库,助力开发者学习了解先进的技术栈,并能在实际业务中敏捷的进行大数据分析,赋能企业业务。 通过本课程可以了解SaaS模式云原生数据仓库领导者MaxCompute核心功能及典型适用场景,可应用MaxCompute实现数仓搭建,快速进行大数据分析。适合大数据工程师、大数据分析师 大量数据需要处理、存储和管理,需要搭建数据仓库?学它! 没有足够人员和经验来运维大数据平台,不想自建IDC买机器,需要免运维的大数据平台?会SQL就等于会大数据?学它! 想知道大数据用得对不对,想用更少的钱得到持续演进的数仓能力?获得极致弹性的计算资源和更好的性能,以及持续保护数据安全的生产环境?学它! 想要获得灵活的分析能力,快速洞察数据规律特征?想要兼得数据湖的灵活性与数据仓库的成长性?学它! 出品人:阿里云大数据产品及研发团队专家 产品 MaxCompute 官网 https://www.aliyun.com/product/odps 
目录
相关文章
|
7月前
|
存储 数据可视化 大数据
彻底搞定数据产品选型-报表平台、BI平台、大数据平台、数据中台一网打尽
彻底搞定数据产品选型-报表平台、BI平台、大数据平台、数据中台一网打尽
|
7月前
|
存储 数据采集 消息中间件
微信技术分享:揭秘微信后台安全特征数据仓库的架构设计
本文将介绍微信的安全数据特征仓库的背景起源、技术演进、当前的架构设计和实践,以及数据质量保证系统的实现。希望给中大型IM系统的安全数据特征仓库的设计带来启发。
166 0
|
数据可视化 安全 数据挖掘
2022 Gartner魔力象限报告发布 ,阿里云数据中台Quick BI国内唯一连续三年入榜
近日,国际权威分析机构Gartner发布2022年商业智能和分析平台魔力象限报告(《Magic Quadrant for Analytics and Business Intelligence Platforms》以下简称ABI领域魔力象限),阿里云Quick BI成为该领域唯一一家连续三年入榜的中国企业!
2022 Gartner魔力象限报告发布 ,阿里云数据中台Quick BI国内唯一连续三年入榜
|
机器学习/深度学习 人工智能 自然语言处理
【重磅】中国唯一企业 阿里云数据中台产品Quick BI再度入选Gartner魔力象限
国际权威分析机构Gartner发布2021年商业智能和分析平台魔力象限报告,阿里云Quick BI再度入选,并继续成为该领域魔力象限唯一入选的中国企业。
554 0
【重磅】中国唯一企业 阿里云数据中台产品Quick BI再度入选Gartner魔力象限
|
机器学习/深度学习 人工智能 自然语言处理
【重磅】中国唯一企业 阿里云数据中台产品Quick BI再度入选Gartner魔力象限
国际权威分析机构Gartner发布2021年商业智能和分析平台魔力象限报告,阿里云Quick BI再度入选,并继续成为该领域魔力象限唯一入选的中国企业。
1157 0
【重磅】中国唯一企业 阿里云数据中台产品Quick BI再度入选Gartner魔力象限
|
存储 数据可视化 关系型数据库
让数据中台飞起来—— Quick BI性能优化解决方案及实践
企业在数据中台初步建设完成以后,怎样让客户直观感受到数据中台的价值?企业决策者、各部门管理人员、业务运营人员如何通过统一的窗口,快速看到数据中台提供的数据,并利用这些数据全方位的支持企业发展?基于Quick BI构建的企业数据门户,有效的解决了上述问题。
21649 0
让数据中台飞起来—— Quick BI性能优化解决方案及实践
|
2月前
|
SQL 关系型数据库 MySQL
在云数据仓库AnalyticDB MySQL版中,有几个参数可能影响SELECT查询的执行及其稳定性
在云数据仓库AnalyticDB MySQL版中,有几个参数可能影响SELECT查询的执行及其稳定性【1月更文挑战第16天】【1月更文挑战第80篇】
27 4
|
13天前
|
SQL Cloud Native 关系型数据库
AnalyticDB MySQL湖仓版是一个云原生数据仓库
【2月更文挑战第15天】AnalyticDB MySQL湖仓版是一个云原生数据仓库
15 2
|
2月前
|
分布式计算 DataWorks 关系型数据库
在云数据仓库AnalyticDB MySQL版中,LIMIT的大小是由系统参数max_limit控制的
【1月更文挑战第7天】【1月更文挑战第31篇】在云数据仓库AnalyticDB MySQL版中,LIMIT的大小是由系统参数max_limit控制的
24 1
|
3月前
|
存储 分布式计算 关系型数据库
云原生数据仓库AnalyticDB MySQL湖仓版架构升级,持续释放技术红利!
云原生数据仓库AnalyticDB MySQL湖仓版架降价23%!持续提供高性价比的产品服务

相关产品

  • 云原生大数据计算服务 MaxCompute