Oozie-HA

On 三月 17th, 2014 by klose | No Comments | Posted in 互联网应用, 海量数据存储与处理

1.Oozie是state-less,状态存储在DB中。 2.借助LoadBalancer、Virtual IP、或者DNS Round-Robin实现对外单一的host封装。 3.利用Zookeeper实现多Server在被用户访问同一个job的Distributed Locking。(实际上仅仅注册了Server,没有注册job-id的状态到ZK,因为后端有统一的DB存储所有的作业的状态。通过Zookeeper,每一个Oozie Server知道当前有几个正在执行的instances,使用mod算法,每一个oozie Server选取部分的Coordinator jobs来进行materialize。)Materialization一个Coordinator上的workflow,是从无到有(WAITING),在从有到RUNNING的过程。 4.支持到任意Server查询任何的job的log,目前通过Log Streaming(HTTP),后续可能会考虑MapReduce JobHistoryServer的方案,将已经完成作业的log存储到HDFS文件夹中. Refer to: Oozie-615 Cloudera-Blog-O

工作小结-Y-1

On 三月 10th, 2014 by klose | No Comments | Posted in 成长历程

Conclusion_201310-201403 最近在Y公司的Hadoop Team,这几个月对我的影响还是挺大的,感觉收获了不少: 1) Get catch of Hadoop/Yarn Again. Before I graduated from ICT, I had spent lots of time in researching Distributed computing framework, then due to my first job as to HBase, they were set aside. Now when I get back to the subject, I feel very excited and a little unfamiliar. Hadoop Security, Yarn log policy, Container lifetime, etc. 2) Acquire a lot of practice how to maintain or manager large number of normal users, especially in multi-tenant data-sharing environment. 3) Touch and become familiar with some other components in hadoop-ecosystem. Oozie – a very useful work flow and co

HBase深入分析之RegionServer

On 十月 11th, 2013 by klose | No Comments | Posted in 互联网应用, 海量数据存储与处理

HBase深入分析之RegionServer 所有的用户数据以及元数据的请求,在经过Region的定位,最终会落在RegionServer上,并由RegionServer实现数据的读写操作。本小节将重点介绍RegionServer的代码结构和功能,从实现细节上深入理解RegionServer对于数据的操作流程。 1 RegionServer概述 RegionServer是HBase集群运行在每个工作节点上的服务。它是整个HBase系统的关键所在,一方面它维护了Region的状态,提供了对于Region的管理和服务;另一方面,它与Master交互,上传Region的负载信息上传,参与Master的分布式协调管理。具体如图(1)所示。 图(1) RegionServer的整体功能图 HRegionServer与HMaster以及Client之间采用RPC协议进行通信。HRegionServer向HMaster定期汇报节点的负载状况,包括RS内存使用状态、在线状态的Region等信息,在该过程中RS扮演了RPC客

HFile文件格式与HBase读写

On 九月 9th, 2013 by klose | 2 Comments | Posted in 互联网应用, 海量数据存储与处理

HFile是HBase存储数据的文件组织形式。HFile文件的特点: 1)HFile由DataBlock、Meta信息(Index、BloomFilter)、Info等信息组成。 2)整个DataBlock由一个或者多个KeyValue组成。 3)在文件内按照Key排序。 HFile V1的数据组织格式: DataBlock区域、MetaBlock(bloomfilter) 与FileInfo、DataBlockIndex、MetaBlockIndex、Trailer分离。 打开一个HFile文件需要加载FileInfo、DataBlockIndex、MetablockIndex以及Fixed File Trailer到内存。 如下图所示: HFile V1的数据格式在0.92版本升级到V2版本, HFile V2的数据组织格式如下图所示: 与V1版本的相比,它的区别在于 1)文件分为三部分:Scanned block section,Non-scanned block section,以及Opening-time data section 2) 为DataBlockIndex建立多层索引。DataBlockIndex分为Leaf Index Block、R

Google-MegaStore的解读

On 八月 14th, 2013 by klose | 2 Comments | Posted in 互联网应用, 海量数据存储与处理

MegaStore是Google在BigTable之上实现了一个跨机房高可用的数据库。 它提供了类似DB的数据分布、索引的功能,实现了在EntityGroup内部以及EntityGroup之间的事务性,并且通过Paxos协议实现在DC之间多备份的一致性。 MegaStore的目标:在跨机房PB级的数据规模上,支持交互式在线服务。我们知道在Google内部的访问情况是,每天几百亿次的访问请求的应用,读写比例大概在7:1。在这样的规模上,需要达到的特性: 1)高扩展性,无论在机器扩展性还是数据规模上 2)快速的开发迭代速度, 3)低延迟 4)数据一致性 5)高可用 MegaStore的实现原理: 1)从数据库的扩展性的角度上,把大数据切分成更小粒度的数据集(EG),每个数据库保持一个独立的log,保存在BigTable当中。//这也就意味着在每个DC上有一个独立的BigTable数据库。 2)从可用性角度上讲,在跨机

深入分析HBase RPC(Protobuf)实现机制

On 八月 2nd, 2013 by klose | No Comments | Posted in 互联网应用, 海量数据存储与处理

