实现MySQL表数据全量索引和增量索引，基于Solr DIH组件实现起来比较简单，只需要重复使用Solr的DIH（Data Import Handler）组件，对data-config.xml进行简单的修改即可。Solr DIH组件的实现类为org.apache.solr.handler.dataimport.DataImportHandler，在Solr的solrconfig.xml中配置两个handler，配置分别说明如下。 全量索引 solrconfig.xml配置如下： <requestHandler name="/dataimport" class="org.apache.solr.handler.dataimport.DataImportHandler"> <lst name="defaults"> <str name="config">data-config.xml</str> </lst> </requestHandler> 上面这个是针对全量索引的，主要是配置data-config.xml文件，示例如下所示： <dataConfig> <dataSource name="jdbc" driver="com.mysql.jdbc.Driver" url="jdbc:mysql://172.0.8.249:5606/marketing_db_saved
分类算法：决策树（C4.5）
C4.5是机器学习算法中的另一个分类决策树算法，它是基于ID3算法进行改进后的一种重要算法，相比于ID3算法，改进有如下几个要点： 用信息增益率来选择属性。ID3选择属性用的是子树的信息增益，这里可以用很多方法来定义信息，ID3使用的是熵（entropy， 熵是一种不纯度度量准则），也就是熵的变化值，而C4.5用的是信息增益率。 在决策树构造过程中进行剪枝，因为某些具有很少元素的结点可能会使构造的决策树过适应（Overfitting），如果不考虑这些结点可能会更好。 对非离散数据也能处理。 能够对不完整数据进行处理。 首先，说明一下如何计算信息增益率。 熟悉了ID3算法后，已经知道如何计算信息增益，计算公式如下所示（来自Wikipedia）： 或者，用另一个更加直观容易理解的公式计算： 按照类标签对训练数据集D的属性集A进行划分，得到信息熵： 按照属性集A中每个属性进行划分，得到一组信息熵： 计算信息增益 然后计算信息增益，即前者对后者做差，得到属性集合A一组信息增益： 这样，信息增益就计算出来了。 计算信息增益率 下面看，计算信息增益率
Solr DIH: 基于MySQL表数据建立索引
选择使用Solr，对数据库中数据进行索引，可以单独写程序将数据库中的数据导出并建立索引，这个过程可能对于数据处理的控制更灵活一些，但是却可能带来很大的工作量。选择使用Solr的DIH组件，可以很方便的对数据库表中数据进行索引，下面基于MySQL数据库实现建立索引。 首先，需要设计你的schema，最主要的工作是，将数据库表中字段映射为Lucene索引（Solr直接使用Lucene的索引格式和数据）的Field，从而将数据表中的一条记录映射为Lucene中的Document，然后进行索引。另外，在schema.xml配置文件中，还需要指定各个字段在索引数据中的属性信息（如是否索引、是否存储、是否分词、排序规则等），以及Field所使用的分析器、过滤器等。在schema.xml文件进行配置，下面是配置实例： <?xml version="1.0" ?> <schema name="example core zero" version="1.1"> <types> <fieldtype name="int" class="solr.IntField" omitNorms="true" /> <fieldtype name="stri
分类算法：决策树（ID3）
决策树是以实例为基础的归纳学习算法。 它从一组无次序、无规则的元组中推理出决策树表示形式的分类规则。它采用自顶向下的递归方式，在决策树的内部结点进行属性值的比较，并根据不同的属性值从该结点向下分支，叶结点是要学习划分的类。从根到叶结点的一条路径就对应着一条合取规则，整个决策树就对应着一组析取表达式规则。 一棵决策树由以下3类结点构成： 根结点 内部结点（决策结点） 叶结点 其中，根结点和内部结点都对应着我们要进行分类的属性集中的一个属性，而叶结点是分类中的类标签的集合。如果一棵决策树构建起来，其分类精度满足我们的实际需要，我们就可以使用它来进行分类新的数据集。 这棵决策树就是我们根据已有的训练数据集训练出来的分类模型，可以通过使用测试数据集来对分类模型进行验证，经过调整模型直到达到我们所期望的分类精度，然后就可以使用该模型来预测实际应用中的新数据，对新的数据进行分类。 通过上面描述，我们已经能够感觉出，在构建决策树的过程中，如果选择其中的内部结点（决策结点），才能够使我们的决策树得到较高的分
JVM 分代GC策略分析
我们以Sun HotSpot VM来进行分析，首先应该知道，如果我们没有指定任何GC策略的时候，JVM默认使用的GC策略。Java虚拟机是按照分代的方式来回收垃圾空间，我们应该知道，垃圾回收主要是针对堆（Heap）内存进行分代回收，将对内存可以分成新生代（Young Generation）、年老代（Tenured Generation）和永久代（Permanent Generation）三个部分。 分代GC 分代GC包括如下三代： 新生代（Young Generation） 新生代有划分为Eden、From Survivor和To Survivor三个部分，他们对应的内存空间的大小比例为8:1:1，也就是，为对象分配内存的时候，首先使用Eden空间，经过GC后，没有被回收的会首先进入From Survivor区域，任何时候，都会保持一个Survivorq区域（From Survivor或To Survivor）完全空闲，也就是说新生代的内存利用率最大为90%。From Survivor和To Survivor两个区域会根据GC的实际情况，进行互换，将From Survivor区域中的对象全部复制到To Survivor区域中，或者反过来，将To Survivor区域中的对象全部复制到From Survivor区域中。 年老代（
开发JAX-WS 2.0 Web服务
实现一个Web服务的过程，大概有3个基本的过程： Web服务提供者设计并开发Web服务 Web服务提供者发布Web服务 Web服务请求者调用Web服务 下面，我通过一个例子，来实现上述过程： 假设一个Web服务提供者提供一个对域名进行探测解析的服务，给定一个域名，可以给出改域名解析后对应的IP地址列表。Web服务提供者设计并开发这个Web服务，然后将服务发布出去，并可以让Web服务请求者进行调用。 开发Web服务 服务接口文件DetectionService.java代码如下所示： package org.shirdrn.server.webservices.jaxws; public interface DetectService { DetectedResult detect(String domain); } 对应的实现类DomainDetectionService.java，如下所示： package org.shirdrn.server.webservices.jaxws; import java.net.InetAddress; import java.net.UnknownHostException; import java.util.Date; import javax.jws.WebMethod; import javax.jws.WebService; import javax.jws.soap.SOAPBinding; import org.xbill.DNS.Address; @WebSe
Hadoop Job使用第三方依赖jar文件
当我们实现了一个Hadoop MapReduce Job以后，而这个Job可能又依赖很多外部的jar文件，在Hadoop集群上运行时，有时会出现找不到具体Class的异常。出现这种问题，基本上就是在Hadoop Job执行过程中，没有从执行的上下文中找到对应的jar文件（实际是unjar的目录，目录里面是对应的Class文件）。所以，我们自然而然想到，正确配置好对应的classpath，MapReduce Job运行时就能够找到。 有两种方式可以更好地实现，一种是设置HADOOP_CLASSPATH，将Job所依赖的jar文件加载到HADOOP_CLASSPATH，这种配置只针对该Job生效，Job结束之后HADOOP_CLASSPATH会被清理；另一种方式是，直接在构建代码的时候，将依赖jar文件与Job代码打成一个jar文件，这种方式可能会使得最终的jar文件比较大，但是结合一些代码构建工具，如Maven，可以在依赖控制方面保持一个Job一个依赖的构建配置，便于管理。下面，我们分别说明这两种方式。 设置HADOOP_CLASSPATH 比如，我们有一个使用HBase的应用，操作HBase数据库中表，肯定需要ZooKeeper，所以对应的jar文件的位置都要设置正确，让运行时Job能够
CentOS 6.4上HAProxy-1.4.24安装配置
HAProxy是一款免费、快速并且可靠的一种代理解决方案，支持高可用性、负载均衡特性，同时适用于做基于TCP和HTTP的应用的代理。对于一些负载较大的Web站点，使用HAProxy特别合适。HAProxy能够支撑数以万计的并发连接。它的配置简单，能够很容易整合大我们现有的应用架构之中。 下面，我们在CentOS 6.4上进行安装配置HAProxy。 安装配置 按照如下步骤进行安装： wget http://haproxy.1wt.eu/download/1.4/src/haproxy-1.4.24.tar.gz tar xvzf haproxy-1.4.24.tar.gz cd haproxy-1.4.24 make TARGET=linux26 make install 默认安装，HAProxy对应的配置文件的存放路径为/etc/haproxy/haproxy.cfg。 我们看一下，默认安装的配置文件内容，如下所示： #--------------------------------------------------------------------- # Example configuration for a possible web application. See the # full configuration options online. # # http://haproxy.1wt.eu/download/1.4/doc/configuration.txt # #-------------------------------------------
基于Dubbo的Hessian协议实现远程调用
Dubbo基于Hessian实现了自己Hessian协议，可以直接通过配置的Dubbo内置的其他协议，在服务消费方进行远程调用，也就是说，服务调用方需要使用Java语言来基于Dubbo调用提供方服务，限制了服务调用方。同时，使用Dubbo的Hessian协议实现提供方服务，而调用方可以使用标准的Hessian接口来调用，原生的Hessian协议已经支持多语言客户端调用，支持语言如下所示： Java：http://hessian.caucho.com/#Java Flash/Flex：http://hessian.caucho.com/#FlashFlex Python：http://hessian.caucho.com/#Python C++：http://hessian.caucho.com/#C C#：http://hessian.caucho.com/#NETC D：http://hessian.caucho.com/#D Erlang：http://hessian.caucho.com/#Erlang PHP：http://hessian.caucho.com/#PHP Ruby：http://hessian.caucho.com/#Ruby Objective-C：http://hessian.caucho.com/#ObjectiveC 下面，我们的思路是，先基于Dubbo封装的Hessian协议，实现提供方服务和消费方调用服务，双方必须都使用Dubbo来开发；然后，基于Dubbo封装的Hessian协议实现提供方服务，然后服务
Dubbo实现RPC调用使用入门
使用Dubbo进行远程调用实现服务交互，它支持多种协议，如Hessian、HTTP、RMI、Memcached、Redis、Thrift等等。由于Dubbo将这些协议的实现进行了封装了，无论是服务端（开发服务）还是客户端（调用服务），都不需要关心协议的细节，只需要在配置中指定使用的协议即可，从而保证了服务提供方与服务消费方之间的透明。 另外，如果我们使用Dubbo的服务注册中心组件，这样服务提供方将服务发布到注册的中心，只是将服务的名称暴露给外部，而服务消费方只需要知道注册中心和服务提供方提供的服务名称，就能够透明地调用服务，后面我们会看到具体提供服务和消费服务的配置内容，使得双方之间交互的透明化。 示例场景 我们给出一个示例的应用场景： 服务方提供一个搜索服务，对服务方来说，它基于SolrCloud构建了搜索服务，包含两个集群，ZooKeeper集群和Solr集群，然后在前端通过Nginx来进行反向代理，达到负载均衡的目的。 服务消费方就是调用服务进行查询，给出查询条件（满足Solr的REST-like接口）。 应用设计 基于上面的示例场景，我们打算使用ZooKeeper集群作为服务注
Hadoop Streaming原理及实践
Hadoop Streaming提供了一个便于进行MapReduce编程的工具包，使用它可以基于一些可执行命令、脚本语言或其他编程语言来实现Mapper和 Reducer，从而充分利用Hadoop并行计算框架的优势和能力，来处理大数据。需要注意的是，Streaming方式是基于Unix系统的标准输入输出来进行MapReduce Job的运行，它区别与Pipes的地方主要是通信协议，Pipes使用的是Socket通信，是对使用C++语言来实现MapReduce Job并通过Socket通信来与Hadopp平台通信，完成Job的执行。任何支持标准输入输出特性的编程语言都可以使用Streaming方式来实现MapReduce Job，基本原理就是输入从Unix系统标准输入，输出使用Unix系统的标准输出。 Hadoop是使用Java语言编写的，所以最直接的方式的就是使用Java语言来实现Mapper和Reducer，然后配置MapReduce Job，提交到集群计算环境来完成计算。但是很多开发者可能对Java并不熟悉，而是对一些具有脚本特性的语言，如C++、Shell、Python、 Ruby、PHP、Perl有实际开发经验，Hadoop Streaming为这一类开发者提供了使用Hadoop集群来进行处理数据的工具，即工具包
Dubbo架构设计详解
Dubbo是Alibaba开源的分布式服务框架，它最大的特点是按照分层的方式来架构，使用这种方式可以使各个层之间解耦合（或者最大限度地松耦合）。从服务模型的角度来看，Dubbo采用的是一种非常简单的模型，要么是提供方提供服务，要么是消费方消费服务，所以基于这一点可以抽象出服务提供方（Provider）和服务消费方（Consumer）两个角色。关于注册中心、协议支持、服务监控等内容，详见后面描述。 总体架构 Dubbo的总体架构，如图所示： Dubbo框架设计一共划分了10个层，而最上面的Service层是留给实际想要使用Dubbo开发分布式服务的开发者实现业务逻辑的接口层。图中左边淡蓝背景的为服务消费方使用的接口，右边淡绿色背景的为服务提供方使用的接口， 位于中轴线上的为双方都用到的接口。 下面，结合Dubbo官方文档，我们分别理解一下框架分层架构中，各个层次的设计要点： 服务接口层（Service）：该层是与实际业务逻辑相关的，根据服务提供方和服务消费方的业务设计对应的接口和实现。 配置层（Config）：对外配置接口，以ServiceConfig和ReferenceConfig为中心，可