Thursday, January 30, 2014

[repost ]The 12 Agile Principles

original:http://ift.tt/1b8LUCP The 12 Agile Principles are a set of guiding concepts that support project teams in implementing agile projects. Use these concepts to implement agile methodologies in your projects. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness [...]



via WordPress http://ift.tt/1kcEzVr

Labels:

Wednesday, January 29, 2014

2014 American Spring Festival Gala

Tuesday, January 28, 2014

[repost ]Pareto’s Principle: The 80/20 Rule

original:http://ift.tt/1mSpFDo There is a universal rule that governs our lives behind the scenes, it resides silently, only observed by those enlightened of its existence. The ones who do recognize its power, spend more of their precious time pursuing their passions, making more money, and living happier lives. They use the principle to accomplish more in [...]



via WordPress http://ift.tt/Mapvvw

Labels:

[repost ]Pareto’s Principle – The 80-20 Rule ——>How the 80/20 rule can help you be more effective

original:http://ift.tt/Vm08oo In 1906, Italian economist Vilfredo Pareto created a mathematical formula to describe the unequal distribution of wealth in his country, observing that twenty percent of the people owned eighty percent of the wealth. In the late 1940s, Dr. Joseph M. Juran inaccurately attributed the 80/20 Rule to Pareto, calling it Pareto’s Principle. While it [...]



via WordPress http://ift.tt/1aFaUnG

Labels:

Thursday, January 23, 2014

[repost ]余弦相似性获取文章相似度的java实现

original:http://ift.tt/1asvnfe 文章相似度的实现可以用余弦相似性实现。余弦定理可参考: 余弦定理 字符串之间的相似度实现:字符串相似度算法(编辑距离)java实现 我们可以把它们想象成空间中的两条线段,都是从原点([0, 0, ...])出发,指向不同的方向。两条线段之间形成一个夹角,如果夹角为0度,意味着方向相同、线段重合;如果夹角为90度,意味着形成直角,方向完全不相似;如果夹角为180度,意味着方向正好相反。因此,我们可以通过夹角的大小,来判断向量的相似程度。夹角越小,就代表越相似。 余弦值越接近1,就表明夹角越接近0度,也就是两个向量越相似,这就叫”余弦相似性”。 阮一峰老师写的一篇博文简单明了,大家可以看看:TF-IDF与余弦相似性的应用(二):找出相似文章 实现该算法思路: 1.先用es-ik进行文章分词。 2.得到两篇文章的词频向量 3.计算两个向量的余弦相似度,值越大就表示越相似。 相关代码实现已经github上。具体地址为:http://ift.tt/1aOmMOw package com.xq.algorithm; import java.util.ArrayList; import java.util.LinkedHashMap; import java.util.List; import java.util.Map; /** * * <p>Title:</p> * <p>Description: 余弦获取文章相似性 * </p> * @createDate:2013-8-26 * @author xq * @version 1.0 */ public class CosineSimilarAlgorithm { /** * * @Title: cosSimilarityByFile * @Description: 获取两个文件相似性 * [...]



via WordPress http://ift.tt/LYoPdj

Labels:

[repost ]字符串相似度和字符串编辑距离

original:http://ift.tt/1aOmLdo 余弦相似度 计算公式为: P(A,B) = sqrt(A × B) / (|A| × |B|) 设有两个字符串: ABCDEFG ABCHIJK 其中共有11个字符,为: A B C D E F G H I J K 如果,不考虑他们之间的关联性以及顺序等隐私,那么可以讲这两个字符串转换成两个11维空间中的向量: {1、1、1、1、1、1、1、0、0、0、0} {1、1、1、0、0、0、0、1、1、1、1} 那,计算他们之间的相似度为: P = sqrt(3) / (sqrt(7) × sqrt(7)) = 0.2474358297 矩阵相似度 给定两个长度相等的字符串,在移动的过程中比较: a b c d d a c b c b a a d [...]



via WordPress http://ift.tt/LYoOWT

Labels:

Sunday, January 19, 2014

[repost ]Spark安装和测试(Standalone 模式)

original:http://ift.tt/1mpJxjT 1:Spark Standalone Mode安装 A:部署文件生成 首先,下载并解压缩Spark的源码,切换到解压缩所生成的目录,运行spark的部署文件生成程序: ./make-distribution.sh –hadoop 2.2.0 –with-yarn –tgz make-distribution.sh可以带3个参数 –tgz: 在根目录下生成 spark-$VERSION-bin.tar.gz –hadoop VERSION: 打包时所用的Hadoop版本号 –with-yarn: 是否支持Hadoop YARN 运行成功后,在根目录下生成spark-0.8.1-incubating-hadoop_2.2.0-bin.tar.gz部署文件,不过该部署文件只带有最基本的Spark运行文件,不包含例程。 B:部署 用生成的spark-0.8.1-incubating-hadoop_2.2.0-bin.tar.gz文件在要安装Spark的机器上部署 [root@hadoop1 app]# tar zxf spark-0.8.1-incubating-hadoop_2.2.0-bin.tar.gz [root@hadoop1 app]# mv spark-0.8.1-incubating spark081_sl [root@hadoop1 app]# cd spark081_sl [root@hadoop1 app]# ls -lsa C:启动Spark [root@hadoop1 spark081_sl]# bin/start-master.sh 启动后,可以通过浏览器浏览8088端口 D:建立Spark集群 规划: 192.168.1.171 hadoop1(master) 192.168.1.172 hadoop2(slave) 192.168.1.173 hadoop3(slave) [...]



via WordPress http://ift.tt/KkXAZc

Labels:

