云

敏捷、分布式、ALM过程自动化、企业应用架构
posts - 14, comments - 0, trackbacks - 0, articles - 1
  BlogJava :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理

2012年3月29日

近期HADOOP（1.0.3）实施心得与总结

Hadoop实施已经有快一个月了，对Hadoop的概念理解、使用，Linux与shell脚本，甚至mysql都有了更多的理解。


项目背景：用于互联网信息收集后的关键词匹配与内容提取。

主要系统架构分为互联网爬虫、分析、业务应用三块：

简单架构描述

由于我在当中的角色主要负责分析架构的搭建，所以其他两块都画得简单，下面也不会过多的描述。


Hadoop理解：提到Hadoop都想到的是云、分布式计算，在一段时间的实施之后有了一些具体的理解。

Hadoop的优势：

针对性能指标，当业务数据量总量或增速上升到一定级别，依靠关系型数据库一定无法支持。对于非关系型数据库，包括Nosql和Solr一类存储方式，稍显复杂，对于机器集群性能要求偏高（相对于文件系统）。从数据使用模式上来讲，目前海量数据的常常是不包含复杂逻辑的简单统计整理（比如上述系统中的关键词匹配）。这时候文件系统的优势反而比较明显（结构简单，逻辑简单）。

如上述系统的应用场景是怎么样的呢，在一个强大的爬虫系统之下，每个小时的数据增量在G到10G的级别，需要搜索所有的文件，获取关键字的匹配，并且对匹配内容进行摘要。很类似我们windows里面的搜索功能，需要解决的就是如何在这样增幅的文件系统之下，如何满足业务系统的需求。

对分析系统有什么要求呢？

l 能够建立集群，分布式的保存数据文件内容（统一控制，可配置）。

l 有一定的保护机制，保证数据或节点丢失不会影响系统使用。

l 如果有一个任务脚本执行框架机制就好了（用于并行计算）。

l 能够进行节点间的数据均衡。

l 能够简单的查看所有的状态与日志（web客户端）

可能主要是这些了。若自己实现，确实是个复杂而庞大的工程，现在我们有了Hadoop。


系统物理架构：

我们使用了一台服务器，利用虚拟化，安装了7套64x位的CentOS。一个Namenode，6个Datanode，复制数设置为3。每个系统分配到一个cpu，2G内存，Datanode挂载了500G的存储空间。

理想的Hadoop的搭建环境，参照《Best Practices for Selecting Apache Hadoop Hardware》（http://hortonworks.com/blog/best-practices-for-selecting-apache-hadoop-hardware/）一文，以及一些其他的文章。

CPU：最好是双CPU，8核左右。不用太高了。

内存：推荐48G，但是4G应该就可以运行Hadoop了。

硬盘：7200转的SATA硬盘即可，Hadoop很占空间，所以尽量加。

网络：内部的数据交换要求非常高，内网最好是千兆网卡，带宽为1GB。

理想与现实，有钱与没钱，呵呵。


系统软件架构：

Hadoop：版本使用的是1.0.3，再下来就是2了，为了尽量简化应用，所以不考虑2的新特性。对Hadoop没有做太多的设置，基本基于默认。70为Namenode，71-76为Datanode。

JDK：1.6.0_33 （64x）


系统实施过程：

HDFS部分：

爬虫抓取数据，整理后存放在50文件服务器，70以外部挂载的形式读取。网页文件比较小，假如直接写入Hadoop对Namenode负载过大，所以入库前合并，将每小时网页整合成为一个文件写入HDFS，由于区分类别，所以每小时基本写入10个文件左右，总量在5-8G，耗时在40-50分钟。（这个过程中，由于爬虫的IO过于频繁，导致文件读取困难，所以做了定时任务，每小时启动一次，将需要处理的文件先拷贝到临时区域，合并入库之后再删除。此处应该是受到单核cpu的限制，所有操作均是串行，包括拷贝（cp）和合并入库（java），所以Namenode严重建议配置稍高。）

此处没有太多问题。

MapReduce部分：

写入完成后，进行分析工作，MapReduce。此处的工作过程为：数据库定时生成关键词列表文件。Job执行时会读取列表文件，匹配指定范围内的HDFS文件（过去一小时），匹配出对应的表达式与HTML，Map过程结束。在Reduce阶段，会将Map的所有数据入数据库（Mysql）。

此处出现过一些问题，记录下来。

1. Reduce阶段需要加载Mysql的第三方驱动包。我在三个环境测试过（公司、家里、发布环境），使用 -libjars 一定可以，有的地方不需要也可以。不明确，怀疑与HADOOP_HOME环境变量有关。

2. MR过程中使用log4j打印日志，在Hadoop临时目录（如果你没有配置dfs.name.dir，dfs.data.dir,mapred.local.dir.mapred.system.dir等目录，这些都会在hadoop.tmp.dir当中，我就偷懒都没配置）mapred文件夹中查看一下。

整个过程实际上还是比较简单的，基本编码量就在Job的部分，但是一个Java文件就够了。在目前初级阶段应该还是比较好用的。现在还没有测试Job的执行效率。完成后会继续记录下来。有什么问题可以提出。我想到什么也会在本文继续更新。

posted @ 2012-08-08 20:21 一酌散千忧 阅读(582) | 评论 (0) | 编辑 收藏

Hadoop完整分布式配置方式(Fully distributed mode)

硬件资源：

三台CentOS5.6虚拟机（Vmware）

本机 windows7 64x

 

基本资源配置：

三台虚拟机均是克隆自同一个镜像

已经安装了Java环境（jdk1.6.0_25）

Hadoop路径在/usr/hadoop/hadoop-0.20.205.0

 

操作步骤：

1、机器名称规范

ip分别为128、129、130，将128设置为master，其他设置为slave

修改

/etc/sysconfig/network

/etc/hosts

两处配置，名称分别为hadoop-master\hadoop-slave01\hadoop-slave02

注意：此处名称最好不用使用下划线，有可能引发namenode的启动异常。

 

2、修改Hadoop配置 

在master节点的conf中修改master和slave文件，分别为机器的ip地址

 

修改master节点的conf中：

core-site.xml

<property>

<name>fs.default.name</name>

<value>hdfs://ip-master:9000</value>

</property>

 

mapred-site.xml

<property>

<name>mapred.job.tracker</name>                                   

<value>master:9001</value>                                

</property>

 

hdfs-site.xm

<property>

<name>dfs.replication</name>

<value>2</value>

</property>

注意此处的端口号均为默认。

 

 

3、建立m-s之间的ssh连接

首先master与slave机器都需要进行ssh信任文件生成，执行如下命令：

$ ssh-keygen -t rsa

中间需要输入的地方直接回车，接受缺省值即可

 

由于使用root用户登录，所以密钥文件生成在 /root/.ssh/文件夹下，存有一对密钥id_dsa和id_dsa.pub。

此处id_dsa（私钥）必须为其他用户不可读，所以文件属性应当是600

 

在master机器执行：

将id_dsa.pub（公钥）复制为 authorized_keys

$ cp id_dsa.pub authorized_keys

如果是多台机器需要,无密码登陆,则各自机器产生公钥追加到authorized_keys即可.

 

使用scp协议覆盖slave端的密钥文件夹，使得slave机器信任来自master的连接:

