HBase系列之compact

在介绍HBase Compaction之前,我们先来看一下HBase是如何存储和操作数据。
HBase数据存储

如上图所示,HRegionServer负责打开region,并创建对应的HRegion实例。当HRegion打开之后,它会为每个表的HColumnFamily创建一Store实例,ColumnFamily是用户在创建表时定义好的,ColumnFamily在每个region中和Store实例一一对应。每个Store实例包含一个或者多个StoreFile实例,StoreFile是对实际存储数据文件HFile的轻量级封装。每个Store对应一个MemStore(也就是写内存)。一个HRegionServer共享一个HLog实例。

当我们不停地往HBase中写入数据,也就是往MemStore写入数据,HBase会检查MemStore是否达到了需要刷写到磁盘的阈值(更多关于MemStore刷写的信息,可以参考HBase Reference Guide关于MemStore的介绍)。如果达到刷写的条件,MemStore中的记录就会被刷写到磁盘,形成一个新的StoreFile。可想而知,随着MemStore的不断刷写,会形成越来越多的磁盘文件。然而,对于HBase来说,当每个HStore仅包含一个文件时,才会达到最佳的读效率。因此HBase会通过合并已有的HFile来减少每次读数据的磁盘寻道时间,从而提高读速度,这个文件合并过程就称为Compaction。在这里需要说明的是,显然磁盘IO也是有代价的,如果使用不慎的话,不停地重写数据可能会导致网络和磁盘过载。换句话说,compaction其实就是用当前更高的磁盘IO来换取将来更低的磁盘寻道时间。因此,何时执行compaction,其实是一个相当复杂的决策。

Compaction会从一个region的一个store中选择一些hfile文件进行合并。合并说来原理很简单,先从这些待合并的数据文件中读出KeyValues,再按照由小到大排列后写入一个新的文件中。之后,这个新生成的文件就会取代之前待合并的所有文件对外提供服务。HBase的compaction分为minor和major两种,每次触发compact检查,系统会自动决定执行哪一种compaction(合并)。有三种情况会触发compact检查:

  • MemStore被刷写到磁盘;
  • 用户执行shell命令compact、major_compact或者调用了相应的API;
  • HBase后台线程周期性触发检查。

除非是用户使用shell命令major_compact或者调用了majorCompact() API(这种情况会强制HBase执行major合并),在其他的触发情况下,HBase服务器会首先检查上次运行到现在是否达到一个指定的时限。如果没有达到这个时限,系统会选择执行minor合并,接着检查是否满足minor合并的条件。

major合并中会删除那些被标记为删除的数据、超过TTL(time-to-live)时限的数据,以及超过了版本数量限制的数据,将HStore中所有的HFile重写成一个HFile。如此多的工作量,理所当然地,major合并会耗费更多的资源,合并进行时也会影响HBase的响应时间。在HBase 0.96之前,默认每天对region做一次major compact,现在这个周期被改成了7天。然而,因为major compact可能导致某台server短时间内无法响应客户端的请求,如果无法容忍这种情况的话,可以关闭自动major compact,改成在请求低谷期手动触发这一操作。

Minor Compaction是指选取一些小的、相邻的StoreFile将他们合并成一个更大的StoreFile,在这个过程中不会处理已经Deleted或Expired的Cell。一次Minor Compaction的结果是更少并且更大的StoreFile。

Read more
Performance optimizations in Apache Impala

历史和动机

SQL on Apache Hadoop

  • SQL
  • Run on top of HDFS
  • Supported various file formats
  • Converted query operators to map-reduce jobs
  • Run at scale
  • Fault-tolerant
  • High startup-costs/materialization overhead (slow…)

impala performance optimizations

query planning

2-phase cost-based optimizer

  • Phase 1: Generate a single node plan (transformations, join ordering, static partition pruning, runtime filters)
  • Phase 2: Convert the single node plan into a distributed query execution plan (add exchange nodes, decide join strategy)
    Query fragments (units of work):
  • Parts of query execution tree
  • Each fragment is executed in one or more impalads
Read more
Google Spanner

原始译文厦门大学林子雨老师翻译,见Google Spanner (中文版)

简介

