- 综合排序
- 最热优先
- 最新优先
- 来自专栏张叔叔讲互联网
人群创建的基础：画像宽表
本节主要介绍人群创建所依赖的画像宽表的生成方式。为什么要创建画像宽表？基于原始的标签数据表进行人群圈选有什么问题？如何生成画像宽表？针对这些问题本节会给出详细解答。 画像宽表 本小节将首先介绍画像宽表的表结构以及在人群创建中的主要优势，然后通过一个示例介绍画像宽表的生成方式及优化手段，最后介绍画像宽表数据写入ClickHouse的实现方案。 本书技术方案支持多日期画像数据下的人群圈选等功能，自然兼容单日期下的各类功能。 画像宽表生成 画像宽表的表结构已经明确，那如何生成宽表数据？ 为了解决以上问题，可以通过如图5-6所示的分组方案生成画像宽表。 图5-6中采用了分治的思路逐层生成画像宽表。 所有标签被划分成多个分组，每个分组下的标签自行产出中间宽表，最后将所有的中间宽表合并成最终的画像宽表。
1.7K20编辑于 2023-10-16 - 来自专栏王磊的博客
宽表的缺点
宽表在BI业务中比比皆是，每次建设BI系统时首先要做的就是准备宽表。有时系统中的宽表可能会有上千个字段，经常因为“过宽”超过了数据库表字段数量限制还要再拆分。 为什么大家乐此不疲地造宽表呢？ 另外，如果构建的宽表不合理还会出现汇总错误。比如基于一对多的A表和B表构建宽表，如果A中有计算指标（如金额），在宽表中就会重复，基于重复的指标再汇总就会出现错误。 灵活性差 宽表本质上是一种按需建模的手段，根据业务需求来构建宽表（虽然理论上可以把所有表的组合都形成宽表，但这只存在于理论上，如果要实际操作会发现需要的存储空间大到完全无法接受的程度），这就出现了一个矛盾 这就是宽表带来的可用性差的问题。 总体来看，宽表的坏处在很多场景中经常要大于好处，那为什么宽表还大量横行呢？ 因为没办法。一直没有比宽表更好的方案来解决前面提到的查询性能和业务难度的问题。 其实只要解决这两个问题，宽表就可以不用，由宽表产生的各类问题也就解决了。 SPL+DQL消灭宽表 借助开源集算器SPL可以完成这个目标。
2.8K21编辑于 2023-02-16 - 来自专栏技术趋势
什么是窄表？什么是宽表？
在数据库层面，什么是窄表？什么是宽表？ 在数据库中，窄表和宽表是两种设计思想，分别指的是列数少或者列数多的表格。 窄表是指只包含少量列（如主键和几个属性）的表格。 宽表能够提供更为全面和详细的数据，但同时也会带来一定的复杂度，包括查询效率下降等问题。 窄表与宽表的选择取决于具体的业务需求和数据处理场景。需要根据实际情况进行评估、设计和优化。 宽表表解决了什么问题？ 宽表可以解决一些需要同时获取多个数据属性、进行数据分析和数据挖掘的问题。相对于狭窄的表格，宽表可能会包含更多关联的信息，如不同维度、时间范围内的历史数据或聚合统计数据。 但是，需要注意的是，宽表对查询性能和储存空间也提出了一些挑战，需要根据具体情况进行优化和平衡。 最后 简单来说宽表就是通过一张表来维护所有信息，而窄表就是通过多张表来维护信息。 当然看场景更有利弊，主要的大数据就是用宽表来实现，而传统关系型数据是有窄表。
4.5K21编辑于 2023-09-01 - 来自专栏Spark学习技巧
HBase学习—高表与宽表的选择
utm_content=m_31236 hbase中的宽表是指很多列较少行，即列多行少的表，一行中的数据量较大，行数少；高表是指很多行较少列，即行多列少，一行中的数据量较少，行数大。 据此，在HBase中使用宽表、高表的优劣总结如下： 查询性能：高表更好，因为查询条件都在row key中, 是全局分布式索引的一部分。高表一行中的数据较少。 分片能力：高表分片粒度更细，各个分片的大小更均衡。因为高表一行的数据较少，宽表一行的数据较多。HBase按行来分片。 元数据开销：高表元数据开销更大。 数据压缩比：如果我们对一行内的数据进行压缩，宽表能获得更高的压缩比。因为宽表中，一行的数据量较大，往往存在更多相似的二进制字节，有利于提高压缩比。 设计表时，可以不绝对追求高表、宽表，而是在两者之间做好**平衡**。
2.7K50发布于 2018-01-31 - 来自专栏大数据-BigData
hudi表流式regular inner join关联写入宽表实践
基本环境 mysql 5.7 hadoop 3.2.2 flink 1.14.4 hudi 0.11.0 flink-cdc-mysql 2.2 操作步骤 使用flink cdc将mysql中两个表的数据同步到 hudi表 增量读取hudi表，增量关联两个表中的数据 将关联后的数据写入宽表中 具体实施 mysql中建表 create database hudi_test; use hudi_test; create 'hdfs://bigdata:9000/user/hive/warehouse'); create database huditest; use huditest; 在flink sql中建hudi表 --- order表 CREATE TABLE hudi.huditest.orders_hudi( id INT, num INT, PRIMARY KEY(id) NOT ENFORCED MERGE_ON_READ', 'read.streaming.enabled' = 'true', 'compaction.async.enabled' = 'false' ); --- 宽表
1.4K30编辑于 2022-06-19 - 来自专栏一个会写诗的程序员的博客
使用 Hive 炸裂函数 explode (map) 宽表转高表
Hive 炸裂函数 explode(map<string,string>) 宽表转高表SQL: select slice_id, user_id, shop_id, 'user_stats_public
2.8K20编辑于 2021-12-24 - 来自专栏数据分析1480
【Hive】从长格式表到宽格式表的转换
前言 使用sql代码作分析的时候，几次遇到需要将长格式数据转换成宽格式数据，一般使用left join或者case when实现，代码看起来冗长，探索一下，可以使用更简单的方式实现长格式数据转换成宽格式数据 宽格式数据：每个变量单独成一列为宽格式数据，例如变量name、age等。 长格式数据：长数据中变量的ID没有单独列成一列，而是整合在同一列。 需求描述 某电商数据库中存在一张客户信息表user_info，记录着客户属性数据和消费数据，需要将左边长格式数据转化成右边宽格式数据。 ? 需求实现 做以下说明 ? 总结 长格式数据转换成宽格式数据，首先将数据转化成map格式数据，然后使用列名['key']得到每一个key的value。当然，也可以使用case when函数实现以及left join函数实现。
3.1K20发布于 2019-05-22 - 来自专栏算法channel
深入Python数据分析：宽表如何重构为长表
这里面引出2个概念： 宽表( wide format) ：指列数比较多 长表( long format) ：行数比较多 回头核对官方给定melt的功能和参数 ? 思考 melt()函数的作用，它能将宽表变化为长表。在做特征分析列数较多，即为宽表时，我们不妨选择某些列为unpivot列，从而降低维度，增加行数据实现对数据的重构。
2.8K10发布于 2019-05-28 - 来自专栏Python学习必看
对比excel，用python实现逆透视操作（宽表变长表）
大家好 最近看到群友们在讨论一个宽表变长表的问题，其实这类需求也很常见于我们日常的数据处理中。综合群友们的智慧，今天我们就来看看excel与python如何实现这个需求吧！ 第一步：选中数据，然后在菜单栏-数据-点击来自表格/区域 [format,png] 选中数据-来自表格 第二步：创建表的时候，根据实际情况选中是否包含标题（本例不包含） [format,png] 创建表 ] 逆透视列 第五步：可以看到出现了我们需要的结果 [format,png] 逆透视结果 第六步：点击左上角文件，选中关闭并上载 [format,png] 上载数据 第七步：我们发现，在原始表出现了 表1 values) data [图片] 辅助列存储店信息列表 # 爆炸列完成需求 data.explode(column='辅助列').dropna() [图片] 爆炸列完成需求 以上就是本次的全部内容，围绕着关于宽表转长表
2.1K50编辑于 2022-01-08 - 来自专栏小网管的运维之路
使用DataEase 关联数据集制作宽表
DE_ENGINE_MODE=local 定时同步配置 数据集 目前支持创建的数据集类型有数据库数据集、SQL 数据集、Excel 数据集、关联数据集、API 数据集五种: 数据库数据集指直接选择数据库中某一表作为数据集
77430编辑于 2023-10-27 - 来自专栏数据分析1480
【Hive】再看看如何将宽表转换成长表
前面已经介绍了在Hive中如何将长格式数据转换成宽格式数据，现介绍一下在Hive中如何将宽格式数据转换成长格式数据。 【Hive】实现长格式数据转换成宽格式数据 需求描述 某电商数据库中存在表user_info1，以宽格式数据记录着客户属性数据和消费数据，需要将左边user_info1宽格式数据转化成右边长格式数据 需求实现思路 步骤一：将宽格式客户信息转化成map格式的数据 u001 {"age":"25","education":"master","first_buytime":"2018/1/ 会发现不管是将长格式数据转换成宽格式数据还是将宽格式数据转换成长格式数据，都是先将数据转换成map格式数据。 长格式数据转换成宽格式数据：先将长格式数据转换成map格式数据，然后使用列名['key']得到每一个key的value；宽格式数据转换成长格式数据：先将宽格式数据转换成map格式数据，然后使用explode
3.2K20发布于 2019-05-22 - 来自专栏木东居士的专栏
DataTalk：是一个宽表好还是多个维表好？
0x01 讨论 问题： 在设计数据表的时候，是一个宽表好，还是多个维度表好？ 回答一： 数据仓库每张表的搭建，主要依赖于这个表在整个数据仓库中的作用和相关意义。 数据的安全问题，每张数据表的安全范围不同，合并成同一张表是面临的是更大的权限开放。比如订单表可能仅需要让一部分人员知晓订单信息，并不想让他们知道供应商信息。 若是机器学习模型的同学要数据的话,我们就只需要从维度表,度量表,事实表中抽取数据做成大宽表给他们了,由于模型做的比较少,对于大宽表的经验比较少,暂时只能来一个模型数据的需求,单独写sql语句去抽取。 虽然，这样看起来会占用更多的存储空间，但不失为一种合适的解决方案，因为宽表是通过别的表拼接而成的，因此宽表的存储周期是可以短一些。 只存多个维度表，通过视图来创建宽表。 这种方式适合于宽表的查询次数较少的情况。比如在Hive中，宽表其实只是为了计算出来之后导入Es等系统中供其它系统查询，那么久没必要存储一份宽表，直接通过视图来封装就可以。
5.8K30发布于 2018-05-25 指标平台选型关键与无宽表计算方案
其根源在于，传统的“数仓+宽表+BI”模式在面对灵活多变的复杂业务逻辑时，存在结构性瓶颈，即“宽表依赖症”。 “宽表依赖症”的核心困境体现在：开发效率低：为应对“指标转标签”（如“上月交易量 > 0 的用户”）或“多层嵌套聚合”（如“月日均交易额最大值”）等复杂逻辑，数据工程师需编写数百行 SQL，构建物理宽表 分析不灵活：分析路径被预建的物理宽表（ADS 层）所固化。一旦业务提出未预见的维度组合（如新增“用户等级”维度），就必须启动新一轮的宽表开发排期，严重制约了业务探索性分析。 二、核心差异：静态宽表计算 vs 动态语义编织性能与灵活性困境的根本差异，源于底层架构的范式革新。传统模式（静态宽表计算）：其核心是 “预计算、后查询” 。 七、常见问题 (FAQ)Q1: 什么是“无宽表计算”？它如何保证查询性能？“无宽表计算”指不依赖预建的物理宽表，而是通过语义编织技术在逻辑层构建虚拟业务事实网络。
13310编辑于 2026-02-10- 来自专栏暴走大数据
实时数仓实践系列 | NO.1『宽表处理』
离线由于表数据都同步到数据仓库中，可以进行随意关联，出一些业务想要的统计结果。但是实时数据，一般是接收线上发送的实时消息或者同步mysql的binlog消息，进行消费的。 二、实时数仓实践中问题 下面是在实时数据仓库加工过程中，经常会遇到的一些问题： 1.需要关联维表信息(与离线数仓类似需要关联维表信息，但是实时数据中并没有维表信息） 2.接收多个消息，消息先后顺序无法保证 （离线中数据都已经同步，不存在先后问题） 3.一条与信息相关的所有消息是否全部到达(离线可以看作是当天的快照，但实时没办法判断是否全部到达) 三、宽表解决方案 针对上述问题、结合工作中的遇到的一些场景， 做一些总结，探讨下实时宽表加工方案： 1.如何关联维表信息问题：比如说我们计算订单相关数据，需要查询部门或者收货地址的地区等等，需要关联部门相关的维表或者地址信息维表。 多个消息无法保证先后顺序问题：还拿订单场景为例，比如我们需要统计订单支付金额，涉及到下单消息、支付消息，正常情况(支付消息后来，但是没办法保证) 解决方案：将消息进行分别存储至hbase， (1)下单消息到了去查询支付消息表，
3.3K11发布于 2020-02-11 - 来自专栏暴走大数据
实时数仓实践系列 | NO.2『宽表处理』
因此，对于上图中加工的实时宽表数据，可以进行持久化，进行存储。 这样，实时数据也有明细数据，就可以和离线数据进行比对了，到底是日志丢失还是消息没有发送或者计算的业务逻辑有问题，就能够一目了然。 这就需要对flink加工的实时宽表进行存储了，这边考虑两种解决方案。 (1) 实时宽表数据存储至elasticsearch ? 将加工的宽表数据通过Flink写入es，这样可以得到所有数据的明细数据，拿着明细和其他数据提供方进行比对即可。 (2) 实时宽表数据存储至HDFS，通过Hive进行查询 但是有一些朋友可能会说，es对应的sql count、group by语法操作，非常复杂，况且也不是用来做线上服务，而只是用与对数，所以时效性也不需要完全考虑 因此可以考虑采用下图的方案，将加工的宽表通过Flink写入到HDFS，然后新建hive表进行关联HDFS数据进行关联查询。 ?
2.3K11发布于 2020-02-11 - 来自专栏数据库与编程
在 Oracle 23c 中的宽表设置
在 Oracle 23c 中，数据库表或视图中允许的最大列数已增加到 4096。此功能允许您构建可以在单个表中存储超过之前 1000 列限制的属性的应用程序。 可以使用 MAX_COLUMNS 参数启用或禁用数据库的宽表。 String 要启用宽表，将 MAX_COLUMNS 参数设置为 EXTENDED。 通过此设置，数据库表或视图中允许的最大列数为 4096。 COMPATIBLE 初始化参数必须设置为 23.0.0.0 或更高才能设置 MAX_COLUMNS = EXTENDED。 要禁用宽表，请将 MAX_COLUMNS 参数设置为 STANDARD。通过此设置，数据库表或视图中允许的最大列数为 1000。 但是，仅当数据库中的所有表和视图包含 1000 或更少的列时，才可以将 MAX_COLUMNS 的值从 EXTENDED 更改为 STANDARD。
1.2K20编辑于 2023-10-23 - 来自专栏全栈学习专栏
告别宽表，用 DQL 成就新一代 BI
不，并没有，宽表并不是一个好的解决方案 宽表的局限性很明显，数据冗余，维护麻烦这些就不说了 单单是：分析也只能基于宽表现有的关联去做这一条，就让用户和厂商都无法忍受了 用户分析需求超出范围，或者有变化， 当然有的BI厂商的建模，不叫宽表，事实上他们也确实比宽表做了更多的准备和优化，但归根结底，不管是CUBE,还是立方体，还是其他名字，本质都还是一个宽表，逻辑上并没有脱离宽表的范畴，分析需求变动时，还是得技术人员去改 功能，用户根本不会用，只能被迫用宽表呢？ DQL和宽表大有不同!!! ，占用数据库资源 它的关联关系只要数据表本身结构不变，就不用修改元数据，不需要像宽表一样总得重新生成，相当于一次定义可以适应无数次不同的分析需求，它拥有宽表的优势但从根本上解决了宽表的各种弊端 这就是所谓的非按需建模
1.1K20编辑于 2022-11-11 - 来自专栏灰小猿技术社区
告别宽表，用 DQL 成就新一代 BI
不，并没有，宽表并不是一个好的解决方案 宽表的局限性很明显，数据冗余，维护麻烦这些就不说了 单单是：分析也只能基于宽表现有的关联去做这一条，就让用户和厂商都无法忍受了 用户分析需求超出范围，或者有变化， 当然有的BI厂商的建模，不叫宽表，事实上他们也确实比宽表做了更多的准备和优化，但归根结底，不管是CUBE,还是立方体，还是其他名字，本质都还是一个宽表，逻辑上并没有脱离宽表的范畴，分析需求变动时，还是得技术人员去改 功能，用户根本不会用，只能被迫用宽表呢？ DQL和宽表大有不同!!! ，占用数据库资源 它的关联关系只要数据表本身结构不变，就不用修改元数据，不需要像宽表一样总得重新生成，相当于一次定义可以适应无数次不同的分析需求，它拥有宽表的优势但从根本上解决了宽表的各种弊端 这就是所谓的非按需建模
1.6K10编辑于 2022-06-15 - 来自专栏木东居士的专栏
数据百问系列：是一个宽表好还是多个维表好？
问题： 在设计数据表的时候，是一个宽表好，还是多个维度表好？ 数据的安全问题，每张数据表的安全范围不同，合并成同一张表是面临的是更大的权限开放。比如订单表可能仅需要让一部分人员知晓订单信息，并不想让他们知道供应商信息。 若是机器学习模型的同学要数据的话,我们就只需要从维度表,度量表,事实表中抽取数据做成大宽表给他们了,由于模型做的比较少,对于大宽表的经验比较少,暂时只能来一个模型数据的需求,单独写sql语句去抽取。 虽然，这样看起来会占用更多的存储空间，但不失为一种合适的解决方案，因为宽表是通过别的表拼接而成的，因此宽表的存储周期是可以短一些。 只存多个维度表，通过视图来创建宽表。 这种方式适合于宽表的查询次数较少的情况。比如在Hive中，宽表其实只是为了计算出来之后导入Es等系统中供其它系统查询，那么久没必要存储一份宽表，直接通过视图来封装就可以。
2.5K20发布于 2020-06-01 - 来自专栏全栈程序员必看
php宽字节注入,宽字节注入详解
宽字节 GB2312、GBK、GB18030、BIG5、Shift_JIS等这些都是常说的宽字节，实际上只有两字节。宽字节带来的安全问题主要是吃ASCII字符(一字节)的现象。 进行内部操作前将请求数据从character_set_connection转换为内部操作字符集，其确定方法如下： • 使用每个数据字段的CHARACTER SET设定值； • 若上述值不存在，则使用对应数据表的 其它的宽字符集也是一样的分析过程，要吃掉%5c，只需要低位中包含正常的0x5c就行了。 同理可得 由上文可得宽字节注入是由于转编码而形成的，那具有转编码功能的函数也成了漏洞的成因。 转编码函数同样会引起宽字节注入，即使使用了安全的设置函数。
3.9K10编辑于 2022-11-04
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号