构建数据中台的组织架构

Posted 2023-04-06 阿里云技术

一、中台是一种企业架构

1.TOGAF企业架构标准

TOGAF是一套企业架构标准。企业架构是指整个公司或企业的软件和其他技术的整体观点和方法。企业架构又细分为业务架构、应用架构、数据架构、技术架构几个方向。

其中业务架构的定义是“定义业务战略和组织，关键业务流程及治理和标准”。因为数据中台其实就是组织为了更好的让数据服务业务而构建的一种企业架构，这个架构自然也会包括业务架构和其中的组织架构。定义组织架构要有明确的业务战略，中台就是目前最具有前瞻性的企业IT战略。著名管理大师钱德勒总结过一个黄金定律：战略决定组织，而组织决定成败。

2.架构愿景与驱动因素

个人以为数据中台架构的愿景是“加速数据驱动业务”。

●业务需求驱动

在这个大数据爆发的时代，业务部门已经不满足于现有数据对业务的支撑的能力，希望从数据侧获得更多、更大的驱动力。

●组织规模驱动

当一个组织足够大，部门分化，组织内部的各种系统林立，就会遇到同一数据多源存储使用、数据获取不便、口径难以统一的问题。

因为业务系统在设计之初就是为了满足某个业务域的功能需求，缺乏对管理决策支持的设计，所以，缺乏统一的数据平台的组织很难获得全局一致的数据为管理决策做支撑，从组织内部不同部门获取的数据总是缺乏可信、相互冲突。

当组织规模足够大，就需要组件一个统一的数据平台来构建组织内部统一的业务数据视图，进而驱动数据为综合业务管理决策服务的能力。

●经济效益驱动

我们会为每一个小的团队都配置财务、人事这些职能角色么？数据决策和分析是每个业务系统建设到一定阶段都要做的功能，要不要从其他业务系统获取数据，要不要构建自己的数据集市，这些都是重复的职能。部门自己竖烟囱，不仅仅是组织内部数据不统一的问题，还带来了资源的大量浪费。

这种情况，会导致各个小团队因为人员没有专业分工，开发人员既要做业务系统功能开发，又要做数据开发，导致团队的专业度和能力受到限制。还会因为各个小团队之间业务割裂，无法达到相应规模应有的规模效应。

二、构建统一数据平台

1.不同阶段的功能需求

计算机系统的出现最基本的诉求是替代或者协助人类进行的重复性的工作，包括计算、记录、控制等。我们从数据库角度来看，这些需求都是操作型的，传统的关系型数据库就是为了解决这类需求而构建的。

系统一旦运行起来，就会进入下一个阶段，改进。系统功能的改进需要对业务过程数据进行分析，并通过分析结果进行系统功能改进。

另外一方面，系统都是需要人去参与和管理的。大型组织和企业都是由多个不同业务功能的系统组成的复杂系统。如何经营与运转这些系统、管理相关的负责部门、人员，通过经营分析与绩效考核做出管理决策和调整组织的发展，这些复杂的系统，需要对数据进行分析。

上面提到的这些阶段分别是：生产系统替代人力、系统改进、经营管理系统构建、管理改进。可以看到越是高阶，对数据分析的需求就越高。

2.数据仓库与数据集市

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

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

最开始的分析与决策需求是直接构建在业务系统上的。刚毕业的时候，我在公司做呼叫中心业务的日常管理与分析报表，都是直接在业务系统的数据库上完成的。

这里会遇到一些颇具挑战的问题。首当其冲的是性能问题，人对系统返回数据的极限忍耐大概只有3-5秒，但是关系型数据库设计之初并不是决策分析服务的，所以，很多时候只有部分报表能满足这个需求，很多计算数据量大的统计报表响应时间并不好，偶尔还会遇到查询失败的情况。其次是对源系统影响的问题，因为直接在源系统上运行，报表的访问需求是一次访问很多行，如果长时间不能返回运行结果，可能会造成锁阻塞交易业务失败。最后是历史状态难以统计的问题，如果业务系统没有对每次操作保留历史，一旦过了相应的统计时点，历史的状态就难以回溯，报表中常见的环比等需求是难以实现的。

