背景：一直以来有不少朋友来信或留言，询问网站分析WA（web analysis）与互联网数据分析挖掘的区别。这个问题看上去的确比较纠缠不清，不是因为字面理解，而是因为在当前的互联网行业的具体实践。今天是周末，我百无聊赖之际试图针对该问题做个肤浅的一孔之见，一方面希望能抛砖引玉，接受大家的批评指正；另一方面也算是对这个周末光阴有个交代，我在这个世界混吃混喝，总是要奉献点什么的吧。
虽然从字面理解，网站分析WA应该被包容在互联网数据分析挖掘的大范畴里面，但是实际情况却是当前“网站分析WA”已经成了一个非常独立的明确定义的专业名称和专业领域，从而事实上已经与当前的“互联网数据分析挖掘”有了一个明确清晰的界限，所以关注互联网，关注互联网的数据分析应用的人，对于“网站分析WA”和“互联网数据分析挖掘”都应该了解并清楚知道两者在实践应用上的主要区别。
关于“网站分析WA”的具体详细的介绍和应用场景，大家可以去www.chinawebanalytics.cn, 这是一个私人的博客（网站），但是在当今中国互联网行业实际上起的作用是一个“网站分析WA”门户网站（知识库）的角色，这个作者（博主、站长）就是宋星。从一定程度上说，宋星就是目前中国网站分析WA的代名词。呵呵，所谓时势造英雄，今日稳坐中国网站分析WA江湖头把交椅的宋头领，大约应该感恩这个伟大的互联网时代，感谢命运感谢生活！！！
从我个人的肤浅理解上看，目前的“网站分析WA”核心就是关注分析网站的“趋势、转化与细分”，实现这些核心的手段就是如何科学有效地布点（只有有效打点，才可以全面记录详细数据），结合目前成熟的一系列分析工具，“网站分析WA”可以进行访客分析（新老客户分析，不同分层分析，等等）、页面分析、转化及结构分析、流量来源分析，等等。个人认为，宋星对于当今国内网站分析WA最大的价值和贡献在于他系统化整理、定义了一批该领域的专业名称、体系化的分析指标、该领域的系统化的分析思想和思路（实际上起到了类似的行业标准起草者的角色）。
但是，如果我们一定要从“网站分析WA”中发现它与目前“互联网数据分析挖掘”的区别的话，我个人觉得区别体现在以下几个方面（我是个井底之蛙，冒昧做个肤浅小结，期待各位指正）：
第一：从分析的焦距来看，“网站分析WA”主要关注分析的是网站的宏观表现，而“互联网数据分析挖掘”既可以分析网站的宏观表现，也可以分析微观表现（细化到具体的某个用户member_id，比如可以预测任何个体的流失率，任何个体的交叉销售可能性，等等）；
第二，从分析的技术算法看，“互联网数据分析挖掘”囊括了目前所有的数据挖掘算法技术，但是“网站分析WA”似乎很少涉猎挖掘算法，（而更关注对于流量的监控，如何有效监控，如何有效定义指标）；
第三，从应用场景来看，“网站分析WA”对于起步阶段的中小型网站，中小型B2C, C2C的应用可以有效提升运营效率，并且对于互联网行业的数据分析师来说都是非常好的入门基础和分析思路借鉴、分析框架参考；而对于大型的互联网行业，大型的或者比较成熟的B2C, C2C网站而言，“网站分析WA”作为分析思路的价值远远高于其作为具体分析手段的价值，在这些大型或者比较成熟的互联网企业里，“互联网数据分析挖掘”可能更加容易满足其多样性复杂性的业务分析需求；
第四，从使用的人群来看，“网站分析WA”固然应该被数据分析专业人员掌握，但是其同样也适合来武装互联网行业里的运营人员，运营团队等相关业务团队；而“互联网数据分析挖掘”更多的是用来武装专职的数据分析人员和分析团队的。我目前打工的东家是中国互联网行业的一家旗舰公司，也是一个著名的行业平台，我注意到我的业务需求方（运营部门）在日常运营工作中他们自觉不自觉用到的就是“网站分析WA”里所重点关注的诸如流量来源分析，页面结构优化，流量转化漏斗，等等；
说了这么多废话，语无伦次，颠三倒四，也不知道是否表达清楚，更不知道看官是否明白。其实，但凡文字总结的都是有误导欠准确的，真正的理解和掌握都是无法用文字和语言来总结的，真正的理解和掌握只能是心有灵犀的会心一笑。遥想当年灵山法会，世尊拈花，众皆不识，唯有迦叶破颜微笑，世尊乃曰：“吾有正法眼藏，涅槃妙心，实相无相，付诸于汝。”此乃教外别传、不立文字、直承当下之无上法门，后人笼统目之为“禅”。
本文来自: 人大经济论坛 数据挖掘 版，详细出处参考： http://bbs.pinggu.org/forum.php?mod=viewthread&tid=1440861&page=1

