有时候没有本地没有足够的机器，可以利用自己的笔记本搭建一个简单的集群，验证一些HBase的基本功能，比较实用，可以学习参考https://bbs.huaweicloud.com/blogs/180567https://bbs.huaweicloud.com/blogs/180565

原文地址：https://bbs.huaweicloud.com/blogs/176372 给hadoop3, hbase2引入高效压缩zstd本地库文章（https://bbs.huaweicloud.com/blogs/168931）已经介绍了zstd算法，以及从源码开始安装zstd库方式；这里介绍一种使用EulerOS 2.x/centos7运行hadoop3/hbase2时，快速安装zstd库的方法。安装直接从下面地址下载zstd库的rpm文件https://download-ib01.fedoraproject.org/pub/epel/7/x86_64/Packages/l/libzstd-1.4.5-3.el7.x86_64.rpm    使用下面命令安装rpm -i zstd-1.4.5-3.el7.x86_64.rpm验证进入$hadoop/bin目录，执行命令：hadoop checknative -a./hadoop checknative -a 2020-06-19 17:20:08,155 INFO bzip2.Bzip2Factory: Successfully loaded & initialized native-bzip2 library system-native 2020-06-19 17:20:08,157 INFO zlib.ZlibFactory: Successfully loaded & initialized native-zlib library Native library checking: hadoop:  true /data/disk2/ts/hadoop-3.2.1/lib/native/libhadoop.so.1.0.0 zlib:    true /lib64/libz.so.1 zstd  :  true /lib64/libzstd.so.1 snappy:  true /lib64/libsnappy.so.1 lz4:     true revision:10301 bzip2:   true /lib64/libbz2.so.1如果能看到zstd : true，说明已经zstd库能够被正常加载

原文地址 https://bbs.huaweicloud.com/blogs/175483 使用HBase的现代产品对其读写性能的期望值不断提高。理想情况下，HBase应用程序希望在不放弃可靠的持久存储保证的情况下享受内存数据库的速度。我们在HBase 2.0中引入了一种名为Accordion的新算法，它朝着这个目标迈出了重要的一步。    HBase将数据划分为由RegionServer群集控制的region。 RegionServer的纵向可伸缩性对于最终用户的性能以及整个系统的利用率至关重要。通过更好地使用RAM，accordion提高了RegionServer的可伸缩性。它可以在内存中容纳更多数据，并减少写入磁盘的频率。这样带来多个好处。首先，降低了HBase的磁盘占用率和写入放大率。其次，更多的读写操作落到RAM，更少的操作落到磁盘I/O，换句话说，HBase的性能得以提高。传统上，这些指标被认为是不一致的，并且需要彼此进行权衡。使用accordion，它们会同时得到改善。    accordion的灵感来自于HBase的内部存储结构Log-Structured-Merge（LSM）树。 HBase region被存储为一系列可搜索键值映射。最顶部是一个可变的内存存储，称为MemStore，它保存最近的写入（put）操作。其余的是不可变的HDFS文件，称为HFiles。 MemStore溢出后，被刷新到磁盘，创建一个新的HFile。 HBase采用了多版本并发控制，即MemStore将数据变化存储为单独的版本。因此，一个key的多个版本可以在MemStore和多个HFile中。读取（get）操作通过key检索值，该操作扫描BlockCache中的HFile数据，以查找最新版本。为了减少磁盘访问次数，多个HFiles在后台被合并。此过程称为压缩（compaction），将删除冗余的cell并创建更大的文件。    accordion将LSM原理重新应用于MemStore，以消除数据仍在RAM中时的冗余和其他开销。这样做可以减少刷新到HDFS的频率，从而减少写放大和整个磁盘占用空间。由于MemStore溢出而产生的刷新减少，因而写操作停顿的频率降低，最后提高了写性能。磁盘上较少的数据还意味着对块缓存的压力较小，命中率较高，并最终改善了读取响应时间。最后，较少的磁盘写入也意味着在后台发生较少的压缩，即，从生产（读取和写入）工作中窃取了较少的周期。总而言之，可以将内存压缩的效果设想为一种催化剂，使整个系统运行起来更快。    accordion目前提供两种级别的内存压缩basic和eager。前者适用于所有数据更新模式的通用优化。后者对于数据流失率较高的应用程序（如生产者-消费者队列，购物车，共享计数器等）最有用。所有这些用例均具有频繁更新相同key的功能，这些key会生成多个冗余版本，算法可利用这些冗余版本提供更多价值。另一方面，eager优化可能会导致计算开销（更多的内存副本和垃圾回收），这可能会影响密集写入负载下的响应时间。如果MemStore使用on-heap的 MemStore-Local Allocation Buffer (MSLAB)，则开销很高。建议不要将这种配置与eager压缩相结合。    在下一部分中，将了解有关Accordion压缩算法的更多详细信息。如何使用    in-memory compaction可以全局配置，也可以按column family配置。 支持的级别为none（旧版实现），basic，eager。    默认情况下，所有表都应用basic in-memory compaction。 可以在hbase-site.xml中覆盖此全局配置，如下所示：<property>     <name>hbase.hregion.compacting.memstore.type</name>     <value><none | basic | eager></value> </property>    也可以在HBase Shell中按column family配置级别，如下所示：create ‘<tablename>’,  {NAME => ‘<cfname>’, IN_MEMORY_COMPACTION => ‘<NONE|BASIC|EAGER>’}性能提升    我们通过流行的Yahoo Cloud Service Benchmark（YCSB）对HBase进行了广泛的压力测试。我们的实验使用了100-200 GB的数据集，并行使了各种代表性的工作负载。结果表明，Accordion可带来显着的性能提升。    Heavy-tailed (Zipf) 分布。第一个实验执行了一个工作负载，其中key使用Zipf分布，遵循大多数现实场景。在这种情况下，当100％为写时，Accordion最多可将写入放大率降低30％，将写入吞吐量提高20％，并将GC降低22％。50％为读时，读延迟减少了12％。    Uniform 分布。第二个实验执行了另一个工作负载，其中所有key都同样热度的。在这种情况下，100％为写时，Accordion可将写入放大率降低多达25％，将写入吞吐量提高50％，并将GC降低36％。读延迟不受影响（这是意料之中的，因为完全缺乏局部性）Accordion是如何工作    高层设计。Accordion引入了CompactingMemStore一种内部应用压缩的MemStore实现。与默认的MemStore相比，后者将所有数据保持在一个整体的数据结构中，而Accordion将其作为一系列段进行管理。最年轻的部分称为活动部分，是可变的。它接受put操作。发生溢出时（默认情况下，为32MB-MemStore大小的25％），活动段将移动到内存管道中，并且变得不可变。我们称其为内存flush。 Get操作将扫描这些段和HFile（与HBase一样，可通过block cache访问后者）。    CompactingMemStore可能会不时在后台合并多个不可变的段，从而创建更大和更精简的段。因此，管道类似于“accordion bellows”（手风琴风箱），是“呼吸”（膨胀和收缩）的。    当RegionServer决定将一个或多个MemStore刷新到磁盘上以释放内存时，将会使用CompactingMemStore。这样做的理由是延长有效管理内存的MemStore的寿命，以减少总体I/O。当发生此类刷新时，所有管道段均移至复合snapshot，合并并流式传输到新的HFile。    段结构。 与默认的MemStore相似，CompactingMemStore在cell存储的顶部维护一个索引，以允许通过key快速搜索。 传统上，此索引被实现为Java跳表（ConcurrentSkipListMap）-动态但浪费的数据结构，用于管理许多小对象。 CompactingMemStore对不可变的段索引使用节省空间的扁平布局。 此通用优化可帮助所有压缩策略减少RAM开销，即使数据几乎没有冗余也是如此。 将段添加到管道后，索引被序列化为名为CellArrayMap的排序数组，该数组可以进行快速二分搜索。    CellArrayMap支持直接从Java堆分配cell，也支持从MSLAB的定制分配（堆上或堆外）。 通过从索引中引用的KeyValue对象可以抽象出实现上的差异。 CellArrayMap本身总是在堆上分配。    压缩算法。in-memory compaction 算法在流水线段的顶部维护单个扁平索引。这样可以节省空间，尤其是在数据项较小的情况下，因此可以更快的完成落盘操作。单个索引允许在一个位置进行搜索，因此控制住了读取延迟。    当活动段刷新到内存时，它进入到压缩管线队列中，并立即安排后台合并任务。后者同时扫描管道中的所有段（on-disk compaction），并将多个索引合并为一个。基本basic策略和eager压缩策略之间的差异体现在它们如何处理cell。basic压缩不会消除冗余数据版本，以避免物理复制。它只是重新排列对KeyValue对象的引用。相反，eager压缩会滤除重复项。这是以额外的计算和数据迁移为代价的-例如，使用MSLAB存储时，将尚存的cell复制到新创建的MSLAB。当数据高度冗余时，压缩的开销得到了回报。    压缩的未来实现可能会自动在basic和eager压缩策略之间进行选择。例如，该算法可能会尝试一次eager压缩，并根据收到的值（例如，被淘汰的部分数据）安排下一次压缩。这种方法可以减轻系统管理员的负担，并适应不断变化的访问模式。摘要    在这篇博客中，我们讨论了Accordion的基本原理，配置，性能提升以及内存压缩算法的一些细节。 下一篇文章将重点为HBase开发人员介绍系统的内部。    我们感谢Michael Stack，Anoop Sam John和Ramkrishna Vasudevan的持续支持，使该项目得以实现。