所以，业务系统中的分析型需求一旦变多，就不得不做出抉择：要不要把分析型需求放在另外一个数据库实现。最简单的实现方式就是通过数据库同步工具把数据分析在备库实现，常规的数据库厂商都提供实时备库的方案，还有很多中间件产品也可以做到。但是很快结构的问题就会凸现，业务系统的数据模型是为了交易系统的模式（OLTP）设计的，在分析型（OLAP）场景上会 表现出严重的性能瓶颈。要不要为分析型需求单独创建数据模型？这样就出现了数据集市的雏形。

当一个组织的IT系统非常多，部门级的数据集市就可能会需要多个业务系统的数据。10年左右我所在的公司是做银行对私CRM的，对私相关的存款、贷款、理财、基金、信用卡等系统都是不同的系统。在没有统一的数据平台（数据仓库）的银行，这些数据都是需要我们去各个系统去拿，有的话就直接从数据平台拿就可以了。

如果不去构建数仓的公共模型、直接使用从业务系统的数据，也就是使用数据仓库贴源层数据，会产生很多独立的数据集市。这些独立数据集市会各自获取自己需要的数据加工，如果各个集市拿到的数据有交叉，在最终的计算结果上就会出现大家出的数据项的名字一样，但是数值不同的情况。因为缺乏统一，这个问题很难解决。如果管理方能接受稍微有些差异的统计数据，这个问题倒是也过得去。

但是如果有统一的数据仓库平台，这个问题就会迎刃而解。多个集市的公共数据统一计算、协调一致，构建一个公共数据层。这样组织（企业）的数据在数据仓库环境就可以拥有一份唯一可信的版本，所有的数据都集中到了数据仓库环境，并基于共同的数据做分析。

在数据仓库环境，可以支撑组织（企业）做面向企业经营管理的各种场景的数据分析、决策支持。

3.构建数据管理组织

如果只是在业务系统的数据库上直接做数据分析，很多时候我们只是要业务系统的研发人员兼职（未进行专业职业分工，开发质量与效率难以保证）把自己设计的表结构的数据分析统计做了。所以，在这种情况下并没有所谓的数据管理组织。但是如果从业务系统中剥离出来，构建了数据集市或者数据仓库，数据管理组织就会从业务系统的IT组织中剥离出来。

站在组织（企业）管理的统一视角，我们并不建议构建独立数据集市的IT架构，还是推荐构建基于数据仓库的IT架构和相应的管理组织。

从统一的视角出发，我们会把数据仓库（包括数据集成、数据公共层、数据集市），基于数据仓库的数据分析应用统一放到一个大的决策支持部门（团队）。这个团队要解决的问题就是数据分析，这个领域传统的叫法有“商业智能分析（Business Intelligence，简称：BI）”、“决策支持”。

在这个组织中会分化为两类大的工作分工，平台和应用。平台就是着眼于数据集成、公共层构建、数据管理、数据服务，用来支撑应用集市的各种能力。应用就是原来从业务系统中剥离出来的系统分析与改进、业务管理的分析与改进，这些数据分析的能力。整个团队的目标都是服务业务部门的数据分析，从层次上来说一前一后，从角色上来说一主一“辅”，共同完成业务的数据分析需求。

所以，从职能上可以把数据平台的组织分为三大块：平台管理团队、基础平台团队、数据应用团队。

平台管理团队负责整体平台的架构管理职能、数据治理职能，管理数据平台与数据应用团队进行日常数据研发与维护工作。平台管理团队的下辖的需求管理组负责整个平台的业务需求的统一管控，确保数据平台组织和数据应用组织对业务需求的理解是一致的、工作的分解是认可的。平台管理团队下辖的架构管理组负责制定和维护整个平台的集成架构、分层架构、服务架构。平台管理团队下辖的数据治理组负责制定面向质量、安全的管理要求和标准规范，监督整个数据平台组织的治理能力的落地执行。平台管理团队下辖的运行维护组织负责对整个组织内部使用的各项资源管理，软件与数据库日常运维。

基础平台团队是支撑数据应用团队的共性数据需求。数据应用组一般按照业务部门构建，会根据部门需求构建部门级的数据集市或者应用级的数据集市。基础平台团队所做的数据模型的建设工作，是面向数据应用中的公共的部分，例如原始数据的集成，明细粒度数据模型的设计，汇总粒度的数据模型设计。大体的划分原则是基础的集成和明细粒度数据，只要有一个应用使用，这个基础能力就要补充在基础平台组织的明细层模型。而汇总粒度的数据模型设计则需要2个以上的应用的共性需求，才会构建到基础平台汇总层模型。