Tuesday, January 14, 2014

[repost ]蛋疼的配置storm

original:http://blog.angryfox.com/?p=2497 wget –no-check-certificate http://download.oracle.com/otn-pub/java/jdk/7u45-b18/jdk-7u45-linux-x64.rpm rpm -i jdk-7u45-linux-x64.rpm ln -s /usr/java/jdk1.7.0_45/bin/javah /usr/bin/javah http://blog.angryfox.com/?p=1420 python 2.7.3 wget http://mirror.bit.edu.cn/apache/zookeeper/zookeeper-3.3.6/zookeeper-3.3.6.tar.gz tar zxvf zookeeper-3.3.6.tar.gz cp -R zookeeper-3.3.6 /usr/local ln -s /usr/local/zookeeper-3.3.6 /usr/local/zookeeper vi /etc/profile (设置ZOOKEEPER_HOME和ZOOKEEPER_HOME/bin) 追加: export ZOOKEEPER_HOME=”/usr/local/zookeeper” export PATH=$PATH:$ZOOKEEPER_HOME/bin cp /usr/local/zookeeper/conf/zoo_sample.cfg /usr/local/zookeeper/conf/zoo.cfg (用zoo_sample.cfg制作$ZOOKEEPER_HOME/conf/zoo.cfg) mkdir /tmp/zookeeper mkdir /var/log/zookeeper yum install gcc g++ make automake uuid-devel libtool wget http://download.zeromq.org/zeromq-2.1.7.tar.gz tar -zxvf [...]



via WordPress http://blog.newitfarmer.com/big_data/streams/storm/13935/repost-%e8%9b%8b%e7%96%bc%e7%9a%84%e9%85%8d%e7%bd%aestorm#utm_source=rss&utm_medium=rss&utm_campaign=repost-%25e8%259b%258b%25e7%2596%25bc%25e7%259a%2584%25e9%2585%258d%25e7%25bd%25aestorm

Labels:

[repost ]Storm Spout : Push vs. Pull

original:http://nsinfra.blogspot.com/2013/06/storm-spout-push-vs-pull.html Since the day one when we started working on Storm, I was mistaken on spouts modus operandi. I believed spouts can both pull and push data from the sources. But when I was about to implement a push styled spout, I stumbled with a few challenges. I wanted to build a thrift base spout [...]



via WordPress http://blog.newitfarmer.com/big_data/streams/storm/13927/repost-storm-spout-push-vs-pull#utm_source=rss&utm_medium=rss&utm_campaign=repost-storm-spout-push-vs-pull

Labels:

[repost ]Windows下开发Hadoop2.2.0程序

original:http://mmicky.blog.163.com/blog/static/150290154201311136482094/ 在windows使用eclipse开发 hadoop2.2.0程序的时候,会提示没有winutils.exe的错误,需要在windows端编译源代码才能解决。 一:准备工作 1:相关软件包下载并安装 Apache Hadoop 2.2.0 Source codes Microsoft Windows SDK for Windows 7 and .NET Framework 4 Maven Protocol Buffers 2.5.0 Cygwin JDK findbugs 2:系统环境变量设置 JAVA_HOME=C:\Java\jdk631 M2_HOME=E:\App\maven305 Platform=x64 Path增加;C:\cygwin64\bin;%M2_HOME%\bin 二:编译和安装 参考文档:Build, Install, Configure and Run Apache Hadoop 2.2.0 in Microsoft Windows OS 1:编译 将hadoop2.2.0的源代码解压缩到d:\hadoop220_src。 开始–>所有程序–> Microsoft Windows SDK v7.1–>Windows SDK 7.1 Command [...]



via WordPress http://blog.newitfarmer.com/big_data/big-data-platform/hadoop/13925/repost-windows%e4%b8%8b%e5%bc%80%e5%8f%91hadoop2-2-0%e7%a8%8b%e5%ba%8f#utm_source=rss&utm_medium=rss&utm_campaign=repost-windows%25e4%25b8%258b%25e5%25bc%2580%25e5%258f%2591hadoop2-2-0%25e7%25a8%258b%25e5%25ba%258f

Labels:

Thursday, January 09, 2014

[repost ]HttpClient 4.2.6 Tutorial

original:http://hc.apache.org/httpcomponents-client-4.2.x/tutorial/html/index.html Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the “License”); you may not use this file except in compliance with the [...]



via WordPress http://blog.newitfarmer.com/java/java-library/13920/repost-httpclient-4-2-6-tutorial#utm_source=rss&utm_medium=rss&utm_campaign=repost-httpclient-4-2-6-tutorial

Labels:

[repost ]数学界的哪些泰山北斗

