网站数据分析教程:关于网站数据分析常见问题

申请免费试用、咨询电话：400-8352-114

从事数据仓库和数据分析相关的工作也有段时间了，其实很多问题一直萦绕在脑中，有些甚至已经困扰相当长的一段时间，自己也在不断学习和工作的过程中寻找各种解决方案或者不断优化和替换之前的方案。这些问题从宏观层面到细节层面，很多问题其实没有绝对完美的解决方案，我们只能一步一步地摸索，不断寻找更优的方案以其让问题能够更好高效地得到解决，但每个人掌握的知识有限，所以无论怎么样每个人对问题的看法都会存在局限性；同时因为每个人的知识背景和经历的差异性，对各种问题又会触发各种不同的见解，所以通过集思广益往往能够得到让人眼前一亮的结论。

先说说博客，无论怎么样我的博客只是想做些记录和总结，只是表述一些个人的观点，我想每个人在学习工作中总会有所积累，有自己在专业领域的一些收获，每个人公平地享有相同的时间，每个人学到的掌握的都是有限的，没有孰强孰弱之分，差别只在于愿不愿意将其分享出来；博客中整理的内容，可能有些人认为不适合公开，毕竟有些东西还有些实用价值，但必须看到的是目前互联网发展速度太快了，我之前发的文章等半年之后回去看就会发现当时自己的想法并不成熟，如果在现阶段可能不会完全按照上面的思路去实现了，知识的更新和积累让我们不断选择更优的方法，不断改进和升级自身的知识体系，更何况很多东西在一个业务体系下适用，到另外的体系下就不适用了，聪明的人不会完全照搬照抄原方法，而是寻找最合适的方法，或者使用更灵活变通的方式去使用方法，所以也不必担心技能被“偷学”，因为只会模仿的人不知道怎么用好这些方法，而足够聪明的人到哪里都能学到适合自己的方法，在这个信息膨胀的环境下无法阻止他们的“偷学”。

其实博客最大的收获还是通过博客认识了很多朋友，尤其是网站分析领域的，相当一部分也有自己的博客，大家互相交流学到了很多东西，有些东西是互补并相互促进的，这些朋友都是乐意分享自己想法的人，每个人都有各自领域的专业和强项，这样反而使我听到和学到了很多耳目一新的东西，受益匪浅。所以如果你有时间写写博客，那么得到的收获绝对要比你觉得可能会失去的多得多。

既然我在博客里面已经写了很多，所以这里想换一个角色，我想通过几篇文章把之前遇到的诸多问题罗列出来，希望大家能够不吝提出自己的看法和解决方案。其实我更希望在博客的评论中看到更多不同的看法或者通过文章的思路扩展衍生出在其他方向上有价值的应用。另外，知乎真的是一个非常棒的知识分享和学习的平台，潜藏了很多的大牛，我会把整理的每个问题都贴到知乎上面，这样可以收集到更多牛人的看法，希望大家在知乎上有认识相关领域的大牛的可以积极地进行邀请。

这篇是第一篇，想重点罗列一些跟网站数据分析行业和数据分析师相关的问题。

Q1、 你因何会选择网站分析或互联网数据分析这个行业，你认为这个行业的价值何在，发展前景如何？

我的答案：互联网是一个阳光行业，而数据分析本身又是一个非常有意思的工作，很多时候，它就像是一个侦探从细枝末节的线索中寻找那个唯一的真相，如果你喜欢这种探秘的感觉，那么你同样会喜欢上网站数据分析这个行业。

其实我之前在《网站分析的应用和价值》这篇文章中介绍过网站数据分析的价值（这里不引用链接了，大家可以搜一下），简单地说就是“系统地帮助网站实现更加高效的运营”。

互联网数据量的快速膨胀，急需对数据进行系统化的处理和分析，以便快速地发现信息，转化价值，所以就目前来看，无论是国外的发展趋势，还是国内对这个行业的需求都是快速增长的，发展前景是比较乐观的。

Q2、 作为网站的数据分析师，你完成的最有成就感的事情是什么，感到最纠结的事情又是什么？

　　我的答案：最有成就感的事情就是用数据实现价值，无论是通过数据排查问题进而解决问题，还是通过数据分析应用优化网站产品，其实都是创造价值的过程。