背景 在HMaster、RegionServer内部,创建了RpcServer实例,并与Client三者之间实现了Rpc调用,HBase0.95内部引入了Google-Protobuf作为中间数据组织方式,并在Protobuf提供的Rpc接口之上,实现了基于服务的Rpc实现,本文详细阐述了HBase-Rpc实现细节。 HBase的RPC Protocol  在HMaster、RegionServer内部,实现了rpc 多个protocol来完成管理和应用逻辑,具体如下protocol如下: HMaster支持的Rpc协议: MasterMonitorProtocol,Client与Master之间的通信,Master是RpcServer端,主要实现HBase集群监控的目的。 MasterAdminProtocol,Client与Master之间的通信,Master是RpcServer端,主要实现HBase表格的管理。例如TableSchema的更改,Table-Region的迁移、合并、下线(Offline)、上线(Online)以及负载平衡,以及Table的删除、快照等相关功能。 Reg

Sparrow(SOSP13)—一种加速短作业的调度方法

On 七月 16th, 2013 by klose | 1 Comment | Posted in 互联网应用, 海量数据存储与处理

背景: 当前大规模数据分析框架的发展朝着两个趋势在变化: 1)任务执行时间更短。 2)更大的任务并行度。 因此,在当前分布式计算框架的调度系统中,需要有所改变,以满足如下的需求: 1)更快的任务调度效率,mill-seconds级别。 2)良好的容错,High Availability. 3)较高的吞吐率,High Throughput. 分析一下:什么原因会造成多任务的作业执行时间较长? 1)作业内任务分配不合理,在同样的并行层次上,任务执行逻辑和处理的数据量不一致,从而拉长整个作业的执行时间。以MapReduce为例的大数据分析框架中,数据是等分的,并且,处理逻辑是一致的,因此,该问题仅仅出现在以DAG、或者具有Data-Skew的数据逻辑中。 2)调度的不均衡性。根据Hadoop作业调度的情况,作业的执行时间由最为执行时间最长的任务决定。例如,Hadoop调度的一个MapTask到

HDFS HA-Quorum Journal Manager

On 七月 8th, 2013 by klose | 4 Comments | Posted in 互联网应用, 海量数据存储与处理

1、背景 HDFS HA,即NameNode单点故障问题,一直是关系到HDFS稳定性最为重要的特性。之前Hadoop0.23初探系列文章中,介绍了HDFS的Federeation概况、配置与部署的情况,以及有关HA的相关概念。  Hadoop0.23.0初探1—前因后果 Hadoop0.23.0初探2—HDFS Federation部署 Hadoop0.23.0初探3—HDFS NN,SNN,BN和HA HDFS HA的发展经历了如下几个阶段: 1)手动恢复阶段。手动备份fsimage、fsedits数据,NN故障之后,重启hdfs。这是最早期使用的办法,由于早期数据量、机器规模、以及对应用的影响还比较小,该方案勉强坚持了一段时间。 2)借助DRBD、HeartbeatHA实现主备切换。 使用DRBD实现两台物理机器之间块设备的同步,即通过网络实现Raid1,辅以Heartbeat HA实现两台机器动态角色切换,对外(DataNode、DFSClient)使用虚IP来统一配置。这种策略,可以

深入分析HBase-Phoenix执行机制与原理

On 七月 1st, 2013 by klose | 2 Comments | Posted in 互联网应用, 海量数据存储与处理

针对HBase上SQL解决方案,目前社区内比较热门的有Cloudera的Impala,Horntworks的Drill,以及Hive。根据与HBase的操作方式,可以分为三种: 以MapReduce为核心,单个任务使用hbase-client原始接口访问; 以Google Dremel为核心,单个任务使用hbase-client原始接口访问; 以HBase-Coprocessor为核心,结合Google Dremel的思想,客户端合并多个节点的处理结果。 Phoenix的安装: 1)git clone https://github.com/forcedotcom/phoenix.git 2)安装apache-maven,可以自行google 3)mvn process-sources 4)mvn package -DskipTests 5)拷贝phoenix-{versionid}.jar到HBASE_HOME/lib/下,重启RS 6)java -jar phoenix-{versionid}-client.jar $(zkquorum) example/web_stat.sql example/web_stat.csv //导入数据 7)java -jar phoenix-{versioni

HBase新特性—Stripe Compaction

On 六月 25th, 2013 by klose | No Comments | Posted in 互联网应用, 海量数据存储与处理

借鉴于LevelDB、Cassandra的Compaction方法,https://issues.apache.org/jira/browse/HBASE-7667 提出了Stripe Compaction的方法。 Motivation: 1)过多Region会增大RS维护的开销,降低RS的读写性能。随着数据量的增大,在一定程度上增加Region个数,会提高系统的吞吐率。然而,RS上服务的Region个数增多,增加了RS下内存维护的开销,尤其每个Store下都配置有一个MemStore,从而会造成频率更高的Flush操作,影响系统的读写性能。因此,如果能够提出更轻量级的mini-Region,不仅能够降低服务多个Region的开销,而且能够提升读写数据的效率。 2) Region Compaction容易”放大”。例如,Region区间为[1FFF,2FFF),在该区间内仅有[1FFF,21FF)区间有大量的写操作(put、delete),但是,在触及MajorCompaction条件时,却需要对所有的文件执行Maj