2012年11月月 发布的文章

持续集成术语解释

Continuous Integration(持续集成):持续集成要求开发人员频繁地提交他们的所完成的工作产品,这个频率通常是至少每天一次,有时候可以多次。每次集成会通过自动化构建(automated build)的方式进行尽量快速地验证,以确保新提交的变化不会造成新的问题。如果在集成的过程中出现异常,则应当快速的反馈给相关的人员。
Build(构建):构建是将源代码放在一起,并验证软件可以作为一个一致的单元运行的过程;验证活动一般包括编译、测试、审查和部署。
Build Tool(构建工具):用于执行构建过程的工具称为构建工具,它通过执行构建脚本实现自动化的编译、测试、审查和部署。Make是所有构建工具之祖,它向我们展示了依赖关系检查和增量式构建,Make可以通过选项用于构建任何语言编写的软件;其他常见的构建工具往往和语言相关,例如Ant:Java、NAnt:.NET、Maven:java、Rake:Rake。
Daily Build / Nightly Build/Weekly Build:每天/每晚/每周 做一次构建。
Daily Run(每日执行):每天都对系统的某一个或几个版本运行自动化的测试。
Build Verification Testing:验证Build是否成功,它是进行后续测试工作的前提。 随着软件功能越来越完整和稳定,BVT会逐步加入一些成熟的自动化测试脚本。
Single BranchTrunkMainline:对于一个产品的源代码测试代码配置数据,在配置库中以单一主干(truck)的方式统一管理。
Release Branch(发布分支):当开发主干中含有某个发布版本所计划的特性时,便可以从主干中拉出一个发布分支用于支持该特定发布版本。一般来说,在发布分支中主要是进行bug修复以及版本发布元数据(例如版本号,构建日期等等)的准备工作,不允许增加新的功能代码。
Hotfix branch(热补丁分支):当已发布或上线的版本出现重大bug需要立即解决的时候,便可以从对应版本的标签创建出一个热补丁分支。热补丁分支和发布分支十分类似,它的目的也是发布一个新的产品版本,尽管是不在计划中的版本发布。使用热补丁分支的主要作用是让在热补丁分支上进行快速的产品bug修复的同时,尽可能减少对其他开发人员的影响。
Feature branch(特性分支)/topic branch(主题分支):特性分支(有时也被称作topic分支)是用于开发某一个特性集而从主干中拉出的分支; 特性分支的重点是,只要特性还在开发,该分支就会一直存在,不过它最终会被合并回主干(将该特性加入到某个计划发布版本中),或者被丢弃(如果试验的结果令人失望)。
Local Build(本地构建):将变更提交到版本控制库之前,在RD开发机上执行的本地构建,目的是尽可能避免因为check in动作而导致主干被破坏。
Build Pipeline (构建管道)/staged build(分阶段构建):构建管道,即多个构建按一定顺序执行。一般先运行轻量级的构建,再运行更大范围、耗时更长的构建,通常是指那些较慢的功能/集成/系统测试。
Version Control System(版本控制系统):提供一个受控的访问库来管理源代码和其他软件资产(如文档)的变更,让开发者以及项目相关人员能够有效管理软件版本。版本控制系统能够让您按时间回溯,取得源代码和其他文件的不同版本。常用的版本控制软件有SVN,CVS,GIT等。
Continuous Integration Server(持续集成服务器):CI Server自动完成软件代码的构建过程。CI服务器可以根据设定的触发机制(代码变更、定时等)自动地去完成构建过程。目前已知的各种CI Server不下几十种,其中比较常见有Hudson、CruiseControl、TeamCity、Pulse、Anthill, Bamboo等。

maven安装

