Architecting HBase Applications-O'Reilly 2016（笔记）最有趣的部分就是Key如何设计了

Architecting HBase Applications

What is HBase？

HBase原则

1. Table布局：null值不存储，列簇（cf）不需要预先定义
2. Table存储：region > cf > 1 memstore + * hfile > blocks
   1. region由RegionServers管理（也就是说不存在真正聪明的分布式hash数据切分）
   2. 严格的水平切分（cf不宜太多，会导致很多小文件），这种情况下感觉更像是一个分布式K-V数据库？
      1. 感觉主要还是底层的分布式存储引擎太弱了（不过复杂性有会导致不可靠性）
   3. 4种block类型：
      1. 数据
      2. 索引
      3. Bloom filter
      4. Trailer
   4. Cells
      1. 块编码（基于与前一个key的diff？）
      2. 一系列最大长度限制
3. 内部表操作
   1. 压缩（Compaction，有点类似于GC的概念）
      1. Minor（HBase的存储是基于immutable快照的，记录在逻辑删除时仅仅只是标记一下，只有当被compact操作时才真正删除）
         1. 与cell version count的关系
      2. Major
   2. 分割（Splits，Auto-sharding）
      1. 基本上是基于key的值区间的，=> 所以数值key最好先做一个MD5哈希？
      2. 所有的columns都会留在相同的region里：再次强调，HBase是‘严格的水平分片’！
      3. 所有的cf都会同样切分（为了保证访问单个key的所有columns时的局部性？）
   3. 平衡（Balancing）
      1. 0.96+ StochasticLoadBalancer
      2. 开发自己的（应用特定的？）balancer？
4. HBase Roles
   1. Master（性能要求不高，但要求可靠性） + RS（IO性能要求高）
   2. Thrift/REST Server

HBase生态系统

1. 监控工具
   1. Cloudera Manager
   2. Apache Ambari
   3. Hannibal
2. SQL on Hadoop/HBase
   1. Apache Phoenix
   2. Apache Trafodion
   3. Splice Machine
   4. Honorable Mentions (Kylin, Themis, Tephra, Hive, and Impala)
3. Frameworks
   1. OpenTSDB
   2. Kite
   3. HappyBase（Python绑定）
   4. AsyncHBase

Sizing and Tuning Overview

1. 0.96 bucket cache（SSD）
   1. 应当在0.98.6+上使用，due to HBASE-11678

环境Setup

实现一个底层（记录）存储引擎

1. Omneo，Avro，Bulk load，Solr Cloud on Hadoop？
2. create 'sensors', {NUMREGIONS => 15, SPLITALGO => 'HexStringSplit'}, \ （注意这里对原始的id进行了MD5哈希）

   {NAME => 'v',

   COMPRESSION => 'SNAPPY',\

   BLOOMFILTER => 'NONE',\

   DATA_BLOCK_ENCODING => 'FAST_DIFF'}

3. HFile Validation
   1. hbase hfile -printmeta -f ch07/hfiles/v/345c5c462c6e4ff6875c3185ec84c48e
4. Data Validation
   1. 记录数：hbase(main):003:0> count 'sensors', INTERVAL => 40000, CACHE => 40000
      1. 或 hbase org.apache.hadoop.hbase.mapreduce.RowCounter sensors
   2. File Content
      1. scan 'sensors', {COLUMNS => ['v'], STARTROW => '000a', LIMIT => 1 }
   3. Data Indexing
      1. solrctl？
   4. Data Retrieval
      1. CloudSolrServer solr = new CloudSolrServer("localhost:2181/solr");
      2. 。。。

用例：近实时的事件处理

1. 作者老喜欢批评Cassandra缺乏生态系统支持，tmd
2. Kafka/Storm/Flume？
   1. ... we will use a Kafka queue as our Flume channel.
   2. Flume Interceptor：XmlToAvro？
3. Lily Indexer？
4. append the customer or insurance ID at the end of the MD5...
5. DocumentID：不作为组合key的一部分（不同row可能在不同的region！），而是直接在column上存储Document内容的多个版本
   1. 上限估计：10000 * 10KB Avro记录 = 100MB，而HBase region可以很容易增加到10GB（还能承受？）
6. Morphlines脚本？skip
7. UniformSplit？
8. alter 'documents', { NAME => 'c', COMPRESSION => 'GZ' }

用例：作为数据管理工具

1. Spark with/over HBase？

用例：文档存储

