如果说整体架构规划是比较遥远和飘渺的事，那么数据仓库架构的中心部分----数据架构，将为我们打开把远期规划和现实项目的实施紧紧地联系在一起，我们可以从现实出发，找到方向的突破口。BTW，今天在公司洋洋洒洒写了10多页关于数据架构的文档，为近期项目做技术准备，等架构定了后，我就开始深入熟悉公司具体业务和现有模型了，现在只是有一定了解而已，但细节架构是根据实际情况去定制的。
　　现在简单说下思路。这些并不是理论，更不是论文，而是经验的描述，不知道唯业务流程是论者看到这些，是否认为技术架构对业务分析的长期有效的支持，是可实现的和很有必要的呢？
　　一. 数据流架构，主要是设计数据流需要多少层次，每个层次的功能必须有独特的定义。ODS是否只有为数据仓库做数据准备的功能，EDW是否没计划和条件去建设范式模型，是否多个集市，多个集市需要统一维度建模，数据集市到底要满足哪些BI功能，这些问题都决定了数据流架构如何去设计。
　　二.数据管理架构。
　　1. 考虑历史存储方式，根据数据使用频率和价值，是否参考DW2.0理论进行数据管理。
　　2. 存储方式的角度，从粒度上讲，维度模型的数据仓库到底需要多大的粒度，特别是时间方面的维度，数据集市到底需要多大的粒度。而从应用数据方面讲，是否需要在数据集市中将维度信息加在事实表中，需要加多少进去，甚至形成大宽表，方便报表或者查询以及数据挖掘。
　　三. 业务数据架构。
　　目前包括国际大厂商的行业模型，其实都是从平面角度看业务，虽然业务上包括很全，但从技术上讲，并不是更合理的模型架构，或者没有架构，只是平面的模型，是否我们就直接拿来用，不需要架构了？以下做简要说明：
　　1. 业务数据流。（1）针对表的考虑。需要考虑不同业务定义中，表当中到底存储多少信息，是多种定义放一起，还是不同定义存储在不同的表。高时间粒度事实表是在数据集市直接通过低粒度事实表汇总，还是从维度建设时就分出来ETL。考虑扩展原因，最好不要多种定义的数据放一起，这样扩展性不强，也不容易维护。
　　（2）针对字段的考虑。维表主要考虑到维数据的增强性描述，事实表主要是度量的描述以及退化维的生成，不过衍生度量和退化维一般在统一维度层或者数据集市中完成，根据是否是企业级定位而定。
　　2. 业务数据管理架构。一般国际大厂商的行业模型，会有很多衍生表来描述不同业务定义的维信息，不过这种扩展性仅仅还是停留在平面层次。如果要适应更大更复杂的业务变化和组织机构变化需求，我们的管理架构需要细到管理相应的业务元数据。根据模型技术的发展，针对主题模型，我们可以设计出辅助模型来描述元数据，达到最大的业务变化/增加、组织结构变化/增加的支持。在实际项目中，根据业务调研，设计出相应的参考模型组，并维护参考表数据（一般100条数据以内），然后在统一维度建模中，由参考表和主体业务模型关联而成统一可信高可扩展性的维表。
　　四. 数据安全架构。
　　一般安全管理分为操作系统级、数据库级、Schema级、表/视图级、数据级（行数据），以及BI界面控制级别、CUBE控制等多个层次。这里主要说的是数据行级。在维度数据仓库，达到所谓数据行级控制，可以通过类似BI界面那样的多个组合权限组，然后结合事实表进行权限控制。
　　五.数据质量架构。
　　数据质量控制本身有多个因素组成，包括业务调研、ETL、测试严密性等，这里主要从数据建模的角度考虑。一般可以设计相应的控制表来一定程度控制，比如维度数据有效性。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。