Windows 如何安装 maven
1、安装 java,配置好 java 的环境变量
2、下载 apache-maven-3.0–bin.zip windows 版本(官网上有下载)
3、安装 maven;安装目录假设为:D:binapache-maven-3.0,添加 maven 的环境变量,变
量名为:M2_HOME;值为:
D:binapache-maven-3.0;配置 path 变量,加上%M2_HOME%bin; 最后 mvn -v 命令(CMD
状态下)检测 maven 有没有
配置好。
4、更新:直接解压新版本的 maven 覆盖老的目录,然后更改下原来的环境变量。
—————————————————————–
Linux 如何安装 maven
1、安装好 java,配置好环境变量
2、下载 apache-maven-3.0-bin.tar.gz;tar -xvzf apache-maven-3.0-bin.tar.gz
3、方便升级,建立个平行目录 ln -s apache-maven-3.0 apache-maven
4、配置环境变量,设置 M2_HOME 环境变量指向符号链接 apache-maven 即可;
export M2_HOME=/home/juven/bin/apache-maven
export PATH=$PATH:$M2_HOME/bin
5、mvn –version 检测有没有安装好。
6、升级 Maven
在基于 Unix 的系统上,可以利用符号链接这一工具来简化 Maven 的升级,
不必像在 Windows 上那样,每次升级都必须更新环境变量。
前一小节中我们提到,解压 Maven 安装包到本地之后,平行地创建一个符号
链接,然后在配置环境变量时引用该符号链接,这样做是为了方便升级。现在,
假设我们需要升级到新的 Maven 3.1 版本,同理,将安装包解压到与前一版本平
行的目录下,然后更新符号链接指向 3.1 版的目录便可:
juven@juven-ubuntu:bin$ rm apache-maven
juven@juven-ubuntu:bin$ ln -s apache-maven-3.1/ apache-maven
juven@juven-ubuntu:bin$ ls -l
total 8
lrwxrwxrwx 1 juven juven 17 2009-09-20 16:13 apache-maven ->
apache-maven-3.1 /
drwxr-xr-x 6 juven juven 4096 2009-09-20 15:39
apache-maven-3.0drwxr-xr-x 2 juven juven 4096 2009-09-20 16:09
apache-maven-3.1
同理,可以很方便地切换到 Maven 的任意一个版本。现在升级完成了,可以
运行 mvn -v 进行检查。

K-means

K-means算法是硬聚类算法,是典型的局域原型的目标函数聚类方法的代表,它是数据点到原型的某种距离作为优化的目标函数,利用函数求极值的方法得到迭代运算的调整规则。K-means算法以欧式距离作为相似度测度,它是求对应某一初始聚类中心向量V最有分类,使得评价指标J最小。算法采用误差平方和准则函数作为聚类准则函数。

Apriori算法

  Apriori算法是一种最有影响的挖掘布尔关联规则频繁项集的算法。其核心是基于两阶段频集思想的递推算法。该关联规则在分类上属于单维、单层、布尔关联规则。在这里,所有支持度大于最小支持度的项集称为频繁项集,简称频集。
 
该算法的基本思想是:首先找出所有的频集,这些项集出现的频繁性至少和预定义的最小支持度一样。然后由频集产生强关联规则,这些规则必须满足最小支持度和最小可信度。然后使用第1步找到的频集产生期望的规则,产生只包含集合的项的所有规则,其中每一条规则的右部只有一项,这里采用的是中规则的定义。一旦这些规则被生成,那么只有那些大于用户给定的最小可信度的规则才被留下来。为了生成所有频集,使用了递归的方法。
 (1) L1 = find_frequent_1-itemsets(D);
(2) for (k=2;Lk-1 ≠Φ ;k++) {   
(3) Ck = apriori_gen(Lk-1 ,min_sup);   
(4) for each transaction t ∈ D {//scan D for counts  
 (5) Ct = subset(Ck,t);//get the subsets of t that are candidates  
 (6) for each candidate c ∈ Ct   
(7) c.count++;  
 (8) }   
(9) Lk ={c ∈ Ck|c.count≥min_sup}   
(10) }   
(11) return L= ∪ k Lk;
  可能产生大量的候选集,以及可能需要重复扫描数据库,是Apriori算法的两大缺点。

数据挖掘工作平台 Weka

