<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[PunC的专栏]]></title><description><![CDATA[]]></description><link>https://blog.youkuaiyun.com/Pun_C</link><language>zh-cn</language><generator>https://blog.youkuaiyun.com/</generator><copyright><![CDATA[Copyright &copy; Pun_C]]></copyright><item><title><![CDATA[Hadoop高可用特性解析]]></title><link>https://blog.youkuaiyun.com/Pun_C/article/details/53244605</link><guid>https://blog.youkuaiyun.com/Pun_C/article/details/53244605</guid><author>Pun_C</author><pubDate>Sun, 20 Nov 2016 21:12:57 +0800</pubDate><description><![CDATA[HDFS采用的是fsimage + edits的存储方式，fsimage是某个时间的内存文件系统镜像，edits是修改操作，每个修改操作称为一个事务，有一个整形的事务id指定。checkpoint的时候就存储一次fsimage，同时可以删除之前的edits。另外edits切割为很多segement，不同的segment都包含一段修改操作记录，正在写入的segment的文件名有inprogress和]]></description><category></category></item><item><title><![CDATA[Java进程与父子进程的标准输出流关联导致线程卡死的故障]]></title><link>https://blog.youkuaiyun.com/Pun_C/article/details/52826554</link><guid>https://blog.youkuaiyun.com/Pun_C/article/details/52826554</guid><author>Pun_C</author><pubDate>Sat, 15 Oct 2016 23:32:01 +0800</pubDate><description><![CDATA[故障现象
    Java调度系统创建PHP数据脚本后，并且获取其标准输出流，然后循环读取其标准输出流内容。此时PHP数据脚本执行时间过长，Java调度系统Process.destory()杀掉进程后，ps也无法找到对应PHP数据脚本，但Java的线程却无法退出，依然卡死在读取标准输出流。曾经怀疑是kill无法清理干净进程，于是变为强制执行kill -9杀掉超时的PHP数据脚本，但情况依旧，Ja]]></description><category></category></item><item><title><![CDATA[数据库的一些论文的个人整理]]></title><link>https://blog.youkuaiyun.com/Pun_C/article/details/51892878</link><guid>https://blog.youkuaiyun.com/Pun_C/article/details/51892878</guid><author>Pun_C</author><pubDate>Tue, 12 Jul 2016 21:55:13 +0800</pubDate><description><![CDATA[数据库架构相关
Architecture of a Database System. Joseph M. Hellerstein, Michael Stonebraker and James Hamilton
    图灵奖获得者Michael Stonebraker的论文之一，具体介绍了数据库的架构以及相关理论和主流数据库的具体做法。

启发：
    对于已经阅读过基础的数据库教材的]]></description><category></category></item><item><title><![CDATA[LRU-K，2Q，LIRS算法介绍与比较]]></title><link>https://blog.youkuaiyun.com/Pun_C/article/details/50920469</link><guid>https://blog.youkuaiyun.com/Pun_C/article/details/50920469</guid><author>Pun_C</author><pubDate>Fri, 18 Mar 2016 09:39:33 +0800</pubDate><description><![CDATA[研究H2的过程中发现新的存储引擎MVStore使用了新的cache替换算法——LIRS，经过一系列相关的论文研读，发现比旧存储引擎PageStore的LRU算法改良不少。为了更好地了解LIRS的优异性，把同样属于LRU变种的基于倒数第二次访问时间对比进行cache替换的LRU-K（K一般为2）[1]，2Q[2]，LIRS[3]算法进行对比。


