众所周知的，Hadoop的版本差异比较大，因此首先明确一下我们的环境：运行环境是x86_64 linux CentOS-5.4，Hadoop 0.20.2；开发环境是windows下的Eclipse3.3及相应版本的Hadoop插件。ICTCLAS当然是64位linux版的。

首先我们要保证作为分词器核心的libICTCLAS50.so链接库所依赖的其它库都已经安装了，这件事ldd一下就可以知道了。在我们的系统中缺少libstdc++.so.5，按照一种流行的做法使用ln命令将libstdc++.so.6起个别名并没有解决这个问题，因此最终还是安装了一个带有这个版本的包。

接下来我们仿照前人的做法，将libICTCLAS50.so做了一个归档文件ictclas.tar，并将它传到HDFS上，路径比如说是/user/ictclas.tar。

在Eclipse下建立Map-Reduce工程（当然，这个是安了Hadoop插件之后才会有的），将ICTCLAS的相关内容拷贝进来：将代码包ICTCLAS放入src，其余保持原有目录结构直接放到工程里来（包括曾经被打包的libICTCLAS50.so）。所谓代码部分其实只有分词器的JNI Wrapper，为了适应我们的工程需要，我们编写了一个适配器将其二次包装为我们需要的接口IctclasI3sWrapper.java。可想而知的是，该类提供了一个分词接口对外提供服务，并在内部实例化ICTCLAS50对象，并依赖其完成分词任务。当然，怎么用它并不是重点。

我们对hadoop经典的词频统计代码稍加改动，在Mapper中加入分词。并试着将测试代码Run on hadoop，但是系统提示找不到ICTCLAS50库。于是我们按照之前引用文献中所说的采用了DistributedCache，将归档的动态链接库分发给具体执行任务的机器。代码如下所示：

TokenizerMapper.java：Mapper实现类

public class TokenizerMapper extends Mapper<Object, Text, Text, IntWritable> {

    private final static IntWritable one = new IntWritable(1);

    private WordBreaker wbreaker = new IctclasI3sWrapper();

    protected void setup(Context context) throws IOException,
            InterruptedException {
        super.setup(context);
        wbreaker.initialize();
    }

    protected void cleanup(Context context) throws IOException,
            InterruptedException {
        wbreaker.destory();
        super.cleanup(context);
    }

    public void map(Object key, Text value, Context context)
            throws IOException, InterruptedException {

         String temp = value.toString();
       
         LinkedList<Token> tokens = new LinkedList<Token>();
         wbreaker.process(temp, tokens);
       
         for (Token t : tokens) {
             context.write(new Text(t.getWord()), one);
         }
    }
}

ChineseWordCount.java：Map-Reduce驱动

public class ChineseWordCount {

  public static void main(String[] args) throws Exception {
     
      Configuration conf = new Configuration();
     
      DistributedCache.createSymlink(conf);
      DistributedCache.addCacheArchive(new URI("/user/ictclas.tar"), conf);
     
      Job job = new Job(conf, "ChineseWordCount");
     
      job.setMapperClass(TokenizerMapper.class);
      job.setCombinerClass(IntSumReducer.class);
      job.setReducerClass(IntSumReducer.class);
     
      job.setOutputKeyClass(Text.class);
      job.setOutputValueClass(IntWritable.class);
     
      FileInputFormat.addInputPath(job, new Path("/user/input"));
      FileOutputFormat.setOutputPath(job, new Path("/user/output"));
           
      System.exit(job.waitForCompletion(true) ? 0 : 1);
  }
}

当作业被调度到数据节点执行时，在hadoop.tmp.dir的深处会产生如图所示的目录结构。任务配置文件及代码会被分发到job_id文件夹下，而DistributedCache分发的归档文件则会在archive文件夹下。图中info是我们自己代码所在的包，请无视之。

当我们从以下两种简化方案中择其一：1）取消掉DistributedCache，或者2）将libICTCLAS50.so从工程文件夹中移除时并没有得到比上述代码更骨感的可运行代码。