利用snapshot特性，可以采用以下简单的方法进行表的Renamehbase shell> disable 'tableName' hbase shell> snapshot 'tableName', 'tableSnapshot' hbase shell> clone 'tableSnapshot', 'newTableName' hbase shell> delete_snapshot 'tableSnapshot'void rename(HBaseAdmin admin, String oldTableName, String newTableName) {        String snapshotName = randomName();     admin.snapshot(snapshotName, oldTableName);     admin.cloneSnapshot(snapshotName, newTableName);     admin.deleteSnapshot(snapshotName);     admin.deleteTable(oldTableName) }

原文地址 https://bbs.huaweicloud.com/blogs/175386 HBase shell中有一个status命令，可以查看HBase集群的一些基本状态，例如：hbase(main):003:0> status3 servers, 0 dead, 2.3333 average load直接运行status命令，可以查看RegionServer的数量和基本的负载情况。 但是这样的结果是否太简单了呢？其实这个命令还可以输入参数，以便查看更多详细的信息的。查看status命令的帮助信息：（只能用help命令查看）hbase(main):001:0> help 'status'Show cluster status. Can be 'summary', 'simple', 'detailed', or 'replication'. Thedefault is 'summary'. Examples:   hbase> status  hbase> status 'simple'  hbase> status 'summary'  hbase> status 'detailed'  hbase> status 'replication'  hbase> status 'replication', 'source'  hbase> status 'replication', 'sink' 例如可以查看replication的基本信息，这些信息在判断replication运行的状态很有帮助，但是这些信息在其它地方比较难获取到（目前版本JMX中没有），只能通过这个命令进行获取。hbase(main):005:0> status 'replication'version 1.0.03 live servers    XXX-172-0-171:       SOURCE: PeerID=1, AgeOfLastShippedOp=0, SizeOfLogQueue=0, TimeStampsOfLastShippedOp=Wed Apr 06 11:00:19 CST 2016, Replication Lag=0       SINK  : AgeOfLastAppliedOp=0, TimeStampsOfLastAppliedOp=Fri Apr 01 12:17:12 CST 2016    XXX-172-0-173:       SOURCE: PeerID=1, AgeOfLastShippedOp=0, SizeOfLogQueue=0, TimeStampsOfLastShippedOp=Wed Apr 06 11:00:17 CST 2016, Replication Lag=0       SINK  : AgeOfLastAppliedOp=0, TimeStampsOfLastAppliedOp=Fri Apr 01 12:17:17 CST 2016    XXX-172-0-172:       SOURCE: PeerID=1, AgeOfLastShippedOp=0, SizeOfLogQueue=0, TimeStampsOfLastShippedOp=Wed Apr 06 11:00:18 CST 2016, Replication Lag=0       SINK  : AgeOfLastAppliedOp=0, TimeStampsOfLastAppliedOp=Mon Apr 04 03:53:53 CST 2016 另外在不方便查看HMaster页面的时候，也可以通过这个命令查看很多集群运行时的信息，很方便使用。 

