廖辰瀚1，王 盛2，李 凯1，王换文1，孟凡德2，尹春阳1
（1.天翼视讯传媒有限公司，上海 201206；2.兵团第五师科技局）
摘要：随着云时代的来临，互联网电视（OTT TV）业务吸引了越来越多的关注。新疆建设兵团所处地域辽阔，生产和生活的网络视频化的管理与服务的需求也日益明显。兵团的互联网电视业务在日常运营中会生成并累积大量的用户行为数据。由于不同类型的用户行为数据来自不同的数据平台，数据结构各异且数量庞大，从成本和性能方面考虑，传统的关系型数据库难以出色地完成用户行为分析。为此，本文介绍一种基于Hbase的互联网电视用户行为分析系统架构和模型设计，实现大规模异构行为数据的挖掘分析，为更好的运营兵团地域的互联网电视业务提供解决办法。
教育期刊网 http://www.jyqkw.com
关键词 ：HBase；大数据；OTT用户行为数据系统架构；用户行为分析模型
随着互联网电视产业的快速发展，由各终端品牌厂商、平台运营商、互联网视频内容服务商、应用服务提供商等不同的产业链环节，构成了互联网电视产业生态系统。格兰研究的数据统计则显示，截至2013年年底，在产业链各参与方一起发力的催化作用下，中国互联网机顶盒市场存量已破千万台。进入2014年，各大运营商的wifi、4G网络的覆盖也将为互联网电视的业务发展解决“最后一公里”业务到户的障碍。相关数据表明，互联网电视用户发展规模预期到2015年就会接近8 000万，全球来看，到2016年甚至会超过5亿，中国的增长时间会更加早一些。
在互联网电视业务的终端、承载网络和平台管理域都呈现离散分布式密集发展的趋势下，在互联网电视内容监管政策日益紧缩的影响下，着眼于互联网电视业务持续运营的产业链参与方都对互联网电视用户的行为分析以及互联网电视行业应用或承载业务的经营分析提出了更高的要求。新疆建设兵团的诸多互联网电视应用场景正是在宽带高速网络全面覆盖的前提下应运而生：如，兵团内部的党校视频学习、基于IP的互联网电视视频通讯和智能放哨等，如何能在保证数据安全性的前提下，对这些异构行为数据进行第一时间的收集处理，形成可靠的用户行为分析结论，成为互联网电视应用在兵团范围内普及的一个重要课题。
而目前的互联网电视的运营体系相对庞大的用户规模来说，运营平面在各自割裂的管理域里过于集中，数据处理体系呈现平面化，不能适应目前大量用户和业务的异构数据分析运营需求。同时在行业内部还来不及形成一个很好的参考模型，现有的平台之间不具备大数据协同处理的能力，为将来的业务合作后的共同发展形成了障碍。行业内对互联网电视运营数据的系统架构模型需求日益突显。
为了解决上述需求与问题，本文基于HBase的分布式的用户行为分析应用，建立了整体互联网电视数据运营的参考架构模型，并详细列举了相匹配的基本数据结构和数据处理模式，最后与其他的数据库构成方式的性能进行了比较。
1 整体架构
1.1 Hbase原有系统架构
HBase是Apache Hadoop的数据库，能够对大型数据提供随机、实时的读写访问。HBase的目标是存储并处理大型的数据。HBase是一个开源的、分布式的、多版本的、面向列的存储模型，它存储的是松散型数据。相比传统的关系型数据库，HBase具有易扩展、大数量、扩展灵活、成本低等优势。Hbase的系统架构如图1所示。
1.2 OTT用户行为数据系统架构图
在OTT体系中，每个机顶盒终端就是一个用户，有唯一的用户标识UserID；用户通过机顶盒来访问和使用互联网电视业务，用户在盒端系统上产生的所有行为日志都上传给系统平台（OpenApi），由系统平台进行数据的处理后进行入库，供经分系统进行单用户或批量用户的查询，OTT的用户行为数据系统架构图如图2所示。
2 数据结构
2.1 数据结构设计
Hbase底层是基于列式存储的，可以在不浪费存储空间的情况下将表设计得非常稀疏[1]。因此可以将所有的用户行为数据存储在一张宽的表中，消除在进行“行为间组合查询条件”查询时带来的表联开销。由于Hbase目前并不能很好的处理两个或者三个以上的列族[２－3]，本场景中采用单列族设计，列族的大版本数（MaxVersion）设定为1。
想要获得较好的查询效率，应该将频繁查询的条件放在Row Key中，尽量保证查询条件都在Row Key中有所体现。
从图３可以看出Hbase的查询效率从高到低依次为Row Key、Column Family、Column Qualifier、TimeStamp和Value。因此想要获得较好的查询效率，应该将频繁查询的条件放在Row Key中，尽量保证查询条件都在Row Key中有所体现。本应用场景中，需要频繁查询的条件依次为用户身份标识（userID）、行为发生时间、行为类型和行为类型所包含的字段及其属性值。根据查询条件的频繁度，可将RowKey设计成userID、行为发生时间和用户行为ID的组合。同时考虑到RowKey的散列性，Key设计方案为：反转userID + “，” + 行为发生日期 + “，” + 用户行为ID。
由于单个用户在特定的某一天，相同的行为类型可以发生多次（例如123456789用户在2013年9月 1日这一天可以发生多次播放行为），如果采用真实的字段名称作为列名，后来写入的数据会把前面写入的数据覆盖掉。为了保证数据的完整性，需要在原有字段名的后面加上一个当天唯一的列ID以作区分。列ID仅仅为了保证数据的完整性，无任何实际意义，可以是一个从0开始依次递增的数字序列。
2.2 数据格式
表1所展示的为流媒体播放日志的模拟数据，源数据部分表示由平台产生的原始日志，自定义部分表示源数据经过人工处理后的扩展属性，行为ID为人为定义，列ID为人工生成的标识ID。列ID在一天内的同一个行为日志中具有唯一性。
由反转userID和用户行为发生的日期以及用户行为ID组成RowKey，由真实的列名加上列ID组成Hbase里面的列名。转换后Hbase表中的数据如表2所示。
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个参数限定了查询的范围，即指定用户在指定时间内发生的指定行为[2]。通过解析userID参数可以得到RowKey的前缀部分；解析用户行为发生的时间区间参数可以得到RowKey的中间部分；解析行为类型参数可以得到RowKey的后缀部分和各行为查询所需要的字段。组成RowKey的全部参数集合都确定后，可以通过迭代将查询所涉及到的RowKey全部穷举出来，生成Get对象的列表，进行批量提交。在生成Get对象的时候，可以调用多重列前缀过滤器（MultipleColumnPrefixFilter），使查询结果只包含所需字段，提高查询效率。
3.2.1 单用户查询
查询数据时，根据上文提到的查询逻辑，将生成的Get的列表一次性提交，获取查询结果。由于Hbase的设计是基于列的，想要使查询结果按行显示，还需进行查询结果的解析。同时，部分在HBase中无法实现的数据筛选功能如“行为间组合查询条件”、值过滤等，可在此时通过编程语言灵活实现。遍历结果进行解析时，可以生成一个哈希表resultMap、resultMap的key为列ID、value为真实字段名的字符串组合。在遍历中可以根据列ID将真实字段名所对应的查询值替换哈希表中value的值。遍历完成后对resultMap的值集合进行排序，排序结果即为用户的行为轨迹。此方法仅需对查询结果进行一次遍历即可完成解析。
3.2.2 批量用户查询
批量用户查询时采用MapReduce方式提交查询、解析查询结果。由于Hbase官方提供的MapReduce接口InputFormat（TableInputFormat）只支持Scan方式来获取数据，并不适用Get方式。因此实现批量用户行为轨迹的分布式提取和解析，需要自定义3个类，即PrefixInputFormat（继承自InputFormat）、PrefixSplit（继承自InputSplit）和PrefixRecordReader（继承自RecordReader）[3]。自定义这3个类的目的在于将输入的userID参数（包含RowKey前缀信息）、日期区间参数（包含RowKey中间部分信息）和用户行为类型参数（包含RowKey的后缀信息和查询所需的列）传入到PrefixInputFormat中，在PrefixInputFormat根据每个userID所在的Region将其分配到不同的PrefixSplit上，在PrefixRecordReader中根据PrefixSplit传入的参数信息完成RowKey的组装和Get列表的生成，并将Get列表作为VALUEIN传递给Mapper进行查询和解析。
4 性能对比
测试数据：天翼视讯9月1日到10日之间10 d的登陆、播放、访问和订购数据，总计条数约1亿条，日志文件总大小21 G；任务描述：找出在9月1日到9月10日这段时间内输入用户集合中同时发生播放、订购、访问、登陆4种行为的活跃用户，并提取这部分用户在这段时间内的用户行为轨迹，数据库的性能情况见表3。
5 结论
本文通过对HBase数据架构及数据字段设计的分析，设计了基于互联网电视用户行为分析的数据系统模型和数据库表结构。经过实际测试发现，在提取用户行为轨迹的数据分析时，HBase与传统的关系型数据库相比，在读写性能上均具有明显优势。伴随互联网电视业务发展和用户行为数据量的增加，对用户行为数据的查询及分析显得尤为重要[4]。目前,在对普通的互联网电视用户的盒端对用户行为数据的采集方面还不够完善，还需要继续完善补充用户行为字段，优化完善基于HBase数据字段及数据库结构，建立数据挖掘模型，通过对用户行为数据的深层次挖掘分析来优化完善业务和产品，为互联网电视业务在新疆兵团的持续优化发展和运营分析提供决策支持。
教育期刊网 http://www.jyqkw.com
参考文献
[1]孙立.为什么要使用NoSQL . http://www.infoq.com/cn/news/2011/01/nosql-why/，2011.
[2]颜开. HBase官方文档 . http://www.yankay.com/wp-content/hbase/book.html，2010.
[3]Lars George .HBase The Definitive Guide[Z] . O´Reilly Media，2011.
[4]Tom Write.Hadoop权威指南（第二版）[Z] . 北京：清华大学出版社，2011.