Linux，du、df统计的硬盘使用情况不一致问题在运维Linux服务器时，会碰到需要查看硬盘空间的情况，这时候，通常会使用df -lh命令来检查每个挂载了文件系统的硬盘的总量和已使用量，或者，可以使用du -sh [directory]命令来统计某个目录下所有文件的空间占用。在使用df、du命令时，常常会遇到统计的硬盘使用情况不一致的问题。比如du统计根目录下文件总共大小为2G，而df判断挂载在根目录的硬盘已用空间达到了3G，20G甚至更多。发生这种情况，有以下三种原因：1.预留空间为了预防紧急情况，linux ext文件系统会预留部分硬盘空间，具体预留的数值可以通过tune2fs -l [dev_name] | grep “Reserved block count”查看到（dev_name是设备名），这里预留的空间会被df计算到已用空间中，从而导致df和du统计不一致。如果需要调整预留空间大小，我们可以使用tune2fs -m [size] [dev_name]来进行调整。2.幻影文件(phantom file)du是统计被文件系统记录到的每个文件的大小，然后进行累加得到的大小，这是通过文件系统获取到的。而df主要是从超级块（superblock）中读入硬盘使用信息，df获取到的是磁盘块被使用的情况。当一个文件被删除时，如果有别的进程正在使用它（占有句柄 ...继续阅读 (23)

DRPC是建立在Storm基本概念（Topology、Spout、Bolt、Stream等）之上的高层抽象，个人理解它的目标是在Storm 集群之上提供一种分布式的RPC框架，以便能够利用Storm快速的实现RPC请求的分布式计算过程，即发起一次RPC请求，多个worker计算节点参 与计算，最后汇总后将计算结果返回给客户端。DRPC实现框架Storm中使用Thrift作为其RPC框架，同样地，DRPC的实现也是构建在Thrift协议之上，相关的源码文件如下：1. storm-core/src/storm.thrift，定义了Storm中实现的Thrift协议，其中有两个service是与DRPC相关的：DistributedRPC和DistributedRPCInvocations，它们的接口定义如下：DistributedRPC.Iface：定义了execute方法，用于客户端发起RPC请求；DistributedRPCInvocations.Iface：定义了fetchRequest、failRequest、result方法，分别用于获取RPC请求、将RPC请求标记为失败、返回RPC请求的处理结果。2. storm-core/src/clj/backtype/storm/daemon/drpc.clj，实现了DRPC的Thrift服务端（即DRPC Server），使用Clo ...继续阅读 (17)

针对HBase在单column family单column qualifier和单column family多column qualifier两种场景下，分别批量Put写入时的性能对比情况，下面是结合HBase的源码来简单分析解释这一现象。1. 测试结果在客户端批量写入时，单列族单列模式和单列族多列模式的TPS和RPC次数相差很大，以客户端10个线程，开启WAL的两种模式下的测试数据为例，单列族单列模式下，TPS能够达到12403.87，实际RPC次数为53次；单列族多列模式下，TPS只有1730.68，实际RPC次数为478次。二者TPS相差约7倍，RPC次数相差约9倍。详细的测试环境这里不再罗列，我们这里关心的只是在两种条件下的性能差别情况。2. 粗略分析下面我们先从HBase存储原理层面“粗略”分析下为什么出现这个现象：HBase 的KeyValue类中自带的字段占用大小约为50~60 bytes左右（参考HBase源码org/apache/hadoop/hbase/KeyValue.java），那么客户端Put一行数据时（53 个字段，row key为64 bytes，value为751 bytes）：1）  开WAL，单column family单column qualifier，批量Put：(50~60) + 64 + 751 = 865~875 bytes；2）  开 ...继续阅读 (28)