概述

    为方便讨论，统一称呼要进行]]></description><category></category></item><item><title><![CDATA[HBase的split分析]]></title><link>https://blog.youkuaiyun.com/Pun_C/article/details/47173453</link><guid>https://blog.youkuaiyun.com/Pun_C/article/details/47173453</guid><author>Pun_C</author><pubDate>Fri, 31 Jul 2015 17:50:17 +0800</pubDate><description><![CDATA[HBase在新建一个表的时候，默认会把所有数据都会放在一个HRegion上，主节点HMaster根据一定的策略把HRegion分配到不同的HRegionServer从节点上，客户端在进行读写操作的时候，就会访问对应HRegionServer的HRegion。当HRegion的数据量超过阀值的时候，为了防止单个热点访问带来的压力，HBase就会对HRegion进行split操作，一个父HRegion]]></description><category></category></item><item><title><![CDATA[HBase的compact分析]]></title><link>https://blog.youkuaiyun.com/Pun_C/article/details/47132419</link><guid>https://blog.youkuaiyun.com/Pun_C/article/details/47132419</guid><author>Pun_C</author><pubDate>Wed, 29 Jul 2015 19:13:28 +0800</pubDate><description><![CDATA[HBase是基于LSM树存储模型的分布式NoSQL数据库。LSM树对比普遍的B+树来说，能够获得较高随机写性能的同时，也能保持可靠的随机读性能（可参考这里）。在进行读请求的时候，LSM树要把多个子树（类似B+树结构）进行归并查询，对于HBase来说，这些子树就是HFile（还包括内存上的树结构MemStore）。因此归并查询的子树数越少，查询的性能就越高。

Compact的作用

   ]]></description><category></category></item><item><title><![CDATA[HBase写请求分析]]></title><link>https://blog.youkuaiyun.com/Pun_C/article/details/46841679</link><guid>https://blog.youkuaiyun.com/Pun_C/article/details/46841679</guid><author>Pun_C</author><pubDate>Sat, 11 Jul 2015 14:21:16 +0800</pubDate><description><![CDATA[HBase作为分布式NoSQL数据库系统，不单支持宽列表，并且对于随机读写来说也具有较高的性能。在高性能的随机读写事务的同时，HBase也能保持事务的一致性。目前HBase只支持行级别的事务一致性。本文主要探讨一下HBase的写请求流程，主要基于0.98.8版本的实现。

客户端写请求

   HBase提供的Java client API是以HTable为主要接口，对应其中的HBase表]]></description><category></category></item><item><title><![CDATA[HBase读请求分析]]></title><link>https://blog.youkuaiyun.com/Pun_C/article/details/46841625</link><guid>https://blog.youkuaiyun.com/Pun_C/article/details/46841625</guid><author>Pun_C</author><pubDate>Sat, 11 Jul 2015 14:11:10 +0800</pubDate><description><![CDATA[HBase为了提供实时查询，以及较高性能的写请求事务吞吐量，对读/写请求都做了大量的优化。经过阅读源码和远程调试，大致了解了读请求的流程。本文主要是基于HBase的0.98.8版本的实现。

客户端读请求

    HBase为客户端提供了的读请求API主要有两个，get和scan。其中，get是通过指定单个的rowKey，获取其对应的value值。而scan是指定startRow和sto]]></description><category></category></item><item><title><![CDATA[Hadoop的一个变长long编码剖析]]></title><link>https://blog.youkuaiyun.com/Pun_C/article/details/46495623</link><guid>https://blog.youkuaiyun.com/Pun_C/article/details/46495623</guid><author>Pun_C</author><pubDate>Sun, 14 Jun 2015 23:38:11 +0800</pubDate><description><![CDATA[Hadoop对于long、int （化成long进行编码）的编码设计了自己的一套编码方式，这是一个zero-compressed encoded的变长编码方式，有利于大大压缩冗余数据。具体算法其实很简单，具体来说有如下几点：