最后，我们并没有理解这样做的具体原因，但这样做确实解决了找不到库的问题。因此写在这里供参考，并请指正。

先前为了搬家，考察了一下几个国内外知名的博客运营商，正如我在微博中写到的那样：Blogger比较适合装B，牛博可以装右粪，博客大巴可以装文青，CSDN可以装GEEK，新浪可以装孙子——于是我犹豫了，因为以上几个需求实在难以取舍。而最后没有选择它们的原因是：我毕竟发不和谐文章比较少，没必要到墙外找，另一方面又不喜欢国内供应商的御事房作风。科学网和CSDN的博客实在太沉闷了，压力好大。而博客大巴，对不起，纯文学的我搞不懂。

而最终选择blog.com的原因有：1.域名显得比较牛；2.虽然好像是位于葡萄牙的国外服务器，但目前还没有被墙的迹象；3.底层是WP，我比较熟悉，再者非常著名，以至于和各种应用的兼容性非常好。比如说可以用Writer，而微软产品之间的兼容性又挺好，比如公式从Word贴到Writer里就会自动转化成图片，这大大降低了发博文的体力成本。

兴趣缺少交集是我的一直以来的问题，这次开博准备做得稍微专业一点。如您所见的，我从以前的文章中选择了一些技术性的保留了下来。以后也希望继续在技术和研究方面展开，而碎碎念和个人兴趣就放在微博上好了。

页面采用简单到不能再简单的整体风格，便于聚焦在内容，白色背景便于贴公式，巨大的字体则使得文章中即使没有什么东西也能将空间填充满。最重要的是，使用免费的托管博客空间，就算N久不发言也不会觉得亏……

1.编写原型系统时最应该注意的是输入输出与核心逻辑的解耦，因为研究用的代码往往要比软件工程中的需求变化得更快，尤其是输入输出，我们可能随时会变换数据集，它们的格式可能差别很大，甚至没有格式，也有可能希望用很多种手段展示处理结果。因此一定要把跟数据直接相关的模块抽象出来，以保证输入输出的变更不会影响核心代码。另一方面，研究用途的代码通常并不重视运行时间，可接受的时间通常很长，因此有些会增加冗余和时间开销的泛化方法也可以适当使用。

2.核心逻辑的泛化切不可操之过急，研究的实验和成果落实在代码上就是修改核心业务逻辑，因此我们很难一上来就知道自己将来会尝试使用哪些方法。从一开始使用的简单方法直接考虑应用哪种设计模式——这种泛化根本就是无稽之谈。应该谨记Occam的剃刀，一切从当前需要出发，简单够用即可，直到第二种需求出现的时候才做最小限度的泛化。若是一上来就构建庞大的体系，自作主张地觉得“这儿需要留个接口”、“那儿需要提一个抽象”什么的，只会作茧自缚。过拟合反而造成泛化能力低下，以后改起代码的时候，重用也重用不了，推倒重练也不对，很是头疼。

3.如果整个处理过程分为多步，一定要保证每个功能模块都可以单独运行，而不依赖于另一个环境，这既是单元测试的需要也是研究的需要。每个功能模块需要的输入可能不同，但是换言之，只要能提供相应格式的输入就能把每个模块单独跑起来，这就要求我们尽量降低模块间传递数据的复杂度，以便于在没有前一个模块支持的情况下，也可以提供本模块需要的数据。在没有下一个模块处理数据的情况下，从本模块的输出也可以清楚地评价这个模块的质量。

其实，这样的假设并不成立，忽略流中元素的顺序并不可取，这里只是胡乱提出来，用来练习一下EM算法。

设序列：

独立同分布于两个指数分布的混合模型，用

作为隐变量，指示每次的观察量是由哪一个指数分布生成的，即：

设Z=0出现的先验概率为p0=p，Z=1的概率则为p1=1-p，那么待求的参数就是：

为了使用EM方法，首先先写出似然函数：

然后进入EM迭代环节。

E Step：

其中

M Step:

接下来就反复迭代去算好了。细节就不多说了，至于效果嘛……假设都站不住脚，就别指望结果好了吧。

