数据中心产品开发规范

数据中心产品开发规范

XXXX公司 XX业务部 XXXX年XX月

开发规范（JAVA部分）

文档说明

本文档所涉及到的文字、图表等，仅限于内部使用，未经双方书面许可，请勿扩散到第三方。 文档属性

属性 客户名称： 项目名称： 文档主题： 文档编号： 文档版本： 版本日期： 文档状态： 作者： 文档变更

版本 修订日期 修订人 描述 内容 文档送呈 单位

姓名 目的 审阅 参阅 本文档仅限内部使用，未经双方许可，请勿扩散到第三方。

第 1 页 共 40 页

开发规范（JAVA部分）

目 录

1

概述.......................................................................................................................................... 5 1.1 2

最根本原则 .............................................................................................................. 5

Java技术规范 ........................................................................................................................ 6 2.1

平台使用的相关技术 .............................................................................................. 6 2.1.1 2.1.2 2.2

基本核心框架包 .............................................................................................. 6 其他框架包 ...................................................................................................... 6

程序设计标准 .......................................................................................................... 7 2.2.1 2.2.2 2.2.3 2.2.4

命名约定 .......................................................................................................... 8 包名，类名，方法名，属性名，常量名命名约定 ...................................... 9 注释约定 ........................................................................................................ 10 快速浏览JavaDoc ......................................................................................... 11

2.3 开发规范 ................................................................................................................ 12 2.3.1 2.3.2 2.3.3 2.3.4 2.3.5

项目结构说明 ................................................................................................ 12 整体包结构说 ................................................................................................ 12 项目模块包结构及命名 ................................................................................ 13 各子项目模块功能包结构 ............................................................................ 14 配置文件包结构 ............................................................................................ 14

2.4 命名规则 ................................................................................................................ 15 2.4.1 2.4.2 2.4.3 2.4.4 2.4.5 2.4.6 2.4.7 2.4.8 2.4.9

共用类 ............................................................................................................ 15 业务层 ............................................................................................................ 15 展现层 ............................................................................................................ 15 模型层 ............................................................................................................ 16 持久层 ............................................................................................................ 16 XML配置 ...................................................................................................... 16 资源文件 ........................................................................................................ 19 JSP文件 ........................................................................................................ 20 事务命名约束 ................................................................................................ 20

本文档仅限内部使用，未经双方许可，请勿扩散到第三方。

第 2 页 共 40 页

开发规范（JAVA部分）

2.4.10

3

JS命名约束 .......................................................................................... 21

数据库技术规范 .................................................................................................................... 22 3.1 3.2 3.3

概述 ........................................................................................................................ 22 命名基本规则 ........................................................................................................ 22 数据库表空间 ........................................................................................................ 22 3.3.1 3.4 3.5 3.6 3.7 3.8 3.9 3.10

命名基本规则 ................................................................................................ 22

默认用户方案 ........................................................................................................ 22 表的命名规则、约定 ............................................................................................ 22 视图的命名规则、约定 ........................................................................................ 23 字段命名规则、约定 ............................................................................................ 23 存储过程的命名规则、约定 ................................................................................ 23 序列对象的命名规则、约定 ................................................................................ 24 触发器命名规则、约定 ........................................................................................ 24

4 5

HIVE技术规范 ..................................................................................................................... 25 HBase设计规范 .................................................................................................................... 26 5.1 5.2

Namespace命名空间设计 .................................................................................... 26 1.2. Table表设计 ................................................................................................... 27 5.2.1 5.2.2 5.2.3 5.2.4 5.2.5 5.2.6 5.2.7 5.2.8 5.2.9 5.2.10 5.2.11 5.3

理想HBase表 ............................................................................................... 27 预创建分区 .................................................................................................... 28 列族数量 ........................................................................................................ 28 可配置的数据块大小 .................................................................................... 29 数据块缓存 .................................................................................................... 29 激进缓存 ........................................................................................................ 29 布隆过滤器（Bloom filters） ....................................................................... 30 生存时间（TTL） ........................................................................................ 31 数据压缩 ........................................................................................................ 32 数据分割 ........................................................................................................ 33 单元时间版本 ................................................................................................ 34

ColumnFamily列族设计 ....................................................................................... 35

本文档仅限内部使用，未经双方许可，请勿扩散到第三方。

第 3 页 共 40 页

开发规范（JAVA部分）

5.4 5.5 5.6

Qualifier列设计 .................................................................................................... 36 版本设计 ................................................................................................................ 37 HBase命名规范 .................................................................................................... 37

本文档仅限内部使用，未经双方许可，请勿扩散到第三方。

第 4 页 共 40 页

开发规范（JAVA部分）

? 普通类的属性命名

普通类的属性命名除常量依照常量命名法外，其他的属性的名字使用“英文名字（首字母大写）”命名，多单词可使用驼峰命名法或用下划线隔开。

2.2.3 注释约定

本文还会对注释进行约定，相关注释风格可以在eclipse中导入codetemplates.xm文件。以下是几个基本点： ? 注释应该增加代码的清晰度

代码注释的目的是要使代码更易于被同时参与程序设计的开发人员以及其他后继开发人员理解。

? 如果你的程序不值得注释，那么它也很可能也不值得运行 。 ? 保持注释的简洁

最好的注释应该是简单明了的注释。注释不必洋洋洒洒，只需提供足够的信息，使别人能够理解你的代码。 ? 先写注释，后写代码

