随着系统中用户数据量的线性增长，数据量将会越来越多。在这样一个数据不断膨胀的环境中，数据已经如洪水般汹涌泛滥。数据查找和调用困难，在海量数据中一些用户提交的请求往往要等到第二天才能得知结果，直接影响到了用户满意度的提升和新业务的布局。在技术上而言，这一特点使得RDBMS在大型应用场景被大幅限制，唯一的可选方案是Scale Out,通过增加多个逻辑单元的资源,并使它们如同一个集中的资源那样提供服务来实现系统的扩展性。

   系统中的数据就好比我们家里的物品，衣服放在衣柜里，碟子放在碗橱里，数据库、存储系统就好比你的衣柜和碗橱是一个存放的容器，衣服和碟子就好比不同的数据，将不同类型的东西放入合适的存储空间里面，这样系统的效率和利用率将会更高，所以我们将会做出如下设计，如图所示：

查看大图请点击这里

对于大型系统存储单元的结构模型我们分为6个部分组成，清单如下：

1. 业务数据层
各类业务所产生的各种文件类型的数据，其中包含 用户信息、用户操作记录、实时业务数据、手机客户端升级应用程序、图片，等。

2. 计算层
针对不同的数据格式、不同类型的数据文件，通过不同的工具、计算方法进行操作，针对大量的数据计算采用一些分布式、并行计算的算法，例如：MapReduce，BSP。并且对一部分的数据进行缓存，缓解对存储应用服务器的压力。

3. 数据存储层
对于海量数据的查询与存储，特别是针对用户行为日志操作，需要使用到一些列式数据库服务器，对于处理业务和一些业务规则的数据依然存放在关系型数据库中，将采用MySQL来存储。

4. 数据仓储
数据存储主要是针对于用户行为日志和用户行为分析，也是系统中数据量产生较大的一个环节，将会采用Apache Hive、Pig、Mathout 对数据仓储进行构建。

5. 数据备份
分为在线数据备份和离线数据备份，数据备份环节需要经过运维经验的积累，根据业务和用户访问量进行定制合理的备份规律。

6. 硬件
硬件环境是存储单元最基础的部分，分为磁盘、内存、网络设备存储，将不同的业务数据、文件存储在不同的硬件设备上。

技术实现
对于系统不同的业务数据和应用服务器的架构需要采用不同的读写方式，以及数据存储类型存放，数据仓储构建，数据冷热分离、数据索引多个部分组成。例如：业务应用程序、日志采集代理、用户空间文件系统（Filesystem in Userspace）。Data Access Proxy Layer(DDAL/Cache Handler)、OLAP、日志服务器、Oracle(暂定)、MySQL、Redis、Hive、HDFS、Moosefs。

如图所示：

查看大图请点击这里

针对以上设计架构，描述清单如下：

1. Data Access Proxy Layer
统称数据访问代理层(简称 DAPL)，封装了DDAL和Cache Handler层，抽象的对编写的应用程序进行了划分，便于扩展和维护，例如：需要对HDFS或者图形数据库操作，上层不需要知道HDFS具体操作，只需要关注提供的接口。DAPL封装了很多访问各种数据源的读写策略。因此，可以保证对不同数据库、数据源操作的事务完整性。

2. DDAL
统称分布式数据访问层(简称 DDAL)主要针对关系数据库的读写分离操作，需要做到读写分离，首先需要对传入的SQL语句进行解析，并且采用Round-Robin算法负载分载对数据大量读取的操作，在代码实现中将使用MySQL-JDBC中的参数配置实现对MySQL-Slave的读取压力分载。

3. Cache Handler
与DDAL的相似，具体区别在于自己实现了Round-Robin算法负载分载对数据大量读取的操作，并且能在Redis Master当机的状态下重新指派新的Master进行写的操作。

4. Redis一主多从
对缓存数据进行读写分离，减少单台机器的I/O瓶颈，值得一提的是Cache不是可靠的存储，所以在设计时，需要容许Cache的数据丢失，因此，Cache的数据全部失效时，会从数据库里重新装载。

5. MySQL双主多从
这种方式是MySQL架构设计中最折中的方案，对数据的访问压力分载和数据的可靠性都有了相应的保障。前端2台Master MySQL相互进行数据备份，后端大量的Slave MySQL对Master写入的数据进行同步，所以每台机器节点上的MySQL数据库中的数据都是一致的，并且DDAL应用程序将数据轮询写入Master MySQL数据库中。

6. 数据库读写分离
主要采用mysql的策略，学习MySQL-Prxoy的策略，自己开发对MySQL书籍节点进行读写分离的方法，MySQL驱动支持读写分离的数据完整性，当数据量超大规模的时候将会采用Sharding策略。

7. 缓存读写分离
缓存Redis的策略，采用自己开发的应用程序需要实现Round Robin算法，对Redis Master和Slave缓存集群进行读写分离操作。

8. ETL Tools
采用Apache Hadoop项目中的Pig对海量的行为数据进行清洗，Pig可以针对有规律的半结构化数据执行类似SQL的脚本，并且可以将计算压力分载到每台服务器上进行分布式、并行处理。

9. Hive集群
针对数据仓库的建设由Apache Hive进行构建，是一个建立在Hadoop上的数据仓库框架，它提供了一个方便的数据集成方法和类似SQL的Hive QL查询语言，实现了Map/Reduce算法支持在Hadoop框架上进行大规模数据分析。

10. HDFS分布式文件系统
Hive中的数据全部存储在Hadoop分布式文件系统中，所有被存储的数据都会有数据的存储副本，这样对数据的可靠性有了保障。

11. Moosefs分布式文件系统
与上面提到的HDFS一个文件系统是有区别的，Moosefs不需要任何客户端程序对分布式文件进行操作的服务器，可以直接与任何运行环境进行对接，而且服务端也有副本复制的功能。

12. 冷热数据分离
将系统中产生的进行归类存放，将用户更多关心、热门话题等内容 抽象为“最近几天”的“热数据”，而越早的数据我们在设计中抽象的分为“冷数据”。由此可见，“热节点”存放最新的、被访问频率较高的数据。对于这部分数据，我们希望能给用户提供尽可能快的查询速度，因此无论在硬件还是软件的选择上都会有了明显的区分，例如：最近常访问频率高的数据将会存储在系统缓存中，需要经常性被的业务数据将会存储在MySQL或者Oracle数据库系统中，

1. 传输层
大量用户对系统请求后，将会造成网络带宽和Web服务器的I/O瓶颈。

2. 计算层
接收大量用户请求进行计算，将会造成业务服务器和业务支撑服务器的瓶颈。

3. 存储层
传输层和计算层将会产生大量的数据，数据量暴增，将会导致数据库和储存上的瓶颈。

针对以上将会造成的系统高并发瓶颈，我们需要采用不同的技术手段解决。

从总体上来看
1.首先需要解决网络带宽和Web请求的高并发，需要合理的加大服务器和带宽的投入，并且需要充分的利用系统中软件、硬件的缓存机制，将能缓存的内容都进行缓存存储，减少计算层和存储层的压力。

2.其次需要对业务服务器和业务支撑服务器进行合理的分层，并且采用并行计算和分布式算法对大量计算进行处理，并且在开发的过程中需要采用Java SDK中并发包(Concurrency)进行编码实现。

3.存储层需要采用分布式文件服务器和列式的存储服务器进行构建，支撑海量数据的存放和读取，并且还要对关系型数据进行深层次的配置参数优化。

4.我们还需要清楚的认识到，将来根据系统运行的状态以及平台中不同的业务场景循序渐进的进行调整和优化。

   对于大型系统来说，采用的技术是涉及面非常广，从硬件到软件、编程语言、数据库、WebServer、防火墙等各个领域都有了很高的要求。在面对大量用户访问、高并发请求方面，基本的解决方案集中在这样几个环节：将会使用高性能的服务器、高性能的数据库、高效率的编程语言、还有高性能的Web容器。

   但是除了这几个方面，还没法根本解决面临的高负载和高并发问题，所以需要将计算和负载的压力分载到每个计算机上，使用不同的服务器集群机组进行分布式和并行计算，面对所产生的压力，下面这张图清晰的描述了，我们对系统中不同的计算瓶颈采用的不同解决手段，如图所示：

查看大图请点击这里

 

以下描述是针对不同层面产生的计算压力所采用的计算策略，清单如下：

传输层

1. CDN

    网络链路出口进行压力分载，通过CDN让用户访问最近的数据缓存。

2. 智能双路

    针对电信、网通 不同的访问用户访问请求，对应用户访问请求进行服务器带宽的智能切换。

3. LVS

    对用户的请求进行压力分载，并且实现多种负载均衡的策略，也可以选择使用HA-Proxy实现。

4. HA-Proxy

   针对Web服务器进行方向代理，通过HA-Proxy将用户的请求分发到不同的Web服务器上。

5. Long-Polling

    在Web服务器上采用的一种策略，专门针对某个用户需要不断频繁的轮询访问。

6. Session2Cache

    将用户的会话进行集中处理，存放在中央式的缓存服务器当中，减少服务器之间的会话通信

 

计算层

1. MapReduce

   采用最经典的分布式算法对海量数据进行处理，将计算进行分载。

2. BSP

    BSP(Bulk Synchronous Parallel-大型同步模型)算法是基于MPI算法的基础进行演化，运用在系统中并行计算的部分。

3. Result Cache

    将计算的一部分结果进行缓存，缓解对存储层读取的请求。

4. Scatter/Gather

    中间通过一个服务器进行中转，将大量的请求分发给内部的服务器进行计算，类似前端的web反向代理。

 

存储层

1. 读写分离

    由于系统的读大于写的频率，数据库架构采用了1主/多从，双主多从的策略，所以我们将会将读和写进行分离，并且将大量的读请求分散给多台不同的(Slave)服务器。

2. 分区策略

    系统采用不同的时间段作为分区的主要策略，提高对数据的读写性能。

3. Sharding

    一台数据库将很快无法满足大量并发，需要使用库表散列，将数据库中的数据进行分散存储。

4. Column-Based

   使用在海量数据中的查询功能，采用列模式的存储方式将可以有效的提高系统查询效率。

 

 

–end–

 

 

 

   有些时候, 生活会拿起一块砖头向你的脑袋上猛拍一下。不要失去信心。我很清楚唯一使我一直走下去的，就是我做的事情令我无比钟爱。你需要去找到你所爱的东西。对于工作是如此, 对于你的爱人也是如此。你的工作将会占据生活中很大的一部分。你只有相信自己所做的是伟大的工作, 你才能怡然自得。如果你现在还没有找到, 那么继续找、不要停下来、全心全意的去找, 当你找到的时候你就会知道的。就像任何真诚的关系, 随着岁月的流逝只会越来越紧密。所以继续找，直到你找到它，不要停下来！

–end—

    在一个推荐系统中可以分析用户的行为，在后台对用户行为数据建模，经过分析去预测用户的喜好、向用户推荐。这里讲的动态，是因为用户的行为是跟时间有关系的，系统中包含了大量和时间有关的数据集合。现实社会是处于变化之中的，用户的喜好也在不断的变化着。
   系统中每天都会有大量的新用户，新的商品加入，按照时间段划分，一个用户在不同的时间段、不同的季节喜好的商品也会有所不同，一个好的智能推荐系统要满足以下两点：1.向用户推荐他们喜欢的内容；2.能够为内容服务提供商提升节目访问量。

     推荐系统的用户界面设计在推荐系统中占有非常重要的作用，好的用户界面设计能够收集到更多，更明确的用户反馈，这对提高后面推荐引擎的准确性有至关重要的作用。日志系统在推荐系统中也有很重要的作用，在很多大流量的网站中，日志系统需要同时满足两方面的需求，一方面需要能够实时的将用户最新的行为写入到数据库中，另一方面需要能够快速的处理大量的数据存储。

     完整的推荐引擎包括离线系统和在线系统两部分。在线系统负责实时响应用户的请求，在线提取和分析用户行为并生成最终推荐结果。离线系统主要负责生成各种用户兴趣模型，视频相关度矩阵，存储在数据库中，供在线系统实时查询和调用。如下图：

协同过滤推荐算法(Collaborative filtering—CF)在推荐系统中是一个非常的组件，其中包含2种  :
   a.基于用户的(User-based-CF):此种算法假定用户更倾向于那些和他具有相同爱好的人喜欢的节目，
   b.基于内容的(Item-based-CF):此种算法假定用户更倾向于以前对他有用的节目类别。此种算法被广泛应用，如Amazon、Netflix。
这种算法有两个优势：1.适用于用户数远多于节目数；2.能够很容易的根据用户行为历史数据推荐当前节目。

五个主要的组成部分
1.建立用户信息：用户第一次进入推荐系统，系统会为他们建立个人用户信息。包括用户的历史行为、主题（分类）以及从那些来自以前行为的信息。例如，他们可以选择观看录像，添加节目到我的最爱，搜索录像，投票给录像和节目。所有这些行为都会被系统纳入考虑范围，将这些行为提炼，然后用成熟的主题模型离线生成用户对主题的喜好表。

2.推荐的核心：在生成关于主题和节目的用户喜好列表以后，将那些相似的节目放在源推荐当中。

3.过滤：由于一些显而易见的原因，源推荐不能直接推荐给用户。对于那些用户已经看过或者正在浏览的视频，从源推荐当中去除，从而使源推荐更准确。

4.排序模块：排序模块重新排列源推荐的顺序来使它们更好的符合用户的喜好。首先，让源推荐更多变化，然后增加源推荐的新鲜度，让用户发现他们喜欢但以前没看过的节目。

5.推荐解释模块：此模块是每一个推荐系统最重要的组件，解释模块对利用用户历史行为而产生的推荐结果给出解答。

这里要特别对推荐解释模块说明一下：推荐解释有很多优点，它可以增加用户对推荐系统的信任。当用户看到一个不靠谱的推荐结果时，根据推荐解释他会知道这个推荐是怎么产生的（由他以前的什么行为产生的），这样用户就会知道，如果需要好的推荐，他应该怎样反馈给系统，整体结构如图所示：

推荐系统离线组件 
上面的在线组件有些模块是基于离线组件的。如主题模型、关系模型，反馈模型等。离线系统也是整个智能推荐系统中一个重要的部分。

1.数据中心：数据中心存储所有用户行为数据。一部分存在Handoop集群中，另一部分存在RMDBS中。

2.关系表生成器：关系表对于在线推荐组件来说是份重要的资源。主要用到两种类型的关系表：一种基于协同过滤（CF），另一种基于内容。在CF如果用户喜欢视频A也喜欢视频B，视频A和视频B会有着高相似度；内容过滤，使用一些基本信息如标题、描述、频道、公司、演员和标签等。

3.主题模型：一组具有相似内容的节目称为一个主题（类别）。他的范围比节目大，但是比频道范围小。也就是说是在一个频道下面的一组相似节目的集合。这里使用的是线性判别分析算法（LDA）。

4.反馈分析器：反馈特指用户对于推荐结果的反馈。利用用户反馈可以很好的提升推荐质量，比如一个节目推荐给了很多用户，却很少有用户点击，那么就要降低这个节目的排序，用户有各种各样的喜好，可以根据这些反馈制定更合理的推荐排序。然而，有些用户会更喜欢那些来自之前观看历史的推荐，一些用户更喜欢来自投票结果的推荐。所有这些影响可以通过分析用户在推荐上的反馈而离线生成模型。

5.报告生成模块：度量（评估）是推荐系统最重要的一部分。它每天对系统推荐质量评估并形成一个多维的报告。如点击率、转换率

    基于内容的协同过滤算法(ItemCF)使我们所有算法的基础。在CF中,定义N(u)是用户u以前较喜欢的节目的集合，那么用户对于节目i的偏好可以用以下公式衡量：

 其中r(u,j)表示用户u对节目j喜爱的度，s(i,j)是节目i和节目j之间的相似度。在CF中，两个节目之间的相似度是根据两个节目的用户行为数据计算出来的，定义N(i)是观看过i节目的用户集合,N(j)是观看过j节目的用户集合，这样节目i和节目j之间的相似度s(i,j)可以用下列公式计算：

    在这个定义中，如果多数用户看过节目i，同时也看过了节目j，那么节目i和节目j就会高度相关。但是，这个定义会出现哈利波特问题(Harry Potter Problem),即每一个节目都会和那些受欢迎的节目高度相关，原因是由于Harry Potter这本书很火，买了任何书的人都会买这本书，那么所有的书和这本书都会很相关，从而使得相似度的结果不够合理，缺乏说服力。

还有一些问题也是值得我们去考虑的，例如：
1.最近行为：
    我们从分桶测试中了解到，用户最近行为比以前的历史行为在系统推荐的分析上更重要。分析的时候要放更多的权重在上面。
    
2.最新鲜的：    一个推荐系统能够准确的预知用户的行为，并不代表它只是单纯的将一个节目推荐给在线用户。比如一部家喻户晓的电影并不需要系统去推荐，完全可以由用户去决定看或者不看。因此，新鲜度也是评价一个推荐系统的重要指标。提高新鲜度的一个方法是修改基于节目的协同过滤算法。首先，对于那些观众已经观赏过的热门的节目，要减少其比重。其次，不仅要增加那些和活跃观众以前观赏过的类似的节目的比例，还要增加热度不及活跃用户以前观赏过的节目。

3.基于解释的多样性：大多数的用户有着多种喜好，推荐系统应该去迎合他们不同的兴趣。在系统中，可以用解释器去多样化推荐系统。可以通过分桶测试（A/B test）展示多样化的有效性。实验结果表明，对于看过十部节目以上的活跃用户，多样化能够显著的增加推荐视频的点击率。

4.时空多样性： 一个好的推荐系统不应该只生成一些静态的推荐推荐。用户希望在每次登陆的时候看到一些新的推荐。比如一位用户有了新的行为（新爱好、新类型），他应该发现对他的推荐有了一些改变，就像前面所说，要把比较多的比重放在用户最近的行为上。但是如果用户最近没有新的动态，那么我们的推荐也应该有所更新和改变。可以用一下几个方法保持推荐系统的时空多样性，例如：将每天最新的节目推荐给用户，这样用户每天能够看到最新的东西，总有部分用户会喜欢。随机的将节目推荐给用户，这是保持推荐更新的最简单的方法。最后，降低那些被用户点击或观赏了很多次的推荐的排名，我们称这为隐式反馈，数据表明，此方法使点击率上升了10%。

在Hulu.com中有一个Recommendation Hub的东东，其实就是系统给每个用户的个人推荐页面。系统认为的用户最喜欢的节目。最顶端的下面有三中不同类型的推荐，这些推荐是分析用户历史行为获得的。用户之前标注过以后希望观看（类似于收藏夹），最后一条传送带是用户已经评分过的视频，这条传送带是用来显式的收集用户的反馈。下面的图是Hulu.com进行的分桶测试结果，经验表明推荐系统使用的算法的点击率远远高于常见的普通推荐算法：观看最多的和评分最高的。

下图是对于不同类型行为推荐的点击率。

    每一个用户的行为能够反映其喜好。我们用大量的用户行为生成我们的推荐，上图中每一种行为反馈的点击率都可以生成用户可能会点击的推荐来。(我们看到最近观看的点击率比较高，系统就可以根据最近观看的类型、标签推荐最有可能被用户点击的节目)。

由此看来，显式反馈的显式数据比隐式数据更重要。如上图，从用户行为历史上看，来自钟爱和喜欢的推荐点击率高于对用户以往订阅/观看/搜索的推荐点击率。虽然显式反馈的数据量要小于隐式反馈，但是实际上它却是重要的多。用户最近的行为比以前的行为重要。新鲜度、多样性和离线精度都是重要的因素。大多数的研究人员聚焦在离线精度，如均方根误差、精度/检索。然而，能够准确预测用户某一单独行为的推荐系统可能不足以满足实际应用，一个优秀的推荐系统应该将多种因素结合在一起考虑。Hulu系统结合了新鲜度和多样性后，点击率提高了超过10%。

总结

1.直观的数据库排序：
   根据用户评价、或者点击率，这也是上面所说的两种最传统的方式。

2.浏览了该商品的用户浏览的其他商品
   延伸——浏览此商品的用户最终购买了商品的比例和购买本商品的比例，记录用户的行为，加入多样性的考虑

3.用推荐算法
    a.协同过滤：找到一个用户最感兴趣商品，方法是分析和此用户具有相同喜好的用户对什么最感兴趣。
    b.关联过滤：购买商品集X的用户有多少购买了商品集Y。

4.基于内容推荐：
   用到了决策树算法，比较各子树的权重，实现有难度！

一个好的推荐系统，有简洁而重要的内容，有推荐理由，而且推荐理由还具有多样性。同时还给出了用户反馈的方式方法，节目产品的推荐可以和广告结合在一起。不光要满足用户的需要，还要满足节目发布者、广告投放商的需要，同时推荐反馈的数据能够对系统有利，推动系统良性的发展。

–end–

攻城师们，你有没有想过这些应用背后的技术实现呢？手机端获得当前的坐标后是怎么进行计算和查询返回附件的结果呢？

用Java程序可以实现Dijkstra算法获得点与多点之间最短路径的计算结果，但是我个人认为是一种暴力的方法，开发的简化程度和计算的执行效率不会非常高。
参考资料：http://baike.baidu.com/view/7839.htm

接着再往下想，用到数据库技术是必然，但不会把节点的坐标信息存储到数据库普通的字段中进行查询，如果和Dijkstra算法相比不会简化工作量也不会提高性能，但使用到MySQL中空间数据库的概念就会简化很多也会得到性能的提升，开源的MySQL Spatial空间索引机制就可以对点到多点之间的距离计算，类似的Spatial Database还有，PostGIS，SpatiaLite。

我的废话：
在android手机上获得当前坐标后，将数据整好录入android中的SQLite数据库也可以获得当前点对多点的最短路径，也就是说在地理数据不会更新的场景下完全可以采用android手机上的数据库完成这项工作，没有必要非要利用服务器端的Spatial Database完成最短路径的计算。

MySQL空间数据几种主要类型:
     – GEOMETRY  Geometry是层次结构的根类。它是一种非实例化类，但具有很多属性，这些属性对由任何Geometry子类创建的所有几何值来说是共同的。
     – POINT   代表坐标空间中单个位置的几何类，他的属性包含 X-坐标值，Y-坐标值。
     – LINESTRING  具有线段的坐标，由每个连续的点对(两点)定义。如果仅包含两点，LineString为Line。 如果它既是简单的也是封闭的，LineString为LinearRing。
     – POLYGON  它由单个外部边界以及0或多个内部边界定义，其中，每个内部边界定义为Polygon中的1个孔。例如:在地区地图上，Polygon对象可表示森林。
     – MULTIPOINT  MultiPoint是一种由Point元素构成的几何对象集合。这些点未以任何方式连接或排序。
     – MULTILINESTRING  MultiLineString是一种由 LineString元素构成的MultiCurve几何对象集合，例如：河流体系或高速路系统。
     – MULTIPOLYGON  MultiPolygon是一种由Polygon元素构成的几何对象集合。在地区地图上，MultiPolygon可表示湖泊系统。
     – GEOMETRYCOLLECTION   他是由1个或多个任意类几何对象构成的几何对象。GeometryCollection中的所有元素必须具有相同的空间参考系(即相同的坐标系).
以上几种的类型依赖关系，如图所示：

了解过上述一些基本知识，下面来创建一张商户表，并且包含定义的空间数据库的POINT字段：
  Create table shop (
     shop_id int(3) primary key,
     Location POINT,
     Shop_na vachar(100),
     Shop_info vachar(300)
     );

插入几条商家的门店信息，其中采用GeomFromText方法将坐标的数据库插入POINT字段中，例如：
insert into shop values (‘XXX’,’,GeomFromText(‘POINT(1 1)’),’XX店’,’ '其他信息');
下面将根据客户当前所在位置在MySQL中查询，搜索出在当前位置附近的一定范围内的门店，并且可以做到按距离由近到远排列显示出来，从让用户而找到离他最近的门店。
把客户当前所在位置可设成变量 ，例如:set @center=GeomFromText(‘POINT(10 10)’)；

再把要找到最近门店可以缩小搜索范围 设半径，添加搜索条件
例：set @radius=30;
WHERE SQRT(POW( ABS( X(location) – X(@center)), 2) + POW( ABS(Y(location) – Y(@center)), 2 )) < @radius