original:http://www.mysanco.com/wenda/index.php?class=discuss&action=question_item&questionid=6202 作者:未知 前两天跟一个老同学聊近年来数学上的重大发现,结果作为科普人的我说着说着就发现,数学史原来就是一部八卦史。这个圈子奇葩辈出,怪事叠显。恩,这也正是我们本行从业人员不能自拔的一大乐趣。特此重新整理如下,绝对不保证事实正确性,与现实如有雷同纯是巧合。 故事首先从85年的 Andrew Wiles 说起。此人生在剑桥,但是考大学的时候2B了,没考上剑桥,去了离家不远的国王学院,毕业后好歹也去了牛津大学读了数学博士,但是毕业已经27岁了。作为数学从业人员,大家都知道,27岁才博士毕业,基本就是 “此人智商也就稀松平常” 的同义语。数学界的最高奖菲尔兹奖只发给40岁以下的人,你丫27岁才毕业,在这个行当里还有几年好混啊,对吧。正如妈妈总会拿邻居家的小孩来对比一样,看看人家特仑苏陶大神,20岁就博士毕业了,24岁都终身教授了,这才有大师范儿。 回头说这个 Wiles ,毕业后颠簸了几年总算去 Princeton 找了份教职,正式迈入伪大佬行列。人们都知道在美国混教职,前七年最难熬,因为每年都有发文章的硬性要求,发不出来就下岗。熬过七年就是终身教授了。这个 Wiles 一去也是玩了命儿地憋文章啊,没日没夜地写。但是他干了件惊天地的NB事儿,每年都扣下几篇写好的文章不发。这是在干啥,等被别人抢发了么?NO,作为一个吊丝大叔,他在盘算一个宏伟的逆袭计划。 大概 85 年左右,数学界发现只要证明 Taniyama 猜想就证明了费马大定理。这个费马大定理可是几百年未决的世纪大难题。Wiles 当时就决定搞这个。这个很有不成功则成仁的勇气,因为几百年来无数英雄天才都在这上面折了腰。搞出来就是一代伟人,搞不出来就是将生命燃烧成一缕烟化作一堆灰埋在春泥里。从85年起,Wiles 就开始闭关修炼费马大定理,谁也没告诉,一个人宅小黑屋里偷偷地搞。恩,搞数学其实就是这样的。生物化学物理都要合作,唯有数学,没有合作这一说,所有大成就都是一个吊人宅小黑屋里偷偷地搞,然后搞出来让大家膜拜他的智商的。这一宅就是好多好多年,但是要晋升终身教授每年都要有文章啊,这时候,前几年攒下的文章就派上用场了,每年都拿出来发一点,最后也有惊无险地成为了终身教授。 宅了整整七年后,竟然终于搞出来了。七年啊,练龙象般诺功也该练到第八九层了都。逆袭了,就这三个字。但是好景不长,还未满一年,就被发现这个证明有错。数学上被发现论文有错可是大事。生物化学还可以是解释试验方法不对,仪器有问题,小白鼠长得丑,之类乱七八糟的原因,但是数学论文有错,只有一个原因,就是你智商有问题。数学史上就有个数学家,挺有名的但是忘了叫啥了,论文发表错了三次,直接身败名裂。投文章的没杂志收了,灰溜溜地退出数学界了。主要是数学论文不好懂,别人看你证明怎么着也得看半个月半年的,看了这么久原来发现有错,这不是耍人谋杀生命么。为了避免身败名裂的厄运, Wiles 没办法又开始宅了。好在这下是终身教授了,宅着也没人开除他。这一宅又是三四年,终于把这个 bug 给修复了。然后,这个故事就结束了,Happy ending, 这位 Wiles 从老吊丝摇身一变成为了武林泰山北斗。 时间转到了2003年。俄罗斯,也就是毛子国,Perelman 说他证明了也是一个一百多年的世纪大问题庞加莱猜想。大家都惊了,此人是谁?问问此行专家,专家都说此人貌似很NB。但是NB在什么地方?不知道,也没见他发过啥文章啥的。而且也不在美国,是在毛子国的一个大学做研究员。这个问题实在是太重要了,于是美国各个大学都开始读他的证明。数学家读同行的文章是怎么读呢?恩,当时是这样的。一个教授,带几个博士后,加几个博士,组成一个小组。每周开会一次,大家看个一两页,一起讨论把搞懂。恩对,每周只能看一两页。然后一堆天才像参详武功秘笈一样,每周争吵讨论才能看懂。就这么几百页的文章看了一年多,大家觉得没啥问题,貌似都看懂了。然后世界才发现,啊,写这个武功秘籍的人原来是大师。看着都这么费劲,写出来的人岂不是智商超越宇宙边际了。 这时候,突然有一个小组,宣布他们发现了 Perelman 的文章有错。正如当年 Wiles 也被发现有错一样。不过这次是另外一种结局,Perelman 给世界的回复只有一句话 “我的文章没错,是丫的没看懂”。然后,最后事实证明,挑错的那个小组的教授们身败名裂了。数学界真的是风险行业,动不动就身败名裂的,入行的骚年们请三思啊。 然后就照例是 Happy ending 时间了,全世界的大学,教授,记者都飞去了莫斯科去找这位扫地神僧。结果人家一概不见。不搞讲座,不领奖,不接受采访。几百万美元的奖励不要,还是宅在老房子里啃黑面包。是真的啃黑面包,因为记者采访到他常去的那个超市的售货员,说 Perelman 总是胡子拉碴衣衫不整地过来买菜,高档的东西统统买不起,每天都买黑面包和通心粉。恩,这就是事实,这就是大师范儿。Perelman 现在在哪里在干什么没人知道,估计还是在宅着研究下一个大问题吧。 再往后,时间到了2013年,这次轮到中国人了。依然是一个老吊丝。此人叫张益唐,年轻的时候在野鸡大学 Purdue University 拿了博士学位,结果博士论文被发现有错,直接身败名裂没找到工作。此后流浪于美国各地,中餐馆小旅社之类的都打过工,还在 Subway 打过工。美国东北部的另一个野鸡大学 University [...]



via WordPress http://blog.newitfarmer.com/ai/math/13915/repost-%e6%95%b0%e5%ad%a6%e7%95%8c%e7%9a%84%e5%93%aa%e4%ba%9b%e6%b3%b0%e5%b1%b1%e5%8c%97%e6%96%97#utm_source=rss&utm_medium=rss&utm_campaign=repost-%25e6%2595%25b0%25e5%25ad%25a6%25e7%2595%258c%25e7%259a%2584%25e5%2593%25aa%25e4%25ba%259b%25e6%25b3%25b0%25e5%25b1%25b1%25e5%258c%2597%25e6%2596%2597

