一种医疗大数据存储中Hbase行键的编码及压缩方法

摘要

一种医疗大数据存储中Hbase行键的编码及压缩方法，包括：第一，对查询条件的编码压缩，根据用到的查询条件，判断查询条件用到的值域是否固定，分别进行编码，直至所有的查询条件编码完成，将所有输出的压缩码拼接成新的字符，作为业务数据的行键将业务数据存放到Hbase表中；第二、查询过程，根据用到的查询条件，判断查询条件用到的值域是否固定，分别进行编码，将所有查询条件转换后到Hbase中查询业务数据。本发明有效控制行键长度、适应数据量的大幅增大，满足一定的基于多条件查询。

权利要求

1.一种医疗大数据存储中Hbase行键的编码及压缩方法，其特征在于：所述方法包括：第一，对查询条件的编码压缩，过程如下：

步骤1.1、根据用到的查询条件，判断查询条件用到的值域是否固定，如果是固定值域，执行步骤1.2，否则执行步骤1.3和1.4；

步骤1.2、公共字典表中查找对应的编码是否存在，如果存在则返回对应的ID压缩码，否则将字典类别发给ID生成服务，将ID生成服务返回的ID编码生成ID压缩码，存入公共字典，返回ID压缩码；公共字典在Hbase中的结构为4位的字典类别代码、字典压缩包和描述；

步骤1.3、将值域拆分为前缀+后缀的形式，根据拆分后的前缀和业务编码到域表中查找对应的记录，如果存在则返回该前缀的ID压缩码，否则将业务编码发给ID生成服务，将ID生成服务返回的ID编码生成ID压缩码，存入域表中，返回前缀ID压缩码；域表的结构为编码前缀、固定宽度的业务编码、压缩码列和前缀ID压缩码；

步骤1.4、根据后缀和业务编码到码表中检索对应的记录，如果存在则返回压缩码，否则将业务编码发给ID生成服务，将ID生成服务返回的ID编码生成ID压缩码，存入码表中，返回后缀ID压缩码；码表的结构为编码后缀、固定宽度的业务编码、压缩码列和后缀ID压缩码；

步骤1.5、重复执行步骤1.1至步骤1.4，直至所有的查询条件编码完成，将所有输出的压缩码拼接成新的字符，作为业务数据的行键将业务数据存放到Hbase表中；

所述步骤1.3和1.4中，将业务编码发给ID生成服务，将ID生成服务返回的ID编码生成ID压缩码中，将前缀编码和业务编码作为行键放到域表中，使用ID生成服务根据业务编码生成编码序列——编码ID，再对编码ID生成前缀ID压缩码；

同样，将后缀编码和业务编码作为行键放到码表中，使用ID生成服务根据业务编码生成编码序列——编码ID，再对编码ID生成后缀ID压缩码；

最终，将原始编码转换的结果为：前缀ID压缩码+后缀ID压缩码；

所述步骤1.2、1.3和1.4中，将ID生成服务返回的ID编码生成ID压缩码中，使用长整型对行键中的信息进行编码，编码字符选择ASCII码中的可打印字符，并将数值型字串转换为字符型字串进行压缩。

2.如权利要求1所述的医疗大数据存储中Hbase行键的编码及压缩方法，其特征在于：所述方法还包括：第二、查询过程，如下：

步骤2.1、根据用到的查询条件，判断查询条件用到的值域是否固定，如果是固定值域，执行步骤2.2，否则执行步骤2.3和步骤2.4；

步骤2.2、根据字典类别和查询条件到公共字典表中查找对应的记录，返回压缩码；

步骤2.3、将值域拆分为前缀+后缀的形式，根据拆分后的前缀和业务编码到域表中查找对应的记录，返回前缀ID压缩码；

步骤2.4、根据拆分后的后缀和业务编码到码表中查找对应的记录，返回后缀ID压缩码；

步骤2.5、根据步骤2.2、步骤2.3、步骤2.4返回的压缩码到Hbase中查询业务数据，如果是多条件查询，重复步骤2.1至步骤2.4，将所有查询条件转换后到Hbase中查询业务数据。

3.如权利要求1或2所述的医疗大数据存储中Hbase行键的编码及压缩方法，其特征在于：所述步骤1.1和2.1中，判断值域是否固定，判断的依据是(1)、其值是否可枚举；(2)、该信息编码跨系统、跨机构是否统一；

