数据仓库架构之数据架构规划与设计

申请免费试用、咨询电话：400-8352-114

如果说整体架构规划是比较遥远和飘渺的事，那么数据仓库架构的中心部分----数据架构，将为我们打开把远期规划和现实项目的实施紧紧地联系在一起，我们可以从现实出发，找到方向的突破口。BTW，今天在公司洋洋洒洒写了10多页关于数据架构的文档，为近期项目做技术准备，等架构定了后，我就开始深入熟悉公司具体业务和现有模型了，现在只是有一定了解而已，但细节架构是根据实际情况去定制的。

现在简单说下思路。这些并不是理论，更不是论文，而是经验的描述，不知道唯业务流程是论者看到这些，是否认为技术架构对业务分析的长期有效的支持，是可实现的和很有必要的呢？

一. 数据流架构，主要是设计数据流需要多少层次，每个层次的功能必须有独特的定义。ODS是否只有为数据仓库做数据准备的功能，EDW是否没计划和条件去建设范式模型，是否多个集市，多个集市需要统一维度建模，数据集市到底要满足哪些BI功能，这些问题都决定了数据流架构如何去设计。

二.数据管理架构。

1. 考虑历史存储方式，根据数据使用频率和价值，是否参考DW2.0理论进行数据管理。

2. 存储方式的角度，从粒度上讲，维度模型的数据仓库到底需要多大的粒度，特别是时间方面的维度，数据集市到底需要多大的粒度。而从应用数据方面讲，是否需要在数据集市中将维度信息加在事实表中，需要加多少进去，甚至形成大宽表，方便报表或者查询以及数据挖掘。

三. 业务数据架构。

目前包括国际大厂商的行业模型，其实都是从平面角度看业务，虽然业务上包括很全，但从技术上讲，并不是更合理的模型架构，或者没有架构，只是平面的模型，是否我们就直接拿来用，不需要架构了？以下做简要说明：

1. 业务数据流。（1）针对表的考虑。需要考虑不同业务定义中，表当中到底存储多少信息，是多种定义放一起，还是不同定义存储在不同的表。高时间粒度事实表是在数据集市直接通过低粒度事实表汇总，还是从维度建设时就分出来ETL。考虑扩展原因，最好不要多种定义的数据放一起，这样扩展性不强，也不容易维护。

（2）针对字段的考虑。维表主要考虑到维数据的增强性描述，事实表主要是度量的描述以及退化维的生成，不过衍生度量和退化维一般在统一维度层或者数据集市中完成，根据是否是企业级定位而定。

2. 业务数据管理架构。一般国际大厂商的行业模型，会有很多衍生表来描述不同业务定义的维信息，不过这种扩展性仅仅还是停留在平面层次。如果要适应更大更复杂的业务变化和组织机构变化需求，我们的管理架构需要细到管理相应的业务元数据。根据模型技术的发展，针对主题模型，我们可以设计出辅助模型来描述元数据，达到最大的业务变化/增加、组织结构变化/增加的支持。在实际项目中，根据业务调研，设计出相应的参考模型组，并维护参考表数据（一般100条数据以内），然后在统一维度建模中，由参考表和主体业务模型关联而成统一可信高可扩展性的维表。

四. 数据安全架构。

一般安全管理分为操作系统级、数据库级、Schema级、表/视图级、数据级（行数据），以及BI界面控制级别、CUBE控制等多个层次。这里主要说的是数据行级。在维度数据仓库，达到所谓数据行级控制，可以通过类似BI界面那样的多个组合权限组，然后结合事实表进行权限控制。

五.数据质量架构。

数据质量控制本身有多个因素组成，包括业务调研、ETL、测试严密性等，这里主要从数据建模的角度考虑。一般可以设计相应的控制表来一定程度控制，比如维度数据有效性。