$ scp /root/.ssh/* ip-slave:/root/.ssh

 

 

4、启动服务 

建议将$HADOOP_HOME/bin下的所有文件给与执行权限：

$ chmod 777 bin

 

master作为namenod需要执行如下脚本：

$HADOOP_HOME/bin/hadoop namenode –format

 

完成后执行 $HADOOP_HOME/bin/start-all.sh

 

5、问题检查

在Hadoop根目录下的logs文件中，检查各个服务日志的启动情况

 

 

6、其他情况说明：

Q: $HADOOP_HOME is deprecated

A: 基本不会产生任何影响。由于脚本启动时设置了该环境变量，就会提示用户原有环境变量失效。可以取消环境变量设置，或者直接去bin/hadoop中找到这句话，去掉即可

 

Q: 无效的选项 -jvm / Unrecognized option: -jvm

A: 在使用root用户登录时 bin/hadoop 脚本就会进行判断，加上-jvm参数。此处是为了进入jsvc（http://commons.apache.org/daemon/jsvc.html），此处并不确定是否bug，也不再进行详细的追溯，解决方法就是进入 bin/hadoop 脚本中 找到 jvm 参数并去掉。

 

 

 

 

 

 

 

posted @ 2012-07-04 07:38 一酌散千忧 阅读(583) | 评论 (0) | 编辑 收藏

我们的用户体验真的这么差？

公司里有同事时常抱怨，项目的用户体验太差，常常挨领导的骂。大家都认为是在用户体验的设计方面，公司人员的能力和经验都不足引起的。发牢骚的时候也会说，如果公司能够请得起“淘宝”的UI设计师，咱们的系统肯定会更上一层楼。我之前也一直认为如此，即我们的设计是影响项目体验的重要原因。最近被领导调动去协助一个项目，产生了一些不一样的体会。

项目背景，一个新的产品，小型项目，纯开发人员3-4人，2名熟练开发人员，1名新手，偶尔会有协助人员。没有技术经理，项目经理身负多个项目，对项目进度关心不足，部门经理会协助进行工作和进度管理。可以看到管理还是比较混乱。

由于项目进度太慢，领导要求从我这边调一个熟练人员协助开发。我也基本了解他们的项目状况，为了不让我的人进去抓瞎，我就和他一起去了解项目情况。

项目状况比较糟糕，介入项目时已经开发了一段时间，保留的文档只有两份，一副数据库说明，一份非常粗略的需求说明，而且还与开发进度不同步，就是没有维护。

我了解了一下项目目前的难度，开发人员和我反映一个是人员熟练程度的问题，二是需求变更的问题。我整体了解了一下项目目前的需求和设计，以及进度。就挑了一个模块询问他们的变更情况，这个模块是一个关键词匹配功能。结果是领导看了他们的页面之后，嫌信息量太少，就要求提供一些更细化的数据展示。开发人员问我有什么意见，我就简单讲了一下页面大概怎么构建。其中有一个点，是用于变更数据范围，即查询的表变更，我一开始觉得使用下拉框就可以，产生了一些意见。有人建议分为不同子模块，或者tab页，或者分为多块并列展示。我想了想，就给他们讲了我认为几种方案的优点缺点及适用范围。

 

1.       多块并行展示：

多个不同范围的数据在同一页面中分为不同区域以相同形式展示。原因是由于多块数据之间有一定的关联因果关系，或值得对比。适用范围：如购物网站中的多个物品比较。

2.       Tab页：

同一个页面的多个tab页，表示多个tab页中的数据可能在一定的领域概念之下有一定的关联，但关联度不强。因为tab页更重要的是强调一个同步工作的状态，即A tab页查看一定信息，会打开B tab页查看其他信息，中途还会切回A tab页。适用范围：如邮箱中，收件箱和草稿箱。

3.       下拉框

下拉框作为查询条件的一部分，常用于有着常规或固定的可选择内容中（如性别，月份），更多是以过滤的形态出现，即下拉框更适合针对某表的某个字段过滤，如果针对的是数据范围或是对用户需要直观了解的重要业务条件则不太合适。适用范围：如在考试成绩中使用下拉框过滤“男女”或“及格不及格”。

4.       单选框

单选框与下拉框的作用范围相似，但是不同之处在于将被选项全部展示，目的在于能够让用户清楚的了解当前数据显示的实际范围或条件，以及备选的其他范围或条件。更适用于选项与实际业务及当前展示数据关系重要，不同选项可能会引发用户的不同行为。适用范围：如银行系统显示了当前用户下绑定多个帐号时，使用单选框。

 

经过上述讨论，我们仔细分析了这个模块中用户的实际需求，以及可能后续操作，最终选择的单选框的方案。

目前还没有后续，但是我想我们基于用户真是需求的挖掘和后续操作的认真分析，会让我们在与领导进行需求讨论的时候有更加充分合理的依据。

回来之后我又看了看淘宝的搜索页面，比如就搜索“鞋子”来讲，将品牌这栏设置为单选和下拉将是完全不同的效果，而确定方案的理由则是对于用户的需求和实际行为的深入研究。这个应该是需求分析和调研的结果。将搜索条件以tag的形式标注于页面上，并且可以直接点击X按钮进行删除，我觉得更加可以倾向为用户体验。满足并充分考虑了用户实际需求的是好的需求分析，能够简化并引导用户行为的是好的用户体验。

当我们面临的系统感觉非常难用的时候，往往这时候并非是用户体验差，我们应该检讨的是我们对用户需求有没有好好挖掘，做出来的是不是用户想要、用户能用的系统。

posted @ 2012-05-22 05:02 一酌散千忧 阅读(259) | 评论 (0) | 编辑 收藏

Zookeeper的学习总结

Zookeeper的核心概念：

ZNode

Znode就是核心结构，Zookeeper服务中是由大量的Znode构成。Znode一般是由客户端建立和修改，作为信息或标志的载体，甚至本身就是标志。

Znode可以设置为持久（PERSISTENT）或临时（EPHEMERAL），区别在于临时的节点若断开连接后就自动删除。建立节点时可选择是否使用序列号命名（SEQUENTIAL），若启用则会自动在节点名后加入唯一序列编号。

Session

作为客户端和Zookeeper服务之间交互的凭证。

Watch

当客户端对节点信息进行查询操作之后，可以选择是否设置一个Watch。其作用就是当本次查询的数据在服务器端发生变化之后，会对设置Watch的客户端发送通知。一次发送之后，就将删除该Watch，以后的变更或不再设置Watch则不会通知。

ACLs

节点的权限限制使用ACL，如增删改查操作。

Zookeeper的服务器安装：

1、下载对应版本号的tar.gz文件

2、使用 tar xzvf zookeeper-3.4.2.tar.gz -C ./ 解压

3、设置，将conf/zoo.example.cfg复制到conf/zoo.cfg或者手动建立一个新的。

4、启动Zookeeper服务：bin/zkServer.sh start

5、启动客户端连接：bin/zkCli.sh -server 127.0.0.1:2181（此处在本机，且使用了默认端口，且在Java环境中）

6、使用命令：ls、get、set等。

7、关闭Zookeeper服务：bin/zkServer.sh stop

Zookeeper代码编写：

代码编写部分比较简单，因为暴露的接口很少，主要复杂在于项目如何使用节点以及节点信息。

启动Zookeeper服务之后，客户端代码进行节点的增删，Watch的设置，内容的改查等。

此处建议查看官方的《Programming with ZooKeeper - A basic tutorial》部分，当中举了两个例子来模拟分布式系统的应用。

代码基本没有问题，唯一需要注意的就是：若之间按照原版进行调试时，有可能在调用

 Stat s = zk.exists(root, false);

这句代码时会出现一个异常，当中包括“KeeperErrorCode = ConnectionLoss for”。

这个问题引起的原因可以看一下代码

                System.out.println("Starting ZK:");
                zk = new ZooKeeper(address, 3000, this);
                mutex = new Integer(-1);
                System.out.println("Finished starting ZK: " + zk);

最后一行有打印出Zookeeper目前的信息，若未修改的原代码，此处的State应当是CONECTING。连接中的时候去验证是否存在节点会报错。解决的方法也很简单，就是等到Zookeeper客户端以及完全连接上服务器，State为CONECTED之后再进行其他操作。给出代码示例：

// 使用了倒数计数，只需要计数一次
private CountDownLatch connectedSignal = new CountDownLatch(1); 
SyncPrimitive(String address) {
    if(zk == null){
        try {
            System.out.println("Starting ZK:");
            zk = new ZooKeeper(address, 3000, this);
            mutex = new Integer(-1);
            connectedSignal.await(); // 等待连接完成
            System.out.println("Finished starting ZK: " + zk);
        } catch (IOException e) {
            System.out.println(e.toString());
            zk = null;
        } catch (InterruptedException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }
    }
    //else mutex = new Integer(-1);
}
synchronized public void process(WatchedEvent event) {
    // 此处设立在Watch中会在状态变化后触发事件
    if (event.getState() == KeeperState.SyncConnected) {
        connectedSignal.countDown();// 倒数-1
    }
    
        synchronized (mutex) {
            //System.out.println("Process: " + event.getType());
            mutex.notify();
        }
}

这样就可以正确运行代码了。

Zookeeper的应用场景及方式：

此处是为引用，原地址为（http://rdc.taobao.com/team/jm/archives/1232 ）

ZooKeeper是一个高可用的分布式数据管理与系统协调框架。基于对Paxos算法的实现，使该框架保证了分布式环境中数据的强一致性，也正是基于这样的特性，使得zookeeper能够应用于很多场景。网上对zk的使用场景也有不少介绍，本文将结合作者身边的项目例子，系统的对zk的使用场景进行归类介绍。 值得注意的是，zk并不是生来就为这些场景设计，都是后来众多开发者根据框架的特性，摸索出来的典型使用方法。因此，也非常欢迎你分享你在ZK使用上的奇技淫巧。

场景类别

典型场景描述（ZK特性，使用方法）

应用中的具体使用

数据发布与订阅

发布与订阅即所谓的配置管理，顾名思义就是将数据发布到zk节点上，供订阅者动态获取数据，实现配置信息的集中式管理和动态更新。例如全局的配置信息，地址列表等就非常适合使用。

1. 索引信息和集群中机器节点状态存放在zk的一些指定节点，供各个客户端订阅使用。2. 系统日志（经过处理后的）存储，这些日志通常2-3天后被清除。 

3. 应用中用到的一些配置信息集中管理，在应用启动的时候主动来获取一次，并且在节点上注册一个Watcher，以后每次配置有更新，实时通知到应用，获取最新配置信息。

4. 业务逻辑中需要用到的一些全局变量，比如一些消息中间件的消息队列通常有个offset，这个offset存放在zk上，这样集群中每个发送者都能知道当前的发送进度。

5. 系统中有些信息需要动态获取，并且还会存在人工手动去修改这个信息。以前通常是暴露出接口，例如JMX接口，有了zk后，只要将这些信息存放到zk节点上即可。

Name Service

这个主要是作为分布式命名服务，通过调用zk的create node api，能够很容易创建一个全局唯一的path，这个path就可以作为一个名称。

 

分布通知/协调

ZooKeeper中特有watcher注册与异步通知机制，能够很好的实现分布式环境下不同系统之间的通知与协调，实现对数据变更的实时处理。使用方法通常是不同系统都对ZK上同一个znode进行注册，监听znode的变化（包括znode本身内容及子节点的），其中一个系统update了znode，那么另一个系统能够收到通知，并作出相应处理。

1. 另一种心跳检测机制：检测系统和被检测系统之间并不直接关联起来，而是通过zk上某个节点关联，大大减少系统耦合。2. 另一种系统调度模式：某系统有控制台和推送系统两部分组成，控制台的职责是控制推送系统进行相应的推送工作。管理人员在控制台作的一些操作，实际上是修改了ZK上某些节点的状态，而zk就把这些变化通知给他们注册Watcher的客户端，即推送系统，于是，作出相应的推送任务。 

3. 另一种工作汇报模式：一些类似于任务分发系统，子任务启动后，到zk来注册一个临时节点，并且定时将自己的进度进行汇报（将进度写回这个临时节点），这样任务管理者就能够实时知道任务进度。

总之，使用zookeeper来进行分布式通知和协调能够大大降低系统之间的耦合。

分布式锁

分布式锁，这个主要得益于ZooKeeper为我们保证了数据的强一致性，即用户只要完全相信每时每刻，zk集群中任意节点（一个zk server）上的相同znode的数据是一定是相同的。锁服务可以分为两类，一个是保持独占，另一个是控制时序。 

所谓保持独占，就是所有试图来获取这个锁的客户端，最终只有一个可以成功获得这把锁。通常的做法是把zk上的一个znode看作是一把锁，通过create znode的方式来实现。所有客户端都去创建 /distribute_lock 节点，最终成功创建的那个客户端也即拥有了这把锁。

控制时序，就是所有视图来获取这个锁的客户端，最终都是会被安排执行，只是有个全局时序了。做法和上面基本类似，只是这里 /distribute_lock 已经预先存在，客户端在它下面创建临时有序节点（这个可以通过节点的属性控制：CreateMode.EPHEMERAL_SEQUENTIAL来指定）。Zk的父节点（/distribute_lock）维持一份sequence,保证子节点创建的时序性，从而也形成了每个客户端的全局时序。

 

集群管理

1. 集群机器监控：这通常用于那种对集群中机器状态，机器在线率有较高要求的场景，能够快速对集群中机器变化作出响应。这样的场景中，往往有一个监控系统，实时检测集群机器是否存活。过去的做法通常是：监控系统通过某种手段（比如ping）定时检测每个机器，或者每个机器自己定时向监控系统汇报“我还活着”。 这种做法可行，但是存在两个比较明显的问题：1. 集群中机器有变动的时候，牵连修改的东西比较多。2. 有一定的延时。 

利用ZooKeeper有两个特性，就可以实时另一种集群机器存活性监控系统：a. 客户端在节点 x 上注册一个Watcher，那么如果 x 的子节点变化了，会通知该客户端。b. 创建EPHEMERAL类型的节点，一旦客户端和服务器的会话结束或过期，那么该节点就会消失。

例如，监控系统在 /clusterServers 节点上注册一个Watcher，以后每动态加机器，那么就往 /clusterServers 下创建一个 EPHEMERAL类型的节点：/clusterServers/{hostname}. 这样，监控系统就能够实时知道机器的增减情况，至于后续处理就是监控系统的业务了。
2. Master选举则是zookeeper中最为经典的使用场景了。

在分布式环境中，相同的业务应用分布在不同的机器上，有些业务逻辑（例如一些耗时的计算，网络I/O处理），往往只需要让整个集群中的某一台机器进行执行，其余机器可以共享这个结果，这样可以大大减少重复劳动，提高性能，于是这个master选举便是这种场景下的碰到的主要问题。

利用ZooKeeper的强一致性，能够保证在分布式高并发情况下节点创建的全局唯一性，即：同时有多个客户端请求创建 /currentMaster 节点，最终一定只有一个客户端请求能够创建成功。

利用这个特性，就能很轻易的在分布式环境中进行集群选取了。

另外，这种场景演化一下，就是动态Master选举。这就要用到 EPHEMERAL_SEQUENTIAL类型节点的特性了。

上文中提到，所有客户端创建请求，最终只有一个能够创建成功。在这里稍微变化下，就是允许所有请求都能够创建成功，但是得有个创建顺序，于是所有的请求最终在ZK上创建结果的一种可能情况是这样： /currentMaster/{sessionId}-1 , /currentMaster/{sessionId}-2 , /currentMaster/{sessionId}-3 ….. 每次选取序列号最小的那个机器作为Master，如果这个机器挂了，由于他创建的节点会马上小时，那么之后最小的那个机器就是Master了。

1. 在搜索系统中，如果集群中每个机器都生成一份全量索引，不仅耗时，而且不能保证彼此之间索引数据一致。因此让集群中的Master来进行全量索引的生成，然后同步到集群中其它机器。2. 另外，Master选举的容灾措施是，可以随时进行手动指定master，就是说应用在zk在无法获取master信息时，可以通过比如http方式，向一个地方获取master。

分布式队列

队列方面，我目前感觉有两种，一种是常规的先进先出队列，另一种是要等到队列成员聚齐之后的才统一按序执行。对于第二种先进先出队列，和分布式锁服务中的控制时序场景基本原理一致，这里不再赘述。 

第二种队列其实是在FIFO队列的基础上作了一个增强。通常可以在 /queue 这个znode下预先建立一个/queue/num 节点，并且赋值为n（或者直接给/queue赋值n），表示队列大小，之后每次有队列成员加入后，就判断下是否已经到达队列大小，决定是否可以开始执行了。这种用法的典型场景是，分布式环境中，一个大任务Task A，需要在很多子任务完成（或条件就绪）情况下才能进行。这个时候，凡是其中一个子任务完成（就绪），那么就去 /taskList 下建立自己的临时时序节点（CreateMode.EPHEMERAL_SEQUENTIAL），当 /taskList 发现自己下面的子节点满足指定个数，就可以进行下一步按序进行处理了。

 

posted @ 2012-05-15 11:02 一酌散千忧 阅读(4829) | 评论 (0) | 编辑 收藏

MongoDB, Java 与对象关系映射

MongoDB介绍

当今NoSQL领域中有很多有力的竞争者通过多种方式来处理海量数据问题。其中重要的解决方案之一就是MongoDB。MongoDB是面向文档的弱结构化存储方案，使用JSON格式来展现、查询和修改数据。

MongoDB文档相当完备，扩展规模与安装一样简单。它提供冗余、切片、索引以及map/reduce等概念支持。MongoDB的开源社区非常大且非常活跃。MongoDB在很多大型产品中被实际运用，如：Disney, Craigslist, Foursquare, Github 和SourceForge。MongoDB是一个开源项目，由10gen.com建立并维护，该公司由DoubleClick的前任执行人员创立。同时，10gen也提供了极好的商业支持与参与建设。

MongoDB 与 NoSQL: 缺陷与优势

MongoDB作为一个可用NoSQL方案具有很多优势。我刚开始接触NoSQL数据库了解了一系列基于Java的方案，并且花了大量的时间来弄懂什么是列家族，Hadoop与HBase的关系，ZooKeeper到底是什么。当我终于全部清楚之后，发现Cassandra与HBase确实是对于NoSQL领域非常可靠、可信赖的解决方案。但与其他的解决方案相比，MongoDB让我在能够开始写代码之前，不用理解那么多的概念。

与其他软件相似，MongoDB也存在缺陷。经过一段时间使用MongoDB，我列举经历过并需要注意的一些事情，我成为“Gotchas”：

  • 不要按照关系型数据库来思考。这很明显，MongoDB使得构建和执行复杂查询变得非常容易。当实际使用的时候，你会主要关注于效率问题（像我一样）。
  • MongoDB的索引是二进制的树。如果你不是很熟悉B-tree，可能需要了解一下。这些都涉及到构建符合提供查询条件需求的建立索引的方式。
  • 小心的设计索引结构。这涉及到上面提到的B-tree。刚开始我的索引包含文档中的很多字段，以防我会使用到他们。不要犯同样的错误。我有一个很小集合的索引（大约1千万记录）增长到超过17GB的空间，比集合本身还大。你应该不会想要索引一个包含成百上千个实体的列表字段。
  • MongoDB采用了非常有意思的方式来实现NoSQL：采用BSON作为存储，JSON作为展示，JavaScript用于管理和Map/Reduce。因此也引起了一些小问题比如这个 （破坏了Number和Long的相等操作），在MongoDB逐渐流行之后，可能会不断的展示出来。

 

MongoDB, 命令行与驱动

MongoDB基本是使用JavaScript客户端命令行程序来进行复杂任务管理的，如数据整合和简单信息处理，编程都是完全使用JavaScript语言来的。本文中，我们会展示命令行的使用示例。现在有大量的MongoDB客户端产品提供，并且由MongoDB社区来支持驱动。通常每种编程语言都有驱动，并且所有流行的语言都有包括，一些不那么流行的也包含在内。这篇文章展示了使用MongoDB的Java驱动，并使用一个ORM库（MJORM）与之进行比较。

介绍 MJORM: MongoDB的ORM方案

在解决的众多有意思的问题中，最近NoSQL数据存储在开发者中主要的问题趋势就是对象关系映射。对象关系映射就是将传统中保存在关系型数据库中的持久化数据映射为在应用程序中使用的对象。这使得编程语言使用起来更加流畅和自然。

MongoDB面向文档的架构使得它非常适合对象关系映射，因为文档本身就是以对象形式存储的。可惜没有太多的MongoDB的Java对象关系映射库，但是还是有一些，如morphia-(A type-safe Java library for MongoDB)， spring-data(SpringData项目的MongoDB实现)

这些ORM库大量使用了注解，因为一些原因对我不适合，其中最重要的就是这些被注解的对象在多个项目中的兼容性问题。这让我开始了mongo-Java-orm 或者 "MJORM" (发音 me-yorm)项目，一个MongoDB的Java对象关系映射项目。MJORM是在MIT许可之下，并且在发布在了google code project。项目采用maven构建，并且maven构件仓库托管于google code版本控制服务器。MJORM的最新可用发布版本为0.15，已经由一些项目使用与生产环境中。

开始使用ORM

加入MJORM 库

Maven的使用者首先应当在pom.xml中加入MJORM的maven仓库，使得MJORM构件可用。

<repository>
         <id>mjorm-webdav-maven-repo</id>
         <name>mjorm maven repository</name>
         <url>http://mongo-Java-orm.googlecode.com/svn/maven/repo/</url>
         <layout>default</layout>
</repository>

然后加入依赖:

<dependency>
         <groupId>com.googlecode</groupId>
         <artifactId>mongo-Java-orm</artifactId>
         <version>0.15</version>
</dependency>

这样就可以在应用中引入MJORM代码。假如没有使用maven，则你需要手动下载MJORM的pom.xml中列举的所有依赖。

建立 POJOs

依赖已经导入，可以开始编码了。我们从POJO开始:

 
class Author {
         private String firstName;
         private String lastName;
         // ... setters and getters ...
}
 
class Book {
         private String id;
         private String isbn;
         private String title;
         private String description;
         private Author author;
         // ... setters and getters ...
}

我们在这个对象模型中的描述是，作者有ID、姓和名，书有ID、ISNB、标题、描述和作者。

你可能注意到书的id属性是一个字符串，这是为了适应MongoDB的对象ID类型。MongoDB的ID是一个12字节的二进制值显示为一个十六进制的字符串。MongoDB要求集合中的每个文档都必须有一个唯一id，但不要求一定要是ObjectId。目前MJORM只支持ObjectId，并且显示为字符串。

你也可能注意到了Author没有id字段。这是因为Book是它的父文档，因此不需要有id。记住，MongoDB只要求集合中的文档在根级别的id。

创建XML映射文件

下一个步骤就是建立XML映射文件，MJORM能够将MongoDB文档转换为对象。我们为每个文档创建一个对象作为示范，无论将所有的映射放在一个XML文件中还是分开都是可以的。

Author.mjorm.xml:

<?xml version="1.0"?>
<descriptors>
         <object class="Author">
                 <property name="firstName" />
                 <property name="lastName" />
         </object>
</descriptors>

Book.mjorm.xml:

<?xml version="1.0"?>
<descriptors>
         <object class="Book">
                 <property name="id" id="true" auto="true" />
                 <property name="isbn" />
                 <property name="title" />
                 <property name="description" />
                 <property name="author" />
         </object>
</descriptors>

 

这些映射文件能够很好的自解释。descriptors 元素是根元素，必须包含在每个映射文件中。在它下面是object元素定义了文档与之对应的类。Object包含的property 元素主要用于描述POJO中的属性以及这些属性如何与MongoDB中的文档想对应。property 元素至少必须包含一个name 属性，这个元素就是POJO和MongoDB的文档中的属性名称。column 属性则是可选的，用于特定一个在MongoDB文档中的可选属性名称。

property 元素当中的id属性应该是对象的唯一识别。一个对象只能有一个property 元素包含id属性。auto 的设置会使得MJORM在持久化时为该属性自动生成一个值。

可以在google code的MJORM项目主页中查看XML映射文件的更多细节描述。

整合POJO与XML

我们创建了数据模型以及映射文件，使得MJORM可以从MongoDB序列号以及反序列号POJO。我们可以进行一些有意思的事情了，首先打开MongoDB的链接：

Mongo mongo = new Mongo(
         new MongoURI("mongodb://localhost/mjormIsFun")); // 10gen driver

Mongo 对象是由10gen编写的Java驱动提供的。示例中连接了一个本地的MongoDB实例中的mjormIsFun数据库。接下来我们创建MJORM ObjectMapper 。目前ObjectMapper 在MJORM中的唯一实现就是XmlDescriptorObjectMapper，使用XML结构描述信息。可能之后会增加对注解或其他结构定义的支持。

XmlDescriptorObjectMapper objectMapper = new XmlDescriptorObjectMapper();
mapper.addXmlObjectDescriptor(new File("Book.mjorm.xml"));
mapper.addXmlObjectDescriptor(new File("Author.mjorm.xml"));

建立好了XmlDescriptorObjectMapper 并且加入了映射文件。接下来建立由MJORM提供的MongoDao 对象的实例。

DB db = mongo.getDB("mjormIsFun"); // 10gen driver
MongoDao dao = new MongoDaoImpl(db, objectMapper);

首先我们要获得10gen驱动提供的DB对象实例。然后使用DB和ObjectMapper 建立MongoDao 。我们准备开始持久化数据，建立一个Book 然后保存到MongoDB中。

Book book = new Book();
book.setIsbn("1594743061");
book.setTitle("MongoDB is fun");
book.setDescription("...");
 
book = dao.createObject("books", book);
System.out.println(book.getId()); // 4f96309f762dd76ece5a9595

首先建立Book 对象并且填值，然后调用MongoDao 的 createObject 方法，将Book 对象传入"books" 的集合中。MJORM会按照之前的xml映射文件将Book 转换为DBObject (这是10gen的Java驱动使用的基本类型)，并保存一个新的文档进"books" 集合。MJORM返回Book对象时，id属性会被填充。请注意，MongoDB默认是不需要在使用前建立数据库或集合的，系统会在需要时自动创建，这可能会造成某些困扰。在MongoDB的命令行中查看Book对象大概如下：

> db.books.find({_id:ObjectId("4f96309f762dd76ece5a9595")}).pretty()
{
         "_id":          ObjectId("4f96309f762dd76ece5a9595"),
         "isbn":         "1594743061",
         "title":        "MongoDB is fun",
         "description": "..."
}

 

我们来看看假如不用MJORM而直接使用10gen的Java驱动，如何使用createObject 方法：

Book book = new Book();
book.setIsbn("1594743061");
book.setTitle("MongoDB is fun");
book.setDescription("...");
 
DBObject bookObj = BasicDBObjectBuilder.start()
         .add("isbn",              book.getIsbn())
         .add("title",             book.getTitle())
         .add("description",       book.getDescription())
         .get();
 
// 'db' is our DB object from earlier
DBCollection col = db.getCollection("books");
col.insert(bookObj);
 
ObjectId id = ObjectId.class.cast(bookObj.get("_id"));
System.out.println(id.toStringMongod()); // 4f96309f762dd76ece5a9595

 

下面进行对象的查询:

Book book = dao.readObject("books", "4f96309f762dd76ece5a9595", Book.class);
System.out.println(book.getTitle()); // "MongoDB is fun"

readObject 方法根据给定文档的id从指定的集合中读取文档，转换为对象（再次使用映射文件）并返回。

敏锐的读者会注意到Book还没有指定Author，仍然保存了。这归咎于MongoDB的结构不敏感的特性。我们不能要求集合中的文档包含所有属性（id属性是必须的），所有在MongoDB中没有Author的Book是可以的。我们现在为Book添加一个Author并且更新一下：

Author author = new Author();
author.setFirstName("Brian");
author.setLastName("Dilley");
 
book.setAuthor(author);
 
dao.updateObject("books", "4f96309f762dd76ece5a9595", book);

现在Book就包含了Author，并且在MongoDB中持久化了。现在在命令行查看了Book：

> db.books.find({_id:ObjectId("4f96309f762dd76ece5a9595")}).pretty()
{
         "_id":          ObjectId("4f96309f762dd76ece5a9595"),
         "isbn":         "1594743061",
         "title":        "MongoDB is fun",
         "description": "..."
         "author": {
             "firstName": "Brian",
             "lastName": "Dilley"
         }
}

可以看到持久化的Book中已经包含了author。不使用MJORM来操作一遍：

Author author = new Author();
author.setFirstName("Brian");
author.setLastName("Dilley");
 
book.setAuthor(author);
 
DBObject bookObj = BasicDBObjectBuilder.start()
         .add("isbn",              book.getIsbn())
         .add("title",             book.getTitle())
         .add("description",       book.getDescription())
         .push("author")
                 .add("firstName",         author.getFirstName())
                 .add("lastName",  author.getLastName())
                 .pop()
         .get();
 
DBCollection col = db.getCollection("books");
col.update(new BasicDBObject("_id", bookObj.get("_id")), bookObj);
 

 

对于MongoDao 方法的深入讨论已经超出了本文的范围。对于将MJORM有兴趣用于实际项目中的用户强烈建议了解一下MJORM项目提供的相关文档，或者MongoDao 接口提供的相关用法。

总结

希望这篇文章对MongoDB和MJORM的亮点有所展示。MongDB是一个优秀的呃NoSQL数据存储，有着大量优秀的特性，会是NoSQL市场中长期竞争者。若你会在一个Java项目中使用MongoDB，希望你也能够考虑使用MJORM作为你的ORM框架。十分欢迎大家提交特性需求、错误异常报告、文档和源码修正。

 

作者 Bio

Brian Dilley 是一个经验丰富的高级工程师以及项目领导，在Java/Java EE /Spring Framework/Linux内部结构理解和管理有着超过13年的经验。Brian对于创业公司有很多经验，推向市场，构建/维护产品等。他是Iaas、cloud、PHP和Linux的专家，熟悉产品的采购、安装及配置定义，以及公司的软硬件架构包括负载均衡、数据库、微博等。可以follow Brian的 Twitter 。

posted @ 2012-05-09 13:46 一酌散千忧 阅读(1537) | 评论 (0) | 编辑 收藏

数据集成的演化：从EII到Big Data

“企业信息集成（EII）：实用方式”于2005年发布，描述了一套集成不同数据源的方法论，利用了当时的先进技术，如面向服务架构（SOA）、Web Services、XML、资源描述架构（RDF）、基于XML的元数据格式以及数据提取、转换和加载（ETL）。EII能够基本为关系型数据元素提供统一视角，但在性能效率上缺乏能够替代数据仓库和多维数据库的能力。五年之后技术已经得到了显著提升，不仅在于对于分散数据的操作，还有简化了单一容器下不同数据的整合，以及对数据深入挖掘的能力。

转变了数据管理方式的技术正是虚拟化。低成本存储、云计算、NoSQL数据库以及Hadoop。当我们提起虚拟化时，已经远远超出为一台物理机器提供一套软件实例这一概念。时至今日，我们可以虚拟化服务器、存储以及网络。所有这些虚拟化意味着我们不再被这些物理条件所限制，能够迅速构建物理环境以支持我们特定时刻的特定需求。当面对Gb、Tb、Pb等级数据量的处理需求时，我们基本能摆脱结构化的数据仓库。我们不在需要仅仅为了发掘业务的某一方面而建立一个特殊的环境了。

低成本存储在业务的数据存储方面节省了开支。高昂的存储成本会使得企业寻找在限定规模的数据之上进行关键业务分析的方案，这样使得如何选择最重要的数据变得十分关键，而且还限制了系统能够处理的数据的质量。

负面影响便是业务最终可能面临很少的选择，因为没有足够的历史数据提供从而识别一个有效关键模式。或者因为高昂的投入使得业务被停止，而使用常规惯例来识别模式。

云计算为那些需要通过海量数据源在合理时间范围内产生结果的需求提供了一个可用的方式。海量数据处理需要两点：弹性存储，CPU。高速网络很有帮助，但是待会我们会看到在发掘软件在处理海量数据时，它并非是系统的瓶颈。弹性存储意味着企业不会在期望操作的数据规模或类型上受到限制，降低了使用数据仓库无法获取最佳结果的风险。更多的CPU使得结果能够在期望的时间范围内更快的被交付。

NoSQL提供了海量数据的支持，但与传统的关系型数据库没有关联。而且大部分NoSQL数据库是开源的，无须支付购买证书等费用。NoSQL对于表结构有着惊人的灵活性，无须随着系统的改进而不断修改完善定义。NoSQL可以支持不同数据源的合并查看，从而成为EII之后另一个备选方案，这或许是NoSQL最重要的方面了。

NoSQL内置了数据冗余与分布式数据存储机制。海量数据的最大问题之一就是磁盘读写，NoSQL通过将数据分布至一系列节点来缓解这个问题。当一个查询请求发出时，这些节点能够并行查询自身节点，而不是仅仅依靠一块磁盘，一个磁盘阵列或一条网络连接等，数据查询能够在节省了读写开支之后变得更加迅速。

最终，我们来讨论Hadoop，集合了上述所有技术力量与一身的用于检测和分析数据的框架。有些人可能认为Hadoop是一项NoSQL技术，实际上Hadoop是一个分布组件的java框架，用于分解“吃大象”（此处也双关Hadoop是以创立者的儿子给自己的一个大象玩具起的名字）的工作——每次一口。

Hadoop自身实际上与待处理数据是各自独立的。它将大型查询任务分解为小的并行查询任务，然后收集结果，并整合出答案返回给用户。Hadoop相对于NoSQL来说是一个并行查询框架，通过云计算驱动节点，运行在低成本存储及虚拟化技术之上。

Kicking的知识回顾

当EII第一次作为最佳实践出现于2003-2004年，关键要素就是无需再移动数据了。当时大部分的数据中心仍然运行于低速网络中，有限的空间用于复制数据。之后，EII成为了当时可用技术和问题域中最优秀的解决方案。EII的某些方面的优秀即使在海量数据中也是很显著的。

EII的优点之一就是将处理过程转移到数据所在地。海量数据方案的关键架构要素之一就是将处理过程转移到数据所在地，而不是转移数据。EII中的一个重要原则就是使用数据归属地的查询功能。这项实践就是构建靠近数据源网络的Web Service，能够建立起通用查询接口，但只针对本地数据库进行查询。我们通过开放的基于Web的接口解决了数据的专有格式的问题，从而使得多个数据子集能够迅速的整合并以统一模式展示。

有了低成本存储和10G网络之后，我们就不必那么担心数据冗余与数据迁移，但还是有其他问题存在的，数据仓库无法确保数据的原始性便是其中之一。在EII中，我们将从原始数据源获取数据视为“黄金准则”，这样就能够保证信息未被修改过，且是准确的。

Big Data要求数据必须转移到新的物理位置，这样可信任度又成为了问题。EII的那些获取基线数据的最佳实践仍然是相关而且重要的。实际上，那些为EII设计开发的Web Services接口最终在Big Data的启用中扮演主要角色。

当然，讨论数据管理不能不涉及到安全问题。EII在安全领域中还是超过了Big Data。技术上来说，Big Data在数据集成方面更加高效与敏捷，但是大部分缺少了固有的安全性，因为在设计上会加大处理的难度。所以，可能要由源系统来担任起数据访问安全方面的责任。因为EII直接在源系统中查询数据，所以必须要求有适当的授权，否则查询就将失败。

上述关于安全讨论描述的是内在的安全控制情况。将访问权限控制列表集成进数据库是非常合理的，这将确保安全能够作为查询的一部分进行维护。然后，一旦能够直接查询NoSQL数据源，就意味着能够自由的访问你所有的数据。

总结

引用老的Virginia Slims的广告中的台词：“我们已经历很长的路途了，宝贝儿！”文中讨论到的技术的发展已经对21世纪第二个10年中的的数据解决方案产生了巨大的影响。商业化与小型化扫除了一些思想体系上的障碍，使得架构师能够专注于问题本身，而不是寻找一些实用及可实现的问题解决方案。构建10000个节点的处理引擎，能够在数秒内处理Pb级别的数据量，却只消耗每小时几便士，这就是数据处理的美好前景。

有了这些新工具，我们就要重新考虑如何推进数据管理。为何数据无法被很好地被维护整合，并且需要花费数万美元。数据管理几乎是每个大中型企业的心病。数据管理曾经在存储、管理、访问、整合以及查询上花费巨大，但是今后不再会是这样了。

关于作者

JP Morgenthal 是在IT策略与云计算方面的世界级专家之一。他在企业复杂问题域的解决方案实施上有着25年的经验。JP Morgenthal以其在技术方面的深度和广度，有利的支持他在企业问题域中的敏感度。他在集成、软件开发和云计算是一位让人尊敬的作者，同时也是InfoQ在引领云计算方面的编辑，并且参与了“云计算：评估风险”项目。 

 

原文链接：http://www.infoq.com/articles/DataIntegrationFromEIItoBigData

posted @ 2012-04-19 07:15 一酌散千忧 阅读(278) | 评论 (0) | 编辑 收藏

Maven项目管理理解与使用

项目经理（Project manager）是项目的支柱与核心，维基百科的定义：项目经理是项目管理方面的专家，负责项目的策划、执行和结束，即整个生命周期过程。项目经理手中的“干将莫邪”便是软件开发过程方法（software development process/software development life cycle (SDLC)），可能采取的有RUP（Rational Unified Process），敏捷等。

其实软件开发区分阶段已经广为大家接受，普遍的概念即需要区分为分析、设计、实施、测试、发布，过程中会产生若干产物，如需求说明书、概要设计、详细设计等。若提及过程方法，如RUP的话，主要分为四大阶段，先启（Inception）、精华（Elaboration）、构建（Construction）、交付（Transition）迭代的开发方式，而Scrum的核心概念则是Sprint。

 

Maven在项目管理中有那些帮助呢？Maven能够从一个信息中心为项目提供构建，报告，文档编制等工作。在Maven官方介绍《What is maven》中介绍了maven的项目目标（Objectives）（http://maven.apache.org/what-is-maven.html），如下：

l         简化构建过程

l         提供统一的构建系统

l         提供项目质量信息

l         提供对于开发最佳实践的指导

l         允许对于新特性的透明整合

 

对于Maven影响最为深刻的就是它的构建系统，几乎贯穿了整个实施阶段。作为对比我们参考一下RUP的Construction阶段，以及Scrum的单个Sprint过程。

 

RUP的Construction阶段的目标：

这个阶段的目标是澄清需求并基于架构基线完成开发。

l          通过优化资源来缩减开支，并避免无意义的争执与返工。

l          实用性与质量兼具。

l          尽快发布可用版本。

l          完成对所有功能的分析、设计、开发、测试。

l          采用增量迭代的模式完成开发并准备交付。

l          检查项目发布的所有资源是否已经准备完全。

l          形成项目组之间的并行开发。

 

在《硝烟中的Scrum与XP》一书中，介绍了作者实施Scrum的过程。在一个Sprint中，不是只有Sprint backlog、burn down chat等，实施过程中的敏捷思想也是其中的核心，我们来看看敏捷信奉的一部分最佳实践：

l          简单设计（Simple Design）

l          结对编程（Pair Programming）

l          测试驱动（Test-Driven Development）

l          小规模发布（Small Releases）

l          持续集成（Continuous Integration）

l          集体拥有代码（Collective Code Ownership）

l          编码标准（Coding Standard）

 

Maven对于上述目标中的质量（实用性与质量，以测试驱动）、可用（可用版本，小规模）、资源管理等均能发挥较大的作用。主要是其定义了一套完整优秀的构建生命周期机制，其基本阶段如下：

l         validate – 验证项目正确性及依赖有效性

l         compile – 编译项目源码

l         test – 使用合适的单元测试框架对编译后的源码进行测试，测试代码不会被打包或发布

l         package –将编译后的代码以规定格式打包，如Jar

l         integration-test – 将打包后的代码放置于环境中进行集成测试

l         verify – 检查打包的有效性并验证质量标准

l         install – 将包装载入本地仓库，以提供与其他项目的依赖

l         deploy – 将包发布至远程仓库中

其上每一个阶段实际都分为前中后三个阶段，用户可以定义在每一个阶段前后进行自定义的操作，打造自己的构建流程（如在某个阶段执行前制定特殊的配置文件，完成后再改回默认）。对于阶段的实际使用方式，如：validate可以项目所有依赖有效，test可以针对dao层进行单元测试，intergration-test可以对完整业务流程或服务层等进行集成测试。

 

在项目中实际使用的经验，对于标签的使用心得：

1.<dependency> - 依赖标签，最重要的标签，也是Maven的基础功能。

              <dependency>

                     <groupId>junit</groupId>

                     <artifactId>junit</artifactId>

                     <version>4.8.1</version>

                     <scope>test</scope>

              </dependency>

 

2. <repository> - 资源仓库，可以包含多个，常用的有Maven，Jboss等，如下是公司内建的Nexus资源库。

<repository>

                     <id>Suntang's Maven Repository</id>

                     <name>Suntang Nexus Repository</name>

                     <url>http://10.10.10.33:8081/nexus/content/groups/public</url>

              </repository>

3. <profile> - 解释为情景模式可能较为合适。可以有多个，在何种场景下会使用哪些属性、插件等。如下例子便是当缺失某个文件时激活。

（感觉写的不错的一篇，http://blog.csdn.net/turkeyzhou/article/details/4894657）

<profile>

 <activation>

<file>

<missing>target/generated-sources/axistools/wsdl2java/org/apache/maven</missing>

</file>

</activation>

 </profile>

4.<build> - 构建过程。是进行整个项目管理的核心标签。重点需要掌握的知识就是生命周期。

（http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Lifecycle_Reference）

下面的例子就是制定了打包时的资源路径，并且定义了最终打包的名称。

 

       <build>

              <resources>

                     <resource>

                            <directory>src/main/resources</directory>

                            <includes>

                                   <include>**/*</include>

                            </includes>

                     </resource>

                     <resource>

                            <directory>src/main/assembly</directory>

                            <includes>

                                   <include>**/*</include>

                            </includes>

                     </resource>

              </resources>

 

              <finalName>po</finalName>

       </build>

 

4.< plugin > - 支持插件。如单元测试自动化，之前提到的Ant的插件等。若有某些功能觉得不顺手，可以尝试官网找一下有没有合适的插件（http://maven.apache.org/plugins/index.html）。

下面的例子就是在集成测试中，只运行后缀为TestSuitex.java的测试类

 

                     <plugin>

                            <groupId>org.apache.maven.plugins</groupId>

                            <artifactId>maven-surefire-plugin</artifactId>

                            <version>2.4.3</version>

                            <configuration>

                                   <junitArtifactName>junit:junit</junitArtifactName>

                                   <forkMode>once</forkMode>

                            </configuration>

                            <executions>

                                   <execution>

                                          <id>default-test</id>

                                          <phase>integration-test</phase>

                                          <goals>

                                                 <goal>test</goal>

                                          </goals>

                                          <configuration>

                                                 <skip>false</skip>

                                                 <includes>

                                                        <include>**/*TestSuitex.java</include>

                                                 </includes>

                                          </configuration>

                                   </execution>

                            </executions>

                     </plugin>

 

