数据中心产品开发规范

数据中心产品开发规范

XXXX公司

XX业务部

XXXX年XX月

文档说明

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

第二方。

文档属性

属性内容

客户名称：

项目名称：

文档主题：

文档编号：

文档版本：

版本日期：

文档状态：

文档变更

版本修订日期修订人描述

文档送呈

单位姓名目的

批阅

参阅

目录

1概述........................................................................5

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

2Java技术规范...............................................................6

2.1平台使用的有关技术..................................................6

2.1.1基本核心框架包..................................................6

2.1.2其他框架包......................................................6

2.2程序设计标准........................................................7

2.2.1命名约定........................................................8

2.2.2包名，类名，方法名，属性名，常量名命名约定....................9

2.2.3注释约定.......................................................10

2.2.4快速浏览JavaDoc...............................................................................................10

2.3开发规范............................................................12

2.3.1项目结构说明...................................................12

2.3.2整体包结构说...................................................12

2.3.3项目模块包结构及命名...........................................13

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

2.3.5配置文件包结构.................................................14

2.4命名规则............................................................14

2.4.1共用类.........................................................14

2.4.2业务层.........................................................14

2.4.3展现层.........................................................15

2.4.4模型层.........................................................15

2.4.5持久层.........................................................16

2.4.6XML配置......................................................16

2.4.7资源文件.......................................................18

2.4.8JSP文件.......................................................19

2.4.9事务命名约束...................................................20

2.4.10JS命名约束...................................................20

3数据库技术规范.............................................................21

3.1概述...............................................................21

3.2命名基本规则.......................................................21

3.3数据库表空间.......................................................21

3.3.1命名基本规则..................................................21

3.4默认用户方案.......................................................21

3.5表的命名规则、约定.................................................21

3.6视图的命名规则、约定...............................................22

3.7字段命名规则、约定.................................................22

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

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

3.10触发器命名规则、约定..............................................23

4HIVE技术规范.............................................................24

5HBase设计规范.............................................................25

5.1Namespace命名空间设计一............................................25

5.21.2.Table表设计.....................................................26

5.2.1理想HBase表..................................................26

5.2.2预创建分区.....................................................27

5.2.3列族数量.......................................................27

5.2.4可配置的数据块大小.............................................27

5.2.5数据块缓存.....................................................28

5.2.6激进缓存.......................................................28

5.2.7布隆过滤器(Bloomfilters)............................................................................29

5.2.8生存时间(TTL)..............................................................................................30

5.2.9数据压缩.......................................................31

5.2.10数据分割.......................................................32

5.2.11单元时间版本...................................................33

5.3ColumnFamily列族设计..............................................34

5.4Qualifier列设计.....................................................35

5.5版本设计...........................................................35

5.6HBase命名规范36

1概述

本文提供一整套编写高效可靠的Java代码的标准、约定与指南。它们以安全可靠的软

件工程原则为基础，使代码易于懂得、保护与增强。而且，通过遵循这些程序设计标准，

你作为一个Java软件开发者的生产效率会有显著提高。经验证明，若从一开始就花时间编

写高质量的代码，则在软件开发阶段，对代码的修改要容易很多。最后，遵循一套通用的

程序设计标准将带来更大的一致性，使软件开发团队的效率明显提高。

1.1最根本原则

□运用常识

当找不到任何规则或者指导方针，当规则明显不能适用，当所有的方法都失效的时侯：

运用常识并核实这些基本原则。这条规则比其它所有规则都重要。

□驼峰命名法

驼峰命名法(Camel-Case)：就是当变量名或者函式名是由一个或者多个单字连结在

一起，而构成的唯一识别字时，第一个单字以小写字母开始；第二个单字的首字母大写或

者每一个单字的首字母都使用大写字母，比如：myFirstName、myLastName,这样的

变量名看上去就像骆驼峰一样此起彼伏，故得名。

驼峰命名法的命名规则可视为一种惯例，并无绝对与强制，目的是增加识别与可读性。

2Java技术规范

2.1平台使用的有关技术

平台使用的框架包分核心框架包与其他务必的框架包，各框架包本身所依靠的开源包

不做列举，由框架包本身的信息来定。

2.1.1基本核心框架包

平台使用Spring+Struts2+myBatis的三层架构作为基本框架。(JDK1.6+)。参考如下:

名称版本备注

Struts22.2.1

Spring3.0.5

mybatis-core3.1.1不支持跨数据库建议，目前

开发在mysql上，现网环境

在db2上

mybatis-spring1.1.1

MySQL5.0

Tomcat7.0

jQuery1.8

2.1.2其他框架包

除基本框架外，平台其他将使用的一些框架包，参考如下：(JDK1.5+)

名称版本备注

SpringSecurity2.0.4

ApacheCommons2.6常用的工具包等

SLF4J1.6.1

ApacheLoggingIog4j1.2.15

ApacheAnt1.7.1

Oscache2.4.1

XMemcache1.2.5

C3P00.9.1

Dom4j2.0

commons-beanutils1.8.3

Mybatis-spring1.1.1

Hadoop-core0.20.2-cdh3u5

Hive-cli0.7.1-cdh3u5

Hbase0.90.6-cdh3u5

2.2程序设计标准

Java的程序设计标准很重要，原因在于它将提高开发团队各成员的代码的一致性。一

致性的提高会使代码更易懂得，这意味着它更易开发与保护。从而降低了应用程序的总开

发成本。

你务必牢记的是：你的Java代码在你已离开并开始另一个项目之后，会保留相当长的

一段时间。因此开发过程中一个很重要的目标就是要确保在开发成员或者开发团队之间的

工作能够顺利交接，不必花很大的力气便能懂得已编写的代码，以便继续保护与改进往常

的工作。假如代码难以懂得，很有可能被废弃与重写。S

2.2.1命名约定

我们将在整个标准中讨论命名约定，下列是几个基本点：

□使用能够准确说明变量/字段/类的完整的英文描述符

比如，使用类似firstName,grandTotal或者CorporateCustomer•这样的名

字。尽管象xLyl或者fn这样的名字很简短，输入起来容易，但是我们难以明白它

们代表什么、结果是什么含义，因而使代码难以懂得、保护与改进。

□使用该领域的术语

假如用户称他们的''客户"（clients）为''顾客"（customers）,那么就使用术语

Customer来命名这个类，而不用Client。许多程序开发者会犯的一个错误是，不去

使用工业或者领域里已经存在着很完美的术语时，却生造出一些普通词汇。

□使用大小写混合，提高名字的可读性

通常应该使用小写字母，但是类与接口的名字的首字母，与任何中间单词的首字

母应该大写。

□尽量少用缩写，但假如一定要使用，就要慎重地使用

这意味着应该保留一个标准缩写的列表，明智地从中选取，同时在使用时保持一

致。比如，想对单词"number”使用缩写，那么可从nbr,no或者者num中选取

一个，说明一下使用了哪一个（具体是哪个倒无所谓），同时只使用这一种形式。

□避免使用长名称（不超过15个字母）

比如：PhysicalOrVirtualProductOrService看起来大概是个不错的类名，但

是名字太长，应该考虑重新给它起个短一点的名字，比如象Offering。

□避免使用相似或者者仅在大小写上有区别的名字

比如，不应同时使用变量名persistentObject与persistentObjects及

anSqlDatabase与anSQLDatabase这样的名称

□避免使用下划线作为名字的首末字母

下列划线为首末字母的名字通常为系统保留，除预处理定义之外，通常不用作用

户命名。更重要的是，下划线经常造成烦恼而且难输入，因此尽量避免使用。

2.2.2包名，类名，方法名，属性名，常量名命名约定

□包命名

包命名全部使用小写英文字母，中间不同意有数字下划线等特殊字符。

□类，接口命名

类，接口名开头使用大写英文字母，多单词使用驼峰命名法。类名中不要使用下

划线与数字等特殊字符，正确的写法示例：HibernateDaoSupporto

假如表示特殊功能的类，在类名的末尾加上所要表示的功能英文名称，如：

****Listener,表示监听器等。

□方法命名

方法命名使用驼峰命名法，方法名中间不要使用下划线与数字等特殊字符，正确

的示例：processing。。

方法的参数与方法内部的局部参数可自定，符合要求就行。

□特殊Bean类的属性命名约定

Bean的属性命名规则严格使用驼峰命名法，不同意使用下划线，名字长度最长不

要超过15个字符，确实需要长名字时，适当缩写部分英文字母。

□常量属性命名