写代码注释的最好方法是在写代码之前就写注释。这使你在写代码之前可以想想代码的功能和运行。而且这样确保不会遗漏注释。另一种方法是边写代码边写注释。因为注释可以使代码更易理解，所以在程序开发的过程中，也可以利用这一点。如果打算花些时间写注释，那么至少你应从这个过程中获得些什么。 ? 注释信息不仅要包括代码的功能，还应给出原因

例如，下面例1中的代码显示金额在 $1,000 以上（包括 $1,000）的定单可给予 5% 的折扣。为什么要这样做呢？难道有一个商业法则规定大额定单可以得到折扣吗？这种给大额定单的特殊是有时限的呢，还是一直都这样？最初的程序设计者是否只是由于慷慨大度才这样做呢？除非它们在某个地方（或者是在源代码本身，或者是在一个外部文档里）被注释出来，否则你不可能知道这些。

本文档仅限内部使用，未经双方许可，请勿扩散到第三方。

第 10 页 共 40 页

开发规范（JAVA部分）

2.2.4 快速浏览JavaDoc

Sun 公司的 Java Development Kit (JDK) 中有一个名为 javadoc 的程序。它可以处理 Java 的源代码文件，并且为 Java 程序产生 HTML 文件形式的外部注释文档。Javadoc 支持一定数目的标记，标识注释文档中各段起始位置的保留字。详情请参考 JDK javadoc 文档。

标记 @author name 用于 类、接口 目的 说明特定某一段程序代码的作者。每一个作者各有一个标记。 说明该类的应用程序编程接口 (API) 已被废弃，因此应不再使用。 说明由成员函数发出的异常。一个异常采用一个标记，并要给出异常的完整类名。 用来说明传递给一个成员函数的参数，其中包成员函数 括参数的类型/类和用法。每个参数各有一个标记。 若成员函数有返回值，对该返回值进行说明。应说明返回值的类型/类和可能的用途。 @since 类、成员函数 说明自从有 JDK 1.1 以来，该项已存在了多长时间。 @see ClassName @see ClassName#member functionName @version text 类、接口 说明特定一段代码的版本信息。 类、接口、成员函数、字段 类、接口、成员函数、字段 在文档中生成指向特定类的超文本链接。可以并且应该采用完全合法的类名。 在文档中生成指向特定成员函数的超文本链接。可以并且应该采用完全合法的类名。 @deprecated @exception description name 类、成员函数。 成员函数 @param description name @return description 成员函数 你注释代码的方式很大地影响着你的工作效率以及所有维护改进代码的后继开发者的工作效率。在软件开发过程中及早注释代码，会促使你在开始撰写代码之前仔细考虑这些代码，从而带来更高的工作效率。而且，当你重新阅读数天前或者数星期前所写的代码时，

本文档仅限内部使用，未经双方许可，请勿扩散到第三方。

第 11 页 共 40 页

开发规范（JAVA部分）

你可以很容易地判断出当时你是怎么想的，因为这一切都有记录。

2.3 开发规范

2.3.1 项目结构说明

数据中心 FDC项目采用多module式项目结构，其中包含如下项目，各项目模块功能说明如下： 父模块 FDC FDC FDC 模块 Fdc-common Fdc-monitor Fdc-compute 依赖模块 none Fdc-common Fdc-monitor, Fdc-common FDC Fdc-report Fdc-monitor, Fdc-common

主要业务功能描述 提供FDC项目中公用框架包及公用工具包 提供FDC项目中监控告警功能 提供FDC项目中核心数据运算功能（包括ETL，汇总，分发）。 提供FDC项 目中数据展现功能（报表展现，短信、邮件展现，数据导出等） 2.3.2 整体包结构说

包结构整体遵循按功能不同分包，主要体现出平台的整体架构。 1.常用的包结构如2.3.2常用包结构及命名。

2.各个模块包结构，如业务层，控制层，持久层，异常，模型POJO，常量类，工具类等。

这里的常用类和公共里的不一样如果各大模块在公共类里没有找到，可以在自己的模块中自行扩展。达到遵循“开—闭”原则。 3.常用xml配置文件结构，如2.3.4配置文件包结构。

4.平台核心的配置文件，存放在包的根目录，如国际化，数据库连接，日志配置，缓存

本文档仅限内部使用，未经双方许可，请勿扩散到第三方。

第 12 页 共 40 页

开发规范（JAVA部分）

配置，系统级配置等。

5.自定义xml的scheme，dtd，以及tld文件存放于Web根目录的WEB-INF文件夹

下，文件名全部使用小写字母。

2.3.3 项目模块包结构及命名

1. Fdc-common

? com.feinno.fdc.common.cache

说明：所有的缓存结构。例如平台所使用的Oscache和Ehcache缓存技术。 ? com.feinno.fdc.common.framework 说明：各个技术层框架类。如下子包 controller：控制层提供的共有框架类。

Module：数据bean公共基础类。

Business：业务层公共业务控制类，提供通用功能。 Persistence：数据持久层公共数据操作类。

? com.feinno.fdc.common.utils

说明：存放基本常用的类。例如文件类，字符串类等。

2. Fdc-moniter , Fdc-compute, Fdc-report

? configs

说明：该包存放所有关于读取配置信息的类 ? Controller

