数仓架构图 sdm odm

https://www.cnblogs.com/zourui4271/p/14139002.html

数据总线

数据仓库作为数据管理核心，必须拥有统一标准的数据输入接口与数据输出通道，才能保证数据输入输出的稳定性。但是数据输入输出会造成数据仓库的资源损耗，尤其是 IO 与网络，所以建设数据总线系统可把数据输入输出功能与数据仓库解耦，让数据仓库专注于数据的整合与计算任务。

数据仓库分层

数据仓库分层架构为 ODM 层、SDM 层、FDM 层及 ADM 层。对上述分层方式可能有童鞋会有这样的疑问：为什么没有共性模型层？每个数据层的定义与职责，以及共性模型层的疑问将在下文逐步介绍，有兴趣的童鞋也可以查阅作者的文章《浅谈银行的数据仓库：分层架构篇》；

数据服务

分为 SOA 接口与文件接口两种方式，分别提供实时与离线的数据服务。由于应用系统调用数据服务接口同样会造成数据仓库的 IO 与网络资源损耗，所以建设数据服务系统可把调用数据服务功能与数据仓库解耦，同时也避免应用系统直接访问数据仓库所造成的数据安全风险；

调度管理

负责数据仓库所有作业（含数据总线的 ETL 作业）的调度配置、依赖配置、日切机制及执行监控；

元数据管理

负责对元数据的录入与查询。对数据仓库而言，比较重要的元数据有数据字典、血缘关系、指标口径、数据映射（mapping）及参考数据（码表与系统参数）；

质量管理

负责两大功能——数据核检及质量评分。

安全管理

负责两大功能——数据生命周期管理及数据安全策略。

数据生命周期管理主要是设定数据的有效期及自动处理策略。当数据达到有效期时，会自动把过期数据进行文本导出、分表、清理等操作，避免数据存储过大造成的一系列系统问题。

数据安全策略主要设定数据的权限，包括查询、下载、分享、补录等权限，避免敏感数据泄露。

数据仓库 ODM 层

• ODM的英文全称是Origin Data Manager，即数据仓库的贴源层，顾名思义，数据层的数据结构跟源系统的数据结构一致。数据总线把每日采集的源系统增量数据文本加载到ODM层中；

• ODM层由于仅保留源系统当日增量数据，且数据结构与源系统一致，故数据加载速度是极快的，无需担心贴源层的数据加载对数据仓库性能造成影响；

• 由于ODM层的数据结构与源系统一致，所以排查数据质量问题时可通过ODM层溯源排查。当然，ODM层仅保留当日增量数据的设计会限制溯源的范围，这是使用关系型数据库搭建数据仓库造成存储成本极高的缘故。当前使用大数据技术框架搭建数据仓库，可使用普通磁盘存储数据，使得存储成本大幅降低，所以也保留ODM层贴源数据的历史轨迹。从很多银行搭建历史数据查询平台来看也能说明这一点；

数据仓库 SDM 层

• SDM的英文全称是Standard Data Manager，即数据仓库的标准数据层，顾名思义，该数据层主要用于数据标准落地。除了数据贯标的职责外，还要负责记录数据历史轨迹，合成历史快照；

• • 在合成历史快照之前，首先对ODM层的增量数据按照数据标准进行清洗与贯标，保证数据标准的一致性；

• 合成历史快照需要对应源系统的供数策略，分别为：

1、源系统全量供数时，数据表只需把全表数据清空并加载即可，但这样只能查询到最新的数据快照。为了记录数据历史轨迹，且节约数据库使用空间，一般只保留特殊时点的历史数据快照，比如每月末、存　　款起息、信用卡账单日等。

2、源系统增量流水供数时，由于增量数据不会影响到历史数据，故只需把增量数据加载到历史数据快照形成最新数据快照即可。

数据仓库 FDM 层

• FDM的英文全称是Finance Data Manager，即数据仓库的金融主题层。当然，金融主题层是针对银行而言，对一般企业，称为主题模型层会更加合适。由于银行业务系统是繁多且复杂的，基于源系统数据模型加工数据应用时，必须要对其熟悉才行，而且源系统数量还不少（至少80个以上），要熟练掌握所有源系统数据模型并灵活运用的学习成本极高。对源系统数据模型按照一定的主题进行梳理与整合后，数据应用开发只需学习主题模型即可，大大降低开发门槛与学习成本；

• 主题划分是一门艺术。划分主题少了，数据过度整合反而使数据模型更加不好理解，且强硬整合不同业务种类的源数据会出现各种奇奇怪怪的数据问题。划分主题多了，数据模型简化达不到效果，使用时跟源系统的数据模型差异不大。所以划分主题建议找业务知识深厚、实施经验丰富的建模专家主导设计，让FDM层建设少踩点坑；