常量的命名规则通常为常量名全部使用大写字母，多单词之间使用下划线隔开，

不同意使用数字等特殊字符，同时常量的声明一定要是staticfinal的。

□普通类的属性命名

普通类的属性命名除常量依照常量命名法外，其他的属性的名字使用“英文名字

（首字母大写）”命名，多单词可使用驼峰命名法或者用下划线隔开。

2.2.3注释约定

本文还会对注释进行约定，有关注释风格能够在eclipse中导入codetemplates.xm

文件•下列是几个基本点：

□注释应该增加代码的清晰度

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

发人员懂得。

□假如你的程序不值得注释，那么它也很可能也不值得运行。

□保持注释的简洁

最好的注释应该是简单明了的注释。注释不必洋洋洒洒，只需提供足够的信息，

使别人能够懂得你的代码。

□先写注释，后写代码

写代码注释的最好方法是在写代码之前就写注释。这使你在写代码之前能够想想

代码的功能与运行。而且这样确保不可能遗漏注释。另一种方法是边写代码边写注释。

由于注释能够使代码更易懂得，因此在程序开发的过程中，也能够利用这一点。假如

打算花些时间写注释，那么至少你应从这个过程中获得些什么。

□注释信息不仅要包含代码的功能，还应给出原因

比如，下面例1中的代码显示金额在$1,000以上（包含$1,000）的定单可给

予5%的折扣。为什么要这样做呢？难道有一个商业法则规定大额定单能够得到折扣

吗？这种给大额定单的特殊是有的时候限的呢，还是一直都这样？最初的程序设计者

是否只是由于慷慨大度才这样做呢？除非它们在某个地方（或者者是在源代码本身，

或者者是在一个外部文档里）被注释出来，否则你不可能明白这些。

2.2.4快速浏览JavaDoc

Sun公司的JavaDevelopmentKit（JDK）中有一个名为javadoc的程序。它能

够处理Java的源代码文件，同时为Java程序产生HTML文件形式的外部注释文档。

Javadoc支持一定数目的标记，标识注释文档中各段起始位置的保留字。详情请参考JDK

javadoc文档。

标记用于目的

说明特定某一段程序代码的作者。每一个作者

@authorname类、接口

各有一个标记。

说明该类的应用程序编程接口(API)已被废

©deprecated类、成员函数。

弃，因此应不再使用。

©exceptionname说明由成员函数发出的特殊。一个特殊使用一

成员函数

description个标记，并要给出特殊的完整类名•

用来说明传递给一个成员函数的参数，其中包

@paramname

成员函数含参数的类型/类与用法。每个参数各有一个标

description

记。

若成员函数有返回值，对该返回值进行说明。

@returndescription成员函数

应说明返回值的类型/类与可能的用途。

说明自从有JDK1.1以来，该项已存在了多长

@since类、成员函数

时间。

类、接口、成员函在文档中生成指向特定类的超文本链接。能够

@seeClassName

数、字段同时应该使用完全合法的类名。

@see

类、接口、成员函在文档中生成指向特定成员函数的超文本链

ClassName#member

数、字段接。能够同时应该使用完全合法的类名。

functionName

©versiontext类、接口说明特定一段代码的版本信息。

你注释代码的方式很大地影响着你的工作效率与所有保护改进代码的后继开发者的工

作效率。在软件开发过程中及早注释代码，会促使你在开始撰写代码之前认真考虑这些代

码，从而带来更高的工作效率。而且，当你重新阅读数天前或者者数星期前所写的代码时,

你能够很容易地推断出当时你是怎么想的，由于这一切都有记录。

2.3开发规范

2.3.1项目结构说明

数据中心FDC项目使用多module式项目结构，其中包含如下项目，各项目模块功能

说明如下：

父模块模块依靠模块要紧业务功能描述

FDCFdc-commonnone提供FDC项目中公用框架包及公用工具包

FDCFdc-monitorFdc-common提供FDC项目中监控告警功能

FDCFdc-computeFdc-monitor,提供FDC项目中核心数据运算功能（包含

Fdc-commonETL,汇总，分发）。

FDCFdc-reportFdc-monitor,提供FDC项目中数据展现功能（报表展现，

Fdc-common短信、邮件展现，数据导出等）

2.3.2整体包结构说