数据应用团队的人员管理权限在数据平台，但是服务的对象是实际的业务部门。业务部门就是数据应用组的甲方，而数据应用组则是业务需求的承建乙方。组织架构如下：

4.构建数据管理流程

数据管理流程是指数据平台组织内部从需求到研发交付中各个组织、人员之间的协作流程。

●研发管理流程

上图是一个数据平台数据研发管理流程，从业务需求到数据开发都有哪些团队的什么角色的人员参与，不同的团队角色负责哪些模块。

1.业务部门提出需求。业务部门有专门与数据平台对接的角色，这个角色是业务部门中的IT人员，他们负责接收业务侧的业务需求转化为IT侧的需求。

2.平台管理团队的需求管理组会接受业务需求，并组织基础平台团队与数据应用团队来对业务需求进行评审和分解。这个过程会确定哪些需求可以在基础平台部门实现，要实现这些需求基础平台团队和数据应用团队都应该做哪些工作。这里的主要拆分原则就是公共、共享需求在基础平台团队实现和个性在数据应用团队实现。因为有的时候会做一些提前的设计，所以，这个公共的尺度主要由基础平台团队把握，由架构组和治理组定期参与评审。

3.进入设计与研发阶段，两个团队会通力配合，分别研发自己负责的部分，联合开发、测试、发布，并按照研发计划确保正常上线。

4.因为基础平台的公共层累积到一定程度，就可以覆盖大部分的基础数据需求。所以，基础平台团队在需求评审过程结束后可能并没有实际要开发的工作，只需要做好当前公共层数据数据使用的业务支持、答疑解惑。

●架构管理流程

架构管理主要管理两个方面，第一技术架构，第二业务流程架构。其中技术架构包括数据集成架构、研发分层架构。

数据集成架构确定了业务系统与数据平台之间的数据集成工具与方案，离线集成采用什么方案、实时集成采用什么方案，在什么系统和场景下使用什么方案。集成架构在两种情况下会有更新，第一新的系统集成需求，第二原有的集成方案不满足业务需求。

在需求评审阶段，如果遇到上面两个问题，可以邀请架构组进入到需求阶段评估，把架构问题验证通过并形成方案后，再进入开发阶段。

数据分层架构主要的目的是把数据研发工作分为贴源层、公共层、应用层这几个大的层次，原则上应用层只能从公共层获取数据、公共层的贴源层数据可以覆盖应用层的数据范围，公共层的汇总层可以覆盖多个应用层的共性加工需求。分层架构在平台创建初期制定，后期也不需要调整。架构管理组主要的作用是在开发阶段、运维阶段调研发现有违反分层架构原则的问题，并提出相应的整改要求。架构组的管理流程主要是发现问题，并发起整改的需求流程。

●数据治理流程

数据质量主要分为集成质量、数据加工质量、线上服务质量三部分。管理流程主要是确保质量工作做到位、及时发现质量问题，并跟进问题的解决。

质量工作检查点流程要在研发工作中嵌入，开发脚本后是否有做单元测试，测试的报表是否有主管的review确认。应用上线前有没有做应用的功能测试、数据验证测试，是否有主管的review确认。重要的业务，是否做了线上质量问题监测的任务。这些检查点，要能在日常工作中体现，并可以给质量团队按期审核。

数据质量问题发现。通过源端数据质量监测、线上数据质量问题监测，及时发现问题。并通过治理流程，把问题派发到相应的责任组织进行改进。

数据安全主要解决日常工作使用数据的安全流程。主要分为数据研发过程中的安全检查点及数据权限申请与审批流程。

数据安全检查点要在研发工作中嵌入。依据最小可用原则，在研发阶段申请到的安全级别高的数据权限，在进入上线后固定时间区间会被自动释放。每一类数据表和数据项，原始的数据安全分级在加工后要进行重新评定。

数据权限申请与审批流程，确定了组织内哪些组织是数据的生产方和拥有者，拥有者最终审批决定数据内容的访问权限。审批流程要能体现出相关的业务需求和功能需求确实需要相应的数据进行开发、业务分析等场景，并能体现实际操作人员和其主管的审批责任。还有是否设定专业的评审角色对相应流程进行管理，数据分类分级的审批结果是否在组织内部定期回顾等。

●运维管理流程

运维管理是研发管理的延伸，数据研发的意义不是研发过程而是数据本身，数据平台提供了数据的服务，保障服务的质量也是数据质量的一个方面。