Labels:

[repost ]Computer science: The learning machines

original:http://www.nature.com/news/computer-science-the-learning-machines-1.14481 Using massive amounts of data to recognize photos and speech, deep-learning computers are taking a big step towards true artificial intelligence. PDF Rights & Permissions BRUCE ROLFF/SHUTTERSTOCK Three years ago, researchers at the secretive Google X lab in Mountain View, California, extracted some 10 million still images from YouTube videos and fed them into [...]



via WordPress http://blog.newitfarmer.com/ai/deep-learning/13912/repost-computer-science-the-learning-machines#utm_source=rss&utm_medium=rss&utm_campaign=repost-computer-science-the-learning-machines

Labels:

Wednesday, January 08, 2014

[repost ]Qt Jambi – Qt for Java

original:http://qt-jambi.org/ Qt is the de facto standard C++ framework for high performance cross-platform software development. Qt Jambi is the Qt library made available to Java. It is an open source technology aimed at all desktop programmers wanting to write rich GUI clients using the Java language, while at the same time taking advantage of Qt’s [...]



via WordPress http://blog.newitfarmer.com/others/13899/repost-qt-jambi-qt-for-java#utm_source=rss&utm_medium=rss&utm_campaign=repost-qt-jambi-qt-for-java

Labels:

[repost ]12款免费与开源的NoSQL数据库介绍

original:http://www.infoq.com/cn/news/2014/01/12-free-and-open-source-nosql Naresh Kumar是位软件工程师与热情的博主,对于编程与新事物拥有极大的兴趣,非常乐于与其他开发者和程序员分享技术上的研究成果。近日,Naresh撰文谈到了12款知名的免费、开源NoSQL数据库,并对这些数据库的特点进行了分析。 现在,NoSQL数据库变得越来越流行,我在这里总结出了一些非常棒的、免费且开源的NoSQL数据库。在这些数据库中,MongoDB独占鳌头,拥有相当大的使用量。这些免费且开源的NoSQL数据库具有很好的可伸缩性与灵活性,非常适合于大数据存储与处理。相较于传统的关系型数据库,这些NoSQL数据库在性能上具有很大的优势。然而,这些NoSQL数据库未必最适合你。大多数常见的应用仍然可以使用传统的关系型数据库进行开发。NoSQL数据库依然不太适合于那些任务关键型的事务要求。我对这些数据库进行了一些简单介绍,下面就来看看。 1. MongoDB MongoDB是个面向文档的数据库,使用JSON风格的数据格式。它非常适合于网站的数据存储、内容管理与缓存应用,并且通过配置可以实现复制与高可用性功能。 MongoDB具有很强的可伸缩性,性能表现优异。它使用C++编写,基于文档存储。此外,MongoDB还支持全文检索、跨WAN与LAN的高可用性、易于实现的复制、水平扩展、基于文档的丰富查询、在数据处理与聚合等方面具有很强的灵活性。 2. Cassandra 这是个Apache软件基金会的项目,Cassandra是个分布式数据库,支持分散的数据存储,可以实现容错以及无单点故障等。换句话说,“Cassandra非常适合于那些无法忍受数据丢失的应用”。 3. CouchDB 这也是Apache软件基金会的一个项目,CouchDB是另一个面向文档的数据库,以JSON格式存储数据。它兼容于ACID,像MongoDB一样,CouchDB也可以用于存储网站的数据与内容,以及提供缓存等。你可以通过JavaScript在CouchDB上运行MapReduce查询。此外,CouchDB还提供了一个非常方便的基于Web的管理控制台。它非常适合于Web应用。 4. Hypertable Hypertable模仿的是Google的BigTable数据库系统。Hypertable的创建者将“成为高可用、PB规模的数据库开源标准”作为Hypertable的目标。换言之,Hypertable的设计目标是跨越多个廉价的服务器可靠地存储大量数据。 5. Redis 这是个开源、高级的键值存储。由于在键中使用了hash、set、string、sorted set及list,因此Redis也称作数据结构服务器。这个系统可以帮助你执行原子操作,比如说增加hash中的值、集合的交集运算、字符串拼接、差集与并集等。Redis通过内存中的数据集实现了高性能。此外,该数据库还兼容于大多数编程语言。 6. Riak Riak是最为强大的分布式数据库之一,它提供了轻松且可预测的伸缩能力,向用户提供了快速测试、原型与应用部署能力,从而简化应用的开发过程。 7. Neo4j Neo4j是一款NoSQL图型数据库,具有非常高的性能。它拥有一个健壮且成熟的系统的所有特性,向程序员提供了灵活且面向对象的网络结构,可以让开发者充分享受到拥有完整事务特性的数据库的所有好处。相较于RDBMS,Neo4j还对某些应用提供了不少性能改进。 8. Hadoop HBase HBase是一款可伸缩、分布式的大数据存储。它可以用在数据的实时与随机访问的场景下。HBase拥有模块化与线性的可伸缩性,并且能够保证读写的严格一致性。HBase提供了一个Java API,可以实现轻松的客户端访问;提供了可配置且自动化的表分区功能;还有Bloom过滤器以及block缓存等特性。 9. Couchbase 虽然Couchbase是CouchDB的派生,不过它已经成为了一款功能完善的数据库产品。它向文档数据库转移的趋势会让MongoDB感到压力。每个节点上它都是多线程的,这是个非常主要的可伸缩性优势,特别是当托管在自定义或是Bare-Metal硬件上时更是如此。借助于一些非常棒的集成特性,诸如与Hadoop的集成,Couchbase对于数据存储来说是个非常不错的选择。 10. MemcacheDB 这是个分布式的键值存储系统,我们不应该将其与缓存解决方案搞混;相反,它是个持久化存储引擎,用于数据存储并以非常快速且可靠的方式检索数据。它遵循memcache协议。其存储后端用于Berkeley DB中,支持诸如复制与事务等特性。 11. REVENDB RAVENDB是第二代开源数据库,它面向文档存储并且无模式,这样就可以轻松将对象存储到其中了。它提供了非常灵活且快速的查询,通过对复制、多租与分片提供开箱即用的支持使得我们可以非常轻松地实现伸缩功能。它对ACID事务提供了完整的支持,同时又能保证数据的安全性。除了高性能之外,它还通过bundle提供了轻松的可扩展性。 12. Voldemort 这是个自动复制的分布式存储系统。它提供了自动化的数据分区功能,透明的服务器失败处理、可插拔的序列化功能、独立的节点、数据版本化以及跨越各种数据中心的数据分发功能。 各位InfoQ读者,不知在你的项目中曾经、现在或是未来使用了哪些NoSQL数据库。现今的NoSQL世界纷繁复杂,NoSQL数据库也多如牛毛,而且有一些数据库提供了相似的特性,本文所列出的只是其中比较有代表性的12款NoSQL产品。你是否使用过他们呢?是否使用了本文没有介绍的产品呢?他们有哪些特性打动了你,让你决定使用他们呢?非常欢迎将你的经历与看法与我们一起分享。



