您现在的位置：首页
--> 量子数科院
在使用df、du命令时，常常会遇到统计的硬盘使用情况不一致的问题。比如du统计根目录下文件总共大小为2G，而df判断挂载在根目录的硬盘已用空间达到了3G，20G甚至更多。发生这种情况，有以下三种原因。。。
针对HBase在单column family单column qualifier和单column family多column qualifier两种场景下，分别批量Put写入时的性能对比情况，下面是结合HBase的源码来简单分析解释这一现象。
Storm是一个分布式的流处理系统，利用anchor和ack机制保证所有tuple都被成功处理。如果tuple出错，则可以被重传，但是如何保证出错的tuple只被处理一次呢？Storm提供了一套事务性组件Transaction Topology，用来解决这个问题。
Transactional Topology目前已经不再维护，由Trident来实现事务性topology，但是原理相同。
本章介绍了storm集群如何实现数据的可靠处理。借助于创新性的tuple tree跟踪技术，storm高效的通过数据的应答机制来保证数据不丢失。storm集群中除nimbus外，没有单点存在，任何节点都可以出故障而保证数据不会丢失。imbus被设计为无状态的，只要可以及时重启，就不会影响正在运行的任务。
本文以Twitter Storm官方Wiki为基础，详细描述如何快速搭建一个Storm集群，其中，项目实践中遇到的问题及经验总结，在相应章节以“注意事项”的形式给出。
本章从storm的基本对象的定义，到广泛的介绍了storm的开发环境，从一个简单的例子讲解了topology的构建和定义。希望大家可以从本章的内容对storm有一个基本的理解和概念，并且已经可以构建一个简单的topology！！
Storm是一个开源的分布式实时计算系统，可以简单、可靠的处理大量的数据流。Storm有很多使用场景：如实时分析，在线机器学习，持续计算，分布式RPC，ETL等等。Storm支持水平扩展，具有高容错性，保证每个消息都会得到处理，而且处理速度很快(在一个小集群中，每个结点每秒可以处理数以百万计的消息)。Storm的部署和运维都很便捷，而且更为重要的是可以使用任意编程语言来开发应用。
HBase 0.92版本之后，Region Server的Compact过程根据待合并的文件大小分为small compaction和large compaction两种，由此可能导致在集群写入量大的时候Compact占用过多的网络出口带宽。本文将详细描述集群使用过程中遇到这一问题的排查过程及其解决方法。
简介: 1.理解linux系统上进程的原理以及实现 2. 信号处理简述 3. 了解内存管理初步知识 4. 打开通向linux内核的大门。
• 数据开发技术概述
简介： 本节课是数据开发技术的入门课程，结合大淘宝数据平台数据平台及开发技术的演进过程，详细讲解目前在用的主要数据开发技术，并且为大家呈现出目前主要的数据开发技术框架图，最后在未来超海量数据的大背景下，数据同学应该主动结合系统痛点进行技术应用 。
• 了解前端内存泄露
简介: 了解前端内存泄露原理，最常见的“循环引用”导致的内存泄露原因解析，以及业务项目中存在的内存泄露现象解析。
这里结合对HBase Thrift接口（HBase版本为0.92.1）的使用经验，总结其中遇到的一些问题及其相关注意事项。 字节的存放顺序 HBase中，由于row（row key和column family、column qualifier、time stamp）是按照字典序进行排序的，因此，对于short、int、long等类型的数据，通过Bytes.toBytes(…)转换成byte数组后，必须按照大端模式（高字节在低地址，低字节在高地址）存放。对于value，也是同样的道理。因此，在使用Thrift API（C++、Php、Python等）方式时，最好对于row和value都统一按照大端进行pack和unpack处理。
HBase集群在读写过程中，可能由于Region Split或Region Blance等导致Region的短暂下线，此时客户端与HBase集群进行RPC操作时会抛出NotServingRegionException异常，从而导致读写操作失败。这里根据实际项目经验，详细描述这一问题的发现及排查解决过程。 1. 发现问题 在对HBase集群进行压力测试过程中发现，当实际写入HBase和从HBase查询的量是平时的若干倍时（集群规模10~20台，每秒读写数据量在几十万条记录的量级），导致集群的读写出现一定程度的波动。
本文结合HBase 0.94.1版本源码，对HBase的Block Cache实现机制进行分析，总结学习其Cache设计的核心思想。 1. 概述 HBase上Regionserver的内存分为两个部分，一部分作为Memstore，主要用来写；另外一部分作为BlockCache，主要用于读。 写请求会先写入Memstore，Regionserver会给每个region提供一个Memstore，当Memstore满64MB以后，会启动 flush刷新到磁盘。当Memstore的总大小超过限制时（heapsize * hbase.regionserver.global.memstore.upperLimit * 0.9），会强行启动flush进程，从最大的Memstore开始flush直到低于限制。
HBase客户端API提供了Write Buffer的方式，即批量提交一批Put对象到HBase服务端。本文将结合HBase相关源码，对其进行深入介绍，分析如何在实际项目中合理设置和使用它。 什么时候需要Write Buffer？ 默认情况下，一次Put操作即要与Region Server执行一次RPC操作，其执行过程可以被拆分为以下三个部分： T1：RTT(Round-Trip Time)，即网络往返时延，它指从客户端发送数据开始，到客户端收到来自服务端的确认，总共经历的时延，不包括数据传输的时间； T2：数据传输时间，即Put所操作的数据在客户端与服务端之间传输所消耗的时间开销，当数据量大的时候，T2的开销不容忽略； T3：服务端处理时间，对于Put操作，即写入WAL日志（如果设置了WAL标识为true）、更新MemStore等。
网站数据统计分析工具是网站站长和运营人员经常使用的一种工具，比较常用的有谷歌分析、百度统计和腾讯分析等等。所有这些统计分析工具的第一步都是网站访问数据的收集。目前主流的数据收集方式基本都是基于javascript的。本文将简要分析这种数据收集的原理，并一步一步实际搭建一个实际的数据收集系统。 数据收集原理分析 简单来说，网站统计分析工具需要收集到用户浏览目标网站的行为（如打开某网页、点击某按钮、将商品加入购物车等）及行为附加数据（如某下单行为产生的订单金额等）。
脚本语言ymd ymd全称yamada script，是某一淘数据部员工业余时间完成的一个玩具脚本语言，其语法类似lua和javascript。代码托管在github 目前只支持Linux x86_64，预计未来会支持Windows/Mac OS。 yamada名称由来是动画《Working!!》角色：山田 葵（Yamada Aoi）
如何和“老板”沟通 我们是一线工程师的时候，和我们的直接技术管理者沟通是非常容易的。我们的技术架构、代码风格、系统扩展性、工程化全局考虑就是我们赢得信任和信赖的名片。但是随着我们的经验的日渐丰富、层级的提高，我们要面对更高层级的管理者的时候，沟通不是一件容易的事情，需要我们做更多的准备和精炼。 我们要获取资源，要获取执行方向的认同，我们必须建立和高层级管理者建立信任，给与他们持续并一致的事实称述。 只给事实 人不是机器，不是代码，我们有时候会不自觉的扭曲一些描述或者信息，让我自己看起来更能干或者让别人看起来不是那么好，有的时候甚至会在背后痛斥别人的不足。经过一次次的个人经历和重复犯上面的错误后，我知道了那样做是小人所为而已，古人说“君子之交淡如水”，从另外一个角度来解读，我认为君子间的认同和信赖，就是建立在相互沟通“事实“之上，而不是个人好恶。
再谈沟通的策略 什么叫做策略，我的认识就是做事情的方法，有些时候光有很好的原则，而没有好的方法也是不行的。比如淘宝的”十月围城“事件。 哪些策略是我们在进阶之路上需要注意的呢？第一条，也是我感受最深的一条： 说”Yes“而不是”No“ 我在做一名开发工程师的时候，尤其是处理需求的时候，我是经常被鼓励说”No“的。但是后来我慢慢发现，随着我越来越‘老’，我需要更多的说”Yes“了。因为当我是一个按图索骥进行开发的一线工程师时，我的擅自行动不加考虑的说”Yes“会让整体项目受到拖累，但是当我逐渐介入整体设计、架构设计和可行性分析的时候，我要做的事情更多是作为产品业务或者销售人员的咨询师，所以更多的情况是在深入分析需求后，站在尽可能覆盖需求的角度给出，尽可能合适的方案进行选择。 换句话说，我们的角色要求就是”找到一条可行的道路“。
谈谈沟通能力——沟通的准则 如果一名工程师要成长为资深专家或者是架构师或者是技术管理者，沟通是必不可少的技能和工作的工具。 对于资深专家或者架构师，对沟通能力的要求甚至大于技术管理者，因为他们没有行政权力，但是却往往需要主导、指导、控制跨小组、跨团队乃至跨公司的项目，怎么能够把各个组织里面的人有效的驱动起来，沟通能力非常重要。 但是我们工程师在成长过程中，往往不注意或者没有收到这方面的训练，当他技而优则”升“成为专家的时候，问题就来了，尤其是他作为团队中坚，既要和一线工程师交流又要向老板汇报，真的是压力山大啊！ 沟通方式和技巧往往是因人而异的，但是我们还是可以总结出一些基本准则供大家参考。 先说一下沟通的准则： 先听后说 古罗马哲学家Epictetus曾经说过很有意思的一句话，人之所以要少说多听，是因为我们只有一个嘴巴但有两个耳朵。
近3天十大热文
-
[67] Go Reflect 性能 -
[67] Oracle MTS模式下 进程地址与会话信
-
[67] 如何拿下简短的域名
-
[61] IOS安全–浅谈关于IOS加固的几种方法
-
[60] 图书馆的世界纪录
-
[59] 【社会化设计】自我（self）部分――欢迎区
-
[58] android 开发入门
-
[56] 视觉调整－设计师 vs. 逻辑
-
[49] 给自己的字体课（一）——英文字体基础
-
[47] 界面设计速成
赞助商广告