对于固定值域，使用公共字典对其编码，编码从1开始依次递增；不同类别的信息各自编码；

对于不固定的值域使用域码表对其进行编码，编码也是从1开始依次递增，不同域的字典各自编码。

说明书

一种医疗大数据存储中Hbase行键的编码及压缩方法

技术领域

[0001] 本发明属于医疗数据存储领域，尤其涉及一种医疗大数据存储中Hbase行键的编码及压缩方法。

背景技术

[0002] 随着云存储、云计算的技术飞跃发展，面向医疗大数据存储的技术研究越来越热，在将医院的历史数据进行整合并集中存储到Hbase过程中，我们必须面对的首要问题是如何将医院数据的唯一标识即主键，使用一定的编码规则生成符合Hbase行键规范要求的唯一标识，原因是Hbase的行键Rowkey的长度不能太长，如果太长，如100个字节，那么区区1000万条数据的行键就要消耗将近占1G的内存空间，同时Hbase只有通过行键进行查询，才能高效率的返回结果，鉴于医疗行业的复杂性，只有将Hbase的行键设计成满足多条件查询才能满足实际的场景需求，加上各家医院的业务数据的唯一标识规范不一致，有些是纯数值型的序列，有些是字母、数字的混合编码，还有些干脆是全局唯一标识符(GUID)。这些都增加了Hbase行键编码设计的难度。

[0003] 为了提高Hbase的查询效率，绕开Hbase行键设计上的障碍，大数据技术专家们想到了很多的技术方案，申请号为201410336964.3的《一种海量数据查询方法》采用SolrCloud和HBase相结合的方法，将HBase非行键值rowkey查询字段与rowkey的索引映射关系维护到SolrCloud中，通过在SolrCloud中查询到查询字段对应的rowkey来实现高效的查询，这样行键的设置就没有了诸多的障碍，该技术方案的实现依赖于SolrCloud。

[0004] 申请号为201310667847.0的《一种基于HBase表的条件查询优化方法》采用Region预分配、RowKey设计及MapReduce来提高性能，在实现过程中，通过设定的查询条件以及预分配的Region来确定RowKey，这样通过明确的StartKey和EndKey就能实现快速查找，该方案适合通过job进行批量导入数据的应用场景。

[0005] 申请号为201310403001.6的《一种数据存储方法及装置》这个技术方案中的行键使用前缀+后缀的方式，前缀使用算法MD5计算出所述满足预设条件的属性字段的摘要值，后缀长度固定为9个字节，是由一个“＝”和8字节表示的long整数组成，这样行键的长度就不能进行有效的控制，对内存的有效利用不是很好。

[0006] 申请号为201210147725.4的《基于Hbase数据库的倒排索引混合压缩及解压方法》该技术方案对Hbase数据库倒排索引数据表中的键部分采用键既字典压缩法进行压缩，即对行键通过字典查找法进行压缩，除此以外还对数据值部分进行压缩。方案提出的针对Hbase数据库下特定的倒排索引表的混合压缩方法具有很高的即时性，可以满足搜索引擎对于即时响应的要求。但是，由于Hbase数据库在源码中只给出了Lzo算法和Gzip算法的选项，因此为了在Hbase中能够使用该方法，必须对Hbase源码修改，同时需要给出本方法的Java调用接口。

[0007] 申请号为201610177721.9的《HBase二级索引的设计方法及查询方法》根据一数据源文件的数据量对HBase中的一数据表进行预分区，得到特定数量的区域，然后每个所述区域划分为主数据区和关联于所述主数据区的索引区，在索引区中的行键设为区域起始行键|索引列|索引键|索引值的形式。主数据区域的行键通过随机产生的Hash前缀(作为索引区域行键的前缀)来建立主数据区域和索引区域的关联关系，这种方案生成的行键长度也不能有效的控制，数据量增大的时候，会很快消耗掉内存空间。

发明内容

[0008] 为了克服已有医疗数据存储方式的行键长度不能有效的控制、内存空间无法适应数据量的大幅增大的不足，本发明提供了一种有效控制行键长度、适应数据量的大幅增大的医疗大数据存储中Hbase行键的编码及压缩方法。

[0009] 本发明解决其技术问题所采用的技术方案是：