WEKA的全名是怀卡托智能分析环境(Waikato Environment for Knowledge Analysis),同时weka也是新西兰的一种鸟名,而WEKA的主要开发者来自新西兰。
WEKA作为一个公开的数据挖掘工作平台,集合了大量能承担数据挖掘任务的机器学习算法,包括对数据进行预处理,分类,回归、聚类、关联规则以及在新的交互式界面上的可视化。
如果想自己实现数据挖掘算法的话,可以看一看weka的接口文档。在weka中集成自己的算法甚至借鉴它的方法自己实现可视化工具并不是件很困难的事情。
2005年8月,在第11届ACM SIGKDD国际会议上,怀卡托大学的Weka小组荣获了数据挖掘和知识探索领域的最高服务奖,Weka系统得到了广泛的认可,被誉为数据挖掘和机器学习 历史上的里程碑,是现今最完备的数据挖掘工具之一(已有11年的发展历史)。Weka的每月下载次数已超过万次。

迈出单元测试的第一步

单元测试不仅是软件行业的最佳实践,在敏捷方法的推动下,它也成为了可持续软件生产的支柱。根据最新的年度敏捷调查,70%的参与者会对他们的代码进行单元测试。
单元测试和其他敏捷实践密切相关,所以开始编写测试是组织向敏捷转型的踏脚石。道路漫长,但值得去做。我将在本文介绍符合要求的小技巧,以及在开发周期里进行单元测试的步骤。
有效的单元测试默认要能自动化。没有自动化,生产力就会下降。没有自动化,单元测试的习惯也不会持续太久。依靠手工测试(由测试人员或开发人员完成)并不能持续太长时间;在有压力的情况下,没人会记得去运行所有的测试,或者去覆盖所有的场景。自动化是我们的朋友,所有的单元测试框架都支持自动化,而且集成了其他自动化系统。
单元测试对现代开发来说至关重要
有代码相关的测试,我们就有一个天然的安全保障。我们修改的代码要是带来了什么问题,测试会告诉我们。这个安全保障越健全,我们对代码正常运行的信心就越大,对按需修改代码的能力也就越有信心。
和其他类型的测试相比,单元测试的主要优点是反馈迅速。在几秒钟内运行数百个成套的测试,这对开发流程很有帮助。我们会形成“添加一些代码,添加测试,测试运行通过,前进”的节奏。小步前进、确保一切正常也意味着调试时间会大大减少。测试能提高生产力也就不足为奇了——在Bug上少花时间,把更多的时间用到新功能的推出上。
依赖关系的壁垒
给新建项目添加测试相当容易——毕竟代码不会阻碍测试。不过这种情况绝对不常见。大多数人都是在处理遗留代码,这些代码不太容易测试,有时候甚至运行不起来——它需要的数据或配置可能只存在于生产服务器上。我们或许要为不同的场景创建不同的设置,这也许会花费过多的精力。在很多情况下,我们可能还会为了测试修改代码。这让人无法理解:我们编写测试就是为了能有修改代码的信心,还没有测试又该如何去稳妥地修改代码呢?
代码可测性是语言和工具的功能。大家认为Ruby等动态语言是可测的。对于测试的内部代码,我们可以改变其依赖关系的行为,而不用修改生产代码。C#或Java等静态类型语言则不太容易去测试。
下面有个例子:一个C#的过期检查方法,检查是否超过了特定日期:
public class ExpirationChecker
{
private readonly DateTime expirationDate = new DateTime(2012, 1, 1);
public bool IsExpired()
{
if (DateTime.Now > expirationDate)
{
return true;
}
return false;
}
}

在这个例子里,IsExpired方法的DateTime属性对测试运行时间有强依赖。Now返回的是实际时间。这个方法有两种情况,它会根据日期返回不同的值。修改计算机时间是绝对不行的,因为我们要在任何时候到任何计算机上去测试场景,并且不能带来任何副作用。
要测试到两种情况,一种可能的解决方案是修改代码。比如说,我们可以把代码修改成:
public bool IsExpired(DateTime now)
{
if (now > expirationDate)
{
return true;
}
return false;
}

