用心去做

摘要： 这几天，我计算了几个领域的PageRank，包括投资人，程序员这种大的垂直领域，也包括“机器学习”“数据挖掘”等这样的小的领域。在挖掘的过程中，也遇到很多有意思的事情。不过，做这个，并不是要给谁排座次，只是想尝试挖掘出来一些有意思的东西。下面是我通过“机器学习”“数据挖掘”“信息检索”等关键字找出来的一批人，然后再计算排名得到的结果。后面一列是粉丝数。不过一些新开通微博的牛人：@余凯 @老师木 尚不在其中。我的数据是之前的一个快照。这样的一个排序，和粉丝的数量关系就不太一致了。所以，垂直领域，还是能够做出很有意思的东西的。可以进一步挖掘，到底哪些因素影响了某一排名。张栋_机器学习 48966. 阅读全文

摘要： 这个想法很早就有了，因为我是做搜索引擎背景的，能够深刻的理解PageRank算法在搜索引擎中的重要性，绝对的核心技术之一。不过，这篇博客，并不打算介绍PageRank算法的原理，而是，让我们来看看，这个重要的算法，在新浪微博中的应用。网页与网页之间，通过链接关系传递着重要性。在微博中呢？这个也是成立的。不过在微博中，情况要更复杂一些。所以，我在微博中指出，我并不赞同计算全量的PageRank（即所有人都参与计算）。原因有以下几点：人的主题属性和网页不同。网页往往只有一个主题，而人的主题属性比较多，我们可以将主题属性理解为人的兴趣，一般而言，人的兴趣，会不止一个。人的兴趣会随着时间不断变化，而大 阅读全文

摘要： 我一直在做社交网络的挖掘工作，深感目前的一些技术并不能满足社交挖掘的需要。我并没有用过太多的工具，而且图计算的平台也没有用过，涉及到大规模数据的离线分析，主要是依赖hadoop。不过，这并不妨碍，我从挖掘需求的角度来探讨：社交挖掘到底需要哪些技术基础，需要一些什么样的工具。题目中有一个词：large graph。也有很多人认为是big graph。我之所以改变称谓，主要的原因在我前面的博客中有体现。因为big data中的个体之间，往往具有关系，这个样就组成了一个graph，并且这是个超大的graph。元数据信息要比单纯的big data要高几个量级。所以，为了进一步体现graph之大，我称之 阅读全文

摘要： 这是博客搬家到博客园之后的第一篇文章，也是我最近对微博社交圈子挖掘的一些思考和总结，最近主要的思考和研究，主要针对一下几个问题：层次性重叠性ego network有向社交网络带权社交网络统一解决上面的问题（!）这几个，都是社交圈子挖掘时候我们所面临的问题，在挖掘逐渐深入的过程中，问题会一个一个显现出来。我们就要一个一个解决掉，最后要能够统一在一个方法，一个框架中。我在思考的过程中，也阅读了之前的研究，绝大部分都是针对其中的一个问题，或者两个问题。很少能够解决全部的问题。那我下面尝试分析一下这些问题的产生原因，以及一些可尝试的方法。层次性层次性是一个社会属性，在我们的社交圈子中非常的明显。比如， 阅读全文

摘要： 写这篇文章，有两个原因： 看了李院士的《大数据研究的科学价值》，有些感触。 我自己做了一段时间社交，也有一些想法。 之前也写过复杂网络的东西，但是都非常肤浅，没有真正的理解复杂网络，近期看了一些资料，有了进一步的理解。 李院士的文章，是从科学家的角度，理解大数据的价值。从文章中，我了解到以下几点： 阅读全文

摘要： 这篇文章是stackoverflow的一篇帖子。上面提到了很多有用的数据结构。有的听过了，经常用，有的没有听过，记录下来。Trie树。应用比较多，一个比较cool的trie的应用TRASH-A dynamic LC-trie and hash data structure。Bloom filter。wiki链接删除某一项是不允许的，不过可以实现可计数的counting bloom filter在BigTable，Cassandra中都有使用可以用来快速检查是否拼写错误Rope：rope 数据结构表示不能修改的字符序列，与 Java 的 String非常像。但是 ropes 效率奇高的字符串变换 阅读全文

摘要： 这篇文章，包含了一些技术，包含了一些回忆。今天看了360的有关Cassandra实践的ppt，有一些感想。让我想起了两年前的一些事情，不过那时，我做的不是存储，而主攻的分布式检索。后来一系列变化，我也经历了很多，后来安下心来，做存储优化，优化的对象就是Cassandra，这也有一年多的时间。理论深厚，心得颇丰，可是仍然缺乏一线经验积累。看到360这么大规模的应用Cassandra，我很高兴。尽管，没有一同战斗，但是我很欣慰，很开心。Cassandra终于摆脱阴影，站起来了。Cassandra在360部署有1500台服务器。国内首屈一指了，还有一家部署规模在这一半左右。不过，单个Cassandr 阅读全文

摘要： 最近在看Cassandra的内存管理方式，Cassandra默认采用的老年代GC回收策略是CMS，以及采用了Slab Allocator的内存分配方式。采用了Slab Allocator的内存分配方式，大大缩短了GC的时间，据说有1000倍。很吸引人。所以，我要深入研究一下这部分。这部分的实际驱动并不大，可能研究并不十分深入。下面有关CMS GC的部分大多是翻译自Understanding GC pauses in JVM, Hotspot's CMS collector.此外，还有我之前的一些理解。在以后的博客中，我会对JVM平台的延迟问题进行深入的研究。而且，我相信，这并不是一个陈 阅读全文

摘要： 一个多月没有更新博客了。我在积累，频繁更新的话，就没有东西写了-_-。不过还是要定期的总结，以备忘，以分享，以交流，以提高。这篇博客说的问题是Cassandra在memtable flush为sstable的时候，大小是如何计算的，以及flush的阈值是如何确定的。这个过程是动态的，并不是设定某个内存的大小，或者qps多少的时候，进行flush。一方面计算过程可能并不那么直接，另一方面1.1.3版本之前，这里隐藏了比较严重的bug：可能会造成内存溢出（很严重）可能会造成L0层的sstable文件很小（长期来看，也比较严重，严重影响读性能）可能会有以下的日志：WARN[MemoryMeter:1 阅读全文

摘要： 整理自：原文1 和 原文2最近需要做一些简单的测试，发现webbench这个小工具非常好用。 wget http://blog.s135.com/soft/linux/webbench/webbench-1.5.tar.gztar zxvf webbench-1.5.tar.gzcd webbench-1.5make && make install遇到错误解决：/bin/sh: ctags: command not foundapt-get install ctagscc: Command not foundapt-get install gcccannot create re 阅读全文