[0010] 一种医疗大数据存储中Hbase行键的编码及压缩方法，所述方法包括：

[0011] 第一，对查询条件的编码压缩，过程如下：

[0012] 步骤1.1、根据用到的查询条件，判断查询条件用到的值域是否固定，如果是固定值域，执行步骤1.2，否则执行步骤1.3和1.4；

[0013] 步骤1.2、公共字典表中查找对应的编码是否存在，如果存在则返回对应的ID压缩码，否则将字典类别发给ID生成服务，将ID生成服务返回的ID编码生成ID压缩码，存入公共字典，返回ID压缩码；

[0014] 步骤1.3、将值域拆分为前缀+后缀的形式，根据拆分后的前缀和业务编码到域表中查找对应的记录，如果存在则返回该前缀的ID压缩码，否则将业务编码发给ID生成服务，将ID生成服务返回的ID编码生成ID压缩码，存入域表中，返回前缀ID压缩码；

[0015] 步骤1.4、根据后缀和业务编码到码表中检索对应的记录，如果存在则返回压缩码，否则将业务编码发给ID生成服务，将ID生成服务返回的ID编码生成ID压缩码，存入码表中，返回后缀ID压缩码；

[0016] 步骤1.5、重复执行步骤1.1至步骤1.4，直至所有的查询条件编码完成，将所有输出的压缩码拼接成新的字符，作为业务数据的行键将业务数据存放到Hbase表中。

[0017] 进一步，所述方法还包括：第二、查询过程，如下：

[0018] 步骤2.1、根据用到的查询条件，判断查询条件用到的值域是否固定，如果是固定值域，执行步骤2.2，否则执行步骤2.3和步骤2.4；

[0019] 步骤2.2、根据字典类别和查询条件到公共字典表中查找对应的记录，返回压缩码；

[0020] 步骤2.3、将值阈拆分为前缀+后缀的形式，根据拆分后的前缀和业务编码到域表中查找对应的记录，返回前缀ID压缩码；

[0021] 步骤2.4、根据拆分后的后缀和业务编码到码表中查找对应的记录，返回后缀ID压缩码；

[0022] 步骤2.5、根据步骤2.2、步骤2.3、步骤2.4返回的压缩码到Hbase中查询业务数据，如果是多条件查询，重复步骤2.1至步骤2.4，将所有查询条件转换后到Hbase中查询业务数据。

[0023] 再进一步，所述步骤1.1和2.1中，判断值域是否固定，判断的依据是(1)、其值是否可枚举；(2)、该信息编码跨系统、跨机构是否统一；

[0024] 对于固定值域，使用公共字典对其编码，编码从1开始依次递增；不同类别的信息各自编码；

[0025] 对于不固定的值域使用域码表对其进行编码，编码也是从1开始依次递增，不同域的字典各自编码。

[0026] 所述步骤1.3和1.4中，将业务编码发给ID生成服务，将ID生成服务返回的ID编码生成ID压缩码中，将前缀编码和业务编码作为行键放到域表中，使用ID生成服务根据业务编码生成编码序列——编码ID，再对编码ID生成前缀ID压缩码；

[0027] 同样，将后缀编码和业务编码作为行键放到码表中，使用ID生成服务根据业务编码生成编码序列——编码ID，再对编码ID生成后缀ID压缩码；最终，将原始编码转换的结果为：前缀ID压缩码+后缀ID压缩码。

[0028] 所述步骤1.2、1.3和1.4中，将ID生成服务返回的ID编码生成ID压缩码中，使用长整型对行键中的信息进行编码，编码字符选择ASCII码中的可打印字符，并将数值型字串转换为字符型字串进行压缩。

[0029] 所述ASCII码中的可打印字符，筛选结果为90个字符，如表1所示：

