由于数据结构的多样性（结构化、半结构化、非结构化），催生了Hadoop生态圈技术的快速发展。大数据。。。我们要做数据分层，采用哪种方式建模呢？尽管维度建模方法已经被广泛采用，但误解依然存在。这些错误的断言会给我们工作带来麻烦，特别是想带领团队做一些最佳实践时，可能会出现对选取维度建模方法的质疑和批评，这时我们需要有一套强有力理论以回击那些保守的家伙。
规划DW/BI系统数据结构需要考虑业务的所有业务过程，以及一些主要的维度描述信息。通常我们可以采用数据仓库矩阵的形式来描述指标。矩阵的潜在好处是提供了一个灵活且更加严谨的主数据管理平台。
数据治理需要考虑主维度级（主数据矩阵）。思考并提炼出描述业务的中心名词，将其放入到来自各个专家团队的数据管理项目列表中。建立这些关键名词的最终目的是开发出一套具有统一一致性，满足业务分析过滤、分组、标识等要求。健壮的维度是后续建立数据中台的基础。
Kimball维度建模思想的基本要素如下：
汇总数据只是维度模型的一部分
由于不能预测业务用户所提出的所有问题，因此必须向业务用户提供对详细数据查询的功能，这样也能够实现数据的上卷操作。维度模型中需要有大量的历史数据，但是具体的历史数据量需要业务需求驱动。
维度模型是企业级而非部门级的
维度建模应该围绕整个业务过程各节点来开展，例如，订单、采购、发货等操作，而不是按照业务部门进行划分的。多个业务部门往往需要分析来自同一个业务过程的相同的度量。数据模型应该避免重复获取同一个数据源的数据，否则会造成数据不一致性。
维度模型是易于扩展的
维度模型天生的优势就是易于扩展。事实表通常包含海量的数据行，规范的数据维度模型中包含详尽的数据关系。这样维护维度模型只需要维护事实表的外键和维度表的主键值即可。
维度模型不仅仅用于预测
将维度模型设计为仅仅关注预定义的报表或者分析是不可取的。维度建模需要把注意力集中在度量事件上，因为与不断变化的数据分析相比较，度量事件还是相对稳定的。
实现灵活查询的灵丹妙药通常是以最细粒度建立事实表。仅仅发布有汇总数据的事实表和维度表是远远不够的。维度模型中正确的做法是以最详细的粒度表达数据，这样才能获得最好的灵活性和可扩展性。
维度模型是可以集成的
如果采用企业数据仓库总线模式，维度模型多数情况下是可以被集成的。一致性维度作为集中的、持续的主数据建立在主ETL系统中。跨维度模型的重用能够实现数据集成和语义一致性。数据集成依赖于标准标识和定义。实现一致性维度非常困难，但是数据建模不能回避困难，必须要建立数据规范化标准并付诸行动。
若展现区的数据如果不采用一致性维度的总线结构，将会产生烟囱式的解决方案。
三、统一一致向前看
打开我们的视野，从全局去观察整个大数据的运作。我们需要对大数据进行分层，数据模型的分层通常可以分为ODS、DWD、DWS、ADS、DIM：
在整个大数据链路中，可以分为采集--同步--离线（实时）计算-存储-线上回流节点上。在后续的文章中我们来一一详解。
作者：清和 来源：大数据漫路求索
| 欢迎光临 168大数据 (http://www.bi168.cn/) | Powered by Discuz! X3.2 |