最近门店搜索，完整的SQL示例：
SELECT shop_id,shop_na, SQRT(POW( ABS( X(Location) – X(@center)), 2) + POW(ABS(Y(Location) – Y(@center)), 2 )) AS distance
FROM shop WHERE SQRT(POW( ABS( X(location) – X(@center)), 2) + POW( ABS(Y(location) – Y(@center)), 2 )) < @radius
order by distance;

其中涉及的数学函数SQRT(x)：表示求一个数x的平方根。POW(x,y):包含两个参数表示求x的y次幂。ABS(x)：表示求数X的绝对值。整个SQRT(POW( ABS( X(Location) – X(@center)), 2) + POW(ABS(Y(Location) – Y(@center)), 2 ))这个SQL语句实现的是一个算术表达式

即两点间的直线距离。
比如说现在有两个点坐标A(x1,y1)，B(x2,y2) 要求线段AB长度 就是用这个公式去计算。把A看成当前位置B看成一个门店，不就是相当于计算当前位置到门店这两个点的距离吗。坐标点有了带进去就行，等于现在只要能用函数把这个公式表示出来就可以了。
所以用到这三个函数：
SQRT(x)：表示求一个数x的平方根。就相当于那个根号。√x
POW(x,y):包含两个参数表示求x的y次幂
例如pow(2,3)就表示23，那么POW((X1-X2),2)就相当于〖（x1-x2）〗^2
ABS(x)：表示求数X的绝对值。|x|  ABS(x1-x2)就等于|x1-x2|.

根据那个公式组合起来就行了
整个SQRT(POW( ABS( X(Location) – X(@center)), 2) + POW(ABS(Y(Location) – Y(@center)), 2))这句话就是用来表示这个公式的
,
这个公式计算得出来的值就是两点间的直线距离。

参考资料：
http://dev.mysql.com/doc/refman/5.1/zh/spatial-extensions-in-mysql.html
http://en.wikipedia.org/wiki/Spatial_database

口水：
 以上部分内容来自 NJ-AMT 实习生余珊的分析报告。

–end–

在最近的技术大会中我们更多的目光都聚焦在这些大型网站，其实中小型门户网站的技术体系也是值得去探讨和关注。全天下的攻城师们并不是都在为这些大型门户网站服务，更多的攻城师们正在默默无闻的为一些刚刚起步的中小型网站服务，而且占据了攻城师队伍中的60%以上的人群。在关注大型门户网站的时候，中小型门户网站的技术发展和实战经验更值得去分享。

无论大型门户网站还是中小型垂直类型网站都会对稳定性、性能和可伸缩性有所追求。大型网站的技术经验分享值得我们去学习和借用，但落实到更具体的实践上并不是对所有网站可以适用,其他语言开发的网站我还不敢多说，但Java开发的系统，我还是能您给插上几句话：

JVM
JEE容器中运行的JVM参数配置参数的正确使用直接关系到整个系统的性能和处理能力，JVM的调优主要是对内存管理方面的调优，优化的方向分为以下4点：
1.HeapSize             堆的大小，也可以说Java虚拟机使用内存的策略，这点是非常关键的。
2.GarbageCollector  通过配置相关的参数进行Java中的垃圾收集器的4个算法(策略)进行使用。
3.StackSize             栈是JVM的内存指令区,每个线程都有他自己的Stack，Stack的大小限制着线程的数量。
4.DeBug/Log           在JVM中还可以设置对JVM运行时的日志和JVM挂掉后的日志输出，这点非常的关键，根据各类JVM的日志输出才能配置合适的参数。
网上随处可见JVM的配置技巧，但是我还是推荐阅读Sun官方的2篇文章，可以对配置参数的其所依然有一个了解
1.Java HotSpot VM Options http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html
2.Troubleshooting Guide for Java SE 6 with HotSpot VM http://www.oracle.com/technetwork/java/javase/index-137495.html
另外，我相信不是每个人攻城师都是天天对着这些JVM参数的，如果你忘记了那些关键的参数你可以输入Java -X(大写X)进行提示。

JDBC
针对MySQL的JDBC的参数在之前的文章中也有介绍过，在单台机器或者集群的环境下合理的使用JDBC中的配置参数对操作数据库也有很大的影响。
一些所谓高性能的 Java ORM开源框架也就是打开了很多JDBC中的默认参数：
 1.例如：autoReconnect、prepStmtCacheSize、cachePrepStmts、useNewIO、blobSendChunkSize 等，
 2.例如集群环境下：roundRobinLoadBalance、failOverReadOnly、autoReconnectForPools、secondsBeforeRetryMaster。
具体内容可以参阅MySQL的JDBC官方使用手册：
http://dev.mysql.com/doc/refman/5.1/zh/connectors.html#cj-jdbc-reference

数据库连接池(DataSource)
应用程序与数据库连接频繁的交互会给系统带来瓶颈和大量的开销会影响到系统的性能，JDBC连接池负责分配、管理和释放数据库连接，它允许应用程序重复使用一个现有的数据库连接，而再不是重新建立一个连接，因此应用程序不需要频繁的与数据库开关连接，并且可以释放空闲时间超过最大空闲时间的数据库连接来避免因为没有释放数据库连接而引起的数据库连接遗漏。这项技术能明显提高对数据库操作的性能。
在此我认为有一点需要说明：
连接池的使用也是需要关闭，因为在数据库连接池启动的时候就预先和数据库获得了相应的连接，之后不再需要应用程序直接的和数据库打交道，因为应用程序使用数据库连接池是一个“借”的概念，应用程序从数据库连接池中获得资源是“借出”，还需要还回去，就好比有20个水桶放在这里，需要拿水的人都可以使用这些木桶从水池里面拿水，如果20个人都拿完水，不将水桶还回原地，那么后面来的人再需要拿水，只能在旁边等待有人将木桶还回去，之前的人用完后需要放回去，不然后面的人就会一直等待，造成资源堵塞，同理，应用程序获取数据库连接的时候Connection连接对象的时候是从“池”中分配一个数据库连接出去，在使用完毕后，归还这个数据库连接，这样才能保持数据库的连接“有借有还”准则。
参考资料：
http://dev.mysql.com/doc/refman/5.1/zh/connectors.html#cj-connection-pooling

数据存取
数据库服务器的优化和数据的存取，什么类型的数据放在什么地方更好是值得去思考的问题，将来的存储很可能是混用的，Cache，NOSQL，DFS，DataBase 在一个系统中都会有，生活的餐具和平日里穿衣服需要摆放在家里，但是不会用同一种类型的家具存放，貌似没有那个人家把餐具和衣服放在同一个柜子里面的。这就像是系统中不同类型的数据一样，对不同类型的数据需要使用合适的存储环境。文件和图片的存储，首先按照访问的热度分类，或者按照文件的大小。强关系类型并且需要事务支持的采用传统的数据库，弱关系型不需要事务支持的可以考虑NOSQL，海量文件存储可以考虑一下支持网络存储的DFS，至于缓存要看你单个数据存储的大小和读写的比例。
还有一点值得注意就是数据读写分离，无论在DataBase还是NOSQL的环境中大部分都是读大于写，因此在设计时还需考虑 不仅仅需要让数据的读分散在多台机器上，还需要考虑多台机器之间的数据一致性，MySQL的一主多从，在加上MySQL-Proxy或者借用JDBC中的一些参数(roundRobinLoadBalance、failOverReadOnly、autoReconnectForPools、secondsBeforeRetryMaster)对后续应用程序开发，可以将读和写分离，将大量读的压力分散在多台机器上，并且还保证了数据的一致性。

缓存
在宏观上看缓存一般分为2种：本地缓存和分布式缓存
1.本地缓存，对于Java的本地缓存而言就是讲数据放入静态(static)的数据结合中，然后需要用的时候就从静态数据结合中拿出来,对于高并发的环境建议使用 ConcurrentHashMap或者CopyOnWriteArrayList作为本地缓存。缓存的使用更具体点说就是对系统内存的使用，使用多少内存的资源需要有一个适当比例，如果超过适当的使用存储访问，将会适得其反，导致整个系统的运行效率低下。
2. 分布式缓存，一般用于分布式的环境，将每台机器上的缓存进行集中化的存储，并且不仅仅用于缓存的使用范畴，还可以作为分布式系统数据同步/传输的一种手段，一般被使用最多的就是Memcached和Redis。
数据存储在不同的介质上读/写得到的效率是不同的，在系统中如何善用缓存，让你的数据更靠近cpu，下面有一张图你需要永远牢记在心里，来自Google的技术大牛Jeff Dean(Ref)的杰作，如图所示：