Spanner是谷歌公司研发的、可扩展的、多版本、全球分布式、同步复制数据库。它是第一个把数据分布在全球范围内的系统,并且支持外部一致性的分布式事务。本文描述了Spanner的架构、特性、不同设计决策的背后机理和一个新的时间API,这个API可以暴露时钟的不确定性。这个API及其实现,对于支持外部一致性和许多强大特性而言,是非常重要的,这些强大特性包括:非阻塞的读、不采用锁机制的只读事务、原子模式变更。

Spanner是个可扩展,多版本,全球分布式还支持同步复制的数据库。他是Google的第一个可以全球扩展并且支持外部一致的事务。Spanner能做到这些,离不开一个用GPS和原子钟实现的时间API。这个API能将数据中心之间的时间同步精确到10ms以内。因此有几个给力的功能:无锁读事务,原子schema修改,读历史数据无block。

功能

从高层看Spanner是通过Paxos状态机将分区好的数据分布在全球的。数据复制全球化的,用户可以指定数据复制的份数和存储的地点。Spanner可以在集群或者数据发生变化的时候将数据迁移到合适的地点,做负载均衡。

spanner提供一些有趣的特性:

  • 应用可以细粒度的指定数据分布的位置。精确的指定数据离用户有多远,可以有效的控制读延迟(读延迟取决于最近的拷贝)。指定数据拷贝之间有多远,可以控制写的延迟(写延迟取决于最远的拷贝)。还要数据的复制份数,可以控制数据的可靠性和读性能。(多写几份,可以抵御更大的事故)
  • Spanner还有两个一般分布式数据库不具备的特性:读写的外部一致性,基于时间戳的全局的读一致。这两个特性可以让Spanner支持一致的备份,一致的MapReduce,还有原子的Schema修改。

这些特性都得益于spanner有个全球时间同步机制,可以在数据提交的时候给出一个时间戳。因为时间是系列化的,所以才有外部一致性。这个很容易理解,如果有两个提交,一个在T1,一个在T2。那有更晚的时间戳那个提交是正确的。

与关系型数据库和nosql对比

https://www.infoq.cn/article/growth-path-of-spanner


八大基础分析模型

模型是指对于某个实际问题或客观事物、规律进行抽象后的一种形式化表达方式。任何模型都有三个部分组成:目标、变量和关系。
通俗来讲:

  • 目标:这个模型是干嘛用的,要解决什么问题。
  • 变量:自变量、因变量、中介变量,总之就是,明确变量,改变变量,即可直接呈现结果,实现目标。
  • 关系:可以理解为对目标和变量进行组织。
    下面介绍常用的八种基础分析模型,可能大家也都了解。而且这些模型,其实也在不断的优化,并且又有了一些新特性,比如用户分群模型中的“新增后”、事件模型中的“活跃比”

用户模型

“用户”是以人为中心的数据分析平台的最小单元,对单个用户画像构建越完整,数据多维交叉的分析能力才能凸显。

事件模型

用户在产品上的行为(所有代码的交互)都是会被记录的,怎样标记是事件模型的核心,它是漏斗模型,自定义留存模型,全行为路径分析模型的数据源。

活跃比:某一时间区间内触发某事件的人数占该时间区间内活跃人数的百分比。

漏斗分析模型

漏斗是常用也是最经典的分析模型,在行为数据的漏斗分析中,通常我们以每一步触发的人数为统计口径。漏斗中另一个重要的限定因素是:转化时间的限定。当设定转化时间是一天内,用户只要在一天内先后完成所有事件就是一个成功转化,未触发或是超过时间限定都不会记为一个成功转化。

热图分析模型

热图的目标是能更直观的分析用户在页面上的焦点,不需要定义事件,不需要去对比事件,直接在页面上通过颜色深浅还原用户的聚焦位置并形成对比。
过去:分析全量人群的热力表现。
现在:分析特定人群,群组之间进行对比。

自定义留存分析模型

留存被认为是比较高级的一个指标。无论用户在应用内做了什么,只要打开了应用就是一个留存用户,但不同产品对留存有不同的定义。比如,阅读类产品会把至少看过一篇文章的用户定义为有效留存用户,电商类产品会把至少看过一次“商品详情”的用户定义为有效留存用户,所以有了自定义留存。

粘性分析模型

计算一段时间内,以周,月为单位看用户不同的访问天数所占的百分比。

全行为路径分析模型

用户在产品中的行为其实是个黑盒子,全行为路径是用全局视野看用户的行为轨迹,很多时候你会有意想不到的收获,在可视化的过程中有两个模型,一个是树形图、一个是太阳图。

