2017年03月_0x12A2A7F

转载 spark数据倾斜调优(二)

调优概述有的时候，我们可能会遇到大数据计算中一个最棘手的问题——数据倾斜，此时Spark作业的性能会比期望差很多。数据倾斜调优，就是使用各种技术方案解决不同类型的数据倾斜问题，以保证Spark作业的性能。数据倾斜发生时的现象绝大多数task执行得都非常快，但个别task执行极慢。比如，总共有1000个task，997个task都在1分钟之内执行完了，但是剩余两三个task却要一两个小时。这种...

2017-03-09 20:39:47 1460

转载 MongoDB的正确使用姿势

MongoDB是一个非常有前途的数据库，MongoDB官方对自己的定位是通用数据库，其实这个定位跟MySQL有些像。虽其流行度还远未达到MySQL的水平，但笔者有个可能不恰当的比较，MongoDB就像N年前的MySQL，随着时间的推移，会变得越来越强大，也会越来越流行。下面结合MongoDB的几大特色来谈谈MongoDB的适用场景。首先，MongoDB是文档型（Document store

2017-03-07 23:42:42 719

转载 HBase Compaction（2）

上一篇文章主要基于工作流程对compaction进行了介绍，同时说明了compaction的核心作用是通过合并大量小文件为一个大文件来减少hfile的总数量，进而保证读延迟的稳定。合并文件首先是读出所有小文件的KVs，再写入同一个大文件，这个过程会带来严重的IO压力和带宽压力，对整个系统的读请求和写请求带来不同程度的影响。因此HBase对于compaction的设计总是会追求一个平衡点，一

2017-03-07 23:33:34 870

转载 HBase Compaction（1）

了解HBase的童鞋都知道，HBase是一种Log-Structured Merge Tree架构模式，用户数据写入先写WAL，再写缓存，满足一定条件后缓存数据会执行flush操作真正落盘，形成一个数据文件HFile。随着数据写入不断增多，flush次数也会不断增多，进而HFile数据文件就会越来越多。然而，太多数据文件会导致数据查询IO次数增多，因此HBase尝试着不断对这些文件进行合并，这个合

2017-03-07 23:27:59 630

转载 HBase集群规划

HBase自身具有极好的扩展性，也因此，构建扩展集群是它的天生强项之一。在实际线上应用中很多业务都运行在一个集群上，业务之间共享集群硬件、软件资源。那问题来了，一个集群上面到底应该运行哪些业务可以最大程度上利用系统的软硬件资源？另外，对于一个给定业务来说，应该如何规划集群的硬件容量才能使得资源不浪费？最后，一个给定的RegionServer上到底部署多少Region比较合适？想必这些问题都曾经困惑

2017-03-07 23:24:55 944

转载 HBase的RIT

相信长时间运维HBase集群的童鞋肯定都会对RIT（Region-In-Transition，很多参考资料误解为Region-In-Transaction，需要注意）有一种咬牙切齿的痛恨感，一旦Region处于长时间的RIT就会有些不知所措，至少以前的我就是这样过来的。正所谓“恐惧来源于未知”，不知所措意味着我们对RIT知之甚少，然而“凡事都有因果，万事皆有源头”，处于RIT状态的Region只是

2017-03-07 21:24:37 2299

转载 HBase－CMS GC调优

HBase发展到当下，对其进行的各种优化从未停止，而GC优化更是其中的重中之重。从0.94版本提出MemStoreLAB策略、Memstore Chuck Pool策略对写缓存Memstore进行优化开始，到0.96版本提出BucketCache以及堆外内存方案对读缓存BlockCache进行优化，再到后续2.0版本宣称会引入更多堆外内存，可见HBase会将堆外内存的使用作为优化GC的一个战略方向

2017-03-07 21:11:51 509

转载 HBase多租户机制简析

背景介绍在HBase1.1.0发布之前，HBase同一集群上的用户、表都是平等的，没有优劣之分。这种’大同’社会看起来完美，实际上有很多问题。最棘手的主要有这么两个，其一是某些业务较其他业务重要，需要在资源有限的情况下优先保证核心重要业务的正常运行，其二是有些业务在某些场景下会时常’抽风’，QPS常常居高不下，严重消耗系统资源，导致其他业务无法正常运转。这实际上是典型的多租户问题，社区针对

2017-03-07 21:02:56 1999

转载 HBaseRegionServer宕机数据恢复

HBase采用类LSM的架构体系，数据写入并没有直接写入数据文件，而是会先写入缓存（Memstore），在满足一定条件下缓存数据再会异步刷新到硬盘。为了防止数据写入缓存之后不会因为RegionServer进程发生异常导致数据丢失，在写入缓存之前会首先将数据顺序写入HLog中。如果不幸一旦发生RegionServer宕机或者其他异常，这种设计可以从HLog中进行日志回放进行数据补救，保证数据不丢失。

2017-03-07 20:53:18 3274 2

转载 HBase读性能优化策略

任何系统都会有各种各样的问题，有些是系统本身设计问题，有些却是使用姿势问题。HBase也一样，在真实生产线上大家或多或少都会遇到很多问题，有些是HBase还需要完善的，有些是我们确实对它了解太少。总结起来，大家遇到的主要问题无非是Full GC异常导致宕机问题、RIT问题、写吞吐量太低以及读延迟较大。Full GC问题之前在一些文章里面已经讲过它的来龙去脉，主要的解决方案目前主要有两方

2017-03-07 20:45:49 1136

转载 HBase写性能优化策略

上一篇文章主要介绍了HBase读性能优化的基本套路，本篇文章来说道说道如何诊断HBase写数据的异常问题以及优化写性能。和读相比，HBase写数据流程倒是显得很简单：数据先顺序写入HLog，再写入对应的缓存Memstore，当Memstore中数据大小达到一定阈值（128M）之后，系统会异步将Memstore中数据flush到HDFS形成小文件。HBase数据写入通常会遇到两类问题，一类是

2017-03-07 20:42:05 876

转载 HBase数据读取流程解析

和写流程相比，HBase读数据是一个更加复杂的操作流程，这主要基于两个方面的原因：其一是因为整个HBase存储引擎基于LSM-Like树实现，因此一次范围查询可能会涉及多个分片、多块缓存甚至多个数据存储文件；其二是因为HBase中更新操作以及删除操作实现都很简单，更新操作并没有更新原有数据，而是使用时间戳属性实现了多版本。删除操作也并没有真正删除原有数据，只是插入了一条打上”deleted”标签的

2017-03-07 20:35:27 10274 1

LW_ICE