并发/多线程
在高并发环境下建议开发者使用JDK中自带的并发包(java.util.concurrent)，在JDK1.5以后使用java.util.concurrent下的工具类可以简化多线程开发，在java.util.concurrent的工具中主要分为以下几个主要部分：
1.线程池，线程池的接口(Executor、ExecutorService)与实现类(ThreadPoolExecutor、 ScheduledThreadPoolExecutor），利用jdk自带的线程池框架可以管理任务的排队和安排，并允许受控制的关闭。因为运行一个线程需要消耗系统CPU资源，而创建、结束一个线程也对系统CPU资源有开销，使用线程池不仅仅可以有效的管理多线程的使用，还是可以提高线程的运行效率。
2.本地队列，提供了高效的、可伸缩的、线程安全的非阻塞 FIFO 队列。java.util.concurrent 中的五个实现都支持扩展的 BlockingQueue 接口，该接口定义了 put 和 take 的阻塞版本：LinkedBlockingQueue、ArrayBlockingQueue、SynchronousQueue、PriorityBlockingQueue 和 DelayQueue。这些不同的类覆盖了生产者-使用者、消息传递、并行任务执行和相关并发设计的大多数常见使用的上下文。
3.同步器，四个类可协助实现常见的专用同步语句。Semaphore 是一个经典的并发工具。CountDownLatch 是一个极其简单但又极其常用的实用工具，用于在保持给定数目的信号、事件或条件前阻塞执行。CyclicBarrier 是一个可重置的多路同步点，在某些并行编程风格中很有用。Exchanger 允许两个线程在 collection 点交换对象，它在多流水线设计中是有用的。
4.并发包 Collection，此包还提供了设计用于多线程上下文中的 Collection 实现：ConcurrentHashMap、ConcurrentSkipListMap、ConcurrentSkipListSet、CopyOnWriteArrayList 和 CopyOnWriteArraySet。当期望许多线程访问一个给定 collection 时，ConcurrentHashMap 通常优于同步的 HashMap，ConcurrentSkipListMap 通常优于同步的 TreeMap。当期望的读数和遍历远远大于列表的更新数时，CopyOnWriteArrayList 优于同步的 ArrayList。

队列
关于队列可以分为：本地的队列 和 分布式队列 2类
本地队列：一般常见的用于非及时性的数据批量写入，可以将获取的数据缓存在一个数组中等达到一定数量的时候在进行批量的一次写入，可以使用BlockingQueue或者List/Map来实现。
相关资料：Sun Java API.
分布式队列：一般作为消息中间件，构建分布式环境下子系统与子系统之间通信的桥梁，JEE环境中使用最多的就是Apache的AvtiveMQ和Sun公司的OpenMQ。
轻量级的MQ中间件之前也向大家介绍过一些例如：Kestrel和Redis(Ref http://www.javabloger.com/article/mq-kestrel-redis-for-java.html)，最近又听说LinkedIn的搜索技术团队推出了一个MQ产品-kaukaf(Ref http://sna-projects.com/kafka )，对此保持关注。
相关资料：
1.ActiveMQ http://activemq.apache.org/getting-started.html
2.OpenMQ  http://mq.java.net/about.html
3.Kafka       http://sna-projects.com/kafka     
4.JMS文章  http://www.javabloger.com/article/category/jms

NIO
NIO是在JDK1.4后的版本中出现的，在Java 1.4之前，Jdk提供的都是面向流的I/O系统，例如读/写文件则是一次一个字节地处理数据，一个输入流产生一个字节的数据，一个输出流消费一个字节的数据， 面向流的I/O速度非常慢，并且一个数据包要么整个数据报已经收到，要么还没有。Java NIO非堵塞技术实际是采取Reactor模式，有内容进来会自动通知,不必死等、死循环，大大的提升了系统性能。在现实场景中NIO技术多数运用两个方面，1是文件的读写操作，2是网络上数据流的操作。在NIO中有几个核心对象需要掌握：1选择器(Selector)、2通道(Channel)、3缓冲区(Buffer)。
我的废话：
1.在Java NIO的技术范畴中内存映射文件是一种高效的做法，可以用于缓存中存储的冷/热数据分离，将缓存中的一部分冷数据进行这样的处理，这种做法上比常规的基于流或者基于通道的I/O快的多，通过使文件中的数据出现为内存数组的内容来完成的，将文件中实际读取或者写入的部分才会映射到内存中，并不是将整个文件读到内存中。
2.在Mysql的jdbc驱动中也可以使用NIO技术对数据库进行操作来提升系统的性能。

长连接/Servlet3.0
这里说的长连接就是长轮询，以前浏览器(客户端)需要关注服务器端发生的数据变化需要不断的访问服务器，这样客户端的数量一多必然会给服务器端造成很大的压力，例如：论坛中的站内消息。现在Servlet3.0规范中提供了一个新的特性：异步IO通信；该特性会保持一个长连接。利用Servlet3异步请求的这项技术可以大大的缓解服务器端的压力。
Servlet3.0的原理就是将request的请求开启一个线程挂起，中间设置等待超时的时间，如果后台事件触发request请求，得到的结果返回给客户端的request请求，如果在设置等待超时的时间内没有任何事件发生也将请求返回给客户端，客户端将再次发起request请求，客户端与服务器端的交互可以与此往复。
就好比，你先过来跟我说如果有人找你，我就立马通知你你来见他，原先你需要不断的问我有没有要找你，而不管有没有人找你，你都需要不断的问我有没有人找你，这样的话不论问的人还是被问的人都会累死。

日志
Log4J是通常被人们使用的工具，系统在刚刚上线的时候日志一般都设置在INFO的级，真正上线后一般设置在ERROR级，但无论在任何时候，日志的输入内容都是需要关注的，开发人员一般可以依靠输出的日志查找出现的问题或者依靠输出的日志对系统的性能进行优化，日志也是系统运行状态的报告和排错的依据。
简单来说日志按照定义的不同策略和等级输出到不同的环境，那样便于我们分析和管理。相反你没有策略的输出，那么机器一多，时间一长，会有一大推乱糟糟的日志，会让你排错的时候无从下手，所以日志的输出策略是使用日志的关键点。
参考资料：http://logging.apache.org/log4j/1.2/manual.html

打包/部署
在代码设计的时候最好能将不同类型的功能模块在IDE环境中粗粒度的分为不同的工程，便于打成不同jar包部署在不同的环境中。有这样的一个应用场景：需要每天定时远程从SP那边获得当天100条新闻和部分城市的天气预报，虽然每天的数据量不多，但是前端访问的并发量很大，显然需要在系统架构上做到读写分离。
如果把web工程和定时抓取的功能模块完全集中在一个工程里打包，将导致需要扩展的时候每台机器上既有web应用也有定时器，因为功能模块没有分开，每台机器上都有定时器工作将会造成数据库里面的数据重复。
如果开发的时候就将web和定时器分为2个工程，打包的时候就可以分开部署，10台web对应一台定期器，分解了前端请求的压力，数据的写入也不会重复。
这样做的另一个好处就是可以共用，在上述的场景中web和定时器都需要对数据库进行读取，那么web和定时器的工程里都有操作数据库的代码，在代码的逻辑上还是感觉乱乱的。如果再抽出一个DAL层的jar，web和定时器的应用模块开发者只需要引用DAL层的jar，开发相关的业务逻辑，面向接口编程，无需考虑具体的数据库操作，具体的对数据库操作由其他开发者完成，可以在开发任务分工上很明确，并且互不干涉。

框架
所谓流行的SSH(Struts/Spring/Hiberanet)轻量级框架,对于很多中小型项目而言一点都不轻量级，开发者不仅需要维护代码，还需要维护繁琐的xml配置文件，而且说不定某个配置文件写的不对就让整个都工程无法运行。无配置文件可以取代SSH(struts/Spring/Hiberanet)框架的产品真的太多了，我之前就向大家介绍过一些个产品(Ref)。
这个我并不是一味的反对使用SSH(Struts/Spring/Hiberanet)框架，在我眼里SSH框架真的作用是做到了规范开发，而并不使用了SSH(Struts/Spring/Hiberanet)框架能提高多少性能。
SSH框架只是对于非常大的项目人数上百人的团队，还需要、继续增加团队规模的公司而言，是需要选择一些市面上大家都认可，并且熟悉的技术，SSH(Struts/Spring/Hiberanet)框架比较成熟所以是首先产品。
但是对于一些小团队中间有个把技术高人的团队而言完全可以选择更加简洁的框架，真正的做到提速你的开发效率，早日抛弃SSH框架选择更简洁的技术在小团队开发中是一种比较明知的选择。

–end–

有这样一个场景：系统中有大约100w的用户，每个用户平均有3个邮箱账号，每隔5分钟，每个邮箱账需要收取100封邮件，最多3亿份邮件需要下载到服务器中(不含附件和正文)。用20台机器划分计算的压力，从多个不同的网路出口进行访问外网，计算的压力得到缓解，那么每台机器的计算压力也不会很大了。

通过我们的讨论和以往的经验判断在这场景中可以实现并行计算，但我们还期望能对并行计算的节点进行动态的添加/删除，做到在线更新并行计算的数目并且不会影响计算单元中的其他计算节点，但是有4个问题需要解决，否则会出现一些严重的问题：
1.20台机器同时工作时，有一台机器down掉了，其他机器怎么进行接管计算任务，否则有些用户的业务不会被处理，造成用户服务终断。
2.随着用户数量增加，添加机器是可以解决计算的瓶颈，但需要重启所有计算节点，如果需要，那么将会造成整个系统的不可用。
3.用户数量增加或者减少，计算节点中的机器会出现有的机器资源使用率繁忙，有的却空闲，因为计算节点不知道彼此的运行负载状态。
4.怎么去通知每个节点彼此的负载状态，怎么保证通知每个计算节点方式的可靠性和实时性。

先不说那么多专业名词，白话来说我们需要的是：1记录状态，2事件通知 ，3可靠稳定的中央调度器，4易上手、管理简单。
采用Zookeeper完全可以解决我们的问题，分布式计算中的协调员，观察者，分布式锁  都可以作为zookeeper的关键词，在系统中利用Zookeeper来处理事件通知,队列,优先队列,锁,共享锁等功能，利用这些特色在分布式计算中发挥重要的作用。

zookeeper的服务器端是采用Java编写，而zookeeper的客户端不仅可以支持java还可以支持C语言的客户端，在zookeeper服务端可以创建一个树状的Key/Vaule 存在着父子节点之间的关系。

Zookeeper允许多个Client对一个或多个ZNode数据进行监控，当ZNode有变化时能够通知到监控这个ZNode的各个Client，所有监听这个节点的成员都会知道了，Zookeeper使用Watcher察觉事件信息,当客户端接收到事件信息,比如连接超时,节点数据改变,子节点改变,可以调用相应的行为来处理业务逻辑。相反，如果zookeeper客户端对服务端的znode不关注，不Watcher，那么发生任何变化zookeeper的客户端都不会收到事件通知。

zookeeper中znode的数据模型

每次zookeeper客户端与服务器端连接后都会创建一个session ID 给客户端，客户端将会定期心跳协议到服务器端验证这个连接的有效性。如果由于某种原因，客户端无法发送心跳到服务器，将导致服务器验证过期的会话，会话ID将变为无效。客户持有的连接/对象将不可用，因此应用程序必须创建一个新的客户对象。如果zookeeper客户端连接到服务器没有任何响应，首先客户端会作抛出的异常并且被捕获，清除当前与Server相关的网络资源和连接会话，然后客户端逐个尝试配置列表中Server的连接地址，选择可用的服务器继续进行工作。

上述Zookeeper客户端和服务器端的关系又是一个典型的“观察者”模式，客户端关注自己关心的对象(znode)，一旦发送变化就立刻通知。在《Head First设计模式》中有这样的一张图来表达 观察者模式的。

如图所示，此系统中的三个部分是气象站(获取实际气象数据的物理装置)、WeatherData对象(追踪来自气象站的数据，并更新布告板)和布告板,再来看看百度百科对“观察者”模式的解释：http://baike.baidu.com/view/1854779.htm

通过对Zookeeper的了解，实现我们系统中需要的Failure detection和Load detection 功能，只需要在每个计算的节点中实现zookeeper客户端程序，计算节点关注zookeeper服务器上znode节点变化。可以在zookeeper服务器的znode上创建一个根节点/clusterA,下面根据计算节点机器名创建对应的子节点，子节点中的value就是这台计算节点的ip地址。
如：/clusterA/node1,/clusterA/node2,/clusterA/nodeN,这些节点都是临时节点(EPHEMERAL)，一旦连接断开，创建的节点自动会被删除，关注/clusterA这个根节点/clusterA的机器都会知道现在哪台机器离开计算单元了，并且获知现在有多少个计算节点在这个计算单元中。
如果有新的计算节点添加，在程序运行的第一步将会到zookeeper服务器上的/clusterA 的znode上创建一个子节点/clusterA/nodeZ，这样关注 /clusterA这个znode的机器都会知道现在多了一个计算节点。
通过zookeeper客户端API中的getChildren()方法对应的数据类型是java.util.List,其返回/clusterA下面的机器列表，这样还能判断出自己在这个列表中排行位置，通过列表中排行位置可以对应用户列表中的数目，这样就知道自己去获得需要计算总数中的几分之分。
例如：有100w用户，20个节点时，每个节点处理5w用户进行同时计算，node3计算节点承载用户总数中10w-15w用户之间的计算压力，有200w用户，20个节点时，每个节点处理10w个用户的业务进行同时计算，node3计算节点承载用户总数中30w-40w用户的计算压力，以此类推。
这样一来无论计算节点的数目发生变化还是，需要计算的数目发生变化，都可以保证计算压力的平均分载。

我的废话：
1.根据节点数对应用户数算出百分比之后进行计算分载，貌似我们通常的分页查询，只不过将每页的分页结果同时显示在N多个显示器上输出，希望这样比喻能让您更好的理解。
2.在计算的中间有新的用户数量增加，将会通知每个计算节点 下次轮询时需要重新统计用户数量，因为用户所有用户的数据分块拿走以后放入本地的静态hashmap(缓存)，没有发生变化就从本地加载，操作数据库发生变化后，通知zookeeper的znode节点 每个计算节点重新从数据库中加载一次。
3.在并行计算中时间同步也是一个需要注意的地方，如果每台机器上的时间不一致会导致潜在的隐患，可以找些工具通过时间服务器同步每台机器上的当前时间和时区。
4.使用zookeeper对计算节点的状态管理只是zookeeper实现的一部分，zookeeper还可以对外提供分组，配置管理，命名空间等服务等，这里只是做了一个抛砖引玉的作用。

对于zookeeper的可靠性和性能而言，有足够的机器那么稳定性就会越高，但是性能会降低，因为ZooKeeper在运行时全部的数据都会加载到内存中，集群中每一台服务器都包含全量的数据，每个节点实时保持数据的同步。因此整个集群中Follower数量越多，整个集群写入的性能越差。后来zookeeper Server为了避免这个问题，可以将ZooKeeper集群中部分服务器指定为Observer。

相关文章：
Apache ZooKeeper入门3
Apache ZooKeeper入门2
Apache Zookeeper入门1

–end–

我的废话：MySQL的JDBC参数加起来有百来个，分为6大类，更多详情请查阅，《MySQL-JDBC连接器使用手册》。

我们有一个生产环境的数据库是MySQL双主，12台JEE应用服务器对MySQL先读再写的轮训操作。昨天运维的人员需要对数据库机器添加内存，添加内存的事儿显然是需要对数据库服务器进行开关机，一拨人负责一台，两台服务器很快内存升级完毕，MySQL服务器也正常工作了。

但回头发现无法执行业务操作，12台应用服务器抛出全部Cause: java.sql.SQLException: Connection is read-only 异常。之前我们没有动应用服务器啊，只是重启数据库服务器按理说应该等数据库服务器重启完毕以后应用服务器会自动重连正常工作了。
由于时间紧迫需要立即恢复，没有办法，我们对12台应用服务器重启了一下，天下太平，世界又恢复平静了。当时没时间去研究个究竟到底是什么原因导致，但我知道如果再次遇到这样的类似场景还是出现同样的问题，所以需要找出问题的根本原因，给自己一个解释。

在MySQL的官方网站上找了一些可能性的依据，原因是设置了autoReconnectForPools=true参数，导致failOverReadOnly参数默认生效。原来failOverReadOnly的默认值是true，导致失效重新连接后出现  Cause: java.sql.SQLException: Connection is read-only. Queries leading to data modification are not allowed 的错误。

看了官方文档中的上面这段话为何是ReadOnly的状态也很能理解是为什么了，其实MySQL官方倡导的是Master-To-Slave的数据库备份方案,而我们的运行环境是Master-To-Master，如果前一个Master挂掉的话 往Slave中去写，等到Master恢复再对Master操作的时候数据就沉于大海，那么数据就不一致了，恢复起来会非常的麻烦，当前一个挂掉的时候，MySQL驱动会认为你的Master挂了，如果继续写将会写入Slave，所以默认的状态是ReadOnly=true，失败后重连，但重连后对下一台操作的是只读(ReadOnly)。

后来我们在测试环境中也重现了这个错误，然后加上failOverReadOnly=false，并且加上了queriesBeforeRetryMaster 和secondsBeforeRetryMaster 配置参数缩短切换和重试之间的时间长度。这两个参数是表示如果出现故障切换(使用多主机故障切换)并返回主机之前发出的查询数。无论首先满足了哪个条件，“queriesBeforeRetryMaster”或“secondsBeforeRetryMaster”，均会再次与主机进行连接，secondsBeforeRetryMaster是表示 出现故障切换后，在尝试再次连接到主服务器。

在测试环境中无论怎么重试、重启或者重连，世界很平静，哥很淡定，才能现在有空写这个blog，将整个过程记录下来。等下次需要停机或者重启的时候将这个参数加上，现已经记录在下个版本的发布计划中了。另外，我整理了一份JDBC操作MySQL的文档，方面日后查阅，下载地址。

相关文章：
MySQL JDBC中autoReconnectForPools的用途
MySQL JDBC 集群

–end–

除此之外，还需要能做到：
  1.使用廉价机器(老机器)构建分布式网络存储环境，支持150TB以上的存储容量，
  2.数据在线同步，支持文件副本复制，无明显的单点问题，可快速恢复故障节点，
  3.通用文件系统，不需要修改上层应用就可以使用(支持fuse)，web服务器可以直接读取分布式存储空间，无中间转取。
  4.支持在线不停机的情况下扩展存储的空间，
  5.随机读写的高效，并且支持海量小文件(5kb)的高效读写，
  6.可监控运行时的存储使用状态，最好是web界面。

得到了一些个解决方案，但依然不满足，对存储本身还有更高的期望：
    1.需要避免图片文件重复的写入，建立图片存储的索引，根据唯一的图片文件名的查询后，再判断是否写入，
    2.小图片，签名照，小头像，表情图片 放在缓存里读取，让数据更靠近cpu，设计的黄金原则，我们尽量把能放入Redis缓存中的数据就在Redis里读取。
   
架构介绍
  1.负载均衡：HAproxy采用RoundRobin负载均衡算法，分载前端用户请求的压力到每个web图片服务器上，
  2.web服务：采用Nginx-0.9.6 做图片的web服务器，对网站的大、中、小图片进行读取，加上Nginx的Redis模块对缓存中的微型(头像)图片进行读取，
  3. 缓存服务器：存储网站的 微型图片，签名照，小头像，表情图片，通过Nginx的Redis模块直接读取，通过调用Redis的java API程序对数据进行写入，
  4.存储单元：采用Moosefs 存储  大、中、小图片，并且提供监控管理界面，查看存储空间运行状态，
  5.图片索引：将图片名和图片url路径作为键值对(Key/Value)，放入HBase 中存储，并且进行数据查询，避免图片重复存储，便于将来管理，
  6.应用服务器：对图片写入的操作全部由Java应用服务器完成。

我们目前图片存储的系统架构，如图所示：

查看大图请点击这里

关于HBase的话题在这里就不多说了，可以参考我之前写的几篇文件文章，主要想说说Moosefs的体系：
        1 Master 管理服务器:负责各个数据存储服务器的管理,文件读写调度,文件空间回收以及恢复.多节点拷贝
        2 Chunk 元数据日志服务器: 负责备份master服务器的变化日志文件，文件类型为changelog_ml.*.mfs，以便于在master server出问题的时候接替其进行工作
        3 Metalogger  数据存储服务器:负责连接管理服务器,听从管理服务器调度,提供存储空间，并为客户提供数据传输.
        4 Client  客户端: 通过fuse内核接口挂接远程管理服务器上所管理的数据存储服务器,看起来共享的文件系统和本地unix文件系统使用一样的效果.

最有代表性的成功案例
     豆瓣网(Douban Inc),155 TB的存储空间，  
          Master server: Gentoo Linux / ReiserFS 3.6
          24 chunk servers: Gentoo Linux / ReiserFS / XFS
          3 metalogger(s): Gentoo Linux / ReiserFS 3.6
          37 client machines: Gentoo Linux

其实，采用某种技术只是一种具体实现的手段，或许从外界的统计数据来看 mogileFS、ceph、FastDFS 等其他产品具有更高的读写性能，甚至可以到满足我上述的任何一项要求，但我们所关注的侧重点不一样，要需要简单，易上手，够用就行，所以在这里利用Moosefs做了一个抛砖引玉。
 

–end–

Redis是一个key/value存储系统,大多数开发者把他当做类似Memcached的缓存系统使用，
Redis和MemCached区别的是：
    1.会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件
    2.对于我来说更重要的是Redis还实现了master-slave(主从)数据同步的功能。
    3.Redis不仅支持传统的存储的value类型，还可以支持list(链表)、set(集合)和zset(有序集合)，
    4.Redis还支持多种方式的排序，并且可以按照数据存储的范围来访问，有点像查询(select)，
    5.支持消息发布和订阅功能。

Redis也有我们对他不满意之处，例如：
        1.对于同一个队列或者通道来说，有N个接收端连接在Redis服务器上，每个接收端会收到相同的消息。
        2.发过了 你不接收 等接收端再上去消息就没有了，默认的配置是写在内存中，重启后不保存。
这2点上跟 Kestrel 是相反的，但通过一些奇巧淫技将Redis消息视为缓存进行持久化，保证redis服务器重启后数据还在，并且通过Redis客户端动态设置机器的主从备份，只要有两台或以上的Redis做集群可以对数据永远有保证，除非服务器集群环境全挂，这样的话Redis还算是对数据提供了可靠性。
但动态指定主从关系的话此时又会面临一致性的话题，在客户端指定Master的时候，为避免相互竞争或者重复指定，我们通过Jgroups工具作为Redis for Java客户端之间的通讯工具，在通讯过程中采用了Paxos算法，由客户端先选出一个Leader，再由这个选出来的Leader进行动态指定Redis集群中的master机器，这样可以提高一致性，避免竞争和冲突。

回到一开始说的Kestrel， 经过一番测试比较使用 xmemcached、spymemcached 等客户端对Kestrel进行收发操作，发现效果都比较烂，很遗憾没有找到让人满意的Kestrel for Java的客户端，所以我们一致认为使用Kestrel 这货将来的杯具估计产生在客户端(java)，也许Twitter使用的是ruby，是不是对ruby反而支持的很好？对Java支持的不够给力？Kestrel 接收端 需要不断的循环服务器 才能及时的收到消息， 这样节点数一多的话网络开销会不会很大？
在测试的过程中，我们使用xmemcached作为客户端，貌似不太靠谱，开10个线程，循环1000次，表示鸭梨很大，出现以下异常信息，producer和consumer都有，而且同时冒出来。
发送端：
Exception in thread "main" java.util.concurrent.TimeoutException: Timed out(1000) waiting for operation
接收端：
Exception in thread "main" java.util.concurrent.TimeoutException: Timed out waiting for operation
随后google之，作者提供了解答：http://code.google.com/p/xmemcached/issues/detail?id=108
作者给出的解释是：“这主要是因为xmc的操作都是异步的，同步等待有个超时时间，默认的1秒在高并发或者存取大数据的时候通常是不够的。”晕啊，表示不能接受这样的解释。

随后目光开始关注Redis，Redis采用长连接，事件监听，不需要轮询，接收端等待消息，只接收字符串类型的消息，对消息的数据没有保证，不接收就没有了服务器端不保存，也不支持Queue的消息模式，就像JMS中的Topic消息那样一个发送端对应N个接收端每个接收端收到同样的消息。
但我们将publish/subscribe和rpush/rpop 4个协议混合使用就可以完全满足我们的要求，客户端不轮训可以保证及时性和消息持久化的问题，而且还是Queue的模式。思路上通了后，做了压力测试，收发100w个消息开1000个线程，8秒以内搞定收发，表示毫无压力，体积小，部署简单比JMS方便，而且无单点，支持可散列。

在压力测试的过程中发现使用Redis Java客户端需要注意的两个问题：1.接收端莫名其妙的异常退出，这是由于没有设置连接空闲的超时导致的，就和MySQL的8小时问题一样，在Redis客户端设置一下config.setMaxIdle(num) 就好了。2.发送端由于发送大量请求会崩溃，出现超时错误，例如：JedisConnectionException: java.net.SocketTimeoutException: Read timed out，后来使用JedisPool和JedisPoolConfig实例，进行池化，一切都ok了，否则难以支持大数据量的高并发。

在系统中采用MQ是为了进行解耦合，用在2个环节上：
    1.系统中有大量数据并发写入，并且可以容忍一定的延时，那么就可以先存储缓存中，然后再将数据批量写入，降低DAL和数据库层每次通讯的开销。
    2.我们自己开发的分布式并行计算的定时器称为“任务工厂”(支持失败转发)，任务工厂从数据库或者缓存中拿用户的信息，将用户信息和业务逻辑框架作为消息，发送给各个不同的处理业务逻辑的服务器进行处理，那样1000w个用户的需要定时批量操作的话，任务工厂集群越大处理的速度就越快，而且如果有一个任务工厂的节点坏掉了或者又添加了一台新节点，轮询完毕后 重新计算一次后，每台机器又将平摊被分载的计算。

这次在实施的项目中，我们还专门设计了一个“失败队列”，他的作用是 处理具体业务逻辑的服务器 收到消息后将处理失败的请求放入“失败队列”中，往往消息在发送过来后进行处理，但是由于种种原因处理失败，但是下次还会再进来处理，这样的情况如果量大而且每次都这样的话对系统显然很不利，所以从原有的队列中移除这个用户请求，转移到“失败队列”中由 专门处理“失败队列”的任务工厂会去定时处理，如果这个账号轮训处理5次再失败，移除失败队列，存入数据库，进行管理员人工干预。

如果你真正的理解了MQ的工作原理，可以采用一些网络通信工具例如：netty、mina、grizzly  ，加上一些基于Key/Value的内存存储产品，例如memcached、redis ，自己可以是建造一个符合自己要求高效的轻量级MQ系统，如果说你可以失去一部分性能而换取可靠性的系统而言JMS依旧是首选产品。

感谢作者 庄晓丹 的回复，内容如下：
———————————————————————————————————————-
1、需要轮询，kestrel就是一个简单的push/pull模型，消费者只能通过pull轮询来获取消息。这个轮询的代价我认为很低的，取决于队列名称的大小，一般也就十几个字节一次请求。
2、超时的原因很多，通常来说跟你传输的消息大小、网络状况、kestrel的服务器状况都有关系，数据越大，在网络传输上耗费的时间越多，相应的越容易出现超时的情况。kestrel是scala写的，启动的时候要注意下jvm参数，如堆大小、gc算法之类，减少gc暂停带来的影响。服务器如果gc暂停，或者磁盘做刷入，都有可能导致响应超时，简单的做法就是将操作的超时时间加大，请注意，这个超时加大，不代表每个操作都要用这么多时间（可以统计平均看看），而是代表可以容许的最大超时时间。

2.就在三月非常荣幸能受到国内云计算知名人物单独会面的邀请(Ref)，与其畅聊了一把云计算的相关话题，大师语出非凡，从他身上通过4个小时的会面学习到了很多东西，感到自己还有很多不足和欠缺的地方， 有待弥补和加强。

3.Redis的话题在团队中不断的被展开和讨论，我们打算使用redis中的缓存和mq功能对目前的技术进行一些革新，现在正在做大量的准备工作。带领的其中一个团队新人较多而且多数是实习生，另一个团队多数是实力相当的技术精英，当需要对新项目技术创新时，我并没有选择后者，而选择了前者，我给出的理由有三：1需要充分给予新人机会发挥，2做创新这档事儿新人更有潜质，更敢想。3摸什么牌跟打什么牌无关，看的是成员执行力和领导者的能力。另外，这些日子在微博上看见不仅是我们似乎国内的很多技术团队都开始对Redis表示关注，通过淘宝几位兄弟在新浪微博上的言论，能看出他们在为此花了不少功夫，记得新浪微博是最早在网上披露自己使用redis的经验，在redis的官方网站上也能看见新浪微博的标记，等我们弄出点什么后在这里会和大家分享，请期待，稍安勿躁。

4.还是Hadoop的云计算话题，最近研究了一把MapReduce和Avro相关的话题，写了几篇日志(ref)，并且打算在新项目中使用hbase对用户的大量离线消息进行储存，avro对于数据传输和存储是不错的工具，具体使用avro做数据传输工具的事情现在正在和几位负责android开发的同学们商讨中，而使用avro工具对后端服务器数据储存的工作已经安排几位同学去实施，有机会和大家分享一些心得和过程。

5.公司新项目越来越多，产品也需要继续优化，需要大量的人手来做事，在不断的招人，经过这个月的连续招聘，每日面试3ˉ5 人，我越来越认为责任心，表达能力，思维方式是更主要的，我们不可能招聘到100%符合条件的人才，需要他有所超般，那只会加大招聘的成本，同时抹杀别人机会，我们不是google也不是微软，相反我们需要有一套好的体制流程和氛围加速新员工融入我们的团队中。在这里继续做个小广告，如果你身边有朋友在南京搞jee、android开发的可以与我联系。

6.吃喝玩乐的三月啊，海底捞，多佐，金钱豹，代官山，等等总之腐败的一塌糊涂，4月还会继续腐败将随着我肚子上的肥肉继续猛烈吧。

7.筹备5月份的技术交流活动，打算和本地的几个业内同行，展开一次线下的技术沙龙活动，届时会邀请在本地各路英雄来畅谈后端和云计算相关的话题。

–end–

Avro还可以做到在同一系统中支持多种不同语言，也有点类似Apache的另一个产品：Thrift(Ref)，对于Thrift不同的是Avro更加具有灵活性，Avro可以支持对定义的数据结构(Schema)动态加载，利于系统扩展。

使用Avro可以通过2中方式来实现：
1.二进制编码，Avro-specific方式依赖代码(文件)生成特定类，并内嵌JSON Schema；
2.JSON编码，Avro-generic方式通过JSON文件动态加载Schema，不需要编译加载直接就可以处理新的数据源。
我肤浅的认为，两者的区别在于同样的数据大小，在二进制编码下所产生的Avro数据的大小为100个字节，而在JSON编码下产生了450个字节。虽然看起来第1种二进制编码的方式占据一定优势，但是二进制传输最大的问题就是出了 bug 不方便追查，而JSON编码的方式更实用于系统与系统之间的数据通讯。

我的废话:
   1.从XML到JSON，再从JSON到Avro/Google PBs，技术不断的在发展，中间经历的时间跨度也越来越短。
   2.我个人认为Avro是比使用压缩(Gzip/z7)对结构化数据处理(JSON/XML)更好的手段。
   3.还可以借用Avro对以下产品进行序列化存储或者传输通信：
    a)HBase、Hive、MySQL
    b)Redis、MemCached
    c)本地文件存储 、Solr远程调用
    d)MapReduce分布式计算
参考资料：https://github.com/spullara/havrobase
4.别拿Avro的Socket当炮使，那玩意儿经不起折腾，在这个api的 ref里面已经明确的说明了。
参考资料：http://avro.apache.org/docs/1.5.0/api/java/org/apache/avro/ipc/SocketServer.html
5.如果specific方式需要用avro-tools.jar包进行编译，而generic方式直接调用JSON文件。

Avro支持本地和远程RPC(Ref)调用,RPC远程调用又分为Http和Netty2种，在这里主要介绍基于Http协议的Avro远程调用，首先需要定义一个JSON文件作为双方通信的传输协议规范，便于解析从对方发送过来的数据。
在这个协议中可以看做分为3大部分：
    1.描述(Protocol Declaration)，定义命名空间，协议名称 等。
    2.数据类型(types)，根据规范中的Primitive和Complex Types数据类型，自己封装一套数据格式。
    3.消息(messages)，根据自己定义的数据类型，再去定义 a)请求、b)回应、c)异常(可选)  数据格式。
以上内容可以详见下面代码示例中的user.avpr文件。

消息从客户端发送到服务器端需要经过传输层(Transport Layer)，它发送消息并接收服务器端的响应。到达传输层的数据就是二进制数据。通常以HTTP作为传输模型，客户端数据以POST方式发送到服务器端。消息被封装成为一组缓冲区(Buffer)，Avro规定一个标准的序列化的格式，即无论是文件存储还是网络传输，数据的Schema都出现在数据的前面。数据本身并不包含任何Metadata(Tag). 在文件储存的时候，schema出现在文件头中。在网络传输的时候Schema出现在初始的握手阶段，客户端和服务器端需要维护一个可见的协议缓存，因此，简单来说一个握手完成后，在进行网络交 换的时候不需要再传输协议的全部文本。
这是我在程序运行的过程中抓包的截图：

图示说明：
192.168.1.2是服务器端，192.168.1.106是客户端，可以看出第一次传输的时候服务器端返回的数据包大小为891，第二次和第三次返回的数据库包大小为77。而且返回的内容明显能看出是经过序列化的(上图的左下方)，也就是服务器端组装好的回应数据。

Avro 的消息被分为多个帧，形成一个缓冲列表。分帧是位于消息和传输层中的一层。它可以优化一些操作。分帧消息的格式为：
    * 一系列的缓存，每个缓冲包括：
          o 一个4字节，大端的缓存长度
          o 缓冲数据
    * 消息以一个零长度的缓存结束。
分帧对于请求和响应消息格式来说是透明的。任何消息都可能被分为一个或者多个缓存。

再来说说，这个代码例子，我大致分了3个包和一个user.avpr文件：
    1.client，我就直接放在最外面了，ClientHandler用来组装根据协议请求的数据，并且得到返回的结果。
    2.server，利用自带的Jetty作服务器，AvroFactory判断不同的请求的message类型，我定义了search、update 2种，也就是说在同一份user.avpr协议中经过处理和判断可以传输不同的协议内容。
    AvroHandler组装经过业务逻辑处理后返回结果，我在updateRespond/searchRespond2个方法中造了一些数据，模拟获取数据的结果
    3.tools，协议解析工具(AvroUtils.java)。
    4.user.avpr  传输协议文件。
将代码导入IDE环境后，运行AvroServer.java启动服务器，再运行ClientHandler.java执行客户端调用。

代码示例下载：
http://javabloger-mini-books.googlecode.com/files/avro-http-json.rar

以上代码示例采用的是Avro的1.4.1版本，如果需要Avro依赖的jar可以从这里下载：
http://javabloger-mini-books.googlecode.com/files/avro-lib-1.4.rar

通过阅读Avro的部分源码，按照其中的设计思路去实现，还可以将Avro集成到Tomcat，GlassFish，Resin 等 其他服务器中去，不见得非要使用Avro自带的Jetty作为服务器，只需要自己实现一个Servlet即可。这样就不受Avro中嵌入式Jetty服务器的限制，可以使用一些技术特性，例如：长连接、长轮询、Servlet监听器和过滤器，并且可以对Web容器进行更深入的性能优化。
在这里提供一个简单代码示例，大家可以参考一下，下载后直接将war工程部署到tomcat 等web容器中，客户端的代码也在这里war工程中(Client.java)。

代码示例下载：
http://javabloger-mini-books.googlecode.com/files/avroweb.war

暂时先说到这里，有空再聊一聊Avro中的MapReduce以及Avro中的内部结构。

–end–

最近看见Medialets(Ref)在网站架构中提到对MapReduce使用的经验分享，采用HDFS作为MapReduce分布式计算的基础环境，基于Python的MapReduce框架计算具体的内容，将计算的结果写入MongoDB中存储，对外宣称每秒1可以处理百万级的业务事件，可见MapReduce的运用场景在越来越多的丰富起来，说明除了Google和Yahoo这样的超大型互联网公司以外，更多的中小门户都对MapReduce和Hadoop开始产生兴趣，使用Hadoop的Mapreduce分布式计算的场景将和我们越来越近。

Hadoop Map/Reduce的框架的确简单易懂，基于他开发的应用程序能够运行在上千个机器组成的大型集群上，或者说MapReduce是一种“蛮力”计算，在一定程度上机器数量越多，得到的效果越显著，而且MapReduce提供了一种可靠容错的方式可并行处理上T级别的数据集。
在现实场景中执行一个Map/Reduce作业(job)会把Input的数据分为多个数据块(就像下面图中左边的黄色小块)，MapperTask以分布式并行的方式处理这些输入的数据。mapreduce框架会对map的输出先排序， 再map把计算结果输入给reduce最终对计算结果合并输出。

集群环境中的mapreduce计算节点失效转发、 分布式存储，工作调度，容错处理，网络通信，负载均衡 等问题不用开发者去考虑，MapReduce框架和MapReduce运行环境早就为此做出的考虑，如下图所示 在集群环境中有一个master负责调度构成一个作业的所有任务，大量的任务存在master的Task Queue里面，将这些任务分配在不同的slave上，master监控它们的执行 如果任务执行失败，由master指派slave(work)重新执行任务，如图所示：

通常作业的输入和输出都会被存储在文件系统HDFS中，也就是说，通常MapReduce框架和分布式文件系统是运行在一组相同的节点上的，允许在那些已经存好数据的节点上高效地调度任务，这可以使整个集群的网络带宽被非常高效地利用。MapReduce框架由一个单独的JobTracker(master)和很多个TaskTracker(slave)集群节点一个共同组成。

在MapReduce客户端的代码需要指明输入/输出的位置(文件路径/DB/NOSQL)，客户端再加上作业的参数，就构成了作业配置(job configuration)，客户端代码需要定义map和reduce方法通过实现合适的抽象类，并在实现的方法中编写你的业务逻辑，在客户端程序中还要定义你的map/reduce输入和输出的类型，当Hadoop的 job client提交作业(jar包/class/可执行程序等)和配置信息给JobTracker，后者负责分发这些软件和配置信息给slave、调度任务并监控它们的执行，同时提供状态和诊断信息给job-client。至于客户端job提交后的工作流程就是hadoop的事情了，分为4个过程，输入| 切分、排序、洗牌，合并 | 输出 ，输出的结果是有序的，因为mapreduce框架是天然排序的。如图所示：

MapReduce把数据集的操作分散到网络节点上，每个节点会周期性的把执行状态报告回，当某个节点连接或者计算超时达到一定次数，主节点记录下这个节点状态为死亡状态，并且分配给这个节点的任务发到别的节点上运行，例如Apache的Hive就是一个MapReduce框架的实现，Hive可以将SQL语句转换为 MapReduce任务把执行的SQL分散到每台机器上运行，最后返回计算结果。

我写了一个代码示例，这个示例通过mapreduce框架从文件夹中读取数据，进过格式化、对内容的加工，再写入HBase的的程序。当输入后根据输入的条件和状态产生多个Mapper(maptask)处理输入的内容，mapper先是从目录中读取所有文件信息，然后加工进行格式化，这一切都处理完成之后，将计算的结果交给Reducer去执行，Reducer根据客户端定义的输入类型做出对应的操作，将最终的结果存入HBase中。