1、对于-112 
2、如果i大于0，则编码的第一个字节 b 范围在-113和-120之间，则 i 会有 (-112 - b)个字节，所以可以表示有1-8个字节；
3、]]></description><category></category></item><item><title><![CDATA[Java泛型的一些限制]]></title><link>https://blog.youkuaiyun.com/Pun_C/article/details/46398453</link><guid>https://blog.youkuaiyun.com/Pun_C/article/details/46398453</guid><author>Pun_C</author><pubDate>Sun, 07 Jun 2015 10:53:36 +0800</pubDate><description><![CDATA[和C++泛型对比，Java泛型只是一种编译期间的擦拭机制。这是由于考虑到和以前的兼容而考虑的一种折中方案。在编译好的泛型代码里，编译期间已经把所有的泛型信息给擦拭掉，因此无法获得任何有关泛型参数类型的信息。因此List和List实际上是同一类型。
    参考以下代码：
    //以下3个例子都无法通过编译
    public  void testGeneric(Object arg) {]]></description><category></category></item><item><title><![CDATA[log4j之个人浅析]]></title><link>https://blog.youkuaiyun.com/Pun_C/article/details/45622083</link><guid>https://blog.youkuaiyun.com/Pun_C/article/details/45622083</guid><author>Pun_C</author><pubDate>Sun, 10 May 2015 20:49:23 +0800</pubDate><description><![CDATA[最近稍微大致地阅读了log4j的源码，毕竟这是Java开源日志框架里几乎最常用的一个实现。在大多数实际应用中，还需要诸如common-logging、slf4j等Facade模式日志框架对log4j进行封装，实际日志记录、输出等级、格式化等工作都是由log4j完成。本文把注意力集中在log4j身上，探讨一下这个开源日志框架的内部。