via WordPress http://blog.newitfarmer.com/nosql/common-nosql/13886/repost-12%e6%ac%be%e5%85%8d%e8%b4%b9%e4%b8%8e%e5%bc%80%e6%ba%90%e7%9a%84nosql%e6%95%b0%e6%8d%ae%e5%ba%93%e4%bb%8b%e7%bb%8d#utm_source=rss&utm_medium=rss&utm_campaign=repost-12%25e6%25ac%25be%25e5%2585%258d%25e8%25b4%25b9%25e4%25b8%258e%25e5%25bc%2580%25e6%25ba%2590%25e7%259a%2584nosql%25e6%2595%25b0%25e6%258d%25ae%25e5%25ba%2593%25e4%25bb%258b%25e7%25bb%258d

Labels:

Sunday, January 05, 2014

[repost ]Apache Kafka Evaluation

original:http://muse-amuse.in/~madhusudancs/asterixdb-kafkaeval/presentation.html



via WordPress http://blog.newitfarmer.com/message/kafka/13872/repost-apache-kafka-evaluation#utm_source=rss&utm_medium=rss&utm_campaign=repost-apache-kafka-evaluation

Labels:

[repost ]关于Cassandra的错误观点

original:http://www.infoq.com/cn/articles/cassandra-mythology 正如Apache Cassandra的名称是来自于著名的物洛伊女巫一样,在它身上确实存在着各种误解。和大多数误解一样,至少在一开始时它们确实是有那么一点道理的,但随着Cassandra不断地深化与改善,这些误解的内容已经不复存在了。在本文中,我将针对五个常见的疑惑作出解释,澄清人们的困惑。 误解:Cassandra就是一个嵌套的map 随着使用Cassandra的应用程序变得越来越复杂,以下观点正在逐渐变得清晰起来:与“任何东西都是一个数组缓冲”或者“任何东西都是一个字符串”这种设计方式相比,schema与数据类型会使大型应用的开发与维护更加简单, 现如今,理解Cassandra的数据模型的最好方式是将其想像为表与行的组合,并且与关系型数据相似的是,Cassandra的列也是强类型的,并且可以进行索引。 你也许还听到过其它这些说法: “Cassandra是一种列数据库。”列数据库会将某个列的全部数据一起保存在磁盘上,这种方式对于数据仓库的检索方式是比较适合的,但对于那些需要对特定的行进行快速访问的应用程序来说就不太适合了。 “Cassandra是一种宽行数据库。”这种说法有一定的道理,因为Cassandra的存储引擎是由Bigtable所启发而设计的,而后者可以说是宽行数据库的祖先了。但宽行数据库的数据模型与存储引擎结合得太过紧密,虽然实现起来比较容易,但针对它进行开发就增加了困难,而且它还使许多优化方式变得不可行了。 我们之所以在开始的部分选择避开“表与行”这种方法,原因之一是因为Cassandra的表与你所熟的关系型数据库的表的确存在着某些微妙的差别。首先,主键的首个元素是分区键,在同一个分区中的所有行都会存储在同一台服务器上,而分区是分布在整个集群中的。 其次,Cassandra不支持关联查询与子查询,这是因为在分布式系统中跨越硬件进行关联查询的性能很差。Cassandra的做法是鼓励你采用去正规化(denormalization)的方式,从一个单独的表中获取你所需的数据,同时提供集合等工具以简化操作。 举例来说,考虑一下以下代码所表示的users表: CREATE TABLE users ( user_id uuid PRIMARY KEY, name text, state text, birth_year int ); 目前多数主流服务都会考虑到一个用户可以拥有多个email地址的情况。在关系型数据库中,我们必需建立一个多对一的关系,随后使用关联查询将地址与用户关联起来,如以下所示: CREATE TABLE users_addresses ( user_id uuid REFERENCES users, email text ); SELECT * FROM users NATURAL JOIN users_addresses; 而在Cassandra中,我们会以去正规化的方式将所有email地址直接加入用户表中,使用一个set集合就可以完美地实现这一点: ALTER TABLE users ADD email_addresses set<text>; 随后我们可以以如下方式为用户添加多个地址: UPDATE [...]