示例例说明：
有一个 input  的输入目录，里面有3个文件 1.txt/2.txt/3.txt,需要在HBase中建立一张 tab1表，f1 是列名称，然后运行代码示例，最后在Hbase查看到3个txt中的数据全部写入hbase中。运行的过程中可以在eclipse的控制台上看见，先读取/格式化数据，最后写入hbase中的效果，如图所示：

Reduce的计算结果，如图：

代码示例下载地址：http://javabloger-mini-books.googlecode.com/files/txt-to-hbase.rar

通过这个例子可以假定一种场景，例如百度文库，每时每刻都有成千上万的人向百度的服务器上传文件，需要做到在最短的时间内对不同格式的文档进行处理、格式化，最终保存起来。前端服务器拿到用户上传的文档后，就像这个例子中x:\input下的3个文件，对于百度文库的运行场景来说也许是3w个，将大量的文档全部扔给mapreduce，mapreduce把需要解析、排版、格式化的文档交给每个分布的hadoop节点，将计算压力分布在多个CPU上进行计算，因为多人力量大的原因很快将能把3w个文档处理完毕，并且保存数据库/NOSQL，用户可以立刻在线阅读到刚刚上传的文档。

在离线的场景中通过mapreduce写入HBase还可以采用另外一种方式，先将文档扔给mapreduce，然后通过HFileOutputFormat输出HBase的数据文件，最后通过Hbase 工具将数据文件导入到HBase中，对于海量数据的迁移可以考虑这样的方式，在这种方案的基础上HBase官方提供了importtsv 工具 可以参考HBase的官方文档(Ref)。

我的废话：
最近有一个项目需要对 国内最大的网络设备供应商  提供方案实施，该项目主要针对android平台上的联系人功能进行扩展，比如2个客户端都安装这个联系人软件可以发送免费短信，类似现在的飞信、kiki，该产品还会向中国以外的市场推广，一旦二期上线用户的数量级将达到上千万，很可能产生大量的离线消息，打算采用HBase对用户的离线消息进行存储，在这点上不折不扣的向FaceBook学习了一把。

相关文章:
Hbase入门6 -白话MySQL(RDBMS)与HBase之间
Lily-建立在HBase上的分布式搜索
MySQL向Hive/HBase的迁移工具
HBase入门5(集群) -压力分载与失效转发
Hive入门3–Hive与HBase的整合
HBase入门篇4
HBase入门篇3
HBase入门篇2-Java操作HBase例子
HBase入门篇
基于Hbase存储的分布式消息(IM)系统-JABase
HBase入门7 -安全&权限

–end–

正好前些日子有位网友看见了我的blog，向我提问关于日志系统需要使用到hadoop和mysql的问题，于是我回问到为何需要使用hadoop的原因，经过一番了解，我建议对方采用缓存+文档数据库的方案，我向这位网友提出的方案可以看做是那个大型垄断国企方案的一个缩小版，除了具体使用的具体技术和产品有差别以外，2者从总体设计思想上大同小异，而且场景也比较相似，对数据库读、写基本不在同一个时段，不论写和读对数据库的操作还是开销比较大的，因此我想借用这位网友的提问阐述对上一次实施中的部分经验分享。
 
这位网友在来信中写到：
    您好，我最近在处理web日志的事情，涉及大量日志的处理，然后在网上搜到你关于Hadoop和Mysql的文章，想向你请教如何将Hadoop和Mysql结合起来处理大批量数据的，网站每个新闻页嵌入了一段js统计代码，每次页面打开时这段代码会在apache服务器端的文件记录一条日志(关于访客的详细信息)，然后后台服务器每隔一段时间将日志文件打成压缩包；同时服务器端每隔一个小时会运行一个jar文件，这个jar文件作用是将压缩包解压，并解析每一条日志信息，同时将日志信息分解后插入mysql数据库。前台可以浏览日志分析图表。现在的问题是随着网站流量越来越大，单台服务器已经不能满足要求了，jar文件现在处理压缩包的时间越来越长，所以考虑网站流量未来几年的增长，想到用数台服务器来处理这个问题。想用hadoop来在每台机子上处理这个压缩包文件，同时将处理好的日志字段写入mysql中。不知道问题我是否解释清楚了。

我回信中写到：
    你好，我只能给你一个方向上的指引，首先hadoop做这样的事情不值得 ,有点大材小用，不是上pb级别的数据量使用hadoop划不来的。
    我建议你是否可以采用这样的一种方案：
        1.前端JS通过http协议调用 Java/REST程序，获得请求
        2.Java/REST程序将获得的数据写入memcached中，将memcached作为缓冲区，
        3.另一个程序作为一个轮询的定时器，可以根据时间范围或者数量级别判断memcached上限的阀值，
        4.到达上限的时候一次性将数据写入mongoDB，如果写入数量较大还可以采用多线程的方式，
        5.最后从mongDB中查询存储的结果。
        6.如果不想使用mongoDB使用mysql也可以，到时候再对mysql对优化，例如：多块物理磁盘分区，mysql参数调整，读写分离。

大致的系统架构：
                 |                                                                                                                             
                 |                   |—>tomcat 1   ———-                                                                       
       js—-http–>loadbalance|                           | ——>memcache<——scheduler—–>DB/NOSQL
                 |                   |—>tomcat  N+1——–                                    multithread
                 |

这样做的理由是 ：
    1.写入日志和分析读取日志不是实时的，完全可以采用异步架构，我建议中间通讯采用http，将来扩展方便。如果将来前端的请求日志系统的并发量很高，可以选用 类似 tomcat+haproxy、tomcat+apache的方案，分载前端请求压力。
    2.采用memcached是为了提高写入的效率，写入比读更占用O/I资源，将平凡写入的数据放入缓存/内存，让数据更靠近CPU这是黄金原则。
    3. 不论是nosql还是mysql批量写入和一次一次写入所产生的开销大小这个差距是不用质疑的。

我的废话：
    希望通过这个blog能与业内更多的同行们得到交流，再次感谢您的阅读。

–end–
 

  在今天越来越多的人在讨论云计算相关的话题，越来越多的人知道云计算是有很多的计算机组成，但人们不会是关心云计算中的运用的具体技术，但是对于今天的程序员和工程师们来说会慢慢的会接触到云计算相关的需求，所以自然的就会接触到云计算相关的技术，云计算技术中包含分布式并行计算，分布式运算模型就是能够把任务分布到多台服务器上面执行，最后把任务归并回来获得计算的结果，而 MapReduce 就是一个为并行处理大量数据而设计的编程模型，它将工作划分为一个独立任务组成的集合。它是一种并行编程，现有的产品包括，如： Google 的 BigTable、Hadoop 、HBase 都用到了MapReduce的计算框架。
 
  Hadoop项目中Mapreduce的分布式计算框架需要依托于Hadoop的集群环境，在集群环境中 MapReduce 程序用于以并行方式计算大量数据，并且可以分配计算机之间的计算负荷，带来很高的运算效率，当计算时需要输入一组键/值对，生成一组输出键/值对。计算涉及的两个基本操作：Map 和 Reduce。用户编写的 Map 操作需要输入并生成一组中间键/值对。MapReduce 库将所有与同一中间键相关联的中间值组合到一起，并且将它们传递给 Reduce 功能。Hadoop 提供了MapReduce这种方法来实现并行计算程序设计的框架，当客户端发出MapReduce计算的请求转发到 Hadoop NameNode。然后Hadoop NameNode 负责具体的操作，它将启动大量 Map 和 Reduce 进程 执行具体的计算任务。当 MapReduce 完成操作之后，主节点 NameNode 将输出值返回到服务器并交付客户端。

  在Hadoop集群环境的节点状态被分类为3类：高利用、平均利用 和未充分利用。根据每个节点的利用率，将负载在节点之间转移以平衡集群。首选需要获取邻近节点详细信息：1. 当 DataNode 的负载增加到阈值级别时，它将向该 NameNode 发送一个请求。2. NameNode 获得特定 DataNode 最邻近节点的负载级别信息。3. NameNode 比较负载，然后将有关最空闲相邻节点的详细信息发送到特定的 DataNode。其次DataNodes 开始工作：1. 每个 DataNode 将自己负载量与其最近节点的负载量之和进行比较。2. 如果 DataNode 的负载级别大于其邻近节点，将随机选择那么负载目标节点(直接相邻的节点及其他节点) 。3. 然后将节点请求发送到目标节点。最后接收请求：1. 每个节点将维护一个缓冲区接收负载请求。2. 消息传递接口(MPI)管理此缓冲区。3. 主线程会侦听缓冲队列，并服务其接收的请求。4. 节点进入负载平衡执行阶段。

  具体到MapReduce框架 读/写数据库，有2个主要的程序分别是 DBInputFormat和DBOutputFormat，DBInputFormat 对应的是SQL语句select，而DBOutputFormat 对应的是 Inster/update，使用DBInputFormat和DBOutputForma时候需要实现InputFormat这个抽象类，这个抽象类含有getSplits()和createRecordReader()抽象方法，在DBInputFormat类中由 protected String getCountQuery() 方法传入结果集的个数，getSplits()方法再确定输入的切分原则，利用SQL中的 LIMIT 和 OFFSET 进行切分获得数据集的范围 ，请参考DBInputFormat源码中public InputSplit[] getSplits(JobConf job, int chunks) throws IOException的方法，在DBInputFormat源码中createRecordReader()则可以按一定格式读取相应数据。
我的废话：好比开启多线程对数据库查询，你先查询出数据结果集的个数，再根据你分配的LIMIT 和 OFFSET 策略分配给每个线程对查询数据库，最后合并在一个结果集里面。

注意：当集群中有大量的节点将会导致mapper的数目上升，此时读取数据库会给数据库造成很大的压力，需要考虑数据库的负载能。

简单的讲述一下 我利用MapReduce对MySQL和分布式文件系统HDFS的操作过程，MapReduce客户端先从MySQL中读取数据写在HDFS上，在示例程序中调用DBAccessReader.java就可以实现运行结果，第二个示例DBOutputFormat.java程序再从MySQL中读取数据，再次写入MySQL中，这样做的目的是想表达：
    1.可以通过MapReduce可以对结构化和非结构化的数据进行操作，
    2.可以通过MapReduce可以对结构化和结构化的数据进行操作，
    3.至于通过MapReduce对非结构化和非结构化的示例就不提供了，网上一大把都是。

JobTracker是一个master服务， JobTracker负责调度job的每一个子任务task运行于TaskTracker上，并监控它们，如果发现有失败的task就重新运行它。一般情况应该把JobTracker部署在单独的机器上。
TaskTracker是运行于多个节点上的slaver服务。TaskTracker则负责直接执行每一个task，TaskTracker需要运行在DataNode上。
Client端通过JobClient类提交到JobTracker，然后由JobTracker创建每一个Task(即MapTask和ReduceTask)并将它们分发到各个TaskTracker服务中去执行。

整个环境的架构如图所示：

查看大图请点击这里

以下是我在项目组测试环境中建立的机器清单如下：
    1.NameNode  / HDFS       192.168.20.212  (主节点/linux)
    2.DataNode   / HDFS        192.168.20.214/192.168.20.215  (从节点/linux)
    3.MySQL                    192.168.20.237  (单机/linux)
    4.MapRereduce  Client      192.168.20.240  (Eclipse/windows xp)
 
注意：将代码示例打成jar，将这个jar文件和mysql的jdbc驱动上传到所有hadoop节点的lib目录下，另外本示例中的blog.sql是建表语句。

代码示例下载地址：http://javabloger-mini-books.googlecode.com/files/hadoop-mysql.zip

相关文章：
谈谈MapReduce

–end–

我的废话2：
     MapReduce 让运算散列 且 并行着。

   MapReduce被业界认定是Google推出，如今也不是什么新的技术，自从Apache的Hadoop项目启动以来MapReduce就是整个Hadoop项目的核心内容，Pig、Hive和Hbase都是针对mapreduce框架的实现工具，所以对Hbase、Hive、Pig的深入了解必须对MapReduce有一定研究，以我自己的理解MapReduce就是把要计算的大型数据集切分成多个小的分区，根据这些被划分的小分区创建多个对应的任务去计算这些被切分的数据，在集群的节点上结合分区表分布式的执行计算,中间有调度器和计数器的环节，最后再把多个任务的计算结果进行合并，输出计算的结果。在这些执行每个分块的分布式集群节点中，可以使用非常廉价的机器，这样就可以使用低端的设备组成一个超大的型的运算。

  MapReduce的原理是比较简单的，并且目前流行大部分语言都能实现。如今Yahoo利用MapReduce定期在搜索业务上使用Hadoop来提高其产品和服务，如排名功能和目标广告。Google利用MapReduce来进行分布排序，web连接图反转，每台机器的词矢量，web访问日志分析，也有一些开源项目利用MapReduce来实现产品的功能，例如：最著名的MongoDB和Apache的Nutch，还有一些项目提出使用MapReduce来执行对数据库的分布式计算，例如：Gearman(Ref)，运行在微软云计算平台上的lokad-cloud(Ref) 。  MySpace也自己研制的MapReduce框架Qizmt开源了(Ref)，可用于在大规模Windows集群上开发或运行分布式计算程序。

   对于在Hadoop中涵盖的技术(Hive/HBase/Pig)对于传统的数据库来说，具有天然的可扩展性和支持海量数据存储的能力，并且对非结构化的数据处理能力完全超越于传统的数据库技术。例如，当MySQL运行的集群节点达到100台以上，虽然说理论上MySQL单张表的最大数据容量可以达到2T，但是如果真正需要依靠MySQL来存储的数据上T再加上大并发的用户访问，无论是维护还是操作都是非常头痛的事情，让MySQL或者传统数据库肩负超大型的数据运算/查询，化九牛二虎之力跑起来稳定一段时间过后，我想也会把MySQL累个半死，这是也并不是说让Hadoop/MapReduce/Hive 这些技术去替代传统的技术，而是希望Hadoop/MapReduce/Hive去用于做数据转换或者装载的(ETL)方面的工作，MapReduce适合海量数据数据被一次写入和多次读取的应用，在这些场合，MapReduce可以成为传统数据库的良好补充，而不是替代品。

  某些特定的场景中要存储上亿个文件本身就是一个头疼的问题，还要找出上亿个文件中存储的文档、图片、网页 哪个最大，并且还要分别列出3类，那更是雪上加霜，但利用Hadoop提供的MapReduce框架，基于HDFS分布式海量数据存储的手段，相对传统的方法而言会轻松一点，因为利用Hadoop的技术可以让廉价的机器组成在一起带来更高的计算性能，并且支持海量存储，换而言之，如果你的数据还没有上千万 上了Hadoop基本上是用“关公的大刀切青菜”，资源浪费。

   Hadoop并非是完全用于非结构化和半结构化的数据处理，在Apache Hadoop的MapReduce中为了方便MapReduce直接访问关系型数据库(Mysql,Oracle)，MapReduce输入的键和值并不是数据固有的属性，可以人为的来选择数据来源。Hadoop提供了DBInputFormat和DBOutputFormat两个类。这样就可以将现有数据库中的数据转储到Hadoop/HDFS中，由MapReduce进行分布式计算，通过MapReduce框架对海量数据进行分析，或者也可以倒过来从海量的非结构/半结构/结构化的数据分析，将计算的结果存储到数据库。关键字：DBOutputFormat、DBInputFormat、DBConfiguration，根据这几个关键字可以Google到更多结果，暂时先不提供代码了，稍后会提供完整的代码示例和个人见解，需要了解的同学可以先看看这里(Ref)。

让我更值得关注的是如何将mapreduce使用在适合的场景，将hadoop mapreduce的框架用途发挥到极致，或者说当面对大型计算该如何借用mapreduce框架、原理将计算进项散列在不同的计算机上去执行同一份作业，去更高的发挥机器的资源，更快的得到计算的运行结果，我想这才是使用mapreduce真正的目标吧。

–end–

一、开发环境(清单1)
1.操作系统
    Server-Linux / Client-WinXP
2.SDK
    Sun JDK1.5+

3.需要的jar依赖包
    libthrift.jar
    slf4j-api-1.5.8.jar
    slf4j-log4j12-1.5.8.jar
    log4j-1.2.15.jar

4.编译工具
    Apache Ant  & Apache ivy

二、安装/配置 (清单2)
    1.下载thrift源文件
        http://labs.renren.com/apache-mirror//incubator/thrift/0.5.0-incubating/thrift-0.5.0.tar.gz
        
    2.编译thrift源文件
        1)解压 thrift-0.5.0.tar.gz
        2)用ant编译源代码，进入x:\thrift-0.5.0\lib\java目录，执行ant，通过ant中的ivy工具会自动从站点下载所需要的依赖包，编译完成后如图所示:
        
        3)编译过程中下载的依赖包在x:\thrift-0.5.0\lib\java\build\ivy\lib 目录下可以看见下载的jar依赖包，将编译成功以后的jar包加入Eclipse的开发环境中。

三、脚本文件(清单3)
    1.创建脚本
        创建脚本文件 testJava.thrift ，脚本文件内容如下：
        namespace java com.javabloger.gen.code   # 注释1   定义生成代码的命名空间，与你需要定义的package相对应。

        struct Blog {   #  注释2.1   定义实体名称和数据结构，类似你业务逻辑中的pojo get/set
            1: string topic     #  注释2.2  参数类型可以参见 Thrift wiki  
            2: binary content  
            3: i64    createdTime
            4: string id
            5: string ipAddress
            6: map<string,string> props
          }
        service ThriftCase {  #  注释3    代码生成的类名，你的业务逻辑代码需要实现代码生成的ThriftCase.Iface接口
            i32 testCase1(1:i32 num1, 2:i32 num2, 3:string  num3) #注释4.1 方法名称和方法中的入参，入参类型参见wiki
            list<string> testCase2(1:map<string,string>  num1)
            void testCase3()
            void testCase4(1:list<Blog> blog)   #  注释4.2   list 是thrift中基本数据类型中的一种，list中包含的Blog对象是上面struct中定义的
        }

    2.运行脚本
        1)从 thrift 站点下载windows版本的编译工具，下载地址：http://labs.renren.com/apache-mirror//incubator/thrift/0.5.0-incubating/thrift-0.5.0.exe
        2)通过Thrift的脚本文件，运行 thrift 命令创建生成的代码，例如：执行 thrift -gen java x:\testJava.thrift  命令，在当前运行的盘符下，可看见gen-java目录，在这里目录中可以看见生成的java代码，更多thrift 命令内容，请参见thrift命令自带的help。

3.Thrift 中的基本数据类型 (清单4)
    类型 描述
    bool true, false
    byte 8位的有符号整数
    i16 16位的有符号整数
    i32 32位的有符号整数
    i64 64位的有符号整数
    double 64位的浮点数
    string UTF-8编码的字符串
    binary 字符数组
    struct 结构体
    list 有序的元素列表，类似于STL的vector
    set 无序的不重复元素集，类似于STL的set
    map key-value型的映射，类似于STL的map
    exception 是一个继承于本地语言的exception基类
    service 服务。包含多个函数接口(纯虚函数)

四、创建代码(清单5)
    我将示例工程分了4个包，如下所示:
     \com\javabloger
            \client               # 1.客户端测试代码
            \gen\code              # 2.通过脚本生成的class
            \layer\transport       # 3.服务器端代码和定义的传输协议
            \layer\business      # 4.具体的业务逻辑代码
    具体代码内容这里就不阐述了，重点是要明白代码的结构和层次关系，其次是里面主要的几个类的含义，至于代码是怎么写的并不是非常重要，仅仅是我个人观点，仅供参考，谢谢。

代码示例的下载地址： http://javabloger-mini-books.googlecode.com/files/Thritf.zip

五、运行程序
    先运行server，再运行client ，客户端向服务器端发送数据调用服务器端的4个方法，服务器端被传入客户端数据，运行效果如图所示：
   

相关文章：
Apache Thrift入门1-架构&介绍

–end–
 

   Thrift是IDL(interface definition language)描述性语言的一个具体实现，关于IDL的话题我们可以追溯到CORBA盛行1999-2001年(Common Object Request Broker Architecture/公用对象请求代理体系结构)，在 IDL 中我们似乎不会忘记到这几个关键字：module、interface、string、long 和 int，我还记得IDL利用module来创建名称空间，并且准确地映射为 Java 的 package，这些特性几乎和现在thrift的特性完全相同，所以thrift的设计思想和理念绝不是什么从火星来的new idea，看看在那个CORBA盛行的年代人们提出的概念，如图所示CORBA 请求的各个部分，回头我们再与thrift进行对比一下：

Thrift 基础架构
   Thrift是一个服务端和客户端的架构体系，从我个人的感官上来看Thrift是一个类似XML-RPC+Java-to- IDL+Serialization Tools=Thrift 的东东，Thrift 具有自己内部定义的传输协议规范(TProtocol)和传输数据标准(TTransports)，通过IDL脚本对传输数据的数据结构(struct) 和传输数据的业务逻辑(service)根据不同的运行环境快速的构建相应的代码，并且通过自己内部的序列化机制对传输的数据进行简化和压缩提高高并发、 大型系统中数据交互的成本，下图描绘了Thrift的整体架构，分为6个部分：1.你的业务逻辑实现(You Code) 2.客户端和服务端对应的Service 3.执行读写操作的计算结果4.TProtocol 5.TTransports  6.底层I/O通信

图 中前面3个部分是1.你通过Thrift脚本文件生成的代码，2.图中的褐色框部分是你根据生成代码构建的客户端和处理器的代码，3.图中红色的部分是2 端产生的计算结果。从TProtocol下面3个部分是Thrift的传输体系和传输协议以及底层I/O通信，Thrift并且提供 堵塞、非阻塞，单线程、多线程的模式运行在服务器上，还可以配合服务器/容器一起运行，可以和现有JEE服务器/Web容器无缝的结合。

数据类型
     * Base Types：基本类型
     * Struct：结构体类型
     * Container：容器类型，即List、Set、Map
     * Exception：异常类型
     * Service： 定义对象的接口，和一系列方法

协议
  Thrift可以让你选择客户端与服务端之间传输通信协议的类别，在传输协议上总体上划分为文本(text)和二进制(binary)传输协议, 为节约带宽，提供传输效率，一般情况下使用二进制类型的传输协议为多数，但有时会还是会使用基于文本类型的协议，这需要根据项目/产品中的实际需求：
    * TBinaryProtocol – 二进制编码格式进行数据传输。
    * TCompactProtocol – 这种协议非常有效的，使用Variable-Length Quantity (VLQ) 编码对数据进行压缩。
    * TJSONProtocol – 使用JSON的数据编码协议进行数据传输。
    * TSimpleJSONProtocol – 这种节约只提供JSON只写的协议，适用于通过脚本语言解析
    * TDebugProtocol – 在开发的过程中帮助开发人员调试用的，以文本的形式展现方便阅读。

传输层
    * TSocket- 使用堵塞式I/O进行传输，也是最常见的模式。
    * TFramedTransport- 使用非阻塞方式，按块的大小，进行传输，类似于Java中的NIO。
    * TFileTransport- 顾名思义按照文件的方式进程传输，虽然这种方式不提供Java的实现，但是实现起来非常简单。
    * TMemoryTransport- 使用内存I/O，就好比Java中的ByteArrayOutputStream实现。
    * TZlibTransport- 使用执行zlib压缩，不提供Java的实现。

服务端类型
    * TSimpleServer -  单线程服务器端使用标准的堵塞式I/O。
    * TThreadPoolServer -  多线程服务器端使用标准的堵塞式I/O。
    * TNonblockingServer – 多线程服务器端使用非堵塞式I/O，并且实现了Java中的NIO通道。
 
谁在用thrift ？

     Thrift用于Quara系统后端数据的通信，服务端是用C++来实现的，客户端则是python。
Quara背景:Quara是在线问答服务公司，类似新浪微博和百度知道的合体，消息灵通人士透露，去年Quara获得了1400万美元投资，目前他们只有9名员工。
原文：http://www.philwhln.com/quoras-technology-examined#thrift

  Thrift用于在多种Evernote API平台开发的客户端与Evernote服务器之间的通信与数据传输，Evernote API定义了自己的Evernote Data Access and Management (EDAM) 协议规范，让客户端使用更小的网络带宽上传、下载文件和在线即时搜索服务。
