工作日志当前库面临的问题

Posted 2022-12-08 Jan丶X

 从最初确定需求到现在，公司并没有给出一套合适的解决方案。我知道公司在这方面的技术欠缺，也不怪。但在实践的过程中我最深的体会暂时有以下几点

• 现数据库的层级关系是否标准？

  • 不标准，业界虽然没有给出一个明确的数据仓库解决方案，但ODS层至少包括

    • E 抽取层 从各系统中抽取数据

    • T 转换层 有一套成熟的Mapping映射关系表

    • L 装载层 数据集市，生产报表

• 表设计的合理性？

  • 时间戳    增量抽取数据

  • 分区        快速定位位置（现系统缺乏此设计）

  • 三范式    表字段有冗余

  • 标准化地址部分    标准化速度慢，关联方式（用地址关联）不可取，应该用序列ID等

• 模型层全量抽取问题？

  • 模型层的更新始终存在瓶颈，200W的数据，Merge方式用了2小时

    • 可以考虑的方案：

      • 减少模型层负荷，在汇总层就将数据作清洗（包括：字段清洗、去重）

      • 更新时候索引要先删除

      • 考虑临时表的解决方案（更新和插入分成两部分）

=========================================================================================

    已经找到数据更新瓶颈的解决方法

        1. 打时间点，在各个操作完成时记录。发现查询和创建表的时候用的时间非常多。后来得知是因为创建表Select的时候连数据也一同抽取来了所以直接在后面加where 1=2就OK，快了四分之一；

        2. 加入了Hint，因为逻辑CPU共有16个之多，所以采取了并行，快了一倍

        3. 在创建临时表的时候加Nologging 不记录日志，快了三倍