原文地址：https://bbs.huaweicloud.com/blogs/174641背景：多租户共享集群时，可以针对namespace，Table，User进行请求的限制，控制负载，避免请求过多导致集群受影响。启用Quota默认情况下，quota功能处于禁用状态。要启用quota，将“hbase-site.xml”文件中的参数“hbase.quota.enabled”的值改为“true”Quota缓存刷新配置默认情况下，quota设置缓存刷新周期“hbase.quota.refresh.period”设为5*60000（5分钟）。这就意味着，用户在更新quota设置后最多需要等待5分钟，这些设置才能生效。 设置Quota当由于用户数量或用户请求过多而导致集群工作负载增加时，系统需要按照优先顺序对用户或用户请求进行排列以实现平稳运行。可利用HBase quota功能，让管理员限制HBase系统中的表、分区或请求的数量。HBase提供以下三种类型的quota：·         Namespace quota：一个Namespace中可包含的表或分区的数量·         请求数量quota：某个用户或某些相同名字的用户可以在任意指定时间内在特定表上或Namespace中执行的请求的数量。·         请求大小quota：某个用户或某些相同名字的用户可以在任意指定时间内在特定表上或Namespace中执行的请求的大小。 下面介绍每一种Quota的用法1.  Namespace QuotaNamespace quota用于设置一个Namespace中可包含的表或分区的数量。以下是Namespace quota：设置Namespace中可包含的表的数量示例命令说明create_namespace 'namespace_name',   {'hbase.namespace.quota.maxtables'=>'5'}使用quota的maxtables来创建Namespace。describe_namespace 'namespace_name '显示Namespace的quota信息。alter_namespace 'namespace_name ', {METHOD =>   'set', 'hbase.namespace.quota.maxtables'=>'8'}修改现有的Namespace并设置quota的maxtables值。alter_namespace 'namespace_name ', {METHOD =>   'unset', NAME=> 'hbase.namespace.quota.maxtables'}删除Namespace中设置的quota的maxtables值。 设置Namespace中可包含的分区的数量示例命令说明create_namespace 'namespace_name', {'hbase.namespace.quota.maxregions'=>'10'}使用quota的maxregions来创建Namespace。describe_namespace 'namespace_name '显示Namespace的quota信息。alter_namespace 'namespace_name ', {METHOD =>   'set', 'hbase.namespace.quota.maxregions'=>'20'}修改现有的Namespace并设置quota的maxregions值。alter_namespace 'namespace_name ', {METHOD =>   'unset', NAME=> 'hbase.namespace.quota.maxregions'}删除Namespace中设置的quota的maxregions值。2.  请求数量Quota请求数量Quota保留某个用户或某些相同名字的用户可以在任意指定时间内在特定表上或Namespace中执行的请求数量。请求数量Quota在命令中使用时间单位。有效的时间单位为秒（sec）、分（min）、小时（hour）和天（day）。以下是五种设置请求数量Quota的示例： 设置用户在指定时间内可以执行的请求数量示例命令说明set_quota TYPE => THROTTLE, USER =>   'user_name', LIMIT => '10req/sec'对指定用户设置每秒10个请求的quota。list_quotas USER => 'user_name'显示指定用户的quota信息。set_quota TYPE => THROTTLE, USER => '   user_name ', LIMIT => NONE删除指定用户的quota。 设置用户在指定时间内在指定表上可以执行的请求数量示例命令说明set_quota TYPE => THROTTLE, USER => '   user_name ', TABLE => 't1', LIMIT => '10req/sec'对指定用户的特定表设置每秒10个请求的quota。list_quotas USER => 'user_name', TABLE => 't1'显示指定用户在特定表上的quota信息。set_quota TYPE => THROTTLE, USER => 'u1',   TABLE => 't1', LIMIT => NONE删除指定用户的特定表的quota。 设置用户在指定时间内在指定Namespace上可以执行的请求数量示例命令说明set_quota TYPE => THROTTLE, USER => '   user_name ', NAMESPACE => 'ns1', LIMIT => '10req/sec'对指定用户的特定Namespace设置每秒10个请求的quota。list_quotas USER => 'user_name', NAMESPACE =>   'ns.*'显示指定用户在特定Namespace上的quota信息。set_quota TYPE => THROTTLE, USER => 'u1',   NAMESPACE => 'ns1', LIMIT => NONE删除指定用户的特定Namespace的quota。 设置在指定时间内可以在表上执行的请求数量示例命令说明set_quota TYPE => THROTTLE, TABLE => 't1,   LIMIT => '10req/sec'针对特定表设置每秒10个请求的quota。list_quotas TABLE => 't1'显示特定表的quota信息。set_quota TYPE => THROTTLE, TABLE => 't1',   LIMIT => NONE删除特定表的quota。 设置在指定时间内可以在Namespace中执行的请求数量示例命令说明set_quota TYPE => THROTTLE, NAMESPACE =>   'ns1', LIMIT => '10req/sec'针对特定Namespace设置每秒10个请求的quota。list_quotas NAMESPACE => 'ns1'显示特定Namespace的quota信息。set_quota TYPE => THROTTLE, NAMESPACE =>   'ns1', LIMIT => NONE删除特定Namespace的quota。3.  请求大小Quota请求大小quota是指设置某个用户或某些相同名字的用户可以在任意指定时间内在特定表上或Namespace中执行的请求大小。请求大小quota在命令中使用时间和大小单位。有效的大小单位为B（字节）、K（千字节）、M（兆字节）、G（十亿字节）、T（兆兆字节）和P（千万亿字节）。以下是五种设置请求大小quota的示例： 设置用户在指定时间内可以执行的请求大小示例命令说明set_quota TYPE => THROTTLE, USER =>   'user_name', LIMIT => '5K/min'对指定用户设置每分钟5千字节的quota。list_quotas USER => 'user_name'显示指定用户的quota信息。set_quota TYPE => THROTTLE, USER => '   user_name ', LIMIT => NONE删除指定用户的quota。·          设置在指定时间内在指定表上可以执行的请求大小示例命令说明set_quota TYPE => THROTTLE, USER => 'u1',   TABLE => 'table_name', LIMIT => '5K/min'对指定用户的特定表设置每分钟5千字节的quota。list_quotas USER => 'bob.*', TABLE => 't1'显示指定用户在特定表上的quota信息。set_quota TYPE => THROTTLE, USER => 'u1',   TABLE => 't1', LIMIT => NONE删除指定用户的特定表的quota。·          设置用户在指定时间内在指定Namespace中可以执行的请求大小示例命令说明set_quota TYPE => THROTTLE, USER => 'u1',   NAMESPACE => 'ns1', LIMIT => '5K/min'对指定用户的特定Namespace设置每分钟5千字节的quota。list_quotas USER => 'bob.*', NAMESPACE =>   'ns.*'显示指定用户在特定Namespace上的quota信息。set_quota TYPE => THROTTLE, USER => 'u1',   NAMESPACE => 'ns1', LIMIT => NONE删除指定用户的特定Namespace的quota。 设置在指定时间内可以在表上执行的请求大小示例命令说明set_quota TYPE => THROTTLE, TABLE => 't1',   LIMIT => '5K/min'针对特定表设置每分钟5千字节的quota。list_quotas TABLE => 'myTable'显示特定表的quota信息。set_quota TYPE => THROTTLE, TABLE => 't1',   LIMIT => NONE删除特定表的quota。 设置在指定时间内可以在Namespace中执行的请求大小示例命令说明set_quota TYPE => THROTTLE, NAMESPACE =>   'ns1', LIMIT => '5K/min'针对特定Namespace设置每分钟5千字节的quota。list_quotas NAMESPACE => 'ns.*'显示特定Namespace的quota信息。set_quota TYPE => THROTTLE, NAMESPACE =>   'ns1', LIMIT => NONE删除特定Namespace的quota。 

原文地址：https://bbs.huaweicloud.com/blogs/173527学习HBase的RPC可以为学HBase打好基础，因为RPC是HMaster，RegionServer和Client通信的纽带1.1      1 RPCRPC（Remote Procedure Call Protocol）——远程过程调用协议，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。RPC协议假定某些传输协议的存在，如TCP或UDP，为通信程序之间携带信息数据。在OSI网络通信模型中，RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。RPC采用客户机/服务器模式。请求程序就是一个客户机，而服务提供程序就是一个服务器。    首先，客户机调用进程发送一个有进程参数的调用信息到服务进程，然后等待应答信息。在服务器端，进程保持睡眠状态直到调用信息的到达为止。当一个调用信息到达，服务器获得进程参数，计算结果，发送答复信息，然后等待下一个调用信息，最后，客户端调用进程接收答复信息，获得进程结果，然后调用执行继续进行。交互过程如下图所示：1.2      HBase.ipc1.2.1        2.1 ServerRPC Server实现了一种抽象的RPC服务，同时提供Call队列。Ø  RPC Server结构 结构 (类)功能 HBaseServer.ListenerRPC Server的监听者，用来接收RPC Client的连接请求和数据，其中数据封装成Call后PUSH到Call队列。HBaseServer.HandlerRPC Server的Call处理者，和Server.Listener通过Call队列交互。HBaseServer.ResponderRPC Server的响应者。HBaseServer.Handler按照异步非阻塞的方式向RPC Client发送响应，如果有未发送出的数据，交由HBaseServer.Responder来完成。HBaseServer.ConnectionRPC Server数据接收者。提供接收数据，解析数据包的功能。HBaseServer.Call持有客户端的Call信息。 Ø  RPC Server主要流程 RPC Server作为服务提供者由两个部分组成：接收Call调用和处理Call调用。接收Call调用负责接收来自RPC Client的调用请求，编码成Call对象后放入到Call队列中。这一过程由Listener线程完成。具体步骤：1.   Listener线程监视RPC Client发送过来的数据。2.   当有数据可以接收时，Listener启动Reader线程，reader线程调用Connection的readAndProcess方法接收并处理数据。3.   Connection边接收边对数据进行处理，如果接收到一个完整的Call包，则构建一个Call对象PUSH到Call队列中，由Handler线程来处理Call队列中的所有Call。4.   Handler线程监听Call队列，如果Call队列非空，按FIFO规则从Call队列取出Call。5.   将Call交给RPC.Server处理。(在WritableRpcEngine.Server类中，该类是HBaseServer的子类)。6.   借助JDK提供的Method，完成对目标方法的调用，目标方法由具体的业务逻辑实现。7.   返回响应HBaseServer.Handler按照异步非阻塞的方式向RPC Client发送响应，如果有未发送出的数据，则交由Server.Responder来完成。1.2.2        ClientRPC Client是Client的实现和入口类。Ø  RPC Client结构 结构 功能 HBaseClient.ConnectionId到RPC Server对象连接的标识。HBaseClient.CallCall调用信息。HBaseClient.ParallelResultsCall响应。WritableRpcEngine.Invoker对InvocationHandler的实现，提供invoke方法，实现RPC Client对RPC Server对象的调用。Invocation用来序列化和反序列化RPC Client的调用信息。（主要应用JAVA的反射机制和InputStream/OutputStream）Ø  RPC Client主要流程 每一个Call都是由RPC Client发起。步骤说明：1.   RPC Client发起RPC Call，通过JAVA反射机制转化为对Client.call调用。2.   调用getConnection得到与RPC Server的连接。每一个RPC Client都维护一个HashMap结构的到RPC Server的连接池。具体建立连接的流程见下图。3.   通过Connection将序列化后的参数发送到RPC服务端。4.   阻塞方式等待RPC服务端返回响应。1.2.3        同步客户端发起的RPC调用是同步的，而服务端处理RPC调用是异步的。客户端调用线程以阻塞同步的方式发起RPC连接及RPC调用，将参数等信息发送给Listener，然后等待Connection接收响应返回。Listener负责接收RPC连接和RPC数据，当一个Call的数据接收完后，组装成Call，并将Call放入由Handler提供的Call队列中。Handler线程监听Call队列，如果Call队列不为空，则按FIFO方式取出Call，并转为实际调用，以非阻塞方式将响应发回给Connection，未发送完毕的响应交给Responder处理。