[0030]# $ ％ & ( ) * + , -
. / 0 1 2 3 4 5 6 7
8 9 : ； < ＝ > ？ @ |A
B C D E F G H I J K
L M N O P Q R S T U
V W |X Y Z [ ] ^ _ `
a b c d e f g h i j
k l m n o p q r s t
u v w x y z { | } ～

[0031] 表1。

[0032] 对数值型的编码ID压缩的过程为：首先将附表1里面的字符依照顺序依次填充到一个长度为90的字符数组array1中；然后对编码ID分别取90的模k和整除90的结果n，到字符数组array1中找k处的字符，数组是从0开始编号的，数组位置0存放的是码表第1个字符，数组位置m存放的是码表第m+1个字符，再对n分别取90的模k和整除90的结果,将整除90的结果赋值给n，取字符数组array1的k处字符，如此重复操作，直至n小于90，最后取数组array1的位置n处的字符，依次将取到的所有字符整合成字符串，即完成编码ID的压缩。

[0033] 本发明的有益效果主要表现在：实现对任意长度的信息进行编码、压缩，压缩后的行键长度不受原始信息的编码长度影响；除了使用现有的数据库系统作为ID生成服务，方案的实施几乎不依赖任何第三方产品的支持；支持少量的多条件查询，同时也支持Hbase的前匹配查询，查询性能足以满足日常的查询要求。

附图说明

[0034] 图1是医疗大数据存储中Hbase行键的编码及压缩方法的流程图。

[0035] 图2是对子串的编码流程图(编码ID为长整型的数字)。

[0036] 图3是使用90个字符对子串编码压缩的流程图(％表示取模运算，/标识整除运算)。

具体实施方式

[0037] 下面结合附图对本发明作进一步描述。

[0038] 参照图1～图3，一种医疗大数据存储中Hbase行键的编码及压缩方法，所述方法包括：

[0039] 第一，对查询条件的编码压缩，过程如下：

[0040] 步骤1.1、根据用到的查询条件，判断查询条件用到的值域是否固定，如果是固定值域，执行步骤1.2，否则执行步骤1.3和1.4；

[0041] 步骤1.2、公共字典表中查找对应的编码是否存在，如果存在则返回对应的ID压缩码，否则将字典类别发给ID生成服务，将ID生成服务返回的ID编码生成ID压缩码，存入公共字典，返回ID压缩码；

[0042] 步骤1.3、将值域拆分为前缀+后缀的形式，根据拆分后的前缀和业务编码到域表中查找对应的记录，如果存在则返回该前缀的ID压缩码，否则将业务编码发给ID生成服务，将ID生成服务返回的ID编码生成ID压缩码，存入域表中，返回前缀ID压缩码；

[0043] 步骤1.4、根据后缀和业务编码到码表中检索对应的记录，如果存在则返回压缩码，否则将业务编码发给ID生成服务，将ID生成服务返回的ID编码生成ID压缩码，存入码表中，返回后缀ID压缩码；

[0044] 步骤1.5、重复执行步骤1.1至步骤1.4，直至所有的查询条件编码完成，将所有输出的压缩码拼接成新的字符，作为业务数据的行键将业务数据存放到Hbase表中。

[0045] 进一步，所述方法还包括：第二、查询过程，如下：

[0046] 步骤2.1、根据用到的查询条件，判断查询条件用到的值域是否固定，如果是固定值域，执行步骤2.2，否则执行步骤2.3和步骤2.4；

[0047] 步骤2.2、根据字典类别和查询条件到公共字典表中查找对应的记录，返回压缩码；

[0048] 步骤2.3、将值阈拆分为前缀+后缀的形式，根据拆分后的前缀和业务编码到域表中查找对应的记录，返回前缀ID压缩码；

[0049] 步骤2.4、根据拆分后的后缀和业务编码到码表中查找对应的记录，返回后缀ID压缩码；

[0050] 步骤2.5、根据步骤2.2、步骤2.3、步骤2.4返回的压缩码到Hbase中查询业务数据，如果是多条件查询，重复步骤2.1至步骤2.4，将所有查询条件转换后到Hbase中查询业务数据。

[0051] 本发明中，对于满足多条件查询的Hbase行键编码，编码在保证唯一的基础上需要整合各查询的条件，如需根据医院查询，就要将医院编码整合到行键中，如需根据时间范围查询，就要将时间整合到行键中，如果有n个常用查询条件，行键就应当包含n个字符串，即s1s2...sn。当然由于行键长度的限制，不能满足随意的查询条件组合，必须事先明确查询用到的那些条件，并仔细筛选，对于过多的查询条件，可以考虑使用二级索引的方法。

[0052] 为了限制行键的增长，技术方案的关键在于如何对整合的信息进行编码、压缩，对此本技术方案使用字典对行键中的信息进行编码，并通过一定的压缩算法进行编码压缩。

[0053] 我们注意到64位的长整型可以表示最大值为9,223,372,036,854,775,807。使用长整型可以满足目前绝大部分业务场景的存储需求，本方案中使用长整型对行键中的信息进行编码，但如果设计的行键需要满足多条件的查询，长整型的数值不能直接用于Hbase的行键，还需要经过压缩处理，本方案使用将数值型字串转换为字符型字串的方法进行压缩。方案选择ASCII码中的可打印字符，并进行一定的筛选，去除编程语言中用到的单引号、双引号、反斜杠，此外还要保留惊叹号作为固定行键长度场景下的填充字符，最后筛选的结果一共有90个字符，如表1所示：

[0054]# $ ％ & ( ) * + , -
. / 0 1 2 3 4 5 6 7
8 9 : ； < ＝ > ？ @ |A
B C D E F G H I J K
L M N O P Q R S T U
V W |X Y Z [ ] ^ _ `
a b c d e f g h i j
k l m n o p q r s t
u v w x y z { | } ～