包结构整体遵循按功能不一致分包，要紧表达出平台的整体架构。

1.常用的包结构如2.3.2常用包结构及命名。

2.各个模块包结构，如业务层，操纵层，持久层，特殊，模型POJO,常量类，工具类等.

这里的常用类与公共里的不一样假如各大模块在公共类里没有找到，能够在自己的

模块中自行扩展。达到遵循''开一闭"原则。

3.常用xml配置文件结构，如2.3.4配置文件包结构。

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

配置，系统级配置等。

5.自定义xml的scheme,dtd,与tld文件存放于Web根目录的WEB-INF文件夹下,

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

2・3.3项目模块包结构及命名

1.Fdc-common

说明：所有的缓存结构。比如平台所使用的Oscache与Ehcache缓存技术。

说明：各个技术层框架类。如下子包

controller：操纵层提供的共有框架类。

Module：数据bean公共基础类。

Business：业务层公共业务操纵类，提供通用功能。

Persistence：数据持久层公共数据操作类。

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

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

□configs

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

□Controller

说明：存放在操纵层下面的业务类。比如登陆，登出，角色切换等。

□Module

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

□Busines

说明：存放个业务层公共业务操纵类。下分各个子业务包。

□Persistence

说明：数据持久层数据操纵类。下分各个子业务包。

□extends

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

□Exceptions

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

按照各个层次结构包分完：功能包基本分为2个包：

1.各个层次的接口包。

2.关于接口的实现包。

2.3.5配置文件包结构

配置文件夹命名为configs,可存放在Web根目录下的WEB-INF文件夹下，也可放

在与javaclass文件根目录同级的目录下。configs目录下要紧包含下列目录结构：

□commons

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

