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

 　　之前的文章——网站数据分析的一些问题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、数据仓库是否就应该保存聚合数据，细节数据不应该放入数据仓库? 　　其实这个问题基本已经达成共识，如果是构建企业级的数据仓库，那么对细节数据的集成和存储是必不可少的，但现实中还是存在很多直接从外部数据源计算聚合之后导入数据仓库的实例。如果对数据仓库只是轻量级的应用，仅存放聚合数据也无可厚非，毕竟没人规定数据仓库一定要是怎么样的，最终的目的无非就是满足对数据的支持和需求。 　　但对于企业的长期发展来看，数据仓库中存放细节数据有两方面的好处：一方面从技术层面，数据仓库存储细节数据可以释放前台数据库的查询压力，同时对于文本类数据和外部文档类数据入库之后管理更加规范，数据仓库保留历史和不可变更的特