[0055] 表1

[0056] 判断该子串的值域是否固定，判断的依据是1、其值是否可枚举，比如患者的血型代码，它的值域是固定的；2、该信息编码跨系统、跨机构是否统一，比如患者的身份证、手机号码，我们也将其当作固定值域来对待。对于固定值域，我们使用公共字典对其编码，编码从1开始依次递增；不同类别的信息各自编码，编码使用独立的编码服务，即ID生成服务。注意此处还有一个标准的对照、转换过程，对于不同的代码，但表示的意义相同，字典复用相同的编码(对照转换的过程不在本方案的描述范围之内)。公共字典在Hbase中的结构如表2所示：

[0057]

[0058] 表2

[0059] 对于不固定的值域我们使用域码表对其进行编码，编码也是从1开始依次递增，不同域的字典各自编码。由于不同的医疗系统的厂商编码规则不同，需要根据具体情况做相应的处理，处理起来比较复杂，总体来说归纳为3种类型，1是直接使用序列，2是使用混合编码如日期+序列、具有一定意义的代码+序列，这种情况比较多见，3使用全局唯一标识符(GUID)，GUID不适合放在Hbase的行键中，因为无论怎么压缩都会占很大的存储空间，而且实际操作中也没有通过输入GUID来查询数据的情况，遇到使用GUID作为编码的情况一般是尝试使用其它字段即候选键替换，如果找不到候选键，需要医疗业务厂商配合添加一个候选键如自增的序列，GUID编码不在本方案考虑范围之内。域码表分为两个部分，域表和码表。

[0060] 在Hbase中的域表的结构如下表3所示:

[0061]

[0062] 表3

[0063] 码表的结构如表4所示：

[0064]

[0065] 表4

[0066] 使用编码、压缩后的业务数据行键结构如表5所示：

[0067]

[0068] 表5

[0069] 不管医疗管理系统的内部编码是序列还是混合的编码形式，只要编码排序后可拆分为前缀+后缀的形式，并且前缀的变化相对固定，后缀的变化有一定的规律，均可使用本方技术方案进行压缩，对于连续编码的数值型前缀或后缀，直接对其进行压缩的效果与使用ID生成服务生成编码ID后再对编码ID进行压缩的效果相同，考虑到通用性，本方案统一使用ID生成服务生成编码前缀的编码ID和后缀的编码ID。

[0070] 方法是，将前缀编码和业务编码作为行键放到域表中，使用ID生成服务根据业务编码生成编码序列——编码ID，再对编码ID运用图3的流程生成前缀ID压缩码。

[0071] 参照图3，对数值型的编码ID压缩的流程为：首先将表1里面的字符依照顺序依次填充到一个长度为90的字符数组array1中；然后对编码ID分别取90的模k和整除90的结果n，到字符数组array1中找k处的字符，数组是从0开始编号的，数组位置0存放的是码表第1个字符，数组位置m存放的是码表第m+1个字符，再对n分别取90的模k和整除90的结果,将整除90的结果赋值给n，取字符数组array1的k处字符，如此重复操作，直至n小于90，最后取数组array1的位置n处的字符，依次将取到的所有字符整合成字符串，即完成编码ID的压缩。

[0072] 同样，将后缀编码和业务编码作为行键放到码表中，使用ID生成服务根据业务编码生成编码序列——编码ID，再对编码ID运用图3的流程生成后缀ID压缩码。