posted @ 2012-04-06 14:48 一酌散千忧 阅读(488) | 评论 (0) | 编辑 收藏

maven自动化测试环境搭建

环境背景：

我作为项目经理和技术架构管理人员负责公司一条生产线。讨论之后，首席架构师希望我们能够实施TDD。在实施TDD的过程中，设计实施过程的整体思路就是：单元测试用例文档 - 实施单元测试 - 实施业务代码 – 修改业务代码逻辑。实施人员需要参与每个环节，按照规范编写单元测试用例文档。单元测试我们按照模块（模块与人员基本没有重合）划分包（suite），保证实施起来不会产生干扰。。技术架构决定采用：maven，junit，svn。

 

技术背景：

技术架构设计上，我们封装了dao层的实现，所以实施人员基本无需涉及dao层的开发。服务层我们采用了JAX-RS的服务规范，对外开发服务接口。

在测试覆盖率方面，我们基本不要求对dao层的单元测试，但要求在服务层的单元测试达到100%。由于服务层是Restful WS的模式，所以我们采用了模拟HTTP请求的方式在测试服务层。

由于需要模拟HTTP的请求，所以我们在单元测试中采用了jetty作为内嵌服务器，单元测试开始时同一启动，完成后关闭。

 

实施过程：

开发过程中，实际实施的时候发现一个问题，对于测试数据的管理问题。即测试当中需要一定的数据环境来验证业务逻辑。这个数据环境如何建立？

 

