今天分享主题分为四个方面，第一个是项目背景，第二个依据项目需求的技术选型，接着就是项目架构，最后讲一下项目实现过程中的一些细节。

　　我们的数据主要有两种，一种是用户账号数据，数据量有十亿，这些数据包括很多类型，比如uid，用户设备号等。还有就是用户标签数据，也达到千万级，包含数据用的社会属性，比如性别、年龄段等，也包括用户的兴趣爱好以及最近的上网行为标签，其实这类数据就是用户画像。这类数据就对应相应的产品线，如精准营销中有个“易获客”项目，这个项目背景就是客户在页面通过用户标签快速精准匹配用户群体，然后通过短信、电话进行营销。当时有两种部署方式，一种是公司部署一套，客户通过外网访问；另外一种就是有些客户对数据安全性比较高，我们会把服务部署到客户，客户就在页面选择一些标签，点击查询返回满足要求用户信息。

　　技术选型依据数据特点，数据量大但也不是特别大，有千万级标签+十亿级用户；依据项目需求，需要很多维度，用户标签分布于几百上千个维度，没有度量概念，度量和维度都是olap中的概念。除了数据之外还有产品要求，需要在线应用，性能要求较高，必须做到毫秒级响应；数据量不断增长，必须做到底层数据存储和计算可扩展性以应对数据量的增加；同时希望产品不属于用户方，再出现问题时能够很容易恢复，需要代码可控。

　　基于这些需求，对开源技术进行相关调研，像Kylin/Druid都是多维分析常见的工具，但是我们并没有使用。这两个框架都会做一些数据预计算/聚合，都能做到亚秒级查询，像Kylin

　　底层是基于HBase可扩展性很强，Druid本身就是一个分布式系统，两个框架都是开源。但是我们选用Bit，因为依据数据需求简单而且Bit只有维度没有度量，还有就是维度个数多，查询是基于用户uid，查询明细数据。在查询明细中Druid有两个问题，如果将uid和维度存储Kylin和Druid，对维度的基数有限制，会构建维度字典，光一个uid就有4G，因此在几百上千维度查询效率会降低；还有一个就是uid用户量大，Kylin和Druid会将uid和其他维度进行组合会出现很多情况，会额外增加数据量，因此这种请款也不适合用Kylin，还有就是Kylin会对维度构建索引，uid索引会很大，查询效率也是很低。基于这些要求还有其他一些技术需求，最终方案是使用HBASE+BitMap的自研框架，HBASE主要做数据存储，将HBASE做处理器做并行计算，BitMap构建索引。

　　HBASE是由一个active和regionmaster作为服务主节点，有Hfile子节点和多个regionserver，底层是HDFS层，每一个regionserver管理很多region，每一个region会根据数据量会有很多Storefile，这几者是依靠客户端协调。接着说一下HBASE表分区，HBASE表里面很为很多region，我们一般会设置每个region的最大值达到最大值自动分裂。而每一个region会有管理范围，分区是用regionserver管理。

　　HBASE有很多特点，第一个就是海量存储，其底层是基于HDFS，是横向存储，可以加很多节点，支持PB级数据存储；按列存储，将树属性相似的放到列组里面，压缩比比较高；第三个就是极易扩展，分为存储和计算，都是分布式存储和计算；然后高并发，单机读写性能在2w+；第五个就是稀疏，当列中属性为空，不占用存储空间。

　　前面讲存储是HBASE，计算是HBASE协处理器，HBASE协处理器分为两种，一种是Endpoint，一种是regionserver。与数据中存储过程和触发器类似，项目用的是Endpoint，类似于数九游娱乐据库中的存储过程。上图左右两边目的相同都是统计表的行数，不用协处理器会直接在命令行中count相关表，从每一个region里面扫描最后得到结果，这种方式耗时很大，由于串行计算，同时会将数据从服务端加载到客户端。Endpoint会以并行方式实现，会将客户端请求发送到所有region上，每个region分担数据量，最后将数据返回协处理器客户端，然后汇总聚合，这样运行速度快很多。速度快一个是并行计算，另一个是将计算的数据移动到服务端，这样数据稳定性高，直接从本地加载数据计算也会减少开销，协处理器返回客户端是数据的数量。