这样,测试可以注入不同、可控的DateTime值,而不用在生产代码里写定一个值。我们要是不能修改代码,可以利用Typemock Isolator等Mocking框架,模拟静态属性和方法。针对先前的代码,测试可以写成:
[TestMethod]
public void IsExpired_BeforeExpirationDate_ReturnFalse()
{
Isolate.WhenCalled(() => DateTime.Now)
.WillReturn(new DateTime(2000, 1, 1));
ExpirationChecker checker = new ExpirationChecker();
var result = checker.IsExpired();
Assert.IsFalse(result);
}

现有的遗留代码不能轻易修改,因为我们没有针对它的测试。开始测试遗留代码之后,我们就能明白:代码越丑陋,测试越困难。工具可以减轻一些痛苦,但我们要努力去构建安全的环境。
依赖关系并不是唯一的内容……
我们很快会遇到的另一个问题是测试维护:测试和被测试代码耦合在一起。有耦合关系,修改生产代码就有可能破坏测试。要是代码修改引起测试失败,我们就需要回去解决这些问题。很多开发人员害怕维护两个代码库,这种恐惧甚至会让他们干脆不进行单元测试。真正的维护工作既取决于工具,也取决于技巧。
编写好的测试是通过实践获得的技能。编写的测试越多,我们就越精于此,同时会提升测试质量,维护也越来越少。有了测试,我们就有机会重构代码,这反过来又会让测试更简洁、更易读、更健壮。
工具对实践的难易程度有极大的影响。在基础层,我们需要一个测试框架和一个Mocking框架。在.Net领域,两种框架的选择都很丰富。
编写第一个测试的准则
开始的时候,我们通常会试用不同的工具,来理解他们的工作原理。我们往往不会在实际的工作代码上开始编写测试。但很快就要给代码编写真正的测试。有一些小提示届时会有用:
•从哪里开始:一般来说,我们编写测试是针对工作代码的,无论代码是Bug修复还是新功能。对Bug修复来说,编写的测试要检查修复。对功能来说,测试应检查正确的行为。
•支架:以我们掌握的知识来看,明智的做法是先添加能确保当前实现运行的测试。添加新的代码之前先写测试,因为我们希望在修改现有代码之前,能有安全的保障。这些测试被称为“特征测试”,这个术语来自Michael Feathers编写的《修改代码的艺术》。
•命名:测试最重要的属性是它的名字。我们一般不会去看运行通过的测试。但当它失败时,我们看的就是它的名字。所以挑一个好名字,描述出场景和代码的预期结果。好名字还有助于我们定位测试里的Bug。
•评审:为了增加测试成功通过的机会,编写第一个测试时我们应该和同事结对。两个人都能从实践中学习,而且我们还能立即评审测试。最好对所测的内容、测试的名称达成共识,因为这会成为团队其他人员的基本模板。
•AAA:现代测试的结构符合AAA模式——Arrange(测试设置)、Act(调用测试里的代码)、Assert(测试通过的标准)。如果我们使用测试驱动开发(TDD),我们要先编写完整的测试,然后再添加代码。对遗留代码来说,我们可能需要换一种方式。一旦我们有一个场景和名称需要测试,那先编写Act和Assert部分。我们要不停构建Arrange部分,因为对需要准备或仿造的依赖关系,我们知道的要更多一些。然后继续这么做,直到有一个测试能够通过。
•重构:一旦准备好了测试,我们就可以重构代码了。重构和测试都是后天获得的技能。我们不仅要重构被测试代码,也要重构测试本身。但DRY(不要重复自己)原则不适用于测试。测试失败时,我们希望尽快修复问题,所有的测试代码最好在一个地方,而不是分散在不同的文件里。
•可读性:测试应该是可读的,最好是人类可读。和搭档评审测试代码,看他能否理解测试的目的。评审其他测试,看看它们的名称和内容怎样与相邻的测试区分开来。一旦测试失败,就需要修复它们,最好还是在运行失败之前评审它们。
•组织:一旦我们有了更多的测试,组织就有了用武之地。测试可以在很多方面有所不同,但最明显的一个就是如何快速运行。有些测试可能在毫秒内运行完,而有些则需要数秒或好几分钟。和工作一样,我们都希望得到最快的反馈。这就是前面谈到的怎么按一定的节奏去进行。要做到这一点,你应该把测试划分一下,把快的测试和慢的测试分开运行。这能手工(努力)去做,但在.NET领域,Typemock Isolator有一个运行器,能自动按运行速度分离。
总结
迈出单元测试的第一步是很有挑战的。体验依赖的东西很多——语言、工具、现有代码、依赖关系和技能。只要稍稍思考,进行大量训练和实践,你就能渐入测试的佳境。
http://www.infoq.com/cn/articles/First-Steps-Unit-Testing?utm_source=infoq&utm_medium=related_content_link&utm_campaign=relatedContent_articles_clk