方案一，使用dbunit和hsqldb。在测试启动时重建数据环境。

否决，原因：

1.与实际运行环境差异较大。

2.反复重建数据环境，效率上有缺失。

3.技术架构增加，学习和维护曲线较大。

 

讨论后决定使用

方案二，独立出一套测试数据库，完整数据环境。考虑到增删改与查询的冲突，制定默认规则，如id在20之内的不允许进行任何改动。以尽量隔离增删改的影响。

 

针对方案二，有一个较大的问题，如何在开发过程中自由的切换数据库配置呢？由于我们还是用了Hudson作为CI服务器，还要考虑到打包的过程。整体考虑之后，有两个步骤需要注意：

一、开发过程。开发过程中，我们将配置直接指向测试数据库。

二、打包过程。使用了maven，存在单元测试配置与最终产品配置的冲突。

所以最终问题的焦点集中在打包过程的maven配置方案。

 

搜索之后比较好的资料有

MAVEN:如何为开发和生产环境建立不同的配置文件 --我的简洁方案

（http://www.blogjava.net/scud/archive/2010/10/27/336326.html）

这篇博客是介绍在maven 中使用mvn package -P test 这样的自定义profile来实现的。这样是可行的，但是在Hudson中无法实现一条命令切换两套配置。

于是继续寻找，最终在maven的官方网站找到《Building For Different Environments with Maven 2》（http://maven.apache.org/guides/mini/guide-building-for-different-environments.html）看完文章之后发现，实际maven提供了一个非常好的插件maven-antrun-plugin，以实现某些ant的功能。此处还需要了解的知识就是maven的构建生命周期标准（http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html）。基于上述两个知识点，我们制定出如下方案，在项目中建立测试配置目录及产品配置目录，在maven的package阶段开始前，都使用测试配置，运行集成测试，完成在package阶段前将产品配置覆盖至打包文件夹内，然后进行打包。思路就是这样，下面贴出pom文件的关键部分。

 

 