　　可能你们会对BitMap了解很少，其应用场景比较单一，但是在某些方面效果比较好。BitMap底层实现是一个位数组，位数组的value取值只能是0或1，因为是数组，数组下标是整数范围内的取值，最大为2147483647。上图中长度为10的BitMap，通过BitMap的api进行相关设置，会将对应的下标设置为1，如图中6、3、5、7的下标都设为1。BitMap可以进行布尔计算，可以求交集和求并集，其取值是0或1（或者是或否，出现与不出现），节省存储空间。BitMap的应用一个是数据排序，排序要求数据不能重复。第二个就是Bloomfilter，是对应于一组hashmap对应一个BitMap，是牺牲一定错误率来释放存储空间，如在HBASE的索引和爬虫URL判重。但是重点是作为索引，其实它在数据库、搜索引擎和OLAP应用很多。

　　举一个例子说明下，如上图是一个数据表有四列，下面是一个简单查询，查询有性别和婚姻状况两个维度，性别有两个取值，婚姻状况有三个取值，BitMap首先会在维度里面构建BitMap，第一步如何构建性别的BitMap，对于性别这个列，位图索引形成两个向量，男向量为10100...，向量的每一位表示该行是否是男，如果是则位1，否为0，同理，女向量位01011。第二部构建婚姻状况的BitMap，婚姻状况这一列，位图索引生成三个向量，已婚为11000...，未婚为00100...，离婚为00010...。这样就构建完需要查询的BitMap，首先将性别为男的标签拿出来，然后将婚姻状况为未婚的标签拿出来求交，这样就定为下标为2，就查出满足需要的结果。

　　BitMap有很多实现方式，构建框架也有很多。最后我们选用RoaringBitmap，选择的原因在于：我们存储的是整数，将下标标签取值设为1，该框架将整数i的高16位会被用于构造块，存储到keys中，低16位则被看做value，存储到Container[]values中的某个Container中，两个数组通过下标对应。BitMap是分快实现的，有三个特点就是分块存储、压缩、计算，这样在BitMap使用时可以按块解压节省内存空间。但是在计算时必须全部解压。RoaringBitmap在开源框架里应用很多，如olap中有kylin、Druid、piont等，搜索引擎方面有Lucene、slor、Elasticserach等，还有spark、hive、tez等。也有很多实现语言，比如Java、C、C++、Python等。

　　前面介绍了项目背景、技术选型，接下来介绍下基于HBASE和BitMap实现的项目框架构建。上图是项目整体架构，因为是用户从页面构建标签，因此从上到下分为几个模块。可视化层，给用户提供页面，选择标签，然后接口层传入标签，提供API服务，将选择标签传入路由层，构建索引服务，在索引服务中会判断是存客营销还是新客营销，页面标签是求交还是求并；然后索引服务将标签部署于服务器的regionserver上，在存储计算层，通过协处理器存储查询。通过标签和startkey构建rowkey，然后查询数据，在BitMap中进行求交、求并的操作，最后将结果返回给索引服务，索引服务将结果返回前端页面，用户拿到的是匹配到的uid。存储计算层还好，主要发费在数据准备阶段，需要考虑很多东西。数据量大（十亿级标签）并不能直接构建BitMap，需要做这些用户标签做MR生成倒排、uid分桶、gid转id，通过bulkload生成BitMap索引，然后传入regionserver里面，提供相关服务。

　　数据准备层完成uid转连续整数id，根据最大id分桶，标签分桶生成BitMap索引，并序列化后生成HFile，BulkloadBitMap索引。存储计算层完成Hbase：存储索引数据，Hbasecop：分布式计算，RoaringBitmap：索引，布尔计算，求交求并。路由层实现

　　2024HBase in Practice-性能、监控及问题解决.docx

　　-ISO17025(GBT27025)-实验室认可质量手册-(第二部分).docx

　　（三级）农作物种植技术员技能鉴定考试复习题库（含理论、实操）.docx

　　国家开放大九游娱乐学2022春（202207）《2228物业信息管理》期末考试真题及答案-开放专科.docx

　　原创力文档创建于2008年，本站为文档C2C交易模式，即用户上传的文档直接分享给其他用户（可下载、阅读），本站只是中间服务平台，本站所有文档下载所得的收益归上传人所有。原创力文档是网络服务平台方，若您的权利被侵害，请发链接和相关诉求至 电线) ，上传者