HBase互联网电视论文(共3438字).docVIP

HBase互联网电视论文(共3438字) 1整体架构 1.1Hbase原有系统架构 HBase是ApacheHadoop的数据库，能够对大型数据提供随机、实时的读写访问。HBase的目标是存储并处理大型的数据。HBase是一个开源的、分布式的、多版本的、面向列的存储模型，它存储的是松散型数据。相比传统的关系型数据库，HBase具有易扩展、大数量、扩展灵活、成本低等优势。 1.2OTT用户行为数据系统架构图 在OTT体系中，每个机顶盒终端就是一个用户，有唯一的用户标识UserID；用户通过机顶盒来访问和使用互联网电视业务，用户在盒端系统上产生的所有行为日志都上传给系统平台（OpenApi），由系统平台进行数据的处理后进行入库，供经分系统进行单用户或批量用户的查询。 2数据结构 2.1数据结构设计 Hbase底层是基于列式存储的，可以在不浪费存储空间的情况下将表设计得非常稀疏。因此可以将所有的用户行为数据存储在一张宽的表中，消除在进行“行为间组合查询条件”查询时带来的表联开销。由于Hbase目前并不能很好的处理两个或者三个以上的列族，本场景中采用单列族设计，列族的大版本数（MaxVersion）设定为1。想要获得较好的查询效率，应该将频繁查询的条件放在RowKey中，尽量保证查询条件都在RowKey中有所体现。从图3可以看出Hbase的查询效率从高到低依次为RowKey、ColumnFamily、ColumnQualifier、TimeStamp和Value。因此想要获得较好的查询效率，应该将频繁查询的条件放在RowKey中，尽量保证查询条件都在RowKey中有所体现。本应用场景中，需要频繁查询的条件依次为用户身份标识（userID）、行为发生时间、行为类型和行为类型所包含的字段及其属性值。根据查询条件的频繁度，可将RowKey设计成userID、行为发生时间和用户行为ID的组合。同时考虑到RowKey的散列性，Key设计方案为：反转userID+“，”+行为发生日期+“，”+用户行为ID。由于单个用户在特定的某一天，相同的行为类型可以发生多次（例如123456789用户在2013年9月1日这一天可以发生多次播放行为），如果采用真实的字段名称作为列名，后来写入的数据会把前面写入的数据覆盖掉。为了保证数据的完整性，需要在原有字段名的后面加上一个当天唯一的列ID以作区分。列ID仅仅为了保证数据的完整性，无任何实际意义，可以是一个从0开始依次递增的数字序列。 2.2数据格式 源数据部分表示由平台产生的原始日志，自定义部分表示源数据经过人工处理后的扩展属性，行为ID为人为定义，列ID为人工生成的标识ID。列ID在一天内的同一个行为日志中具有唯一性。由反转userID和用户行为发生的日期以及用户行为ID组成RowKey，由真实的列名加上列ID组成Hbase里面的列名。 3数据处理 源数据入库过程分为2个步骤，源数据处理和并行入库。源数据处理部分进行源数据整理，包括日志的清洗，RowKey和列ID的生成。并行入库过程将处理好的源数据以MapReduce方式将源数据导入到Hbase中。 3.1数据入库 源数据处理过程负责进行数据清洗及RowKey和列ID的生成，并将生成好的数据文件拷贝到HDFS中。一种列ID的设计方案是将列ID设定为一个从0开始依次递增的数字序列，此ID使得同一天内，同一种用户行为类型的每一条数据都具有唯一标识。以表1中模拟的播放日志数据为例。并行入库部分负责将处理好的源数据以MapReduce方式从HDFS导入到Hbase中。此方式通过读取HDFS上的文件，以Put的方式在Map过程中完成数据写入，无Reduce过程。 3.2数据查询 进行用户行为轨迹查询时需要输入userID的集合、用户行为发生的时间区间和行为类型信息这3个参数。这3个参数限定了查询的范围，即指定用户在指定时间内发生的指定行为。通过解析userID参数可以得到RowKey的前缀部分；解析用户行为发生的时间区间参数可以得到RowKey的中间部分；解析行为类型参数可以得到RowKey的后缀部分和各行为查询所需要的字段。组成RowKey的全部参数集合都确定后，可以通过迭代将查询所涉及到的RowKey全部穷举出来，生成Get对象的列表，进行批量提交。在生成Get对象的时候，可以调用多重列前缀过滤器（MultipleColumnPrefixFilter），使查询结果只包含所需字段，提高查询效率。 3.2.1单用户查询 查询数据时，根据上文提到的查询逻辑，将生成的Get的列表一次性提交，获取查询结果。由于Hbase的设计是基于列的，想要使