POM.xml

<!—profile 节点定义覆盖文件的方式内容 -->

       <profiles>

              <profile>

                     <id>product</id>

                     <build>

                            <plugins>

                                   <plugin>

                                          <artifactId>maven-antrun-plugin</artifactId>

                                          <executions>

                                                 <execution>

                                                        <id>pre_product</id>

                                                        <phase>prepare-package</phase>

                                                        <goals>

                                                               <goal>run</goal>

                                                        </goals>

                                                        <configuration>

<!—此处与ant的任务相似 -->

                                                               <tasks>

                                                                      <delete file="${project.build.outputDirectory}/spring/dataSourceContext.xml" />

                                                                      <delete file="${project.build.outputDirectory}/log4j.properties" />

                                                                      <copy file="src/product/assembly/log4j.properties" tofile="${project.build.outputDirectory}/log4j.properties" />

                                                                      <copy file="src/product/assembly/spring/dataSourceContext.xml" tofile="${project.build.outputDirectory}/spring/dataSourceContext.xml" />

                                                               </tasks>

                                                        </configuration>

                                                 </execution>

                                          </executions>

                                   </plugin>

                            </plugins>

                     </build>

              </profile>

       </profiles>

 

<!—构建过程 -->

       <build>

<!—指定资源目录 -->

              <resources>

                     <resource>

                            <directory>src/test/resources</directory>

                            <includes>

                                   <include>**/*</include>

                            </includes>

                     </resource>

                     <resource>

                            <directory>src/test/assembly</directory>

                            <includes>

                                   <include>**/*</include>

                            </includes>

                     </resource>

              </resources>

 

              <finalName>po</finalName>

 

