江苏龙网

  1. 首页 > 人文 > >

万字干货还原美团Flink实时数仓建设( 五 )


比如说 ， 美团上开了一家新的门店 ， 门店所在的城市名字等这些固定的属性 ， 其实可能很长时间都不会变 ， 取最新的那一条数据就可以了 。 这种情况下 ， 我们会通过公司内部的一些公共服务 ， 直接去访问当前最新的数据 。 最终 ， 我们会包一个维度服务的这样一个概念来对用户进行屏蔽 ， 具体是从哪里查询相关细节 ， 通过维度服务即可关联具体的维度信息 。
② 变化频率高的维度
第二类是一些变化频率较高的数据 。 比如常见的病人心脑科的状态变动 ， 或者某一个商品的价格等 。 这些东西往往是会随着时间变化比较频繁 ， 比较快 。 而对于这类数据 ， 我们的处理方案就稍微复杂一点 。 首先对于像价格这样变化比较频繁的这种维度数据 ， 会监听它的变化 。 比如说 ， 把价格想象成维度 ， 我们会监听维度价格变化的消息 ， 然后构建一张价格变换的拉链表 。
万字干货还原美团Flink实时数仓建设文章插图
一旦建立了维度拉链表 ， 当一条数据来的时候 ， 就可以知道 ， 在这个数据某一时刻对应的准确的维度是多少 ， 避免了由于维度快速的变化导致关联错维度的问题 。
另一类如新老客这维度 ， 于我们而言其实是一种衍生维度 ， 因为它本身并不是维度的计算方式 ， 是用该用户是否下过单来计算出来的 ， 所以它其实是用订单数据来算出来的一个维度 。
所以类似订单数的维度 ， 我们会在 DW 层建立一些衍生维度的计算模型 ， 然后这些计算模型输出的其实也是拉链表 ， 记录下一个用户每天这种新老客的变化程度 ， 或者可能是一个优质用户的变化的过程 。 由于建立拉链表本身也要关联维度 ， 所以可以通过之前分组 key 的方式来保障不乱序 ， 这样还是将其当做一个不变的维度来进行关联 。
通过这种方式来建立拉链表相对麻烦 ， 所以实际上建议利用一些外部组件的功能 。 实际操作的时候 ， 我们使用的是 Hbase 。 HBase 本身支持数据多版本的 ， 而且它能记录数据更新的时间戳 ， 取数据的时候 ， 甚至可以用这个时间戳来做索引 。
所以实际上只要把数据存到 HBase 里 ， 再配合上 mini-versions， 就可以保证数据不会超时死掉 。 上面也提到过 ， 整个实时数仓有一个大原则 ， 不处理离线数仓能处理的过程 。 相当于处理的过程 ， 只需要处理三天以内的数据 ， 所以还可以通过配置 TTL 来保证 HBase 里的这些维度可以尽早的被淘汰掉 。 因为很多天以前的维度 ， 实际上也不会再关联了 ， 这样就保证维度数据不会无限制的增长 ， 导致存储爆炸 。
7）维度数据使用
处理维度数据之后 ， 这个维度数据怎么用？
万字干货还原美团Flink实时数仓建设文章插图
第一种方案 ， 也是最简单的方案 ， 就是使用 UDTF 关联 。 其实就是写一个 UDTF 去查询上面提到的维度服务 ， 具体来讲就是用 LATERAL TABLE 关键词来进行关联 ， 内外关联都是支持的 。
另外一种方案就是通过解析 SQL， 识别出关联的维表以及维表中的字段 ， 把它原本的查询进行一次转化为原表.flatmap (维表) ， 最后把整个操作的结果转换成一张新的表来完成关联操作 。
但是这个操作要求使用者有很多周边的系统来进行配合 ， 首先需要能解析 SQL， 同时还能识别文本 ， 记住所有维表的信息 ， 最后还要可以执行 SQL 转化 ， 所以这套方案适合一些已经有成熟的基于 Flink SQL 的 SQL开发框架的系统来使用 。 如果只是单纯的写封装的代码 ， 建议还是使用 UDTF 的方式来进行关联会非常的简单 ， 而且效果也是一样的 。
8）汇总层的建设
在建设实时数仓的汇总层的时候 ， 跟离线的方案其实会有很多一样的地方 。
万字干货还原美团Flink实时数仓建设文章插图


推荐阅读


上一篇：iPhone 12刚刚发布，你还会选择它吗？说说你的看法！

下一篇：打造平台，北京经开区为自动驾驶绘制高精度地图