数据挖掘:中国互联网未来的十年——专访党书国

门户解决了web0.5时代的信息匮乏;Google解决了web1.0时代的信息泛滥;Fackbook解决了web2.0时代的社交需求;未来是谁的十年?展望web3.0时代,当高效的社交网络趋于信息量爆炸,我们庞大的社交关系也需要一个”Google”来处理,那就是下一个十年,数据挖掘的十年,网络智能的十年。
数据挖掘:互联网阶段性产物
数据挖掘之所以在近几年颇受关注与互联网发展的阶段有关。随着网页的增多,用户量达到一定规模,就产生了大量用户和网页应用交互的行为,这些数据实际上非常有意义。互联网也因此形成了两条主线结构。一种是以信息为对象的,还有一种是以人为对象。但是人与信息之间不是割裂的,而是时时刻刻交织在一起,而且信息是通过人流动的,人也在流动的信息中构建新的关系,这催生了如Facebook这样类型的网站。数据挖掘被频频提及,并不是资本操作的结果,而是随着互联网发展的进一步深化,原本被大家忽略的数据挖掘的价值逐渐凸显,如何使广告投放更加有效,增加广告投放ROI,如何提高网站的转化率以及用户再次购买的能力,这些都需要数据挖掘在背后做支撑,因此这个领域逐渐被大家重视。
国外数据挖掘的发展要成熟许多。基于历史悠久的邮购业务,国外公司具备目录式的用户库,可以进行数据挖掘。随着互联网的出现,又自然而然过度到网络数据挖掘的阶段。但是中国在互联网出现之前,没有相应的用户库基础,大家对它还没有形成清晰明确的认识,专业人才匮乏,大学里也没有开设数据挖掘的专业。
从事数据挖掘的人员,我个人认为要备有一定的统计学、社会调查等方面的基本素质,而且要充满好奇心。获取数据并不困难,关键是要具有能挑出金子的能力。比如像微博,通过用户大量的互动行为,产生人与信息的交流,交织,不断变化着向前推进。我发一条微博,被评论,然后被转发,再次被转发,有时候会产生类似蝴蝶效应的情况。数据挖掘可能帮助企业更好的预测信息,甚至还有人在互联网上通过数据挖掘,得出2012要毁灭的结论。
数据挖掘:从垃圾里捡金子
数据挖掘的前提是数据量足够庞大。这种大数据是非常诱人的,通过分析可以发现许多含金量很高的信息和趋势。
目前获得用户数据的方式大致有两种。一种是通过和电信运营商合作,在路由器上截取全网数据。这种方式能够在最大限度上掌握用户数据,但是这种全样本在操作上存在问题,国外一般采用以抽样小样本数据推向全局的做法。另一种方法是以cookie的方式植入到用户的机器里,通过连续性的跟踪,生成用户行为的信息流,经过对这些信息的分析,将有效的广告推送给用户。这种方法的技术不断提高,从文本到动画,越来越难被用户清除,因此可以更加完整地呈现用户在互联网上的行为。
这两种不同的获取数据的方法并没有优劣之分,抽样数据对于一些现象或者结果的预测并不一定低于全样本数据。获得全样本数据的代价非常大,如果全样本数据没有进行很好的分解,那么就是垃圾数据而已。
在数据分析结果与预期不符合的情况下,首先要看模型是否设计得合理。比如我经常会遇到自身网站的排名和第三方检测的排名很不一样,这其中有很大程度是因为数据筛选过滤以及模型的差异。通过不同的方法获得的数据结果会有不同,算法不同,实现方法也都会导致数据结果的差异性。
针对两种不同的数据获取方式的数据分解,采用cookie的会更加容易。特别是对于像Baidu这类公司,用户的行为基本覆盖了它的网络广告范围,因此更容易形成对用户的连续印象。在这种情况下,如果掌握了全网的用户,就可以对每一个用户的特点进行描绘,从而给用户打上相应的标签。为每一位用户定义自身标签是一个非常重要的过程。用户的行为在不断变化,因此在标签老化后,需要进行定期的更新管理,一般三个月更新一次标签。在贴标签的时候,需要对分类进行细化。我曾经看见过将一组用户命名为“农林牧副渔”的情况,这是非常可笑的,这种标签对于研究消费者毫无意义,不能起到指导营销的作用。
通过获取数据、分解数据以及将数据赋予标签意义的三个步骤,就可以基本上完成数据挖掘的过程。这些经过筛选的“金子”可以应用各种领域。例如广告投放,虽然互联网广告已经比电视广告更加精确,但是仍然存在着高度浪费的情况。实际上很多广告投放仍然是不精确的,因此先要判断用户的类型,才能决定向其推送广告的类型。此外,例如电子商务网站就可以根据不同的用户类型,将网站页面重组,把相应的内容推送给用户,使得电子货架体系随时根据每个人发生变化。数据挖掘不是以单纯的报告形式存在,而是具有非常广泛的市场应用潜力。
数据挖掘行业还未出现领导者
在数据挖掘与市场营销结合方面,我曾经做过一个关于红孩子电子商务网站的案例,但其实很难定义它是否成功。经过研究,我们的结果是:红孩子通过我们做广告投放,每获得一个有效客户的成本是通过其他渠道的好几倍。有趣的是,用户的购买率却非常高,ROI又比其他公司高许多。我认为这是一个好的案例,因为我们的技术只是帮助客户标定一个用户,在众多用户中寻找到目标客户是非常不容易的,这就导致单位用户获取成本非常高,但是将他引到红孩子的电商平台后,重复购买率却非常高。这种情况与中国目前数据挖掘还不成熟有关。虽然很多公司都对外宣称能够通过大量数据挖掘,达到广告精准营销,但是我并不认为在数据挖掘行业有某家公司已经确立了决定的领先地位,但是有很多公司在这方面或者结合云结算等领域已经颇有建树。
数据挖掘的基础在于数据量的大小和质量。例如淘宝、阿里云等所掌握的数据量都是非常巨大,百度和谷歌会更大,电信运营商的数据量更是不可想象,甚至一些网络广告公司也可以截取网民的全部数据。每个公司从不同角度获取数据,本身就使得结果具有很大差异性。其次,数据服务的对象和产品也使得结果有出入。因此很难说在整个数据挖掘的领域,已经有成熟的市场领导者或者佼佼者不能被超越。也许这个看法是错误的,但是我认为中国的数据挖掘发展还不成熟,甚至单单将新浪微博的数据挖掘做好就可以形成一个特别庞大的公司。
越来越多的公司认识到数据的重要性,同时越来越多的资本也促进了行业发展壮大,一些互联网集团都在加强自己的数据研究和应用水平。例如阿里巴巴的云服务系统,其中很重要的就是数据服务,一些专门做网站流量统计的公司都被阿里巴巴收购,后者在不断巩固自己在数据领域的领先地位。淘宝也新近推出了一些针对数据应用的可视化产品。一些小公司也利用微博的开放平台,获取和挖掘数据,开发出很多有趣的应用产品。
在产业链层面,国外数据发掘的产业链,分工非常明晰。但是中国的现状是,大而全,想延伸和覆盖产业链各个环节。但是随着竞争的加剧,以及越来越多公司的加入,整个行业会逐步分化,慢慢形成一个相对成熟的台式。因此,国内数据挖掘要达到相对成熟的发展阶段还需要很长时间和很大努力。

网站分析WA(web analysis)与互联网数据分析挖掘的区别

背景:一直以来有不少朋友来信或留言,询问网站分析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)

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作为统计量,可以更加准确的了解单位时间内实际上有多少个访问者来到了相应的页面。

OLTP-联机事务处理系统

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