云计算、分布式架构、K8S、大数据、机器学习、搜索、推荐、广告

1、  和其他模块之间的交互接口分析1)作为client，NodeStatusUpdater通过ResourceTracker协议和RM进行交互(NMàRM)。该API有两个方法向RM注册NodeManager，参数为httpPort、nodeId、totalResource，其中totalResource为节点的总可分配资源，包括CPU、内存。向RM心跳，NM启动后通过定期的向RM汇报Conta

执行mapreduce的几种方式1、copy jar到hadoop中执行           ./hadoop jar  xxxx.jar mainclass          ./hadoop jar -libjars xxx.jar    /home/test/xxx.jar      对于引用的第三方jar,该如何处理？？         a、通过命令行参数传递jar文件

整个处理流程包括主要包括，语法解析（抽象语法树，AST,采用antlr），语义分析(sematic Analyzer生成查询块)，逻辑计划生成（OP tree），逻辑计划优化,物理计划生成（Task tree），以及物理计划执行组成。下面这张图（不知道是谁画的）简要的说明了整个处理的流程 这里重点说一下物理计划生成，以及执行。物理计划的生成是根据逻辑操作树（operator）来

一般情况下，在输入源是文件的时候，一个task的map数量由splitSize来决定的，那么splitSize是由以下几个来决定的goalSize = totalSize / mapred.map.tasksminSize = max {mapred.min.split.size, minSplitSize}splitSize = max (minSize, min(goalSize,

网上有很多mapreduce的源码解析以及执行过程，这里从相关的日志角度看mapreduce的执行过程，以便于在通过日志分析定位分析问题先简单说一下mapreduce的执行过程，如下图：1、应用程序客户端client准备作业(数据split划分，作业配置等)，并上传值HDFS中；并提交作业至JobTracker。2、JobTracker根据job的配置信息(jobconf，spli

UDF永久生效现在是只能修改源代码.不过可以变通一下处理也可以实现.在HIVE_HOME的bin目录下新建一个.hiverc的文件,把写好的udf的注册语句写在这里就可以类似HIVE内置的用法一样用原理是，在运行./hive命令时，同时会加载HIVE_HOME/bin/.hiverc and $HOME/.hiverc作为初始化所需要的文件 在.hiverc文件中加入以下内容：ad

distribute by：控制着在map端如何分区，按照什么字段进行分区，要注意均衡sort by：每个reduce按照sort by 字段进行排序，reduce的数量按照默认的数量来进行，当然可以指定。               最终可以进行归并排序得出结果。                适用于数据量比较大的排序场景。order by：reduce只有一个，在一个reduc

目前业界大概这么几个开源的分布式日志系统，notify+rsync，Facebook 的Scribe，apache的chukwa，linkin的kafa和cloudera的flume。对这几款开源分布式日志系统的比较，参见这篇文章，讲的比较细致http://dongxicheng.org/search-engine/log-systems/之所以自己设计一台这么一个平台，而没有采用开源

HDFS文件系统调优  1、系统角度              存储方式，NameNode采用raid1+0，DataNode采用磁盘组JBOD方式               在顺序读文件的场景中，比如mapreduce，可以调整文件系统预读缓存的大小。               文件挂载设置noaptime、nodiratime，提升文件系统的性能2、hdfs的参数优化

一、NameNode数据结构1、物理结构${dfs.name.dir}/current/{VERSION,edits,fsimage,fstime}dfs.name.dir是一个目录列表，存储每个目录的镜像。VERSION文件是Java属性文件,包含运行HDFS的版本信息。edits，是编辑日志文件。当客户断执行写操作的时，NameNode首先会在编辑日志中写下记录，并在内存中保存

hadoop最初主要是针对流式文件的,每个文件在NameNode中都会保存一份文件元数据，并且运行过程中，元数据都是加载到内存中的，有namenode内存的限制;其次mapreduce的时候，每个小文件占用一个slot，调度方面的开销比较大。hadoop自带了三种方案：hadoop archive，SequenceFile，CombineFileInputFormata、 hadoop a

Hadoop中常用的压缩算法有bzip2、gzip、lzo、snappy，其中lzo、snappy需要操作系统安装native库才可以支持下面这张表，是比较官方一点的统计，不同的场合用不同的压缩算法。bzip2和GZIP是比较消耗CPU的，压缩比最高，GZIP不能被分块并行的处理；Snappy和LZO差不多，稍微胜出一点，cpu消耗的比GZIP少。通常情况下，想在CPU和IO之间取得平衡的

hadoop中可以对文件进行压缩，可以采用gzip、lzo、snappy等压缩算法。对于lzo压缩，常用的有LzoCodec和lzopCodec，可以对sequenceFile和TextFile进行压缩，但是有一点，对TextFile压缩后，mapred对压缩后的文件默认是不能够进行split操作，需要对该lzo压缩文件进行index操作，生成lzo.index文件，map操作才可以进行spl

Flume的架构基本agent-->collect-->storage的架构，agent主要负责日志的产生，并把日志传给collector端，collect负责把agent发送的日志收集起来，发送给storage存储，storage负责的存储；其中agent和collect本身都是source,sink架构，所谓source、sink，类似生成者和消费者的架构，他们之间通过queue传输，解耦。

在用FlumeNG1.3.1 Tail 一个文件收集日志到HDFS中时，发现原始日志文件最后几行数据总是不能写入到HDFS文件中，即使HDFS按照大小或者时间rollling成了一个新的文件。   HDFS在回滚一个新的文件中时，保留在HDFSEventSink中的数据（即使未达到一个包的大小）会写入到HDFS中，在HDFS的.hadoop fs -cat命令可以看到该数据。   经过分析

最近在MapReduce的逻辑运算测试的时，发现单个节点的CPU的IO wait值比较高，CPU大量的消耗在等待IO操作上。单个节点的运算的数据量比较大，每秒的IO吞吐量将近200M，iotop监控了一下主要是消耗在tasktacker从datanode节点读取数据上。从以下几个角度上对这个问题进行优化。1、源数据压缩存储2、dfs.data.dir分多个目录存储3、io.fi

最近在测试过程中，发现在做map reduce数据分析的过程中，cpu sys部分会偶然的升到，甚至到达50%，抖动的比较厉害。节点的磁盘的IO吞吐量比较大，每秒达到150M，大部分是tasktracker读取本地节点DFS的数据，默认情况下，读取数据是系统调用每次从硬盘上读取4K大小的数据到内核空间中，后由内核copy到应用程序空间，是什么导致内核部分消耗大部分的时间。经过大量的各方面的

前段时间有组员对mapreduce输出关系型数据库进行了验证，发现不支持输出到oracle中，但是对mysql支持的没有问题，用的版本是hadoop 1.0.4。经过调试，发现对oracle的支持在生成查询语句的语法时有个小的问题，语法不正确。需要修改DBOutputFormat中的constructQuery方法 query.append(");");//去掉其中的; ==>quer

为了保证可用性，传统的关系型数据库(mysql)通常采用一主多备的方式，当主宕机后，切换到备机。有多种方式可以做到主备自动失效检测切换，比如传统的HA软件heartbeat，keepalived等等，采取虚拟IP的方式对客户端透明；这里主备自动切换方案没有采取VIP的方式，而是用zookeeper对数据库集群进行管理，可以做到主备失效检测切换，主库的选举，比如考虑到mysql对多核利用

原有的spooling source的方式只支持一级目录的文件变动的检测，修改了一下源码支持对目录的递归检测，可以支持多级目录下的文件变动SpoolingFileLineReader类增加以下下方法 /**  * add by yangbutao  *   * @param files  * @param dir  * @param filter  */ pri

最近在测试环境下，把NameNode节点更换了一台机器，并增加了一些数据节点。在FlumeNG往hadoop集群写数据的过程中，有些节点报以下类似的错误2013-04-24 13:25:50,180 INFO org.apache.hadoop.hdfs.server.datanode.DataNode: PacketResponder 0 for block blk_7250572864

zookeeper watch机制的原理分析

客户端ClientWatchManager，管理由ClientXncn产生的watchers和handle events在zookeeper的exists、getChildren、getData等这些API中可以注册watcher对象到ClientWatchManager中，create、setData、delete等这些引起zookeeper节点变化的API会触发watcher proc

解决方案依然很简单，需要加锁的进程先尝试在zookeeper上创建一个临时节点L，如果创建成功则加锁成功，如果不成功（已存在）则在该节点上设置watch。进程通过删除L来解锁（当进程意外终止，L也会被删除，不会造成死锁），当L被删除时，其它等待锁的进程会得到通知，此时这些进程再次创建L来获得锁。上面的方案，当竞争锁的进程比较多时，解锁时会引起Herd Effect，可对加锁规则进行限制，如按进

阅读了下YARN的源码，架构中设计模式除了服务生命周期管理模式外，还包括事件驱动和状态机模式。生命周期管理模式在容器设计时候比较常见，包括资源模型的加载，卸载等等，比如tomcat、jboss等开源产品。这里重点讲一下事件驱动和状态机模式的使用。从提交任务到任务处理完成，YARN架构中整个任务的处理过程的设计都是事件驱动和状态机器的模式。对于事件驱动模式，对象包括事件类型EventTy

Hbase的优化总结 上面这张图不是一太清晰，我后面给个单独的连接 这里的HBase的优化主要从三个大的维度来进行分析1、系统硬件       采用普通的PC Server即可，Master要求高一点(比如8 CPU，48G内存，SAS raid)，Regionserver(如8CPU，24G内存，1T*12 SATA JBOD)      对于存储regionserver

利用Hbase的客户端进行Get或者scan操作时，在regionserver端用netstat -anp|grep 60020时，发现每一个Hbase客户端只有一个和该regionserver的连接，无论hbase client是否开启了多个线程进行并发操作。 后来翻了一下源码，果然是这样的。参见下面的源码截图，对同一个目的地的RegionServer来说，connection只有一

最近在使用HBase0.94版本的时，偶尔会出现，HRegionInfo was null or empty in Meta 的警告java.io.IOException: HRegionInfo was null or empty in Meta for writetest, row=lot_let,9399239430349923234234,99999999999999at org.

以前给研发做的HBase培训的ppt，分享给大家http://download.youkuaiyun.com/download/yangbutao/5206137 从以下角度对HBase进行了分析关系型数据库的在解决海量数据方面的解决方案和缺陷互联网业务的需求Nosql的提出，CAPHBase使用业务场景HBase的特性1)基于列式的高效存储2)强一致的数据访问3)

最近研究了下新一代的mapreduce框架YARN，这里先对YARN框架的引入和架构做个介绍，后续针对每一块做深入分析从Hadoop0.23版本开始对于mapduce计算框架，就完全是新的架构了(YARN)。老的版本MRv1 Jobtracker中存在单点，功能比较多的问题，负责资源管理调度和job的生命周期管理(task调度，跟踪task过程状态，task处理容错)，这样当大量的任务需要处理