[0073] 最终，将原始编码转换的结果为：前缀ID压缩码+后缀ID压缩码。

[0074] 假设压缩后前缀ID的压缩码为4个字符长度，后缀偏移压缩码为4个字符长度，那么8个字符的行键可以表示90×90×90×90×90×90×90×90-1＝4304672099999999个不同的数据。对于公共字典的压缩码，如身份证，使用5个字符表示全国所有的身份证号码或手机号码绰绰有余，再如全国的行政区划编码，原始编码使用6个数字字符表示，而使用公共字典的压缩码只要2个字符表示即可。所以正常应用的情况下，本设计方案可以满足3至4个查询条件组合，足以满足日常的查询需求。

[0075] 关于ID生成服务，ID生成服务根据不同的字典类别和业务类别各自维护一套自增的序列，ID生成服务只要根据字典类别或业务类别各自简单的自增即可。可以用现有的数据库系统如redis实现或自行实现ID生成服务，如何自行实现ID生成服务不在本发明文档的描述范围之内。

[0076] 对固定值域编码、压缩案例：假设需要通过患者身份证(每次就诊患者都必须提供身份证)、就诊日期，检查患者的就诊记录。

[0077] 首先，明确查询条件组合是否能唯一识别一条诊疗记录，实际情况下，同一患者同一天在同一家医院可以到两个以上的科室进行就诊，但不会在同一个科室就诊两次(两次就诊视为同一个就诊行为)。为了简化起见此处不考虑跨医院的情况，那么可以唯一确定单次就诊记录的查询条件可以确定为：患者身份证号、就诊日期、就诊科室。

[0078] 其次，判断患者身份证号、就诊日期、就诊科室的值域是否固定，很明显，患者身份证号、就诊日期、就诊科室的值域都是是固定的，本案例中使用基于公共字典的编码压缩方法。

[0079] 最后定制身份证、日期(年月日)、科室类别压缩码的宽度，中国最大的两个城市上海和北京的总人口都在2千万左右，理论上说身份证压缩码的宽度只要4个字符宽度就足够国内任何一个地区使用了(90*90*90*90-1＝65609999)，但为了保守起见，我们使用5个字符的宽度表示身份证压缩码；对于日期(年月日)的压缩码，使用4个字符的宽度；对于门诊科室，使用2个字符的宽度。

[0080] 编码、压缩的步骤如下：

[0081] 步骤一、根据字典类别到公共字典表中查找是否存在对应的身份证编号、日期或科室代码(以下统一称为原始编码)，如果存在则返回对应的压缩码，否则执行步骤二至步骤四；

[0082] 步骤二、将原始编码和对应的字典类别发到ID生成服务，请求新的ID[0083] 步骤三、ID生成服务根据字典类别生成新的ID(ID的类型为正整数)。

[0084] 步骤四、将ID生成服务返回的ID通过图3的流程进行压缩，将压缩码、原始编码、字典类别一同存入公共字典中，返回压缩码；

[0085] 步骤五、对返回的压缩码使用惊叹号(！)进行填充使达到定制的字符宽度，为了避免Hbase的热点问题、作为构成行键的第一个压缩码需要进行反转，然后再将惊叹号(！)填充到该压缩码的后面，返回定制宽度的压缩码。

[0086] 步骤六、重复执行步骤一至步骤五，直至身份证编号、日期、科室代码均编码、压缩完成。

[0087] 步骤七、将压缩码组合后作为行键将诊疗数据存入Hbase中。

[0088] 对非固定值域编码、压缩案例：假设需要将LIS系统的数据存入Hbase中，并能通过检验编号进行查询，该LIS系统将检验项目组合成一个个“检验套餐”，每个检验套餐使用3个字符标识，如血常规的标识符为“XCG”。医生根据需要可以在这些套餐上增减检验项目，增减的检验项目体现在检验明细上，套餐的名称和代码还是不变。该系统检验编号由8位的日期(4位年+2位月+2位日)+套餐标识符+流水号构成，每个套餐分别使用各自的流水号(4位)；每天凌晨0点，套餐的流水号重置为0。

[0089] 首先，明确查询条件是否能唯一识别一条检验记录，很明显检验编号可以唯一识别检验记录。

[0090] 其次，检验编号的值域是否固定，由于检验编号是由检验系统内部产生的，不能作为固定值域的数据来对待。