以下是我们对HBase集群一次慢查询请求问题的排查解决过程。1. 发现问题项目中有一张HBase表，每天凌晨以后会集中批量导入一批数据，导入数据量很大，在千万到亿的量级，然后白天为用户提供查询服务。某天突然发现， 该表按照各个region（共计256个）分别仅顺序scan少数几条数据时，部分region的查询请求的响应时间很慢，长达10秒甚至几十秒不等。2. 排查问题首先，通过查看HBase的region server监控界面，看到这张表的每个region下面只有1~3个StoreFile，排除了由于StoreFile过多导致查询响应慢的情况。接着排查，发现这张表的TTL只有5天，因此到一定程度后会有大量过期数据存在。同时，由于这张表每天早上会导入一批数据（其中，发现问题的5天前那天曾集中导入了7亿多条记录），而集群的major compact周期配置是7天，虽然到当天时这部分数据已经过期了，但是由于还没有经过major compact触发清除所有过期的数据，因此，这个时间窗口内存在大量过期但尚未被清除的数据，导致即使按照各个region分别仅scan少数几条数据，仍需要过滤掉一大批过期的数据（从监控看到当时的Block Cache访问量比平时要高了一倍左右，如下图所示），才能扫到实际有用的数据，所以查询响应时间很慢。3. 解决问题针对这一问题，有以下两种解决方法：1）每天早上导入 ...继续阅读 (16)

没赶上20年前关系型数据库系统的狂潮，不要紧！没赶上8年前分布式数据处理系统的突飞猛进，不要紧！但是现在摆在大家面前的大数据应用浪潮，你不珍惜，那就太可惜了！未来是你们的，也是我们的，但终究是大数据的！如果你精通海量数据处理技术or精通数据可视化技术or精通数据挖掘及算法技术or网站和前端开发牛人，对业务及数据敏感，那么请加入淘宝商家数据部吧！我们的项目神秘、性感而且充满挑战，和我们一起在AWS+Big Data平台的建设中找寻自己的梦想吧！If not now, when?!  If not you, who?!  此时此刻，非你莫属！您可以发送简历到adjob@taobao.com，邮件标题“姓名”+应聘+“职位名称”即可。———————————————–产品相关职位—————————————-部门最新开放“产品经理”、“运营专员”相关职位阿里巴巴集团最强的能力之一是商家端的能力，阿里巴巴集团未来十年战略是“数据分享第一平台”。如果你有 ...继续阅读 (12)

第五章 一致性事务Storm是一个分布式的流处理系统，利用anchor和ack机制保证所有tuple都被成功处理。如果tuple出错，则可以被重传，但是如何保证出错的tuple只被处理一次呢？Storm提供了一套事务性组件Transaction Topology，用来解决这个问题。Transactional Topology目前已经不再维护，由Trident来实现事务性topology，但是原理相同。5.1一致性事务的设计Storm如何实现即对tuple并行处理，又保证事务性。本节从简单的事务性实现方法入手，逐步引出Transactional Topology的原理。5.1.1 简单设计一：强顺序流保证tuple只被处理一次，最简单的方法就是将tuple流变成强顺序的，并且每次只处理一个tuple。从1开始，给每个tuple都顺序加上一个id。在处理tuple的时候，将处理成功的tuple id和计算结果存在数据库中。下一个tuple到来的时候，将其id与数据库中的id做比较。如果相同，则说明这个tuple已经被成功处理过了，忽略它；如果不同，根据强顺序性，说明这个tuple没有被处理过，将它的id及计算结果更新到数据库中。以统计消息总数为例。每来一个tuple，如果数据库中存储的id 与当前tuple id不同，则数据库中的消息总数加1，同时更新数据库中的当前tuple id值。 ...继续阅读 (13)

4.1 简介storm可以确保spout发送出来的每个消息都会被完整的处理。本章将会描述storm体系是如何达到这个目标的，并将会详述开发者应该如何使用storm的这些机制来实现数据的可靠处理。4.2 理解消息被完整处理一个消息(tuple)从spout发送出来，可能会导致成百上千的消息基于此消息被创建。我们来思考一下流式的“单词统计”的例子：storm任务从数据源（Kestrel queue）每次读取一个完整的英文句子；将这个句子分解为独立的单词，最后，实时的输出每个单词以及它出现过的次数。本例中，每个从spout发送出来的消息（每个英文句子）都会触发很多的消息被创建，那些从句子中分隔出来的单词就是被创建出来的新消息。这些消息构成一个树状结构，我们称之为“tuple tree”，看起来如图1所示：图1 示例tuple tree在什么条件下，Storm才会认为一个从spout发送出来的消息被完整处理呢？答案就是下面的条件同时被满足：tuple tree不再生长树中的任何消息被标识为“已处理”如果在指定的时间内，一个消息衍生出来的tuple tree未被完全处理成功，则认为此消息未被完整处理。这个超时值可以通过任务级参数Config.TOPOLOGY_MESSAGE_TIMEOUT_SECS进行配置，默认超时值为30秒。4.3 消息的生命周期如果消息被完整处理或者未被完整处理，Sto ...继续阅读 (21)

