网站数据分析的一些问题3：数据仓库相关的问题.pdf

网站数据分析的一些问题 3：数据仓库 相关的问题 之前的文章——网站数据分析的一些问题 2中主要整理了 BI相关的问题， 这篇文章主要想整理一些数据仓库相关的问题。因为最近重新在看一些数据仓 库的资料和书籍，想把之前以及当前遇到的主要问题提出来(博客中有关数据仓 库的相关内容请参阅网站数据仓库这个目录)，同时自己也对数据仓库方面的知 识进行下重新的整理和认识，而且很久没有在博客发新的文章了，不能让自己 过于懒散了。 之前看过 Inmon的《构建数据仓库》和《DW 2.0》，而另外一位数据仓库 大师 Kimball的《数据仓库生命周期工具箱》一直没有时间阅读，最近才有时 间看完了大部分，就迫不及待想写点东西了。其实数据仓库领域普遍认为 Inmon和 Kimball的理论是对立的，两者在构建数据仓库上方向性的差异一直 争论不休，谁也无法说服谁到底哪种方法更好。我的 Evernote的笔记里面不知 什么时候从哪里摘录过来了对两者观点的概括性描述，非常简洁明了而一针见 血： Inmon vs Kimball Kimball – Let everybody build what they want when they want it, we’ll integrate it all when and if we need to. (BOTTOM-UP APPROACH) Pros: fast to build, quick ROI, nimble Cons: harder to maintain as an enterprise resource, often redundant, often difficult to integrate data marts Inmon – Don’t do anything until you’ve designed everything. (TOP-DOWN APPROACH) Pros: easy to maitain, tightly integrated Cons: takes way too long to deliver first projects, rigid 其实看了《数据仓库生命周期工具箱》之后，发现两者的观点没有那么大 的本质性差异，可能随着数据仓库的不断发展，两者在整体的架构上慢慢趋 同。基本上，构建统一的企业级数据仓库的方向是一致的，而 Inmon偏向于从 底层的数据集成出发，而 Kimball则趋向于从上层的需求角度出发，这可能跟 两者从事的项目和所处的位置有关。 有了上面这段高质量的概括，第一个问题——你更偏向于以何种方式搭建 数据仓库(BOTTOM-UP or TOP-DOWN)，分别有什么优劣势?——其实就不用问 了，所以下面主要提几个在实际中可能经常遇到或者需要想清楚的问题： Q1、数据仓库的技术解决方案有哪些，这些解决方案的优势在哪，瓶颈在 哪? 随着数据仓库的不断发展和成熟，“大数据”概念的风靡，有越来越多的 相关产品出来，最常见的技术解决方案包括 hadoop和 hive，oracle，mysql 的 infobright，greenplum 及 nosql，或者多个结合使用。 其实归纳起来就两类：一是用传统 RDBMS为主导的数据库管理数据， oracle、mysql等都是基于传统的关系型数据库，优势就是有更严谨的数据结 构，关系型数据库对数据的管理更加规范，数据处理过程中可能出现的非人为 误差极小，而且标准的 SQL接口使数据获取的成本较低，数据的查询和获取更 加灵活和高效;但劣势也很明显，对海量数据的处理和存储的能力不足，当数据 量达到一定程度的时候就会出现明显的瓶颈。而是基于文本的分布式处理引 擎，hadoop、greenplum 和 nosql都是基于文本数据的处理和存储，优势是强 大的数据处理能力，分布式的架构支持并行计算，并且具备超强的扩展延伸能 力;劣势就是上层接口不方便，因此 Hadoop上层的 hive和 greenplum上层的 postgreSQL都是为了解决数据接口的问题，并且数据的查询和获取很难做到实 时响应，灵活性不足。 Q2、数据仓库是否就应该保存聚合数据，细节数据不应该放入数据仓库? 其实这个问题基本已经达成共识，如果是构建企业级的数据仓库，那么对 细节数据的集成和存储是必不可少的，但现实中还是存在很多直接从外部数据 源计算聚合之后导入数据仓库的实例。如果对数据仓库只是轻量级的应用，仅 存放聚合数据也无可厚非，毕竟没人规定数据仓库一定要是怎么样的，最终的 目的无非就是满足对数据的支持和需求。 但对于企业