Evernote 背景:EverNote是一款非常著名的免费软件，它最大的特点就是支持多平台，而且数据能通过网络互相同步。譬如说，你可以随时在手机上的Evernote新增笔记，回家后在电脑上也能看到它了！
原文：http://www.evernote.com/about/developer/api/evernote-api.htm

HBase 中的Thrift
    Thrift用于HBase中是为了提供跨平台的服务接口，在HBase 中可以使用[hbase-root]/bin/hbase thrift start 命令启动涵盖Thrift的HBase服务端，客户端通过thrift的命令生成不同版本的客户端代码，根据定义的数据格式，对远程HBase服务端进行 操作，是除了REST远程方法调用的另一种途径。
参见：http://wiki.apache.org/hadoop/Hbase/ThriftApi

更多资料请阅读：http://wiki.apache.org/thrift/PoweredBy

Thrift与其他传输方式的比较
    xml与JSON相比体积太大，但是xml传统，也不算复杂。
    json 体积较小，新颖，但不够完善。
    thrift 体积超小，使用起来比较麻烦，不如前两者轻便，但是对于1.高并发、2.数据传输量大、3.多语言环境， 满足其中2点使用 thrift还是值得的。

  假定需要传输相同的内容，但使用不同的方式从 1、传输内容所产生的大小 2、传输过程中服务端和客户端所产生的开销，这2个方便进行比较。使用Thrift和其他方式的所产生的内容大小比较结果如下：
    
    在上图中我们能明显看出，最臃肿的是RMI，其次是xml，使用Thrift的TCompactProtocol协议和Google 的 Protocol Buffers 相差的不算太多，相比而言还是Google 的 Protocol Buffers效果最佳。

使用Thrift 中的协议和其他方式的所产生的运行开销比较结果如下：
 

   在上图中我们能明显看出，最占资源是REST2中协议，使用Thrift的TCompactProtocol协议和Google 的 Protocol Buffers 相差的不算太多，相比而言Thrift的TCompactProtocol协议效果最佳。

接下来请继续阅读，迈向Thrift的第一步，Thrift示例。

–end–

查看更多照片

–end–

   近2年来云计算的话题到目前为止风风火火从来没有平静过，一直是大家嘴边讨论的热门话题，人们期望运用云计算提供可靠、稳定、高速的计算，在云计算中Google是目前最大的云计算供应商，例如：Google GAE(Google App Engine)和Google的Docs在线文章服务，这些SaaS上线产品的数据存储(datastore)是由BigTable提供存储服务的，在次之前我提到过Yahoo贡献给Apache的那些山寨版本(Google与Yahoo的那些利器)，其中Apache的HBase就是山寨了Google的BigTable。

   我们知道在云计算的技术话题中Apache的Hadoop项目是一块基石，利用Hadoop项目中的产品可以建立云计算平台和超大型的计算。不知道你是否有想过如果将HBase作为Google GAE上的数据存储(datastore)，那么每个用户之间的数据访问权限怎么办？如果使用HBase提供对大客户提供“私有云”(private cloud)或者另一种可能一个公司内部的集群上运行HBase，公司的内部可能有几个部门，某几个部门之间的数据都是独立分离但又运行在一个平台上，那么你就会发现HBase不具备这样的功能，貌似目前HBase的最高版本0.90.0还没有这样的功能对用户的表、Row、Cell的访问权限。但是我们知道Google的GAE上每个用户访问的数据肯定是有权限划分的，不然我只要有权限登录GEA就能看见所有用户存放的数据了。这样的问题你有可能没有想过，但趋势公司的工程师们却为此想到了这点，并且把他们的设想和设计提交了HBase项目组，并且提出了以下主要的设计思想：
   1. Client access to HBase is authenticated
   2. User data is private unless access has been granted
   3. Access to data can be granted at a table or per column family basis.

对HBase中的表和数据划分权限等级和身份验证后，操作权限被分为3大类，每类中包含的操作权限如下所示：

对于方案中涉及到存储的权限的是指整个表或表中的列族，也就是说只考虑在表这个级别的权限，表与表之间的所属关系是存放在 .META. 系统表中，以regioninfo:owner 的格式进行存放，例如:系统中table1这个表是有权限的，这个表权限的存根保存在3个地方 ：
    * The row in .META. for the first region of table1                   
    * The node /hbase/acl/table1 of Zookeeper                         
    * The in-memory Permissions Mirror of every regionserver that serves table1      
如图所示，图中的箭头表示了数据流向的顺序：

查看大图请点击这里

方案中HBase在分布式、集群环境下，而权限一致性的问题交给了Zookeeper来处理，在多个regionservers中，每个服务器的HRegion中存放着多个表，并且实现了(implement)ZKPermissionWatcher接口的nodeCreated() 和 nodeChanged() 方法，这2个方法对Zookeeper 的节点进行监控， 节点的状态发生相应的变化时会ZooKeeper刷新镜像中的权限。
如图所示：

查看大图请点击这里

HBase的这一关于权限的功能正在设计和研讨当中，让我们继续对他保持关注，看看今后将会发生的变化能给我们带来什么样的效果，非常期待这个功能早日正式发布。

2011年的大年三十夜，祝大家新年快乐，往事如意。
 

相关文章:
Hbase入门6 -白话MySQL(RDBMS)与HBase之间
Lily-建立在HBase上的分布式搜索
MySQL向Hive/HBase的迁移工具
HBase入门5(集群) -压力分载与失效转发
Hive入门3–Hive与HBase的整合
HBase入门篇4
HBase入门篇3
HBase入门篇2-Java操作HBase例子
HBase入门篇
基于Hbase存储的分布式消息(IM)系统-JABase

–end–

   传统数据库是以数据块来存储数据，简单来说，你的表字段越多，占用的数据空间就越多，那么查询有可能就要跨数据块，将会导致查询的速度变慢。在大型系统中一张表上百个字段，并且表中的数据上亿条这是完全是有可能的。因此会带来数据库查询的瓶颈。我们都知道一个常识数据库中表记录的多少对查询的性能有非常大的影响，此时你很有可能想到分表、分库的做法来分载数据库运算的压力，那么又会带来新的问题，例如：分布式事务、全局唯一ID的生成、跨数据库查询 等，依旧会让你面对棘手的问题。如果打破这种按照行存储的模式，采用一种基于列存储的模式，对于大规模数据场景这样情况有可能发生一些好转。由于查询中的选择规则是通过列来定义的，因此整个数据库是自动索引化的。按列存储每个字段的数据聚集存储， 可以动态增加，并且列为空就不存储数据，节省存储空间。 每个字段的数据按照聚集存储，能大大减少读取的数据量，查询时指哪打哪，来的更直接。无需考虑分库、分表 Hbase将对存储的数据自动切分数据，并支持高并发读写操作，使得海量数据存储自动具有更强的扩展性。

   Java中的HashMap是Key/Value的结构，你也可以把HBase的数据结构看做是一个Key/Value的体系,话说HBase的区域由表名和行界定的。在HBase区域每一个"列族"都由一个名为HStore的对象管理。每个HStore由一个或多个MapFiles(Hadoop中的一个文件类型)组成。MapFiles的概念类似于Google的SSTable。 在Hbase里面有以下两个主要的概念，Row key 和 Column Family，其次是Cell qualifier和Timestamp tuple，Column family我们通常称之为“列族”，访问控制、磁盘和内存的使用统计都是在列族层面进行的。列族Column family是之前预先定义好的数据模型，每一个Column Family都可以根据“限定符”有多个column。在HBase每个cell存储单元对同一份数据有多个版本，根据唯一的时间戳来区分每个版本之间的差异，最新的数据版本排在最前面 。

口水：Hbase将table水平划分成N个Region，region按column family划分成Store，每个store包括内存中的memstore和持久化到disk上的HFile。

上述可能我表达的还不够到位，下面来看一个实践中的场景，将原来是存放在MySQL中Blog中的数据迁移到HBase中的过程：
MySQL中现有的表结构：

迁移HBase中的表结构：

原来系统中有2张表blogtable和comment表，采用HBase后只有一张blogtable表，如果按照传统的RDBMS的话，blogtable表中的列是固定的，比如schema 定义了Author,Title,URL,text等属性，上线后表字段是不能动态增加的。但是如果采用列存储系统，比如Hbase，那么我们可以定义blogtable表，然后定义info 列族，User的数据可以分为：info:title  ,info:author ,info:url 等，如果后来你又想增加另外的属性，这样很方便只需要 info:xxx 就可以了。
对于Row key你可以理解row key为传统RDBMS中的某一个行的主键，Hbase是不支持条件查询以及Order by等查询，因此Row key的设计就要根据你系统的查询需求来设计了额。 Hbase中的记录是按照rowkey来排序的，这样就使得查询变得非常快。

具体操作过程如下：
============================创建blogtable表=========================
create 'blogtable', 'info','text','comment_title','comment_author','comment_text'
 
============================插入概要信息=========================
put 'blogtable', '1', 'info:title', 'this is doc title'
put 'blogtable', '1', 'info:author', 'javabloger'
put 'blogtable', '1', 'info:url', 'http://www.javabloger.com/index.php'

put 'blogtable', '2', 'info:title', 'this is doc title2'
put 'blogtable', '2', 'info:author', 'H.E.'
put 'blogtable', '2', 'info:url', 'http://www.javabloger.com/index.html'

============================插入正文信息=========================
put 'blogtable', '1', 'text:', 'what is this doc context ?'
put 'blogtable', '2', 'text:', 'what is this doc context2?'

==========================插入评论信息===============================
put 'blogtable', '1', 'comment_title:', 'this is doc comment_title '
put 'blogtable', '1', 'comment_author:', 'javabloger'
put 'blogtable', '1', 'comment_text:', 'this is nice doc'

put 'blogtable', '2', 'comment_title:', 'this is blog comment_title '
put 'blogtable', '2', 'comment_author:', 'H.E.'
put 'blogtable', '2', 'comment_text:', 'this is nice blog'

HBase的数据查询\读取，可以通过单个row key访问，row key的range和全表扫描,大致如下：
注意：HBase不能支持where条件、Order by 查询，只支持按照Row key来查询，但是可以通过HBase提供的API进行条件过滤。
例如：http://hbase.apache.org/apidocs/org/apache/hadoop/hbase/filter/ColumnPrefixFilter.html

scan 'blogtable' ,{COLUMNS => ['text:','info:title'] }  —> 列出 文章的内容和标题

scan 'blogtable' , {COLUMNS => 'info:url' , STARTROW => '2'}    —> 根据范围列出 文章的内容和标题

get 'blogtable','1'    —> 列出 文章id 等于1的数据

get 'blogtable','1', {COLUMN => 'info'}    —> 列出 文章id 等于1 的 info 的头(Head)内容

get 'blogtable','1', {COLUMN => 'text'}   —> 列出 文章id 等于1 的 text  的具体(Body)内容

get 'blogtable','1', {COLUMN => ['text','info:author']}  —> 列出 文章id 等于1 的内容和作者(Body/Author)内容

我的废话2:
   有人会问Java Web服务器中是Tomcat快还是GlassFish快？小型数据库中是MySQL效率高还是MS-SQL效率高？我看是关键用在什么场景和怎么使用这 个产品(技术)，所以我渐渐的认为是需要对产品、技术本身深入的了解，而并非一项新的技术就是绝佳的选择。试问：Tomcat的默认的运行参数能和我们线 上正在使用的GlassFish性能相提并论吗？我不相信GlassFishv2和GlassFishv3在默认的配置参数下有显著的差别。我们需要对产 品本身做到深入的了解才能发挥他最高的性能，而并非感观听从厂家的广告和自己的感性认识 迷信哪个产品的优越性。

我的废话3:
  对于NOSQL这样的新技术，的的确确是可以解决过去我们所需要面对的问题，但也并非适合每个应用场景，所以在使用新产品的同时需要切合当前的产品需要， 是需求在引导新技术的投入，而并非为了赶时髦去使用他。你的产品是否过硬不是你使用了什么新技术，用户关心的是速度和稳定性，不会关心你是否使用了 NOSQL。相反Google有着超大的数据量，能给全世界用户带来了惊人的速度和准确性，大家才会回过头来好奇Google到底是怎么做到的。所以根据 自己的需要千万别太勉强自己使用了某项新技术。

我的废话4:
  总之一句话，用什么不是最关键，最关键是怎么去使用！

 
相关文章:
Lily-建立在HBase上的分布式搜索
MySQL向Hive/HBase的迁移工具
HBase入门5(集群) -压力分载与失效转发
Hive入门3–Hive与HBase的整合
HBase入门篇4
HBase入门篇3
HBase入门篇2-Java操作HBase例子
HBase入门篇
基于Hbase存储的分布式消息(IM)系统-JABase

–end–

Lily以NoSQL技术为主题，是建立在云计算上的内容仓库(content repository)。它是基于Apache的 HBase(存储)和Solr(索引/搜索)，并提供了大型内容集合存储与检索的解决方案。可运用在 门户网站，内容管理系统，及时搜索，档案应用，文案管理，等等。

Lily项目与传统的Lucene框架相比体现了以下几点关键性的优势：
    ·伸缩性  –> sharding/MapReduce
    ·可用性  –> replication
    ·及时性  –> real-time update index
    ·容错性  –> no SPFO

另外，Lily 借用了Apache的 HBase进行存储 ，Solr进行Index/Search；
            Lily 重新构建大数量的索引Lily会采用MapReduce把索引当做文件切在HDFS上；
            Lily 索引更新时切换并没有像LinkedIn的Zoie那样保存在内存里，Lily在Hbase上建立了secondary indexes；
            Lily 在建立索引的结构方面 借鉴了Google App Engine的索引设计思想；
            Lily 提供REST 和 API 2种方式提供客户端调用；
           

BTW：关于上面提到了LinkedIn的Zoie我想多数两句，Zoie跟LinkedIn的其他产品捆绑的非常紧密，导致你如果单一的使用Zoie总会觉得很变扭，而且文档非常少，那篇让人貌似惊喜的中文文档仍然不够详细，只好对Zoie望而却步了。

Lily的系统架构由4个主要的部分组成：
    1.Zookeeper – 对分布式环境中的状态和配置进行管理，让Client可以知道当前有多少个工作的 Lily Node。
    2.Lily Node – a)WAL(预写日志)、b)Message Queue(消息队列)、c)Indexer(索引策略)、d)Lily Repository(索引CRUD) 组成。
    3.HBase -作为存储单元，最终的消息、索引、数据和二进制数据还是存储在HDFS上。
    4.Solr – 建立Lucene框架基础上查询器，并且支持分布式搜索，切片的策略由Lily Middleware中的Indexer部件提供。
    5.Client-客户端的访问入口基于Avro的协议(类似于PB)操作Repository，

如图所示:

废话1：
         1.Lily 提供了快速入门的模拟集群工具(Minicluster)，不需要搭建HBase/Hadoop/Zookeeper环境，只要有JDK你第一次上手20分钟内也能跑起来一个例子。
         2.Lily 在分布式的环境中不能使用Apache的原版Hbase和Hadoop，需要使用改装过的版本，HBase是Lily自己改装的，Hadoop是Cloudera的 0.20.2+737版 。
         3.Lily 为了简化开发和将来对项目的维护，在代码上使用了Spring作为集成工具。
         4.Lily 考虑使用HBase和Solr作为基础平台纠结了很久，最终给出了一些依据。
       
废话2：
    1.zookeeper作为JEE分布架构中最上层防止单点(SPFO)系统接口是不错的选择，不仅是Lily在这样做，HBase本身也是这样。
    2.分布式搜索中需要异步架构的支撑，消息中间件是最佳的选择，用来对索引进行CRUD和挂起的操作。
    3.对于大数量的索引合并和更新是MapReduce实战才能的时候了。
    4.通过Lily项目对于HBase的使用场景又有了新的参考。
        
废话3：
         1.Srping也对云计算的话题蠢蠢欲动，Spring Framework HBase Template  列入计划中。
         2.在众多HBase ORM中pigi 算是不错的一个，使用简单，Pigi Project 。
         3.JMXToolkit 可以对HBase进行监控，并且可以和Cacti、Nagios进行集成。
 

相关文章：
MySQL向Hive/HBase的迁移工具
HBase入门5(集群) -压力分载与失效转发
Hive入门3–Hive与HBase的整合
HBase入门篇4
HBase入门篇3
HBase入门篇2-Java操作HBase例子
HBase入门篇
基于Hbase存储的分布式消息(IM)系统-JABase

–end–

整个系统架构由HBase/HDFS、JABase、ErlBase 这3大部分组成，整体架构如图所示：

除了需要安装HBase和HDFS一些主要部件以外，还需要有以下一些组件支持：
   – ejabberd-2.0.3.tar.gz    (Erlang)
   – erlbase-1.0.tar.gz         (Erlang)
   – jabase-1.0.tar.gz           (Java)

对JABase项目的了解，结合目前采用的架构引发出2个的设想：
    1、XMPP与MQ 可扩展性的比较，有时间需要坐下来跟大家讨论一下。
    2、MQ的性能扩展 a)前端集成缓存 b)后端消息存储，看看这么加才对我们有真正的帮助。
 

相关文章:
MySQL向Hive/HBase的迁移工具
HBase入门5(集群) -压力分载与失效转发
Hive入门3–Hive与HBase的整合
HBase入门篇4
HBase入门篇3
HBase入门篇2
HBase入门篇
Lily建立在HBase上的分布式搜索

–end–

而然伟大的云计算公司cloudera.com也是Hadoop强力支持者推出了Sqoop，Sqoop顾名思义SQL-to-Hadoop，在sqoop中通过 ManagerFactory 抽象类对多种数据库类型进行了抽象，可以做到 Hsqldb、MySQL、Oracle、PostgreSQL 这些数据库中的数据可以向Hive中写入。

   从导出/导入所有数据一条命令即可，而且可以对表和数据的筛选，开发的效率提升和配置的简洁是这个工具的特色所在，同样的机器配置、机器数量、数据量和数据内容，但是换了不同的环境得到了不同的执行效率，通过对RMDBS到Hadoop的迁移，带来了性能的提升，所以就体现了sqoop的价值。

在一次开发大会上提到的Sqoop主要功能
    JDBC-based implementation
        ▪ Works with many popular database vendors
    Auto-generation of tedious user-side code
        ▪ Write MapReduce applications to work with your data, faster
    Integration with Hive
        ▪ Allows you to stay in a SQL-based environment
    Extensible backend
        ▪ Database-specific code paths for better performance

具体操作手册相见：
http://archive.cloudera.com/cdh/3/sqoop/SqoopUserGuide.html (官方)

相关文章：
 Hive入门3–Hive与HBase的整合
 Apache Hive入门2
 Apache Hive入门1
 Apache Pig入门1 –介绍/基本架构/与Hive对比

–end–

其中的技术架构是我们在2007-2009年实施的案例摘录，2009-2011年实施的一些架构暂时还没有全部整理好。

以上PPT内容非公司内部资料，解释权 归本人所有。

H.E. 最想看到您对这份 PPT宝贵的观点和评论，先跟各位说声：谢谢了。

 BTW：今年将主打GIS和云计算(Hadoop) 话题。

–end–

读书推荐
在每篇文章中可以向读者推荐与当前文章有关话题的书籍，一般可以做到有效推荐10几本，多则可以上百本。该功能是为了：
1.推荐相关书籍可以帮助读者系统性的学习，因为光是阅读一篇文章不可能掌握某想技术的全部知识，
2.推荐的书籍列表可以帮助读者开拓视野，读者会知道哪几项技术是有必然的关联性的，此时会放在同一阶段的学习计划中。
3.推荐读者离线的阅读书籍/资料，可以让读者循序渐进的进行学习。

   设想一下，站在用户的角度看待这个功能，他阅读这个片文章《Glassfish(EJB)与Quartz Job Scheduler整合》，该文章与GlassFish话题相关并且还与J2EE服务器有关，根据文章的标签再对应豆瓣的API，读者可以得到两类书籍推荐 GlassFish，J2EE服务器，学习Java的人都知道J2EE服务器包含了GlassFish服务器 要掌握 GlassFish服务器 学习J2EE服务器还是必不可少的。再比如我写的上一篇文章《谷歌分析数据》，通过这篇文章会向你推荐  有关 SEO 和 google-analytics 类别的书籍，对用户系统化的学习和开拓视野可以起到一定的作用。  

   此时推荐的书籍98%是有效的推荐，因为推荐的内容完全针对用户感兴趣的话题。用这项功能的服务是“豆瓣读书”提供的API做到的。BTW: 豆瓣不是网上书店，只是一个中间机构，所以我觉得他给出的结果相对客观。

在文章中推荐的链接，如下图所示：
    

首页栏目
  方便访问用户对本站作者更多的了解，比如：读什么书籍?看什么电影?听什么音乐? 通过这些内容可以大致了解作者的什么性格、类型的人，这样便于彼此在线上和线下更好的交流，展开更多扩展的共同话题，提高彼此的认知度，拉近与读者直接的距离。

新浪微博
   不论是作为推广和获得新识 都是一个不错的选择，但新浪微博对于非注册用户是不开放里面的内容，你在新浪微博里面的内容再精彩对于非注册用户来说一切都是空白。所以我利用新浪微博的API直接面向所有用户，可以知道我最近关注的一些正经事和破事儿，这样做也是拉近与读者的距离。点击这里可以查阅。

其他
   还添加了 留言板和 废话录 2个页面，方便与用户直接进行交流，并且修改了评论字体样式 。

最后
没有什么总结，因为还没有做完，先记着在这里，有些东西完善以后和现在记录下来的东西整合在一起。
 

最后，再来一个小投票：

–end–

2、网站使用率 :   
    综合浏览量为199,512次，每次访客访问页数为2.70个页面，   跳出率到达38.66%，平均网站停留时间为00:01:36，新访问次数百分比为84.87%，如图所示:

查看大图请点击这里

3、访客流量来源:
    91 个国家/地区带来了 74020 次的独立访问量，其中除中国外访问来源最多的地区就是台湾(Taiwan)，有3,116个独立访客，其次是美国(United States)有1,388个独立访客.如图所示：

查看大图请点击这里
   
   中国有 378 个城市带来了 66,274 次的独立访问，其中访问来源最多的3个城市是:Beijing、Shanghai、Shenzhen ，而我所在的城市南京只排在第6位,如图所示：

查看大图请点击这里

4、访问途径来源:
    直接进入本站的访问是最大的访问来源，其次是来自Google和Baidu2个搜索引擎的访问来源，再次是来自stackoverflow.com和tech-q.cn的访问来源，如图所示：

5、被查看最多的网页:
    除了本站首页之外，人们看的最多的就是关于本人的自我介绍，其次是关于spring框架和系统架构(architecture)相关的话题,如图所示：

查看大图请点击这里

6、被查看最多的目标网页:
    不论是通过直接输入网址还是通过其他网站跳转，除了本站首页以外，被访问最多的页面就是与Spring框架有关的页面，其次是和mongodb话题有关的网页，如图所示：

查看大图请点击这里

我的废话:
 这些数据让我判断出中国的程序员在北京和上海的最多，本站Hadoop系列的文章要比spring多，但是SSH框架之类的话题依然是最被关注的，这些可能我说的不准确，但是这至少是我从数据上得到的直观判断，暂时先这样，现在的数据需要跟来年相比较才会有更大的价值，来年在看吧，呵呵，新年快乐。

–end–

JMS与JMX(页1) – J2EE开发者- web思想社区关注互联网平台级架构设计 …
1 个帖子 – 新贴子： 10月4日
可以使用JEE规范中的JMX协议进行管理OpenMQ中的集群管理节点(managing brokers)、服务(admin/jms)、消息队列(destinations), 接收者(consumers), …
www.tech-q.cn/archiver/tid-12594.html

百万级大型J2EE Push Mail 项目后记
百万级大型J2EE Push Mail 项目后记. … 2.JVM的优化是任何大型J2EE项目中必不可少的话题，当然并不是你把JVM的内存使用空间设置的越大越好，SUN的官方网站已经指出， …
http://www.360doc.com/content/10/1111/15/15643_68489672.shtml

