专注于HDFS、HBase、Yarn、Spark、Kafka等领域研发
Apache Thrift 是 Facebook 实现的一种高效的、支持多种编程语言的远程服务调用的框架。 它采用接口描述语言定义并创建服务,支持可扩展的跨语言服务开发,所包含的代码生成引擎可以在多种语言中,如 C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, Smalltalk 等创建高效的、无缝的服务,其传输数据采用二进制格式,相对 XML 和 JSON 体积更小,对于高并发、大数据量和多语言的环境更有优势。
指定主机策略SpecificHostPolicy是一种总是返回一个指定主机名的worker的定位策略。如果在那个主机名对应机器上没有活跃worker的话则返回null。在SpecificHostPolicy内部,封装了一个成员变量,如下: // 主机名 priva...
循环遍历策略RoundRobinPolicy是一种通过循环遍历方式并且跳过没有足够空间workers的为下一个数据块选择worker的策略。如果没有worker被找到,该策略会返回null。
最大可用容量优先策略MostAvailableFirstPolicy是一种worker可用容量最大的定位策略。如果没有worker合格的话该策略返回null。它的核心方法getWorkerForNextBlock()实现如下: /** * A policy that returns the worker with the most available bytes. The policy returns null if no * worker is qualified. * 一种worker可用容量最大的定位策略。
LocalFirstPolicy是一个优先返回本地主机的定位策略,如果本地worker没有足够的容量,那么就会从活跃有效的workers列表随机选择一个worker用于每个块写入。
OpenFileOptions是为读数据打开一个文件方法的选项,提供了打开文件的多种选择。在OpenFileOptions内部,封装了两个重要的成员变量,如下: // 定位策略 private FileWriteLocationPolicy mLocationPolicy; // 读取类型 private ReadType mReadType; 其中mLocationPolicy为FileWriteLocationPolicy类型的定位策略,而mReadType为ReadType类型的读取类型。
Alluxio源码分析读数据:打开文件(二)
Alluxio源码分析读数据:打开文件(一)
Alluxio源码分析写数据:创建文件(二)
Alluxio源码分析写数据:创建文件(一)
Alluxio提供定位策略,用于确定应该选择哪个Worker来存储文件数据块。用户可以在CreateFileOptions中设置该策略以用于写文件,也可在OpenFileOptions中设置该策略用于向Alluxio中读文件。
一、读类型 1、CACHE_PROMOTE 如果读取的数据在Worker上时,该数据被移动到Worker的最高层。如果该数据不在本地Worker的Alluxio存储中,那么就将一个副本添加到本地Alluxio Worker中,用于每次完整地读取数据快。
一、分层存储种类 1、MEM (内存) 2、SSD (固态硬盘) 3、HDD (硬盘驱动器) 二、分层存储参数 1、alluxio.worker.tieredstore.levels,缺省值1 Alluxio Worker多层存储中的最大存储级数。
一、写文件 // 获取文件系统客户端FileSystem实例 FileSystem fs = FileSystem.Factory.get(); // 构造Alluxio路径AlluxioURI实例 AlluxioURI pat...
一、Alluxio是什么? Alluxio是一个基于内存的分布式文件系统,它是架构在底层分布式文件系统和上层分布式计算框架之间的一个中间件,主要职责是以文件形式在内存或其它存储设施中提供数据的存取服务。
HBase是一个复杂的分布式非结构化数据库,它将表中的数据按照行的方向切分成一个个的Region,并在若干RegionServer上上线,依靠所在RegionServer对外提供数据读写IO服务。
HBase源码分析之Region下线,近期推出!
HBase源码分析之Region上线,近期推出!
HBase源码分析之Region合并merge,近期推出!
HDFS源码分析心跳汇报之周期性心跳,近期推出!
HDFS源码分析心跳汇报之DataNode注册,近期推出!
HRegionServer上工作组件汇总,近期推出!
HBase源码分析之Region上Spilt流程,近期推出!
Disruptor简介,近期推出!
设计模式之装饰者模式,近期推出!
在《HDFS源码分析心跳汇报之数据块增量汇报》一文中,我们详细介绍了数据块增量汇报的内容,了解到它是时间间隔更长的正常数据块汇报周期内一个smaller的数据块汇报,它负责将DataNode上数据块的变化情况及时汇报给NameNode。
在《HDFS源码分析心跳汇报之数据结构初始化》一文中,我们了解到HDFS心跳相关的BlockPoolManager、BPOfferService、BPServiceActor三者之间的关系,并且知道最终HDFS的心跳是通过BPServiceActor线程实现的。
一、问题引入 二、何为跳表 跳表具有如下性质: 1、 跳表由很多层结构组成; 2、跳表中每一层都是一个有序链表; 3、跳表的最底层(Level 1)的链表包含所有元素; 4、如果一个元素出现在跳表 Level i 的链表中,则它在 Level i 之下的链表也都会出现。
设计模式之适配器模式,近期推出!
// 核心是一个循环缓冲区。我们的循环缓冲区是一个LMAX Disruptor。当多个线程在单个WAL竞争append和sync时,它试图最小化同步与volatile写。 // Disruptor配置为处理多个生产者和仅有一个消费者(HBase中的生产者是调用append、sync的IPC Handlers)。
红黑树是一种自平衡二叉查找树 通过红黑两种颜色域保证树的高度近似平衡。它的每个节点是一个五元组:color(颜色),key(数据),left(左孩子),right(右孩子)和p(父节点)。 性质1. 节点是红色或黑色 性质2. 根是黑色 性质3. 所有叶子都是黑色(叶子是NIL节点) 性质4. 如果一个节点是红的,则它的两个儿子都是黑的 性质5. 从任一节点到其叶子的所有简单路径都包含相同数目的黑色节点。
在《HDFS源码分析心跳汇报之BPServiceActor工作线程运行流程》一文中,我们详细了解了数据节点DataNode周期性发送心跳给名字节点NameNode的BPServiceActor工作线程,了解了它实现心跳的大体流程: 1、与NameNode握手: 1.
一、引入:为什么要使用ThreadLocal 之前,在某位大牛的一篇文章中,看到了实现线程安全的几个层次,分别是: 1、使用无状态的对象 无状态对象也就是不变的对象,它是最安全的,因此不需要考虑线程间同步等安全...
我们知道,HBase是一个基于RowKey进行检索的分布式数据库。它按照行的方向将表中的数据切分成一个个Region,而每个Region都会存在一个起始行StartKey和一个终止行EndKey。
MovedRegionsCleaner是什么呢?我们先来看下它在HRegionServer上的定义: /** * Chore to clean periodically the moved region list * 被移动Region列表的定期清理工作线程 */ private MovedRegionsCleaner movedRegionsCleaner; 原来它是HRegionServer上一个被移动Region列表的定期清理工作线程。
昨日,某群友在某群里发了一个问题,内容如下: public class Base { private String baseName = "base"; public Base(){ callName(); } public void callName(){ System.
在《HDFS源码分析心跳汇报之整体结构》一文中,我们详细了解了HDFS中关于心跳的整体结构,知道了BlockPoolManager、BPOfferService和BPServiceActor三者之间的关系。
我们知道,HDFS全称是Hadoop Distribute FileSystem,即Hadoop分布式文件系统。既然它是一个分布式文件系统,那么肯定存在很多物理节点,而这其中,就会有主从节点之分。
在《HDFS源码分析DataXceiver之整体流程》一文中我们知道,无论来自客户端还是其他数据节点的请求达到DataNode时,DataNode上的后台线程DataXceiverServer均为每个请求创建一个单独的后台工作线程来处理,这个工作线程就是DataXceiver。
一、什么是ConcurrentHashMap? ConcurrentHashMap是一种线程安全且高效的HashMap。 二、为什么要引入ConcurrentHashMap? 针对Key-Value类型的集合而言,HashMap不是线程安全的,无法在多线程或高并发情况下使用,而Hashtable虽然使用synchronized关键字来保证安全,但是在高并发等线程竞争比较激烈的情况下其效率非常低下。
在《HDFS源码分析之DataXceiverServer》一文中,我们了解到在DataNode中,有一个后台工作的线程DataXceiverServer。它被用于接收来自客户端或其他数据节点的数据读写请求,为每个数据读写请求创建一个单独的线程去处理。
近期推出,敬请期待!
在《HBase源码分析之MemStore的flush发起时机、判断条件等详情》一文中,我们详细介绍了MemStore flush的发起时机、判断条件等详情,主要是两类操作,一是会引起MemStore数据大小变化的Put、Delete、Append、Increment等操作,二是会引起HRegion变化的诸如Regin的分裂、合并以及做快照时的复制拷贝等,同样会触发MemStore的flush流程。
前面三篇文章中,我们详细叙述了compact流程是如何在HRegion上进行的,了解了它的很多细节方面的问题。但是,这个compact在HRegionServer上是如何进行的?合并时文件是如何选择的呢?在这篇文章中,你将找到答案! 首先,在HRegionServer内部,我们发现,它定义了一个CompactSplitThread类型的成员变量compactSplitThread,单看字面意思,这就是一个合并分裂线程,那么它会不会就是HRegionServer上具体执行合并的工作线程呢?我们一步一步来看。
在《HBase源码分析之HRegion上compact流程分析(二)》一文中,我们没有讲解真正执行合并的CompactionContext的compact()方法。现在我们来分析下它的具体实现。
继《HBase源码分析之HRegion上compact流程分析(一)》一文后,我们继续HRegion上compact流程分析,接下来要讲的是针对表中某个列簇下文件的合并,即HStore的compact()方法,代码如下: /** * Compact the StoreFiles. This method may take some time, so the calling * thread must be able to block for long periods. * * 合并存储文件。
首先来想两个问题:1、何谓compact?2、它产生的背景是怎样的? compact是指HBase表中HRegion上某个Column Family下,部分或全部HFiles的合并。
前面的几篇文章,我们详细介绍了HBase中HRegion上MemStore的flsuh流程,以及HRegionServer上MemStore的flush处理流程。那么,flush到底是在什么情况下触发的呢?本文我们将详细探究下HBase中MemStore的flush流程的发起时机,看看到底都有哪些操作,或者哪些后台服务进程会触发MemStore的flush。
继上篇文章《HBase源码分析之HRegionServer上MemStore的flush处理流程(一)》遗留的问题之后,本文我们接着研究HRegionServer上MemStore的flush处理流程,重点讲述下如何选择一个HRegion进行flush以缓解MemStore压力,还有HRegion的flush是如何发起的。
在《HBase源码分析之HRegion上MemStore的flsuh流程(一)》、《HBase源码分析之HRegion上MemStore的flsuh流程(二)》等文中,我们介绍了HRegion上Memstore flush的主体流程和主要细节。