via WordPress http://blog.newitfarmer.com/nosql/bigtable-store/cassandra/13868/repost-%e5%85%b3%e4%ba%8ecassandra%e7%9a%84%e9%94%99%e8%af%af%e8%a7%82%e7%82%b9#utm_source=rss&utm_medium=rss&utm_campaign=repost-%25e5%2585%25b3%25e4%25ba%258ecassandra%25e7%259a%2584%25e9%2594%2599%25e8%25af%25af%25e8%25a7%2582%25e7%2582%25b9

Labels:

[repost ]机器学习是什么–周志华

original:http://hi.baidu.com/giqguarzqdbadpq/item/8d41e5160121a3ff65eabf8d 机器学习现在是一大热门,研究的人特多,越来越多的新人涌进来。 不少人其实并没有真正想过,这是不是自己喜欢搞的东西,只不过看见别人都在搞,觉着跟大伙儿走总不会吃亏吧。 问题是,真有个“大伙儿”吗?就不会是“两伙儿”、“三伙儿”?如果有“几伙儿”,那到底该跟着“哪伙儿”走呢? 很多人可能没有意识到,所谓的machine learning community,现在至少包含了两个有着完全不同的文化、完全不同的价值观的群体,称为machine learning “communities”也许更合适一些。 第一个community,是把机器学习看作人工智能分支的一个群体,这群人的主体是计算机科学家。 现在的“机器学习研究者”可能很少有人读过1983年出的“Machine Learning: An Artificial Intelligence Approach”这本书。这本书的出版标志着机器学习成为人工智能中一个独立的领域。它其实是一部集早期机器学习研究之大成的文集,收罗了若干先贤(例 如Herbert Simon,那位把诺贝尔奖、图灵奖以及各种各样和他相关的奖几乎拿遍了的科学天才)的大作,主编是Ryszard S. Michalski(此君已去世多年了,他可算是机器学习的奠基人之一)、Jaime G. Carbonell(此君曾是Springer的LNAI的总编)、Tom Mitchell(此君是CMU机器学习系首任系主任、著名教材的作者,机器学习界没人不知道他吧)。Machine Learning杂志的创刊,正是这群人努力的结果。这本书值得一读。虽然技术手段早就日新月异了,但有一些深刻的思想现在并没有过时。各个学科领域总有 不少东西,换了新装之后又粉墨登场,现在热火朝天的transfer learning,其实就是learning by analogy的升级版。 人工智能的研究从以“推理”为重点到以“知识”为重点,再到以“学习”为重点,是有一条自然、清晰的脉络。人工智能出身的机器学习研究者,绝大部分 是把机器学习作为实现人工智能的一个途径,正如1983年的书名那样。他们关注的是人工智能中的问题,希望以机器学习为手段,但具体采用什么样的学习手 段,是基于统计的、代数的、还是逻辑的、几何的,他们并不care。 这群人可能对统计学习目前dominating的地位未必满意。靠统计学习是不可能解决人工智能中大部分问题的,如果统计学习压制了对其他手段的研 究,可能不是好事。这群人往往也不care在文章里show自己的数学水平,甚至可能是以简化表达自己的思想为荣。人工智能问题不是数学问题,甚至未必是 依靠数学能够解决的问题。人工智能中许多事情的难处,往往在于我们不知道困难的本质在哪里,不知道“问题”在哪里。一旦“问题”清楚了,解决起来可能并不 困难。 第二个community,是把机器学习看作“应用统计学”的一个群体,这群人的主体是统计学家。 和纯数学相比,统计学不太“干净”,不少数学家甚至拒绝承认统计学是数学。但如果和人工智能相比,统计学就太干净了,统计学研究的问题是清楚的,不象人工智能那样,连问题到底在哪里都不知道。在相当长时间里,统计学家和机器学习一直保持着距离。 慢慢地,不少统计学家逐渐意识到,统计学本来就该面向应用,而机器学习天生就是一个很好的切入点。因为机器学习虽然用到各种各样的数学,但要分析大 量数据中蕴涵的规律,统计学是必不可少的。统计学出身的机器学习研究者,绝大部分是把机器学习当作应用统计学。他们关注的是如何把统计学中的理论和方法变 成可以在计算机上有效实现的算法,至于这样的算法对人工智能中的什么问题有用,他们并不care。 这群人可能对人工智能毫无兴趣,在他们眼中,机器学习就是统计学习,是统计学比较偏向应用的一个分支,充其量是统计学与计算机科学的交叉。这群人对统计学习之外的学习手段往往是排斥的,这很自然,基于代数的、逻辑的、几何的学习,很难纳入统计学的范畴。 两个群体的文化和价值观完全不同。第一个群体认为好的工作,第二个群体可能觉得没有技术含量,但第一个群体可能恰恰认为,简单的才好,正因为很好地 抓住了问题本质,所以问题变得容易解决。第二个群体欣赏的工作,第一个群体可能觉得是故弄玄虚,看不出他想解决什么人工智能问题,根本就不是在搞人工智 能、搞计算机,但别人本来也没说自己是在“搞人工智能”、“搞计算机”,本来就不是在为人工智能做研究。 两个群体各有其存在的意义,应该宽容一点,不需要去互较什么短长。但是既然顶着Machine Learning这个帽子的不是“一伙儿”,而是“两伙儿”,那么要“跟进”的新人就要谨慎了,先搞清楚自己更喜欢“哪伙儿”。 引两位著名学者的话结尾,一位是人工智能大奖得主、一位是统计学习大家,名字我不说了,省得惹麻烦: “I do not come to AI to do [...]