假设文档流的时间戳序列为：T=(t0,t1,…,tn)，如何从这之中提取Bursty特征呢？

首先将相邻两篇文档的到达时间相减就会有时间间隔序列：X=(x1,x2,…,xn)

一个直观的想法是，设定一个阈值e>0，时间间隔序列中若干个连续的，且数值小于e的最长子串就是Bursty特征。

而文献提出了另一种做法：将Bursty Stream用无限状态自动机建模，文章中证明了无限状态自动机求解这一问题与用有限状态自动机的等价性（虽然我觉得这个证明并没有什么意义……）。特殊地，当目标仅仅是发现Bursty时可以将模型简化成两状态自动机。

顾名思义，自动机只有两个状态，一个称为low，一个称为high，每个时刻自动机都必定处于其中一个状态下，所处的这个状态会在一个”时间间隔”后放出一篇文档，随后会有一定概率切换到另一个状态，或是保持原状态。时间间隔的长度服从于当时所处状态所限定参数的指数分布f(x)=aExp(-ax)，并且low状态的参数al要小于high状态的参数ah，以保证high状态以更高的频率放出文档。通过观测量反推时，我们希望观测量能尽可能符合当时状态的指数分布特征，所以设定一个当状态s产生间隔x时的开销函数为-Lnf(x)

另一方面，当自动机切换状态时可能会产生一定损耗。我们希望自动机有保持在低频状态的”惰性”，所以指定当自动机从low状态向high状态切换时产生开销c>0。

接下来的工作就是猜测时间间隔序列X中每一个元素是由哪个状态生成的了，这种从观测量反推随机变量的事情自古以来就是MLE的工作。而可观测的生成量，隐藏的状态序列，有限自动机，无疑是HMM的思想，可以用动态规划的方法在状态机中找一条长度为n的并且能产生最小开销的状态序列。

最后得到了一个状态序列P=(p1,p2, …,pn)，这个序列中所有high状态最大子串即为一个bursty结构。

和直观方法做一下对比，发现后者绕了一大圈其实做的事并不多，主要优势是：
1.低频状态懒惰特性
2.将连续的时间间隔映射成有限个状态
3.提供了一种更具可操作性的阈值指定策略

[文献]

Jon Kleinberg等，Bursty and Hierarchical Structure in Streams，DMKD2003

p.s.

Bursty Stream这词乍一看怎么让我想起了高桥留美子的某民工漫啊……

Normalized Discounted Cumulative Gain

一种对搜索引擎或相关程序有效性的度量。

假设：

1. 强相关的文档出现在结果列表越靠前（rank越高）越有用

1. 强相关文档比弱相关文档有用，比不相关文档有用

下面有几个层层递进的概念：

Graded Relevance:

制定的衡量相关度的若干个等级，如：

Highly relevant: 2

Marginally relevant: 1

Irrelevant: 0

一般由人（Human judge）来裁定。下述公式中表示为rel

Cumulative Gain:

不考虑结果集中的序信息，单纯把分级相关度相加。

结果集中第p个结果的CG值为：

改变p之前的任意两结果的位置关系不会影响p的CG值

在上述假设下，DCG较CG为优

Discounted Cumulative Gain

如果一个强相关的文档排名靠后则应该受到惩罚

计算式不唯一，理论上只证明了对数折扣因子的平滑性要求

另一个DCG计算公式更加强调相关性

若分级相关度只在0和1取二值的话，二公式效果相同

Normalized Discounted Cumulative Gain

根据Query的不同，结果列表的长度也不同，所以这一度量考虑了正规化问题

IDCGp（Ideal DCG）是在一个完美的排序下，p所具有的最大DCG值

这样一来无论Query是什么，nDCG都可以得到一个平均值，因此不同的Query之间的效能就可以做比较了。

完美的排序算法会使DCGp和IDCGp相同，从而使nDCGp为1，nDCG的取值在0到1之间

例：

结果列表中的6篇文档D1,D2,D3,D4,D5,D6，判定了他们的相关度是3,2,3,0,1,2，则：