VV，为video view的简写，即中文意思为视频播放次数，为当前衡量视频网效果如何的参数之一。例如：风行、暴风影音、优酷、土豆、奇艺网等视频网站均涉及视频播放次数的问题。
　　UV是unique visitor的简写，是指独立用户/独立访客。指访问某个站点或点击某条新闻的不同IP地址的人数，在同一天的00:00-24:00内，UV只记录第一次进入网站的具有独立IP的访问者，在同一天内再次访问该网站则不计数。独立IP访问者提供了一定时间内不同观众数量的统计指标，而没有反应出网站的全面活动。
　　00:00-24:00内相同的客户端只被计算一次。
　　PV（访问量）：即Page View, 即页面浏览量或点击量，用户每次刷新即被计算一次。
　　IP（独立IP）：指独立IP数。00:00-24:00内相同IP地址只被计算一次。
　　雅虎统计指数（YSR）：通过来源带来的PV、UV、IP，以及用户停留时间、访问情况、用户行为等因素综合分析按不同权重计算得到的，评判来源质量的指数，指数越高，表明来源质量越高。
　　现在大多数的统计工具只统计到IP和PV的层面上，因为在大多情况下IP与UV数相差不大。但由于校园网络、企业机关等一些部门的特殊性，IP已经很难真实的反映网站的实际情况，所以引入了更加精确的UV这个概念。
　　所有UV与IP对于是使用真实IP上网的用户，数值是相同的。
　　但是如果访问你的站点中有通过“网络地址转换”（NAT）上网的用户，那么这两个值就不同的。所以对于国内站长来说，这个UV值还是很有意义的。
　　IP是一个反映网络虚拟地址对象的概念，UV是一个反映实际使用者的概念，每个UV相对于每个IP，更加准确地对应一个实际的浏览者。使用UV作为统计量，可以更加准确的了解单位时间内实际上有多少个访问者来到了相应的页面。

　　On-Line Transaction Processing联机事务处理系统(OLTP)
　　也称为面向交易的处理系统，其基本特征是顾客的原始数据可以立即传送到计算中心进行处理，并在很短的时间内给出处理结果。这样做的最大优点是可以即时地处理输入的数据，及时地回答。也称为实时系统(Real time System)。衡量联机事务处理系统的一个重要性能指标是系统性能，具体体现为实时响应时间(Response Time)，即用户在终端上送入数据之后，到计算机对这个请求给出答复所需要的时间。OLTP是由数据库引擎负责完成的。
　　OLTP 数据库旨在使事务应用程序仅写入所需的数据，以便尽快处理单个事务。

flume
　　Flume是Cloudera提供的一个高可用的，高可靠的，分布式的海量日志采集、聚合和传输的系统，Flume支持在日志系统中定制各类数据发送方，用于收集数据；同时，Flume提供对数据进行简单处理，并写到各种数据接受方（可定制）的能力。

ETL，Extraction-Transformation-Loading的缩写，中文名称为数据提取、转换和加载。
ETL负责将分布的、异构数据源中的数据如关系数据、平面数据文件等抽取到临时中间层后进行清洗、转换、集成，最后加载到数据仓库或数据集市中，成为联机分析处理、数据挖掘的基础。
　　ETL一词较常出现在数据仓库，但其对象并不局限于数据仓库。
　　ETL是数据仓库中的非常重要的一环。它是承前启后的必要的一步。相对于关系数据库，数据仓库技术没有严格的数学理论基础，它更面向实际工程应用。所以从工程应用的角度来考虑，按着物理数据模型的要求加载数据并对数据进行一些系列处理，处理过程与经验直接相关，同时这部分的工作直接关系数据仓库中数据的质量，从而影响到联机分析处理和数据挖掘的结果的质量。
　　数据仓库是一个独立的数据环境，需要通过抽取过程将数据从联机事务处理环境、外部数据源和脱机的数据存储介质导入到数据仓库中；在技术上，ETL主要涉及到关联、转换、增量、调度和监控等几个方面；数据仓库系统中数据不要求与联机事务处理系统中数据实时同步，所以ETL可以定时进行。但多个ETL的操作时间、顺序和成败对数据仓库中信息的有效性至关重要。