说明：存放在控制层下面的业务类。例如登陆，登出，角色切换等。 ? Module

本文档仅限内部使用，未经双方许可，请勿扩散到第三方。

第 13 页 共 40 页

开发规范（JAVA部分）

说明：存放各个业务数据bean类。下分各个子业务包。 ? Busines

说明：存放个业务层公共业务控制类。下分各个子业务包。 ? Persistence

说明：数据持久层数据控制类。下分各个子业务包。 ? extends

说明:平台扩展功能类。下分子包，第一级子包名表示扩展功能模块名。

? Exceptions

2.3.4 各子项目模块功能包结构

按照各个层次结构包分完：功能包基本分为2个包： 1. 各个层次的接口包。 2. 对于接口的实现包。

2.3.5 配置文件包结构

配置文件夹命名为configs，可存放在Web根目录下的WEB-INF文件夹下，也可放在与java class文件根目录同级的目录下。configs目录下主要包含以下目录结构：

? commons

存放公共的Xml配置文件，如：struts,spring,mybatis等的xml配置文件。 ? core/*

存放平台核心模块，各功能模块，扩展功能模块的所需的配置文件。如各模块的spring，struts，mybatis配置文件。

本文档仅限内部使用，未经双方许可，请勿扩散到第三方。

第 14 页 共 40 页

开发规范（JAVA部分）

2.4 命名规则

2.4.1 共用类

公共用类要求以“功能英文名称(首字母大写)+ Utils”驼峰命名。例如：日期的英文名为date，按照规则要求，命名为：DateUtils 。

2.4.2 业务层

? 业务层接口要求以 I +“模块英文名称(首字母大写)”+ Manager命名。例如：导

航菜单的英文名为navigator，按照规则要求，命名为：INavigatorManager ； ? 接口的实现类要求以“模块英文名称(首字母大写)”+ ManagerImpl 命名。例如：

导航菜单的英文名为navigator，按照规则要求，命名为：NavigatorManagerImpl ；

2.4.3 展现层

? 基类要求以“模块英文名称(首字母大写)”+ActionBase命名。例如：导航菜单的

英文名为navigator，按照规则要求，命名为：NavigatorActionBase ； ? 查询模块列表类要求以List +“模块英文名称(首字母大写)”+ s + Action命名。

例如：导航菜单的英文名为navigator，按照规则要求，命名为：ListNavigatorsAction ；

? 创建模块对象类要求以Create +“模块英文名称(首字母大写)”+ Action命名。例

如：导航菜单的英文名为navigator，按照规则要求，命名为： CreateNavigatorAction ；

? 修改模块对象类要求以Modify +“模块英文名称(首字母大写)”+ Action命名。例

如：导航菜单的英文名为navigator，按照规则要求，命名为：ModifyNavigatorAction ；

? 删除模块对象类要求以Remove +“模块英文名称(首字母大写)”+ Action命名。

本文档仅限内部使用，未经双方许可，请勿扩散到第三方。

第 15 页 共 40 页

开发规范（JAVA部分）

例如：导航菜单的英文名为navigator，按照规则要求，命名为：RemoveNavigatorAction ；

? 对模块对象的操作类要求以“模块英文名称(首字母大写)”+ Operator + Action

命名。例如：导航菜单的英文名为navigator，按照规则要求，命名为： NavigatorOperatorAction 。

2.4.4 模型层

? 模型层存放的是实体类，要求以“模块实体英文名称(首字母大写)”命名。例如：导

航菜单的英文名为navigator，按照规则要求，命名为：Navigator ； ? 属性字段参照Bean属性命名规则。

2.4.5 持久层

? dao接口要求以 I +“模块英文名称(首字母大写)”+ DAO命名。例如：导航菜单

的英文名为navigator，按照规则要求，命名为：INavigatorDAO ；

? 接口的实现类要求以“模块英文名称(首字母大写)”+ DAOImpl 命名。例如：导航

菜单的英文名为navigator，按照规则要求，命名为：NavigatorDAOImpl 。

2.4.6 XML配置

主要配置文件包括spring.xml,struts.xml,mybatis.xml等。

由于这些文件都是分包存放，所以配置文件统一为spring.xml，struts.xml，mybatis.xml。如果模块内的spring，struts，mybatis配置较多时，需要分文件来写，那么可直接在spring，struts，mybatis的后面直接加连接号“-”+名字来命名。如spring-common.xml。

各模块的mybatis sqlmap配置文件放到相应模块的Model包下，一个域模型对应一个sqlMap配置文件，如域模型名为Item，则与域模型相对应的sqlMap文件名为Item.xml。

本文档仅限内部使用，未经双方许可，请勿扩散到第三方。

第 16 页 共 40 页

开发规范（JAVA部分）

1、 spring.xml平台Spring相关组件配置。 Module

? 需要新建一个用户管理模块managerUserModule，设置其父节点是后台管理树

的根节点，也就是设置parentModeulId为#号，然后它的子节点可以设置相应的父节点为managerUserModule,。

? ationURL：指用来访问这个相关模块的命名空间。

? viewType：查看类型，是指要说明此模块节点是要在前台显示还是后台管理的。 ? imgURL：指当我们把这些模块展示在相关树上显示的图标链接。 Fuction

? 确定包含的功能，如增加用户：addUser。 Method

? 增加用户的入口方法：saveAddUser。

? actionUR：指这个入口方法在当前模块命名空间下的访问地址createUser.加一个

点是用来判断最后的后缀，如果是点结尾程序会自动补齐访问链接的后缀，如果是其他后缀直接访问这个链接。

? isDefault：是否默认入口，一个模块功能只能有一个方法作为默认入口。

2、 struts.xml平台struts组件相关配置，开发相关模块的时候注意相关规范

? package：我们可以在模块中定义包以避免命名空间重复，命名规则：

struts-xxx(模块名层)。

? namespace：相关模块的命名空间。这里涉及几个需要注意的地方：这个链接会

和权限关联由过滤器判断命名空间管理权限功能。凡是命名空间在/public/common这个路径下的系统定义为前台没有权限管理的访问链接，凡是命名空间在/manage/common这个路径下的系统定义为后台没有权限管理的访

本文档仅限内部使用，未经双方许可，请勿扩散到第三方。

第 17 页 共 40 页

开发规范（JAVA部分）

问链接。在这个两个路径下面访问的地址，过滤器不作权限判断。其它访问地址会根据rights中配置定义的权限进行过滤。

? extends：在struts配置中需要考虑各种拦截器和错误处理跳转，配置在

struts-interceptor.xml这个文件。 Action

? name：定义action被访问的id命名规范与定义java变量同样的规范。 ? class：就是我们在spring.xml文件已经配置了注入action spring bean的id。 ? result：struts处理跳转，两种跳转方式dispatcher转向和redirect重定向。 ? interceptor-ref：所使用的拦截器。在struts-interceptor.xml这个文件有相关

注释。

3、 mybatis.xml，平台myBATIS相关组件配置

? 配置sqlMap元素的resource属性，指示域模型对应的SQL配置文件的包全路径。

4、 myBATIS的SQLMap文件

配置域模型的增删改查SQL语句，存储过程等；配置文件名与域模型同名。 ? sqlMap根元素的namespace属性，设置成域模型的本身的名字。如域模型名字

为Item.java，那么namespace属性名就为Item。

? typeAlias，resultMap，cacheModel，select，insert，delete，update等元

素的id属性名以“自定英文名字（首字母小写）”命名，多单词使用驼峰命名法。 ? 在使用select，insert，update，delete元素配置增删改查时，id属性的名字规

则为，select的id属性名以get***开头，insert的以add***开头，update的以update***开头，delete的以delete***开头，配合事务中的配置，多单词使用驼峰命名法。可在这些元素中使用复合查询配置。

本文档仅限内部使用，未经双方许可，请勿扩散到第三方。

第 18 页 共 40 页

开发规范（JAVA部分）

? procedure元素，的id属性名以“功能英文名（首字母小写）+Procedure”命

名，使用驼峰命名法。

? sql元素的id属性名以“自定义英文名字（首字母小写）”命名。多个单词可使用

下划线或使用驼峰命名法。

? statement元素的id属性名与sql元素命名规则一致。statement主要配置复合

查询。

5、 ehcache.xml 平台ehcache缓存实现配置文件 6、 system-config.xml 平台系统配置文件

2.4.7 资源文件

平台properties以及国际化资源 配置文件

? commons-logging.properties 公共日志配置文件。 ? config.properties 平台数据连接，基本参数配置等。 ? log4j.properties 平台日志输出保存等相关设置的配置文件。 ? quartz.properties 平台调度组件相关设置的配置文件。 ? oscache.properties 平台oscache缓存实现配置文件

? struts.properties 平台struts组件相关系统配置文件（国际化、上传等）。 国际化资源文件使用标准JSTL标签绑定。通过不同的local读取不同语言的相关资源，国际化资源文件中key的定义规则：模块名称.功能名称.key描述，但此全部小写，多个单词之间用下划线分割。国际化资源配置文件进行分割处理，属于本功能模块的国际化资源文件放到本模块的根包下，在JSP中使用JSTL标签的调用，在文件开头处加上< fmt:setBundle basename=”” />设置。

全局国际化配置文件如下（直接设置在struts.properties文件中）： ? messages开头的资源文件包含相关的国际化资源内容。

本文档仅限内部使用，未经双方许可，请勿扩散到第三方。

第 19 页 共 40 页

开发规范（JAVA部分）

? exceptionMessages开头的资源文件包含异常处理描述的国际化资源内容。 各功能模块的国际化配置文件使用如下：

? 文件名使用“功能模块名+”_”+messages”命名，如

search_message.properties。

? 在JSP文件最开头处使用标签设置全局

bundle，其中basename属性名为模块资源文件所在的包全路径，scope为使用范围。

? 在位于setBundle设置后使用标签可直接使用该资源

文件中的key属性。

2.4.8 JSP文件

? JSP文件统一存放在应用的Web根目录下，即与WEB-INF文件夹同级。 ? 文件夹名按照java对于的功能模块名来设置，文件夹名全部使用小写字母。 ? JSP文件名以“自定英文名（首字母小写）+“_”+功能名”命名，多单词英文可

使用驼峰命名法。

2.4.9 事务命名约束

平台中，所有关于事务处理的，必须遵循以下命名规则： ? 保存/填加：以save开头。 ? 修改：以update开头。 ? 删除：以delete开头。 ? 获取：以get开头。 ? 查找：以find开头。

本文档仅限内部使用，未经双方许可，请勿扩散到第三方。

第 20 页 共 40 页

开发规范（JAVA部分）

2.4.10 JS命名约束

与Java命名一致，但JS文件名可小写，甚至可以加下划线等特殊符号。

本文档仅限内部使用，未经双方许可，请勿扩散到第三方。

第 21 页 共 40 页

开发规范（JAVA部分）

3 数据库技术规范

3.1 概述

本规范目前只适合部分数据库的相关定义。

3.2 命名基本规则

针对不同工程模块采用不同的数据命名。

开发时数据库：dev+系统名。如：devcompute。

试运行数据库：test+系统名。如：testcompute。

正式运行数据库：系统名。如：compute。

3.3 数据库表空间

3.3.1 命名基本规则

表空间：tbs_+系统名。如：tbs_compute。

临时表空间：tbs_+系统名+tempspace。如：tbs_computetempspace。

3.4 默认用户方案

User name ：raysdata/root Password ：raysdata/root

3.5 表的命名规则、约定

命名基本规则

本文档仅限内部使用，未经双方许可，请勿扩散到第三方。

第 22 页 共 40 页

开发规范（JAVA部分）

按照表在当前数据仓库内不同数据职能划分，所有字母均大写： 字典定义类表以 D_开头；如：D_DIM。

关系定义类表以P_开头，当前表示关系类名称中间以“_”分割，表示两者关系；如：P_ITEM_IDT。

数据汇总类表以G_开头，拥有数据维度的，将维度名称采用”_”分割，拼合在表名称中；如：G_ITEM_VSN

对前端报表支持表以R_开头，名称采用各报表业务名称定义，如：R_CONFIG_LOG

3.6 视图的命名规则、约定

命名基本规则

vi_视图的类型（模块名）_英文单词_英文单词_... 例如：vi_base_message。

3.7 字段命名规则、约定

命名基本规则

英文单词_英文单词_英文单词_... 例如：message_id、message_name。

3.8 存储过程的命名规则、约定

命名基本规则

usp_英文单词_英文单词_... 例如：usp_message

本文档仅限内部使用，未经双方许可，请勿扩散到第三方。

第 23 页 共 40 页

开发规范（JAVA部分）

3.9 序列对象的命名规则、约定

命名基本规则

seq_英文单词_英文单词_ 如：seq_base_message。

3.10 触发器命名规则、约定

命名基本规则

trigger_英文单词_英文单词_ 如：trigger_message。

本文档仅限内部使用，未经双方许可，请勿扩散到第三方。

第 24 页 共 40 页

开发规范（JAVA部分）

4 HIVE技术规范

1. 按照表在当前数据仓库内不同数据职能划分，所有字母均大写： 字典定义类表以 D_开头；如：D_DIM。

关系定义类表以P_开头，当前表示关系类名称中间以“_”分割，表示两者关系；如：P_ITEM_IDT。

数据集成类表以FACT_开头，使用相关业务定义名称，如：FACT_

数据汇总类表以G_开头，拥有数据维度的，将维度名称采用”_”分割，拼合在表名称中；如：G_ITEM_VSN

对前端报表支持表以R_开头，名称采用各报表业务名称定义，如：R_CONFIG_LOG 2. 数据路径

数据路径内全部按照大写定义路径字符。

本文档仅限内部使用，未经双方许可，请勿扩散到第三方。

第 25 页 共 40 页

开发规范（JAVA部分）

5 HBase设计规范

介绍了HBase应用开发时建议遵循的设计规范，主要是针对开发层面的。

Hbase中与表结构相关的逻辑模型涉及到以下几个词汇：命名空间、表、列族、列、行键、版本等，这些是构建hbase表的所有元素。下文就依据这几个关键词汇，陈述下相关的规范。

5.1 Namespace命名空间设计

通俗地讲，命名空间可视为表组（与Oracle中的表空间类似），划分依据不固定，可依据业务类型划分，也可依据时间周期划分。譬如，针对电力气象方面的数据表，可以创建一个电力气象的命名空间，取名为DLQX，将电力气象相关的表都组织在此命名空间下面。引进命名空间的好处就是方便对表进行组织管理。

HBase默认的命名空间是default，默认情况下，如果在创建表时没有显式地指定命名空间，那么表将创建在default命名空间下。如果表隶属于某个非默认的命名空间，那么在引用表（譬如读取表数据）时，就必须指定命名空间，否则将出现类似“无法定位到表”的错误，完整表名的格式为“命名空间名称:表名称”，譬如”DLQX:SYSTEM_USER”；如果是默认的命名空间，则完整表名也可以省略掉“default:”，直接拼写表名SYSTEM_USER即可。

本文档仅限内部使用，未经双方许可，请勿扩散到第三方。

第 26 页 共 40 页

开发规范（JAVA部分）

命名空间与表的关系，可以用下图表示：

命名空间与表之间是一对多的关系，即一个命名空间下面可以包含多个hbase表，但一个hbase表只能属于一个命名空间。在创建表时，如果没有指定命名空间（或者命名空间为空），则系统会将此hbase表放置在默认命名空间（default）下。

另外，删除命名空间之前，必须先删除掉此命名空间下的所有hbase表，否则将无法删除此命名空间。

5.2 1.2. Table表设计

HBase有几个高级特性，在你设计表时可以使用。这些特性不一定联系到模式或行键设计，但是它们定义了某些方面的表行为。

5.2.1 理想HBase表

Hbase作为列数据库，根据官方的说法，在性能和效率上更擅长处理“高而瘦”的表，而非“矮而胖”的表。所谓“高而瘦”，是指表的列的数量

本文档仅限内部使用，未经双方许可，请勿扩散到第三方。

第 27 页 共 40 页

开发规范（JAVA部分）

较少，但是行的数量极大，从而使表展现出一种又高又瘦的形象。所谓“矮而胖”，是指表的列的数据居多，但是行的数量却有限，给人一种又矮又胖的形象，虽然hbase表号称可容纳百万列，但是那也仅仅限于理论上的极限，在实际应用中，请尽量构建“高而瘦”的表，同时需要对列的数量进行测试，以避免过度影响读写性能。

5.2.2 预创建分区

默认情况下，在创建HBase表的时候会自动创建一个region分区，当导入数据的时候，所有的HBase客户端都向这一个region写数据，直到这个region足够大了才进行切分。一种可以加快批量写入速度的方法是通过预先创建一些空的regions，这样当数据写入HBase时，会按照region分区情况，在集群内做数据的负载均衡。

5.2.3 列族数量

不要在一张表里定义太多的column family。目前Hbase并不能很好的处理超过2~3个column family的表。因为某个column family在flush的时候，它邻近的column family也会因关联效应被触发flush，最终导致系统产生更多的I/O。所以，根据官方的建议，一个HBase表中创建一个列族即可。

本文档仅限内部使用，未经双方许可，请勿扩散到第三方。

第 28 页 共 40 页

开发规范（JAVA部分）

5.2.4 可配置的数据块大小

HFile数据块大小可以在列族层次设置。这个数据块不同于HDFS数据块。其默认值是65,536字节，或64KB。数据块索引存储每个HFile数据块的起始键。数据块大小设置影响到数据块索引的大小。数据块越小，索引越大，从而占用更大内存空间。同时因为加载进内存的数据块更小，随机查找性能更好。但是如果你需要更好的序列扫描性能，那么一次能够加载更多HFile数据进入内存则更为合理，这意味着数据块应该设置为更大的值。相应地索引变小，你将在随机读性能上付出代价。

5.2.5 数据块缓存

把数据放进读缓存，但工作负载却经常不能从中获得性能提升。例如，如果一张表或表里的列族只被顺序化扫描访问或者很少被访问，你不会介意Get或Scan花费时间是否有点儿长。在这种情况下，你可以选择关闭那些列族的缓存。如果你只是执行很多顺序化扫描，你会多次倒腾缓存，并且可能会滥用缓存把应该放进缓存获得性能提升的数据给排挤出去。如果关闭缓存，你不仅可以避免上述情况发生，而且可以让出更多缓存给其他表和同一表的其他列族使用。

5.2.6 激进缓存

你可以选择一些列族，赋予它们在数据块缓存里有更高的优先级（LRU缓存）。如果你预期一个列族比另一个列族随机读更多，这个特性迟早用得上。

本文档仅限内部使用，未经双方许可，请勿扩散到第三方。

第 29 页 共 40 页

开发规范（JAVA部分）

IN_MEMORY参数的默认值是false。因为HBase除了在数据块缓存里保存这个列族相比其他列族更激进之外并不提供额外的保证，该参数在实践中设置为true不会变化太大。

创建表的时候，可以通过HColumnDescriptor.setInMemory(true)将表放到RegionServer的缓存中，保证在读取的时候被cache命中。

5.2.7 布隆过滤器（Bloom filters）

数据块索引提供了一个有效的方法，在访问一个特定的行时用来查找应该读取的HFile的数据块。但是它的效用是有限的。HFile数据块的默认大小是64KB，这个大小不能调整太多。

如果你要查找一个短行，只在整个数据块的起始行键上建立索引无法给你细粒度的索引信息。例如，如果你的行占用100字节存储空间，一个64KB的数据块包含(64 * 1024)/100 = 655.53 = ~700行，而你只能把起始行放在索引位上。你要查找的行可能落在特定数据块上的行区间里，但也不是肯定存放在那个数据块上。这有多种情况的可能，或者该行在表里不存在，或者存放在另一个HFile里，甚至在MemStore里。这些情况下，从硬盘读取数据块会带来IO开销，也会滥用数据块缓存。这会影响性能，尤其是当你面对一个巨大的数据集并且有很多并发读用户时。

布隆过滤器允许你对存储在每个数据块的数据做一个反向测试。当某行被请求时，先检查布隆过滤器看看该行是否不在这个数据块。布隆过滤

本文档仅限内部使用，未经双方许可，请勿扩散到第三方。

第 30 页 共 40 页

开发规范（JAVA部分）

器要么确定回答该行不在，要么回答它不知道。这就是为什么我们称它是反向测试。布隆过滤器也可以应用到行里的单元上。当访问某列标识符时先使用同样的反向测试。

布隆过滤器也不是没有代价。存储这个额外的索引层次占用额外的空间。布隆过滤器随着它们的索引对象数据增长而增长，所以行级布隆过滤器比列标识符级布隆过滤器占用空间要少。当空间不是问题时，它们可以帮助你榨干系统的性能潜力。

你可以在列族上打开布隆过滤器，如下所示： hbase(main)> create

'mytable',{NAME=>'colfam1',BLOOMFILTER=>'ROWCOL'} BLOOMFILTER参数的默认值是NONE。一个行级布隆过滤器用ROW打开，列标识符级布隆过滤器用ROWCOL打开。行级布隆过滤器在数据块里检查特定行键是否不存在，列标识符级布隆过滤器检查行和列标识符联合体是否不存在。ROWCOL布隆过滤器的开销高于ROW布隆过滤器。

5.2.8 生存时间（TTL）

应用系统经常需要从数据库里删除老数据。由于数据库很难超过某种规模，所以传统上数据库内建了许多灵活处理办法。例如，在TwitBase里你不愿意删除用户在使用应用系统期间生成的任何推帖。这些都是用户生成数据，将来有一天当你执行一些高级分析时可能有用。但是并不

本文档仅限内部使用，未经双方许可，请勿扩散到第三方。

第 31 页 共 40 页

开发规范（JAVA部分）

需要保存所有推帖用于实时访问。所以早于某个时间的推帖可以归档存放到平面文件里。

HBase可以让你在数秒内在列族级别设置一个TTL。早于指定TTL值的数据在下一次大合并时会被删除。如果你在同一单元上有多个时间版本，早于设定TTL的版本会被删除。你可以关闭TTL或者通过设置其值为INT.MAX_VALUE (2147483647)来让它永远打开（这是默认值）。你可以在建表时设置TTL，如下所示： hbase(main)> create

'mytable',{NAME=>'colfam1',TTL=>'18000'}

该命令在colfam1列族上设置TTL为18,000秒=5小时。colfam1里超过5小时的数据将会在下一次大合并时被删除。

5.2.9 数据压缩

HFile可以被压缩并存放在HDFS上。这有助于节省硬盘IO，但是读写数据时压缩和解压缩会抬高CPU利用率。压缩是表定义的一部分，可以在建表或模式改变时设定。除非你确定不会从压缩中受益，我们推荐你打开表的压缩。只有在数据不能被压缩或者因为某种原因服务器的CPU利用率有限制要求的情况下，有可能会关闭压缩特性。

HBase可以使用多种压缩编码，包括LZO、Snappy和GZIP。LZO[1]和Snappy[2]是其中最流行的两种。Snappy由Google在2011年发布，发布不久Hadoop和HBase项目开始提供支持。在此之前，选

本文档仅限内部使用，未经双方许可，请勿扩散到第三方。

第 32 页 共 40 页

开发规范（JAVA部分）

择的是LZO编码。Hadoop使用的LZO原生库受GPLv2版权控制，不能放在Hadoop和Hbase的任何发行版里；它们必须单独安装。另一方面，Snappy拥有BSD许可（BSD-licensed），所以它更容易和Hadoop和HBase发行版捆绑在一起。LZO和Snappy的压缩比例和压缩/解压缩速度差不多。

当建表时你可以在列族上打开压缩，如下所示： hbase(main)> create

'mytable',{NAME=>'colfam1',COMPRESSION=>'SNAPPY'} 注意数据只在硬盘上是压缩的。在内存里（MemStore或BlockCache）或网络传输时是没有压缩的。

改变压缩编码的做法不应该经常发生，但是如果你的确需要改变某个列族的压缩编码，直接做就可以。你需要更改表定义，设定新压缩编码。此后合并时，生成的HFile全部会采用新编码压缩。这个过程不需要创建新表和复制数据。但你要确保直到改变编码后所有老HFile被合并后才能从集群中删除老编码函数库。

5.2.10 数据分割

在HBase中，数据在更新时首先写入WAL 日志(HLog)和内存(MemStore)中，MemStore中的数据是排序的，当MemStore累计到一定阈值时，就会创建一个新的MemStore，并且将老的MemStore添加到flush队列，由单独的线程flush到磁盘上，成为一个StoreFile。

本文档仅限内部使用，未经双方许可，请勿扩散到第三方。

第 33 页 共 40 页

开发规范（JAVA部分）

于此同时， 系统会在zookeeper中记录一个redo point，表示这个时刻之前的变更已经持久化了(minor compact)。

StoreFile是只读的，一旦创建后就不可以再修改。因此Hbase的更新其实是不断追加的操作。当一个Store中的StoreFile达到一定的阈值后，就会进行一次合并(major compact)，将对同一个key的修改合并到一起，形成一个大的StoreFile，当StoreFile的大小达到一定阈值后，又会对 StoreFile进行分割(split)，等分为两个StoreFile。 由于对表的更新是不断追加的，处理读请求时，需要访问Store中全部的StoreFile和MemStore，将它们按照row key进行合并，由于StoreFile和MemStore都是经过排序的，并且StoreFile带有内存中索引，通常合并过程还是比较快的。

实际应用中，可以考虑必要时手动进行major compact，将同一个row key的修改进行合并形成一个大的StoreFile。同时，可以将StoreFile设置大些，减少split的发生。

5.2.11 单元时间版本

HBase在默认情况下每个单元维护三个时间版本。这个属性是可以设置的。如果你只需要一个版本，推荐你在设置表时只维护一个版本。这样系统就不会保留更新单元的多个时间版本。时间版本也是在列族级设置的，可以在表实例化时设定：

本文档仅限内部使用，未经双方许可，请勿扩散到第三方。

第 34 页 共 40 页

开发规范（JAVA部分）

hbase(main)> create 'mytable',{NAME=>'colfam1', VERSIONS=>1}

你可以在同一个create语句里为列族指定多个属性，如下所示： hbase(main)> create

'mytable',{NAME=>'colfam1',VERSIONS=>1,TTL=>'18000'}

你也可以指定列族存储的最少时间版本数，如下所示： hbase(main)> create

'mytable',{NAME=>'colfam1',VERSIONS=>5, MIN_VERSIONS=>'1'}

在列族上同时设定TTL也是迟早有用的。如果当前存储的所有时间版本都早于TTL，至少MIN_VERSION个最新版本会保留下来。这样确保在你的查询以及数据早于TTL时有结果返回。

5.3 ColumnFamily列族设计

列族是针对多个列的分组，分组的依据是不固定的。虽然理论上HBase一个表可以创建多个列族，但是HBase官方建议一个表不要创建多于一个的列族。经过测试，单个列族的写入和读取效率要远远超过多个列族时的情况。在存储时，一个列族会存储成一个StoreFile，多个列族

本文档仅限内部使用，未经双方许可，请勿扩散到第三方。

第 35 页 共 40 页

开发规范（JAVA部分）

对应的多个文件在分裂时会对服务器造成更大的压力。所以建议，一个表创建一个列族。

列族的名称不宜过长，因为在存储时每列都会拼上列族名称，过长的列族将会浪费更多的存储空间。

删除列族时，将同时删除列族下的列及列值数据。

创建表时，最少要创建一个列族。创建表后，可以添加多个列族。 Version版本是针对列族而言的，如果一个表有多个列族，可以为每个列族设置不同的版本数量。譬如，允许列族A最多有5个版本，列族B最多有3个版本。

5.4 Qualifier列设计

HBase与传统的关系数据库一个明显的不同之处，就是创建表时不需要创建列，而是在写入数据时动态地创建列。而且其中的空列并不真正占用存储空间。

列内容被封装成为KeyValue对象，从中可以获取多个信息，如下所示：

//行键

String rowKey = Bytes.toString(kv.getRow()); //列族

String family = Bytes.toString(kv.getFamily()); //列名称

本文档仅限内部使用，未经双方许可，请勿扩散到第三方。

第 36 页 共 40 页

开发规范（JAVA部分）

String qualifier = Bytes.toString(kv.getQualifier()); //列值

String value = Bytes.toString(kv.getValue()); //版本号

long timestamp = kv.getTimestamp();

5.5 版本设计

如果表的某个列族涉及到多版本的问题，则必须在创建列族时指定MaxVersions。虽然，HBase默认的版本数是3，但是如果在创建表时没有明确指定，则仍然只能保存一个版本，因为HBase会认为你不想启用列族的多版本机制。

可以在写入数据时指定版本号，如果不指定版本号，则将采用默认的版本号，即时间戳。

读取数据时，如果没有指定版本号，将只读取最新版本数据，而非最新版本号的数据。

5.6 HBase命名规范

项目 说明 示例 ? 采用英文单词、阿拉伯数字的组合形? 式，其中，单词必须大写，并且首字符必须为英文字符，不能是数字。 根据项目名称构建命名空间：DLQX（电力气象首字母拼接形式），简短明了。 命名空间 本文档仅限内部使用，未经双方许可，请勿扩散到第三方。

第 37 页 共 40 页

开发规范（JAVA部分）

? 不建议用连接符（下划线）拼接多个? 单词，简单语义的可采用单个单词，复杂语义的可采用多个单词的首字母拼接。 不建议过长的命名空间名称，譬如不推荐采用以下形式：USER_INFO_MANAGE等。 ? ? 长度尽量限制在4~8字符之间。 命名空间一般可与项目名称、组织机构名称等保持一致。 ? 采用英文单词、阿拉伯数字、连接符? 符合规范的表名称： （_）的组合形式，其中，单词必须大写，USER_INFO_MANAGE、 并且首字符必须为英文字符，不能是数字，可用连接符拼接多个单词。 表名称 ? ? WEATHER_DATA、 长度尽量限制在8~16字符之间。 T_ELECTRIC_GATHER等。 尽量采用具有明确意义的英文单词，而不建议采用汉字的拼音字母或者拼音首字母组合。 ? 采用英文单词、阿拉伯数字的组合形? 式，其中，单词必须大写，并且首字符符合规范的列族名称： 列族名称 D1、D2、DATA等。 必须为英文字符，不能是数字。 ? 长度尽量限制在1~6字符之间，过? 不推荐的列族名称： 本文档仅限内部使用，未经双方许可，请勿扩散到第三方。

第 38 页 共 40 页

开发规范（JAVA部分）

长的列族名称将占用更多的存储空间。 USER_INFO、D_1等。 ? 采用英文单词、阿拉伯数字、连接符? 符合规范的列名称： （_）的组合形式，其中，单词必须大写，USER_ID、DATA_1、REMARK等。 并且首字符必须为英文字符，不能是数字，可用连接符拼接多个单词。 列名称 ? ? ? 不推荐的列名称： 长度尽量限制在1~16字符之间。 尽量采用具有明确意义的英文单词，而不建议采用汉字的拼音字母或者拼音首字母组合。 UserID、1_DATA等。

本文档仅限内部使用，未经双方许可，请勿扩散到第三方。

第 39 页 共 40 页

本文来源：https://www.bwwdw.com/article/2qp7.html