信息网站建设的意义,网络推广培训网,用ps怎样做网站文字logo,江苏省建设主管部门网站分享嘉宾#xff1a;陈杨 快手编辑整理#xff1a;Hoh Xil内容来源#xff1a;BigData NoSQL 12th Meetup出品社区#xff1a;DataFun注#xff1a;欢迎转载#xff0c;转载请注明出处。快手建设 HBase 差不多有2年时间#xff0c;在公司里面有比较丰富的应用场景#…分享嘉宾陈杨 快手编辑整理Hoh Xil内容来源BigData NoSQL 12th Meetup出品社区DataFun注欢迎转载转载请注明出处。快手建设 HBase 差不多有2年时间在公司里面有比较丰富的应用场景如短视频的存储、IM、直播里评论 feed 流等场景。本次只分享其中的一个应用场景快手 HBase 在千亿级用户特征数据分析中的应用与实践。为什么分享这个 Topic主要原因对于大部分公司来说这都是一个普适的场景因为很普遍所以可选择的分析引擎也非常多但是目前直接用 HBase 这种分析用户特征的比较少希望通过今天的分享大家在将来遇到这种场景时, 可以给大家提供一个新的解决方案。本次分享内容包括业务需求及挑战BitBase 引擎的初衷是什么BitBase 解决方案在 HBase 基础上BitBase 的架构是什么样业务效果在快手的实际应用场景中效果如何未来规划中短期的规划。▌业务需求及挑战1. 业务需求用一句话来概括业务需求在千亿级日志中选择任意维度秒级计算7-90日留存。如上图所示。左边是原始数据可能跨90天每一天的数据可以看作是一张 Hive 宽表在逻辑上可以认为每行数据的 rowkey 是 userId(这里不严谨userId 可能是重复的)需要通过90天的原始数据计算得到右边的表它的横轴和纵轴都是日期每个格子表示纵轴日期相对于横轴日期的留存率。该需求的挑战日志量大千亿级任意维度如 city、sex、喜好等需要选择任意多个维度在这些维度下计算留存率秒级计算产品面向分析师等待时间不能过长最好在1-2秒。2. 技术选型面对这些问题我们当时的技术选型① Hive因为大部分数据可能是存在 Hive 里可以直接写 SQL 计算该方案不用做数据迁移和转换但是时延可能是分钟到小时级别因此否定了这个方案。② ES通过原始数据做倒排索引然后做一个类似计算 UV 的方式求解但是在数据需要做精确去重的场景下它的耗时比较大需要秒到分钟级。③ ClickHouseClickHouse 是一个比较合适的引擎也是一个非常优秀的引擎在业界被广泛应用于 APP 分析比如漏斗留存。但是在我们的测试的中当机器数量比较少时 ( 10台 )耗时依然在10秒以上。立足于这种场景是否存在其它解决方案延迟可以做到2-3秒(复杂的场景10秒以下)同时支持任意维度组合基于 HBase结合业界简单/通用的技术 我们设计并实现了 BitBase 解决方案用很少的资源满足业务需求。▌BitBase 解决方案1. 数据模型如上图所示首先将原始数据的一列的某个值抽象成 bitmap(比特数组)举例citybjcity 是维度bj (北京) 是维度值抽象成 bitmap 值就是10100表示第0个用户在 bj第1个用户不在北京依次类推。然后将多维度之间的组合转换为 bitmap 计算bitmap 之间做与、或、非、异或举例比如在北京的用户且兴趣是篮球这样的用户有多少个就转换为图中所示的两个 bitmap 做与运算得到橙色的 bitmap最后再对 bitmap 做 count 运算。count 表示统计“1”的个数list 是列举“1”所在的数组 index业务上表示 userId。2. BitBase 架构整个 BitBase 架构包括五部分数据存储主要存储两类数据一类数据是 bitmap 索引和数据另一类是转换字典的归档文件(见后面描述)。数据转换有两种方式第一种是通过 mrjob 转换第二种是在线计算或导入数据计算负责计算和调度并把 IO 数据计算结果返回给 ClientClient站在业务的角度把它们的业务逻辑分装成一个个业务的接口ZK整个系统是一个分布式的服务用 ZK 做管理。3. 存储模块用数据存储设计的核心目的是让计算更快。如上图左边为一天的原始数据包括多个 table通过 mrjob 或者 rpc 的方式转换成中间的 bitmap。bitmap 分为两部分第一部分为 meta 信息(橙色部分)第二部分是 data 信息Meta 信息唯一定位一个 bitmapdb 可以认为是 hive 中的 dbtable 也可以认为是 hive 中的 tableevent 表示维度 (如:城市)eventv 表示维度值 (如:bj)entity 表示 userId(也可能是 photoId)version 表示版本。BitmapData 从物理上讲是一个比特数组把比特数组按照一定的大小进行切块b1b2b3...bn从而实现分块存储分块计算。最后把 bitmap 存在 HBase 的3张表中: 两张核心表和一张辅助表。BitmapMeta 保存 bitmap 的 meta 信息和一些 block 索引信息。BlockData 直接保存 bitmap block 数据。BlockMeta保存 block 的 meta 信息起辅助作用。4. 计算模块一个完整的计算流程涉及到三个组件BitBase Client、BitBase Server 和 HBase regionServer。① BitBase Client 首先把业务的需求封装成计算表达式然后把计算表达式发给 BitBase Server② BitBaseServe 接收到请求后从 BitmapMeta 表中查询 Block 索引然后根据索引将表达式切分为 n 个子表达式③ 如果所有 bitmap 的 db 相同则走 coprocessor 路由否则按照数据亲和性将 block 计算分发到其它 bitbaseServer 中。④ 根据第3步的调度策略分两条不同的路径计算 block 表达式⑤ BitBase Server 聚合 block 计算表达式的结果然后返回给 BitBase Client。两种计算方式的对比非本地计算解决跨 db 计算的需求它主要的瓶颈在于网卡和 GC。本地计算解决同 db 计算的需求它主要的瓶颈在 CPU 和 GC 上。整体上看本地计算的性能比非本地计算的性能提高3-5倍所以要尽量采用本地计算方式。5. DeviceId 问题在引入 Bitmap 数据模型之后我们隐含的也引入了一个非常大的问题无法支持 deviceId。要支持 deviceId首先需要将 deviceId 转化为数字类型并且转换之后的 DeviceIdIndex 必须要满足四个条件① 连续deviceIdIndex 如果存在空洞会降低压缩效率同时 Block 数量会增加计算复杂度相应增加最终计算变慢② 一致deviceId 和 deviceIdIndex 必须是一一对应的否则计算结果不准确③ 反解根据 deviceIdIndex 能够准确、快速地反解成原始的 deviceId④ 转换快在亿级数据规模下deviceId 转化为 deviceIdIndex 的过程不能太长。6. DeviceId 方案连续、一致、支持反解如何保证连续、一致、支持反解解决方案非常简单利用 HBase 实现两阶段提交协议。如上图中间实线部分所示定义 deviceId 到 deviceIdIndex 的映射为字典。第一张表存储字典的 meta 信息第二张表存储 index 到 deviceId 的映射第三张表存储 deviceId 到 index 的映射。生成 Index 的过程。举例说明, 假设我们已经生成了 1w 个 deviceId 映射那么此时 f:max1w现在将新生成 1k 条映射① 将 f:nextMaxf:max1k1.1w② 写 Index 到 deviceId 的反向映射表1k 条③ 写 deviceId 到 Index 的正向映射表1k 条④ 把 f:maxf:nextMax1.1w 更新到 meta 表生成过程结束。如果在生成过程中出现异常或服务器宕机则执行回滚流程① 如果我们检测到 f:nextMax 不等于 f:max(f:nextMaxf:max)则从表2中查询 max 到 nextMax 的数据从表3中删掉相应的 deviceId 到 index 的映射记录② 再删掉表2中相应的 index 到 deviceId 的记录③ 最后把 f:nextMaxf:max从而实现数据100%一致。用 HBase 实现两阶段提交协议要求 index 生成流程和回滚流程一定是单线程的从而出现性能瓶颈所以 BitBase 设计了归档流程以支持快速转换(见后面的描述)。Meta 表中有两个字段如果发现新产生的数据大于 f:archive_num 就发起归档把表3中的新数据直接写到 HDFS 中 archive_path 目录下。快速转化这里我们用到了 MRjob 中的 Join① 同时输入原始数据和字典归档数据在 MRjob 中根据 deviceId 做 join② 判断 deviceId 是否 join 成功③ 如果成功了直接写 hdfs这样就得到了转化后的数据④ 如果 join 失败直接请求单实例 BitBase MasterBitBase Master 通过两阶段提交协议生成新的映射⑤ 然后返回给 join task 执行替换 deviceId⑥ 把转换后的数据写入 hdfs。反解的过程很简单直接多并发读取 HBase。▌业务效果如上图所示第一个图是2维度不同时间跨度计算留存的时间延迟第2个图是15日留存在不同维度上的时延时延并不会随着维度的增长而增长原因是维度越多表达式中可能不需要计算的 block 块也越多。如上图所示BitBase 可以应用在 app 分析用户增长广告 DMP用户画像等多个业务场景中。▌未来规划根据现在面临的业务场景BitBase 后续会在多个方面做优化。支持实时聚合在一些业务场景下如运营效果监测导入时效需要 5minBitBase 需要支持实时聚合支持 SQL 查询目前只支持 api 的接入方式在一些简单场景下比较复杂开源希望通过开源和大家一起挖掘 BitBase 的业务场景。