运维管理流程从平台基础技术组件、平台批量任务运行、平台提供的数据服务能力几个方面对平台进行运维保障。平台运维管理流程主要的目的是在发现问题后，保障整个组织能快速的对对问题做出决策，找到第一责任人和问题兜底处理团队，确保问题快速修复。并能在事后，对问题发生的原因进行分析改进与问题追责。

资源管理流程从整个平台资源规划与利用的角度，对新创建的数据应用、原有数据应用对数据平台的资源使用进行合理的扩容、缩容。在平台管理团队发现对资源使用不利的问题后（例如存储资源、计算性能），引入架构团队与研发团队，共同对问题进行解决。也可以由应用侧发起流程，引入运维与架构团队，协助问题处理。

三、加速数据服务业务

1.数据中台还是后台

“数据中台还是数据后台“，这是一个涉及到本质的话题。从组织整体架构来看，IT部门就是一个后台支持部门，业务部门才是前台部门。从IT架构来看，业务和生产系统才是一线人员的核心支撑，数据分析更多的是从事后分析和事中研判的角度出现，仍然是一个偏后台的角色。

从管理和经营的角度来看，这部分工作主要依托数据分析的结果进行辅助决策，所以对数据分析的依赖更高。即便是某个生产过程中的最细小的环节，在进行数据分析后都可能获得巨大的业务改进价值。但是困难的是如何能从数据中发掘出能改进业务、辅助决策的数据价值。

在传统的数据仓库环境，数据部门一直被当作一个后台部门。常规的业务模式就是被动响应的模式，对业务部门的响应与业务需求之间的关系是迟滞的。之前参与过的一个项目，一线人员提的需求，排计划都排到了1年以后。后台部门能获取到的资源都是局促的，数据服务业务的能力也是局促的。

所以，回过头来看数据中台，我们是否转变思维，核心还是要把数据部门放到更重要的位置，加大对数据部门的投资。让数据部门对业务的支撑能力和规模更大，相比之前更加前置。让数据部门从一个纯成本部门的位置变成真正的价值部门的位置。

值得关注的是，在近些年大数据风起云涌带来的巨大的技术变革中，阿里提出的中台战略依托这种变革看到了数据服务业务的更大的潜力，并兴起了数据中台建设的大潮。

2.加速数据服务业务

数据中台最核心的诉求，还是希望加速利用数据服务业务。因为“数据服务业务”这个口号可能几十年前就有了，所以相比之前数据中台要做的就是让这个过程的速度更快，“加速数据服务业务”。

如何加速呢？大数据技术给我们带来了更多技术的可能，让数据服务业务的能力和范围更加扩展。但是并不能解决速度问题，如果组织规模和能力不变，反而可能因为事情变多、技术变复杂，变得更慢。所以，构建中台化的组织是非常重要的。从技术上补充大数据与算法分析的人员能力，从组织上对数据团队进行分化扩充，让数据对业务支撑从以前的力不从心变成绰绰有余才可以做到真正的加速。

对数据中台的投资近些年变的越来越大，越来越多的组织尝试对自己的数据团队做出变革，引入相关的技术与项目。但是我们是否从本质上对组织结构和模式做出改变呢？我们是否创建出了更加敏捷的数据业务化、业务数据化的通路，来适应这个大变革的时代？

对数据部门来说，我们要怎么做调整工作方法和思维，才能加速数据服务业务？数据中台的核心思想其实已经告诉我们，就是“服务化”。只有我们把数据变成各种触手可得的服务，才能真正做到加速。

服务化（数据即服务、信息即服务、分析即服务）需要我们把业务人员需要的不同层次的数据、信息、分析都变成服务，用服务化的思想，服务化的流程去支撑业务。从之前的被动响应变成主动推送，从业务人员自己去发现问题提出改进需求，变成与一起为业务人员发掘需求，变成业务人员的左右手。

为此，我们需要面向更好的服务业务去建设服务化的能力与应用，构建面向服务的组织。只有这样才能真正实现数据中台的业务目标。

3.构建服务化的组织

服务化的组织的创建要以服务为目标构建，要创造一个数据部门的“客户服务团队”，这个团队能快速响应业务部门对数据部门的服务需求，并在组织内部分解需求，对需求做出快速的响应。所以，在组织架构的设计上，我把数据管理组重新定义为数据服务组，并在这个组织下新增数据服务运营（资产运营）组。

