数据仓库处理工作随笔

最新推荐文章于 2025-09-10 11:30:00 发布

转载最新推荐文章于 2025-09-10 11:30:00 发布 · 143 阅读

原项目型数据仓库的一些随笔。。。。

一,简化业务需求的复杂度。
1，粒度尽量粗（特别是时间维），能月统计尽量别精确到时间。
2，同一展现分析中，时间维尽量单一，多个时间角度统一将难使数据聚合，查询效率差。
3，估算展现分析中查询所涉及的数据量及复杂性，若查询无法定位到具体数据分区且数据量过大，查询效率差。
二，建模的结构统一
1，以何为基准（原始业务表单)
2，如何权衡各系统抽取转换的复杂度。
3，针对性能考虑，如何处理复杂加工、增量加工。
三，数据仓库各环节的技术积累，有长期积累项目开发、实施知识库
1，建模，有建模的统一标准，统一的字段域，表、字段命名，建模人员熟练使用建模工具的能力。
         注：有一套模板，建模前期的统一培训。
        2，抽取及其它整合工具，包括角本编写，有一套相对完善可靠的框架调用，
         针对任何一种工具，熟练使用是前提，更重要的是，在此方面，有调用监控接口，有与项目集成的前期积累，如果没有，在项目前期里进行积累，项目的要求是，不只是使用工具，有对此工具的整合、二次开发、积累成果，如模板、可复用程序。工具的使用不是从头开始，有属于项目的积累，而不仅仅在于人的技术。
3，报表展现有自身开发的框架或第三方工具的熟练高效的集成。

目前我们欠缺的是什么？

   1，关键技术点的实现
   2，业务需求的把控，业务需求是否符合数据仓库实施要求及规范
   3，各个技术环节的规范
      如：建模，是否具有建模的统一标准，统一的字段域，表、字段命名，建模人员熟练使用建模工具的能力。
          抽取及其它整合工具，包括角本编写，有一套相对完善可靠的框架调用，
         针对任何一种工具，熟练使用是前提，更重要的是，在此方面，有调用监控接口，有与项目集成的前期积累，如果没有，在项目前期里进行积累，项目的要求是，不只是使用工具，有对此工具的整合、二次开发、积累成果，如模板、可复用程序。工具的使用不是从头开始，有属于项目的积累，而不仅仅在于人的技术。
报表展现有自身开发的框架或第三方工具的熟练高效的集成。

----------------------------------数据仓库常见问题

3，需求分析

4，建模
统一视图
5，ETL(角本、工具)
增量汇总

6 报表展现

----------------------------------------同业务多版本统一表结构
问题：
   1，原系统各个字段应该都有意义，不可能整合所有源系统所有字段，如何取舍
   2，原系统表主外键各不相同，如何统一
我在此说的主外键，只是逻辑上的，而且是数据仓库最底层的基础数据模型来用的，主键只是为了表示基础数据与源系统之间的对应关系，这种关系是必须的，而外键只是说各表之间的关联，这个很多关联分析是非常重要的，表不是单独存在，之间关联是相当重要的，你不能随便把源业务系统的关联关系打断，后期要找就无法实现了。针对增加对照表，数据量大，性能及对照表维护代价也相当大。
3，原系统各属性字段内容定义不同，如何统一
   字段内容属性不统一，比如源系统有各自的维表，除一些国家标准维外，还有很多自定义的维，同一个维，定义的内容肯定会不同，这时候要统一，很多时候要加入人工手段，难度工作量大，处理不及时可能会影响ETL。是否要做个代码表的对应表，做此种表存在手工工作量很大
   4，原系统各业务定义方式不同，如何统一
如何权衡各表关系、拆分合并处理的妥当性

----------------------------
不能保证所建模型完全符合各源业务系统要求

数据集成工作

一，goldengate内容
    1，gg本身角本的自动生成（分多少个进程、文件数分布)
    2，针对gg中使用的窄表自动生成
       (可利用数据库中主键生成相应文件)
二，存储过程
    1，存储过程模板准备、规范
      (参数定义、变量定义、sql书写、）
三，infomatica程序
    1，infa中mapping或worklet程序模板的准备、参数文件定义、参数传递
    2，infa并发策略
      启用多个instance name，然后session中参加文件根据instance Name变量进行定义，最终运行时找不同的参加达到并行目标
四，建表角本
    1, 表空间定义管理
    2，分区角本自动生成
    3，索引自动生成
其它：表空间、存储管理，不足时扩展策略
      各步骤衔接关系