数据治理实战——翼支付金融板块业务数仓建设和数据治理之路

吵吵叭火

已于 2024-03-22 09:33:11 修改

阅读量1.1k

点赞数 28

分类专栏： # 数据治理系列文章标签：大数据数据仓库

于 2024-03-04 20:54:11 首次发布

本文链接：https://blog.csdn.net/SHWAITME/article/details/136462064

版权

数据治理系列专栏收录该内容

18 篇文章 5 订阅

订阅专栏

原文大佬的这篇数据治理及数仓建设案例有借鉴意义，这里摘抄下来用作学习和知识沉淀。

一、数据治理背景

在数据仓库建设初期，翼支付主要面对以下几方面的问题：

（1）代码冗余，任务失效不稳定

祖传代码问题严重，任务链路长，存在大量烟囱式开发。另外由于没有统筹管理，资源任意抢占，使得任务时效得不到保障。

（2）元数据信息严重缺失

缺少元数据信息，没有明确的建表责任人，字段缺少中文备注，分区字段随意，一系列问题导致库表清理及新人上手难度大。

（3）数据安全风险高

敏感数据未加密，数据下载入口多，大量明细数据通过Tableau （BI工具）进行处理，无下载记录，数据安全风险非常高。

（4）数据口径差异明显

在一些整合数据口径下，由于各自整合口径来源不同，后续指标口径不一致。

这些问题突显出在整个数据仓库建设和优化过程中，需要在数据治理体系、技术架构、安全策略和运营管理等多方面进行明确规划和持续优化。

二、数据治理建设内容

在翼支付进行数据治理时，我们首先确定了数据治理的主要内容。关键点包括：

2.1 组织协同

确保不同部门间的配合与共同目标；建立数据治理委员会、技术架构委员会和治理实施小组，分别负责推动治理进程和解决分歧、审核信息架构以及具体实施任务。数据治理委员会需要统筹管理，并推动治理工作，各部门紧密协作，形成统一、顺畅、敏捷的组织协同链路。

2.2 平台建设

从0到1打造数据开发平台，支撑2万+离线/实时调度及各类数据质量监控规则，打造自助 BI 平台，支持即席查询与可视化开发，构建数据资产平台，并加强元数据管理，以确保数据的整洁性和安全性。整体上形成统一的数字化和数据平台架构。

2.3 数据应用治理

强调数据治理在应用层的实施，提高易用性，减少计算和存储成本，加快查询速度，提高数据质量，构建敏捷的商业分析模式和数据洞察能力。

2.4 数据规范

通过规范业务生产系统数据，保障源数据的质量，构建各个方面的标准和规范，如数仓建设规范，数据分类规范，主数据和元数据管理等。

2.5 数据安全

在数据的存储、传输和使用三个方面加强数据安全性，使企业数据符合国家数据安全合规要求。

三、企业级数仓建设

3.1 调研阶段

翼支付数据治理早期的调研工作，可归纳为四个重点领域。

（1）首先，识别业务痛点，例如：数据获取困难、数据口径不统一、数据延迟以及数据权限审批长等。

（2）第二，进行组织架构调研，明确不同部门如市场、技术、运营的数据需求与使用模式，以确定主要需求来源及其应用偏好。这有助于指导数据治理工作的方向，优先稳固主体业务需求。

（3）第三，产品及业务流程调研，明确各个部门业务流程和产品特点，是基础建模和数据架构设计的前提。

（4）最后，技术架构调研，旨在解析产品在生产库中的 ER 关系图与库表信息。这一步可以借助元数据管理平台来完成，以便梳理出准确的技术生态图。

通过这四步详尽的调研工作，翼支付为数据治理打下了扎实的基础，从而得以规划和推进后续的治理进程。

2.2 平台护航

在进行数据治理时，关键环节之一是建立并优化技术平台，以支撑数据治理架构。

（1）首先，数据开发平台，提供了至关重要的调度、监控以及运维等功能。并升级了计算引擎，从 Hive 过渡到 Spark，以提升性能和可靠性。

（2）第二，自助BI平台，包括两部分，一是即席查询平台，提供数据探查和管理数据下载等功能，致力于提升数据查询效率和加强数据安全管理，在数据产出的各个环节实施了紧密的安全控制。例如数据下载需通过审批流程，分为自动审批和领导审批，不同等级的数据对应不同的审批等级。另一部分是自研报表平台，提供可视化界面，推动国产化进程。

（3）第三，元数据管理平台，对于规范和整合基础的元数据信息至关重要，包括建表、数据地图、血缘分析以及数据的安全分类和生命周期管理。

（4）第四，指标管理平台，处理指标业务口径和技术口径，存放于特定的数据表，并提供基础信息，以实现标签和其他数据资产的有效管理。

在完成调研和技术平台的搭建后，下一步是数仓的具体建设工作。数仓建设前必须确立清晰的规范，避免烟囱式开发，确保数据治理的统一性和效率。这一系列构建和完善的平台为数据治理的细致工作打下了坚实的基础。