服务化的起点一定是组织的管理层以服务化为目标去构建组织，所以要在管理组织内分化出数据服务管理职能。数据服务团队除了之前对数据平台和数据应用组织有协调和指导的作用，组内需求管理、架构管理、数据治理、运行维护等职能外，新增数据服务运营子团队（服务运营&资产运营）。这个团队与数据平台和数据应用一样，也是一个直接负责对接业务、解决业务问题的组织。这个组织通过梳理整个平台的数据资产，提供平台层面的数据资产服务门户，对整个平台的服务能力和服务质量进行监督管理。并通过资产门户直接面对一线业务人员和数据研发人员提供数据平台的数据和应用的咨询服务、即时分析服务，收集平台侧零散的业务和技术需求，并从服务的角度评价平台的产品、团队的服务能力。

4.构建数据服务流程

服务化的组织需要整合和重构原有的业务流程，通过服务化去减少或者缩短业务与数据之间的距离。下图是一个依托数据门户的服务流程举例：

在数据中台的服务构建中，数据门户是非常重要的一环。门户会让数据团队与业务人员之间的技术和距离的鸿沟消失，构建出一个交互和共建的数据协作平台，通过对平台所有数据资产的梳理与服务以及问答等服务化的方法让原有的数据研发流程变短。所以，我们的数据服务流程都要以资产门户为基础去构建。

上图是一个面向服务的数据研发组织阵型，每个数据团队都有不同的分工。但是我们在传统的数据需求组织直接面对业务部门的基础上增加了数据服务组织。我们以下面几个场景为例，来看服务化流程。

1.数据服务场景。通过数据资源目录找到相应的数据，申请权限；

2.数据报表需求；

a需求：定义报表，指标定义,标签定义b开发：数据元定义，模型设计,数据模型映射，算法定义；c运维：质量问题反馈

3.数据问答；

a找不到数据；数据服务组，指定到数据资源目录对应的表；b对特定数据使用问题；数据服务组解答，如果是质量问题，转到质量管理；开发把质量问题转变为需求，需求组审核，进行开发；

4.数据安全；

a 治理组，定义新增数据源的数据安全；b 数据组，数据变化后，修改数据安全的定义级别；c 治理组，审核通过后，定义最终确定后才会在数据资源目录开放；

四、道路艰险而漫长

从管理学角度，组织（Organization）即由若干个人或群体所组成的、有共同目标和一定边界的社会实体。它包含三层意思：

(1)组织必须是以人为中心，把人、财、物合理配合为一体，并保持相对稳定而形成的一个社会实体。

(2)组织必须具有为本组织全体成员所认可并为之奋斗的共同目标。

(3)组织必须保持一个明确的边界，以区别于其他组织和外部环境。

上述三条，是组织存在的必要条件。

数据中台的组构建是数据中台成功的关键因素，并不是我们购买了某一款中台产品或者做了一个相关咨询就能达成中台的目标。我以一般的数据仓库项目为例，在做数据仓库项目的时候，我们长用3-5-7这三个数字来衡量一个组织数据仓库平台的成熟度。即便是客户购买了行业领先的行业解决方案和产品，也需要3年才能达到基础，5-7年才能相对成熟。而数据中台架构中又包含数据仓库的构建，涉及的组织面更大、涉及的工作范围更大，即便我们仍然使用数据仓库的标准来衡量，我们现在的数据中台项目大多还都处在打基础这个范围内（阿里大约在2018年左右提出了数据中台架构）。

在数据中台构建的道路上，我们仍然会遇到很多很多的未知和困难，只有不断的排除这些困难才能达到最终的目标，中台化的组织构建就是实现这个目标的利器。

因为每个组织对中台的需求和目标都可能有差异，组织内部也各有不同，以上的内容思考更多是从一个行业参与者的个人角度，给相关的组织提供一些思考和参考的内容，思考有所欠缺的部分还请指正。

原文链接

本文为阿里云原创内容，未经允许不得转载。

浅谈数据仓库架构设计

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）的基石。

（概念引用：商务智能与分析-决策支持系统）

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架构

• 辐射状企业信息工厂（CIF）

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

从上面几张图上我们可以看到，之所以在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 Kimball与Bill Inmon都应该使用维度模型来构建。

1.3. 综合的选择

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

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

原文链接

本文为阿里云原创内容，未经允许不得转载。