最纠结的事情其实不是整日需要维护和验证数据的一致性、准确性，数据时常会存在诸多细节上的问题，因为这些基本是必然存在的，无论在哪个公司，网站从事何种业务，技术或者数据的环境如何，数据的问题还是无所不在，而保证数据质量本身就是数据分析师最基础的工作，也是开展分析的前提和基础。

我最纠结的还是在于数据的需求和应用，如果与数据的需求方在数据的理解上达不成一致，那么很多数据需求就会存在反复的调整变动，期间就会做很多重复的工作或者无用功，甚至有些时候数据分析师大费周章地提取的一份数据在需求方那里只是用几秒钟扫视一遍，没有产生任何的价值，这也是令数据分析师最伤感的事情。所以数据分析始终要从获取最终insight的角度出发，如果数据需求中无法说明获取数据是为了试图得出何种insight，那么这个需求基本就没有实现的必要了。

Q3、 作为网站的数据分析师，你日常工作中最常做的是什么，需要与哪些同事交流，一般会用到哪些工具？

　　我的答案：数据分析师的日常工作很简单，就是数据处理和观察报表，而且这两块工作会占用每天的大部分时间。如果每天能够准时提供准确的报表，及时地反馈数据异常，那么你已经是一个合格的数据分析师了。

数据分析师要接触的部门会比较多，可以是任何有数据需求的部门，运营、产品、市场、销售、客服……甚至是各层级的BOSS。

同样，数据分析师日常使用的工具其实也非常简单，估计在90%的时间都在使用数据库的SQL、Excel或者PPT，当然视每个公司的情况会有差异。所以如果你听到某位数据分析师说他天天在研究什么什么样的高级分析方法或者高深的数据算法，天天在使用R、SPSS、SAS，那么不排除有装X的嫌疑。

Q4、 在你刚刚步入网站数据分析的工作，或者你曾经新到一个公司或者网站从事数据分析师的工作，你是如何着手开始你的新工作的，你觉得你需要了解哪些东西，会从哪些方面优先开始学习？

　　我的答案：“业务 => 网站或产品 => 数据处理流程 => 指标和报表”，我的基本流程就是这样的，当然这个也不绝对是前后的顺序，可以是同时结合着看的。

数据分析的重点不在于数据而在于分析，分析针对的是业务，所以业务是首要了解的东西，就像一个人做事情，首先要明确的是要做的是什么事情；然后是网站或产品，它是实现业务的媒介，就像是做事情时使用的工作或方法；数据的处理流程包括了数据的获取、处理和存储模型，它是记录信息，可以看做是日记，记录了一个人做事情的整个流程；指标和报表就是为了将一个人做事情的整个流程复述出来，把握重点同时又不失关键细节，所以必须要了解指标的统计规则和报表的展现方式，以便更好地突显重点，了解省略的细节，让复述贴近事实。

很明显，当你了解了这个人在做什么事情之后再去阅读这个人在做事情时记录的信息或听取复述要远比你直接通过复述内容或者阅读记录信息来猜测这个人在做什么事情来得高效得多。

主要想罗列一些关于BI的问题。

BI（Business Intelligence，商业智能），先看一下维基百科上面对BI的定义：

Business intelligence (BI) is defined as the ability for an organization to take all its capabilities and convert them into knowledge.

BI提供大量有价值的信息引导企业寻找新的发展机遇，当企业认识到潜在的机遇并成功地实施相应战略决策的时候，BI就能帮助企业在市场建立竞争优势并维持企业持续地发展。BI时常跟决策支持系统（Decision Support System, DSS）联系在一起，其实BI最主要的目标就是实现对企业的决策支持。

下面就探讨几个BI方面的问题：

Q1、BI与数据仓库（DW）之间的关系是怎么样的？

　　首先可以明确的是BI的重点在于对数据的应用上，让数据变成有价值的信息，而所有的基础数据基本都是来源于数据仓库。

BI有两个方向的定义：广义的BI是包含数据仓库的，广义的BI包括数据的获取、处理、储存，到之后的分析、挖掘、展现变成有价值信息的整个过程，组成了一套完整的系统，当然在这个系统中数据仓库担当着从数据获取之后的处理和存储的职责，是基础组成部分；狭义的BI仅仅包括上层的数据应用，包括数据的展现、分析、挖掘等，所以不包括数据仓库。

因为BI的定义更侧重于数据应用，而随着数据量的不大扩大，数据仓库更多地被作为一项独立的技术被抽离出来，所以当前BI和数据仓库的定义更倾向于分离，整个系统被叫做“DW/BI”的解决方案。

Q2、BI系统主要是为了帮助企业解决什么样的问题？

　　BI最初的目标就是优化企业的决策支持，实现从数据到有价值的信息的转化，辅助企业商业战略和决策的制定。所以BI的最终目标是获取商业的Insight。

BI首先实现的是企业数据的透明化，原始的数据报表就是为了从数据的角度定量地掌握企业的运营状态，有了数据的支撑，很多决策的制定就会有了参考依据。随着商业和信息技术的不断发展，BI不再仅仅停留在报表的领域，数据除了展现以外被更多地用于商业分析，而商业分析的基础组成就是统计、预测和优化，这些对企业的运营决策起到了更加关键的作用。但随着信息膨胀，数据量的剧增，BI也不断面临挑战，我们需要花更多的成本去处理和存储数据，需要花更多的精力去分析和应用数据。我之前写过BI应用中的三大矛盾这篇文章，因为有段时间了，很多地方的看法可能有了变化，但这3个矛盾相信依然还是存在。

所以，最终还是要把握BI的输出是有价值的信息，无论中间的处理方式是查询、报表，还是分析、挖掘，最终要得出的是有价值的结论。

Q3、目前BI的应用或组件主要有哪些？

这里简单地归纳了一下，可能会有遗漏，希望大家能够在评论中补充。这里仅仅包括狭义BI中基于数据应用层面的一些功能，数据仓库的数据处理方面的应用不在这里罗列。

首先是报表、图表和Dashboard，目前的报表和图表除了更加丰富以外，跟传统报表还有一个关键的区别就是可交互性。目前的报表基本都提供简单的数据筛选、排序等功能，Dashboard的出现实现了按需整合报表和图表的功能。

再则是OLAP，OLAP一度被当做BI的核心功能，不得不承认OLAP是分析数据最有效的手段，尤其是基于多个维度多个层面的分析，这些是一两张报表图表所无法做到的。OLAP一般都是基于已经设计成型的多维模型以及存放多维模型的数据集市（Data Mart），数据集市和OLAP跟业务层面有着很多关联，这个使数据集市跟底层的数据仓库有了区分。

然后是数据的查询和分析，有时基于既定的模型的OLAP无法满足分析的需求，所以就有了数据查询的需求，一般直接查询数据仓库的细节数据；BI中的Ad-hoc Query则是对既定多维模型的灵活查询，可以自由组合维度和度量。

最后是报表的发布和数据预警，这都是属于BI平台的推送功能，一般可以通过邮件订阅的形式定期把组合的报表推送给相关的人员，而通过预警的设定，可以监控数据的变化趋势，掌握数据可能出现的异常。

另外BI还有很多新奇的功能，如基于GIS的地图数据、基于Flash实现的动态图表及对数据挖掘功能的集成等。

Q4、BI中的多维数据模型和OLAP的实用价值在哪？

之前有关于多维数据模型和OLAP的介绍，可以参考数据仓库的多维数据模型和数据立方体与OLAP这两篇文章中的内容。

其实多维数据模型和OLAP最主要的是解决了如何有效地观察数据的问题，传统关系模型很难直接对数据进行观察分析，而多维模型为数据观察者提供了清晰的视角，就如平常我们从多个角度看待事物一样，多维模型维度的设计就很好地提供了这些角度的选择。而OLAP的几个操作形式正是体现了“分析”这个词本身的含义，从总体到细节，结合多个维度的交叉分析，让我们具备了对整个数据集进行全景观测的能力。

OLAP最关键的技术除了多维模型设计还有就是预计算（Precomputation），或者叫预聚合，预计算解决了数据快速获取的问题，基于一定的规则或者算法对数据集进行预计算之后，OLAP的操作性能可能得到有效地提升，从而使对大量数据的快速灵活的分析操作成为可能。

Q5、目前市场上主流的BI产品主要有哪些？