1. HBASE-11339 MOB：‘写放大’问题 => 当刷新memstore时，仅其引用被写到HFile（专门的MOB区域）
   1. http://blog.cloudera.com/blog/2015/06/inside-apache-hbases-new-support-for-mobs/
2. RDBMS需要SSD，而HBase只需要SDATA，所以开销更低？？？
3. 一致性：保证数据放在一个row里面（一次Put完成），抛弃cross-ref？

问题解决：Too many regions

1. the more regions there are, the smaller the memstore flushes will be（更小的HFile）
2. 原因：
   1. Maximum region size set too low
   2. Configuration settings not updated following an HBase upgrade
   3. Accidental configuration settings
   4. Over-splitting
   5. Improper presplitting
3. 解决方案：
   1. 0.98-：
      1. CopyTable？
         1. Kafka and Flume可配置为暂停数据Ingest？
      2. Offline merges（集群必须完全下线）
   2. 0.98+：HBASE-7403 online merge
4. 预防
   1. Regions Size：最大size设置为最少10GB
   2. Key and Table Design（降低cf）

问题解决：Too many 列簇

1. 每个cf会被flush到一个HFile里，但共享同一个memstore！
2. Split：基于目录的均衡？（split操作不会分布到另一个RS上去吧？还是说这里的目录是HDFS上的虚拟逻辑概念？）
3. 删除cf：alter 'sensors', NAME => 'picture', METHOD => 'delete'
4. 合并cf：CopyTable，源和目标可以是同一个？
   1. hbase org.apache.hadoop.hbase.mapreduce.CopyTable --new.name=customer --families=address:profile customer
      1. 合并多个cf到一个：--families=address:profile,phone:profile,status:profile
5. 分隔cf到新表（都是通过数据复制来实现的！）
   1. hbase org.apache.hadoop.hbase.mapreduce.CopyTable --families=picture --new.name=map customer

问题解决：Hotspotting（热点）

1. 我觉得热点问题才是HBase的核心疑难问题，应用特定的数据总是有可能导致不均匀的hash分布的
2. 原因：key design？
   1. Small Reference Tables（例如postcode-city关联映射表）：直接冗余存储到引用表中去
      1. 也可预先直接加载到内存常驻
      2. 如果有update需求，则最好一开始就想好怎么presplit！
   2. 如果数据是均匀分布的，=> Applications Issues？
   3. Meta Region Hotspotting：创建一个到ZooKeeper的单连接

问题解决：超时与GC

1. RS没有来得及向ZooKeeper作HeartBeat报告，YouAreDeadException
2. 原因
   1. Java平台上，memory fragmentation（内存碎片）是GC和pause的主要原因（由于不一样的object size）
   2. Storage Failure
   3. Power-Saving Features
   4. Network Failure
3. 避免
   1. Reduce Heap Size（靠？）
      1. 默认设置：<20G，CMS
   2. Off-Heap BlockCache（BucketCache）：允许HBase自己管理碎片？
   3. 使用G1GC：内存根据不同size作regions分类，garbage first，允许HBase更大的memstore（从而提高性能）
      1. -XX:+UseG1GC
      2. -XX:+PrintFlagsFinal
      3. -XX:+PrintGCDetails
      4. -XX:+PrintGCDateStamps
      5. -XX:+PrintGCTimeStamps
      6. -XX:+PrintAdaptiveSizePolicy
      7. -XX:+PrintReferenceGC
   4. 附加选项（当内存超过100G）
      1. -XX:-ResizePLAB
      2. -XX:+ParallelRefProcEnabled
      3. -XX:+AlwaysPreTouch
      4. -XX:MaxGCPauseMillis=100
   5. 其他的有趣参数
      1. -XX:ParallelGCThreads=X 公式：8 + (logical processors – 8) (5/8)
      2. -XX:G1NewSizePercent=X
      3. -XX:+UnlockExperimentalVMOptions
      4. -XX:G1HeapWastePercent=5
      5. -XX:G1MixedGCLiveThresholdPercent=75
   6. Configure Swappiness to 0 or 1
   7. Disable Environment-Friendly Features（电源管理）
   8. 硬件冗余

问题解决：HBCK与不一致状态

1. hbase(main):002:0> describe 'hbase:meta'
2. -bash-4.1$ hadoop fs -ls -R /hbase/data/default/odell/3ead...
3. -bash-4.1$ sudo -u hbase hbase hbck
   1. 下略