百万级J2EE Push Mail 后记（转自H.E.）_Kyle's BLOG_百度空间
1、虽然都是搞J2EE的老手，都没有接触过Push Mail这样的国外项目，所以对业务的精髓不能完全 … 5、对J2EE以外的技术只有1-2人了解。比如：分布式计算、应用服务器,数据库集群技术和大型 …
http://hi.baidu.com/zhizhesky/blog/item/6c693dd35f69e00e3bf3cf62.html

JavaBloger迷你书(系统架构专题).pdf – OPEN开源文档
2010年12月13日 … JavaBloger迷你书(系统架构专题).pdf. … JavaBloger迷你书(JMS与消息中间件专题).pdf. 1人评 48页. 利用iText生成PDF.doc. 6人评 4页 …
http://doc.open-open.com/view/6e500b5643e44013980fb04f1d0bed5e

JavaBloger迷你书(JMS与消息中间件专题).pdf – OPEN开源文档
2010年12月13日 … JavaBloger迷你书(JMS与消息中间件专题).pdf. … 相关文档. JavaBloger迷你书(系统架构专题).pdf. 1人评 45页. JavaBloger迷你书(性能优化专题).pdf …
http://doc.open-open.com/view/c0d19a098dff4308bfbf4446717a039b

JavaBloger迷你书(性能优化专题).pdf – OPEN开源文档
2010年12月13日 … JavaBloger迷你书(性能优化专题).pdf. … JavaBloger迷你书(JMS与消息中间件专题).pdf. 1人评 48页. 利用iText生成PDF.doc. 6人评 4页 …
http://doc.open-open.com/view/5af0d9d8ac604d15a217d30209f67291

JavaBlog 电子“迷你书” 看图说话： – docin.com豆丁网
2010年8月18日 … Javabloger.com网站也在孵化当中，将略懂的一些知识与经验进行与大家 … Javabloger.com 将会分享更多有价值的内容和经验给大家，同时还会以正式与非 …
http://www.docin.com/p-71793683.html

[转]说说每日项目例会的必要性 全文显示- 学习笔记- JavaEye技术网站
2010年11月13日 … 五、信息反馈是非常重要的，项目例会起到了团队沟通，但是更重要的是需要和 … 原文出处:http://www.javabloger.com/article/talk-about-project- …
http://merrygrass.javaeye.com/blog/721048

MongoDB 集群: NoSQLfan
2010年9月8日 … 原文链接：http://www.javabloger.com/article/mongodb-cluster.html. MongoDB 集群中包含一个自动分片模块(“mongos”). 自动分片可以用于构建一个大 …
http://blog.nosqlfan.com/html/544.html

Java操作MongoDB NoSQL数据库
2010年3月25日 … http://www.javabloger.com/images/article_pic/mongodb/ MongoDB是一个“绿色”免安装直接解压(unzip)即可运行的高性能，开源，无关系型(NoSQL)的文档 …
http://www.jin-dou.cn/whilehall-jiangtai/236.html

Google Analytics(谷歌分析) 的架构与原理详解（组图）(页1) – Google …谷歌众包论坛's Archiver
14 个帖子 – 14 个作者 – 新贴子： 12月18日
[align=center][b][url=https://proxysama.appspot.com/www.javabloger.com/images/article_pic/ga/google-analytics-architecture.png]查看大图请 …
http://bbs.pxysm.com/archiver/tid-3374.html

Google Analytics(谷歌分析) – 企业信息化与知识管理研究中心
2010年5月12日 … http://www.javabloger.com/images/article_pic/ga/. 具体使用Google Analysis 的过滤器方法可以去问Google自己，也可以点击这里 ..
http://www.myikmc.com/showContent/ZS266653406950651826_JD371605882867846309.html

使用memcache 管理session – 翻过这座山，就到菩提洞了- JavaEye技术网站
2010年8月27日 … http://www.javabloger.com/images/2010-05/webcluster/msem.jsp.txt …
http://cailin.javaeye.com/blog/748730

德国SNS交友/视频网站Poppen.de的技术架构分享 – J2EE企业应用 …
Javabloger的总结： 1.越来越多的网站由于业务的壮大，在寻求通过消息传递的，异步式架构的方案，在poppen.de中使用的RabbitMQ是Erlang编写的消息服务器，支持Java、C/C++、.Net 、PHP 等语言。2.MySQL 的第三方引擎 XtraDB 受到越来越多 …
http://www.360doc.com/content/10/0731/13/11586_42714353.shtml

德国SNS交友/视频网站Poppen.de的技术架构分享 …
查看大图请点击这里 Javabloger的总结： 1.越来越多的网站由于业务的壮大，在寻求通过消息传递的，异步式架构的方案，在poppen.de中使用的RabbitMQ是Erlang编写的消息服务器，支持Java、C/C++、.Net 、PHP 等语言。2.MySQL 的第三方引擎 …
http://www.cnblogs.com/skyaspnet/archive/2010/12/31/1923017.html

分享一篇好的大型网站技术架构文章，同时与各位讨论消息队列在架构中的应用
摘要：* 消息服务器 整个网站采用的算是一种分布式的异步架构体系，中间采用RabbitMQ作为异步通讯服务器，通过上层28台PHP Ap Server做成的LVS集群对下层2台集群的 RabbitMQ 消息系统进行调用，这里消息系统主要用来发送运行日
http://it.haitianyuan.com/programforum/picture.php?id=603473

Apache Zookeeper入门2 – 给自己一片纯净的天空
2010年12月18日 … Apache Zookeeper入门1：作者: H.E. | 您可以转载, 但必须以超链接形式标明文章原始出处和作者信息及版权声明
http://my.oschina.net/cmffire/blog/11281

Apache Zookeeper入门1 – 给自己一片纯净的天空
2010年12月18日 … Apache Zookeeper入门1：作者: H.E. | 您可以转载, 但必须以超链接形式标明文章原始出处和作者信息及版权声明
http://my.oschina.net/cmffire/blog/11280

hbase入门1_hanzhaoxia123的空间_百度空间
2010年12月7日 … 转载地址：http://www.javabloger.com/article/apache-hbase-shell-and- … Zookeeper 提供的功能包括：配置维护、名字服务、分布式同步、组服务等， …
http://hi.baidu.com/hanzhaoxia123/blog/item/0b577630a2166d5f251f141e.html

hbase 入门2_hanzhaoxia123的空间_百度空间
2010年12月7日 … 转载地址：http://www.javabloger.com/article/apache-hbase-shell-and- … 是如何进行工作的，首先HBase Client端会连接Zookeeper Qurom(从下面的 …
http://hi.baidu.com/hanzhaoxia123/blog/item/681938b7683d1fb6d9335a13.html

HBase入门篇(页1) – DBA/数据库管理- web思想社区关注互联网平台级架构 …
2010年11月6日 … Zookeeper 提供的功能包括：配置维护、名字服务、分布式同步、组服务等，用 ….. 前几篇文章讲述了
http://www.tech-q.cn/viewthread.php?tid=14058

我的HBase之旅- K_Flex – JavaEye技术网站
2010年11月21日 … http://www.javabloger.com/article/apache-hbase-shell-and-install-key-value.html … 停止的时候也是有顺序的， hbase–zookeeper–hadoop …
http://keren.javaeye.com/blog/818553

Spring3 REST MVC框架,提速你的Web开发- kinggod03的日志- 网易博客
2010年5月16日 … package com.javabloger.springrest.action;. import javax.servlet.http. … import com.javabloger.springrest.pojo.Users;. @Controller …
http://kinggod03.blog.163.com/blog/static/4406394820104169445708/

Spring3 REST MVC 例子- J2EE开发者- web思想社区关注互联网平台级架构 …
5 个帖子 – 5 个作者 – 新贴子： 9月20日
System.out.println("Hello [url=http://www.javabloger.com/]www. …. 来源：http://www.javabloger.com/article/spring3-rest-mvc-example.html …
http://www.tech-q.cn/thread-7242-1-1.html

GlassFishv3 设置虚拟主机(页1) – LINUX/BSD/UNIX管理- web思想社区 …
2010年7月30日 … asadmin create-virtual-server –hosts ddns.javabloger.com … 说明:创建一个虚拟主机别名为vs1，虚拟主机指向的站点域名是ddns.javabloger.com， …
http://tech-q.cn/archiver/tid-10191.html

Spring3文件上传,提速你的Web开发_人人IT网
2010年10月16日 … 文章转至：网址: http://www.javabloger.com/article/spring-3-file-upload- … package com.javabloger.springrest.action;. import java.io. …
http://www.renren.it/a/JAVAbiancheng/Spring/20101016/36510.html

Spring3 REST MVC框架提速你的Web开发-itnetIT163网是中国IT行业信息最 …
2010年5月16日 … setAttribute("message" "Hello JavaBloger ! @RequestMapping(value='/add')"); … package com.javabloger.springrest.action; …
http://www.163-auto.cn/index.php?mod=group_thread&code=view&id=19656

Java操作MongoDB NoSQL数据库- 云开发-锋云网
2010年12月27日 … 作者: H.E. | 您可以转载, 但必须以超链接形式标明文章原始出处和作者信息及版权声明 网址: http://www.javabloger.com/article/mongodb-java.html
http://w-w.cn/article-579-1.html

大型系统外利用jms劣化技巧–sunopenmq – 电脑问答网
2010年6月11日 … 可以或许查阅我写的别的一篇文章www.javabloger.com/article/sun-glassfish-openmq-topic.html正在文章外我提到，若是正在发送端或者正在领受端加上 …
http://www.pcwenda.com/html/System/2010/0611/3733.html

服务器、工作站Server & Workstation – J2EE企业应用顾问/咨询Java传教 …
2010年7月31日 … www.javabloger.com – J2EE企业应用顾问/咨询- HE's Blog – J2EE企业应用顾问/咨询Java传教士- HE's Blog HE's Blog 用最简洁的页面描述企业应用 …
http://www.sunwukong.cn/company/computer_and_software/server_and_workstation,461492.html

GlassFish v3 优化经验分享- 狗狗的专栏- CSDN博客
网址: http://www.javabloger.com/article/glassfish-v3-jvm-configuring-and-64-bit-jvm.html. 发表于@ 2010年07月04日23:39:00 | 评论( loading. …
http://blog.csdn.net/yuanyuan110_l/archive/2010/07/04/5712647.aspx

GlassFish 数据库连接池的配置步骤(图解) – 追寻的博客- JavaEye技术网站
http://www.javabloger.com/images/article_pic/glassfish/ 4.进入“新建JDBC 连接池” 第2步，并且定义你的连接属性，一共有182个属性可以配置，暂时不管其他的，配置几 …
http://sundful.javaeye.com/blog/773110

Spring集成JMS OpenMQ – 小白的日志- 网易博客
glassfish 2010-11-24 13:14:13 阅读5 评论0 字号：大中小 订阅. 来源: http://www.javabloger.com/article/spring-jms-openmq.html …
http://baiyizhong.blog.163.com/blog/static/278517362010102411413917/

netli博客- 网站架构分类文章列表- JavaEye技术网站
2010年6月8日 … http://www.javabloger.com/images/article_pic/glassfish/ · 查看大图请点击这里. 还没有看懂没有关系，听我慢慢的口水： 系统环境： …
http://netli.javaeye.com/blog/686923

同位素_百度空间
我们先来看看在Sun OpenMQ系统中一个持久、可靠的方式传送消息的步骤是怎么样的，如图所示：
http://hi.baidu.com/1shome/blog/item/fc03ae2450c1bd0c4c088dfe.html

–end–

2011新年的开始。

                    Hello 2011,Hello Baby(HTY)

–start–

什么都不想说，说什么愿望都是以后的事儿，人入30后，我渐渐习惯不去多想大于明天的事，因为那些事儿后天我就会明白。

  ·Hama中有2个主要的模型:
    – 矩阵计算(Matrix package)
    – 面向图计算(Graph package)

·Hama项目起源于在2008年5月19日
·Hama主要成员 Edward J. Yoon (高丽棒子)
·Hama项目的最大支持者 韩国NHN互联网搜索引擎以及网络游戏公司，貌似中国的百度，详见这里。

2、Hama介绍 
   2008年5月Hama被视为Apache众多项目中一个被孵化的项目，目前(2010年12月)在Hama的项目网站上还没有正式的release版本，作为Hadoop项目中的一个子项目，BSP模型是Hama计算的核心，并且实现了分布式的计算框架，采用这个框架可以用于矩阵计算(matrix)和面向图计算(grah)、网络计算(network)。

我的废话:
1、如果要深入了解到 Hama中采用到的技术体系，需要去阅读一些BSP、MPI、Pregel等相关资料，可以有助于对Hama项目的了解。
2、看来Apache基金会对Google未开源的核心技术彻底的做了一个山寨版本，比如我之前提到过关于Yahoo山寨了Google的那些技术。
3、Hama中依然存在SPFO的单点问题，如果主节点BSPMaster挂了，依然全挂，当然有其他的解决办法，不过这里主要想指出的是Hama暂时还没有设计到这点。
4、Hama在MapReduce的基础上实现了2种算法，Iterative 和 Block ，其中Iterative比较简单，而Block相对复杂些。

3、关于BSP模型
Hama中最关键的就是BSP(Bulk Synchronous Parallel-“大型”同步模型)模型, BSP的概念由Valiant(1990)提出的，“块”同步模型，是一种异步MIMD-DM模型，支持消息传递系统，块内异步并行，块间显式同步，该模型基于一个master协调，所有的worker同步(lock-step)执行, 数据从输入的队列中读取， 该模型的架构如图所示：

另外，BSP并行计算模型可以用 p/s/g/i 4个参数进行描述：
·    P为处理器的数目(带有存储器)
·    s为处理器的计算速度
·    g为每秒本地计算操作的数目/通信网络每秒传送的字节数，称之为选路器吞吐率，视为带宽因子 (time steps/packet)=1/bandwidth
·    i为全局的同步时间开销,称之为全局同步之间的时间间隔 (Barrier synchronization time)
那么假设有p台处理器同时传送h个字节信息，则g•h就是通信的开销。同步和通信的开销都规格化为处理器的指定条数。

BSP计算模型不仅是一种体系结构模型，也是设计并行程序的一种方法。BSP程序设计准则是 bulk同步 (bulk synchrony)，其独特之处在于超步(superstep)概念的引入。一 个BSP程序同时具有水平和垂直两个方面的结构。从垂直上看,一个BSP程序由一系列串行的超步(superstep)组成,如图所示:

这种结构类似于一个串行程序结构。从水平上看， 在一个超步中， 所有的进程并行执行局部计算。一个超步可分为三个阶段 ,如图所示:

1 )本地计算阶段， 每个处理器只对存储本地内存中的数据进行本地计算。 
2 )全局通信阶段， 对任何非本地数据进行操作。 
3 )栅栏同步阶段， 等待所有通信行为的结束。 

BSP模型相对于其他两种模型而言， 具有如下两个方面的优点： 
•MPI 和 PVM两种并行计算模型，依赖于接收和发送 的操作对。这样通信方式容易导致上层应用程序产生死锁，而BSP并行计算库是一个程序划分为超步(superstep)，使得死锁不再发生。 
•BSP模型由于其本身的特点， 使得对于程序的正确性和时间的复杂性预测成为可能。

4、Apache Hama与Google Pregel
Hama类似Google发明的Pregel，如果你听过Google Pregel这个利器的话，那么就对BSP计算模型不会陌生，Google的Pregel也是基于BSP模型，在Google的整个计算体系中有20%的 计算是依赖于Pregel的计算模型，Google利用Pregel实现了图遍历(BFS)、最短路径(SSSP)、PageRank计算,我猜想 Google的Google Me 产品很有可能会大量采用Pregel的计算方式，用Pregel来绘制Google Me产品中SNS的关系图。

Google的Pregel是采用GFS或BigTable进行持久存储，Google的Pregel是一个Master-slave主从结构，有一个节点扮演master角色，其它节点通过name service定位该顶点并在第一次时进行注册，master负责对计算任务进行切分到各节点(也可以自己指定，考虑load balance等因素)，根据顶ID哈希分配顶点到机器(一个机器可以有多个节点，通过name service进行逻辑区分)，每个节点间异步传输消息，通过checkpoint机制实行容错(更高级的容错通过confined recovery实现)，并且每个节点向master汇报心跳(ping)维持状态。

 Hama是Apache中Hadoop的子项，所以Hama可以与Apache的HDSF进行完美的整合，利用HDFS对需要运行的任务和数据进行持久化存储，也可以在任何文件系统和数据库中。当然我们可以相信BSP模型的处理计算能力是相对没有极限的特别对于图计算来说，换句话说BSP模型就像MapReduce一样可以广泛的使用在任何一个分布式系统中，我们可以尝试的对实现使用Hama框架在分布式计算中得到更多的实践，比如：矩阵计算、排序计算、pagerank、BFS 等等。

5、Hama Architecture
Apache的Hama主要由三个部分组成：BSPMaster，GroomServers和Zookeeper，下面这张图主要概述了Hama的整体系统架构,并且描述了系统模块之间的通讯与交互。Hama的集群中需要有HDFS的运行环境负责持久化存储数据(例如:job.jar),BSPMaster负责进行对Groom Server 进行任务调配，groom Server 负责进行对BSPPeers进行调用 程序进行具体的调用，Zookeeper负责对Groom Server 进行失效转发。

BSPMaster
在Apache Hama中BSPMaster模块是系统中的一个主要角色，他主要负责的是协同各个计算节点之间的工作，每一个计算节点在其注册到master上来的时候会分配到一个唯一的ID。Master内部维护着一个计算节点列表，表明当前哪些计算节点出于alive状态，该列表中就包括每个计算节点的ID和地址信息，以及哪些计算节点上被分配到了整个计算任务的哪一部分。Master中这些信息的数据结构大小取决于整个计算任务被分成多少个partition。因此，一台普通配置的BSPMaster足够用来协调对一个大型计算。
下面我们来看看BSPMaster做了哪些工作：
   •    维护着Groom服务器的状态。
   •    控制在集群环境中的superstep。
   •    维护在groom中job的工作状态信息。
   •    分配任务、调度任务到所有的groom服务器节点。
   •    广播所有的groom服务器执行。
   •    管理系统节点中的失效转发。
   •    提供用户对集群环境的管理界面。

   一个BSPMaster或者多个grooms服务器是通过脚本启动的，在Groom服务器中还包含了BSPeer的实例，在启动GroomServer的时候就会启动了BSPPeer，BSPPeer是整合在GrommServer中的，GrommServer通过PRC代理与BSPmaster连接。当BSPmaster、GroomServer启动完毕以后，每个GroomServer的生命周期通过发送“心跳”信息给BSPmaster服务器，在这个“心跳”信息中包含了GrommServer服务器的状态，这些状态包含了能够处理任务的最大容量，和可用的系统内存状态，等等。

   BSPMaster的绝大部分工作，如input ，output，computation，saving以及resuming from checkpoint，都将会在一个叫做barrier的地方终止。Master会在每一次操作都会发送相同的指令到所有的计算节点，然后等待从每个计算节点的回应(response)。每一次的BSP主机接收心跳消息以后，这个信息会带来了最新的groom服务器状态，BSPMaster服务器对给出一个回应的信息，BSPMaster服务器将会与groom 服务器进行确定活动的groom server空闲状态，也就是groom 服务器可资源并且对其进行任务调度和任务分配。 BSPMaster与Groom Server两者之间通讯使用非常简单的FIFO(先进先出)原则对计算的任务进行分配、调度。

GroomServer
   一个Groom服务器对应一个处理BSPMaster分配的任务，每个groom都需要与BSPMaster进行通讯，处理任务并且想BSPMaster处理报告状态，集群状态下的Groom Server需要运行在HDFS分布式存储环境中，而且对于Groom Server来说 一个groom 服务器对应一个BSPPeer节点，需要运行在同一个物理节点上。

Zookeeper
   Zookeeper这里就不多提了，可以参考我之前写的几篇文章，在Apache HaMa项目中zookeeper是用来有效的管理BSPPeer节点之间的同步间隔(barrier synchronisation),同时在系统失效转发的功能上发挥了重要的作用。

6、Hama对BSP模型的实现
在一个BSP计算模型的程序中包含了一个supersteps步骤，每一个superstep由以下3个体系：
   •    本地计算
   •    进程通信
   •    同步间隔

public class BSPEaxmple {

  public static class MyBSP extends BSP {

    @Override
    public void bsp(BSPPeer bspPeer) throws IOException, KeeperException,
        InterruptedException {
      // 1. Do something locally
     
      // 2. Sends/receives data to/from neighbor nodes
      bspPeer.send(peerName, msg);

      while ((message = bspPeer.getCurrentMessage()) != null) {
         byte[] data = message.getData();
      }

      // 3. Barrier synchronization
      bspPeer.sync();
    }

    @Override
    public Configuration getConf() {
      return conf;
    }

    @Override
    public void setConf(Configuration conf) {
      this.conf = conf;
    }   

  }
 
  // BSP job configuration
  public void main(String[] args) throws Exception {
    BSPJob bsp = new BSPJob(new HamaConfiguration(), BSPEaxmple.class);
    // Set the job name
    bsp.setJobName("My BSP Job");
    bsp.setBspClass(MyBSP.class);

    // Submit job
    BSPJobClient.runJob(bsp);
  }
} 

接下来将会介绍 Hama的具体的用例和安装配置说明，待续。

感谢您的阅读。

相关文章:
  Apache ZooKeeper入门2
  Apache Zookeeper入门1
  Apache ZooKeeper入门3

–end–

如果你是一个喜欢去解释，习惯去解释的人，下面的文字就不用看，因为你会反对我这样的说法。

看一下在现代汉语词典中对抱怨的解释：
抱怨 bàoyuàn
[complain;grumble] 心中怀有不满,责怪别人

我，现在在一个900-1000个人生长型公司生存的技术人员、核心工程师、架构师、部门经理、新人导师 这些都是我在这个公司的称号和头衔。不管是谁，不管怎么称呼我都没问题。新来的菜鸟，资深的老员工向我请教问题我都满怀耐心去对待他们，同时我也会向他们请教我不解的问题。这些我都无所谓，但是我不喜欢别人向我抱怨，对问题，对人，对公司等等，一切的抱怨我都表示从潜意识上的反感，对待问题我可以耐心去接受与聆听，但对待抱怨和无聊的解释我一概无视，但我至少会聆听。

没有完成你的目标也别跟我谈什么理想，我太不爱听！因为我们不是评论家，也不是社会关系学家，没有那个水平和足够的资格对这些、那些说三道四，解决了问题我们才有闲功夫去说三道四。

我是在一个提交解决方案的公司，客户只想看最终的结果，不会想听我的解释。生存的环境就是这样，大环境也是这样，被逼的。看到这些文字被我说过的人，请原谅我对您的刻薄。

一些刚刚入职的新人向我解释说到：这个技术、这个问题我没有接触过，不知道能不能解决。我记得在《娱乐现场》的节目中，记者采访汤灿关于歌舞剧《雪狼湖》的情节，让我尤为深刻，汤灿说到“和学友大哥每一次排练都有50-60遍，我本来以为只需要5-6遍，没有想到学友大哥非常认真”。我想表达的是：不是你没有这个能力解决当前的问题，而是看的太少，想的太少，试验的太少，对待问题没有充分的理解，所以导致对问题没有底气，才会有了为难的情绪向人抱怨，天王级别的人物都丝毫不敢放松，还是那样的刻苦练习，别说我们这些普通人了。

当然新人在做的事过程中方法很重要，我只会告诉他该如何去做的方法和做事情的方向，而绝不会是问题的答案，不然我就贪污了他的一次成长过程，那样对他的成长和公司的成长丝毫没有帮助，只告诉他问题的答案那是徒劳的过程。

有人问过我，你想去什么样的公司？我回答道：“什么样的公司，并不非常重要，而是你在什么样的公司，能改变什么,这个才是最重要的，就算在微软，google 进去了没有能力胜任工作去了也毫无意义。”

再看看看 淘宝、腾讯这些多年前的小公司，在成长的过程中肯定不会是马云、马化腾一个人在奋斗，我相信而是一帮人，一帮能改变现有环境的人，才会成就他们的今天。我认为在有前景的中小型公司里，通过每个人的努力不是没有可能成为一家大公司，因为现在的大公司都是原本的小公司变成了，那时你也是一位大公司中元老级的人物。

