2024HBase RowKey 与索引设计方案

HBaseRowKeyHBase法，第三部分是关于RowKey与索引设计的一些技巧、原则，第四部分是关于OpenTSDB/JanusGraph/GeoMesa典型案例的设计分享。RowKey在读写流程中TableRegion：将表横向切割成一个个子表，从而实现分布式的存储，子表在HBase中称作ColumnFamily：HBaseColumnFamily，不同的ColumnFamily文件被存储在不同的路径中。RegionServer：HBaseRegionRegionServer关于进程角色如下图，主要有ZooKeeper、Master、RegionServer等角色。Meta表的RegionServerFailoverRegionServerHBase有数据文件都存放在HDFS中。我们先来理解一下KeyValue的概念。在HBase中所存储的数据，是以KeyValue形式存在的。KeyValue拥有特定的组织结构，如下图所示。一个KeyValue可以理解成HBase表中的一个列，当一行存在多个列时，将包含多个KeyValue。同一行的KeyValue有可能需要定义用户数据的RowKey，指定每一列所存放的ColumnFamily，并且为其定义相应这就是HBaseSchema-Less的特点。下面介绍KeyValue多版本。HBase中支持数据的多版本，通过带有不同时间戳的多个用户数据存入到HBaseQualifier(KeyValue/Qualifier(KeyValue/列)设HBase1上与关系型数据库的设计是一致，但这种会带来较大冗余(KeyValue结构化开销)。但HBase基于KeyValue图2所示。HBase层感知，HBaseSchemaHBaseSchema绿色背景的KeyValue为后续增加的。关于ColumnFamily，前面提到它是列的集合。每个ColumnFamily里面关联了一个MemStoreHFileColumnFamily时可以考虑用两个ColumnFamily。如下图所示，假设为表设置了两个列族，而且定义每一个列族中要存放的列：{Name}->ColumnFamily-A，{City,Phone,Gender}->ColumnFamily-B不同列族的数据会被存储在不同的路径中。即设置多个列族时一行数据可能存在一行记录。但如果仅仅读取Name一列的话，只需要读取ColumnFamily-A即可。息，然后在Meta中定位每条数据关联的用户Region路径。下面这部分是基于RowKey从Meta表定位关联Region方法，通过一个反向扫描的方式进行。RegionServerWALmemstoreflushRegionSplitRegionSplitRegionRegion。RegionSplitRegionHFileRegionSplitRegionRegionHFile引用文件，子Region1HFileRegion2HFile2Compaction下面是读取流程。当进行读取时，客户端会先发送scan请求到RegionServer，打开scanner，nextResult的Cache中ScannerMemStore，当数据达到一定大小以后再RegionResultScanner对象，每个列族封装成StoreScanner对象，每个StoreScanner里面又有多个HFileMemStoreStoreScannerSegmentScannerStoreFileScanner，这ScannerScanKey值，ScannerKeyScannerKeyValueNextScanScannerNextScannerA-DScanner，当依次Next请求调用时，会判断哪个Scanner的数据是最小的。比如ScannerAKeyValueScannerScanHFileHFileBlockDataBlock64KB，DataBlockKeyValueBlockLeafIndexBlockDataBlock的索引信息存储在LeafIndexBlock中。而LeafIndexBlock的信息存储在RootIndex中(不考虑IntermediateIndexBlockRootIndexBlockLeafIndexBlockLeafIndexBlockLeafIndexBlockLeafIndexBlockLeafIndexBlockLeafIndexBlockDataBlock，以及从DataBlock到用户数据KeyValueBRowKeyRegion，MemStoreRowKeyHFile中的数据按RowKey排序。RowKeyRowKeySplitRowKey查询的局限性。根据下表信息，基于Name+Phone+ID构建RowKey。如果提供的查询条件能够尽可能丰富的描述RowKey的前缀信息，则查询时延越能得到保障。如Name信息，则RowKey的前缀条件是无法确定的，此时只能通过全表扫描的方式来查找结果。一种业务模型的用户数据RowKey，只能采用单一结构设计。但事实上，查询场景可能是多维度的。例如在上面的场景基础上，还需要单独基于Phone列进行查询。这注意：HBaseHBaseKeyValueAPI，可以轻易地构建出二级索引数据。Phoneix提供了两种索引方案，而一些大厂家也都提供Region据量和Region数目的不断增多，查询时延无保障，查询所支持的并发数也会降低。RowKeyRowKey合理地分配到每一个Region中，从而很好地满足业务的读写需求。索引设计目标是为HBase提供更多维度的查询能力，在实际应用中应该通过构建尽量少的索引，来满足更多负载特点指的是读写TPS大小以及读写比重，数据负载均衡与高校读取时常是矛盾的，在重度轻写的大数据场景中，RowKey设计应该更侧重于如何高校读取，而在重写轻读的大查询条件字段的离散度信息？字段离散度是指字段A的离散度等于字段A的划分Region信息。数据生命周期？因为生命周期影响到一个表的一次MajorCompaction首先看一下影响查询性能的关键因素是什么？基于某一个索引/RowKey无论应用是什么样的负载特点，RowKey字段都应该参考最高频的查询场景。数据库通常点，再对选取的RowKey字段值进行改造，组合字段场景下需要重点考虑字段的顺序。RowKeyRowKey好的随机性，此时，可以考虑将RowKey的信息翻转，或者直接将尾部的bytes提前到RowKey的前部。SaltingRowKeybytesbytesRegionsbytesRowKeybytesRegionsSaltingRowKeyHashHashingRowKeyRowKeyReversing类似，HashingScan，因为打乱了原RowKey的自然顺序。方式有Hash分片、Range分片。原理与区别见下图，在实际应用中，两者还可以结合应用。HBase采用了基于RowKey分区的方式。RowKey中已经包含了索引列的信息，该设计容易导致RowKey但该设计需要事先支持Schema，也就是需要事先定义原数据的RowKey结构以及索引的引。即我们应该基于离散度较好的一些列来构建索引。如下图所示，字段ID，PHONE的NAME=”Wang”&&Phone=”1388888”如果基于NAME构建索引，则依然可能构建索引，则可以更精确地命中目标记录，如下图2所示。查询性能可大幅度提升。严格控制二级索引的数量。每一个索引所关联的数据总条数，与用户是1:1的。因此，GlobalIndexLocalIndex查看每一个IndexRegion才能获取到符合条件的完整结果集，这对高并发查询不利。但LocalIndex对于并发分析场景却是有利的。全文检索需求可考虑与Elasticsearch/SolrElasticsearch/Solr但不适合作为数据主存系统，因此，将核心数据存放在HBase中，而通过ES/Solr构建全OpenTSDBJanusGraphGeoMesa设计分析三个案例，将从数据模型、典型查询场景、RowKey设计三个方面介绍。OpenTSDBTimeSeriesName以及一组Tags信息来唯一确定一个TimeSeries。每一条记录成为DataPoint。典型场景分析：给定MetricName以及一组Tags信息，查询某时间范围的所有的DataName,查询所有相关TimeSeries在某时间范围的统计信息。提供的MetricID信息，其他包括Timestamp以及tags信息。EdgeLabelEdgeLabelMultiplicity线查询）如“AA的朋友的朋友中，有哪些拥有本科学历并且在深圳工作？”；基于属性的查询如“姓名为XXX，学历为本科，居住地在深圳龙岗区，年龄在30~40岁左右的人？”Vertex形式存在，因此JanusGraph包含了各色各样的Vertex类型，这些类型在IDPadding部分体现出来。如：000：NormalVertices;010:PartitionedVertices;100:Unmodifiablevertices;101:SchemaTypeVertices;000101:UserPropertyKey;100101:SystemPropertyGeoMesa—数据模型。GeoMesaHBaseGeoMesa据，称之为一个SimpleFeature，SimpleFeature中主要包含如下数据：时间信息、空间Point（Z3）EpochWeek(2bytes)+Point(Z2)Polygon)的时间+空间三维索引(XZ3)EpochWeek(2bytes)+Poly