如果是缓慢变化维那边维度变化后数据会统一变化,不存在改变前改变后,因为历史就是历史,不会改变的
如果就单独一个系统这样子且数据量不大 你就建一个缓冲库 相当于给该系统建一个备库 每天同步一次 然后再进数据仓库 如果数据量特别大 那么就考虑月同步一次 由于客户原因的话 说明好 管客户要硬件资源 这是我
回复 jielee 每个人遇到的问题都不一样,我只是把我的想要探讨的问题说出来,至于您说的关联表的问题,源业务系统涉及到钱,这个在银行会涉及到运营、财务、客户所属分支机构,客户信息修改要走一些系列流程,关联表这种方式核
回复 julian1983 理论上可以,但是不好执行,而且这样容易引起基层人员对IT部门的反感,他们会认为IT部门系统没做好,我输入错了怎么不提示我,人之本性,嘿嘿
回复 yaozw 目前看没有好的管理手段,前端系统也不会因为数据治理而进行大范围修改,比如数据字段类型或者数据长度。我们当时管理层也针对数据质量发了很多文件,但是基层执行没有有效的执行保障,比如对公客户资产规模人员
目前市面上有一些相对成熟的产品,可以管理数据仓库元数据和建立数据链路,但是限制较多,我建议还是基于行内实际情况,自己写一个元数据管理系统,功能相对简单实用,数据仓库的元数据管理最关键的就是源系统与模型之间的对照关
目前我在验证的一个有效治理数据质量的手段就是采用技术限制,这个跑出了数据仓库的范围,我们目前在做客户整合,在数据仓库层面T+1模式的客户整合已经完成,发现了很多数据质量问题,都是源系统的问题,源系统也不会去更正,因为
回复 jielee 这方面我可不是个外行,数据仓库本身是不能完全解决数据质量问题,比如:有效证件问题,一个人的有效证件可以军官证、身份证、护照等,那么在客户整合过程中怎么处理,如果在数据仓库级别处理会造成一个结果,数据仓
这个就看数据仓库模型的建设好坏了,银行业数据仓库模型在字段级别上已经很稳定了,无论关键系统如何改造,看数据仓库模型好坏的标准就是表字段数有没有变化,在关键系统进入数据仓库中要做好充分的参数化表,参数化越深入,这类
我们自己写有数据质量验证的程序,再有就是在数据分析和数据建模的过程中发现,比如组织机构代码证位数是固定的,用一些常识性的业务逻辑写程序发现问题。
关于TWT使用指南社区专家合作厂商入驻社区企业招聘投诉建议版权与免责声明联系我们 © 2024 talkwithtrend — talk with trend,talk with technologist京ICP备09031017号-30