□core/*

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

spring,struts,mybatis配置文件。

2.4命名规则

2.4.1共用类

公共用类要求以“功能英文名称（首字母大写）+Utils”驼峰命名。比如：日期的英文

名为date,按照规则要求，命名为：DateUtils。

2.4.2业务层

□业务层接口要求以I+''模块英文名称（首字母大写）”+Manager命名。比如：导

航菜单的英文名为navigator,按照规则要求，命名为:INavigatorManager；

□接口的实现类要求以''模块英文名称（首字母大写）”+Managerlmpl命名。比如:

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

NavigatorManagerlmpI；

2.4.3展现层

□基类要求以''模块英文名称（首字母大写）”+ActionBase命名。比如：导航菜单的

英文名为navigator,按照规则要求，命名为：NavigatorActionBase；

□查询模块列表类要求以List+''模块英文名称（首字母大写）”+s+Action命名。

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

ListNavigatorsAction；

□创建模块对象类要求以Create+''模块英文名称（首字母大写）"+Action命名。比

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

CreateNavigatorAction；

□修改模块对象类要求以Modify+''模块英文名称（首字母大写）”+Action命名。比

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

ModifyNavigatorAction；

□删除模块对象类要求以Remove+''模块英文名称（首字母大写）"+Action命名。

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

RemoveNavigatorAction；

□对模块对象的操作类要求以''模块英文名称（首字母大写）”+Operator+Action

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

NavigatorOperatorAction。

2.4.4模型层

□模型层存放的是实体类，要求以''模块实体英文名称（首字母大写）”命名。比如：导

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

□属性字段参照Bean属性命名规则。

2.4.5持久层

□dao接口要求以I+''模块英文名称（首字母大写）”+DAO命名。比如：导航菜单

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

□接口的实现类要求以''模块英文名称（首字母大写）"+DAOImpI命名.比如：导航

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

2.4.6XML配置

要紧配置文件包含spring.xml,struts.xml,mybatis.xml等。

由于这些文件都是分包存放，因此配置文件统一为spring.xml,struts.xml,

mybatis.xml,假如模块内的spring,struts,mybatis配置较多时，需要分文件来写，

那么可直接在spring,struts,mybatis的后面直接加连接号+名字来命名。如

spring-common.xmlo

各模块的mybatissqlmap配置文件放到相应模块的Model包下，一个域模型对应一

个sqlMap配置文件，如域模型名为Item,则与域模型相对应的sqlMap文件名为

Item.xmL

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

Module

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

的根节点，也就是设置parentModeulId为#号，然后它的子节点能够设置相应的

父节点为managerllserModule,»

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

□viewType：查看类型，是指要说明此模块节点是要在前台显示还是后台管理的。

□imgURL：指当我们把这些模块展示在有关树上显示的图标链接。

Fuction

□确定包含的功能，如增加用户：addUsero

Method

□增加用户的入口方法：saveAddUsero

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

点是用来推断最后的后缀，假如是点结尾程序会自动补齐访问链接的后缀，假如是

其他后缀直接访问这个链接。

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

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

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

struts-xxx（模块名层）。

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

与权限关联由过滤器推断命名空间管理权限功能。凡是命名空间在

/public/common这个路径下的系统定义为前台没有权限管理的访问链接，凡是

命名空间在/manage/common这个路径下的系统定义为后台没有权限管理的访

问链接。在这个两个路径下面访问的地址，过滤器不作权限推断。其它访问地址会

根据rights中配置定义的权限进行过滤。

□extends：在struts配置中需要考虑各类拦截器与错误处理跳转，配置在

struts-interceptor.xml这个文件。

Action

□name：定义action被访问的id命名规范与定义java变量同样的规范。

□class：就是我们在spring.xml文件已经配置了注入actionspringbean的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***开头，配合事务中的配置，多单词使

用驼峰命名法。可在这些元素中使用复合查询配置。

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

名，使用驼峰命名法。

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

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

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

查询。

5、ehcache.xml平台ehcache缓存实现配置文件

6、system-config.xml平台系统配置文件

2.4.7资源文件

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

□perties公共日志配置文件。

□perties平台数据连接，基本参数配置等。

□Iperties平台日志输出储存等有关设置的配置文件。

□perties平台调度组件有关设置的配置文件。

□perties平台oscache缓存实现配置文件

□perties平台struts组件有关系统配置文件（国际化、上传等）。

国际化资源文件使用标准JSTL标签绑定。通过不一致的local读取不一致语言的有关

资源，国际化资源文件中key的定义规则：模块名称.功能名称.key描述，但此全部小写，

多个单词之间用下划线分割。国际化资源配置文件进行分割处理，属于本功能模块的国际

化资源文件放到本模块的根包下，在JSP中使用JSTL标签的＜fmt:messagebundle*'"

/＞调用，在文件开头处加上＜fmt:setBundlebasename='"'/＞设置。

全局国际化配置文件如下（直接设置在perties文件中）：

□messages开头的资源文件包含有关的国际化资源内容。

□exceptionMessages开头的资源文件包含特殊处理描述的国际化资源内容。

各功能模块的国际化配置文件使用如下：

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

search_message.properties.,

□在JSP文件最开头处使用标签＜fmt:setBundlebasename=""/＞设置全局

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

范围。

□在位于setBundle设置后使用＜fmt:messagekey=""＞标签可直接使用该资源

文件中的key属性。

2.4.8JSP文件

□JSP文件统一存放在应用的Web根目录下，即与WEB-INF文件夹同级。

□文件夹名按照java关于的功能模块名来设置，文件夹名全部使用小写字母。

□JSP文件名以“自定英文名（首字母小写）++功能名”命名，多单词英文可

使用驼峰命名法。

2.4.9事务命名约束

平台中，所有关于事务处理的，务必遵循下列命名规则：

□储存/填加：以save开头。

□修改：以update开头。

□删除：以delete开头。

□获取：以get开头。

□查找：以find开头。

2.4.T0JS命名约束

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

3数据库技术规范

3.1概述

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

3.2命名基本规则

针对不一致工程模块使用不一致的数据命名。

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

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

正式运行数据库：系统名。$n：computeo

3.3数据库表空间

3.3.1命名基本规则

表空间:tbs_+系统名。如：tbs_computeo

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

3.4默认用户方案

Username：raysdata/root

Password：raysdata/root

3.5表的命名规则、约定

命名基本规则

按照表在当前数据仓库内不一致数据职能划分，所有字母均大写:

字典定义类表以D开头；如：DDIM。

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

P_ITEM_IDT«

数据汇总类表以6_开头，拥有数据维度的，将维度名称使用"」’分割，拼合在表名称

中；如：G_ITEM_VSN

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

3.6视图的命名规则、约定

命名基本规则

Vi一视图的类型（模块名）一英文单词一英文单词一

比如:vi_base_message<>

3.7字段命名规则、约定

命名基本规则

英文单词一英文单词一英文单词一...

比如：message_id>message_nameo

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

命名基本规则

USP一英文单词一英文单词一...

比如：usp_message

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

命名基本规则

seq英文单词英文单词

如：seq_base_message。

3.10触发器命名规则、约定

命名基本规则

trigger.英文单词—英文单词_

如：trigger_message。

4HIVE技术规范

i.按照表在当前数据仓库内不一致数据职能划分，所有字母均大写：

字典定义类表以D_开头；如：D_DIM«

关系定义类表以P一开头，当前表示关系类名称中间以“，分割，表示两者关系；如：

P_ITEM_IDTo

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

数据汇总类表以GJf头，拥有数据维度的，将维度名称使用“.“分割，拼合在表名称

中；如：G_ITEM_VSN

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

2.数据路径

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

5HBase设计规范

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

层面的。

Hbase中与表结构有关的逻辑模型涉及到下列几个词汇：命名空

间、表、列族、歹h行键、版本等，这些是构建hbase表的所有元素。

下文就根据这几个关键词汇，陈述下有关的规范。

5.1Namespace命名空间设计

HBase默认的命名空间是default,默认情况下，假如在创建表时没有

显式地指定命名空间，那么表将创建在default命名空间下。假如表隶

属于某个非默认的命名空间，那么在引用表（譬如读取表数据）时，就

务必指定命名空间，否则将出现类似''无法定位到表〃的错误，完整表名

的格式为''命名空间名称:表名称〃，譬如"DLQX:SYSTEM_USER〃；假

如是默认的命名空间，则完整表名也能够省略掉''default:",直接拼写

表名SYSTEM_USER即可。

命名空间与表的关系，能够用下图表示:

、

NameSpace

命名空间

命名空间与表之间是一对多的关系，即一个命名空间下面能够包含多个

hbase表，但一个hbase表只能属于一个命名空间。在创建表时，假

如没有指定命名空间(或者者命名空间为空)，则系统会将此hbase

表放置在默认命名空间(default)下。

另外，删除命名空间之前，务必先删除掉此命名空间下的所有hbase

表，否则将无法删除此命名空间。

5.21.2.Table表设计

HBase有几个高级特性，在你设计表时能够使用。这些特性不一定联

系到模式或者行键设计，但是它们定义了某些方面的表行为。

5.2.1理想HBase表

Hbase作为列数据库，根据官方的说法，在性能与效率上更擅长处理

''高而瘦〃的表，而非''矮而胖"的表。所谓''高而瘦"，是指表的列的数量

较少，但是行的数量极大，从而使表展现出一种又高又瘦的形象。所谓

''矮而胖"，是指表的列的数据居多，但是行的数量却有限，给人一种又

矮又胖的形象，尽管hbase表号称可容纳百万列，但是那也仅仅限于

理论上的极限，在实际应用中，请尽量构建''高而瘦〃的表，同时需要对

列的数量进行测试，以避免过度影响读写性能。

522预创建分区

默认情况下，在创建HBase表的时候会自动创建一个region分区，

当导入数据的时候，所有的HBase客户端都向这一个region写数据,

直到这个region足够大了才进行切分。一种能够加快批量写入速度的

方法是通过预先创建一些空的regions,这样当数据写入HBase时，

会按照region分区情况，在集群内做数据的负载均衡。

523列族数量

不要在一张表里定义太多的columnfamilyo目前Hbase并不能很

好的处理超过2~3个columnfamily的表。由于某个columnfamily

在flush的时候，它邻近的columnfamily也会因关联效应被触发

flush,最终导致系统产生更多的I/O。因此，根据官方的建议，一个

HBase表中创建一个列族即可。

5.2.4可配置的数据块大小

HFile数据块大小能够在列族层次设置。这个数据块不一致于HDFS数

据块。其默认值是65,536字节，或者64KB。数据块索引存储每个

HFile数据块的起始键。数据块大小设置影响到数据块索引的大小。数

据块越小，索引越大，从而占用更大内存空间。同时由于加载进内存的

数据块更小，随机查找性能更好。但是假如你需要更好的序列扫描性能,

那么一次能够加载更多HFile数据进入内存则更为合理，这意味着数据

块应该设置为更大的值。相应地索引变小，你将在随机读性能上付出代

价。

5.2.5数据块缓存

把数据放进读缓存，但工作负载却经常不能从中获得性能提升。比如，

假如一张表或者表里的列族只被顺序化扫描访问或者者很少被访问，你

不可能介意Get或者Scan花费时间是否有点儿长。在这种情况下，

你能够选择关闭那些列族的缓存。假如你只是执行很多顺序化扫描，你

会多次倒腾缓存，同时可能会滥用缓存把应该放进缓存获得性能提升的

数据给排挤出去。假如关闭缓存，你不仅能够避免上述情况发生，而且

能够让出更多缓存给其他表与同一表的其他列族使用。

5.2.6激进缓存

你能够选择一些列族，给予它们在数据块缓存里有更高的优先级（LRU

缓存）。假如你预期一个列族比另一个列族随机读更多，这个特性迟早

用得上。

IN_MEMORY参数的默认值是falseo由于HBase除了在数据块缓存

里储存这个列族相比其他列族更激进之外并不提供额外的保证，该参数

在实践中设置为true不可能变化太大。

创建表的时候，能够通过HColumnDescriptor.setinMemory(true)

将表放到Regionserver的缓存中，保证在读取的时候被cache命中。

5.2.7布隆过滤器(Bloomfilters)

数据块索引提供了一个有效的方法，在访问一个特定的行时用来查找应

该读取的HFile的数据块。但是它的效用是有限的。HFile数据块的默

认大小是64KB,这个大小不能调整太多。

假如你要查找一个短行，只在整个数据块的起始行键上建立索引无法给

你细粒度的索引信息。比如，假如你的行占用100字节存储空间，一

个64KB的数据块包含(64*1024)/100=655.53=~700行，而

你只能把起始行放在索引位上。你要查找的行可能落在特定数据块上的

行区间里，但也不是确信存放在那个数据块上。这有多种情况的可能，

或者者该行在表里不存在，或者者存放在另一个HFile里，甚至在

MemStore里。这些情况下，从硬盘读取数据块会带来10开销，也会

滥用数据块缓存。这会影响性能，特别是当你面对一个巨大的数据集同

时有很多并发读用户时。

布隆过滤器同意你对存储在每个数据块的数据做一个反向测试。当某行

被请求时，先检查布隆过滤器看看该行是否不在这个数据块。布隆过滤

器要么确定回答该行不在，要么回答它不明白。这就是为什么我们称它

是反向测试。布隆过滤器也能够应用到行里的单元上。当访问某列标识

符时先使用同样的反向测试。

布隆过滤器也不是没有代价。存储这个额外的索引层次占用额外的空

间。布隆过滤器随着它们的索引对象数据增长而增长，因此行级布隆过

滤器比列标识符级布隆过滤器占用空间要少。当空间不是问题时，它们

能够帮助你榨干系统的性能潜力。

你能够在列族上打开布隆过滤器，如下所示：

hbase(main)>create

,

'mytable',{NAME=>'colfamlzBLOOMFILTER=>'ROWCOL'}

BLOOMFILTER参数的默认值是NONE。一个行级布隆过滤器用ROW

打开，列标识符级布隆过滤器用ROWCOL打开。行级布隆过滤器在数

据块里检查特定行键是否不存在，列标识符级布隆过滤器检查行与列标

识符联合体是否不存在。ROWCOL布隆过滤器的开销高于ROW布隆

过滤器。

528生存时间(TTL)

应用系统经常需要从数据库里删除老数据。由于数据库很难超过某种规

模，因此传统上数据库内建了许多灵活处理办法。比如，在TwitBase

里你不愿意删除用户在使用应用系统期间生成的任何推帖。这些都是用

户生成数据，将来有一天当你执行一些高级分析时可能有用。但是并不

需要储存所有推帖用于实时访问。因此早于某个时间的推帖能够归档存

放到平面文件里。

HBase能够让你在数秒内在列族级别设置一个TTL。早于指定TTL值

的数据在下一次大合并时会被删除。假如你在同一单元上有多个时间版

本，早于设定TTL的版本会被删除。你能够关闭TTL或者者通过设置

其值为INT.MAX_VALUE(2147483647)来让它永远打开(这是默认

值)。你能够在建表时设置TTL,如下所示：

hbase(main)>create

,

'mytable',{NAM