一个理想的排序应该是：3，3，2，2，1，0，所以

文献：

wikipedia: Discounted Cumulative Gain

英文的当然首推wiki：《Type System》

中文的除了wiki《类型系统》之外，还有一篇大综合的文章《动态语言/静态语言和强类型语言/弱类型语言》

人家说得已经够到位了，我就不重复了。不过，就算是这样一篇大综合的文章之中，前后引用的“专家观点”也有些矛盾呢。看来这个分类的定义除了固有的错误观念之外，也有一些暧昧和含糊不清的地方呢。

嘛～不管了，按照我的理解，简单总结一下：

静态语言（statically typed language）：在编译期确定变量类型，IDE有良好的支持

Ada, AS3, C, C++, C#, Eiffel, F#, Go, JADE, Java, Fortran, Haskell, ML, Objective-C, Pascal, Perl (with respect to distinguishing scalars, arrays, hashes and subroutines) and Scala

动态语言（dynamically typed language）：在运行时确定变量类型，IDE往往难以提供友善的辅助

Erlang, Groovy, JavaScript, Lisp, Lua, Objective-C, Perl (with respect to user-defined types but not built-in types), PHP, Prolog, Python, Ruby, Smalltalk and Tcl

强类型（strongly typed language）：变量类型确定后就严格贯彻到最后，除非有显式地或隐式地定义转型方法，否则类型间无法相互混用

弱类型（weakly typed language）：无视变量类型皆可赋值。（个人感觉好像有点像C语言里原始类型的指针void*）

至于类型安全和不安全（Safely and unsafely typed systems）似乎是另一种分类方法，我的理解是：对任意一种操作符f，若f可接收n个操作数，则对n个任意类型且持有任意有定义的值的常量或变量集合A，若f(A)的操作总有定义，并且操作之后得到的值是有定义的，则是类型安全的，否则是不安全的。

Django

近来在做着拍脑袋找灵感的工作，自由地漫步在遐想国度之余，开始寻找一些快速构造原型的方法。想象中，一向只留给我们伟岸身影的数学家们可能只需要一打草稿纸就可以搞定一切，但说起来，咱毕竟是搞计算机的哈，若是不具有将理想具现化的能力，于情于理都是说不过去的。

在kite的引荐下，得知了玩聚网，虽然目标不同，方法不同，但同样还都是文本挖掘方面的同僚，看过人家的实现之后还是很有启发的。不过更引起我关注的是网站下端的Django Project字样，自从结识了Wordpress这么一个神奇的家伙之后，就不由自主地会关注网页的footer，真是帮大忙了！

接下来用膝盖想都知道了：Django就是开发这个网站的框架啦。

那么这个框架究竟是何方神器呢？不打开潘多拉的盒子永远都不会知道的，而打开注定要面临灾厄……

Python，一种从没接触过的神秘语言。远古的传说中流传着它是一种弱类型语言的说法，而对于常年被强类型束缚大脑的coder来说，简直是一场噩梦！还好咱对编程还是有足够的信心的，鼓起勇气，硬起头皮看tutorial。一步一步跟着做。

“接下来就是见证奇迹的时刻。”一位知名小品演员的话语突然响彻耳畔。教程还没翻过第二页，咱就为这宝具的力量所折服：优美的MVC架构，模型与数据库的同步，URL管理机制，模板语言，还有完全不用操心的后台界面……

…Take a few minutes to marvel at all the code you didn’t have to write….

好了，花几分钟来惊叹一下这些你从未写过的代码吧！

喂喂，你这毫不自谦的教程能不能给我空一行吐槽的空间呀？哈！

之前我没说过要做产品介绍，对吧？所以索性不细说了，详情见链接。

这是一个初次踏入这一领域的外行人对前人鬼斧神工的赞叹和膜拜！

刚入口时，激烈的味道瞬间掀起一阵波澜——那来自一种从没吃过的香料，惊讶之余一股浓香淹没了意识。清醒过来后仔细咀嚼，又是一番别样滋味。令人感到如此清新和愉快。