<!—指定集成测试配置 -->

              <plugins>

                     <plugin>

                            <groupId>org.apache.maven.plugins</groupId>

                            <artifactId>maven-surefire-plugin</artifactId>

                            <version>2.4.3</version>

                            <configuration>

                                   <junitArtifactName>junit:junit</junitArtifactName>

                                   <forkMode>once</forkMode>

                            </configuration>

                            <executions>

                                   <execution>

                                          <id>default-test</id>

                                          <phase>integration-test</phase>

                                          <goals>

                                                 <goal>test</goal>

                                          </goals>

                                          <configuration>

                                                 <skip>false</skip>

                                                 <includes>

                                                        <include>**/*TestSuitex.java</include>

                                                 </includes>

                                          </configuration>

                                   </execution>

                            </executions>

                     </plugin>

              </plugins>

       </build>

posted @ 2012-04-05 11:26 一酌散千忧 阅读(1743) | 评论 (0) | 编辑 收藏

Nosql企业之道

     摘要: Nosql企业之道 http://www.infoq.com/articles/nosql-in-the-enterprise   介绍 作为一个企业架构师的好处，就是我一直在找一些新的有希望的概念或想法，能够帮助我的企业用户处理不同垂直行业之间的问题。甚至在NoSQL这个词被杜撰（错误的杜撰？此处作者认为NoSQL这个词并不恰当，后面会提到）出来之前，因为上述的原因我曾持续...  阅读全文

posted @ 2012-04-04 21:41 一酌散千忧 阅读(366) | 评论 (0) | 编辑 收藏

Hadoop in action 实践(伪分布式)

《Hadoop in action》由Manning出版，磕磕绊绊总算是看完了。书的内容就不做介绍，主要讲一下实践的过程。并且在实践过程中参考的书籍的部分也会简单介绍。

灰色背景部分为一些介绍，或过程中出现问题的描述，可以直接忽略。

由于公司的业务需要，要在网络收集网页之后对网页进行结构化的解析，这个结构化过程希望能够基于HDFS并且使用MR算法实现。

我虚拟了一个需求，针对http://hadoop.apache.org/common/releases.html 页面，假设已经下载了页面并入库。要求最终体现的数据是 “版本号+完整链接（即a标签全部内容）” 的结构。

 

伪分布式环境搭建在虚拟机上，操作系统是centos5.5，hadoop的版本是1.0.0.

 

插入书中的一些环境搭建的介绍

书中的2.1节中介绍了每个进程的作用。2.2节中的ssh设置也比较重要，否则好像会一直提示你输入密码。2.3.2节介绍了伪分布式的配置方式，对core-site.xml，mapred-site.xml，hdfs-site.xml进行配置之后，需要对namenode节点进行格式化。

bin/hadoop namenode –format

 

hadoop的根目录为/usr/local/hadoop-1.0.0，直接启动start-all.sh

 

[root@localhost hadoop-1.0.0]# ./bin/start-all.sh

 

启动成功后使用jps命令

jdk小工具jps介绍 

jps(Java Virtual Machine Process Status Tool)是JDK 1.5提供的一个显示当前所有java进程pid的命令，简单实用，非常适合在linux/unix平台上简单察看当前java进程的一些简单情况。 jps存放在JAVA_HOME/bin/jps

 

[root@localhost hadoop-1.0.0]# jps

5694 SecondaryNameNode

5461 NameNode

5578 DataNode

6027 Jps

5784 JobTracker

5905 TaskTracker

这几个进程是非常重要的。很多时候出现意外就是因为某项服务未启动或异常。可以看到上面的命令上打印出日志位置。出现异常后可以在日志中查看详细的堆栈信息。

 

至此，hadoop已经启动，环境已经准备就绪。

 

下面准备我们的测试数据，将目标页面的html保存为news.txt，伪分布式也同样支持hdfs，所以我们使用 fs –put 将news.txt存入hdfs中。

[root@localhost hadoop-1.0.0]# ./bin/hadoop fs -put /mnt/hgfs/shared/news.txt /user/root

[root@localhost hadoop-1.0.0]# ./bin/hadoop fs -lsr /userdrwxr-xr-x   - root supergroup          0 2012-04-01 11:22 /user/root

-rw-r--r--   1 root supergroup       3935 2012-04-01 11:22 /user/root/news.txt

 

实现的代码在eclipse中使用maven打包，上传至虚拟机。

文件名com.suntang.analyse.hadoop-0.0.1.jar。
使用hadoop的中的jar命令调用该jar文件。


[root@localhost hadoop-1.0.0]# ./bin/hadoop jar com.suntang.analyse.hadoop-0.0.1.jar com.suntang.analyse.hadoop.AnalyseJob /user/root/news.txt output_root_test

12/04/01 14:40:04 INFO input.FileInputFormat: Total input paths to process : 1

12/04/01 14:40:05 INFO mapred.JobClient: Running job: job_201204011420_0001

12/04/01 14:40:06 INFO mapred.JobClient:  map 0% reduce 0%

12/04/01 14:40:19 INFO mapred.JobClient:  map 100% reduce 0%

12/04/01 14:40:31 INFO mapred.JobClient:  map 100% reduce 100%

12/04/01 14:40:37 INFO mapred.JobClient: Job complete: job_201204011420_0001

…

 

 

此处注意我犯的一个错误：

[root@localhost hadoop-1.0.0]# ./bin/hadoop jar com.suntang.analyse.hadoop-0.0.1.jar AnalyseJob -libjars hadoop-core-1.0.0.jar /user/root/news.txt output_root_test

Exception in thread "main" java.lang.ClassNotFoundException: AnalyseJob

提示找不到类，因为我忘了写完整类名，命令应该改为

./bin/hadoop jar com.suntang.analyse.hadoop-0.0.1.jar com.suntang.analyse.hadoop.AnalyseJob -libjars hadoop-core-1.0.0.jar /user/root/news.txt output_root_test 即可。

 

此处运行可能出现另外一个错误。在命令行中出现

12/04/01 14:01:38 INFO mapred.JobClient: Task Id : attempt_201204011356_0001_m_000001_0, Status : FAILED

java.lang.Throwable: Child Error

        at org.apache.hadoop.mapred.TaskRunner.run(TaskRunner.java:271)

Caused by: java.io.IOException: Creation of symlink from /mnt/hgfs/shared/hadoop-1.0.0/libexec/../logs/userlogs/job_201204011356_0001/attempt_201204011356_0001_m_000001_0 to 。。。

就不打全了，重点在与

Creation of symlink，看详细日志中hadoop-root-tasktracker-localhost.localdomain.log中提示org.apache.hadoop.fs.FileUtil: Command 'ln -s ....': Operation not supported，即ln操作不支持。google可知这个是由于vm中的共享区域的问题，解决方法就是将hadoop完全转移至linux目录中。本例中从/mnt/hgfs/shared/hadoop-1.0.0转移至/usr/local/hadoop-1.0.0。

 

执行完成后可在hdfs中查看结果，查看目录结构为

-rw-r--r--   1 root supergroup          0 2012-04-01 14:40 /user/root/output_root_test/_SUCCESS

drwxr-xr-x   - root supergroup          0 2012-04-01 14:40 /user/root/output_root_test/_logs

drwxr-xr-x   - root supergroup          0 2012-04-01 14:40 /user/root/output_root_test/_logs/history

-rw-r--r--   1 root supergroup      13634 2012-04-01 14:40 /user/root/output_root_test/_logs/history/job_201204011420_0001_1333262405103_root_ccAnalyseJob

-rw-r--r--   1 root supergroup      20478 2012-04-01 14:40 /user/root/output_root_test/_logs/history/job_201204011420_0001_conf.xml

-rw-r--r--   1 root supergroup       3580 2012-04-01 14:40 /user/root/output_root_test/part-r-00000

 

/user/root/output_root_test/part-r-00000即为最终结果文件。

 

 =======================================================================

附加AnalyseJob代码

package com.suntang.analyse.hadoop;

 

import java.io.IOException;

 

import org.apache.hadoop.conf.Configuration;

import org.apache.hadoop.conf.Configured;

import org.apache.hadoop.fs.Path;

import org.apache.hadoop.io.LongWritable;

import org.apache.hadoop.io.Text;

import org.apache.hadoop.mapreduce.Job;

import org.apache.hadoop.mapreduce.Mapper;

import org.apache.hadoop.mapreduce.Reducer;

import org.apache.hadoop.mapreduce.lib.input.FileInputFormat;

import org.apache.hadoop.mapreduce.lib.input.TextInputFormat;

import org.apache.hadoop.mapreduce.lib.output.FileOutputFormat;

import org.apache.hadoop.mapreduce.lib.output.TextOutputFormat;

import org.apache.hadoop.util.Tool;

import org.apache.hadoop.util.ToolRunner;

 

public class AnalyseJob extends Configured implements Tool {

 

       public static class MapClass extends Mapper<LongWritable, Text, Text, Text> {

 

              @Override

              protected void map(LongWritable key, Text value, Context context)

                            throws IOException, InterruptedException {

                    

                    

                     // TODO Auto-generated method stub

                     // super.map(key, value, context);

                     if (value.toString().matches("<a[^>]*>.*?release.*?</a>"))

                            context.write(

                                          new Text(value.toString().substring(

                                                        value.toString().indexOf("release") + 8,

                                                        value.toString().indexOf("available") - 1)),

                                          value);

              }

 

       }

 

       public static class ReduceClass extends Reducer<Text, Text, Text, Text> {

 

              @Override

              protected void reduce(Text arg0, Iterable<Text> arg1, Context arg2)

                            throws IOException, InterruptedException {

                     // TODO Auto-generated method stub

                     // super.reduce(arg0, arg1, arg2);

                     arg2.write(arg0, arg1.iterator().next());

              }

 

       }

 

       public int run(String[] args) throws Exception {

              Configuration conf = getConf();

 

              Job job = new Job(conf, "myAnalyseJob");

              job.setJarByClass(getClass());

 

              Path in = new Path(args[0]);

              Path out = new Path(args[1]);

              FileInputFormat.setInputPaths(job, in);

              FileOutputFormat.setOutputPath(job, out);

 

              job.setMapperClass(MapClass.class);

              job.setReducerClass(ReduceClass.class);

 

              job.setInputFormatClass(TextInputFormat.class);

              job.setOutputFormatClass(TextOutputFormat.class);

              job.setOutputKeyClass(Text.class);

              job.setOutputValueClass(Text.class);

 

              System.exit(job.waitForCompletion(true) ? 0 : 1);

 

              return 0;

       }

 

       public static void main(String[] args) throws Exception {

              int res = ToolRunner.run(new Configuration(), new AnalyseJob(), args);

              System.exit(res);

       }

}

posted @ 2012-04-01 15:00 一酌散千忧 阅读(910) | 评论 (0) | 编辑 收藏

给开发维护大型项目的开发者的建议

Tips to Developers Starting on Large Applications

原文引用：http://www.infoq.com/articles/tips-to-developers-starting-on-large-apps

 

假设你是正在开发和维护一个包含2000个类并使用了很多框架的Java开发者。你要如何理解这些代码？在一个典型的Java企业项目小组中，大部分能够帮你的高级工程师看起来都很忙。文档也很少。你需要尽快交付成果，并向项目组证明自己的能力。你会如何处理这种状况？这篇文字为开始一个新项目的Java开发者提供了一些建议。

 

1         不要试图一下子搞懂整个项目

好好考虑一下，为什么理解项目代码是第一位的？大部分情况是你被要求修复一个bug或者加强系统已有功能。你要做的第一件事情不是理解整个项目的架构。当对项目进行维护时，这样（理解整个项目架构）可能会对你造成巨大的压力。

即便是有着10年可靠编程经验的Java开发者可能也没有理解项目的核心工作机制，尽管他们可能已经在这个项目工作超过一年（假设他们并非原始开发人员）。比如，对于认证机制或事务管理机制。

他们是怎么做的？他们对于自己负责的部分非常了解，并且能够交付价值给小组。每天的交付价值远比了解一些以后还不确定有没有的东西重要的多。

2         关注于尽快交付价值

那我是否定了你对于项目架构理解的热情了么？完全不。我只是要求你尽早的交付价值，一旦你开始一个项目，搭建了开发环境，你就不应该花一两周时间才交付什么，无论他的规模大小。假如你是一个有经验的程序员却两周都没有任何交付，你的经理怎么会知道你是真的在工作还是在看新闻。

所以交付可以使大家都轻松起来。不要认为你能够做有价值的交付前必须理解整个项目。这是完全错误的。加一段javascript的验证代码对业务就很有价值，经理能够通过你的交付达到对你的信任。这样能够向上级领导证明你的贡献以及员工价值。

日复一日，在你不断修复bug及增强功能之后，就能够慢慢开始理解项目架构。不要低估对系统方方面面理解时需要花费的时间。花3-4天理解认证机制，2-3天理解事物管理。这些都是依靠之前的相似项目的经历，但关键还是要花时间才能透彻的理解。要在日常工作中挤出时间，不要向经理要求特定的时间来做这些。

找找项目是否有一些不断维护的单元测试用例。有效的单元测试用例是理解大型项目代码的很好途径。单元测试能够帮助理解代码片段，包括一个单元的外部接口（单元如何被调用以及返回内容）及其内部实现（调试单元测试比调试整个实际用例简单许多）。

你如果能够很好的理解一些内容，写一些笔记，或者画一些类图、时序图、数据模型图，以便你或日后其他的开发者维护。

 

3         维护大型项目所必须的技能

你能从事当前的工作，必然已经具有良好的java技术。我们来谈谈能够让你在新项目中良好表现的其他技能。大部分时间，你在项目中的任务是修复bug和增强功能。

有两项很重要的技能能够协助你维护大型项目代码。

3.1         能够迅速发现需要的类

在任何维护活动中，无论是修复bug或增强功能，第一个动作就是识别出当前修复或增强的用例中调用的类。当你定位到需要修复或增强的类/方法，就已经完工了一半。

3.2         能够分析变更的影响

当你在完成必要的修改或增强工作后，最重要的就是要确认你的修改没有破坏代码的其他部分。你要用你的java技术及对其他框架的理解找出变更可能影响的部分。下面有两个简单的例子详细描述了最后提及的情况：

a）当类A的equals()方法变更后，调用一个保护A实例的List的contains()方法时就会被影响到。若Java知识不够，很难考虑到这样的影响。

b）在一个web项目中，我们假设“user id”保存在session中。一个新入程序员可能在“user id”中加入一些信息作为bug修复的方法，但是却不知道会影响到那些关联“user id”的用例。

当你提高了如上两个技能，尽管你对项目不是非常了解，但大部分的维护任务会变得简单很多。若你修复一个bug，你会定位并修复这个bug，并且保证变更不会破坏项目的其他部分。若你增强或加入一个特性，基本上你只需要模仿现有的特性使用相似的设计。

在一个在线银行项目中，为什么“查看账户摘要”和“查看交易历史”的设计需要巨大的差别呢？如果你理解了“查看账户摘要”的设计，完全可以模仿开发出“查看交易历史”的功能。

就修复bug和增强来说，你不必完全理解所有2000个类的工作内容和代码如何运行来推动系统。你若有上面的技能，就能很快定位需要修改的代码的部分，使用良好的java和框架技能修复，保证变更不会破坏项目的其他部分并交付，尽管你可能只知道一小部分项目的设计。

4         使用工具找到需要的变更内容以及变更产生的影响

继续我们尽快交付的主题，你应当寻找那些能够通过尽量少的了解项目但能帮助你尽快实施交付的工具作为辅助。

4.1         迅速发现需要变更内容的工具

无论是修复bug还是系统增强，首先都要找到该用例调用的你需要修改的类及方法。基本有两种方式理解一个用例的工作方式，静态代码分析和运行时分析。

源码分析统计扫描所有代码并且展示类之间的关系。市场上有很多设备与工具。比如：Architexa， AgileJ， UModel， Poseidon等。

所有的静态代码分析工具缺点在于无法确切展示用例中类或方法的运行时调用情况。因此Java新加入了特性，如回调机制（callback patterns）。如静态分析工具无法推断出当页面提交按钮被点击时哪个Servlet被调用了。

运行时分析工具能够展示类和方法在用例运行时的状态。工具包括：MaintainJ， Diver，jSonde，Java Call Tracer等。这些工具可以捕获运行时的堆栈状态，并以此为一个用例生成序列图和类图。

序列图展示了该用例在运行时所有调用的方法。若你在修复一个bug，那这个bug很可能就是这些被调用的方法之一。

若你在增强已有功能，利用序列图理解调用流程然后再修改。可能是新增一个验证，修改DAO等。

若你在新增功能，找到一些相似的特性，利用序列图理解调用流程然后模仿开发新功能。

要小心挑选运行时分析工具。信息过多是这类工具的主要问题。选择一些提供简单过滤无效信息并能够方便的查看各种视图的工具。

4.2         迅速发现需要变更内容的工具

若单元测试有效，可以通过运行单元测试发现变更有没有破坏其他测试用例。有效维护并且覆盖大型企业应用的单元测试还是比较少的。下面有一些针对该情况的工具。

仍然是有两种技术静态代码分析和运行时分析可以使用。市场中有很多静态代码分析工具可用。如：Lattix, Structure101, Coverity, nWire and IntelliJ's DSM。

给定一个变更后的类，上述工具均可识别对该类存在依赖的类的集合。开发者需要根据这些信息“猜测”可能产生影响的用例，因为这些工具无法展示运行时类之间的调用关系。

市场上的可以用于运行时影响分析的工具并不多，除了MaintainJ。MaintainJ先捕获在一个用例中调用的所有类和方法。当所有用例的上述信息都被捕获之后，就很容易发现类的变更对用例的影响。MaintainJ能够有效工作的前置条件就是项目的所有用例都应当先运行一遍，以便能够获得运行时的依赖关系。

总之，目前你在迅速准确分析变更影响方面，还是可以从工具中获得有限的帮助。首先根据需要实施一些影响分析，然后根据自己或小组其他高级成员评审来判断变更的影响。你可能需要上面提到的工具对你的判断进行反复确认。

5         对上述内容的两个忠告

5.1         不要降低代码质量

为了快速交付，所以没有全盘理解架构，但绝不能以降低代码质量为条件。下面是一些你可能因为只考虑快速交付而引发的代码质量问题。

因为修改代码涉及到很多的依赖，所以新增代码相对而言风险较小。例如，有5个用例都调用了某个方法。为了改进某个用例，你需要修改这个方法的实现。最简单的做法就是复制这个方法，重命名，然后在改进的用例中调用新方法。千万不要这么做。代码冗余绝对是非常有害的。尝试对方法进行包装或者重写，甚至是直接修改，然后重新测试所有用例，通常停下来想一想，然后亲手去实施，是一个比较好的方式。

另一个例子是将“private”方法改为“public”，使得别的类也可以调用。尽量不要将非必须的部分暴露出来。假如为了更好的设计需要重构，就应当着手去做。

大部分应用都有确定的结构和模式来实施。修复或增强程序时，确认你没有偏离这样的模式。若对约定不确定，请其他的高级开发者来审核你的变更。若你必须做一些违背约定的实施，尽量放置于一个规模较小的类中（一个200行代码的类中的私有函数应当不会影响应用的整体设计）

5.2         不要停止深入理解项目架构

按照文章列出的方式，假设你能够在对项目了解较少的情况下进行交付并以此持续下去，可能你会停止对项目架构的深入了解。这样从长远角度来说对你的职业生涯没有帮助。当你的经验增加时，你应当承担比较大的模块任务。如构建一个完整的新特性或者修改项目的一些基础设计等较大的改进。当你能够做这些改进时，你对项目的整体架构应该相当了解。文中列举的方法是让你在最短的时间内提升自己，而不是阻止你完整理解整个项目。

6         结论

整篇文章集中在对项目进行必要了解的前提下进行快速交付。你可以在不降低代码质量的前提下这么做。

若修复一个bug，迅速定位并修复。有必要可以使用运行时分析工具。若新增一个特写，可以寻找相似特写，理解流程（有必要使用工具）并编写。

或许这些听起来很简单，但是实用吗？当然。但前提是你有良好的java技术以及对框架足够了解才能先修改代码，然后对变更影响进行分析。对变更影响的分析比实施变更需要更多的技巧。你可能需要高级开发人员协助你分析变更影响。

大约有50%的IT可操作预算用于简单的bug修复和功能增强。根据文中的建议，对于维护活动中的经费的节省应当还是很有帮助的。

作者Choudary Kothapalli 也是MaintainJ项目的建立者。

About the Author

Choudary Kothapalli is the founder of MaintainJ Inc., the company that builds tools to reduce the costs of maintaining large Java applications. He has over 15 years of experience in developing and maintaining enterprise Java applications. He is a Sun Certified Enterprise Architect and Java Programmer. He lives with his wife and two sons in Toronto, Canada.

 

posted @ 2012-03-29 22:44 一酌散千忧 阅读(424) | 评论 (0) | 编辑 收藏

企业技术体系架构建设

软件企业的技术体系架构包括对软件产品本身及生产过程、软件生产环境及生产者的管理和支持，此架构应当基于下列五项基础建设之上：

l 开发技术架构

l 开发环境架构

l 过程管理架构

l 企业产品架构

l 企业人件架构

下面详细介绍各项架构的内容及特点。

 

 

开发技术架构

开发技术架构作为一个软件企业的基石，包括可复用的架构组件、公用的基础代码库等。开发技术框架应当在一个良好的过程管理之下，严格的质量管理与实用性检查，并且鼓励普通技术人员的参与。

1.建立技术架构仓库标准体系与维护模式。建议使用MAVEN作为所有开发技术（包括架构预研与实际项目开发）的基础项目管理工具，实施严格的质量管理和持续集成。

2.选拔组建高素质的架构师队伍，并且鼓励技术人员参与到技术架构仓库的构建和维护。

3.加强技术架构实用性与适用性的检查与改造。

4.架构运营模式的考察，技术架构的改进与预研。技术架构的预研模式比较复杂，多个部门中多个项目可能都会要求进行多个同类框架的考察、比较、环境搭建等工作，若集中在独立架构组可能压力较大。可以考虑架构组内部划分为多个技术领域，如企业基础应用架构、消息中间件、动态化组件、分布式集群等。以技术部门的实施领域作为导向，进行技术架构的预研。

5.开放知识系统的构建（内部wiki，个人博客，视频分享）

根据企业行业背景，需要关注的技术领域包括：企业应用、ESB/SOA、大型分布式架构（在线/离线），自然语言处理。

 

开发环境架构

包含IDE，编译环境，远程支持，通讯支持与其他大量功能性支持软件，并可以根据不同的工作角色制定不同的环境，以便排除干扰，更加快速有效的进入工作状态。

项目的关键问题是沟通，个性化的工具妨碍——而不是促进沟通。开发和维护公共的通用编程/项目管理工具有很多的好处。

1.建立具有鲜明特色与强大实用性的自有开发环境，展示一个软件龙头企业在企业技术沉淀中的深厚功力和规范性。

2.建立行政流程以规范和约束开发环境管理。

3.划分相关职能以保持对开发环境的维护

4.建立多种培训机制以促进新员工能够迅速投入工作。如固定新员工开发环境熟悉培训机制，建立企业讲解&培训视频库，小组内互助&沟通。

 

过程管理架构

1.过程方法

对多家企业软件生命周期中使用的过程方法进行调查了解到，大部分优秀的软件企业对于过程方法十分重视，且存在针对不同项目合理运用不同的过程方法。项目经理对于过程方法的理解与运用常常关系到项目的成败。

目前核心的管理模型/过程方法主要分为三大类：CMMI，RUP，敏捷。

CMMI作为软件质量体系的标准，软件企业必须具备的资质，具有文档齐全，流程规范等优势，对于大型核心项目有较大优势，其劣势在于灵活度不足，无法很好的满足日益变化的需求。

RUP由Rational公司（被IBM收购，目前是IBM 软件集团旗下之第五大软件品牌）提出，采用迭代开发模式，四个阶段，九大核心工作流，明确的角色划分与文档规划，可裁剪配置的开发过程。目前被大量的软件厂商作为最核心的过程方法使用。

敏捷（Agile）为了满足队伍小型化和需求快速变化而产生的目前最流行的过程方法。XP（Extreme Programming）通过简单的四个核心价值（沟通（Communication）、简单（Simplicity）、反馈（Feedback）和勇气（Courage））与十二条最佳实践从研发的角度提出了最简单直接的开发方式。XP的形态特殊，从编程的角度描述方法与原则，加入了SCRUM之后，加强了从行政体制方面的支持，从而形成了完整的敏捷开发的过程方法体系。

 

过程方法一定不是万金油，针对不同的企业特点，甚至不同项目，都有必要对过程方法进行合理的裁剪与整合。对于目前公司的情况，大型核心项目可以使用CMMI，这些往往决定了企业的战略方向，稳健的过程方法最为合适。大部分中小型项目均可采用 RUP+敏捷 的过程方法，即遵守RUP的核心阶段和工作流，但是迭代周期和开发的基本原则根据敏捷，并挑战整合部分敏捷方法中的最佳实践。这样的策略用于面对市场需求的快速变化，同时也能很好的保障企业在软件生产中的产品价值保存和技术经验积累。

 

2.过程方法自动化支持

针对不同的过程方法，往往有若干的软件产品用以快速自动化的实施。如实施CMMI时所使用到的DEVSUITE产品。完整体系的支持产品往往在应用于某套固定方法有着良好的效果，但容易存在流程生硬，无法与开发环境更好结合形成了信息孤岛，改进困难等缺点。一套优秀的过程方法支持软件，需要和开发环境（如IDE等）良好结合，并且易于调整以应对过程方法的变化，同时没有复杂冗余的过多细节流程以便容易被开发人员学习和掌握。

产品涉及方面：项目计划、项目需求管理、软件配置管理、自动集成、自动产品发布、代码审核、代码质量管理等。

 

 

企业产品架构

1.产品/产品需求流程补充，产品立项时的立项报告中应当包含市场、竞争对手、对手产品、风险等分析。

2.领域模型与概念，在特定的行业中可以即使关注领域专家的动态，以便构建正确的领域模型，确定产品的发展方向和形态的正确性。

3.对于特定产品的领域概念及相关技术发展需要深入了解，如舆情分析系统，需要进行了一定的市场调查，跟进了当前领域专家的报告，参考国内外多项相关项目的设计理念和原则。对于目前市场状况、未来的方向、目前的技术实力等要有比较清晰的概念

4.坚持以市场为导向的原则，在商务部门与研发部门之间搭建积极的沟通桥梁，研发部门的计划根据实际市场需求进行调整。产品的发布配合市场的要求，达到利益最大化。

 

 

企业人件架构

企业自身环境除了常见的软件（Software），硬件（Hardware）以为，还应当加入人件（Peopleware）。之前的种种，如过程方法、技术架构积累、知识分享等均是为了将整个企业构建成为一部精密的机器，无论缺少什么重要零件均可以快速修复，但是人员流失所造成的损失是巨大的。目前公司有着良好的软硬件环境，技术部门作为发动机，若在针对技术性员工有特别的规划和关心，必然能够增强在整个市场中的竞争力，对企业自身的发展也是有良好的推进作用。

公司可以按照职位和员工自身的情况规划发展路线，明确技术目标。开发进化角色基本按照软考标准，程序员-高级程序员-软件设计师-系统分析师-系统架构师，程序员-高级程序员-项目经理。

在技术部门内部，可以定期组织交流心得、新技术等。（在SCRUM中实际上有一些比较好的行政手段可以借鉴参考）

由于软件技术部门的特殊性，一些应用于生产线的行政制度可能能够讨论出更好的实施方案，避免员工单方面的错误认识引发消极的工作态度。

由于有一定经验，而且公司技术架构建设的需要，能够很好的协助企业进行技术架构全方面的介绍和培训。而且我自身也很希望参与到企业文化的建设工作中去，鼓励技术人员之间的技术交流与沟通。

 

posted @ 2012-03-29 16:27 一酌散千忧 阅读(1296) | 评论 (0) | 编辑 收藏

Hadoop: The Definitive Guide（Hadoop权威指南）Unix Tools 脚本编程实施

Example 2-2. A program for finding the maximum recorded temperature by year from NCDC weather records

#!/usr/bin/env bash

for year in all/*

do

  echo -ne `basename $year .gz`"\t"

  gunzip -c $year | \

    awk '{ temp = substr($0, 88, 5) + 0;

           q = substr($0, 93, 1);

           if (temp !=9999 && q ~ /[01459]/ && temp > max) max = temp }

         END { print max }'

done

 

使用linux脚本打印每年最高温度，先解释一下该脚本几个注意点。

脚本目的是发现每年的最高温度，第一句for year in 后的all/*表示在名称为all的文件夹下每年度的温度信息都以 如 1990.gz 方式存在。使用gunzip方式解压并打印，对打印的内容使用awk函数进行处理，获取最大温度，单个文件处理完毕后打印max。

 

在上一篇中获取的数据包是这样，年度为文件夹，当中包含若干个温度详情文件。

E:\testData\1990\010010-9999-1990.gz

E:\testData\1990\010014-9999-1990.gz

E:\testData\1990\010015-9999-1990.gz

E:\testData\1990\010016-9999-1990.gz

…

 

从后面Appendix C的描述中得知，实际上作者对这样的数据进行了处理，因为hadoop在处理大量的小文件时无法达到很高的效率，因此作者使用hadoop将小文件合并，并且给出了代码。

 

我比较希望能够使用脚本处理，将所有的gz解压之后，合并成为一个文件，打包成gz的格式，这样就能完全符合之前那段脚本的处理方式。所以，脚本如下：

packyear

#! /bin/sh

# /usr/data/packyear

 

# unzip all gz files in data

for yeards in data/*

do

       # unzip all gz files in year directory

       for gzfile in $yeards/*

       do

              gunzip $gzfile

       done

      

       # cat all content to year file

       cat $yeards/* | head -2 >> $yeards.tc

 

       # remove year directory

       rm -rf $yeards

       mv $yeards.tc $yeards

 

       # zip the tc file

       gzip $yeards

done

 

根据实际路径改写的计算最大温度的脚本

maxyear

#! /bin/sh

# /usr/data/ maxyear

 

for year in /usr/data/*

do

  basename $year .gz

  gunzip -c $year | \

    awk '{temp=substr($0, 88, 5)+0;

        q=substr($0, 93, 1);

        if(temp !=9999 && q ~ /[01459]/ && temp > max) max = temp}

      END {print max}'

done

这个脚本最终显示出来会是：

1990

3

这样的格式。由于对数据结构的不熟悉，所以不确定显示出来的数据是否正确，但是基本的脚本和数据操作方式就是这样了。

posted @ 2012-03-29 16:21 一酌散千忧 阅读(476) | 评论 (0) | 编辑 收藏