因为近期工作的变更，一直在忙一些杂七杂八的东西，工作交接、离职手续及对新工作的思路整理，目前还处在这个阶段，所以可能近期没有比较新的内容跟大家分享，最近的几篇文章会以一些总结的内容为主，主要是对之前的工作中的一些感想。但相信之后会有更加丰富的数据分析相关的内容向大家呈上，因为我相信我要去的新公司是一个朝气蓬勃、充满创意和挑战的地方，而最重要的是他们对数据的重视和理解。

　　看到文章标题，相信大家已经知道这篇文章还是关于BI方面的，其实这是我刚进现在所在公司的时候所写的一篇文章，现在回头看来即使一直努力地在协调好这些矛盾，但说实话最终没有一个是真正完完全全的解决了的。我相信如果其他公司也是自己搭建BI系统的话，多多少少也会遇到这些问题，可能其中的一两个矛盾现在也正困扰着大家，我这里提供了我的解决方案，至于可行性和效果，有待大家去验证。

矛盾一：业务部门对数据的理解与数据部门对需求的理解

　　把它放在第一位是因为这个直接影响着数据所能发挥的效用，或者说这个矛盾没协调好的话，数据所能创造的价值将大打折扣。造成这个矛盾的原因就是业务部门无法了解数据的获取、处理、计算整个流程，从而对数据的含义和用处产生了自己的理解；同时数据部门无法真正了解业务需求，不清楚数据到底用于何处，为了监控或评估产品的哪个方面，于是无法提供最优或最有效的数据。

　　解决方案：建立业务部门与数据部门间的接口。这个接口包括规范的流程、详细的文档、合理的数据展现，而最重要的还是能够衔接起业务和数据之间的人。

　　首先是数据需求流程的规范化，也就是需求一般由业务部门提起，通过数据部门对数据的获取和计算将结果返回给业务部门，这个流程中业务部门不仅要提供数据的规则，同时应该对获取数据的目的、指标的定义、用处和价值做出详细的描述；而数据部门不仅要给出最终数据，同时需要对指标的获取途径、计算方法作出解释，最终的目的都是为了使双方在理解上能够达成一致。

　　其次是详细的文档。这个其实就是上面所说的流程中必然会产生的两类文档：数据需求文档和数据解释文档（在数据仓库里面是元数据的重要组成部分，关于数据仓库的元数据一直想整理一篇文章出来，希望在之后尽快贴上来），文档的内容基本就是包含上面流程中提到的那些内容。

　　再者就是合理的数据展现。其实就是一个原则：让每个人看到自己想看的数据，并能直观地理解这些数据。无论是报表、Excel还是其他展现方式，每个指标都应该能够有途径去直接查看相应的数据解释文档，而数据应该以最直观的方式展现出来以方便理解，借助各类图表结合的方式。

　　最后也是最重要的一点就是业务与数据的衔接者。这类人员应该对产品的战略目标、业务流程十分熟悉，同时对数据的获取途径、计算方法也了如指掌，或许不需要涉及高技术难度的数据ETL处理、组织和优化，但必须具备自己去计算和获取各类数据的能力。

矛盾二：业务需求的不断变化与生成数据的复杂流程

　　业务需求是不断变化的，尤其是身在互联网这个发展迅速的环境中。所以我们往往会遇到每天业务部门都会有新的需求过来，或者几天前某个指标的计算逻辑在几天之后就发生了变化。而数据部门面对这些情况，往往会陷入困境，一方面由于数据获取上的问题导致某些指标没法计算得到，另一方面指标计算逻辑的改变可能需要改动到整个复杂的数据处理流程，令人头疼。

　　解决方案：集成化的完整的底层数据与快速灵活的数据获取途径。

　　其实在关于数据仓库架构的文章中就提到过数据仓库尽量保存所有的底层细节数据，包括原始的日志点击流数据和前台数据库的ODS数据以及其他来源的数据，其实我不太建议数据仓库是单纯根据需求建立起来的多维模型，因为需求始终会变，但多维模型在应对变化时有缺失灵活性。而如果保存的底层数据，其实在大部分时间内就能做到以不变应万变，因为几乎所有的指标都是从这些底层数据中计算得到的，拥有了底层数据相当于满足了大部分数据的需求。

　　还有一个问题就是对需求改变时的及时应变，一种方法是建立面向不同主题的多维模型（当然是在底层数据的上层建的），因为多维模型能够满足从多个角度多个层面对数据的观察分析，能够从一定程度上解决数据的多样需求；同时基于底层数据集成化的组织管理环境，使用标准化的统计语言，如SQL语句，借助其强大的对数据的聚合、排序、分组等能力，加速数据的获取和计算。

矛盾三：数据即时查询的效率与海量数据的处理和建模

　　其实这里又是一个权衡的问题，即如何在提供足够丰富的指标的前提下保证数据的展现、获取和查询的效率能够满足数据需求方的要求。如果提供的指标不够，或者数据的粒度不够细，就无法满足日常数据监控和分析需要；相反，如果每天计算和统计的指标过多或者数据分得太细，那么显然会增加服务器运算的负荷，同时在数据查询上的响应能力也会相应的下降。

　　解决方案：把握核心数据，建立合理的多维模型。

　　其实数据仓库中海量数据的处理和查询效率的问题本身就是一门很深的学问，涉及数据仓库结构和ETL的优化、OLAP的优化（上一篇文章——OLAP的基本特征有提到Oracle在这方面所做的优化），这里不谈论这些技术上的实现途径，还是说应用上的。

　　核心数据，简单说就是网站的目标、KPIs等，这些数据是从高层到基层人员都在时刻关注的数据，所以最优先的原则就是保证这些数据的查询效率和及时响应。最简单的做法就是这些指标独立统计，不放入多维模型，只做每天的简单聚合存入Summary表中直接供报表展现。

　　另一个就是建立合理的多维模型，说到合理这里又要抱怨下，数据的需求方起初会漫无边际地提各种需求，可能会有上百个指标，但一旦统计出来之后很少会有人真正去使用和分析这些指标（估计是因为看了会眼花），这个我在关于实时数据统计中提到过类似问题。因为在多维模型中增加一个维或维的层次加深一层，对于立方的数据是以乘积方式递增的，比如增加一个100条记录的维相当于立方的数据乘以100，或者时间维的粒度从天到小时，相当于数据量是原先的24倍，这个对于那些本身数据量就非常庞大的多维模型而言本身就是一场灾难。所以建立多维模型时的原则是提供实际应用中需要的维和指标，同时把握好各个维的层次粒度。

　　上面就是我遇到的三大难题了，一下子又写了这么多，希望大家有耐心看完。其实之前的工作也较多地涉及了一些技术上面的东西，主要是Oracle和PL/SQL，由于对于那方面不是很擅长，另外博客主要面向网站数据分析方面的主题，所以很多总结的东西也不敢拿出来献丑，如果大家希望也有这个方面的讨论的，我可以分享几篇上来，大家可以留言给我点建议。