用户分群模型

用户分群其实是最常做的,但是如何把群组划分这一操作变得更便捷和高效,可以进一步优化了这一模型,也足以满足很多场景下的用户分群需求:

  • 维度:新增于、活跃于、触发过什么行为、用户属性满足什么条件;在基于行为事件筛选人群的时候有一个新的维度,叫:新增后。
  • 时间:绝对时间和相对时间
  • 关系:并且、或者

新增后: 计算用户触发某行为的时间和用户新增的时间,然后定义为“新增后”,比如,你可以快速找到新增后 1 天内就付款、新增后 30 天才付款的用户,背后其实是对用户价值的快速衡量;还可以基于此条件,不断去分群,比如用户完成一次购买是发生在新增后的 7 天,30 天,还是一个月,快速找到用户购买的决策周期。


传统的MapReduce框架慢在哪里

本文转载于传统的MapReduce框架慢在那里,翻译自Shark: SQL and Rich Analytics at Scale的论文第七章节,从理论上讨论了相比于Hive,Shark的优势在哪里,原文可见http://www.eecs.berkeley.edu/Pubs/TechRpts/2012/EECS-2012-214.pdf.

为什么之前的MapReduce系统比较慢

常理上有几个理由使得MapReduce框架慢于MPP数据库:

  • 容错所引入的昂贵数据实体化 (data materialization)开销。
  • 孱弱的数据布局 (data layout),比如缺少索引。
  • 执行策略的开销[1 2]

而我们对于Hive的实验也进一步证明了上述的理由,但是通过对Hive“工程上”的改进,如改变存储引擎(内存存储引擎)、改善执行架构(partial DAG execution)能够缩小此种差距。同时我们也发现一些MapReduce实现的细节会对性能有巨大的影响,如任务调度的开销,如果减小调度开销将极大地提高负载的均衡性。

中间结果输出:类似于Hive这样的基于MapReduce的查询引擎,往往会将中间结果实体化 (materialize)到磁盘上:

  • 在MapReduce任务内部,为了防止Reduce任务的失败,Map通常会把结果存储在磁盘上。
  • 通常一些查询在翻译到MapReduce任务的时候,往往会产生多个stage,而这些串联的stage则又依赖于底层文件系统(如HDFS)来存储每一个stage的输出结果。

对于第一种情况,Map的输出结果存储在磁盘上是为了确保能够有足够的空间来存储这些大数据批量任务的输出。而Map的输出并不会复制到不同的节点上去,因此如果执行Map任务的节点失效的话仍会造成数据丢失[3]。由此可以推出,如果将这部分输出数据缓存在内存中,而不是全部输出到磁盘上面也是合理的。Shark Shuffle的实现正是应用了此推论,将Map的输出结果存储在内存中,极大地提高Shuffle的吞吐量。通常对于聚合 (aggregation)和过滤之类的查询,它们的输出结果往往远小于输入,这种设计是非常合理的。而SSD的流行,也会极大地提高随机读取的性能,对于大数据量的Shuffle,能够获得较大的吞吐量,同时也拥有比内存更大的空间。

Read more
数据存储系统性能优化思维导图

当前计算机硬件的基本性能指标及其在数据库中主要操作内容,可以整理出如下图所示的性能基本优化法则:

这个优化法则归纳为5个层次:

1、 减少数据访问(减少磁盘访问)

2、 返回更少数据(减少网络传输或磁盘访问)

3、 减少交互次数(减少网络传输)

4、 减少服务器CPU开销(减少CPU及内存开销)

5、 利用更多资源(增加资源)

由于每一层优化法则都是解决其对应硬件的性能问题,所以带来的性能提升比例也不一样。传统数据库系统设计是也是尽可能对低速设备提供优化方法,因此针对低速设备问题的可优化手段也更多,优化成本也更低。我们任何一个SQL的性能优化都应该按这个规则由上到下来诊断问题并提出解决方案,而不应该首先想到的是增加资源解决问题。

Read more
OLAP引擎思维导图

联机分析处理(OLAP)

