Hive是基于Hadoop平台的，它提供了类似SQL一样的查询语言HQL。有了Hive，如果使用过SQL语言，并且不理解Hadoop MapReduce运行原理，也就无法通过编程来实现MR，但是你仍然可以很容易地编写出特定查询分析的HQL语句，通过使用类似SQL的语法，将HQL查询语句提交Hive系统执行查询分析，最终Hive会帮你转换成底层Hadoop能够理解的MR Job。 对于最基本的HQL查询我们不再累述，这里主要说明Hive中进行统计分析时使用到的JOIN操作。在说明Hive JOIN之前，我们先简单说明一下，Hadoop执行MR Job的基本过程（运行机制），能更好的帮助我们理解HQL转换到底层的MR Job后是如何执行的。我们重点说明MapReduce执行过程中，从Map端到Reduce端这个过程（Shuffle）的执行情况，如图所示（来自《Hadoop: The Definitive Guide》）： 基本执行过程，描述如下： 一个InputSplit输入到map，会运行我们实现的Mapper的处理逻辑，对数据进行映射操作。 map输出时，会首先将输出中间结果写入到map自带的buffer中（buffer默认大小为100M，可以通过io.sort.mb配置）。 map自带的buffer使用容
按作者浏览文章: Yanjun
CentOS 6.4系统MySQL主从复制基本配置实践
对于MySQL数据库一般用途的主从复制，可以实现数据的备份（如果希望在主节点失效后，能够使从节点自动接管，就需要更加复杂的配置，这里暂时先不考虑），如果主节点出现硬件故障，数据库服务器可以直接手动切换成备份节点（从节点），继续提供服务。基本的主从复制配置起来非常容易，这里我们做个简单的记录总结。 我们选择两台服务器来进行MySQL的主从复制实践，一台m1作为主节点，另一台nn作为从节点。 两台机器上都需要安装MySQL数据库，如果想要卸掉默认安装的，可以执行如下命令： sudo rpm -e --nodeps mysql yum list | grep mysql 现在可以在CentOS 6.4上直接执行如下命令进行安装： sudo yum install -y mysql-server mysql mysql-deve 为root用户设置密码： mysqladmin -u root password 'shiyanjun' 然后可以直接通过MySQL客户端登录： mysql -u root -p 主节点配置 首先，考虑到数据库的安全，以及便于管理，我们需要在主节点m1上增加一个专用的复制用户，使得任意想要从主节点进行复制从节点都必须使用这个账号： CREATE USER repl
Hadoop-2.2.0集群安装配置实践
Hadoop 2.x和1.x已经大不相同了，应该说对于存储计算都更加通用了。Hadoop 2.x实现了用来管理集群资源的YARN框架，可以面向任何需要使用基于HDFS存储来计算的需要，当然MapReduce现在已经作为外围的插件式的计算框架，你可以根据需要开发或者选择合适的计算框架。目前，貌似对MapReduce支持还是比较好的，毕竟MapReduce框架已经还算成熟。其他一些基于YARN框架的标准也在开发中。 YARN框架的核心是资源的管理和分配调度，它比Hadoop 1.x中的资源分配的粒度更细了，也更加灵活了，它的前景应该不错。由于极大地灵活性，所以在使用过程中由于这些配置的灵活性，可能使用的难度也加大了一些。另外，我个人觉得，YARN毕竟还在发展之中，也有很多不成熟的地方，各种问题频频出现，资料也相对较少，官方文档有时更新也不是很及时，如果我选择做海量数据处理，可能YARN还不能满足生产环境的需要。如果完全使用MapReduce来做计算，还是选择相对更加成熟的Hadoop 1.x版本用于生产环境。 下面使用4台机器，操作系统为CentOS 6.4 64位，一台做主节点，另外三台做从节点，实践集
使用libsvm实现文本分类
文本分类，首先它是分类问题，应该对应着分类过程的两个重要的步骤，一个是使用训练数据集训练分类器，另一个就是使用测试数据集来评价分类器的分类精度。然而，作为文本分类，它还具有文本这样的约束，所以对于文本来说，需要额外的处理过程，我们结合使用libsvm从宏观上总结一下，基于libsvm实现文本分类实现的基本过程，如下所示： 选择文本训练数据集和测试数据集：训练集和测试集都是类标签已知的； 训练集文本预处理：这里主要包括分词、去停用词、建立词袋模型（倒排表）； 选择文本分类使用的特征向量（词向量）：最终的目标是使得最终选出的特征向量在多个类别之间具有一定的类别区分度，可以使用相关有效的技术去实现特征向量的选择，由于分词后得到大量的词，通过选择降维技术能很好地减少计算量，还能维持分类的精度； 输出libsvm支持的量化的训练样本集文件：类别名称、特征向量中每个词元素分别到数字编号的映射转换，以及基于类别和特征向量来量化文本训练集，能够满足使用libsvm训练所需要的数据格式； 测试数据集预处理：同样包括分词（需要和训练
聚类算法：K-means
K-means算法是很典型的基于距离的聚类算法，采用距离作为相似性的评价指标，即认为两个对象的距离越近，其相似度就越大。该算法认为簇是由距离靠近的对象组成的，因此把得到紧凑且独立的簇作为最终目标。 对于聚类问题，我们事先并不知道给定的一个训练数据集到底具有哪些类别（即没有指定类标签），而是根据需要设置指定个数类标签的数量（但不知道具体的类标签是什么），然后通过K-means算法将具有相同特征，或者基于一定规则认为某一些对象相似，与其它一些组明显的不同的数据聚集到一起，自然形成分组。之后，我们可以根据每一组的数据的特点，给定一个合适的类标签（当然，可能给出类标签对实际应用没有实际意义，例如可能我们就想看一下聚类得到的各个数据集的相似性）。 首先说明一个概念：质心（Centroid）。质心可以认为就是一个样本点，或者可以认为是数据集中的一个数据点P，它是具有相似性的一组数据的中心，即该组中每个数据点到P的距离都比到其他质心的距离近（与其他质心相似性比较低）。 k个初始类聚类质心（Centroid）的选取对聚类结果具有较大的影
Impala与HBase整合实践
我们知道，HBase是一个基于列的NoSQL数据库，它可以实现的数据的灵活存储。它本身是一个大表，在一些应用中，通过设计RowKey，可以实现对海量数据的快速存储和访问。但是，对于复杂的查询统计类需求，如果直接基于HBase API来实现，性能非常差，或者，可以通过实现MapReduce程序来进行查询分析，这也继承了MapReduce所具备的延迟性。 实现Impala与HBase整合，我们能够获得的好处有如下几个： 可以使用我们熟悉的SQL，像操作传统关系型数据库一样，很容易给出复杂查询、统计分析的SQL设计 Impala查询统计分析，比原生的MapReduce以及Hive的执行速度快很多 Impala与HBase整合，需要将HBase的RowKey和列映射到Impala的Table字段中。Impala使用Hive的Metastore来存储元数据信息，与Hive类似，在于HBase进行整合时，也是通过外部表（EXTERNAL）的方式来实现。 准备工作 首先，我们需要做如下准备工作： 安装配置Hadoop集群（http://www.cloudera.com/content/cloudera-content/cloudera-docs/CDH4/latest/CDH4-Installation-Guide/cdh4ig_topic_4_4.html） 安装配置HB
Cloudera Impala架构设计要点
我们知道，在实时性要求不是很高的应用场景中，比如，月度统计报表生成等，我们基于传统的Hadoop MapReduce来处理海量大数据（包括使用Hive），在各方面表现都还不错，只需要离线处理数据，然后存储结果即可。但是如果在一些实时性要求相对较高的应用场景中，哪怕处理时间能够在原有的基础有大幅度地减少，也能很好地提升用户体验。对于大数据的实时性要求，其实是相对的，比如，传统使用MapReduce计算框架处理PB级别的查询分析请求，可能耗时30分钟甚至更多，但是如果能够使这个延迟大大降低，如3分钟计算出结果，这是很令人震撼的。Impala就是基于这样的需求驱动而出现的。 Impala是Cloudera开发的一款用来进行大数据实时查询分析的开源工具，它能够实现通过我们熟悉的传统关系数据库的SQL风格来操作大数据，数据可以是存储到HDFS或HBase中的。 下面，我们从不同的角度来认识和理解Cloudera Impala： 设计目标 官网给出的介绍是，使用Impala来实现SQL on Hadoop，实现对海量数据的实时查询分析，它的优势有如下几点： 快速 可以方便地执行SQL语句，在数秒内返回
基于C#+Thrift操作HBase实践
在基于HBase数据库的开发中，对应Java语言来说，可以直接使用HBase的原生API来操作HBase表数据，当然你要是不嫌麻烦可以使用Thrift客户端Java API，这里有我曾经使用过的 HBase Thrift客户端Java API实践，可以参考。对于具有其他编程语言背景的开发人员，为了获取HBase带来的好处，那么就可以选择使用HBase Thrift客户端对应编程语言的API，来实现与HBase的交互。 这里，我们使用C#客户端来操作HBase。HBase的Thrift接口的定义，可以通过链接http://svn.apache.org/viewvc/hbase/trunk/hbase-server/src/main/resources/org/apache/hadoop/hbase/thrift/Hbase.thrift?view=markup看到，我们需要安装Thrift编译器，才能生成HBase跨语言的API，这里，我使用的版本是0.9.0。需要注意的是，一定要保证，安装了某个版本Thrift的Thrift编译器，在导入对应语言库的时候，版本一定要统一，否则就会出现各种各样的问题，因为不同Thrift版本，对应编程语言的库API可能有变化。 首先，下载上面链接的内容，保存为Hbase.thrift。 然后，执行如下命令，生成C#编程语言的HBase Th
ZooKeeper应用案例
我们通过学习借鉴，哪些项目或应用都使用了ZooKeeper，可以了解我们的应用使用ZooKeeper是否能真正地带来价值，当然，有些项目可能也未必非常适合使用ZooKeeper，我们要批判地学习、借鉴和吸收。 下面是一些使用了ZooKeeper实现的案例： HDFS HA(QJM) Hadoop 2.x之前的版本，HDFS集群中Namenode是整个集群的中央元数据存储和服务节点，它存在SPOF的问题。在2.x版本中，提出了各种HA方案，避免Namenode的SPOF问题，其中基于QJM（Quorum Journal Manager）的方案可以解决这个问题：使用QJM的方案中，HDFS集群中存在两类节点，一类是Namenode节点（包括Active状态的Namenode，和Standby状态的Namenode），另一类是JournalNode，进行容错。当Active状态的Namenode元数据发生改变时，通过JournalNode进程（ZooKeeper集群中）来监视这种变化，然后同步到Standby状态的Namenode节点（实际上同步的是EditLog镜像文件内容的变更）。 当Active状态的节点发生故障后，Standby节点的Namenode自动切换，并接管HDFS集群中Active状态Namenode的服务，用来向客户端提供元数据服务。
ZooKeeper架构设计及其应用要点
ZooKeeper是一个开源的分布式服务框架，它是Apache Hadoop项目的一个子项目，主要用来解决分布式应用场景中存在的一些问题，如：统一命名服务、状态同步服务、集群管理、分布式应用配置管理等，它支持Standalone模式和分布式模式，在分布式模式下，能够为分布式应用提供高性能和可靠地协调服务，而且使用ZooKeeper可以大大简化分布式协调服务的实现，为开发分布式应用极大地降低了成本。 总体架构 ZooKeeper分布式协调服务框架的总体架构，如图所示： ZooKeeper集群由一组Server节点组成，这一组Server节点中存在一个角色为Leader的节点，其他节点都为Follower。当客户端Client连接到ZooKeeper集群，并且执行写请求时，这些请求会被发送到Leader节点上，然后Leader节点上数据变更会同步到集群中其他的Follower节点。 Leader节点在接收到数据变更请求后，首先将变更写入本地磁盘，以作恢复之用。当所有的写请求持久化到磁盘以后，才会将变更应用到内存中。 ZooKeeper使用了一种自定义的原子消息协议，在消息层的这种原子特性，保证了整个协调系统中的节点数据或状态
ZooKeeper-3.3.4集群安装配置
ZooKeeper是一个分布式开源框架，提供了协调分布式应用的基本服务，它向外部应用暴露一组通用服务——分布式同步（Distributed Synchronization）、命名服务（Naming Service）、集群维护（Group Maintenance）等，简化分布式应用协调及其管理的难度，提供高性能的分布式服务。ZooKeeper本身可以以Standalone模式安装运行，不过它的长处在于通过分布式ZooKeeper集群（一个Leader，多个Follower），基于一定的策略来保证ZooKeeper集群的稳定性和可用性，从而实现分布式应用的可靠性。 有关ZooKeeper的介绍，网上很多，也可以参考文章后面，我整理的一些相关链接。 ZooKeeper的安装配置还算比较容易的，下面，我们简单说明一下ZooKeeper的配置。 ZooKeeper Standalone模式 从Apache网站上（zookeeper.apache.org）下载ZooKeeper软件包，我选择了3.3.4版本的（zookeeper-3.3.4.tar.gz），在一台Linux机器上安装非常容易，只需要解压缩后，简单配置一下即可以启动ZooKeeper服务器进程。 将zookeeper-3.3.4/conf目录下面的 zoo_sample.cfg修改为zoo.cfg，配置文件内容如下
基于Thrift实现跨语言服务
假设，现在我们有这样一个需求： 要通过一个代理平台，将查询请求转发到后端服务器进行查询。后端存在多种查询服务器，查询方式也不同，比如，有基于SQL的关系数据库查询，也有基于搜索引擎Solr的查询。通过代理平台，将 服务暴露给具有任何编程语言技能的开发人员进行调用。 我们可以选择Thrift来定义语言中性的服务接口，然后通过Thrift编译器将定义生成多种编程语言的客户端代码框架，服务器端使用指定语言进行开发，如Java，最后通过连接Thrift服务器来进行查 询调用。 根据我们的需求，后端服务使用Java实现，而外部使用C#进行调用返回结果，再执行进一步的处理。 Thrift服务定义 首先，看一下，我们给出的示例服务定义，文件命名为queryproxy.thrift，内容如下所示： namespace java org.shirdrn.queryproxy.thrift.protocol namespace csharp Query.Proxy.Thrift.Protocol namespace py queryproxy.thrift.protocol typedef i16 short typedef i32 int typedef i64 long enum QueryType { SOLR = 1, SQL = 2 } struct QueryPara