理性的小恶魔在另一只耳畔说着，其实这不算什么，不过是些小聪明小把戏罢了。这东西的确算不上什么伟大的创造，就算是在相同领域中也未必是最好的，但是正如盛宴上首先呈上的一份开胃菜，不断刺激着本已消化不良的胃。

而在我所不知道的地方，究竟还有多少这般令人兴奋的东西存在呢？

Wake up every day with a feeling of passion for the different technology will make in people’s Life. By Microsoft

http://www.djangoproject.com/

开源中国社区

啄木鸟社区

不过这点问题好解决，用这个题目再到google里找一圈去。于是乎，Ok，找到了琳琅满目的真相。
点了几个链接，基本上全是转载。也是呢，google的搜索结果是按PR值排名的，完全没有原创性的保证。（什么？让我去问度娘？这么无耻的话也说得出口！？）

这我就不怪google了，可是你们这帮转载的人不知道给个原文链接吗？有的还荒唐地注上了“原文出处不详”——你以为是武林传说吗？不详你不会去找吗？

更有甚者，完全不做标记，如果不是你发表时间忒靠后，我还真把你当原创了呢！转载不写引用者，贼人也。鄙视你(ーー)

再去google找，加上关键词“-转载”，依然没有找到原文。好在碰上了一位48岁的程序员博客（前面那句话好像略有语病，嘛……）给了一个醒目而给力的链接，真是感谢！一下就跳到了百度空间上，找到了正主，仔细看看，人家原文不是叫这个名字，而且是一个系列文章中的其中一篇。

问我怎么知道这个是正主？是啊……我也确定不了，只不过看了文章前面的一段引言，加上系列文章，和相似的文风，再考虑到发表时间比较早，严格来讲是原创的概率非常大。由于超过了脑子里的一个固有阈值，所以认为他是原创，这个解释还算合理吧？

一直对字符的各种编码方式懵懵懂懂，什么ANSI UNICODE UTF-8 GB2312 GBK DBCS UCS……是不是看的很晕，假如您细细的阅读本文你一定可以清晰的理解他们。Let’s go!

对写此文章的这位作者表示感谢。

最后，我们的搜索技术除了用pr值这种方法之外，能否在原创性上也加以考虑呢？尽管这相对困难些，但对那些在偏僻的小角落里精心写着精彩文章的博主是一种极大的尊重和肯定啊！

首先我们看到的是一个酷似微博的主页面，但请注意，它不是微博。当然，里面也有一些我们似曾相识的组件：比如有一个只允许输入140个字的奇怪文本框，一个怪蜀黍的个人资料和大头像，还有一个不请自来非要follow你，又非要你follow的小姑娘。

这就是与其他微博不同的地方啦：奇怪文本框的下面有一个插入图片的按钮——而不是“一排”七七八八的插入按钮。以及小姑娘头像下方有一个令人垂涎欲滴的“换”字，不知南京某教授看了之后有何感触。不过据说真相是用户交换手机号，真不错，难怪有专家称可以把百度建设成“世纪佳缘”。

接下来就是强势的“SB广场”页面，里面陈列着各式各样的SB。还有我这个SB在看着他们。

最后，来看看我们最关心的实名认证系统。

注册的时候首先要输入手机号以获取验证码——确保用户有支付一台手机开销的财力。
输入中文姓名——确保用户认得中文。
然后要上传一个头像——确保用户的长相不会吓跑各位相亲的来宾。
最后要输入身份证到哪个威武的平台上去认证——确保用户已经到了适婚年龄。

瞧，做足了婚恋网的准备。

笔者本来想给古板而又可爱的理查德中校征友的，不过好心的系统提示我们说，如果不用真实照片就不能发图片。哦，NO，不能上PP还怎么征友？于是笔者遐想到：莫非是后台有个什么人脸识别系统，对我们二次元的中校不满意？于是改传一个三次元蒙面大叔的照片。