via WordPress http://blog.newitfarmer.com/ai/machine-learning/13863/repost-%e6%9c%ba%e5%99%a8%e5%ad%a6%e4%b9%a0%e6%98%af%e4%bb%80%e4%b9%88-%e5%91%a8%e5%bf%97%e5%8d%8e#utm_source=rss&utm_medium=rss&utm_campaign=repost-%25e6%259c%25ba%25e5%2599%25a8%25e5%25ad%25a6%25e4%25b9%25a0%25e6%2598%25af%25e4%25bb%2580%25e4%25b9%2588-%25e5%2591%25a8%25e5%25bf%2597%25e5%258d%258e

Labels:

Friday, January 03, 2014

[repost ]HBase in 2013

original:http://yanbohappy.sinaapp.com/?p=434 2013年马上就要过去了,总结下这一年HBase在这么一年中发生的主要变化。影响最大的事件就是HBase 0.96的发布,代码结构已经按照模块化release了,而且提供了许多大家迫切需求的特点。这些特点大多在Yahoo/Facebook/淘宝/小米等公司内部的集群中跑了挺长时间了,可以算是比较稳定可用了。 1,Compaction优化 HBase的Compaction是长期以来广受诟病的一个feature,很多人吐槽HBase也是因为这个特征。不过我们不能因为HBase有这样一个缺点就把它一棒子打死,更多的还是希望能够驯服它,能够使得它适应自己的应用场景。根据业务负载类型调整compaction的类型和参数,一般在业务高峰时候禁掉Major Compaction。在0.96中HBase社区为了提供更多的compaction的策略适用于不同的应用场景,采用了插件式的架构。同时改进了HBase在RegionServer端的存储管理,原来是直接Region->Store->StoreFile,现在为了支持更加灵活多样的管理StoreFile和compact的策略,RS端采用了StoreEngine的结构。一个StoreEngine涉及到StoreFlusher, CompactionPolicy, Compactor, StoreFileManager。不指定的话默认是DefaultStoreEngine,四个组件分别是DefaultStoreFlusher, ExploringCompactionPolicy, DefaultCompactor, DefaultStoreFileManager。可以看出在0.96版之后,默认的Compaction算法从RatioBasedCompactionPolicy改为了ExploringCompactionPolicy。为什么要这么改,首先从compaction的优化目标来看:compaction is about trading some disk IO now for fewer seeks later,也就是compaction的优化目标是执行Compaction操作能合并越多的文件越好,如果合并同样多的文件产生的IO越小越好,这样select出来的列表才是最优的。 主要不同在于: RatioBasedCompactionPolicy是简单的从头到尾遍历StoreFile列表,遇到一个符合Ratio条件的序列就选定执行compaction。对于典型的不断flush memstore形成 StoreFile的场景是合适的,但是对于bulk-loaded是不合适的,会陷入局部最优。 而ExploringCompactionPolicy则是从头到尾遍历的同时记录下当前最优,然后从中选择一个全局最优列表。 关于这两个算法的逻辑可以在代码中参考对应的applyCompactionPolicy()函数。其他CompactionPolicy的研究和开发也非常活跃,例如Tier-based compaction (HBASE-6371,来自Facebook) 和stripe compaction(HBASE-7667) 吐槽:HBase compaction为什么会问题这么多,我感觉缺少了一个整体的IO负载的反馈和调度机制。因为compaction是从HDFS读数据,然后再写到HDFS中,和其他HDFS上的负载一样在抢占IO资源。如果能有个IO资源管理和调度的机制,在HDFS负载轻的时候执行compaction,在负载重的时候不要执行。而且这个问题在Hadoop/HDFS里同样存在,Hadoop的资源管理目前只针对CPU/Memory的资源管理,没有对IO的资源管理,会导致有些Job受自己程序bug的影响可能会写大量的数据到HDFS,会严重影响其他正常Job的读写性能。 http://blog.cloudera.com/blog/2013/12/what-are-hbase-compactions/ http://www.slideshare.net/cloudera/hbasecon-2013-compaction-improvements-in-apache-hbase 2,Mean Time To Recovery/MTTR优化 目前HBase对外提供服务,Region Server是单点。如果某台RS挂掉,那么直到该RS上的所有Region被重新分配到其他RS上之前,这些Region是的数据是无法访问的。对这个过程的改进主要包括: HBASE-5844 和 HBASE-5926:删除zookeeper上Region Server/Master对应的znode,这样就省的等到znode 30s超时才发现对应的RS/Master挂了。 HBASE-7006: Distributed Log Replay,就是直接从HDFS上读取宕机的WAL日志,直接向新分配的RS进行Log Replay,而不是创建临时文件recovered.edits然后再进行Log Replay HBASE-7213/8631: [...]



via WordPress http://blog.newitfarmer.com/big_data/big-data_store/hbase/13854/repost-hbase-in-2013#utm_source=rss&utm_medium=rss&utm_campaign=repost-hbase-in-2013

Labels:

[repost ]谦卑的架构师