一位互联网上市公司高管出身的创业者曾向南都记者这样自我剖析：“我们这类人创业，最大的问题在于，我们更擅长把一件事从1做到10，却不知道如何从0做到1.”而在已经过去的2011年里，这并不是一个个别现象。
2011年，是国内移动互联网疾速发展的一年，也是整个互联网世界疆土大拓的一年———它不仅指向由于智能手机的进一步普及而衍生出的一个被寄希望 “10倍于传统互联网”的移动网络世界，也包括了向更多传统行业如医疗健康、金融理财等进行更深层次的渗透，孕育出无数新的奇思妙想和商业模式。
同时，作为附带的衍生品之一，在过去一年里，我们也“遭遇”到了许多闻所未闻的新鲜词汇：LBS签到、轻博客、弹性社交、O2O……如果我们只是为了学 习这些概念，而去寻找与之对应的海外代表案例以及它们的故事与成绩，这本无可厚非，但如果将其作为选择创业方向的方法，则极有可能陷入本文开头所说的这种 “无根”状态中。
是的，这并非大公司高管出身的创业者才有的通病。我们称其为“概念式生存”。
真正的用户不会因为你是中国版的“×××”或是贴上了“LBS”、“O2O”这样的热门标签而使用你的产品。这句话直指“概念式生存”的要害。
诚然，这种将自己类比为某个海外热门公司的“中国版”或是为自己贴上几个热门标签的做法，的确能在投资方所限定的短短几分钟内将自身的模式表述得较为清 楚，但一来，即便是在盈利模式的形成普遍滞后的互联网创业领域，引入风险投资也并不是创业公司唯一的头等大事；二来，在实际创业的过程中，如果目光只聚焦 于某一个海外标杆或热门概念，则更容易因为忽略了本土用户的真实需求而招致“水土不服”。
在2011年里，我们看到过、也采访过很多聚集在一些热门概念下的海外标杆之中国版公司。尽管它们中大多数都能比照着某一个或几个海外标杆，将自己的商业模式解释得逻辑通顺，但在它们身上，我们却看不到任何属于他们自己的性格或基因。
真正的互联网创业，远不只是“一个产品经理+一个程序员在一间出租房内coding（写代码）“这么简单，它更需要创业者出没在城乡接合部周围的网吧 里，观察属于你的那群目标用户的真实习惯，抑或是在数九寒冬的深夜，驻守在已经没有了机场大巴、公共交通工具的机场、火车站附近，与旅客攀谈，了解他们当 下的心情与需求变化，并将这种最一手的市场资料融入自身商业模式的打造之中。
在即将展开的2012年里，外部经济环境的不明朗可能导致很多互联网、移动互联网创业企业举步维艰。也正是在这时，对“概念式生存”本身的反思才显得尤为重要。
我们并不反对“模仿”和借鉴，因为在消费者需求深度挖掘领域，海外创业者的确有着更为敏锐的触觉。但在模仿一种界面风格、色彩选择，甚至是一个按钮设计 的背后，它可能引发的用户心理或需求，又如何通过与线上线下信息或资源的整合来满足这种需求，却是需要创业者自己去完成的“隐形”功课。