本文以Twitter Storm官方Wiki为基础，详细描述如何快速搭建一个Storm集群，其中，项目实践中遇到的问题及经验总结，在相应章节以“注意事项”的形式给出。3.1 Storm集群组件Storm集群中包含两类节点：主控节点（Master Node）和工作节点（Work Node）。其分别对应的角色如下：1. 主控节点（Master Node）上运行一个被称为Nimbus的后台程序，它负责在Storm集群内分发代码，分配任务给工作机器，并且负责监控集群运行状态。Nimbus的作用类似于Hadoop中JobTracker的角色。2. 每个工作节点（Work Node）上运行一个被称为Supervisor的后台程序。Supervisor负责监听从Nimbus分配给它执行的任务，据此启动或停止执行任务的工作进程。每一个工作进程执行一个Topology的子集；一个运行中的Topology由分布在不同工作节点上的多个工作进程组成。Storm集群组件Nimbus和Supervisor节点之间所有的协调工作是通过Zookeeper集群来实现的。此外，Nimbus和Supervisor进程都是快速失败（fail-fast)和无状态（stateless）的；Storm集群所有的状态要么在Zookeeper集群中，要么存储在本地磁盘上。这意味着你可以用kill -9来杀死Nimbus和Super ...继续阅读 (15)

2.1 Storm基本概念在运行一个Storm任务之前，需要了解一些概念：TopologiesStreamsSpoutsBoltsStream groupingsReliabilityTasksWorkersConfigurationStorm集群和Hadoop集群表面上看很类似。但是Hadoop上运行的是MapReduce jobs，而在Storm上运行的是拓扑（topology），这两者之间是非常不一样的。一个关键的区别是： 一个MapReduce job最终会结束， 而一个topology永远会运行（除非你手动kill掉）。在Storm的集群里面有两种节点： 控制节点（master node）和工作节点（worker node）。控制节点上面运行一个叫Nimbus后台程序，它的作用类似Hadoop里面的JobTracker。Nimbus负责在集群里面分发代码，分配计算任务给机器， 并且监控状态。每一个工作节点上面运行一个叫做Supervisor的节点。Supervisor会监听分配给它那台机器的工作，根据需要启动/关闭工作进程。每一个工作进程执行一个topology的一个子集；一个运行的topology由运行在很多机器上的很多工作进程组成。Nimbus和Supervisor之间的所有协调工作都是通过Zookeeper集群完成。另外，Nimbus进程和Supervisor进程都 ...继续阅读 (21)

1.1   实时流计算互联网从诞生的第一时间起，对世界的最大的改变就是让信息能够实时交互，从而大大加速了各个环节的效率。正因为大家对信息实时响应、实时交互的需求，软件行业除了个人操作系统之外，数据库（更精确的说是关系型数据库）应该是软件行业发展最快、收益最为丰厚的产品了。记得十年前，很多银行别说实时转账，连实时查询都做不到，但是数据库和高速网络改变了这个情况。随着互联网的更进一步发展，从Portal信息浏览型到Search信息搜索型到SNS关系交互传递型，以及电子商务、互联网旅游生活产品等将生活中的流通环节在线化。对效率的要求让大家对于实时性的要求进一步提升，而信息的交互和沟通正在从点对点往信息链甚至信息网的方向发展，这样必然带来数据在各个维度的交叉关联，数据爆炸已不可避免。因此流式处理加NoSQL产品应运而生，分别解决实时框架和数据大规模存储计算的问题。早在7、8年前诸如UC伯克利、斯坦福等大学就开始了对流式数据处理的研究，但是由于更多的关注于金融行业的业务场景或者互联网流量监控的业务场景，以及当时互联网数据场景的限制，造成了研究多是基于对传统数据库处理的流式化，对流式框架本身的研究偏少。目前这样的研究逐渐没有了声音，工业界更多的精力转向了实时数据库。2010年Yahoo！对S4的开源，2011年twitter对Storm的开源，改变了这个情况。以前互联网的开发人员在做一个实时应 ...继续阅读 (19)