2.3 数仓分层

数据仓库建设遵循互联网公司常见的分层架构，主要包括操作数据存储(ODS)层、明细数据(DWD)层、汇总数据（DWS）层、公共数据集市（DWM）层、个性数据集市(DM)层和应用(APP)层。

在ODS 层，数据从业务库同步，基本保持和业务库数据一致。DWD数据明细层进一步处理明细数据，进行敏感数据加密、数据质量处理以及命名规范化，并关联常用的维度和维度退化。DIM 层专注于存储维度数据。DWS 层则包含明细宽表和汇总数据，明细宽表一般为在不改变原有粒度的多数据域中拉宽的明细数据，汇总数据则是基于统一统计粒度，同一统计周期的指标计算，生成供多种应用场景使用的公共汇总数据。DM 层与 DWS 内容基本差不多，区别在于一些个性化指标加工不具有复用性，DM 层指标可以根据DWS的指标集进行不同需要的整合。

所有的数据输出都必须通过 APP 层以确保数据的一致性，且 APP 层不做复杂指标的计算，只做简单的指标拉宽、union 及简单的计算，通过这种方法，翼支付确保了数据架构的整洁性和可维护性。

在完成产品调研、业务流程和技术库表的梳理后，现在翼支付专注于制定规范并进行数据建模，这是数据仓库建设的下一个重要步骤。

2.4 维度建模

2.4.1 维度建模四步曲

维度建模的核心步骤包括：①选择业务过程，例如选择金融产品中授信、放款、还款等用户需要经历的业务相关的过程，并通过总线矩阵划分到相应的数据域；②声明粒度，指找出需要建模表的业务主键（一般自增主键 ID 是无意义的，除非具备业务含义可以关联），描述数据的详细程度。③确认维度，确立分析中需要包含的各个维度，如省份、城市和渠道等；④确认事实，确定核心的业务度量，例如授信金额、放款金额及还款金额。

维度建模为分析场景提供了重要的维度支持，并通过设置清晰的模型密度，避免了因为不合适的聚合层级导致模型复杂化和数据准确性下降。

2.4.2 命名规范

作为数据仓库建设中的一部分，建立规范是至关重要的。重要的规范包括命名规范，涵盖表命名、字段命名和代码命名。

表命名应反映数据的层级（如 DWD、DWS）、数据域（数据抽象化）、产品线、业务过程以及刷新/增全量标识，如：dws_trade_lxp_loan_order_detail_df。产品线通过公司市场的产品规划采用缩写进行区分。除此之外，还有自定义缩写、数据刷新标识和增量标识的规范。字段命名则遵循词根组规范，例如，“人数”使用“num”，“次数”使用“cnt”，避免混淆。此外，派生指标的命名应注意不要与原子指标混淆，如：授信人数(原子指标) crdt_num,近一天成功授信人数(派生指标) succe_crdt_num_1d，不可以在已命名好的原子指标中间穿插修饰词(crdt_succe_num)。

总体上，这些命名规范确保了数据元素在整个数据仓库中的一致性和可理解性，对后续的数据处理和分析至关重要。

2.4.3 资产沉淀

在数据仓库建设中，资产沉淀是确保信息完整性和便于管理的关键步骤。数仓建设时需规范的记录表的基础信息（如库名、表名、责任人）、描述、表的生命周期，并设立分区保留策略，以确定分区的保留期限。此外，为促进数据的查找与分类，需构建数据地图，标签化各个表，明确其属于明细层、汇总层，还是其他层及产品线。同时，在表的建立阶段，要对表的分类和字段级别进行规范。总之，建表时需妥善规划并完成资产的沉淀，避免为求速度而忽略长期要求，保障数据仓库的可持续管理和利用。

2.4.4 任务保障

在数据仓库的操作流程中，数据开发任务的上线是关键环节。首先，完成表的构建和代码编写后，通过开发平台的测试与审核，数据任务就可部署至生产环境。接着，与代码和表关联的指标也会被开发，并在指标管理平台注册。

通过数据基线SLA 保证任务在离线高峰期能有足够的并发度及计算资源按时完成。任务的数据质量也需监测，包括数据的唯一性、枚举的有效性以及数值检查从而避免不合理的数据波动。最后，要进行任务调度的监控，确保任务稳定执行且在预定时间内完成，以保证数据的及时产出。

整个流程从数仓模型构建到数据产出，其中包括规范、编码、任务上线、指标制定和任务监控等方面。

2.5 数据监控

作为数据监控的关键，数据质量的监控包括完整性、一致性、及时性等维度；监控不仅限于事前，更重要的是事后全方位的审视，例如管理成千上万的任务，以及计算成本和存储成本。在数据存储过程中，监控数据存储以便优化成本，通过审查数据的生命周期来决策数据清理策略。同时，安全监控检查敏感数据是否加密以及防止数据泄露，确保数据下载的安全审计。数据监控旨在保持数据治理的完善性，这是一个长期的过程，而不是一次性的事件。