1，针对面向对象的设计与分析：为了让软件有更好的可维护性，重用性以及快速开发，简短的OOAD与它的SOLID原则对于每一个软件工程师来说都是该牢记的。
2，软件品质因素：软件工程的好坏与软件的品质因素是绝对关联的。请在开发过程中深刻的理解这一点。
3，数据结构与算法：深刻理解像数组，列表，栈，树，图，集合等这样的基本数据结构，并在软件开发过程的关键部分使用好的算法。这样整个软件逻辑就会很清晰了。
4，Big-O符号来标记算法复杂度：在开发过程中，请务必使用 Big-O 符号来比较两个代码段或者不同算法所消耗的时间复杂度，这在开发高性能软件项目中是非常重要的。
5，UML图：UML图已经是一个通用的软件设计与分析的语言。如果你们在开发软件的过程中还没有做UML图，那么给人的感觉就是这压根就不是软件工程。
6，正确的衡量软件开发进度。
7，设计模式：设计模式是前人在解决各种各样问题的过程中总结出来的一套标准对策，在绝大部分情况下，使用这些模式肯定是利大于弊的。如果你不想在开发过程中重新造轮子，那么就直接使用它吧。
8，理解操作系统的基本原理：因为所有的应用程序都是直接运行在操作系统这个层级的，学习操作系统的基本原理能让我们对应用程序的底层以及性能有更好的把握。
9，学习计算机组成原理：几乎所有的应用程序甚至是OS都需要与物理硬件打交道的，所以学习计算机组成原理与理解操作系统原理一样都可以让你对于应用程序有更深刻的理解。
10，网络基础：网络与计算机组成，操作系统以及传输流程都是紧密关联的，理解网络基础能让你在开发过程中得心应手。
11，需求分析：对于软件工程来说，需求分析是项目的起点，也是整个项目最最重要的部分。如果这玩意你搞错了，整个项目的方向也就错了。
12，软件测试：在软件工程中，测试也是非常重要的。单元测试，黑盒测试，白盒测试，TDD，集成测试等等都是我们必须知道的。
13，独立管理：主要是说类库(JAR,DLL等等)的管理，熟悉使用一些类似Maven,Ant,lvy这样的知名工具对于大型项目的类库管理是非常有用的。
14，持续化集成：持续化集成能让测试大型模块与组件更加简单与自动化，关于这一点，你可以去了解 Hudson 这个工具。
15，ORM：了解Hibernate这种将对象与数据库表映射工具是非常有好处的，它可以减少你的代码量并节省你的代码维护时间。
16，DI(独立注入)：DI或者IoC(Inversion of Control)的具体实现框架Spring能让你创建对象时更加轻松，对于大型企业级项目更是如此。
17，版本控制系统：VSC工具(SVN,TFS,CVS等)对于团队合作开发以及版本控制都是非常重要的。熟练使用这类工具算得上是必备技能。
18，国际化：通过i18n来将不同语种的字符串存储在其他文件是让软件支持多语种最好的方法。所以i18n在不同的IDE上使用的方法我们应该了解。
19，架构模式：理解类似MVC,MVP,MVVM这样的架构模式非常关键，这能让你写出易维护，简洁以及方便测试的代码。
20，编写干净的代码：你的代码仅仅只是能够正常运行是远远不够的，它必须让编程人员轻易看懂来方便后续维护，所以，代码格式以及编写易读的代码技术都是我们需要了解的关键点。

AJP协议
　　AJP13是定向包协议。因为性能原因，使用二进制格式来传输可读性文本。WEB服务器通过TCP连接和SERVLET容器连接。为了减少进程生成socket的花费，WEB服务器和SERVLET容器之间尝试保持持久性的TCP连接，对多个请求/回复循环重用一个连接。一旦连接分配给一个特定的请求，在请求处理循环结束之前不会在分配。换句话说，在连接上，请求不是多元的。这个是连接两端的编码变得容易，虽然这导致在一时刻会有很多连接。
　　一旦WEB服务器打开了一个到SERVLET容器的连接，连接处于下面的状态：
　　◆ 空闲
　　这个连接上没有处理的请求。
　　◆ 已分派
　　连接正在处理特定的请求。
　　一旦一个连接被分配给一个特定的请求，在连接上发送的基本请求信息是高度压缩的。在这点，SERVLET容器大概准备开始处理请求，当它处理的时候，它能发回下面的信息给WEB服务器：
　　◆ SEND_HEADERS
　　发送一组头到浏览器。
　　◆ SEND_BODY_CHUNK
　　发送一块主体数据到浏览器。
　　◆ GET_BODY_CHUNK
　　从请求获得下一个数据如果还没有全部传输完，如果请求内容的包长度非常大或者长度不确定，这是非常必要的。例如上载文件。注意这和HTTP的块传输没有关联。
　　◆ END_RESPONSE
　　结束请求处理循环。