在使用GeoMesa时，会经常遇到性能问题，Geomesa作为HBase的客户端程序，它的代码调用了许多HBase的接口，有些地方调用不好，就会造成HBase额外消耗资源，造成性能下降。之前程序员小哥就遇到过Geomesa频繁调用hbase:meta表造成meta表节点所在RS cpu偏高的情况，这次又遇到内存持续增长造成HBase节点重启的问题，遇到这情况就需要深入到Geomesa的代码里才能去发现问题解决问题。这篇Geomesa的内存优化博文，就处理了其中一个场景下的内存问题https://bbs.huaweicloud.com/blogs/173946

MRS:SparkStreaming对接安全kafka写入hbase样例关键词: MRS官网样例 Kerberos认证 kafka SparkStreaming hbase摘要:MRS spark官网样例的补充,实现SparkStreaming对接安全kafka写入hbase前期准备:1.      创建MRS 1.9.0 混合集群,大数据组件至少包括Hadoop , Spark , Hive , HBase , Kafka,开启Kerberos认证2.      集群创建好之后,参照官网https://support.huaweicloud.com/devg-mrs/mrs_06_0154.html准备开发用户,作者创建的用户名为sparkuser ,然后下载keytab与krb5.conf文件待用3.      样例下载地址https://github.com/huaweicloud/huaweicloud-mrs-example/tree/mrs-1.9开发程序:1.      将huaweicloud-mrs-example/src/spark-examples/SparkStreamingKafka010JavaExample样例导入idea2.    删除掉com.huawei.bigdata.spark.examples包下面所有类,将 SparkOnStreamingToHbase.java和StreamingExampleProducer.java文件(见附件)复制到com.huawei.bigdata.spark.examples包下3.    将pom.xml文件替换掉原工程的pom文件场景说明:1.      假定某个业务Kafka每3秒就会收到5个用户的消费记录。Hbase的table1表存储用户历史消费的金额信息。现table1表有10条记录，表示有用户名分别为1-10的用户，他们的历史消费金额初始化都是0元。基于某些业务要求，开发的Spark应用程序实现如下功能：实时累加计算用户的消费金额信息：即用户总消费金额=用户的消费金额(kafka数据) + 用户历史消费金额(table1表的值)，更新到table1表。2.      创建HBase表，并插入数据a.     通过HBase创建名为table1的表，命令如下:create 'table1', 'cf'b.     通过HBase执行如下命令，将数据插入table1表中put 'table1', '1', 'cf:cid', '0'put 'table1', '2', 'cf:cid', '0'put 'table1', '3', 'cf:cid', '0'put 'table1', '4', 'cf:cid', '0'put 'table1', '5', 'cf:cid', '0'put 'table1', '6', 'cf:cid', '0'put 'table1', '7', 'cf:cid', '0'put 'table1', '8', 'cf:cid', '0'put 'table1', '9', 'cf:cid', '0'put 'table1', '10', 'cf:cid', '0'c.     通过HBase执行scan 'table1'命令,3.      集群组件的配置a.      将kafka的Broker配置参数“allow.everyone.if.no.acl.found”的值修改为“true”b.      如果开启了kerberos认证，需要将客户端的配置文件“spark-defaults.conf”和sparkJDBC服务端中的配置项spark.yarn.security.credentials.hbase.enabled置为true。c.       需要修改程序SparkOnStreamingToHbase类中kerberos.domain.name的值为$KAFKA_HOME/config/consumer.properties文件中kerberos.domain.name配置项的值。d.      用户需要对接安全Kafka，创建jaas.conf文件待用,文件内容内容如下. 注意:在Spark on YARN模式下，jaas.conf和user.keytab通过YARN分发到Spark on YARN的container目录下，因此KafkaClient中对于“keyTab”的配置路径必须为相对jaas.conf的所在路径，例如“./user.keytab”。principal修改为自己创建的用户名。Client {com.sun.security.auth.module.Krb5LoginModule requireduseKeyTab=truekeyTab="./user.keytab"principal="sparkuser"useTicketCache=falsestoreKey=truedebug=true;};KafkaClient {com.sun.security.auth.module.Krb5LoginModule requireduseKeyTab=truekeyTab = "./user.keytab"principal="sparkuser"useTicketCache=falsestoreKey=truedebug=true;}; 调测程序:1.      在后台master节点创建/root/jars和/root/jars/conf文件夹,然后将程序打包上传至/root/jars下,再将jaas.conf,keytab,krb5.conf文件上传至/root/jars/conf下.在idea中将程序打包,上传至/root/jars目录下2.      创建Topic, 并且启动Kafka的Producer，向Kafka发送数据,{zkQuorum}表示ZooKeeper集群信息，格式为IP:port, JAR_PATH为程序jar包所在路径，BrokerList格式为brokerIp:9092, {Topic}为kafka的topic名称,作者为apple。 $KAFKA_HOME/bin/kafka-topics.sh --create --zookeeper {zkQuorum}/kafka --replication-factor 1 --partitions 3 --topic {Topic}作者命令:$KAFKA_HOME/bin/kafka-topics.sh --create --zookeeper 192.168.0.122:2181/kafka --replication-factor 2 --partitions 3 --topic apple java -cp $SPARK_HOME/jars/*:$SPARK_HOME/jars/streamingClient010/*:$KAFKA_HOME/libs/*:{JAR_PATH} com.huawei.bigdata.spark.examples.StreamingExampleProducer {BrokerList} {Topic}作者命令:java -cp $SPARK_HOME/jars/*:$SPARK_HOME/jars/streamingClient010/*:$KAFKA_HOME/libs/*:/root/jars/SparkStreamingKafka010JavaExample-1.0.jar com.huawei.bigdata.spark.examples.StreamingExampleProducer 192.168.0.106:9092 apple3.      在运行样例主程序时需要指定<checkpointDir> <brokers> <topic> <batchTime>，其中<checkPointDir>指应用程序结果备份到HDFS的路径，<brokers>指获取元数据的Kafka地址，安全集群格式为brokerIp:21007,<topic>指读取Kafka上的topic名称，<batchTime>指Streaming分批的处理间隔.切换目录到/root/jars下面a.     yarn-client模式下的运行命令:spark-submit --master yarn --deploy-mode client --files ./conf/jaas.conf,./conf/user.keytab --driver-java-options "-Djava.security.auth.login.config=./jaas.conf" --conf "spark.executor.extraJavaOptions=-Djava.security.auth.login.config=./jaas.conf" --jars $SPARK_HOME/jars/streamingClient010/kafka-clients-0.10.0.0.jar,$SPARK_HOME/jars/streamingClient010/kafka_2.10-0.10.0.0.jar,$SPARK_HOME/jars/streamingClient010/spark-streaming-kafka-0-10_2.11-2.1.0.jar --class com.huawei.bigdata.spark.examples.SparkOnStreamingToHbase /root/jars/SparkStreamingKafka010JavaExample-1.0.jar <checkpointDir> <brokers> <topic> <batchTime>作者命令:spark-submit --master yarn --deploy-mode client --files ./conf/jaas.conf,./conf/user.keytab --driver-java-options "-Djava.security.auth.login.config=./jaas.conf" --conf "spark.executor.extraJavaOptions=-Djava.security.auth.login.config=./jaas.conf" --jars $SPARK_HOME/jars/streamingClient010/kafka-clients-1.1.0-mrs-1.9.0.jar,$SPARK_HOME/jars/streamingClient010/kafka_2.11-1.1.0-mrs-1.9.0.jar,$SPARK_HOME/jars/streamingClient010/spark-streaming-kafka-0-10_2.11-2.2.2-mrs-1.9.0.jar --class com.huawei.bigdata.spark.examples.SparkOnStreamingToHbase /root/jars/SparkStreamingKafka010JavaExample-1.0.jar /tmp 192.168.0.106:21007 apple 6b.     yarn-cluster模式下,首先需要修改SparkOnStreamingToHbase.java文件中将代码”String filePath = System.getProperty("user.dir") + File.separator + "conf" + File.separator;””修改为”String filePath = System.getProperty("user.dir") + File.separator ;”,运行命令如下:spark-submit --master yarn --deploy-mode cluster --files ./conf/jaas.conf,./conf/user.keytab,./conf/krb5.conf --conf "spark.yarn.cluster.driver.extraJavaOptions=-Djava.security.auth.login.config=./jaas.conf" --conf "spark.executor.extraJavaOptions=-Djava.security.auth.login.config=./jaas.conf" --jars $SPARK_HOME/jars/streamingClient010/kafka-clients-0.10.0.0.jar,$SPARK_HOME/jars/streamingClient010/kafka_2.10-0.10.0.0.jar,$SPARK_HOME/jars/streamingClient010/spark-streaming-kafka-0-10_2.11-2.1.0.jar --class com.huawei.bigdata.spark.examples.SparkOnStreamingToHbase /root/jars/SparkStreamingKafka010JavaExample-1.0.jar <checkpointDir> <brokers> <topic> <batchTime> 作者命令:spark-submit --master yarn --deploy-mode cluster --files ./conf/jaas.conf,./conf/user.keytab,./conf/krb5.conf --conf "spark.yarn.cluster.driver.extraJavaOptions=-Djava.security.auth.login.config=./jaas.conf" --conf "spark.executor.extraJavaOptions=-Djava.security.auth.login.config=./jaas.conf" --jars $SPARK_HOME/jars/streamingClient010/kafka-clients-1.1.0-mrs-1.9.0.jar,$SPARK_HOME/jars/streamingClient010/kafka_2.11-1.1.0-mrs-1.9.0.jar,$SPARK_HOME/jars/streamingClient010/spark-streaming-kafka-0-10_2.11-2.2.2-mrs-1.9.0.jar --class com.huawei.bigdata.spark.examples.SparkOnStreamingToHbase /root/jars/SparkStreamingKafka010JavaExample-1.0.jar /tmp 192.168.0.106:21007 apple 6 4.     在hbase下面查看表scan ”table1”,验证成功