original:http://www.infoq.com/cn/news/2013/12/humble-architects Johannes Brodwall是一位程序员、解决方案架构师、用户组与会议组织者、会议演讲者与布道师。Johannes一直在不遗余力地将敏捷原则应用到大型软件项目中,不过他真正感兴趣的是与全世界的程序员分享更多关于编程的有趣经验。目前,Johannes就职于Exilesoft,担任首席科学家一职。近日,Johannes撰写了题为谦卑的架构师一文,探讨了架构师所应该遵循的几个原则,在程序员群体中引起了很大的反响。 谦卑并不是软件架构师一个非常常见的特质。我曾与一些可怕的架构师共事过,最近也与一位非常棒的架构师合作过。基于此,我根据每个架构师都喜欢的方式将我过去的经验汇聚起来,以规则集的形式写出来,与大家一起分享并讨论。 规则0:不要愚蠢地做出假设 看起来有些架构师会觉得一旦让开发者自行处理某些事情,那么他们就会像猴子那样杂乱无序。根据我的经验,这种情况其实是很少会出现的。只有一种情况会让开发者做傻事,那就是他们在心里默默抵触架构师。如果遵循着这条原则,那么其他的都将是细节问题。 规则1:你可能是错误的 在审查某人的设计想法时,我更倾向于以坦诚布公的方式询问问题。也许我觉得开发者忽略掉了某个关键的事实,比如说并发等。对于这种情况有几种不同的方式: 架构师:你不能那样做,因为它破坏了编码规范。 架构师:你不能那样做,因为当同时有几个用户时是不安全的。 架构师:你想过它是如何处理几个用户的情况的么? 架构师:你提出的解决方案是如何处理几个用户的情况的? 亲爱的架构师们:请对这些方式评级,按照从最差到最好的方式排序(提示:这是个很简单的事,不过很多架构师却还是做不好)。 规则2:对技术保持谨慎的态度 每种技术都是有代价的,而很多技术所带来的好处是非常有限的。下面是我使用过的一些代价要远远高于所带来的好处的一个技术列表(如果不知道也没关系,关键在于数量):JavaServer Pages、Java Server Faces、JAX-WS、Hibernate、Spring、EJB、Oracle SOA Server、IBM WebSphere、Wicket、Google Web Toolkit、Adobe Flex、JBoss jBPM、JMS(所有实现)与 JBoss。下面是我非常喜欢使用的一个技术列表:JUnit、Jetty、Joda-time与Java标准版。 看看下面的对话吧: 架构师:你应该使用技术X。 我:我看过技术X,不过不清楚怎样通过它来解决业务问题。 架构师:你的意思是? 我:这是我们需要做的事情。。。这是技术X所能解决的问题。。。我不知道他们之间是如何匹配的。 架构师:那你的建议是什么呢? 我:我觉得可以通过普通的Java来解决这个问题。事实上,昨天晚上我已经做了一个很不错的概念验证。 架构师:太酷了,我们就这么干吧。 规则3:一致性并不如你所想象的那么重要 我总听到有人这么说: 架构师:没错,我知道这种方式看起来很笨拙,不过你必须这么做。你也看到了,如果不这么做,那么系统就会变得不一致,也难以维护。 好吧,我确实很少接触维护方面的工作,不过我知道在处理任何系统时,最困难的部分在于理解系统的业务逻辑。系统X(有自己的一套业务逻辑)与系统Y(有另一套业务逻辑)是否是一致的并不那么重要。如果说系统X非常复杂的原因在于它为了保持与系统Y的一致性而增加了很多层次,那我真的要抓狂了。不同的上下文有不同的权衡。还记得规则0吗,开发者在给定的上下文进行开发,那么他就会为该上下文创建一个很好的解决方案。另外,我还从来没有见过规模不大的系统非常复杂,等系统逐步变大时就变得更好维护了。如果程序员感到不爽的原因只是因为有些代码的花括号使用的是一种风格,而另外一些代码则采用了其他风格,那么我也真的要崩溃了。 规则4:至底向上的一致性要优于自上而下的一致性 我有一种方式可以实现系统中更多的一致性: 创建一个参考应用,并使用易于遵循的架构。如果这件事干得好,那么开发者们就会始终记得不要偏离这个架构。除非他们不想,否则这么做就没问题。 培育一种互助的文化。能够看到彼此代码的开发者要比那些只看到自己代码的具有更好的一致性。结对编程、代码审查以及技术分享讲座都有助于这种文化的培育。 规则5:跨系统的重用是次要的优化 重用会导致耦合。如果系统X与系统Y重用了某些功能,系统X需要修改某个功能,这就会影响到系统Y。至少,系统X的开发团队必须要对重用的功能创建一个私有的分支,这意味着该功能实际上并不会再被重用了。更糟糕的是,被重用的功能的某个改变会导致系统Y出现Bug。在进行跨系统重用时,你所重用的应该是要么稳定的(比如说,Java SE平台,或是某个非常稳定的功能),要么是策略性的。根据策略重用,我指的是集成了信息而不仅仅是复制功能的服务。换句话说,重用要么是使用,要么是集成。重复是你的朋友。 规则6:分清规则与教条 任何编码标准都需要有原则,原因有3: 不安全:代码的Bug只会在某些情况下才能显现出来 费解的:我不理解接下来的事情 异端:某些人不喜欢某些代码风格 如果有一条规则说到“所有属性都必须要有JavaDoc注释”,那么你认为这是个安全问题、让人费解的问题还是异端呢?看看下面这个代码示例: /** * Contains the [...]



via WordPress http://blog.newitfarmer.com/architecture/arch-others/13852/repost-%e8%b0%a6%e5%8d%91%e7%9a%84%e6%9e%b6%e6%9e%84%e5%b8%88#utm_source=rss&utm_medium=rss&utm_campaign=repost-%25e8%25b0%25a6%25e5%258d%2591%25e7%259a%2584%25e6%259e%25b6%25e6%259e%2584%25e5%25b8%2588

Labels: