关于宽表加工的一点提示思考

最新推荐文章于 2022-11-15 14:32:17 发布
最新推荐文章于 2022-11-15 14:32:17 发布
阅读量1.6k 收藏 1
点赞数
分类专栏： 架构 文章标签： java flink kafka
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/yyqq188/article/details/121513553
版权

分清事实表join 还是维表join


原因在于
1 事实表join是需要两头关联的，维表join是 只需要事实流表一方关联
2 维表join可以利用broadcast是方式来实现，当然也可以利用传统的hbase的方式实现

初始化要来两遍


第一遍是初始化中间层
中间表包括broadcast的初始化，其实可以自己写个程序统一读取后放入kafka的topic
第二遍是通过已经初始化好的中间层来关联出宽表，也就是静态的宽表

实时流入

就是将上游的数据再导入到初始化时的topic中


 

yyqq188
关注
  • 0
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
实时数仓宽表加工解决方案
诸葛子房的博客
08-28 4498
一.实时数据仓库与离线数据仓库 由于离线数据每天凌晨拉去线上生成数据库(凌晨请求较少，减少线上库压力)，导致数据是T+1，而对于一些时效性要求较强的场景。比如需要看现在的用户数、GMV等等，离线方案就很难解决了。 实时数据仓库就是刚好为了满足时效性要求较高的场景下而生的，但是在做实时数据仓库中经常会遇到一些问题。离线由于表数据都同步到数据仓库中，可以进行随意关联，出一些业务想要的统计结果。但是...
（转载）实时数仓宽表加工解决方案
moose_killer的博客
03-01 567
一.实时数据仓库与离线数据仓库 由于离线数据每天凌晨拉去线上生成数据库(凌晨请求较少，减少线上库压力)，导致数据是T+1，而对于一些时效性要求较强的场景。比如需要看现在的用户数、GMV等等，离线方案就很难解决了。 实时数据仓库就是刚好为了满足时效性要求较高的场景下而生的，但是在做实时数据仓库中经常会遇到一些问题。离线由于表数据都同步到数据仓库中，可以进行随意关联，出一些业务想要的统计结果。但是实时数据，一般是接收线上发送的实时消息或者同步mysql的binlog消息，进行消费的。 这就会出现如果消息来
宽表和窄表的区别---字段
weixin_30501857的博客
08-13 989
宽表和窄表的建设该如何选择？ 这个问题相信纠结了很多从是数据库开发、数据仓库开发和后台开发人员；单单考虑这个问题，难给出一个绝对的答案；本人从事数据仓库开发工作到现在已经有一年半时间了，对于这个问题，我也曾经纠结过，但是是否有绝对的答案呢？事实上任何东西都没有绝对的说法。 考虑这样的一个问题，一个公司有这样的一个需求： 设计销售领域的订单事实表，该事实表应该包含哪些维度和度量？事...
一个例子搞懂宽表和窄表的区别
热门推荐
SmartShylyBoy的博客
11-13 5万+
宽表：从字面意义上讲就是字段比较多的数据库表。通常是指业务主题相关的指标、维度、属性关联在一起的一张数据库表。由于把不同的内容都放在同一张表存储，宽表已经不符合三范式的模型设计规范，随之带来的主要坏处就是数据的大量冗余，与之相对应的好处就是查询性能的提高与便捷。这种宽表的设计广泛应用于数据挖掘模型训练前的数据准备，通过把相关字段放在同一张表中，可以大大提高数据挖掘模型训练过程中迭代计算时的效率问题...
HBase学习笔记——高表与宽表的选择
weixin_33858336的博客
09-21 443
hbase中的宽表是指很多列较少行，即列多行少的表，一行中的数据量较大，行数少；高表是指很多行较少列，即行多列少，一行中的数据量较少，行数大。 hbase的row key是分布式的索引，也是分片的依据。hbase的row key + column family + column qualifier + timestamp + value 是HFile中...
数据仓库建模：定义事实表粒度及事实表关联非最低粒度的维度的情况
Megustas_JJC的博客
01-11 2877
事实表粒度 维度建模中一个非常重要的步骤是定义事实表的粒度。定义了事实表的粒度，则事实表能表达数据的详细程度就确定了。定义粒度的例子如下： 1．客户的零售单据上的每个条目。 2．保险单上的每个交易。 定义好事实表的粒度有很大的用处。 第一个用处就是用来确定维度是否与该事实表相关。例如，对于粒度细到医疗单据上条目项的事实表来说，医疗结果是不会作为维度和它进行关联的，因为它们不在同一个粒度上。但是，对...
Flink cdc+ doris 大宽表实践~
qq_31866793的博客
11-19 6847
还没整理好，别慌。
宽表是什么意思?
DreamSun的博客
11-15 862
宽表从字面意义上讲就是字段比较多的数据库表。通常是指业务主题相关的指标、维度、属性关联在一起的一张数据库表。
实时计算Flink+Hologres
song_quan_的博客
10-11 2753
对于主键关联的场景（即 Join 条件分别是两条流的主键），我们可以将 Join 的工作下沉到 Hologres 去做，通过 Hologres 的局部更新功能来实现宽表 Merge，从而省去了 Flink Join 的状态维护成本。数据实时入仓形成了 ODS 层的数据后，通常需要将事实数据与维度数据利用 Flink 多流 Join 的能力实时地打平成宽表，结合 Hologres 宽表极佳的多维分析性能，助力上层业务查询提速。目前该方案已在阿里巴巴内部、众多云上企业生产落地，成为实时数仓的最佳解决方案之一。
elasticsearch实践篇：跨表join查询补充篇
布道
07-31 1万+
在上一篇elasticsearch实践篇：跨表join查询中讲过2种方式，其实并不全面。ES还有2种方法来处理数据实体间的关联关系：Nested objects（嵌套文档）和Parent/child relationships（父子文档）。 1. Application-side joins（服务端Join或客户端Join） 这种方式，索引之间完全独立（利于对数据进行标准化处理，如便于上述两种...
宽表, 窄表, 维度表, 事实表的区别
艾斯比
03-16 1万+
在数据开发里, 会涉及到一些概念: 宽表, 窄表, 维度表, 事实表 宽表: 把多个维度的字段都放在一张表存储, 增加数据冗余是为了减少关联, 便于查询. 查询一张表就可以查出不同维度的多个字段 窄表: 和我们 mysql 普通表三范式相同, 把相同维度的字段组成一张表, 表和表之间关联查询其他维度数据. 维度表: 包含维度编码和该维度下的多个属性 事实表: 包含一个业务事件的相关属性 举例 宽表 包含性别, 年龄, 各个用户身份 维度表 事实表 ...
【数仓设计】宽表和窄表
清平乐的技术专栏
09-10 2119
宽表： 从字面意义上讲就是字段比较多的数据库表。通常是指业务主题相关的指标、维度、属性关联在一起的一张数据库表。由于把不同的内容都放在同一张表存储，宽表已经不符合三范式的模型设计规范，随之带来的主要坏处就是数据的大量冗余，与之相对应的好处就是查询性能的提高与便捷。这种宽表的设计广泛应用于数据挖掘模型训练前的数据准备，通过把相关字段放在同一张表中，可以大大提高数据挖掘模型训练过程中迭代计算时的效率问...
什么叫宽表
weixin_34380948的博客
04-06 7921
宽表从字面意义上讲就是字段比较多的数据库表。通常是指业务主题相关的指标、维度、属性关联在一起的一张数据库表。由于把不同的内容都放在同一张表存储，宽表已经不符合三范式的模型设计规范，随之带来的主要坏处就是数据的大量冗余，与之相对应的好处就是查询性能的提高与便捷。这种宽表的设计广泛应用于数据挖掘模型训练前的数据准备，通过把相关字段放在同一张表中，可以大大提高数据挖掘模型训练过程中迭代计算时的效率问题。...
数据库制作宽表的方法
feizuiku0116的博客
12-05 1578
INNER JOIN：如果表中有至少一个匹配，则返回行 LEFT JOIN：即使右表中没有匹配，也从左表返回所有的行 RIGHT JOIN：即使左表中没有匹配，也从右表返回所有的行 FULL JOIN：只要其中一个表中存在匹配，则返回行 ...
SparkSQL之Join原理
Magician的博客
04-02 4597
文章目录前言：Join背景介绍Join常见分类以及基本实现机制Hash JoinBroadcast Hash JoinShuffle Hash JoinSort-Merge Join总结 前言： 写SQL的时候很多时候都有用到join语句，但是我们真的有仔细想过数据在join的过程到底是怎么样的吗？今天借这位大神的文章来交接下sql中join的原理。同样，如有冒犯，请联系。 Join背景介绍 Jo...
简单说说SQL中Join的使用
架构栈
11-09 1万+
最近工作中，遇到了一起由于慢SQL引起DB CPU > 90% ，数据库hang住。。最终导致其他业务查询统统失败。       细看下来是由于几张大表Join关联查询引起的，故障本身很常见，不过让我想到有必要讲讲如何规避Join的问题。       以下的讨论都是基于数据库能力有限的前提下，否则后续的讨论就可以直接忽略了。首先，我们来谈谈SQL Join的使用场景1）如果系统存在高并发、分布式业
20亿与20亿表关联优化方法(超级大表与超级大表join优化方法)
落落的专栏 专注SQL调优 性能调优
02-27 3万+
记得5年前遇到一个SQL，就是一个简单的两表关联，SQL跑了差不多一天一夜，这两个表都非常巨大，每个表都有几十个G，数据量每个表有20多亿，表的字段也特别多。 相信大家也知道SQL慢在哪里了，单个进程的PGA 是绝对放不下几十个G的数据，这就会导致消耗大量temp tablespace，SQL慢就是慢在temp来回来回来回...的读写数据。 遇到这种超级大表与超级大表怎么优化呢？这篇文章将告诉你答案。
都在说实时数据架构，你了解多少？
阿里云技术
05-13 578
作者：刘大龙@唯品会 随着互联网的发展进入下半场，数据的时效性对企业的精细化运营越来越重要， 商场如战场，在每天产生的海量数据中，如何能实时有效的挖掘出有价值的信息， 对企业的决策运营策略调整有很大帮助。此外，随着 5G 技术的成熟、广泛应用， 对于工业互联网、物联网等数据时效性要求非常高的行业，企业就更需要一套完整成熟的实时数据体系来提高自身的行业竞争力。 本文从上述现状及实时数据需求出发，结合工业界案例、笔者的实时数据开发经验， 梳理总结了实时数据体系建设的总体方案，本文主要分为三个部分： 第一
mysql数据库宽表
最新发布
05-31
MySQL数据库中的宽表是指包含许多列的表。相对于纵向分割表，即将表分为较小的关联表，横向拆分表通常包含更多的列，并且可以支持更快的查询。这是因为在查询时，不需要通过 JOIN 操作来关联多个表，而是直接从单个...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值