通常情况下,HEAD指向一个分支;同时,每一个分支对应一个特定的commit(确切的说,一个分支上可以有多个commit,但是只有一个顶层commit,而且commit之间是简单的线性关系)。我们来看下面这个包含三个commit的例子,其中目前在master分支上。
HEAD (refers to branch 'master')
|
v
a---b---c branch 'master' (refers to commit 'c')
^
|
tag 'v2.0' (refers to commit 'b')
在这样的状况下,如果进行一次提交,当前分支将指向新的提交点。具体来说,git commit创建了一个新的commit id,它的父节点是的commit的id是C。这个时候,HEAD仍然指向master分支,而且指向commit id是d的提交点。
$ edit; git add; git commit
HEAD (refers to branch 'master')
|
v
a---b---c---d branch 'master' (refers to commit 'd')
^
|
tag 'v2.0' (refers to commit 'b')
有时,如果能够检出到一个不在分支顶端的commit点是很有用的(通常情况下,我们直接运行命令git checkout mater,这样checkout到master的最新commit上);同样,如果能够创建一个不属于任何分支的提交点也是一件很有用的事情。运行接下来的两条命令,看看会发生什么。
$ git checkout v2.0 # or
$ git checkout master^^
HEAD (refers to commit 'b')
|
v
a---b---c---d branch 'master' (refers to commit 'd')
^
|
tag 'v2.0' (refers to commit 'b')
注意,现在head已经指向commit b,这就是所谓的dedatched head状态。从这里我们也可以看出,head是当前index的状态,而不是当前分支(的最近commit节点)。这仅仅意味着head指向某个特定的commit点,而不是指向每一个特定的分支(的顶端节点)。如果我们此时提交一个commit,看看将要发生什么:
$ edit; git add; git commit
|
v
e
/
a---b---c---d branch 'master' (refers to commit 'd')
^
|
tag 'v2.0' (refers to commit 'b')
注意,此时产生了一个新的提交点,但是它只能被head索引到,不属于任何一个分支。当然,我们还可以给在这个“无名分支”的基础上继续提交。
$ edit; git add; git commit
HEAD (refers to commit 'f')
|
v
e---f
/
a---b---c---d branch 'master' (refers to commit 'd')
^
|
tag 'v2.0' (refers to commit 'b')
实际上,我们可以进行任何git的常规操作。但是,让我们开看看如果我们运行git checkout master将会发生什么:
$ git checkout master
e---f |
/ v
a---b---c---d branch 'master' (refers to commit 'd')
^
|
tag 'v2.0' (refers to commit 'b')
此时,我们一定要注意,e f已经处于无法被索引到的状态。最终e和f将被git的默认回收机制所回收,除非我们在它们被回收之前创建一个指向他们的索引。如果我们没有从commit f离开的话,可以用接下来的命令创建一个指向f的索引。
$ git checkout -b foo (1)
$ git branch foo (2)
$ git tag foo (3)
1.创建来一个foo分支,指向f,接着更新head指向分支foo,此时,我们不再处在detached head的状态
2.同样创建了一个foo分支,但是head仍然指向master分支,仍然处在detached head的状态。
3.创建了一个新标签foo,仍处于detached的状态。
如果我们从f处离开,我们必须首先恢复他的主体名称,接着我们才可以创建指向它的索引。例如,为了看看最近的两个由head指向的commit点,我们可以使用如下的命令:
$ git reflog -2 HEAD # or
$ git log -g -2 HEAD
在说Hadoop之前,作为一个铁杆粉丝先粉一下Google。Google的伟大之处不仅在于它建立了一个强悍的搜索引擎,它还创造了几项革命性的技术:GFS,MapReduce,BigTable,即所谓的Google三驾马车。Google虽然没有公布这几项技术的实现代码,但它发表了详细的设计论文,这给业界带来了新鲜气息,很快就出现了类似于Google三驾马车的开源实现,Hadoop就是其中的一个。
Hadoop是Apache基金会下的一款开源软件,它实现了包括分布式文件系统HDFS和MapReduce框架在内的云计算软件平台的基础架构,并且在其上整合了包括数据库、云计算管理、数据仓储等一系列平台,其已成为工业界和学术界进行云计算应用和研究的标准平台。Hadoop现在已经广泛应用于包括国外的FaceBook,Twitter,Yahoo!等公司,国内的百度,阿里等,Hadoop运行在数以千计的服务器和数以万计的CPU的集群上。
基于Hadoop,用户可编写处理海量数据的分布式并行程序,并将其运行于由成百上千个结点组成的大规模计算机集群上。Hadoop已被全球几大IT公司用作其”云计算”环境中的重要基础软件,如:雅虎正在开发基于Hadoop的开源项目Pig, 这是一个专注于海量数据集分析的分布式计算程序。亚马逊公司则基于Hadoop推出了Amazon S3(Amazon Simple Storage Service ),提供可靠,快速,可扩展的网络存储服务。因此,Hadoop是云计算中一部分技术的实现,而不是全部。
我们可以回想下当初做的课堂作业,它可能是一个处理数据的程序,没有多线程,没有进程间通信,数据输入都是来自键盘(stdin),处理完数据之后打印到屏幕(stdout),这时的程序非常简单。后来我们学习了多线程、内存管理、设计模式,写出的程序越来越大,也越来越复杂。但是当学习使用Hadoop时,我们发现又回到了最初,尽管底层是一个巨大的集群,可是我们操作文件时就像在本地一样简单,写MapReduce程序时也只需要在单线程里实现数据处理。
Hadoop就是这样一个东西,简单的文件系统(HDFS),简单的计算模型(MapReduce)。这其中,我觉得HDFS是很自然的东西,如果我们自己实现一个,也很可能是这样的。但是仔细琢磨下MapReduce,会发现它似乎是个新奇事物,不像HDFS的界面那样通俗易懂老少皆宜。MapReduce虽然模型简单,却是一个新的、不广为人所知的概念。比如说,如果说要简化计算,为何要做成Map和Reduce两个阶段,而不是一个函数足矣呢?另外,它也不符合我们耳熟能详的那些设计模式。一句话,MapReduce实在太另类了。
Hadoop的思想来源于Google的几篇论文,Google的那篇MapReduce论文里说:
这样我们就可以把MapReduce理解为,把一堆杂乱无章的数据按照某种特征归纳起来,然后处理并得到最后的结果。Map面对的是杂乱无章的互不相关的数据,它解析每个数据,从中提取出key和value,也就是提取了数据的特征。经过MapReduce的Shuffle阶段之后,在Reduce阶段看到的都是已经归纳好的数据了,在此基础上我们可以做进一步的处理以便得到结果。这就回到了最初,终于知道MapReduce为何要这样设计。
日志处理: Hadoop擅长这个
并行计算
ETL: 每个人几乎都在做ETL(Extract-Transform-Load)工作 Netezza关于使用Hadoop做ETL任务的看法)
使用HBase做数据分析: 用扩展性应对大量的写操作—Facebook构建了基于HBase的实时数据分析系统
机器学习: 比如Apache Mahout项目
Hadoop是什么?
是google的核心算
一、概述
定义一个用于创建对象的接口,让子类去决定实例化哪个类。工厂方法将一个类的实例化延迟至其子类。
二、适用性
1.当一个类不知道它所必须创建的对象的类的时候。
2.当一个类希望由其子类来指定它所创建的对象的时候。
3.当类将创建对象的职责委托给多个帮助子类的某一个,并且你希望将哪一个帮助子类是代理者这一信息局部化的时候。
三、参与者
1.Product:定义工厂方法所创建的对象的接口。
2.ConcreteProduct:实现Product接口。
3.Creator:声明工厂方法,该方法返回一个Product类型的对象。Creator也可以定义一个工厂方法的缺省实现,它返回一个缺省的ConcreteProduct对象。
4.ConcreteCreator:重定义工厂方法以返回一个ConcreteProduct实例。
四、类图
五、示例
Product
package cn.lynn.factorymethod; public interface IWork { public void doWork(); }ConcreteProduct
package cn.lynn.factorymethod; public class ManagerWork implements IWork { @Override public void doWork() { System.out.println("经理审批流程!"); } }
package cn.lynn.factorymethod; public class EmployeeWork implements IWork { @Override public void doWork() { System.out.println("员工处理事情!"); } }Creator
package cn.lynn.factorymethod; public interface IWorkFactory { public IWork getWork(); }ConcreteCreator
package cn.lynn.factorymethod; public class ManagerWorkFactory implements IWorkFactory { @Override public IWork getWork() { return new ManagerWork(); } }
package cn.lynn.factorymethod; public class EmployeeWorkFactory implements IWorkFactory { @Override public IWork getWork() { return new EmployeeWork(); } }Test
package cn.lynn.factorymethod; public class Test { public static void main(String[] args) { IWorkFactory employeeWorkFactory = new EmployeeWorkFactory(); employeeWorkFactory.getWork().doWork(); IWorkFactory managerWorkFactory = new ManagerWorkFactory(); managerWorkFactory.getWork().doWork(); } }Result
员工处理事情! 经理审批流程!