果然一上来大叔受到了亲睐的，系统不再提示照片问题，而是改提示姓名与身份证不符。我勒个去，它还真去公安部验证去啦？……不过好景不长，过了一会儿，蒙面大叔也被抛弃了。莫非系统不是个大叔控，而是萝莉控吗？还是说，其实后台有个家伙在做人脸审核呢？真不禁对他的工作强度表示担心，是不是符合劳动法的呀？对了，淫淫网好像也有头像审核队伍，哎，想看美女图片的人真多。

好了，上面便是笔者看到的全部了，真是“简约而不简单”，简约到吐血，当然我们有理由相信它的血肉会慢慢丰富——反正又没啥难度。接下来说说实质问题吧，看官请轻戳翻页……

在下一页中专家将为SB辟谣。

【插广告】

在这个新的章节里，我们来说说这个说吧怎样推向市场吧？

这还用说吗？世纪佳缘嘛。

可百度说：我们的目标是“实名社交平台”——诶？什么嘛，不是婚恋网啊……真失望。

言归正传，所谓实名社区到底会有多少人来参与呢？这里给几个写得很给力的外链供参考。（排名不分先后）

百度说吧，说个毛啊！<< ZFreet . CHeung

东拉西扯：说说百度说吧 << 对牛乱弹琴

说说百度说吧 如何死掉 << 苏湘迅观察

前因后果略过了，单说百度是不是傻呀？不想有用户了吗？百度说吧真的是百度SB的近亲吗？

我想，不是的。
如果想理解别人的意图，首先就一定要坚信：那人不是SB。
百度不是一个菜鸟，他岂能不知实名制将会给自己的市场带来多大的冲击？
我们应该看到，这是一个信号。

有足够的证据表明，微博是当今社会中非官方信息传播速度最快的媒体，没有之一。
回想一下前些时候，所有微博又重新挂上“测试版”招牌的事吧。他们在做什么呢？
他们在等待相关规定的出台，等着主人把项圈套在自己的脖子上，生怕自己做了出头鸟，重蹈了谷歌的覆辙。
另一方面，一如既往保持神秘的相关部门却迟迟不见动静，它们去干什么了呢？
忙着洗脚还是忙着采购中秋月饼为国庆61周年献礼？
而百度这时候出击了，它提出了一种方案——实名制。
我们应该佩服百度，在最恰当的时机插入到了这片看起来已经成熟，其实却尚未开发的土地。
SB实名制的背后是期望着有人站出来买单，如果成功则一本万利，如果没人买单，以现在这“简约”的投入也损失不了什么东西。
成功的收入主要是官方形象，本来在国外上市，老外股东，充分受到不信任的情况下，现在借助微博实名制又被饲主正眼看待了。
这难道不是聪明之举吗？

由于不恰当的发言将会直接锁定到个人，因此绝不会有人擅自做出愚蠢的举动。
——博弈——万马齐喑？
如果能够达到这个效果，我想相关部门一定很满意。
除此之外，谁来再提个方案吧？新浪，腾讯，你们都来说说看？说一个能让我们神秘的相关部门满意的方案？！

最后，让我们YY一下如果实名制得到了认可会发生什么事吧～
=>CCAV新闻联播焦点访谈披露某某微博散布色情小段子，影响青少年身心健康。
=>采访青少年代表：“有一天我打开了个微博，很黄很暴力，我马上就给关上了。”
=>家长代表强烈要求相关部门对微博进行管控。
=>相关部门以迅雷不及掩耳盗铃之势做出响应，出台管理规定：所有微博必须实行实名制，在得到运营许可证之后才可正式上线，否则视为非法运营。
=>已经拥有大批用户的新浪腾讯早就闻到了气味，第二天就把偷偷准备就绪的认证系统上线，随即损失了一批用户。
分支1=>广大有志青年分分学习bypass技术，纷纷上推表示不满。
=>防火长城频繁升级，加强围追堵截。进一步刺激翻墙技术的开发。
=>我国成为网络技术大国，网络科技创新数量猛飙。
分支2=>一直在百度说吧里谈情说爱的男男女女成为国内微博的主要用户。
=>和谐社会的建立。

如此居功至伟，您还觉得百度说吧和百度SB有关系吗？