[0091] 最后，将检验编号拆分为前缀+后缀的形式，并制定前缀和后缀压缩码的宽度，这里将检验编号拆分以日期为前缀，套餐代码和流水号为后缀的形式，对于前缀，它使用的是日期的格式，压缩码的宽度设定为4个字符，由于套餐的总数是有限的(常见的检验套餐也就几十个而已)，检验编号的流水号为4位，这样使用3个字符就够了，保守起见使用4个字符的宽度表示后缀。

[0092] 编码、压缩的步骤如下：

[0093] 步骤一、将检验编号才分为前缀+后缀的形式，到域表中查询是否存在该前缀和检验业务编码，如果存在则返回该前缀的压缩码，否则执行步骤二至步骤三。

[0094] 步骤二、向ID生成服务发送检验业务编码，请求新的前缀ID，将ID生成服务返回的ID通过图3的流程进行压缩；将压缩码、前缀、检验系统编号一同存入域表中，返回前缀的压缩码；

[0095] 步骤三、使用后缀和检验业务编码到码表中检索后缀是否存在，如果不存在，则使用检验业务编码向ID生成服务申请新的编码ID，并对ID生成服务返回的编码ID进行压缩，将压缩码、后缀、检验系统编码一同存入码表中，返回后缀压缩码。

[0096] 步骤四、对返回的压缩码使用惊叹号(！)进行填充使达到定制的字符宽度。为了避免Hbase的热点问题、对前缀压缩码进行反转，然后再将惊叹号(！)填充到该压缩码的后面，返回定制宽度的前缀压缩码。

[0097] 步骤五、将步骤四返回的前缀压缩码+后缀压缩码作为行键，将检验记录及其检验明细整合后一同存入Hbase中。

[0098] 对序列进行编码、压缩案例：假设门诊收费系统的收费数据使用序列进行唯一标识，需要将门诊收费系统的收费数据存入Hbase中，查询要求能够通过序列号进行收费信息的查询。

[0099] 首先，明确查询条件是否能唯一识别一条检验记录，如上所述收费编号可以唯一识别收费记录。

[0100] 其次，收费序编号的值域是否固定，由于收费编号是通过序列产生的，不能作为固定值域的数据来对待。

[0101] 最后，将收费编号拆分为前缀+后缀的形式，并制定前缀和后缀压缩码的宽度，针对序列的拆分，有很多的拆分方案，本案例中拆分的依据是医院收费系统每天生成的收费记录数据量，假设该医院每天产生的收费记录为数万条，那么将收费编号的后5位拆开，作为编码的后缀，剩余的部分作为前缀，对于长度小于等于5位的收费编号，使用0作为前缀，即0+收费编号的形式。这样的话域表中每天会生成一条新的记录，如果前缀的压缩码使用3个字符的宽度，足够使用1997年(90*90*90/365)，所以前缀的宽度定为3个字符宽度，对于后缀，使用3个字符的宽度足以表示所有的后缀，所以后缀的宽度也为3个字符宽度。

[0102] 步骤一、将收费编号拆分为前缀+后缀的形式，确保后缀的数字字符不会超过5个，对于长度小于等于5位的收费编号，使用0+收费编号的形式，到域表中查询是否存在该前缀和收费业务编码，如果存在则返回该前缀的压缩码，否则执行步骤二至步骤三。

[0103] 步骤二、向ID生成服务发送收费业务编码，请求新的前缀ID，将ID生成服务返回的ID通过图3的流程进行压缩；将压缩码、前缀、收费业务编码一同存入域表中，返回前缀的压缩码；

[0104] 步骤三、使用后缀和收费业务编码到码表中检索后缀是否存在，如果不存在，则使用收费业务编码向ID生成服务申请新的编码ID，并对ID生成服务返回的编码ID进行压缩，将压缩码、后缀、收费业务编码一同存入码表中，返回后缀压缩码。

[0105] 步骤四、对返回的压缩码使用惊叹号(！)进行填充使达到定制的字符宽度。为了避免Hbase的热点问题、对前缀压缩码进行反转，然后再将惊叹号(！)填充到该压缩码的后面，返回定制宽度的前缀压缩码。

[0106] 步骤五、将步骤四返回的前缀压缩码+后缀压缩码作为行键，将收费记录及其收费明细整合后一同存入Hbase中。