数据仓库 ADM 层

• ADM的英文全称为Application Data Manager，即数据仓库的数据应用层，主要为数据服务而产生的。由于数据服务一般具备特定业务场景，所以ADM层以服务特定业务场景的数据集市形态存在。然而，有两类数据集市对于ADM层来说相对异类，一个是共性宽表，另一个是指标体系，因为这两类数据集市并非针对特定业务场景，而是针对共性业务场景；

• • 共性宽表由日常数据分析使用频繁的，共性的元素，按业务主键关联并整合的明细数据。共性宽表主要为了业务人员进行自助数据分析，业务人员可根据共性宽表的维度自由组合筛选及对表内元素编辑计算逻辑从而快速设计报表；

  • • 指标体系由日常数据分析使用频繁的，共性的统计指标，按相同的统计维度关联并整合的汇总数据。指标体系主要为了让业务人员快速查询统计数据及自由编辑指标计算逻辑来衍生新指标，从而快速了解业务的经营情况。对比共性宽表，指标体系少了灵活性（因指标统计口径是固化在代码中，只能靠技术人员维护），但能极大提升查询效率。

     

    • 共性宽表与指标体系可结合成为业务人员的自助统计工具，既帮助业务人员快速获取想要的数据，又能大大解放开发团队的工作量。

     

    • 很多童鞋可能对共性宽表与指标体系抱有疑问：为什么不把这两类的数据模型做成数据仓库的共性模型层？这里分享一下作者的观点：

     

    1、共性宽表与指标体系都是针对日常数据分析使用频繁的，共性的内容进行整合，达到数据共享的效果。实际上，数据应用的统计指标都具备特定业务场景特色，而非共性统计指标可以满足，比如有效账户数统计，共性统计指标口径是要求非注销的账户，而 A 部门的口径是要求账户非注销，且账户余额不为 0，这样实际共性统计指标的共享性会大打折扣。

     

    2、共性宽表与指标体系无法覆盖所有的源数据，也就是说数据应用会从金融主题层与共性模型层取数加工，会导致血缘关系的絮乱。

     

    3、一些基础的共性统计指标也可以落地到金融主题层，这样既满足数据共享，也满足清晰的血缘关系。

• 银行既是营销金融产品的机构，也是风险运营的机构，所以营销集市与风险集市对业务支撑作用极大；

• 营销集市核心是建设客户标签体系，由客户标签构成客户画像助力营销；

• 风险集市核心是建设风险评分体系及风险预警体系。风险评分体系贯穿整个信贷业务的生命周期，为快速业务决策提供数据支持。风险预警体系通过统计与展示全行机构的风险运营的数据，让领导层及时识别经营风险及采取相应措施；

• 无论是营销集市的客户画像体系还是风险集市的风险评分体系，都需要形成业务数据闭环来不断迭代与优化。

• 获取高管的支持承诺

1、在项目建设前，必须跟高管分析数据仓库建设的利与弊，明确告知建设路径是一个缓慢的过程，让高管形成心理预期与具备一定的认知。同时要宣扬同业数据仓库建设的成功案例，特别是每个里程碑的成效，让高管明确了解项目带来的好处，自然就容易获得支持了。

2、在项目建设过程中，要懂得向高管“邀功”，这样才能获得更多的信任与支持。

• 进行规范化管理

1、建立需求实施流程，管理需求生命周期，让整个需求实施过程都是有迹可循。

2、做好元数据管理，哪怕缺乏元数据管理系统，也要用文档沉淀下重要的元数据，比如架构文档、模型文档、数据映射文档、指标口径文档。

3、 维护好技术文档，宁可牺牲一定的开发时间，也必须维护好项目过程的资料。这样系统出现异常或者需要交接项目时，就能发挥重大的作用。

• 打造阶梯型开发团队

• 1、开发团队哪怕规模小，也要做到麻雀虽小五脏俱全，至少要具备项目经理、架构师/模型师、需求分析师、研发骨干、研发工程师、测试工程师的角色。

   

  2、重要角色必须要有 AB 角，避免重要角色突然流失造成的项目风险与技术断层。

• 多、好、新的打法

1、允许试错并鼓励尝试，在合适范围内对模型进行增删改，甚至推到重构，培养能建模的能力。

2、在建模能力培养过程中，所涉及的模型肯定会出现效果特别好的机会。以此机会作为标杆，复盘设计思路并形成方法论沉淀。

3、待到模型建设基本成熟后，再从宏观的角度观察模型，结合业务场景持续思考可优化地方并落地。这样就会回到“多”阶段，不断试错从而产生新的建模能力及方法论。