本帖汇总HBase入门学习相关的资料，和大家一起学习和使用HBase，了解基础原理.定期更新...https://bbs.huaweicloud.com/blogs/173527  HBase学习之：HBase RPChttps://bbs.huaweicloud.com/forum/thread-54213-1-1.html  HBase RowKey思路https://bbs.huaweicloud.com/blogs/173943  HBase篇---Shell命令行和Rest APIhttps://bbs.huaweicloud.com/blogs/174641 HBase Quota的使用 https://bbs.huaweicloud.com/blogs/173946  HBase&&GeoMesa 内存优化https://bbs.huaweicloud.com/blogs/175255   大数据组件运维工具之HBasehttps://bbs.huaweicloud.com/blogs/175386  HBase shell-status命令https://bbs.huaweicloud.com/blogs/175483  HBase 2.0 中的 In-Memory Compactionhttps://bbs.huaweicloud.com/blogs/178986  opentsdb读写与查询命令整理https://bbs.huaweicloud.com/blogs/180585  hbase hbtop工具介绍https://bbs.huaweicloud.com/blogs/184848 HBase客户端代码书写规范https://bbs.huaweicloud.com/blogs/187173 分享一个HBaseCompaction引起的GC问题及其恢复https://bbs.huaweicloud.com/blogs/192853 HBase是怎样从HFile中找到某个rowkeyhttps://bbs.huaweicloud.com/blogs/193849 UserGroupInformation中的几种user介绍https://bbs.huaweicloud.com/blogs/198191 初学Flink-使用Flink读写HBasehttps://bbs.huaweicloud.com/blogs/199399  HBase实用技巧：一种全量+增量数据的迁移方法https://bbs.huaweicloud.com/blogs/199075  HBase 2.X版本的元数据修复及一种数据迁移方式

问题Spark任务读取HBase报错，报错信息：Task 0.0 in stage 0.0 (TID 0) had a not serializable result: org.apache.hadoop.hbase.io.ImmutableBytesWritable，应该如何处理？回答可通过如下两种方式处理：在代码的SparkConf初始化之前执行以下两行代码：System.setProperty("spark.serializer", "org.apache.spark.serializer.KryoSerializer");System.setProperty("spark.kryo.registrator", "com.huawei.bigdata.spark.examples.MyRegistrator");在SparkConf对象使用set方法设置，代码如下：val conf = new SparkConf().setAppName("HbaseTest");conf.set("spark.serializer", "org.apache.spark.serializer.KryoSerializer");conf.set("spark.kryo.registrator", "com.huawei.bigdata.spark.examples.MyRegistrator");

    此方案会清空hbase的表数据,谨慎操作     此方案会清空hbase的表数据,谨慎操作     此方案会清空hbase的表数据,谨慎操作1：停止hbase服务           在mrs manager上停止hbase服务 2：删除 hbase 在hdfs 上目录    hdfs dfs  -rm -r /hbase3：清空hbase 在zk上的节点     rmr    /hbase 4：重新启动Hbase即可            在mrs manager上重启hbase服务                   

