【数据治理】学习笔记

【数据治理】
定义了一个达成共识的模型，该模型描述了谁（Who）能根据什么信息，在什么时间（When）和情况（Where）下，用什么方法（How），采取什么行动（What）。

大数据时代的到来，让政府、企业看到了数据资产的价值，快速开始探索应用场景和商业模式、建设技术平台。这无可厚非。但是，如果在大数据拼图中遗忘了数据治理，那么做再多的业务和技术投入也是徒劳的，因为很经典的一句话：Garbage in Garbage out，数据质量没有保证。而保证数据质量，数据治理是必须的手段。

数据治理这个话题看似阳春白雪高大上，实际上是非常下里巴人接地气，或者说必须要顶天立地才能见实效。顶天是指，与信息化类似，数据治理也是一把手工程，没有高层推动、在业务与业务间、业务与技术间协调，数据治理无法落地；立地是指：一般是IT人员对数据问题有深刻体会，也是IT人员最先意识到数据治理的重要性，而且数据治理最终是在IT层面落地的。

https://cloud.tencent.com/developer/article/1131459
https://zhuanlan.zhihu.com/p/110487122
https://www.esensoft.com/products.html
http://www.qzdatasoft.com/
https://blog.csdn.net/kuangfeng88588/article/details/89952992

https://tech.meituan.com/2021/04/15/data-governance-in-meituan-jiulv.html
目前我们做的等同于是游戏数据中台的治理，而每个项目内部其实也应该有自己的数据治理，例如云游戏的数据治理、内容池的数据治理。

对于每个子项目，都会有各自的原始上报日志，后续基于业务需求的统计，其实都不应该直接对原始日志进行统计；每个原始日志，都应该有对应的中间处理层
多张日志可以对应多个中间层，也可以对应一个中间层，这里可以灵活处理。

中间表一般只保留可用字段，剔除原始日志中太多的无用字段；当然，当前的字段设计不可能一直满足未来的业务需求，当有新的需求过来时，就需要进行字段评估，是否需要新增字段来进行了。

数仓设计需要遵循分层，表的设计需要遵循维度建模，但并不是死板的维度建模。
并不是所有的item都需要用id映射，电商行业中，对于成千上万的货品，存在很多名称类似、过多的情况，因此用id映射商品的名称会方便。
在用户属性表中，对于性别特征的设计，如果也用id来指代性别，显然是不太方便的。因为性别最多只有四种，男、女、未知、其它。如果用id反而还对用户不方便
以此类推，对于操作系统、等也是遵循这样的思路。此时，枚举值也是由汉字真实值来给定的，与数字id一样都保持了枚举的有限性。

共建很重要，独行快、众兴远，比如其它人参与渠道归因开发，也属于整个数仓的一部分，我们需要知道，了解。

岗位职责

从需求出发去学习一项技能，是快速进步的不二法门。遍览数据治理相关的岗位JD，可以总结出如下关键词。

• 职责
  • 梳理数据资产，提高数据质量，完善数据血缘关系管理、指标设计、成本优化，提供数据易用性、安全性、稳定性、一致性；
  • 数据规范、标准、权责、工具、流程等数据管理体系建设；
  • 构建数据质量的检测评价，基于数据质量洞察数据管理机制；
  • 大数据治理工具的设计和开发，例如元数据管理、数据自动化治理工具、数据生命周期管理、数据管控平台、主数据设计、数据安全保障平台、元数据访问接口服务等；
  • 数据治理项目的评估和验收方法；
• 技术要求
  • 熟练掌握数据治理相关方法论，熟悉数据治理体系架构；
  • 熟悉数据治理工具，掌握元数据、数据标准、数据质量、数据安全、数据资产目录、主数据、指标等概念；
  • 熟悉数据数据治理领域知识和技能，包括但不局限于：成本优化、报警治理、安全治理、DAMA等；
  • 深入理解数据质量管理、数据标准管理、企业级数据建模、主数据管理等方法；
  • DAMA认证优先；
  • 分析业务系统数据断点，设计数据埋点，建立数据完整链条；
  • 建立经营分析业务框架，设计基础/衍生等多层指标体系，推动建立指标监控体系；

核心概念

• 元数据。
• 主数据。
• 数据质量。
• 数据资产。
• 指标。
• 数据生命周期。

关于数仓建模的规范，每个团队都可以提出很多条条框框，但这些规则的执行是由一个个人来完成的，司内每个人的工作都很多，不可能有专人来做CR、打回修改。
特别对于数据开发而言，我们的数据需求往往是短平快类型的，如果还要一个人进来做CR，那么必将会耗费很多人力，这显然不现实。
因此最好能有一种规范平台，代替个人去进行这种强制的规范管控。

https://tech.meituan.com/2018/03/21/mtdp-dataman.html

《代码整洁之道》中有这样一个开发案例。两个coder，一个开发一个看，然后周期交替。这样对于代码质量、开发能力都有很大提升，但是在人力不足的情况下没有可执行性。

---

统一数仓规范建模（One Model）
工具保障-数仓规范化开发系统-Dataman
1、标准化规范制定，且配置在系统中；
2、数据开发脚本模板自动生成，只需要在这样的模板里面进行开发；
3、冗余验证，判断出不符合规范的任务（较少）、高度相似的数据表，定期清理；
4、主数据隔离，一般用户无法访问明细层，例如合作伙伴；

---

统一指标逻辑管理（One Logic） 部分是kt那边去做的
1、业务指标体系的规范化；
2、指标的管理规范化，新增、修改指标都以SOP流程的形式跟进，使得指标定义、指标录入、指标修改都遵循严格的规范；
3、物理表管理， 类似咱们现在的渠道大盘常用表文档… 光子大盘
4、数据模型管理，雪花 星星
5、数据销毁机制，pg表太大的问题频发，结果表都在tdw保存一份，再同步一份一样的到pg外表做展示；分库设计，ret专用库、rpt专用库；日增量为百万的数据，不能写入pg

---

统一数据服务（One Service）
这个是xone，已经很成熟了。但我们还没有系统的将大盘的信息以实时接口的形式推送出去

---

统一用户产品入口（One Portal）
idata的各个业务，已经很成熟了，但暂未提供这样的能力。似乎之前有零散的
1、基于xone的http接口。接口实时调用，但数据还是离线；
2、基于Oceanus的实时数据开发；

---

数据运营效率提升工具
1、知识白皮书，打通业务使用场景和数据使用场景；
2、基于规则匹配的答疑机器人
3、百灵-监控收敛与消息推送

---

数据成本管理
1、计算。
2、存储。数据销毁机制，pg的自研上云
3、日志采集。无效埋点梳理

课题《渠道归因项目的数据治理》

目前的数据资产管理系统主要是做资产盘点、安全共享机制、数据地图