有人说过公司某些项目没有技术含量，我觉得并不是没有技术含量，而是他对技术本身就没有完全的认识，有人说公司没有一帮牛人，我觉得并非没有一帮牛人，而是他没有成为牛人的愿望和理想。

问题和对手不会管你是否疲劳，一旦给你自己找一个借口，你就会停下来一会，你将来会花费十倍的力气去追赶，才能赶上他们，你只有拼命的去跑，这并不代表你贪婪，这个的游戏规则就是剩者为王，意志力尤为重要，踏实的心态尤为重要。

在奔跑的过程中每个人都是艰辛的，但你只有挨过最困难的时光，才能看见希望，如果你停下来了，你所处的位置就决定了你所能看见什么样的视野，因为什么样的视野，决定了你能看见什么样的未来，什么样的胸怀就创建什么样的事业。
我相信一个真理，成功没有捷径，需要付出，需要忍耐，需要坚持，一个人真正的成功，是来自于点滴的成果。别去再谈什么超级壮观的理想，把小于等于明天的事情做好，一切水到渠成，喜悦的时分自然而来。

以上的这些字我早就想说了，只是最近我听了太多的抱怨和解释，但我都无视，团队需要的是结果和有能力解决问题的人！我喜欢做事踏实的人，因为我就是这样爬过来的，我也感谢我现在的公司，他不仅给了我一个不错的工作氛围，同时也让我戒掉了一些浮躁的态度。

“我没有天分，所以我很勤奋”–天王刘德华在一次颁奖典礼上说过的话。

–end–

祝大家2010年的平安夜快乐。

一、介绍
Google的工程师为了方便自己对MapReduce的实现搞了一个叫做Sawzall的工具，Google就放了几篇论文放在网上，但这玩意在代码上不开源在设计思想是开源的，在前面一篇文章中我也提到过Hadoop也推出了类似Sawzall的Pig语言，就是根据Google放出来的论文山寨的。

Pig是对处理超大型数据集的抽象层，在MapReduce中的框架中有map和reduce两个函数，如果你亲手弄一个MapReduce实现从编写代码，编译，部署，放在Hadoop上执行这个MapReduce程序还是耗费你一定的时间的，有了Pig这个东东以后不仅仅可以简化你对MapReduce的开发，而且还可以对不同的数据之间进行转换，例如：包含在连接内的一些转化在MapReduce中不太容易去实现。

Apache Pig的运行可以纯本地的，解压，敲个“bin/pig -x local”命令直接运行，非常简单，这就是传说中的local模式，但是人们往往不是这样使用，都是将Pig与hdfs/hadoop集群环境进行对接，我看说白了Apache的Pig最大的作用就是对mapreduce算法(框架)实现了一套shell脚本 ，类似我们通常熟悉的SQL语句，在Pig中称之为Pig Latin，在这套脚本中我们可以对加载出来的数据进行排序、过滤、求和、分组(group by)、关联(Joining)，Pig也可以由用户自定义一些函数对数据集进行操作，也就是传说中的UDF(user-defined functions)。

经过Pig Latin的转换后变成了一道MapReduce的作业，通过MapReduce多个线程，进程或者独立系统并行执行处理的结果集进行分类和归纳。Map() 和 Reduce() 两个函数会并行运行，即使不是在同一的系统的同一时刻也在同时运行一套任务，当所有的处理都完成之后，结果将被排序，格式化，并且保存到一个文件。Pig利用MapReduce将计算分成两个阶段，第一个阶段分解成为小块并且分布到每一个存储数据的节点上进行执行，对计算的压力进行分散，第二个阶段聚合第一个阶段执行的这些结果，这样可以达到非常高的吞吐量，通过不多的代码和工作量就能够驱动上千台机器并行计算，充分的利用计算机的资源，打消运行中的瓶颈。

所以用Pig可以对TB级别海量的数据进行查询非常轻松，并且这些海量的数据都是非结构化的数据，例如：一堆文件可能是log4j输出日志存又放于跨越多个计算机的多个磁盘上，用来记录上千台在线服务器的健康状态日志，交易日至，IP访问记录，应用服务日志等等。我们通常需要统计或者抽取这些记录，或者查询异常记录，对这些记录形成一些报表，将数据转化为有价值的信息，这样的话查询会较为复杂，此时类似MySQL这样的产品就并非能满足我们的对速度、执行效率上的需求，而用Apache的Pig就可以帮助我们去实现这样的目标。

反之，你如果在做实验的时候，把MySQL中的100行数据转换成文本文件放在在pig中进行查询，会让你非常失望，为何这短短的100行数据查询的效率极低，呵呵，因为中间有一个生成MapReduce作业的过程，这是无法避免的开销，所以小量的数据查询是不适合pig做的，就好比用关二哥的大刀切青菜一样。另外，还可以利用Pig的API在Java环境中调用，对Apache的Pig以上内容请允许我这样片面的理解，谢谢。

 
二、基本架构
 
从整体上来看大量的数据聚集在HDFS系统上，通过输入类似SQL的脚本简化对MapReduce的操作，让这几行代码/脚本去驱动上千台机器进行并行计算。
如图所示：

Pig的实现有5个主要的部分构成：
如图所示：

1.Pig自己实现的一套框架对输入、输出的人机交互部分的实现，就是Pig Latin 。
2.Zebra是Pig与HDFS/Hadoop的中间层、Zebra是MapReduce作业编写的客户端，Zerbra用结构化的语言实现了对hadoop物理存储元数据的管理也是对Hadoop的数据抽象层，在Zebra中有2个核心的类 TableStore(写)/TableLoad(读)对Hadoop上的数据进行操作。
3.Pig中的Streaming主要分为4个组件: 1. Pig Latin 2. 逻辑层(Logical Layer) 3. 物理层(Physical Layer) 4. Streaming具体实现(Implementation)，Streaming会创建一个Map/Reduce作业，并把它发送给合适的集群，同时监视这个作业的在集群环境中的整个执行过程。
4.MapReduce在每台机器上进行分布式计算的框架(算法)。
5.HDFS最终存储数据的部分。

三、与Hive对比
请允许我很无聊的把飞机和火车拿来做比较，因为2者根本没有深入的可比性，虽然两者都是一种高速的交通工具，但是具体的作用范围是截然不同的，就像Hive和Pig都是Hadoop中的项目，并且Hive和pig有很多共同点，但Hive还似乎有点数据库的影子，而Pig基本就是一个对MapReduce实现的工具(脚本)。两者都拥有自己的表达语言，其目的是将MapReduce的实现进行简化，并且读写操作数据最终都是存储在HDFS分布式文件系统上。看起来Pig和Hive有些类似的地方，但也有些不同，来做一个简单的比较，先来看一张图：

查看大图请点击这里

再让我说几句废话：
Language
在Hive中可以执行  插入/删除 等操作，但是Pig中我没有发现有可以 插入 数据的方法，请允许我暂且认为这是最大的不同点吧。

Schemas
Hive中至少还有一个“表”的概念，但是Pig中我认为是基本没有表的概念，所谓的表建立在Pig Latin脚本中，对与Pig更不要提metadata了。

Partitions
Pig中没有表的概念，所以说到分区对于Pig来说基本免谈，如果跟Hive说“分区”(Partition)他还是能明白的。

Server
Hive可以依托于Thrift启动一个服务器，提供远程调用。 找了半天压根没有发现Pig有这样的功能，如果你有新发现可以告诉我，就好像有人开发了一个Hive的REST

Shell
在Pig 你可以执行一些个 ls 、cat 这样很经典、很cool的命令，但是在使用Hive的时候我压根就没有想过有这样的需求。

Web Interface
Hive有，Pig无

JDBC/ODBC
Pig无，Hive有

四、使用
1启动/运行 
分为2台服务器,一台作为pig的服务器，一台作为hdfs的服务器。
首先需要在pig的服务器上进行配置，将pig的配置文件指向hdfs服务器，修改pig/conf目录下的
 vim /work/pig/conf/pig.properties
 添加以下内容：
fs.default.name=hdfs://192.168.1.201:9000/    #指向HDFS服务器
mapred.job.tracker=192.168.1.201:9001          #指向MR job服务器地址

如果是第一次运行请在Hadoop的HDFS的服务器上创建root目录，并且将etc目录下的passwd文件放在HDFS的root目录下，请执行以下两条命令。
hadoop fs -mkdir /user/root
hadoop fs -put /etc/passwd /user/root/passwd

创建运行脚本，用vim命令在pig的服务器上创建javabloger_testscript.pig 文件，内容如下：
LoadFile = load 'passwd' using PigStorage(':');
Result = foreach LoadFile  generate $0 as id;
dump Result;

运行pig脚本，例如:pig javabloger_testscript.pig，执行状态如图所示：

执行结果：

2.java 代码  运行并且打印运行结果
import java.io.IOException;
import java.util.Iterator;

import org.apache.pig.PigServer;
import org.apache.pig.data.Tuple;

public class  LocalPig {
    public static void main(String[] args) {
        try {
            PigServer pigServer = new PigServer("local");
            runIdQuery(pigServer, "passwd");
        } catch (Exception e) {
        }
    }

    public static void runIdQuery(PigServer pigServer, String inputFile)  throws IOException {
        pigServer.registerQuery("LoadFile = load '" + inputFile+ "' using PigStorage(':');");
        pigServer.registerQuery("Result = foreach A generate $0 as id;");
        Iterator<Tuple> result = pigServer.openIterator("Result ");
        while (result.hasNext()) {
               Tuple t = result.next();
               System.out.println(t);
            }
//        pigServer.store("B", "output");
       
    }
}

–end–

   对于Google简单搜索的页面而言后端服务器数量是超级庞大的，有最新统计资料显示Google全球的计算机数量加起来有1000w台，这样的一个庞大而复杂的计算系统，当然是要有一套强大的体系支撑，其中最最著名的就是Google的文件系统简称GFS(Google File System)，在这个GFS上存放了Google所有的数据，例如：你Gmail中的数据就放在上面了跑着。目前据Google保守估计有200个的GFS集群，其中有些集群的服务器数量超过5000台。

   在Yahoo默认了若干年后，一个小孩在纸上画了一个大象，激发了Doug Cutting这位大牛人的灵感，决定采用他儿子画的那只小象作为Hadoop项目的吉祥物， Doug Cutting是 Lucene 的创始人，也是Hadoop项目的创始人， Doug Cutting创造的Hadoop是一个用Java语言实现的软件框架，他在看了Google的几篇论文以后就在硬生生的把Google这些牛x的分技术都山寨了一把， 例如：HDFS类似Google的GFS，HBase类似Google的BigTable，Zookeeper类似Google的Chubby，pig类似Google的Sawzall。我列了一下Google被Yahoo 和 Doug Cutting 山寨的产品列表，如图所示：

查看大图请点击这里

通过Hadoop的开源项目对分布式计算进行简化可以让更多的人可以体验到分布式计算和云计算的快乐和价值，在此向Doug Cutting致敬。
 

相关文章:
Hbase入门6 -白话MySQL(RDBMS)与HBase之间
Lily-建立在HBase上的分布式搜索
MySQL向Hive/HBase的迁移工具
HBase入门5(集群) -压力分载与失效转发
Hive入门3–Hive与HBase的整合
HBase入门篇4
HBase入门篇3
HBase入门篇2-Java操作HBase例子
HBase入门篇
基于Hbase存储的分布式消息(IM)系统-JABase
 

–end–

先来回顾一下HBase主要部件：
   1.HBaseMaster 
   2.HRegionServer
   3.HBase Client
   4.HBase Thrift Server
   5.HBase REST Server

HBaseMaster
    HMaster 负责给HRegionServer分配区域,并且负责对集群环境中的HReginServer进行负载均衡，HMaster还负责监控集群环境中的HReginServer的运行状况，如果某一台HReginServer down机，HBaseMaster将会把不可用的HReginServer来提供服务的HLog和表进行重新分配转交给其他HReginServer来提供，HBaseMaster还负责对数据和表进行管理，处理表结构和表中数据的变更，因为在 META 系统表中存储了所有的相关表信息。并且HMaster实现了ZooKeeper的Watcher接口可以和zookeeper集群交互。

HRegionServer
    HReginServer负责处理用户的读和写的操作。HReginServer通过与HBaseMaster通信获取自己需要服务的数据表，并向HMaster反馈自己的运行状况。当一个写的请求到来的时候，它首先会写到一个叫做HLog的write-ahead log中。HLog被缓存在内存中，称为Memcache，每一个HStore只能有一个Memcache。当Memcache到达配置的大小以后，将会创建一个MapFile，将其写到磁盘中去。这将减少HReginServer的内存压力。当一起读取的请求到来的时候，HReginServer会先在Memcache中寻找该数据，当找不到的时候，才会去在MapFiles 中寻找。

HBase Client
    HBase Client负责寻找提供需求数据的HReginServer。在这个过程中，HBase Client将首先与HMaster通信，找到ROOT区域。这个操作是Client和Master之间仅有的通信操作。一旦ROOT区域被找到以后，Client就可以通过扫描ROOT区域找到相应的META区域去定位实际提供数据的HReginServer。当定位到提供数据的HReginServer以后，Client就可以通过这个HReginServer找到需要的数据了。这些信息将会被Client缓存起来，当下次请求的时候，就不需要走上面的这个流程了。

HBase服务接口
    HBase Thrift Server和HBase REST Server是通过非Java程序对HBase进行访问的一种途径。
 

进入正题

先来看一个HBase集群的模拟环境，此环境中一共有4台机器，分别包含 zookeeper、HBaseMaster、HReginServer、HDSF 4个服务，为了展示失效转发的效果HBaseMaster、HReginServer各有2台，只是在一台机器上即运行了HBaseMaster，也运行了HReginServer。
注意，HBase的集群环境中HBaseMaster只有失效转发没有压力分载的功能，而HReginServer即提供失效转发也提供压力分载。

服务器清单如下：
    1、zookeeper               192.168.20.214
    2、HBaseMaster         192.168.20.213/192.168.20.215
    3、HReginServer         192.168.20.213/192.168.20.215
    4、HDSF                         192.168.20.212

整个模拟环境的架构如图所示：

注意，这里只是做了一个模拟环境，因为这个环境的重点是HBase，所以zookeeper和HDFS服务都是单台。

虽然说在整个HBase的集群环境中只能有一个HMaster，可是在集群环境中HMaster可以启动多个，但真正使用到的HMaster Server只有一个，他不down掉的时候，其他启动的HMaster Server并不会工作，直到与ZooKeeper服务器判断与当前运行的HMaster通讯超时，认为这个正在运行的HMaster服务器down掉了，Zookeeper才会去连接下一台HMaster Server。

简单来说,如果运行中HMaster服务器down掉了，那么zookeeper会从列表中选择下一个HMaster 服务器进行访问，让他接管down掉的HMaster任务，换而言之，用Java客户端对HBase进行操作是通过ZooKeeper的，也就是说如果zookeeper集群中的节点全挂了 那么HBase的集群也挂了。本身HBase并不存储中的任何数据 真正的数据是保存在HDFS上，所以HBase的数据是一致的，但是HDFS文件系统挂了，HBase的集群也挂。

在一台HMaster失败后，客户端对HBase集群环境访问时，客户端先会通过zookeeper识别到HMaster运行异常，直到确认多次后，才连接到下一个HMaster，此时，备份的HMaster服务才生效，在IDE环境中的效果，如图所示：

上图中能看见抛出的一些异常和name:javahttp://www.javabloger.com和name:javahttp://www.javabloger.com1的结果集，因为我在serv215机器上用killall java命令把 HMaster和HReginServer都关掉，并且立刻用Java客户端对HBase的集群环境进行访问有异常抛出，但是retry到一定次数后查询出结果，前面已经说了访问HBase是通过zookeeper再和真正的数据打交道，也就是说zookeeper接管了一个standby 的 HMaster，让原先Standby的HMaster接替了失效的HMaster任务，而被接管的HBaseMaster再对HReginServer的任务进行分配，当 HReginServer失败后zookeeper会通知 HMaster对HReginServer的任务进行分配。这样充分的说明了HBase做到了实效转发的功能。
如图所示：

 

口水：
1、HBase的失效转发的效率比较慢了，不指望能在1-2秒切换和恢复完毕，也许是我暂时没有发现有什么参数可以提高失效转发和恢复过程的速度，将来会继续关注这个问题。
2、在官方网站上看见HBase0.89.20100924的版本有篇讲述关于数据同步的文章，我尝试了一下在一台机器上可以运行所谓的HBase虚拟集群环境，但是切换到多台机器的分布式环境中，单点失效转发的速度很慢比HBase0.20.6还要慢，我又检查了是否存在网络的问题，目前尚未找到正确的答案，对与HBase0.89.20100924 新版中的数据同步的原理，如图所示：(更多信息)

可以留言或者发邮件与我交流，我的联系方式是:njthnet  # gmail.com

相关文章：
 HBase入门篇4
 HBase入门篇3
 HBase入门篇2
 HBase入门篇
 Hive入门3–Hive与HBase的整合

–end–
 

高清无码的屏幕截图

还有2张照片，（请忽略我贴在书桌上乱写乱画的小纸片。。。）

配置：GIGABYTE GA-G31M-ES2C主板(声卡/显卡集成)、3G内存、250G硬盘、Dell 19寸的显示器+Dell键盘鼠标。

–end–

  说白了XML-RPC其实就是一个通过xml协议实现的远程方法调用，XML-RPC的全称是XML Remote Procedure Call，在我看来是一个非常简单的WebService的实现，只要在服务端自己写一个类，构造一个方法，实现自己需要的业务逻辑，再通过一个配置文件指明其中映射的关系，例如：配置文件中的Calculator=com.demo.xmlrpc.DataHandler描述，客户端指明在服务端配置文件需要调用的对象名称和方法名称即可进行数据传输和通讯了，这种远程过程调用使用http作为传输协议，XML作为传送信息的编码格式。Xml-RPC的定义尽可能的保持了简单，但同时能够传送、处理、返回复杂的数据结构。原理如图所示：

服务端代码示例：
WebServer webServer = new WebServer(8080);
XmlRpcServer xmlRpcServer = webServer.getXmlRpcServer();
PropertyHandlerMapping phm = new PropertyHandlerMapping();
phm.load(Thread.currentThread().getContextClassLoader(), "DataHandlers.properties");

客户端代码示例：
XmlRpcClientConfigImpl config = new XmlRpcClientConfigImpl();
config.setServerURL(new URL("http://127.0.0.1:8080"));
XmlRpcClient client = new XmlRpcClient();
client.setConfig(config);
List<String> list = new ArrayList<String> ();
list.add( "data1" );list.add( "data2" );list.add( "data3" );
Object result = client.execute("Calculator.getRequestData", new Object[]{list   } );

业务逻辑代码示例：
public int getRequestData( List<String> list){
        System.out.println("\nServer Side print:");
        for (int i=0;i<list.size();i++){
            System.out.println(list.get(i));
        }
        return list.size();
    }

配置文件示例：
Calculator=com.demo.xmlrpc.DataHandler

运行程序：
  1.运行服务端，启动的默认端口为8080，
  2.客户端通过代码中的 client.execute(……)方法，传入 ("映射名称.方法名称",入参数据)即可。
  3.服务端会打印出通过业务逻辑代码循环出的一组数据，客户端会显示出传入参数的个数。
效果如图所示：

XML-RPC与Web容器集成
可以将XML-RPC的服务端写成Servlet集成在Tomcat或者Jetty中， 将并发和会话等资源相关的问题，交给web容器去处理，因为XML-RPC中启动的web Server毕竟是一个嵌入式的，只能处理非大量的请求。 在服务端还是2个程序1个配置文件：1.继承XmlRpcServlet (extends XmlRpcServlet) 写一个servlet，2.业务逻辑程序。3.创建一个配置文件跟上面的方法一样。

此时，在XML-RPC与Web容器集成的环境中web工程下的web.xml文件扮演了重要的角色。
xml-rpc中的web.xml示例：
	<servlet>
		<servlet-name>XmlRpcServlet</servlet-name>
		<servlet-class>com.javabloger.demo.xmlrpc.RpcServer</servlet-class>
		<init-param>
			<param-name>enabledForExtensions</param-name>
			<param-value>true</param-value>
		</init-param>
		<init-param>
			<param-name>configFile</param-name>
			<param-value>DataHandlers.properties</param-value>
		</init-param>
	</servlet>
	<servlet-mapping>
		<servlet-name>XmlRpcServlet</servlet-name>
		<url-pattern>/xmlrpc</url-pattern>
	</servlet-mapping>
在web.xml文件中需要定义了这些内容：1.服务端的servlet 2.xml-rpc中的配置文件3.url的站点路径。

XLM-RPC的数据类型
只能支持Java中最基本的一些基本类型，例如：Integer、String、Double 等，详见：http://ws.apache.org/xmlrpc/types.html

扩展话题
rpc-xml不支持对象的传递，只支持String、List、Map 等一些Java中基本的数据类型，如果要传递自定义的对象(POJO)可以将这组对象转化成XML格式用Stringbuffer拼装起来，服务端再将传入的字符型xml字符串解析成一个或者一组对象，结合 Xstream开源框架完成一个对XML-RPC自定义对象(POJO)传递的扩展应用。另外在XML-RPC的客户端中还可以设置对http server的用户名和秘密验证以及gzip压缩和编码的定义，例如：basicUserName，basicPassword、basicEncoding，gzipCompressing 等。

文中代码示例下载
http://javabloger-mini-books.googlecode.com/files/xml-rpc.zip

–end–

立场
    大公司找我们做生意，必然是一笔大买卖，无论是公司还是我自己对这个项目的重视程度都很高，丝毫不敢怠慢整个人和整个事。而对方希望通过技术大牛给我们1-2次的播种 能很快的看见做出东东，对于时间概念完全等同于金钱。

沟通
    外国人也好，外企也罢，就是让你觉得沟通起来比较简单，1和0，黑和白，讲究的就是效率，不会跟你绕什么弯子。看的就是你的执行力。
       
迎战
    兄弟们个个都是铁打的，让我感觉到没人愿意闲着，都在加班加点的做技术预研，系统分析，风险评估，不亦乐乎。

借兵
    Oh，No！不是我向其他部门的兄弟借兵，是其他部门的兄弟向过来借兵，上头的旨意，一个字借！没有什么话多问的。

 
牛逼闪闪的大牛，牛逼闪闪的客户，我们能做出牛逼闪闪的产品乎？拭目以待吧。

口水：
   以本职工作为主，只好放慢关于Hadoop项目的研究了。
 

最后，再来一个跟项目有关小科普 ：闪信。

以上内容，纯属虚构，如同雷同，纯属巧合。

–end–

口水：
 对 hive_hbase-handler.jar 这个东东还有点兴趣，有空来磋磨一下。

一、2个注意事项：
1、需要的软件有 Hadoop、Hive、Hbase、Zookeeper，Hive与HBase的整合对Hive的版本有要求，所以不要下载.0.6.0以前的老版本，Hive.0.6.0的版本才支持与HBase对接，因此在Hive的lib目录下可以看见多了hive_hbase-handler.jar这个jar包，他是Hive扩展存储的Handler ，HBase 建议使用 0.20.6的版本，这次我没有启动HDFS的集群环境，本次所有测试环境都在一台机器上。
    
2、运行Hive时，也许会出现如下错误，表示你的JVM分配的空间不够，错误信息如下：
Invalid maximum heap size: -Xmx4096m
The specified size exceeds the maximum representable size.
Could not create the Java virtual machine.

解决方法：
/work/hive/bin/ext# vim util/execHiveCmd.sh 文件中第33行
修改，
HADOOP_HEAPSIZE=4096
为
HADOOP_HEAPSIZE=256

另外，在 /etc/profile/ 加入 export $HIVE_HOME=/work/hive

二、启动运行环境
1启动Hive
hive –auxpath /work/hive/lib/hive_hbase-handler.jar,/work/hive/lib/hbase-0.20.3.jar,/work/hive/lib/zookeeper-3.2.2.jar -hiveconf hbase.master=127.0.0.1:60000
加载 Hive需要的工具类，并且指向HBase的master服务器地址，我的HBase master服务器和Hive运行在同一台机器，所以我指向本地。