什么是软件配置管理(SCM)
　　软件配置管理是指通过执行版本控制、变更控制的规程，以及使用合适的配置管理软件，来保证所有配置项的完整性和可跟踪性。配置管理是对工作成果的一种有效保护。 (Software configuration management (SCM, or just plain CM) is an organizational framework — that is, a discipline — for managing the evolution of computer systems throughout all stages of systems development.)
为什么需要配置管理
　　如果没有软件配置管理，最大的麻烦是工作成果无法回溯。为了避免成果被覆盖，包括我自己在内的很多人早期采用手工管理版本的方式，例如当一个新版本产生时用当时的日期来命名文件夹，然后再复制一下以后的修改在复制的文件夹内进行，这样上一个版本就被保存下来了，周而复始不同的版本不会被覆盖。虽然这种方式可以从某种程度上解决版本的回溯问题，但他存在的缺点是显而易见的：第一点如果保留结果过于频繁，将会导致产生大量的有着重复内容的文件夹，庞大的物理空间，管理起来很麻烦；如果保留旧版本的时间间隔太长，可能产生某些有用的老程序无法回溯。第二容易产生版本的混乱，如果是团队开发软件，这种简单的方法更难解决问题的本质了。
人的问题
　　配置管理的方法是成熟的，而且相应的软件工具也是成熟的，基本上不存在看不懂、不会用的问题。配置管理的执行效果如何，完全是事在人为。妨碍配置管理的主要问题是人们嫌麻烦和侥幸心理作怪。
　　在没出乱子的情况下，执行版本控制看起来有些麻烦。每次修改工作的时候总是要Get Latest Version，接着Check Out，修改完后又要Check In，多做了三步。其实这三步加起来也就十几秒钟，而且不费脑子，根本没有添加多少麻烦，仅仅是个人感觉不爽而以。然而不执行版本控制的话，万一发生工作成果被覆盖或丢失等问题，麻烦就大了。
软件配置管理规范
　　软件研发和管理过程中会产生许许多多的工作成果，例如文档、程序和数据等，他们都应当妥善地保管起来，以便查阅和修改。如果把所有文件一股脑的塞进计算机里，那么使用起来很麻烦。
　　凡是纳入配置管理范畴的工作成果统称为配置项，配置项主要有两大类：一类是属于产品的组成部分，例如需求文档、设计文档、源代码、测试用例等等；另一类是在管理过程中产生的文档，例如各种计划、报告等。
　　每个配置项的主要属性有名称、标识符、文件状态、版本、作者、日期等。配置项及历史纪录反映了软件的演化过程。
　　基线由一组配置项组成，这些配置项构成了一个相对稳定的逻辑实体。基线中的配置项被冻结后，不能再被任何人随意更改。基线通常对应于开发过程中的里程碑。通常将交付该客户的基线称为一个Release，为内部开发用的基线称为一个Build。
　　版本控制的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混乱等现象。配置项的状态有三种：“草稿”、“正式发布”和“正在修改” 。
　　配置项的版本号与配置项的状态紧密相关：
　　（1） 处于“草稿”状态的配置项的版本号格式为：0.YZ
　　（2） 处于“正式发布”状态的配置项的版本号格式为：X.Y。
　　一般只是Y值递增，当Y值到达一定的范围时X值才发生变化。
　　（3） 处于“正在修改”状态的配置项的版本号格式为：X.YZ。
　　一般只增大Z值，当配置项修改完毕，状态重新变成“正式发布”时，将Z值变为0，增加X.Y值。
常用的配置管理软件
　　目前国内常用的配置管理工具大概有SourceSafe、CVS、subversion、git和ClearCase，其中CVS，subversion和git属于开源版本控制系统。
　　SCM（Software Configuration Management，软件配置管理）是一种标识、组织和控制修改的技术。软件配置管理应用于整个软件工程过程。我们知道，在软件建立时变更是不可避免的，而变更加剧了项目中软件开发者之间的混乱。SCM活动的目标就是为了标识变更、控制变更、确保变更正确实现并向其他有关人员报告变更。从某种角度讲，SCM是一种标识、组织和控制修改的技术，目的是使错误降为最小并最有效地提高生产效率。
常用的软件配置管理工具
　　现在常用的软件配置管理工具主要分为三个级别：
　　Rational ClearCase，CA CCC/Havest
　　Merant PVCS
　　Microsoft VSS，CVS

持续集成原则
　　1. 所有的开发人员需要在本地机器上做本地构建，然后再提交的版本控制库中，从而确保他们的变更不会导致持续集成失败。
　　2. 开发人员每天至少向版本控制库中提交一次代码。　
　　3. 开发人员每天至少需要从版本控制库中更新一次代码到本地机器。　
　　4. 需要有专门的集成服务器来执行集成构建,每天要执行多次构建。　
　　5. 每次构建都要100%通过。　
　　6. 每次构建都可以生成可发布的产品。　
　　7. 修复失败的构建是优先级最高的事情。