市场上主要的商业BI产品包括IBM的Cognos，另外IBM有自己的DB2可以建立数据仓库，在2010年收购SPSS之后，让其在数据分析和数据挖掘的领域也更加具有竞争力、SAP的Business Objects（BO），另外SAP有BW（Business Information Warehouse），作为传统的ERP方案提供商在数据集成方面有独特的优势、Oracle的BI（企业级的叫BIEE，Oracle Business Intelligence Enterprise Edition），Oracle借助其强大的关系型数据库建立数据仓库有独特的优势。这3大商业BI都属于整合型的BI，再加上微软借助Sql Server数据库提供的SSIS、SSAS和SSRS也是属于整合型的BI解决方案。另外也有独立的BI公司，如SAS，传统优势在数据挖掘领域、Micro Strategy的BI解决方案、开源强大的BI系统Pentaho（之前几年还有很多开源的BI系统，但因为BI在技术上有一定的门槛和成本，所以目前很多开源BI 都会包括开源版本和商业版本，Pentaho也不例外），国内也有用友的BQ软件也是属于BI产品。

归纳一下就是目前的BI产品主要以商业产品为主，而且整套的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、数据仓库是否就应该保存聚合数据，细节数据不应该放入数据仓库？

其实这个问题基本已经达成共识，如果是构建企业级的数据仓库，那么对细节数据的集成和存储是必不可少的，但现实中还是存在很多直接从外部数据源计算聚合之后导入数据仓库的实例。如果对数据仓库只是轻量级的应用，仅存放聚合数据也无可厚非，毕竟没人规定数据仓库一定要是怎么样的，最终的目的无非就是满足对数据的支持和需求。

但对于企业的长期发展来看，数据仓库中存放细节数据有两方面的好处：一方面从技术层面，数据仓库存储细节数据可以释放前台数据库的查询压力，同时对于文本类数据和外部文档类数据入库之后管理更加规范，数据仓库保留历史和不可变更的特性可以让信息不被丢失；另一方面就是从数据的使用上，数据仓库让数据的获取和使用更加简便，集成细节数据让大量的文本型数据可查询，可关联，而面向主题的设计让数据的展现和分析更有方向性和目的性，而且细节数据是支持数据分析和数据挖掘应用所必不可少的。所以，如果数据仓库要不断地催生出更大的价值，细节数据的存储是必不可少的。

Q3、你会把数据仓库分为几层，每层的数据作用是什么？

没有标准答案，根据数据仓库中数据的复杂性和对数据使用的需求程度，数据仓库可以有不用的层级划分。

我一般会把数据仓库划成三层：最底层的细节数据，管理策略是优化存储，一般存储导入的原始数据，便于进行向上的统计汇总，因为数据量较大所以需要优化存储；中间层是多维模型，管理策略是优化结构和查询，面向主题的多维模型的设计，需要满足OLAP和数据查询的多样需求，同时保证查询的便捷性，关键在与维表的设计和维度的选择及组合，事实表需要关注存储和索引的优化；最上层是展现数据，管理策略是优化效率，一般会存放每天需要展现的汇总报表，或者根据多维模型拼装的视图，展现层的数据需要以最快的速度展现出来，一般用于BI平台的Dashboard和报表。

Q4、数据仓库搭建中最繁杂的事情是什么，最容易缺失的是哪一块？

一直觉得数据仓库的核心不在于数据集成，当然数据集成是数据仓库实现价值的前提，数据仓库真正的价值体现在数据的有效应用，数据源于业务反作用于业务。而搭建数据仓库的核心在于数据仓库的架构和数据模型的设计，怎么权衡数据的存储和数据获取效率之间的矛盾是数据仓库管理上的难点，这个难点任何数据仓库都会存在，而大数据增大了这种权衡中的难度。而数据的集成和数据质量控制是数据仓库搭建中最繁杂的事情，尤其是数据清洗的过程，我之前也写过几篇数据质量控制的文章，但现实中这个过程还要复杂得多，而且为了上层数据产出的准确性和有效性，这项工作又不得不做，而且要做得尽量细致。

搭建数据仓库中最容易缺失的就是对元数据的管理，很少有数据仓库团队具备完整的元数据，当然搭建数据仓库的工程师本身就是活的元数据，但无论是为了用数据的人还是数据仓库自身的团队着想，元数据都不可或缺。一方面元数据为数据需求方提供了完整的数据仓库使用文档，帮助他们能自主地快速获取数据，另一方面数据仓库团队成员可以从日常的数据解释中解脱出来，无论是对后期的不断迭代更新和维护还是培训新的员工，都非常有好处，元数据可以让数据仓库的应用和维护更加高效。

写在最后：以上仅代表个人观点，欢迎大家踊跃拍砖，更加希望高手们能在评论中给出宝贵的答案，任何角度的观点和讨论都可以，集思广益。