2024网易HBase 实践方案

网易HBaseHBaseHBaseHBaseRITHBCKHBaseHadoopv是没问题的，通过row-kscan，还是大就衍生出另一个问题HBase适合干啥。第三个就是小规模的scan。些打点数据，最后一个数据来源就是sensor，如工业设备监控产生的数据、CPU或者IO的一些指标数据。这些数据经过数据采集器进入数据存储，数据采集器比如sqoop、datastream（采集日志数据），还有APP的一些sdk。这些数据采集器可以将数据取出来通过kafka、sparkstreaming、flink流到存储系统。存离线存储系统底层存储使用HDFS，基于HDFS之上的数据格式有很多种，比如ORC、个比较重要的存储成员Kudu。除此之外，GPSQL在线存储之外，还有一类存储系统是时序数据库，这类系统比如OpenTSDB、Druid、InfluxDB等。当然，不同模式的存储系统适用于不同的业务场景，比如用离线数据做一些数仓报表、机器学习模型训练等，HBase主要做交易订单、商品优惠券、用户画像等，时HBaseHBaseHBase300+物理机，3PB数据量。应用的业务也非常多，有网易考拉、网易云音乐、网易新闻客户端，还包括很多云服务、大数据服务都是用HBASE做存储。在结合MR和spark做一些机器学习的工作，训练一些模型，这些模型数据通过bulkload导入HBase的HDFS中，然后通过HBase提供在线服务。这类业务有新闻推荐，比如通HadoopHBaseHBaseOpenTSDB？其一是它聚合能力比较差，只能做一些基本的聚合。还有一个就是OpenTSDB的数据采集能力比较弱，因此用HBASE做了哨兵系统。类似OpenTSDB的用法很多，如Kylin，其底层也是用HBase。还有很多图数据库底层也是用HBase，HBase在很多通用的查询底层系统应用很多。HBaseHBaseAPPPush录、日志明细归档、cdn流量及带宽数据、信息安全用户轨迹等等。第三部分讲一下HBCK和RIT相关的知识，HBCK有两部分工作，第一部分工作是做数据部分是完整性的检查。HBCK到唯一一台RegionServer上。其二是region的状态在内存中、hbase:meta表中以及zookeeper这三个地方需要保持一致。表的完整性就是一个rowkey只能存在于一个region里面。HBCK常见的检查命令就是./bin/hbasehbck、./bin/hbasehbck–details、./bin/hbasehbckTableFooTableBar，建议做到表级别，如果集群级别的话，HBCKassign、assignassignRegionServerregion。第二个是修复元数据，主要修复.regioninfo文件和hbase:meta元数据表的不一致。存在，就会在hbase:meta表中添加一条记录。反之如果在HDFS上不存在，而在hbase:meta表中存在，就会将hbase:meta表中对应的记录删除。region区间overlapHDFShbckdetails细了解更多的问题细节，再执行相应的修复命令。但是现实中又很多-repair|、-fix命令导致的，如会导致一个rowkey存在多个region里面去，因此强烈不建议生产线使用。regiondeployregionserver90%只要执行./hbasehbck–fixAssignments就可以解决。如果实在解决不了，再去看打印的region没有deploy到任何regionserver如果在HBCK输出的detail中看到“onHDFS，butnotlistedinhbase：metaordeployedonregionserver”，可以用./hbasehbckfixMetafixAssignments解决。同样看到“thereisaholeintheregionchain”这样的信息先不用处理，执行完上述修复命令再执行HBCK检查是否还有不一致现象。总结下有几个套路，第一个套路如果状态是pending_open（或pending_close）状态的的region通常无法使用hbckfailed_open（或failed_close）regionregionregion处于RIT状态但hbckzk上的region-in-transaction节点相关region删除，重启master就解决了。HBase一旦业务读写响应变慢，写入阻塞，RS来！资源使用情况，队列使用情况，业务相互干扰情况，Compaction情况，GC情况。去排查下regionserver监控，如regionserver队列长度、rpc等情况，需要真正排查regionserver生的，这个时候就需要表级别的监控。如表级别的读写，GPS等，这种就知道是那种业务监控只会告诉你发生问题但是不能告诉你为什么。这时就需要日志分析，masterDDLbalance，snapshotHBase的开发运维，热衷于MySQL等相关数据库技术。如下方向：时序数据库研发工程师，MPP数据仓库存储引擎研发工程师，大数据开发工程师，Base\h云上HBase作者：郭泽晖整理：HBase应该如何实现，最后介绍下HBase在云端的实现方案。1.xSSD的配置，负责在线查HBaseHDFSDataNode可以指定表写在冷介质还是热介质上，最后在HDFS上可以依据你设置在文件上的属性决定是将数据放在机械盘还是SSD上。这样一个集群可以存在冷表和热表，这样相对于1.X因此在云端解决方案是一个比较弹性的方案，在介绍之前先介绍下我们云端HBase。云HBase是一个存储计算完全分离的架构，底层是存储，今天主要讲冷存储，云端regionserver访问部署的节点，磁盘都是远程读的。因此磁盘大小是可以动态设置的，完全弹性。多模式是HBase云端之上除了HBase本身kv功能，还架设很多开源组件，如如伪造车祸骗取保险，而图可以分析一个关系网，能够预防这种情况。openTSDB主要是物联网、车联网这些场景使用，geospatial是时空数据库，主要应用在轨迹场景。底下存储层主要是有两块，热数据或一般数据会放在云盘，冷数据是放在OSS。整个模式是一个上，同一个集群也能实现冷表和热表。OSS是阿里的一个对象存储产品，也是一个k-v存低。成本和云盘对比，云盘本身也保证数据可靠性，在云上自建HBase、HDFS用两副本如果在阿里云上使用OSS作为Bseadop社区NtveOslesemlesemS上，也可以享受OS低成本特性。但是存在几个问题，一个是NiveOsesem针对的是pReduce因为OS是-v一字符。如果要模拟文件系统创建“oo/pen/onfe”,你需要创建图中右边四个对otpaent”rootNativeOssFileSystem的过程，如果server在mv操作时中途crash只会移走一部分，导致目录文件不一致。放在HDFS上，在APP调用HadoopFileSystem实际是调用ApsaraDistributedFileSystem，这个实现会控制你的文件调用OssFileSystem就将其放到OSS里面，调ApsaraFileSystemHadoopHDFSHadoop个文件存储也是保证原子的。读取冷文件时将读的通道转发到OSS上，然后构建一个OSSinputstream和OSSoutputstream。性能上和社区版比较也做了一些优化，实现上会有一些限制，请求OSS是有费用的，HadoopFileSystemOutputStreamwrite去，OSSsdkInputStreamHadoopfilestreamOSSOutputStreamInputStreamnativeOSSOutputStreambuffer128M将其包装成fileInputStream提交给OSS的SDK，会有一个异步线程池来提交buffer文件。这样存在的问题是写入过程需要入磁盘，会损耗性能；第二比较依赖磁盘性能，异步发送buffer会变成一个单线程；crash会残留这些文件，对运维比较麻烦。我们实现版本写入是不在磁盘落地，中间会有一个ringbuffer（只有几M），用户写入到ringbuffer里，里面由固定数量配置组成，有5个配置。蓝色是写入，绿色有一个异步线inputstream，相当于实时源源不断类似于流的形式。每当inputstream被OSS的SDK读完128M，将数据提交，然后再有数据写入再包装成inputstream128M磁盘，占用内存开销也很少。性能测试写入吞吐差25%，我的valuesize只有100B。在HBase使用这个特性，建表的时候配一下config，create'test',{NAME=>'info'},CONFIGURATION=>{'HFILE_STORAGE_POLICY'=>'COLDOSS偶尔读