联机分析处理(英语:On-Line Analytical Processing,简称OLAP),是一套以多维度方式分析数据,而能弹性地提供上卷(Roll-up)、下钻(Drill-down)、和透视分析(pivot)等操作,呈现集成性决策信息的方法,多用于决策支持系统、商务智能或数据仓库。其主要的功能,在于方便大规模数据分析及统计计算,对决策提供参考和支持。
OLA数据库的设计目的是为了提高检索数据的速度。
OLAP数据库包含两种基本类型的数据:度量值和维度。前者是数值数据,表示您用于做出明智的商业决策的数量和平均值;后者是用于组织这些度量值的类别。OLAP 数据库可帮助您按照多个明细级别组织数据,从而可以使用您熟悉的相同类别来分析数据。

各类OLAP引擎

针对OLAP查询,出现了各类的引擎,主要以ROLAP与MOLAP为主,MOLAP将需要查询分析的维度数据预先计算好,来实现高速的查询要求。
下面例举常见的OLAP引擎以及优缺点,实现技术细节等。
OLAP引擎思维导图


bitmap与标签存储

最近在标签存储中,需要根据标签值查询用户id,所以想到在源数据表基础上建立索引。因为标签数据量大,且标签基数相对较少,查询条件往往涉及多标签组合过滤,所以选用了bitmap作为索引。

bitmap简介

bitmap就是以比特位来存储状态。
bitmap

bitmap索引

例如用户数据表

现在要在用户性别和婚姻状态建立bitmap索引。

通过索引值为1,我们可以看出性别男的用户rowid为1和3,然后在查询源用户表,就可以查出性别男的是张三,王五。婚姻状况同理。
下面我们如果要查询:
select * from table where Gender=’男’ and Marital=’未婚’
首先我们找到男索引列和未婚索引列,然后对其取并集。

Read more
磁盘I/O

最近一直在看HBase底层存储,想更深入的理解HBase采用LSM结构,而不是B-tree的缘由,所以需要更深入的理解磁盘存储。
本文转载于磁盘I/O那些事,该文详细讲解了磁盘结构,磁盘如何存储数据,如果读取数据,以及磁盘读写的IO过程。

背景

计算机硬件性能在过去十年间的发展普遍遵循摩尔定律,通用计算机的CPU主频早已超过3GHz,内存也进入了普及DDR4的时代。然而传统硬盘虽然在存储容量上增长迅速,但是在读写性能上并无明显提升,同时SSD硬盘价格高昂,不能在短时间内完全替代传统硬盘。传统磁盘的I/O读写速度成为了计算机系统性能提高的瓶颈,制约了计算机整体性能的发展。

硬盘性能的制约因素是什么?如何根据磁盘I/O特性来进行系统设计?针对这些问题,本文将介绍硬盘的物理结构和性能指标,以及操作系统针对磁盘性能所做的优化,最后讨论下基于磁盘I/O特性设计的技巧。

硬盘的物理结构

硬盘内部主要部件为磁盘盘片、传动手臂、读写磁头和主轴马达。实际数据都是写在盘片上,读写主要是通过传动手臂上的读写磁头来完成。实际运行时,主轴让磁盘盘片转动,然后传动手臂可伸展让读取头在盘片上进行读写操作。磁盘物理结构如下图所示:

磁盘结构

Read more
工程师跨越成长视频笔记

今天看了一个分享视频,来自美团技术学院院长刘江的分享。结合最近自己在公司里,对除技术外其他技能的要求有所反思,觉得有必要对这个分享做个纪要。下面是刘江老师的分享主要内容(包括主持人提问回答)。

技术人员需要的技能

之前觉得技术很牛逼很重要,很多事情的改变都是由技术推动的,但渐渐发现跟技术同等重要的事情还有很多。技术人员的能力要求分为四个方面:技术知识,技术能力,通用能力,专业影响力。

技术知识和技术能力是一个工程师通识的技能要求,毕竟要完成任务。但是沟通能力,以及商业sense也是很重要的。随着职级上升,沟通表达能力以及商业sense也越来越重要(上次去数据库大会,百度首席科学家毕然老师也强调了商业sense)。没有商业sense的技术在公司是没有价值的。而团队合作,作为leader是需要通过演讲来凝聚团队,给与团队目标。职级越高,对表达能力要求越高。而专业影响力在于沉淀,通过文字或者演技总结经验,传输给别人。通过博客或者演讲让自己在业界有一定影响力。

公司在对技术人员培养上,也需要给予表达和演讲这样的平台和机会,push他们,让他们走出舒适区,提升自己的软实力。

Read more