博客
关于我
谈笑间学会数仓—维度层设计④
阅读量:601 次
发布时间:2019-03-12

本文共 840 字,大约阅读时间需要 2 分钟。

谈笑间学会数仓—维度层设计④

极限存储

历史拉链存储是处理缓慢变化维度的一种方式。通过新增start_dt和end_dt两个时间戳字段,将变更数据按时间戳存储。这种方式通常用于处理时间.grain为天的维度。

示例分析:以商品维度为例,假设卖家A于2020-1-1发布商品B和C,并于2020-1-2下架B并发布D。采用全量存储,1月1日分区存储t1和t2,1月2日分区存储更新后的t1及t2和t3。

采用历史拉链存储后,不变数据不重复存储。下游应用可通过限制start_dt和end_dt范围获取历史数据。

实例操作:

  • 1月1日数据:start_dt <= '20200101'且end_dt > '20200101'
  • 1月2日及以后:前端应用自动处理

优缺点分析:

  • 优势:
    • 透明化处理,便于下游用户理解
    • 适合变化频率低的维度
  • 缺陷:
    • 数据分区膨胀带来性能负担
    • 解释成本高,对非技术用户不友好

极限存储解决方案

为应对上述问题,采用极限存储方案:

透明化处理:

  • 基于历史拉链存储,应用视图或Hive hook技术转换查询语句。用户面临全量存储表和极限存储表一致。

分区优化:

  • 分区开启月初重新生成整体历史数据,最大分区数约为5232,显著减少存储成本。

存储优化策略:

  • 创建全量存储表,仅存储大范围内的近期数据,便于用户访问。
  • 历史数据通过映射关联到基线表,保证用户无感知。
  • 对变化频率高字段进行过滤,确保极限存储存储效率。
  • 微型维度设计

    维度过度增长会影响极限存储效果。解决方案:

    垂直拆分技术:

    • 将稳定属性分离,割裂维度,保持主维度稳定。

    微型维度优化:将不稳定属性归类至独立维度,基于组合代理键构建。如用户维度,移除VIP等级和信用评价相关字段,分别维护,可在买家维度引用。

    实际应用考量:

  • 枚举值适用性有限,非枚举属性需谨慎处理。
  • ETL复杂度查高,需投入研发资源。
  • 微型维度破坏了浏览性,需额外维护。
  • 优化建议:在不可避免的局限性下,合理选择存储策略,最大化节省成本。

    转载地址:http://kcdxz.baihongyu.com/

    你可能感兴趣的文章
    Spring源码学习(二):Spring容器之prepareContext和BeanFactoryPostProcessor的介绍
    查看>>
    PatchMatchStereo可能会需要的Rectification
    查看>>
    Path does not chain with any of the trust anchors
    查看>>
    Path形状获取字符串型变量数据
    查看>>
    PAT甲级——1001 A+B Format (20分)
    查看>>
    Skywalking原理
    查看>>
    PAT甲级——1006 Sign In and Sign Out (25分)
    查看>>
    PAT甲级——1007 Maximum Subsequence Sum (25分)
    查看>>
    PAT甲级——1009 Product of Polynomials (25分)(最后一个测试点段错误)
    查看>>
    Spring对jdbc的支持
    查看>>
    vagrant 的安装
    查看>>
    PayPal网站付款标准版(for PHP)
    查看>>
    Paystack Android SDK 集成与使用指南
    查看>>
    pbf格式详解,javascript加载导出pbf文件示例
    查看>>
    PBOC2.0与3.0的区别
    查看>>
    PbootCMS entrance.php SQL注入漏洞复现
    查看>>
    PbootCMS 前台RCE漏洞复现
    查看>>
    PBT
    查看>>
    PB级分析型数据库ClickHouse的应用场景和特性
    查看>>
    pc3-12800
    查看>>