操作场景：    Flume消费kafka数据存储到HBase中。前提条件：    已创建混合集群或者流式和分析集群（集群间网络互通，如果开启kerberos，则需配置跨集群互信https://support.huaweicloud.com/usermanual-mrs/mrs_01_0354.html）。操作步骤：    1. 从HBase客户端拷贝配置文件hbase-site.xml到Flume server所在节点（流式core节点）的配置目录 "/opt/Bigdata/MRS_x.x.x/1_x_Flume/etc/" 下。通常可以在分析集群Master节点HBase客户端安装目录如“/opt/client/HBase/hbase/conf/”下找到hbase-site.xml文件。 拷贝完成后文件需要修改文件属组为omm:wheel。    2. 从HBase集群下载用户的认证凭据。a. 在MRS Manager，单击“系统设置”。b. 在“权限配置”区域，单击“用户管理”。c. 在用户列表中选择需要的用户，单击后面的“更多”下载用户凭据。d. 解压下载的用户凭据文件，获取krb5.conf和user.keytab文件。    3. 将上一步获得的krb5.conf和user.keytab拷贝到Flume server所在节点（流式core节点）的配置目录 "/opt/Bigdata/MRS_x.x.x/1_x_Flume/etc/" 下。文件属组需要修改为omm:wheel。    4. 修改配置文件jaas.conf，文件所在目录 "/opt/Bigdata/MRS_x.x.x/1_x_Flume/etc/" 。        修改参数“keyTab”定义的用户认证文件完整路径即步骤3中保存用户认证文件的目录。    5. 修改配置文件flume-env.sh，文件所在目录 "/opt/Bigdata/MRS_x.x.x/1_x_Flume/etc/" 。                在 “-XX:+UseCMSCompactAtFullCollection”后面，增加以下内容：-Djava.security.krb5.conf=/opt/Bigdata/MRS_x.x.x/1_x_Flume/etc/krb5.conf -Djava.security.auth.login.config=/opt/Bigdata/MRS_x.x.x/1_x_Flume/etc/jaas.conf -Dzookeeper.request.timeout=120000                例如："-XX:+UseCMSCompactAtFullCollection -Djava.security.krb5.conf=/opt/Bigdata/MRS_2.1.0/1_6_Flume/etc/krb5.conf -Djava.security.auth.login.config=/opt/Bigdata/MRS_2.1.0/1_6_Flume/etc/jaas.conf -Dzookeeper.request.timeout=120000"                请根据实际情况，修改配置文件路径，然后保存并退出配置文件。    6. 将HBase集群的“/etc/hosts”文件中host匹配相关内容添加到Flume server节点的“/etc/hosts”文件。    7. 重启该节点的flume实例。    8. 修改Flume配置文件“properties.properties”。                vi /opt/Bigdata/MRS_x.x.x/1_x_Flume/etc/properties.properties                将以下内容保存到文件“properties.properties”中：             server.sources = kafka_source         server.channels = flume         server.sinks = hbase                         server.sources.kafka_source.channels = flume         server.sources.kafka_source.type = org.apache.flume.source.kafka.KafkaSource         server.sources.kafka_source.topics = flume_test         server.sources.kafka_source.groupId = flume_group         server.sources.kafka_source.batchSize = 1000         server.sources.kafka_source.kafka.security.protocol  = SASL_PLAINTEXT         server.sources.kafka_source.kafka.kerberos.domain.name = hadoop.XXX.com         server.sources.kafka_source.kafka.bootstrap.servers=XXX.XXX.XXX.XXX:21007,XXX.XXX.XXX.XXX:21007,XXX.XXX.XXX.XXX:21007                  server.channels.flume.type = memory         server.channels.flume.capacity=100000         server.channels.flume.transactionCapacity=10000         server.channels.flume.channelfullcount = 10         server.channels.flume.keep-alive = 3          server.channels.flume.byteCapacityBufferPercentage = 20                  server.sinks.hbase.channel = flume         server.sinks.hbase.type = hbase         server.sinks.hbase.table = hbase_name         server.sinks.hbase.columnFamily= info         server.sinks.hbase.batchSize = 1000         server.sinks.hbase.kerberosPrincipal = admin         server.sinks.hbase.kerberosKeytab = /opt/Bigdata/MRS_x.x.x/1_x_Flume/etc/user.keytab         请根据实际情况，修改以下参数，然后保存并退出。         kafka.bootstrap.servers         默认情况下，安全集群对应端口21007，普通集群对应端口9092。         kafka.security.protocol         安全集群请配置为SASL_PLAINTEXT，普通集群请配置为PLAINTEXT。         kafka.kerberos.domain.name         普通集群无需配置此参数。安全集群对应此参数的值为Kafka集群中“kerberos.domain.name”对应的值。具体可到Borker实例所在节点上查看“/opt/Bigdata/MRS_Current/1_X_Broker/etc/server.properties”文件中配置项“kerberos.domain.name”对应的值，仅安全集群需要配置，其中“X”为随机生成的数字，请根据实际情况修改。         kerberosPrincipal         安全集群需要配置，用户名         kerberosKeytab                安全集群需要配置，用户认证文件，需要写绝对路径。

标签数据已经成为越来越普遍的一类数据，以用户画像场景最为典型，如在电商场景中，这类数据可被应用于精准营销推荐。常见的用户画像标签数据举例如下：基础信息：如性别，职业，收入，房产，车辆等。购买能力：消费水平、败家指数等。行为特征：活跃程度，购物类型，起居时间等。兴趣偏好：品牌偏好，颜色偏好，价格偏好等。如何高效的利用标签数据进行精准查询，在TB/PB级别标签数据规模下，达到ms级别的查询性能，请看CloudTable的标签索引特性https://bbs.huaweicloud.com/blogs/163489