特性
    关于log4j的具体配置以及例子这里就不多说了，]]></description><category></category></item><item><title><![CDATA[Zookeeper介绍]]></title><link>https://blog.youkuaiyun.com/Pun_C/article/details/44281409</link><guid>https://blog.youkuaiyun.com/Pun_C/article/details/44281409</guid><author>Pun_C</author><pubDate>Sun, 15 Mar 2015 21:57:05 +0800</pubDate><description><![CDATA[Zookeeper是一个分布式的开源系统，目的是为分布式应用提供协调一致性服务。分布式应用能够在Zookeeper提供的简单原语集之上构造更高层次的服务，例如统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。Zookeeper使用了类似文件系统的目录树结构的数据模型，帮助简化程序编写。
        目前，一些知名的大数据开源框架就是利用了Zookeeper来完善分布式的协调一致]]></description><category></category></item><item><title><![CDATA[Hadoop 1.2.1升级2.6.0的一次崎岖之旅（包括Hive、HBase对应的升级）]]></title><link>https://blog.youkuaiyun.com/Pun_C/article/details/44118119</link><guid>https://blog.youkuaiyun.com/Pun_C/article/details/44118119</guid><author>Pun_C</author><pubDate>Sat, 07 Mar 2015 17:44:11 +0800</pubDate><description><![CDATA[为了更好地紧跟大数据发展先进性的技术趋势，追赶业界最顶尖的发展技术，我们把线上环境的Hadoop 1.2.1升级到2.6.0版本。这次的升级其实早有预谋，但鉴于升级过程较为繁琐，并且不但涉及HDFS的底层存储的升级，还涉及Hive、Hbase等上层系统的使用，有一定的风险，因此一直都在等待一个合适的时机。直到最近，我们的利用了Hadoop2.6.0和HBase的0.98.8的API的ETL系统正式]]></description><category></category></item><item><title><![CDATA[HDFS新特性Centralized Cache Management介绍]]></title><link>https://blog.youkuaiyun.com/Pun_C/article/details/44118095</link><guid>https://blog.youkuaiyun.com/Pun_C/article/details/44118095</guid><author>Pun_C</author><pubDate>Sat, 07 Mar 2015 17:39:29 +0800</pubDate><description><![CDATA[概述


    HDFS作为Hadoop底层存储架构实现，提供了高可容错性，以及较高的吞吐量等特性。在Hadoop 2.3版本里，HDFS提供了一个新特性——Centralized Cache Management。该特性能够让用户显式地把某些HDFS文件强制映射到内存中，防止被操作系统换出内存页，提高内存利用效率，有效加快文件访问速度。对于Hive来说，如果对某些SQL查询里需要经常读取]]></description><category></category></item><item><title><![CDATA[Hadoop集群中JobTracker和TaskTracker启动耗时过多的原因分析]]></title><link>https://blog.youkuaiyun.com/Pun_C/article/details/44118041</link><guid>https://blog.youkuaiyun.com/Pun_C/article/details/44118041</guid><author>Pun_C</author><pubDate>Sat, 07 Mar 2015 17:35:05 +0800</pubDate><description><![CDATA[在正式环境中，我们遇到一个这样的问题：配置更改后，需要重启JobTracker和TaskTracker节点的进程。在重启过程中，JobTracker和TaskTracker进程都很快启动完成，但是查看JobTracker的50030端口的Web管理页面时，发现JobTracker一直无法探知任何一个TaskTracker节点，大概经过10分钟后，才陆陆续续地探知完所有的TaskTracker节点。]]></description><category></category></item><item><title><![CDATA[Hadoop的默认调度器JobQueueTaskScheduler的一个Map Task Pending问题]]></title><link>https://blog.youkuaiyun.com/Pun_C/article/details/44117871</link><guid>https://blog.youkuaiyun.com/Pun_C/article/details/44117871</guid><author>Pun_C</author><pubDate>Sat, 07 Mar 2015 17:29:57 +0800</pubDate><description><![CDATA[在正式环境的Hadoop任务调度里，集群整体资源还有大量slot的情况下，出现了某些MapReduce任务无法被调度，一直处于pending状态，无法获得集群slot资源进行计算的诡异情况。更改几个指定类的loglevel后，查看其Debug的log发现了问题原因：这是由于Hadoop 1.x默认的FIFO调度器JobQueueTaskScheduler在进行集群均衡计算时，忽略Speculati]]></description><category></category></item><item><title><![CDATA[Hadoop2.0新特性]]></title><link>https://blog.youkuaiyun.com/Pun_C/article/details/44117837</link><guid>https://blog.youkuaiyun.com/Pun_C/article/details/44117837</guid><author>Pun_C</author><pubDate>Sat, 07 Mar 2015 17:07:57 +0800</pubDate><description><![CDATA[一、大数据处理系统

        大量节点服务器组成集群，用户根据需要输入不同处理请求，经过复杂计算过程，输出对应结果，整个计算过程对用户来说透明。 对于这个大量节点组成的数据处理系统，需要考虑的问题有很多，比如数据存储、数据处理、资源管理、容错性、扩展性、较好的吞吐量......等问题。在目前来说，Hadoop框架可以有效解决以上大部分问题，而且由于Hadoop对于集群上的节点硬件要求不]]></description><category></category></item><item><title><![CDATA[Java调用重载方法(invokevirtual)和接口方法(invokeinterface)的解析]]></title><link>https://blog.youkuaiyun.com/Pun_C/article/details/43118697</link><guid>https://blog.youkuaiyun.com/Pun_C/article/details/43118697</guid><author>Pun_C</author><pubDate>Sun, 25 Jan 2015 20:40:35 +0800</pubDate><description><![CDATA[先开坑]]></description><category></category></item><item><title><![CDATA[Hadoop的mapreduce.framework.name属性原理]]></title><link>https://blog.youkuaiyun.com/Pun_C/article/details/42966983</link><guid>https://blog.youkuaiyun.com/Pun_C/article/details/42966983</guid><author>Pun_C</author><pubDate>Wed, 21 Jan 2015 13:10:15 +0800</pubDate><description><![CDATA[配置Tez引擎时，只要我们把Tez的jars和配置文件路径添加进HADOOP_CLASSPATH里，然后通过设置mapred-site.xml文件的mapreduce.framework.name属性为yarn-tez，就可以替换默认的MR框架为tez引擎。
    其中的奥妙在于使用了JDK6+的一个特性ServiceLoader类。其为JDK实现了一个依赖注入的机制。
    Servic]]></description><category></category></item><item><title><![CDATA[可重入(Reentrancy)VS线程安全(Thread safety)]]></title><link>https://blog.youkuaiyun.com/Pun_C/article/details/39802845</link><guid>https://blog.youkuaiyun.com/Pun_C/article/details/39802845</guid><author>Pun_C</author><pubDate>Sun, 05 Oct 2014 14:00:04 +0800</pubDate><description><![CDATA[可重入vs线程安全]]></description><category></category></item></channel></rss>