2启动HBase
/work/hbase/bin/hbase master start

3启动Zookeeper
/work/zookeeper/bin/zkServer.sh start

三、执行
在Hive中创建一张表，相互关联的表
CREATE TABLE hbase_table_1(key int, value string) STORED BY 'org.apache.hadoop.hive.hbase.HBaseStorageHandler' WITH SERDEPROPERTIES ("hbase.columns.mapping" = ":key,cf1:val") TBLPROPERTIES ("hbase.table.name" = "xyz");

在运行一个在Hive中建表语句，并且将数据导入
建表
    CREATE TABLE pokes (foo INT, bar STRING);
数据导入
    LOAD DATA LOCAL INPATH '/work/hive/examples/files/kv1.txt' OVERWRITE INTO TABLE pokes;

在Hive与HBase关联的表中 插入一条数据
    INSERT OVERWRITE TABLE hbase_table_1 SELECT * FROM pokes WHERE foo=98;
运行成功后，如图所示：

插入数据时采用了MapReduce的策略算法，并且同时向HBase写入，如图所示：

在HBase shell中运行 scan 'xyz' 和describe "xyz" 命令，查看表结构，运行结果如图所示：

xyz是通过Hive在Hbase中创建的表，刚刚在Hive的建表语句中指定了映射的属性 "hbase.columns.mapping" = ":key,cf1:val"  和 在HBase中建表的名称 "hbase.table.name" = "xyz"

在hbase在运行put命令，插入一条记录
    put 'xyz','10001','cf1:val','www.javabloger.com'

在hive上运行查询语句，看看刚刚在hbase中插入的数据有没有同步过来，
    select * from hbase_table_1 WHERE key=10001;
如图所示：

最终的效果
    以上整合过程和操作步骤已经执行完毕，现在Hive中添加记录HBase中有记录添加，同样你在HBase中添加记录Hive中也会添加， 表示Hive与HBase整合成功，对海量级别的数据我们是不是可以在HBase写入，在Hive中查询 喃？因为HBase 不支持复杂的查询，但是HBase可以作为基于 key 获取一行或多行数据，或者扫描数据区间，以及过滤操作。而复杂的查询可以让Hive来完成，一个作为存储的入口(HBase)，一个作为查询的入口(Hive)。如下图示。
   
    
    呵呵，见笑了，以上只是我面片的观点。

先这样，稍后我将继续更新，感谢你的阅读。

相关文章：
 Apache Hive入门2
 Apache Hive入门1

 HBase入门篇4
 HBase入门篇3
 HBase入门篇2
 HBase入门篇

–end–

以上是我对 Hive Why(为什么使用Hive)片面的观点。
 

集群中的Hive
Hive的失效转发可以设计成这样的，将元数据和存储的数据分别保存在同一个位置，如图所示：

多个Hive的物理节点连接到相同的数据库和HDFS环境,防止Hive Thrift Server单点失效(SPFO)问题。

将Hive的MetaData 存储在 MySQL中，MySQL的运行环境支持双向同步或者集群，这样至少2台数据库服务器上热备份着Hive的元数据存储,例如:
<property>
  <name>javax.jdo.option.ConnectionURL</name>
  <value>jdbc:mysql://192.168.1.203:3306/hive?createDatabaseIfNotExist=true</value>
</property>

多个物理Hive节点的数据内容保存在HDFS上，通过修改 hive-default.xml 配置 文件，指向NameNode节点即可，例如：
<property>
  <name>hive.metastore.warehouse.dir</name>
   <value>hdfs://serv1:9000/user/hive/warehouse</value>
   <!– <value>/user/hive/warehouse</value> –>
  <description>location of default database for the warehouse</description>
</property>

Hive 与 Log4J
在Hive中建一张表叫user_log，里面含有4个字段，以\t划分，一行一条数据，建表的脚本如下：
CREATE TABLE USER_LOG(DateInfo STRING,LogName STRING,LogLevel STRING,MSG STRING)
ROW FORMAT DELIMITED FIELDS TERMINATED BY '\t' LINES TERMINATED BY '\n' STORED AS TEXTFILE;

在Log4J的日子输出格式中每个栏目以Tab相隔开，中间不是空格而是Tab，例如：
log4j.appender.A1.layout.ConversionPattern=%d    %-6p    %l %m  %n

输入数据文件格式如下：

 
在Hive的控制台下将Log4J输出的日志文件导入Hive中，操作结果如下，如图所示：

在建表语句中还可以加入正则表达式，的自定义功能都在contrib里面， 例如：将WEB日志先用正则表达式进行组合，再按需要的条件进行组合输入到表中
add jar ../build/contrib/hive_contrib.jar;
CREATE TABLE apachelog (
host STRING,
identity STRING,
user STRING,
time STRING,
request STRING,
status STRING,
size STRING,
referer STRING,
agent STRING)
ROW FORMAT SERDE 'org.apache.hadoop.hive.contrib.serde2.RegexSerDe'
WITH SERDEPROPERTIES (
"input.regex" = "([^ ]*) ([^ ]*) ([^ ]*) (-|\\[[^\\]]*\\]) ([^ \"]*|\"[^\"]*\") (-|[0-9]*) (-|[0-9]*)(?: ([^ \"]*|\"[^\"]*\") ([^ \"]*|\"[^\"]*\"))?",
"output.format.string" = "%1$s %2$s %3$s %4$s %5$s %6$s %7$s %8$s %9$s"
)STORED AS TEXTFILE;

对于Hive的学习方向：
1、hive 的 hive-default.xml 配置文件中的参数细节，主要针对Hive的性能优化。
2、Hive 是如何使用MapReduce来完成工作的整套机制。
 

我的口水，目前使用Hadoop产品的国内外公司有如下一些：
Facebook
    处理内部产生的日志和数据挖掘、展示以及机器学习
IBM
    用Hadoop MapReduce 分析billions of lines of GPS data 并产生交通路线资讯.
Krugle
    用Hadoop and Nutch 建构原始码搜寻引擎
SEDNS – Security Enhanced DNS Group
    收集全世界的DNS 以探索网路分散式内容.
Technical analysis and Stock Research
    分析股票资讯
University of Nebraska Lincoln, Research Computing Facility
    用Hadoop跑约200TB的Compact Muon Solenoid经验分析紧凑渺子线圈,该机构是为瑞士欧洲核子研究组织CERN的大型强子对撞器计划的两大通用型粒子侦测器中的一个。
Yahoo!
    使用Hadoop平台来发现发送垃圾邮件的僵尸网络
趋势科技
    过滤像是钓鱼网站或恶意连结的网页内容
还有以前提到过的：A9.com、ImageShack、Last.fm、Powerset、纽约时报
 
在国内使用Hadoop的公司有：
淘宝、中国移动研究院、英特尔研究院、金山软件、百度、腾讯、新浪、搜狐。

相关文章：
Apache Hive入门1

–end–

Hive 元数据存储
    Hive 将元数据存储在 RDBMS 中，有三种模式可以连接到数据库：

    Single User Mode： 此模式连接到一个 In-memory 的数据库 Derby，一般用于 Unit Test，如图1
                            
   Multi User Mode：通过网络连接到一个数据库中，是最经常使用到的组合模式，如图2
                            
   Remote Server Mode：用于非 Java 客户端访问元数据库，在服务器端启动一个 MetaStoreServer，客户端利用 Thrift 这个东东 通过 MetaStoreServer 访问元数据库。如图3
                           

Hive 的启动方式
    hive  命令行模式，直接输入/hive/bin/hive的执行程序，或者输入 hive –service cli
    hive  web界面的启动方式，hive –service hwi 
    hive  远程服务 (端口号10000) 启动方式，nohup hive –service hiveserver  &

Hive的SQL
建表
    CREATE TABLE javabloger (foo INT, bar STRING); 
插入
    LOAD DATA LOCAL INPATH '/work/hive/examples/files/kv1.txt' OVERWRITE INTO TABLE javabloger;
查询
    SELECT a.* FROM javabloger a;

Hive使用MySQL存放元数据
    可以参考一下这篇文章
    http://www.mazsoft.com/blog/post/2010/02/01/Setting-up-HadoopHive-to-use-MySQL-as-metastore.aspx 
    别忘了下载 MySQL 的JDBC驱动，推荐下载 mysql-connector-java-5.1.11.tar.gz
  
Hive 与 JDBC
导入hive\lib下的所有jar包到IDE的classpath里面，还有hadoop中的 hadoop-0.20.2-core.jar包，即可运行下列代码：

package com.javabloger.hive;

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.Statement;

public class HiveTestCase {

    public static void main(String[] args) throws  Exception {
        Class.forName("org.apache.hadoop.hive.jdbc.HiveDriver");
       
        String dropSQL="drop table javabloger";
        String createSQL="create table javabloger (key int, value string)";
        String insterSQL="LOAD DATA LOCAL INPATH '/work/hive/examples/files/kv1.txt' OVERWRITE INTO TABLE javabloger";
        String querySQL="SELECT a.* FROM javabloger a";
       
        Connection con = DriverManager.getConnection("jdbc:hive://192.168.20.213:10000/default", "", "");
        Statement stmt = con.createStatement();
        stmt.executeQuery(dropSQL);  // 执行删除语句
        stmt.executeQuery(createSQL);  // 执行建表语句
        stmt.executeQuery(insterSQL);  // 执行插入语句
        ResultSet res = stmt.executeQuery(querySQL);   // 执行查询语句
       
          while (res.next()) {
            System.out.println("Result: key:"+res.getString(1) +"  –>  value:" +res.getString(2));
        }

    }

}

Hadoop学习之旅正在进行中，正在走向Hive的路上，目前只对Hive一些简单的操作和整体结构有所了解，更深入的知识正在学习ing。。。。

相关文章：
Hive入门3–Hive与HBase的整合
Apache Hive入门2
Apache Hive入门1

–end–

Zookeeper用来同步Hbase服务状态、监控集群防止单点失效
HDFS是Hadoop中最核心的一部分,用来对Hbase的数据进行存储

1、Zookeeper客户端与服务端的大致结构
   服务端
    Zookeeper还是属于一个C/S的架构的应用服务，Zookeeper的服务器端分为2种运行模式：单台和集群多台的运行模式，通过conf/zoo.cfg中的配置判定你启用的运行模式，以及在群集模式中数据同步和心跳的频率等等。
   Zookeeper集群中的Leader和Follower之间的选举通过Paxos算法来实现的，它是一个基于消息传递的一致性算法，这里讲述了http://zh.wikipedia.org/zh-cn/Paxos算法，传说中Paxos算法是分布式一致性算法中最有效的一种算法。
口水:在源代码中的通讯部分看见了大量采用NIO和concurrent的代码(例如:LinkedBlockingQueue/AtomicLong)。

  客户端
ZooKeeper的Client由三个主要模块组成：
Zookeeper
    Zookeeper是最主要的类，可以写入一个或者多个Zookeeper的服务器地址，例如："127.0.0.1:3000,127.0.0.1:3001,127.0.0.1:3002" ，当你new Zookeeper( ….)的时候会有两个线程被创建：SendThread和EventThread，会在Server端创建大量的Session。
WatcherManager
    在Zookeeper类中还有一个WatcherManager，用来管理Watcher的，Watcher是ZK的一大特色功能，允许多个Client对一个或多个 ZNode进行监控，当ZNode有变化时能够通知到监控这个ZNode的各个Client，管理了ZK Client绑定的所有Watcher。
ClientCnxn
    在Zookeeper类中还包含了对ClientCnxn类的调用，ClientCnxn这个类管理所有对Zookeeper服务器端的网络通讯，服务端和客户端所有交互的数据都要调用这个类，包括给ZK Server发送Request，从ZK Server接受Response，以及从ZK Server接受Watcher Event。

2、服务端运行模式
服务端单机模式
    zoo.cfg文件配置参数详解
    # 这个时间是被用来做服务器之间或客户端与服务器心跳和最低会话超时时间的基数。
    tickTime=2000
    # 存储在内存中数据快照的目录。
    dataDir=d:/zookeeperdata/1
    # 服务器端开启的监听端口，用来接受客户端访问请求的端口。
    clientPort=2181

服务端集群模式
    配置参数详解
     #Zookeeper服务器集群中连接到Leader与Follower 服务器少次心跳时间间隔数，以及最大通讯的超时时间，总时间为 5(initLimit)*2000(tickTime)=10 秒。
     initLimit=5
     #Leader与Follower间请求/应答时间长度,这里总时间长度就是 2(syncLimit)*2000(tickTime)=4 秒。
     syncLimit=2
     #server是固定配置，1和2表示这个是第几号服务器，2888:3888表示服务器与集群中的 Leader 服务器的通讯端口。
     server.1=192.168.1.1:2888:3888
     server.2=192.168.1.2:2888:3888

另外，集群模式下还要在 dataDir 目录下创建一个myid文件，这个文件中写入的内容就是一个数字，这个数字就是和server.x中的x这个数字对应，Zookeeper 启动时会读取这个文件判定自己是谁，myid文件的编码格式是ANSI。
 

相关文章：
Apache ZooKeeper入门2
Apache Zookeeper入门1

–end–

内容提要：

   本期内容主要对JavaEE中的JMS话题进行讲述，其中一些文章是我们经过了很多错/败与大量的测试总结出的经验和心得，所以拿来与大家分享。

   在大型系统中不仅仅要考虑JMS服务器端或者JMS客户端消息收/发的效率和性能，在系统架构设计方面还需要考虑到JMS服务器的可扩展性、伸缩性、容错性。在设计时如何巧妙的将JMS的性能提高，如何充分发挥JMS所有的功能，如何提高JMS服务器的容错能力 等等，都是我们一线架构师们需要思考的话题。

   对于JMS服务器的每一项参数必须在投入使用前理解的明明白白，做到一旦出现关于JMS的问题能迅速定位，提供开发团队解决问题的明确思路。我在此感谢我们技术团队的所有同仁，没有你们的投入与陪伴，不会让我有机会遇见各种形形色色的问题，也不会让我对JMS产品去深入的了解与提高。
 

下载地址:
http://javabloger-mini-books.googlecode.com/files/Java-JMS-Javabloger-mini-book.pdf

其他资源:
http://code.google.com/p/javabloger-mini-books/downloads/list

–end–

口水：
Hive数据仓库工具是Hadoop中的一个子项目，Hadoop中的子项目还包括Zookeeper分布式锁，提供类似Google Chubby的功能，我在前面几篇文章中也有提到过关于Zookeeper的应用 ，在Hadoop大型计算中Zookeeper与他们密不可分。

   Facebook是Hadoop的忠实用户和贡献源码的参与者，并且Facebook还贡献了Hive和Thrift两个重要Hadoop组件，目前已经收入在Apache的Hadoop的子项目中，Hive是基于 Hadoop DFS的 adhoc query system，定义了HQL语言，基于MapReduce实施查询但是别指望性能有多么的高，Thrift是Hadoop的跨语言接口，可以支持多种语言，例如php和ruby。

  除了Yahoo!和FaceBook两大站点在大量使用超过10,000个微处理器核心的Linux计算机集群运行Hadoop，还有A9.com、 IBM 、 ImageShack、 Last.fm、Powerset、 纽约时报 等 也在使用 Hadoop系统。

   在国内百度也是一个Hadoop的忠实用户，传说中百度的Hadoop的运行节点达到了2000个左右，并且采用SSD硬盘对Hadoop的数据进行存储。还有淘宝，在淘宝的数据库团队的博客上我看见过几篇介绍使用 Hive和Hadoop的经验分享，但是不知道他们的具体使用情况(或者我没有注意到)。

  Facebook目前全球用户数量有5亿，每天有超过一半以上的用户进行登录，每月处理超过250亿的信息内容其中包括用户状态更新，评论等，替代以前Oracle的RAC，Facebook从两个主要的数据源输入数据到Hadoop集群。他们使用开源的Scribe上传工具从Web集群载入数据，每10到15分钟就从成千上万的机器传输数据。他们每天还从系统记录载入数据，一个超过2000节点的MySQL联合集群。这些数据包括概要文件，好友信息，以及广告和广告推广信息。

  将来 FaceBook 会把数据库直接写到 Hive上，Hadoop和Hive 最基本的设计思想和传统数据库存储最大的不同是基于列的存储模式，这样可以让更多的开发人员去使用Hive系统。已知Facebook在DFS中存储的数据达到22T，目前肯定更大了。

上面这张图告诉我们采用哪些组件是用来处理数据 ，显示了FaceBook对于Hadoop架构的基本组成部分和数据流。

  Facebook的工程师邵铮(2008年3月加入facebook,现居加州) 介绍在2009年一次技术会议上说到，Facebook是采用 自主研发的 Hive 把用户每一个用户操作的行为习惯记录下来，便于Facebook内部分析师更好的从用户使用的行为习惯去分析用户需求，对于Hive/Hadoop的使用并不是意味着将会完全放弃原来传统的数据库(Oracle/MySQL)，而且把Hadoop/Hive看做是数据库仓库的和应用操作层的交集。据说现在在开发支持JDBC和ODBC的接口，我记得他当时说到：“Facebook计算节点上Hadoop节点有600个集群的节点，每个机器的2个CPU，将来会达到1000台节点”，这里有一个相关的视频介绍.

  今年五月份(2010/5)，一位Facebook工程师 Dhruba Borthakur 说到，“Facebook是当今使用Hadoop最大的用户了，这已经不是什么秘密”，并且公布了在Facebook使用Hadoop/HDFS 集群的一些详细信息：
    * 21 PB of storage in a single HDFS cluster
    * 12 TB per machine (a few machines have 24 TB each)
    * 1200 machines with 8 cores each + 800 machines with 16 cores each
    * 32 GB of RAM per machine
    * 15 map-reduce tasks per machine
    * 12 TB of compressed data added per day
    * 800 TB of compressed data scanned per day
    * 25,000 map-reduce jobs per day
    * 65 millions files in HDFS
    * 30,000 simultaneous clients to the HDFS NameNode

这位老兄的言词不能排除有点自大和水分，但是我们至少能看出Facebook是怎么对Hadoop进行使用和部署的状态。

    FaceBook的数据和日志是海量的，需要FaceBook有一套出色的系统来支撑他们每日已TB级别为单位的增长的数据，据说，现在Facebook每天的新数据量最高可以达到20TB。对于这样环境的数据处理平台的关键要求是能够能够迅速做出响应，系统在整个运营和构建的过程中不得不需要考虑到投入的成本，同时还需要考虑系统非常高可靠的性、易于使用和维护，这不是一件容易的事情。

–end–

JMS在J2EE系统中的应用场景

   异步消息比同步消息操作更加便利。在J2EE系统中最常见的一个场景，前端浏览器 jsp/servlet向服务器端发出一个请求，jsp/servlet将请求传递给后端的应用程序处理业务逻辑，业务模块将响应的结果直接返回给客户端，而不是真正的计算结果，例如一个网站的用户注册功能，一个用户点击注册以后，将会发送一份邮件给他当时的注册邮箱，如果需要等到邮件发送成功再返回给用户结果的话，用户体验将会很差，所以将结果直接返回给用户，将用户注册的信息通过消息发送给后端程序慢慢处理。

点击这里查看大图

谈到 JMS一词 大体上有 3个部分  1 消息发送端  2中间件服务器  3消息接收端  3个组件缺一不可。 JMS消息分为两种消息模式，点对点和发布者/订阅者。许多提供商支持这一因此，程序员可以在他们的分布式软件中实现面向消息的操作，这些操作将具有不同面向消息中间件产品的可移植性。
 

Java消息服务器是指，将数据通过消息作为载体在网络中从一个系统异步传送给另一个系统。这样的异步消息传送意味着：发送者不需要等待接收者接收或处理该消息；它可以自由地发送消息并持续进行处理。这样一个异步式的架构主要依赖于一台消息服务器（message server）。消息服务器，也称为消息路由器（message router）或代理（broker），它负责从一个消息传送客户端向其他消息传送客户端传送消息。

JMS对与一个大型系统是必不可少的一个应用组件，可以利用JMS来实现3个目的：
            1.提高可伸缩性(Increase Scalability),
            2.可以利用JMS来缓解系统瓶颈(Reduce  Bottlenecks)
            3.提高系统对用户的响应能力

JMS公共API内部，和发送和接收JMS消息有关的JMS API接口常用的有7个：
        ·ConnectionFactory
        ·Destination
        ·Connection
        ·Session
        ·Message
        ·MessageProducer
        ·MessageConsumer
其中关键的5个部件，如图所示：

查看大图请点击这里

Topic与Queue消息的区别
    Queue是一对一的消息传送，你可以看做是QQ应用程序中的一对一发送消息，一个人发出消息，只能有另外一个人阅读的到，中间需要通过一个队列支持Queue消息发送完毕后会保存在 JMS服务器的队列中，如果接收端接收以后将从队列中摘除。如图所示：

Queue消息发送到服务器，接收端会平均接收到发送端发送过来的消息，如图所示，一次发送150个消息，3个接收端每个收到50个

查看大图请点击这里

Topic  是一对多的消息传送，你可以看做是QQ应用程序 QQ群 聊天中的一对多发送消息，一个人发出消息，可以有多个订阅的人阅读的到，需要有一个消息主题作为支柱,Tocip消息发送完毕以后 无论有没有客户端接收，JMS服务器中的Topic消息都不会存在JMS服务器中。如图所示：

发送Topic消息无论连接在JMS服务器上有多少个接收端，将会收到同样的消息，而且Topic发送完毕以后不会保留在JMS服务器，否则将会和Topic消息的设计思想相互冲突。

查看大图请点击这里

JMS消息的属性

JMS的每条消息分为 Header、Properties   、Body   3个属性 ：

Header、Properties 中包含可设置的参数，分别是：
JMSDestination   消息发送的目的地

JMSDeliveryMode  传递模式， 有两种模式： PERSISTENT 和NON_PERSISTENT，PERSISTENT 表示该消息一定要被送到目的地，否则会导致应用错误。NON_PERSISTENT 表示偶然丢失该消息是被允许的，这两种模式使开发者可以在消息传递的可靠性和吞吐量之间找到平衡点。

JMSMessageID  唯一识别每个消息的标识，由JMS Provider 产生。

JMSTimestamp  一个消息被提交给JMS Provider 到消息被发出的时间。

JMSCorrelationID  用来连接到另外一个消息，典型的应用是在回复消息中连接到原消息。

JMSReplyTo        提供本消息回复消息的目的地址

JMSRedelivered  如果一个客户端收到一个设置了JMSRedelivered 属性的消息，则表示可能该客户端曾经在早些时候收到过该消息，但并没有签收(acknowledged)。

JMSType  消息类型的识别符。

JMSExpiration   消息过期时间，等于QueueSender 的send 方法中的timeToLive 值或TopicPublisher 的publish 方法中的timeToLive 值加上发送时刻的GMT 时间值。如果timeToLive值等于零，则JMSExpiration 被设为零，表示该消息永不过期。如果发送后，在消息过期时间之后消息还没有被发送到目的地，则该消息被清除。

JMSPriority  消息优先级，从0-9 十个级别，0-4 是普通消息，5-9 是加急消息。JMS 不要求JMS Provider 严格按照这十个优先级发送消息，但必须保证加急消息要先于普通消息到达。

Body 分为以下5种：

TextMessage
    这种类型携带了一个java.lang.String作为有效负载。它可以用于简单的文本消息交换，还可以用于更复杂的字符数据交换，比如XML文档等。

ObjectMessage
    这种类型携带了一个可序列化Java对象作为有效负载。它可以用于Java对象交换。

BytesMessage
    这种类型携带了一组原始类型字节流（primitive byte）作为有效负载。它可以使用应用程序的本机格式（native format）来交换数据，这种格式可能不兼容其他现有的Message类型。当JMS纯粹用于两个系统之间的消息传送时，也可以使用这种类型，而且该消 息的有效负载对JMS客户端来说是不透明的。

StreamMessage
    这种类型携带了一个Java原始数据类型流（int、double、char等）作为有效负载。它提供了一套将格式化字节流映射为Java原始数据类型的简便方法。在以固定顺序进行原始应用数据交换时，这种模型非常易于编程实现。

MapMessage
    这种类型携带了一组名/值对（name-value pair）作为有效负载。有效负载类似