1       概述   Hbase是No SQL的列存储数据库，和关系型数据库不同，没有表连接操作，在操作上限制比较大。因此，如果Schema设计的不好，会大大降低数据访问的效率，无端增加系统的负载。Schema设计需要综合考虑业务的需求和Hbase存储、访问的特点。设计好的Schema，能够充分享用Hbase大容量存储的优势同时，又能够获取较高的访问效率。本文所阐述的原则基于Hbase的路由寻址原理和底层文件存储结构，因此对本文的理解需要首先掌握Hbase路由寻址原理和文件存储结构。本文阐述HbaseSchema设计的经验原则，但需要注意的是Schema设计是根据场景综合考虑的结果，没有哪个准则能够适应所有的场景，因此在应用中需要综合考虑多个准则，平衡多种因素，才能设计出最符合业务需求的Schema。设计任何HBase业务的schema，都综合要考虑如下问题：Ø  读数据o    业务读数据是否方便？业务逻辑尽量简单o    要读取的数据在存储上是否连续分布？连续分布的数据读取效率较高，系统IO的垃圾数据较少Ø  写数据o    一次RPC能够写入多少数据？IO是hbase的瓶颈之一，需要考虑一次RPC能够写入更多的数据。o    写数据是否能够均衡？一段时间之内写入的数据在分布上能够一定程度上分散开能够保证并发度，提高写数据速度。o    写数据是否相对集中？短时间内写入的数据太分散的话会导致容易达到写操作内存警戒线，影响性能。Ø  数据清理o    如何清理数据？Hbase没有提供高效的数据清理手段，数据如何清理（Delete/dorptable/TTL/Versions?）o    如何保证没有大量过小或者空的region？空region在HBase中占用负载和内存，而且hbase没有有效手段来清理或者合并这些region，如何避免？  2       Schema设计思路   2.1   总体思路   本节讲述Schema设计总体的思路，Rowkey、Column、Family、Value的设计为本节讲述的原则的具体实现。2.1.1   Denormalization——以空间换取效率HBase具有大容量的特点，摆脱了Normalization的限制，可以采用冗余的方法，将常用的计算结果存储在一张数据表中，不需要在查询的时候适时计算。例如，对于排名统计，受容量限制，传统数据库采用适时计算排序的方式。这样的做法在数据量比较大的时候，适时计算无法满足查询的性能要求。而在HBase中，可以将排名数据提前计算出来，存放在Hbase中。如下所示为topURL的Schema设计：2.1.2   业务需要同时访问的数据连续分布Hbase是排序过的列存储形式。数据访问按照数据块来进行。一次业务中需要的数据连续分布可以让系统读到的一个数据块包含更多的有用信息。另外，Hbase Scan的效率远高于random read，连续分布的业务数据可以使用scan操作。HBase数据在存储上先按照rowkey进行排序，rowkey相同的按照column排序，rowkey和column都相同的按照时间戳排序。HBase存储的格式是byte类型，按照ascii编码大小进行排序。如下图所示：2.1.3   减少系统瓶颈的压力Hbase系统性能的瓶颈在于IO，因此提高系统的性能关键在于减少IO上的压力。可以采用的方法有：Ø  能够同时存取的数据压缩在一个cell中，如使用protobufØ  能够同时存取的数据放在同一行的不同列中，减少RPC2.2   数据放在同一个cell中还是同一行的不同列中需要根据数据量的大小和枚举值的多少进行权衡。表设计   Hbase表可以定义一些表属性，这些属性的合理使用对业务有较大影响。这些属性包括TTL、Versions、compression、bloomfilter等。另外，建表的方法以及region划分对系统并发能力、数据清理能力有影响。2.2.1   按天建表按天建表的主要作用有两个：Ø  可以将数据以天为单位分开，这样当数据过期的时候，可以通过drop表的方法来清理。Ø  在存入数据的时候，只涉及到当天的数据表，数据相对集中，在数据量非常大的情况下会有更好的性能表现。按天建表是一个例子，实际应用中可以按照特定时间周期来建表，例如年、月等。建表选择时间周期的原则有两个：Ø  当数据过期以后，能够同时清理。Ø每张表的数据分配到每个regionserver上以后，能够划分成数目合适的region。每个regionserver的激活Region数大于1，小于（写操作内存/flushsize）为宜。如果激活region数过少，则系统并发度不好；否则如果过大，会导致写操作内存很容易达到警戒线，影响写操作性能。2.2.2   预分regionHBase0.90以后的版本提供了建表预分region的功能。建表预分region可以让region在开始阶段就能够均衡到各个regionserver之间。因此需要根据数据的分布，识别出可能会造成热点的key的区域，在这些区域设置splitkey，进行预分region。2.2.3   TTLTTL是另外一种数据清理的方法。设定数据的生命周期，在数据过期以后，hbase自动清理这些数据。和按天建表，过期后删表的方法相比，设置TTL的方法更为简单直观，但是也有一些缺点：Ø  过期的数据需要一定时间才能够清理掉，这时候如果查询到了过期的数据可能会长时间没有响应，影响查询的性能。Ø  使用TTL来清理数据主要是通过compact进行的，在特定场合下会增加compact的负担。因此，对TTL的使用需要根据业务需求、数据量来综合考虑。需要尽量避免查询到过期的数据，如果系统负荷非常大，不建议使用TTL。2.2.4   VersionsHbase是个多维的数据表。每行每列可以存放多个版本的数据。多个版本之间除了内容不同以外，唯一的区别是时间戳。时间戳相同的版本会被覆盖掉。Versions提供了查询历史版本的信息，但是版本个数是有限的，对于需要查询历史上不同时间段的内容的场景，可以通过设置多个版本来实现。Versions的个数有限，如果需要存放的历史版本数量非常巨大或者数量不能确定在一定范围之内的场景，不适合使用versions。另外，versions也是清理数据的一种方式。例如设置versions=3，如果在其中写入了4个版本的数据，则最老的版本数据会被清理掉。2.2.5   使用压缩创建表的时候，可以指定压缩算法。Hbase0.90系列版本支持lzo和gzip两种压缩方式。Lzo的压缩率低一些，能够压缩到原始数据的40%左右，但是压缩速度比较快，适合于对于存取速度要求比较高，但对空间要求略低的场景。Gzip的压缩率高，能够压缩到原始数据的30%以内，但是压缩速度比较慢，适合于存取速度要求低，但空间要求高的场景。压缩率和数据的结构有关系，如果是随机程度比较高的无序数据，压缩率会比较低一些，如果是比较有规律的数据（如日志数据），压缩率会比较高。另外，使用lzo需要用到具有gpl 授权的桥接程序，商用的化需要考虑授权的问题。2.2.6   BloomfilterHbase中，使用bloomfilter的列，写入数据的时候，要将该数据的key添加到bloomfilter中；读取数据之前，要使用该数据的key在bloomfilter中进行测试，确定该key是否添加到了bloomfilter中。因此，bloomfilter可以用来在读取一个精确的key之前，预判该key是否在文件中实际存在，进而减少读取文件的消耗。由于bloomfilter是根据多个hash函数hash出来的bit值进行判断，可能会有重复，因此bloomfilter可以准确判断出一个key的不存在，而不能准确判断出key的存在。BloomFilter的key指的是Hstorekey。HStorekey中包括row、column、timestamp成员变量。 在实际使用中，获取bloomfilterkey的返回值是Hstorekey的row。因此，hbase中，Bloomfilter真正使用的key是rowkey。bloomfilter的vectorsize、元素个数、hash函数个数之间的关系如下：M表示vectorsize，n表示元素个数，k表示hash函数个数，则：M = (k*n)/ln2在hbase中，hash函数个数默认为4，因此，m和n的关系为：M=5.77n。因此，假定有1M条记录要插入bloomfilter，则需要的向量的大小为5.7M bit，约0.7Mb。如果每条记录在磁盘上存储的大小是256个字节，如果有1T的数据，则有4G条记录，约耗费2.7G内存用于存储bloomfilter。如果每条记录在磁盘上的存储大小为2K，如果有1T的数据，则有500M条记录，约耗费350M内存用于存储bloomfilter。因此，存储的每条记录越大，bloomfilter的空间利用效率越高。 综上所述，适合使用bloomfilter的场景需要同时满足如下条件：Ø  访问数据使用精确的key。Ø  数据是小key，大value的模式。（即使这样，也要根据数据量来计算消耗的内存，综合判断） 2.3   Rowkey结构设计   在系统设计中，为了提高系统性能都需要考虑以下两个因素：1）  提高数据访问的速度2）  提高数据的利用率结合Hbase的存储访问特点，要做到以上两点，在hbase的rowkey设计时，一个总的原则是：需要同时访问的数据，rowkey尽量连续。原因如下：          i.            数据Scan操作必须使用Startrow和Endrow来指定范围，避免或减少使用filter才能提高访问速度。因为：Ø  在Hbase的regioninfo中，有region的startrow和endrow信息，因此指定了scan的rowkey范围的话，hbase能够快速定位出需要访问的数据在哪个region。Ø  Hbase在文件存储上是排序并有索引的存储。Hfile中keyvalue的排序优先考虑rowkey的排序。并且Hfile的索引使用storekey，在storekey中，rowkey处于最优先的位置。因此如果指定出startrow和endrow，hbase就能快速定位需要访问的数据在hfile中的位置。这样可以提高数据访问的速度。根据这个原则，如果需要访问的数据rowkey差异很大，则没有办法指定Startrow和endrow。访问可能会是一个全表扫描的过程，效率就非常低了。        ii.            需要访问的数据rowkey连续的话，scan到的有用数据比较多，利用率高，能够避免或减少反复内存倒换。 另外，rowkey的设计和数据的分布有很大关系，rowkey设计的时候需要保证数据入库时的并发度，但又不能过于分散。下面以MD业务和scmartcare业务的schema设计为例，讲述为了保证业务需要的数据rowkey连续以及保证数据良好分布的一些原则。2.3.1   可枚举属性值较少的属性放在rowkey前面在rowkey中，需要放入多个属性，这多个属性的先后次序和访问的效率有直接的关系。一个普遍的规则是：数量较少，可控的属性放在rowkey前面（如ServiceType，CPID等）；反之放在后面（如url，mxid等）。这样做的原因是可控属性放在前面，对各种不同查询需求的平衡性强一些，反之平衡性较差。例如如下TraficGeo表rowkey的场景：模型一：ServiceType可枚举，并且数量较少，分为http和rtsp两种，放在前面；而cpid可能会比较多（假设有5个cp），因此放在后面。这样的设计能够适应如下两种需求，复杂度都比较小：1）  查询2010-10，所有cp的http数据。这种需求设置scan的startrow=‘2010-10,http,’，endrow=‘2010-10,http,z’，即可。2）  查询2010-10，cp001的所有协议的数据。这种需求下，根据scan rowkey连续的原则，需要将查询划分成两个scan，分别查询http，cp001的数据和rtsp，cp001的数据。但是，如果将cp放在前面，如下所示，适应性就差一些，如下所示模型二：1）  查询2010-10，cp001的所有协议的数据。这种需求下，设置scan的startrow=‘2010-10,cp001,’，endrow=‘2010-10,cp001,z’，即可。2）  查询2010-10，所有cp的http数据。这种需求下，根据scan的rowkey连续原则，需要将查询分成cp001，http；cp002，http；cp003，http；cp004，http；cp005，http五个查询进行，相对模型一复杂了一些。 2.3.2   业务访问中权重高的key放在前面例如URLRecords表的主要用途是用来计算当天的URL访问排名。根据业务需求，需要访问某天的所有URL，因此date是主键，权重更高，放在前面，而URL则放在后面。如下所示：但是在percontent表中，业务需求是LDS查询某个URL一个时间段内的访问数据，因此date需要放在URL后面，如下所示。 2.3.3   多业务共用rowkey导致数据访问矛盾采用折中取舍或冗余的方法解决同一种key，在满足不同需求的时候可能权重不同。例如3.1.1中讲述的cpid和ServiceType，在遇到不同需求的时候权重不同。但cpid和serviceType是可枚举，数量较少的属性，可以按照3.1.1的方法解决。在一些场景中，有些不可枚举，数量较大的key也存在类似的问题，本节给出几种解决思路。2.3.3.1         寻求折中兼顾的方案例如：Percontent业务，在LDS中，业务需要查询video001，guangdong从2010-10-5~2010-10-20的数据，则rowkey设计成如下形式更为方便：但是，在LDA中，需要聚合每个月的daily数据，声称monthly数据，按照上面的格式，则无法指定一个scan的范围，来启动MR程序将daily数据聚合。但是把时间属性放在前面的话，就非常容易了，如下所示：因此，将时间属性放在前面还是后面，是一对矛盾，在不同场景下，权重不同，各有其适用场景。但是将时间分段，分别放在前后，能够很好的解决这个矛盾，如下所示：2.3.3.2         构造冗余数据例如，percontent表的数据包含了URL Records的数据，URL Records的数据是冗余存储的，区别在于percontent的URL放在date前面，而URL Records表的URL放在date后面。这就是由于URL在满足不同需求的时候，权重不同，由于URL Records需要的数据量不大，因此采用冗余的机制解决该矛盾。2.3.3.3         权衡需求的重要性和系统忍受度选择一种方案当两种需求有矛盾，但其中一方属于次要需求，并且在系统忍受度范围之内的话，可以舍弃一种方案。优先满足需求更强的一方。2.3.4   时间属性在rowkey中的使用如果需要经常访问特定时间段的数据，将时间属性放在rowkey中是一个较好的选择。和利用时间戳来访问特定时间段的数据方法相比，将时间属性放在rowkey中具有可控性，容易将能够同时访问的数据相对集中存放的优点。时间属性放在rowkey中需要注意数据分布和并发度的问题：hbase数据是按照rowkey排序的，时间属性放在rowkey中容易造成数据总是在末尾写入的情况，这种情况下并发度很差。这种情况可以通过在时间属性前面增加prefix和提前预分region的方法解决。2.3.5   循环key使用如果rowkey中有时间属性，并且随着时间的增加，rowkey会不断的增大下去的话，会造成region数量不断地增加。如果使用TTL来控制数据的生命周期，一些老的数据就会过期，进而导致老的region数据量会逐渐减少甚至成为空的region。这样一方面region总数在不断增加，另外一方面老的region在不断的成为空的region，而空的region不会自动合并，进而造成过多空的region占用负载和内存消耗的情况。这种情况下，可以使用循环key的方法来解决。思路是根据数据的生命周期设定rowkey的循环周期，当一个周期过去以后，通过时间映射的方法，继续使用老的过期数据的rowkey。例如，key的格式如下：YY-MM-DD-URL。如果数据的生命周期是一年，则可以使用MM-DD-URL的格式。这样当前一年过去以后，数据已经老化，后一年的数据可以继续写入前一年的位置，使用前一年数据的rowkey。这样可以避免空的region占用资源的情况。根据hbase的原理，key的周期需要至少比TTL大2* hbase.hregion.majorcompaction（默认24小时）的时间，才能够保证过期的数据能够在key循环回来之前得到完全清理。按照时间周期进行建表的方式也可以解决空region的问题，和循环key方法相比较，循环key的优点如下：Ø  操作简单，不需要重复建表，系统自动处理同样，循环key具有如下劣势：Ø  需要使用TTL来老化数据，可能会增加compact负担Ø  需要保证查询操作不会查询到过期数据，否则会影响系统性能。根据以上对比，如果在系统压力不是特别大，需要长期运行，能够控制查询不会查询到过期数据的场景下，建议使用TTL+循环key的方式，否则建议使用按照时间周期进行建表的方式。 2.3.6   通过rowkey设计来控制并发度在相同业务模式下，不同的rowkey设计系统的并发度不一样。和按天建表的思路类似，通过rowkey控制并发度的原则是激活的region总数适中，每个regionserver的激活Region数大于1，小于（写操作内存/flushsize）为宜。为了实现这一点，可以将可枚举、数量有限的属性放在rowkey的前面，时间放在后面的方式来提高并发度；通过将大粒度的时间属性（如天、小时等）放在rowkey前面，数量很大的可枚举属性（如电话号码、URL等）放在后面的方法来控制激活的region数。2.4   Family&Column   2.4.1   可枚举数量少扩展性弱的属性作为Family，不可枚举数量多扩展性强的属性作为column由于Column Family的增、删、改都需要首先disable Table，影响其他Family的正常访问，因此作为Family的属性取值范围要尽量减少扩展。例如ServiceType，当前的取值只有两种http、rtsp，看似比较适合做为Family，但是ServiceType可能会扩展，并不局限于http、rtsp两种，当扩展的时候会影响系统的访问，因此并不推荐作为Family。而是放在rowkey中。而在userequipment表中，设备的纪录纬度为播放器、浏览器、终端三种，不需要扩展，因此适合作为family。如下所示：相对的，具体的浏览器类型、终端类型由于种类比较多，可枚举性差，所以适合放在column中。 2.4.2   对于hbase需求不同分表或者分family每个family有自己独立的属性，例如version和TTL。因此，如果数据对于这些属性需求不同的话，则可以放在不同的family中。例如，相同类型的数据，如trafic、percontent等，时间纬度不同，如daily数据、monthly数据需要保存的时间不一样，因此TTL不同。这种情况下，daily数据、monthly数据可以放在不同的family中或者不同的数据表中。2.4.3   尽量均衡各个store的大小如上一节所述，daily、monthly、hourly数据的TTL不同，可以放在不同的family中。但是这样做的话将会导致同一个reagion不同family的大小差异比较大，出现很多小的或者空的store，导致store数量无端增加。如下所示：由于hbase中，很多内部操作（如flush、compact）的执行单位是store，store的增加会影响系统性能，因此需要尽量避免由于不同family大小失衡导致的大量小store的出现。因此，daily、hourly、monthly数据推荐存放在不同的table中。2.4.4   需要同时读取但数量较多的数据放在同一行的不同column中有些数据，业务需要同时访问，但这些数据比较多，不适合全部打包存放的，可以放在同一个row和family的不同column中。例如，业务需要查询2010-10-10，URL001在中国所有省的访问情况。这种场景下，中国31个省的数据需要同时读取，但是31个省比较多，不适合打包在一个cell里面，可以放在同一行的不同column中，如下所示。这样做可以减少rpc，方便存取。2.5   Value   2.5.1   多数场景下同时存取的数据放在一个cell中一个table中，相同row、family、column的数据为一个cell。多数场景下都需要同时存取的数据可以放在一个cell中。例如，用户访问纪录数据中的属性request，delived，connection，duration等，在LDS端多数场景下需要同时访问，并且这些数据在存储时也是同时写入hbase，因此可以放在一个cell中。这样可以减少rowkey的存放，节省存储空间，提高访问效率。放入一个cell中的数据可以通过protobuf来进行压缩封装。Protobuf提供了数据压缩、存取的接口。例如percontent业务的数据protobuf如下：package com.huawei.ngcdn.md.lda.hbase.protobuf;option java_outer_classname =   "VisitorsInfoProtos";message Visitors {  optional int64 requests = 1;  optional int64   delivered  = 2;  optional int64   internal  = 3;  optional int64   duration  = 4;  optional int64   users  = 5 ;   enum ServiceType {    ALL = 0;    HTTP = 1;    RTSP = 2;  }  optional ServiceType type = 6   [default = ALL];}message VisitorsInfo {       repeated   Visitors visitor = 1;} Requests、delived、internal、duration、users、ServiceType等属性经过protobuf打包压缩后，在hbase中以Byte[]的形式存放，如下所示：                                                                                                                                                       本文转载自华为内部博客，作者：bijieshan