数据中心产品开发规范

数据中心产品开发标准XXXX公司XX业务部XXXX年XX月文档说明本文档所涉及到的文字、图表等，仅限于内部使用，未经双方书面许可，请勿扩散到第三方。文档属性属性内容客户名称：工程名称：SUBJECT文档主题：文档编号：文档版本：版本日期：文档状态：文档变更版本修订日期修订人描述文档送呈单位姓名目的审阅参阅目录TOC\o"1-5"\h\z\u1 概述 51.1 最根本原那么 52 Java技术标准 62.1 平台使用的相关技术 6 根本核心框架包 6 其他框架包 62.2 程序设计标准 7 命名约定 8 包名，类名，方法名，属性名，常量名命名约定 9 注释约定 10 快速浏览JavaDoc 112.3 开发标准 12 工程结构说明 12 整体包结构说 12 工程模块包结构及命名 13 各子工程模块功能包结构 14 配置文件包结构 142.4 命名规那么 15 共用类 15 业务层 15 展现层 15 模型层 16 持久层 16 XML配置 16 资源文件 19 JSP文件 20 事务命名约束 20 JS命名约束 213 数据库技术标准 223.1 概述 223.2 命名根本规那么 223.3 数据库表空间 22 命名根本规那么 223.4 默认用户方案 223.5 表的命名规那么、约定 223.6 视图的命名规那么、约定 233.7 字段命名规那么、约定 233.8 存储过程的命名规那么、约定 233.9 序列对象的命名规那么、约定 243.10 触发器命名规那么、约定 244 HIVE技术标准 255 HBase设计标准 265.1 Namespace命名空间设计 265.2 1.2.Table表设计 27 理想HBase表 27 预创立分区 28 列族数量 28 可配置的数据块大小 29 数据块缓存 29 激进缓存 29 布隆过滤器〔Bloomfilters〕 30 生存时间〔TTL〕 31 数据压缩 32 数据分割 33 单元时间版本 345.3 ColumnFamily列族设计 355.4 Qualifier列设计 365.5 版本设计 375.6 HBase命名标准 37概述本文提供一整套编写高效可靠的Java代码的标准、约定和指南。它们以平安可靠的软件工程原那么为根底，使代码易于理解、维护和增强。而且，通过遵循这些程序设计标准，你作为一个Java软件开发者的生产效率会有显著提高。经验证明，假设从一开始就花时间编写高质量的代码，那么在软件开发阶段，对代码的修改要容易很多。最后，遵循一套通用的程序设计标准将带来更大的一致性，使软件开发团队的效率明显提高。最根本原那么运用常识当找不到任何规那么或指导方针，当规那么明显不能适用，当所有的方法都失效的时侯：运用常识并核实这些根本原那么。这条规那么比其它所有规那么都重要。驼峰命名法驼峰命名法〔Camel-Case〕：就是当变量名或函式名是由一个或多个单字连结在一起，而构成的唯一识别字时，第一个单字以小写字母开始；第二个单字的首字母大写或每一个单字的首字母都采用大写字母，例如：myFirstName、myLastName，这样的变量名看上去就像骆驼峰一样此起彼伏，故得名。驼峰命名法的命名规那么可视为一种惯例，并无绝对与强制，目的是增加识别和可读性。Java技术标准平台使用的相关技术平台使用的框架包分核心框架包和其他必须的框架包，各框架包本身所依赖的开源包不做列举，由框架包本身的信息来定。根本核心框架包平台采用Spring+Struts2+myBatis的三层架构作为根本框架。〔JDK1.6+〕。参考如下：名称版本备注Struts22.2.1Springmybatis-core不支持跨数据库建议，目前开发在mysql上，现网环境在db2上mybatis-springMySQL5.0Tomcat7.0jQuery1.8其他框架包除根本框架外，平台其他将采用的一些框架包，参考如下：〔JDK1.5+〕名称版本备注SpringSecurityApacheCommons2.6常用的工具包等SLF4JApacheLogginglog4j5ApacheAntOscacheXMemcacheC3P0Dom4j2.0commons-beanutilsMybatis-springHadoop-coreHive-cliHbase程序设计标准Java的程序设计标准很重要，原因在于它将提高开发团队各成员的代码的一致性。一致性的提高会使代码更易理解，这意味着它更易开发和维护。从而降低了应用程序的总开发本钱。你必须牢记的是：你的Java代码在你已离开并开始另一个工程之后，会保存相当长的一段时间。因此开发过程中一个很重要的目标就是要确保在开发成员或开发团队之间的工作可以顺利交接，不必花很大的力气便能理解已编写的代码，以便继续维护和改良以前的工作。如果代码难以理解，很有可能被废弃和重写。s命名约定我们将在整个标准中讨论命名约定，以下是几个根本点：使用可以准确说明变量/字段/类的完整的英文描述符例如，采用类似firstName，grandTotal或CorporateCustomer这样的名字。虽然象x1，y1或fn这样的名字很简短，输入起来容易，但是我们难以知道它们代表什么、结果是什么含义，因而使代码难以理解、维护和改良。采用该领域的术语如果用户称他们的“客户”(clients)为“顾客”(customers)，那么就采用术语Customer来命名这个类，而不用Client。许多程序开发者会犯的一个错误是，不去使用工业或领域里已经存在着很完美的术语时，却生造出一些普通词汇。采用大小写混合，提高名字的可读性一般应该采用小写字母，但是类和接口的名字的首字母，以及任何中间单词的首字母应该大写。尽量少用缩写，但如果一定要使用，就要谨慎地使用这意味着应该保存一个标准缩写的列表，明智地从中选取，并且在使用时保持一致。例如，想对单词“number”采用缩写，那么可从nbr，no或者num中选取一个，说明一下采用了哪一个〔具体是哪个倒无所谓〕，并且只使用这一种形式。防止使用长名称〔不超过15个字母〕例如：PhysicalOrVirtualProductOrService看起来似乎是个不错的类名，但是名字太长，应该考虑重新给它起个短一点的名字，比方象Offering。防止使用相似或者仅在大小写上有区别的名字例如，不应同时使用变量名persistentObject和persistentObjects及anSqlDatabase和anSQLDatabase这样的名称防止使用下划线作为名字的首末字母以下划线为首末字母的名字通常为系统保存，除预处理定义之外，一般不用作用户命名。更重要的是，下划线经常造成麻烦而且难输入，所以尽量防止使用。包名，类名，方法名，属性名，常量名命名约定包命名包命名全部使用小写英文字母，中间不允许有数字下划线等特殊字符。类，接口命名类，接口名开头使用大写英文字母，多单词使用驼峰命名法。类名中不要使用下划线和数字等特殊字符，正确的写法例如：HibernateDaoSupport。如果表示特殊功能的类，在类名的末尾加上所要表示的功能英文名称，如：****Listener，表示监听器等。方法命名方法命名使用驼峰命名法，方法名中间不要使用下划线和数字等特殊字符，正确的例如：processing()。方法的参数以及方法内部的局部参数可自定，符合要求就行。特殊Bean类的属性命名约定Bean的属性命名规那么严格使用驼峰命名法，不允许使用下划线，名字长度最长不要超过15个字符，确实需要长名字时，适当缩写局部英文字母。常量属性命名常量的命名规那么一般为常量名全部采用大写字母，多单词之间使用下划线隔开，不允许使用数字等特殊字符，并且常量的声明一定要是staticfinal的。普通类的属性命名普通类的属性命名除常量依照常量命名法外，其他的属性的名字使用“英文名字〔首字母大写〕”命名，多单词可使用驼峰命名法或用下划线隔开。注释约定本文还会对注释进行约定，相关注释风格可以在eclipse中导入codetemplates.xm文件。以下是几个根本点：注释应该增加代码的清晰度代码注释的目的是要使代码更易于被同时参与程序设计的开发人员以及其他后继开发人员理解。如果你的程序不值得注释，那么它也很可能也不值得运行。保持注释的简洁最好的注释应该是简单明了的注释。注释不必洋洋洒洒，只需提供足够的信息，使别人能够理解你的代码。先写注释，后写代码写代码注释的最好方法是在写代码之前就写注释。这使你在写代码之前可以想想代码的功能和运行。而且这样确保不会遗漏注释。另一种方法是边写代码边写注释。因为注释可以使代码更易理解，所以在程序开发的过程中，也可以利用这一点。如果打算花些时间写注释，那么至少你应从这个过程中获得些什么。注释信息不仅要包括代码的功能，还应给出原因例如，下面例1中的代码显示金额在$1,000以上〔包括$1,000〕的定单可给予5%的折扣。为什么要这样做呢？难道有一个商业法那么规定大额定单可以得到折扣吗？这种给大额定单的特殊是有时限的呢，还是一直都这样？最初的程序设计者是否只是由于慷慨大度才这样做呢？除非它们在某个地方〔或者是在源代码本身，或者是在一个外部文档里〕被注释出来，否那么你不可能知道这些。快速浏览JavaDocSun公司的JavaDevelopmentKit(JDK)中有一个名为javadoc的程序。它可以处理Java的源代码文件，并且为Java程序产生HTML文件形式的外部注释文档。Javadoc支持一定数目的标记，标识注释文档中各段起始位置的保存字。详情请参考JDKjavadoc文档。标记用于目的@authorname类、接口说明特定某一段程序代码的作者。每一个作者各有一个标记。@deprecated类、成员函数。说明该类的应用程序编程接口(API)已被废弃，因此应不再使用。@exceptionnamedescription成员函数说明由成员函数发出的异常。一个异常采用一个标记，并要给出异常的完整类名。@paramnamedescription成员函数用来说明传递给一个成员函数的参数，其中包括参数的类型/类和用法。每个参数各有一个标记。@returndescription成员函数假设成员函数有返回值，对该返回值进行说明。应说明返回值的类型/类和可能的用途。@since类、成员函数说明自从有JDK1.1以来，该项已存在了多长时间。@seeClassName类、接口、成员函数、字段在文档中生成指向特定类的超文本链接。可以并且应该采用完全合法的类名。@seeClassName#memberfunctionName类、接口、成员函数、字段在文档中生成指向特定成员函数的超文本链接。可以并且应该采用完全合法的类名。@versiontext类、接口说明特定一段代码的版本信息。你注释代码的方式很大地影响着你的工作效率以及所有维护改良代码的后继开发者的工作效率。在软件开发过程中及早注释代码，会促使你在开始撰写代码之前仔细考虑这些代码，从而带来更高的工作效率。而且，当你重新阅读数天前或者数星期前所写的代码时，你可以很容易地判断出当时你是怎么想的，因为这一切都有记录。开发标准工程结构说明数据中心FDC工程采用多module式工程结构，其中包含如下工程，各工程模块功能说明如下：父模块模块依赖模块主要业务功能描述FDCFdc-commonnone提供FDC工程中公用框架包及公用工具包FDCFdc-monitorFdc-common提供FDC工程中监控告警功能FDCFdc-computeFdc-monitor,Fdc-common提供FDC工程中核心数据运算功能〔包括ETL，汇总，分发〕。FDCFdc-reportFdc-monitor,Fdc-common提供FDC项目中数据展现功能〔报表展现，短信、邮件展现，数据导出等〕整体包结构说包结构整体遵循按功能不同分包，主要表达出平台的整体架构。常用的包结构如HYPERLINK常用包结构及命名。各个模块包结构，如业务层，控制层，持久层，异常，模型POJO，常量类，工具类等。这里的常用类和公共里的不一样如果各大模块在公共类里没有找到，可以在自己的模块中自行扩展。到达遵循“开—闭”原那么。常用xml配置文件结构，如HYPERLINK配置文件包结构。平台核心的配置文件，存放在包的根目录，如国际化，数据库连接，日志配置，缓存配置，系统级配置等。自定义xml的scheme，dtd，以及tld文件存放于Web根目录的WEB-INF文件夹下，文件名全部使用小写字母。工程模块包结构及命名Fdc-common.cache说明：所有的缓存结构。例如平台所使用的Oscache和Ehcache缓存技术。.framework说明：各个技术层框架类。如下子包 controller：控制层提供的共有框架类。 Module：数据bean公共根底类。 Business：业务层公共业务控制类，提供通用功能。 Persistence：数据持久层公共数据操作类。.utils说明：存放根本常用的类。例如文件类，字符串类等。Fdc-moniter,Fdc-compute,Fdc-reportconfigs说明：该包存放所有关于读取配置信息的类Controller说明：存放在控制层下面的业务类。例如登陆，登出，角色切换等。Module说明：存放各个业务数据bean类。下分各个子业务包。Busines说明：存放个业务层公共业务控制类。下分各个子业务包。Persistence说明：数据持久层数据控制类。下分各个子业务包。extends说明:平台扩展功能类。下分子包，第一级子包名表示扩展功能模块名。Exceptions各子工程模块功能包结构按照各个层次结构包分完：功能包根本分为2个包：各个层次的接口包。对于接口的实现包。配置文件包结构配置文件夹命名为configs，可存放在Web根目录下的WEB-INF文件夹下，也可放在与javaclass文件根目录同级的目录下。configs目录下主要包含以下目录结构：commons存放公共的Xml配置文件，如：struts,spring,mybatis等的xml配置文件。core/*存放平台核心模块，各功能模块，扩展功能模块的所需的配置文件。如各模块的spring，struts，mybatis配置文件。命名规那么共用类公共用类要求以“功能英文名称(首字母大写)+Utils”驼峰命名。例如：日期的英文名为date，按照规那么要求，命名为：DateUtils。业务层业务层接口要求以I+“模块英文名称(首字母大写)”+Manager命名。例如：导航菜单的英文名为navigator，按照规那么要求，命名为：INavigatorManager；接口的实现类要求以“模块英文名称(首字母大写)”+ManagerImpl命名。例如：导航菜单的英文名为navigator，按照规那么要求，命名为：NavigatorManagerImpl；展现层基类要求以“模块英文名称(首字母大写)”+ActionBase命名。例如：导航菜单的英文名为navigator，按照规那么要求，命名为：NavigatorActionBase；查询模块列表类要求以List+“模块英文名称(首字母大写)”+s+Action命名。例如：导航菜单的英文名为navigator，按照规那么要求，命名为：ListNavigatorsAction；创立模块对象类要求以Create+“模块英文名称(首字母大写)”+Action命名。例如：导航菜单的英文名为navigator，按照规那么要求，命名为：CreateNavigatorAction；修改模块对象类要求以Modify+“模块英文名称(首字母大写)”+Action命名。例如：导航菜单的英文名为navigator，按照规那么要求，命名为：ModifyNavigatorAction；删除模块对象类要求以Remove+“模块英文名称(首字母大写)”+Action命名。例如：导航菜单的英文名为navigator，按照规那么要求，命名为：RemoveNavigatorAction；对模块对象的操作类要求以“模块英文名称(首字母大写)”+Operator+Action命名。例如：导航菜单的英文名为navigator，按照规那么要求，命名为：NavigatorOperatorAction。模型层模型层存放的是实体类，要求以“模块实体英文名称(首字母大写)”命名。例如：导航菜单的英文名为navigator，按照规那么要求，命名为：Navigator；属性字段参照Bean属性命名规那么。持久层dao接口要求以I+“模块英文名称(首字母大写)”+DAO命名。例如：导航菜单的英文名为navigator，按照规那么要求，命名为：INavigatorDAO；接口的实现类要求以“模块英文名称(首字母大写)”+DAOImpl命名。例如：导航菜单的英文名为navigator，按照规那么要求，命名为：NavigatorDAOImpl。XML配置主要配置文件包括spring.xml,struts.xml,mybatis.xml等。由于这些文件都是分包存放，所以配置文件统一为spring.xml，struts.xml，mybatis.xml。如果模块内的spring，struts，mybatis配置较多时，需要分文件来写，那么可直接在spring，struts，mybatis的后面直接加连接号“-”+名字来命名。如spring-common.xml。各模块的mybatissqlmap配置文件放到相应模块的Model包下，一个域模型对应一个sqlMap配置文件，如域模型名为Item，那么与域模型相对应的sqlMap文件名为Item.xml。spring.xml平台Spring相关组件配置。Module需要新建一个用户管理模块managerUserModule，设置其父节点是后台管理树的根节点，也就是设置parentModeulId为#号，然后它的子节点可以设置相应的父节点为managerUserModule,。ationURL：指用来访问这个相关模块的命名空间。viewType：查看类型，是指要说明此模块节点是要在前台显示还是后台管理的。imgURL：指当我们把这些模块展示在相关树上显示的图标链接。Fuction确定包含的功能，如增加用户：addUser。Method增加用户的入口方法：saveAddUser。actionUR：指这个入口方法在当前模块命名空间下的访问地址createUser.加一个点是用来判断最后的后缀，如果是点结尾程序会自动补齐访问链接的后缀，如果是其他后缀直接访问这个链接。isDefault：是否默认入口，一个模块功能只能有一个方法作为默认入口。struts.xml平台struts组件相关配置，开发相关模块的时候注意相关标准package：我们可以在模块中定义包以防止命名空间重复，命名规那么：struts-xxx(模块名层)。namespace：相关模块的命名空间。这里涉及几个需要注意的地方：这个链接会和权限关联由过滤器判断命名空间管理权限功能。但凡命名空间在/public/common这个路径下的系统定义为前台没有权限管理的访问链接，但凡命名空间在/manage/common这个路径下的系统定义为后台没有权限管理的访问链接。在这个两个路径下面访问的地址，过滤器不作权限判断。其它访问地址会根据rights中配置定义的权限进行过滤。extends：在struts配置中需要考虑各种拦截器和错误处理跳转，配置在struts-interceptor.xml这个文件。Actionname：定义action被访问的id命名标准与定义java变量同样的标准。class：就是我们在spring.xml文件已经配置了注入actionspringbean的id。result：struts处理跳转，两种跳转方式dispatcher转向和redirect重定向。interceptor-ref：所使用的拦截器。在struts-interceptor.xml这个文件有相关注释。mybatis.xml，平台myBATIS相关组件配置配置sqlMap元素的resource属性，指示域模型对应的SQL配置文件的包全路径。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属性名以“功能英文名〔首字母小写〕+Procedure”命名，使用驼峰命名法。sql元素的id属性名以“自定义英文名字〔首字母小写〕”命名。多个单词可使用下划线或使用驼峰命名法。statement元素的id属性名与sql元素命名规那么一致。statement主要配置复合查询。ehcache.xml平台ehcache缓存实现配置文件system-config.xml平台系统配置文件资源文件平台properties以及国际化资源配置文件perties公共日志配置文件。perties平台数据连接，根本参数配置等。perties平台日志输出保存等相关设置的配置文件。perties平台调度组件相关设置的配置文件。perties平台oscache缓存实现配置文件perties平台struts组件相关系统配置文件〔国际化、上传等〕。国际化资源文件使用标准JSTL标签绑定。通过不同的local读取不同语言的相关资源，国际化资源文件中key的定义规那么：模块名称.功能名称.key描述，但此全部小写，多个单词之间用下划线分割。国际化资源配置文件进行分割处理，属于本功能模块的国际化资源文件放到本模块的根包下，在JSP中使用JSTL标签的<fmt:messagebundle=””/>调用，在文件开头处加上<fmt:setBundlebasename=””/>设置。全局国际化配置文件如下〔直接设置在perties文件中〕：messages开头的资源文件包含相关的国际化资源内容。exceptionMessages开头的资源文件包含异常处理描述的国际化资源内容。各功能模块的国际化配置文件使用如下：文件名使用“功能模块名+”_”+messages”命名，如search_perties。在JSP文件最开头处使用标签<fmt:setBundlebasename=””/>设置全局bundle，其中basename属性名为模块资源文件所在的包全路径，scope为使用范围。在位于setBundle设置后使用<fmt:messagekey=””>标签可直接使用该资源文件中的key属性。JSP文件JSP文件统一存放在应用的Web根目录下，即与WEB-INF文件夹同级。文件夹名按照java对于的功能模块名来设置，文件夹名全部使用小写字母。JSP文件名以“自定英文名〔首字母小写〕+“_”+功能名”命名，多单词英文可使用驼峰命名法。事务命名约束平台中，所有关于事务处理的，必须遵循以下命名规那么：保存/填加：以save开头。修改：以update开头。删除：以delete开头。获取：以get开头。查找：以find开头。JS命名约束与Java命名一致，但JS文件名可小写，甚至可以加下划线等特殊符号。数据库技术标准概述本标准目前只适合局部数据库的相关定义。命名根本规那么针对不同工程模块采用不同的数据命名。开发时数据库：dev+系统名。如：devcompute。试运行数据库：test+系统名。如：testcompute。正式运行数据库：系统名。如：compute。数据库表空间命名根本规那么表空间：tbs_+系统名。如：tbs_compute。临时表空间：tbs_+系统名+tempspace。如：tbs_computetempspace。默认用户方案Username：raysdata/rootPassword：raysdata/root表的命名规那么、约定命名根本规那么按照表在当前数据仓库内不同数据职能划分，所有字母均大写：字典定义类表以D_开头；如：D_DIM。关系定义类表以P_开头，当前表示关系类名称中间以“_”分割，表示两者关系；如：P_ITEM_IDT。数据汇总类表以G_开头，拥有数据维度的，将维度名称采用”_”分割，拼合在表名称中；如：G_ITEM_VSN对前端报表支持表以R_开头，名称采用各报表业务名称定义，如：R_CONFIG_LOG视图的命名规那么、约定命名根本规那么vi_视图的类型〔模块名〕_英文单词_英文单词_...例如：vi_base_message。字段命名规那么、约定命名根本规那么英文单词_英文单词_英文单词_...例如：message_id、message_name。存储过程的命名规那么、约定命名根本规那么usp_英文单词_英文单词_...例如：usp_message序列对象的命名规那么、约定命名根本规那么seq_英文单词_英文单词_如：seq_base_message。触发器命名规那么、约定命名根本规那么trigger_英文单词_英文单词_如：trigger_message。HIVE技术标准按照表在当前数据仓库内不同数据职能划分，所有字母均大写：字典定义类表以D_开头；如：D_DIM。关系定义类表以P_开头，当前表示关系类名称中间以“_”分割，表示两者关系；如：P_ITEM_IDT。数据集成类表以FACT_开头，使用相关业务定义名称，如：FACT_数据汇总类表以G_开头，拥有数据维度的，将维度名称采用”_”分割，拼合在表名称中；如：G_ITEM_VSN对前端报表支持表以R_开头，名称采用各报表业务名称定义，如：R_CONFIG_LOG数据路径数据路径内全部按照大写定义路径字符。HBase设计标准介绍了HBase应用开发时建议遵循的设计标准，主要是针对开发层面的。Hbase中与表结构相关的逻辑模型涉及到以下几个词汇：命名空间、表、列族、列、行键、版本等，这些是构建hbase表的所有元素。下文就依据这几个关键词汇，陈述下相关的标准。Namespace命名空间设计通俗地讲，命名空间可视为表组〔与Oracle中的表空间类似〕，划分依据不固定，可依据业务类型划分，也可依据时间周期划分。譬如，针对电力气象方面的数据表，可以创立一个电力气象的命名空间，取名为DLQX，将电力气象相关的表都组织在此命名空间下面。引进命名空间的好处就是方便对表进行组织管理。HBase默认的命名空间是default，默认情况下，如果在创立表时没有显式地指定命名空间，那么表将创立在default命名空间下。如果表隶属于某个非默认的命名空间，那么在引用表〔譬如读取表数据〕时，就必须指定命名空间，否那么将出现类似“无法定位到表”的错误，完整表名的格式为“命名空间名称:表名称”，譬如”DLQX:SYSTEM_USER”；如果是默认的命名空间，那么完整表名也可以省略掉“default:”，直接拼写表名SYSTEM_USER即可。命名空间与表的关系，可以用下列图表示：命名空间与表之间是一对多的关系，即一个命名空间下面可以包含多个hbase表，但一个hbase表只能属于一个命名空间。在创立表时，如果没有指定命名空间〔或者命名空间为空〕，那么系统会将此hbase表放置在默认命名空间〔default〕下。另外，删除命名空间之前，必须先删除掉此命名空间下的所有hbase表，否那么将无法删除此命名空间。1.2.Table表设计HBase有几个高级特性，在你设计表时可以使用。这些特性不一定联系到模式或行键设计，但是它们定义了某些方面的表行为。理想HBase表Hbase作为列数据库，根据官方的说法，在性能和效率上更擅长处理“高而瘦”的表，而非“矮而胖”的表。所谓“高而瘦”，是指表的列的数量较少，但是行的数量极大，从而使表展现出一种又高又瘦的形象。所谓“矮而胖”，是指表的列的数据居多，但是行的数量却有限，给人一种又矮又胖的形象，虽然hbase表号称可容纳百万列，但是那也仅仅限于理论上的极限，在实际应用中，请尽量构建“高而瘦”的表，同时需要对列的数量进行测试，以防止过度影响读写性能。预创立分区默认情况下，在创立HBase表的时候会自动创立一个region分区，当导入数据的时候，所有的HBase客户端都向这一个region写数据，直到这个region足够大了才进行切分。一种可以加快批量写入速度的方法是通过预先创立一些空的regions，这样当数据写入HBase时，会按照region分区情况，在集群内做数据的负载均衡。列族数量不要在一张表里定义太多的columnfamily。目前Hbase并不能很好的处理超过2~3个columnfamily的表。因为某个columnfamily在flush的时候，它邻近的columnfamily也会因关联效应被触发flush，最终导致系统产生更多的I/O。所以，根据官方的建议，一个HBase表中创立一个列族即可。可配置的数据块大小HFile数据块大小可以在列族层次设置。这个数据块不同于HDFS数据块。其默认值是65,536字节，或64KB。数据块索引存储每个HFile数据块的起始键。数据块大小设置影响到数据块索引的大小。数据块越小，索引越大，从而占用更大内存空间。同时因为加载进内存的数据块更小，随机查找性能更好。但是如果你需要更好的序列扫描性能，那么一次能够加载更多HFile数据进入内存那么更为合理，这意味着数据块应该设置为更大的值。相应地索引变小，你将在随机读性能上付出代价。数据块缓存把数据放进读缓存，但工作负载却经常不能从中获得性能提升。例如，如果一张表或表里的列族只被顺序化扫描访问或者很少被访问，你不会介意Get或Scan花费时间是否有点儿长。在这种情况下，你可以选择关闭那些列族的缓存。如果你只是执行很多顺序化扫描，你会屡次倒腾缓存，并且可能会滥用缓存把应该放进缓存获得性能提升的数据给排挤出去。如果关闭缓存，你不仅可以防止上述情况发生，而且可以让出更多缓存给其他表和同一表的其他列族使用。激进缓存你可以选择一些列族，赋予它们在数据块缓存里有更高的优先级〔LRU缓存〕。如果你预期一个列族比另一个列族随机读更多，这个特性迟早用得上。IN_MEMORY参数的默认值是false。因为HBase除了在数据块缓存里保存这个列族相比其他列族更激进之外并不提供额外的保证，该参数在实践中设置为true不会变化太大。创立表的时候，可以通过HColumnDescriptor.setInMemory(true)将表放到RegionServer的缓存中，保证在读取的时候被cache命中。布隆过滤器〔Bloomfilters〕数据块索引提供了一个有效的方法，在访问一个特定的行时用来查找应该读取的HFile的数据块。但是它的效用是有限的。HFile数据块的默认大小是64KB，这个大小不能调整太多。如果你要查找一个短行，只在整个数据块的起始行键上建立索引无法给你细粒度的索引信息。例如，如果你的行占用100字节存储空间，一个64KB的数据块包含(64*1024)/100=655.53=~700行，而你只能把起始行放在索引位上。你要查找的行可能落在特定数据块上的行区间里，但也不是肯定存放在那个数据块上。这有多种情况的可能，或者该行在表里不存在，或者存放在另一个HFile里，甚至在MemStore里。这些情况下，从硬盘读取数据块会带来IO开销，也会滥用数据块缓存。这会影响性能，尤其是当你面对一个巨大的数据集并且有很多并发读用户时。布隆过滤器允许你对存储在每个数据块的数据做一个反向测试。当某行被请求时，先检查布隆过滤器看看该行是否不在这个数据块。布隆过滤器要么确定答复该行不在，要么答复它不知道。这就是为什么我们称它是反向测试。布隆过滤器也可以应用到行里的单元上。当访问某列标识符时先使用同样的反向测试。布隆过滤器也不是没有代价。存储这个额外的索引层次占用额外的空间。布隆过滤器随着它们的索引对象数据增长而增长，所以行级布隆过滤器比列标识符级布隆过滤器占用空间要少。当空间不是问题时，它们可以帮助你榨干系统的性能潜力。你可以在列族上翻开布隆过滤器，如下所示：hbase(main)>create'mytable',{NAME=>'colfam1',BLOOMFILTER=>'ROWCOL'}BLOOMFILTER参数的默认值是NONE。一个行级布隆过滤器用ROW翻开，列标识符级布隆过滤器用ROWCOL翻开。行级布隆过滤器在数据块里检查特定行键是否不存在，列标识符级布隆过滤器检查行和列标识符联合体是否不存在。ROWCOL布隆过滤器的开销高于ROW布隆过滤器。生存时间〔TTL〕应用系统经常需要从数据库里删除老数据。由于数据库很难超过某种规模，所以传统上数据库内建了许多灵活处理方法。例如，在TwitBase里你不愿意删除用户在使用应用系统期间生成的任何推帖。这些都是用户生成数据，将来有一天当你执行一些高级分析时可能有用。但是并不需要保存所有推帖用于实时访问。所以早于某个时间的推帖可以归档存放到平面文件里。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小时的数据将会在下一次大合并时被删除。数据压缩HFile可以被压缩并存放在HDFS上。这有助于节省硬盘IO，但是读写数据时压缩和解压缩会抬高CPU利用率。压缩是表定义的一局部，可以在建表或模式改变时设定。除非你确定不会从压缩中受益，我们推荐你翻开表的压缩。只有在数据不能被压缩或者因为某种原因效劳器的CPU利用率有限制要求的情况下，有可能会关闭压缩特性。HBase可以使用多种压缩编码，包括LZO、Snappy和GZIP。LZO[1]和Snappy[2]是其中最流行的两种。Snappy由Google在2011年发布，发布不久Hadoop和HBase工程开始提供支持。在此之前，选择的是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被合并后才能从集群中删除老编码函数库。数据分割在HBase中，数据在更新时首先写入WAL日志(HLog)和内存(MemStore)中，MemStore中的数据是排序的，当MemStore累计到一定阈值时，就会创立一个新的MemStore，并且将老的MemStore添加到flush队列，由单独的线程flush到磁盘上，成为一个StoreFile。于此同时，系统会在zookeeper中记录一个redopoint，表示这个时刻之前的变更已经持久化了(minorcompact)。StoreFile是只读的，一旦创立后就不可以再修改。因此Hbase的更新其实是不断追加的操作。当一个Store中的StoreFile到达一定的阈值后，就会进行一次合并(majorcompact)，将对同一个key的修改合并到一起，形成一个大的StoreFile，当StoreFile的大小到达一定阈值后，又会对StoreFile进行分割(split)，等分为两个StoreFile。由于对表的更新是不断追加的，处理读请求时，需要访问Store中全部的StoreFile和MemStore，将它们按照rowkey进行合并，由于StoreFile和MemStore都是经过排序的，并且StoreFile带有内存中索引，通常合并过程还是比拟快的。实际应用中，可以考虑必要时手动进行majorcompact，将同一个rowkey的修改良行合并形成一个大的StoreFile。同时，可以将StoreFile设置大些，减少split的发生。单元时间版本HBase在默认情况下每个单元维护三个时间版本。这个属性是可以设置的。如果你只需要一个版本，推荐你在设置表时只维护一个版本。这样系统就不会保存更新单元的多个时间版本。时间版本也是在列族级设置的，可以在表实例化时设定：hbase(main)>create'mytable',{NAME=>'colfam1',VERSIONS=>1}你可以在同一个create语句里为列族指定多个属性，如下所示：hbase(main)>create'mytable',{NAME=>'colfam1',VERSIONS=>1,TTL=>'18000'}你也可以指定列族存储的最少