编辑导语：数据资产管理与治理是数据产品经理的四大方向之一。本篇文章作者为我们分享了数据资产模块到底在做哪些事情，以帮助有需要的小伙伴判断是不是可以去尝试的数据产品方向。
在数据产品经理从业指南相关文章中讲到，数据资产管理与治理是数据产品经理的四大方向之一。Q2开始了，近期在整理数据资产方向的产品工作规划，顺便分享一下，数据资产模块到底在做哪些事情，也方便大家在未来找工作的时候（今年铜三铁四的行情让很多人只能静待惊蛰了）判断是不是可以去尝试的数据产品方向。
一、用户是谁要解决什么问题?
B端产品经理工作方法论中，首要的一点就是搞清楚你的用户是谁，他的诉求是什么，有哪些影响他工作效率的点，可以通过产品化的方式去解决。
数据资产产品的用户分为两类，一是数据资产的生产者，二是资产的消费者。
1. 资产生产者工作内容及诉求
这里的生产者指的是数据开发者，虽然“我们不生产数据，我们只是数据的搬运工”，但是他们基于原始的rawdata经过加工处理之后，生成资产化的数据。
上图是很多数据开发者的“愉快”的一天，也有人调侃说他们干着“出力不讨好的脏活累活”，不出问题叫数据赋能，荣耀和光环都聚焦在应用产品端，出了问题就是“数据质量有问题”。“工欲善其事，必先利其器”，所以，作为数据资产产品经理，给他们提供趁手的工具，可以高效快速的干活，帮助他们把自己的资产管理和治理好，才是对他们的一丝丝安慰。
- 开发数据的时候，ODS层、DWD层、APP层，临时表，一堆的命名规范限制，记下来消耗CPU，记不住建模不规范事后被批还要整改。所以，能不能简单点，开发的方式简单点。
- 睡得正稥的时候报警电话什么的最恶心了，所以，任务调度运维的报警策略，失败重试机制可以更AI一些么。即使非得人工处理，任务的一键通知、重跑能不能闭着眼睛就可以操作完接着睡觉了?
- 负责很多的数据模型，业务经常来问数据在哪里，字段啥意思，可以不要来骚扰我吗。所以，我想让模型更多的被复用，但是最好自助去使用，我只想安静去coding。
- 每次被老板指着鼻子说模型健康度差，哪个模型命名不规范，元数据缺失，任务耗时高，长时间没人访问。所以，可不可以提供个工作台，就像农民去田间看庄稼长啥样要不要除草，让我每天早上上班第一件事，把代办清单的治理事项提前完成，下次老板直接周会表扬，我们要向XX同学学习，开发习惯非常优雅。
- 数据开发者除了自己不能删库跑路外，还需要对数据安全问题负责，所以需要流程化、自动化的权限授权和审批管理流程。
2. 资产消费者的场景及诉求
指使用数据的业务产品、运营、分析以及二次加工的数据开发人员。作为数据消费者，就像你去实体店或者电商平台买东西，你希望能够：找得到，看得见，放心用（买）。也就是说，在资产仓库中，SKU覆盖全面，并且规格参数、用法用量（元数据）完备可见，帮助你决策是否是所需要的，除此之外，最好有一些客户好评推荐或者官方认证的童叟无欺的证明，这样才可以放心使用，不至于掉坑里。
资产消费者的主要诉求包括：
- 当我需要用数据，但是不知道数据在哪的时候，可以有工具引导我，从产品线，到数据分类可以逐步缩小范围，最终众里寻他千百度，啊原来你在这里。所以，需要有地图指引的能力。
- 新入职工作交接，前辈告诉我需要的数据都在这个表里，但是求知欲比较强的我，希望搞清楚数据的来龙去脉，以便举一反三，而不是仅仅改个日期参数就查数据去了，所以需要便捷的数据检索能力。
- 数据找到了，有没有相关的认证，证明今天数据没问题呢。
- 虽然内心是拒绝骚扰数据开发者的，但是遇到逻辑不清楚，数据不确定的时候，还是想能够找到负责人，或者其他使用过这张表墙裂推荐的人，去交流交流。
- 除了利用表进行SQL查询或者拖拽分析外，现在不都提中台吗，所以，还希望有可以直接可以输出的数据服务，比如指标API、标签服务，可以通过界面化的配置就生成了接口，DAAS嘛（数据接口即服务）。
二、数据资产模块的产品体系规划设计
明确了用户及其诉求，接下来就是需要通过相应的数据产品来为其赋能助力了。两类用户可能会有重合的场景，比如数据开发者也会作为数据消费者去使用别人开发的数据，同样，业务人员也可以自己去申请建表。所以，在资产产品架构设计上，主要围绕数据的汇聚、加工处理、资产管理、数据治理、价值输出等环节进行覆盖。
1. 数据汇聚
主要解决异构数据源之间的数据传输问题，数据从业务数据库、产品端埋点采集或者其他第三方的API接口、FTP文件互传，需要提供简单通用的数据集成能力，方便把数据统一汇聚到中央数仓。
在产品功能设计时，不同的源、和目标之间所需要的参数配置是差异化的，逐个对接解决即可。另外，数据需要每天或者实时的进行同步消费，所以需要和调度系统结合，提供智能化自动化的资源调度和任务运维能力。
所以，很多数据产品是把数据集成作为一种数据开发任务类型，整合在数据开发套件产品之中。
2. 数据加工处理
在这个环节主要是基于业务对数据使用场景进行数据清洗和逻辑处理，包括离线数据开发和实时数据开发，相当于是数据的加工厂，基于同步过来的数据源进行加工，形成高可用的数据模型。开发套件比较大，可以独立成单独的产品模块。
同时，可以将模型建设规范融入到任务开发的校验流程中。多些事前校验，而不是仅仅依靠事后治理。例如提供dataphin之类的流程化建模或数据加工工具
3. 数据资产化管理
资产化管理：数据工厂加工好的数据，还需要进行分门别类的规整，贴上各种规格标签，才能给到下游消费者使用。资产化管理主要通过数据地图进行数据表查询检索，元数据信息维护查询，为使用者提供方便的数据指引能力。
数据血缘：是贯通数据从入湖到业务终端全流程的数据链路关系，一是可以方便排查数据生产过程的来龙去脉，为翻代码查逻辑提供指引。此外，基于血缘可以做到数据异常时的下游通知，以及下游应用无人使用时，数据一键治理，存储计算资源释放。
数据质量监控：针对任务执行的结果准确性进行监控，提前发现因为源端数据库变更、开发Bug等问题引发的数据不准等问题。
数据治理：从任务资源消耗、时间消耗、业务使用（冷热数据）、开发规范、模型覆盖度复用度等不同维度建立资产健康度评估指标体系，以及数据治理工作台，每天上班就可以知道有哪些坑要填，提前把自己埋了。
4. 数据价值输出
搞大数据最终是为了数据能够产生价值，一是基于数据的决策，二是数据驱动的产品智能化、运营精细化。
SQL即席查询是基于数据模型的SQL取数，自助分析则是通过傻瓜式拖拽方式服务于无SQL能力的业务人员。在这个环节和资产关系密切的就是指标管理、标签资产管理，通过数据API方式，最终将数据输出给到前端的可视化分析产品或者产品、运营主流程的接入应用。
5. 数据安全管理
数据库、数据表、指标及标签的元数据可以公开查阅，但真正要取数使用，必须先获取对应的授权，因此需要提供一键权限申请、审批消息通知、授权后应用自动赋权等全流程的自动化产品设计。
三、总结
数据资产是大数据的根基，前期业务发展追求短平快，留下的资产不规范不健全的坑未来还是要逐一去填平。数字化转型首先要解决的也是数据汇聚和数据资产等问题。
数据资产模块相关的产品经理，不仅要具备良好的产品通用能力，同时需要对大数据生态、数据流转流程、数仓建设等理论有良好的认知，这样做起产品才能更加游刃有余。但万变不离其宗，数据的采存管用流程涉及的数据产品模块，各家公司也都大同小异。
#专栏作家#
数据干饭人，微信号公众号：数据干饭人，人人都是产品经理专栏作家。专注数据中台产品领域，覆盖开发套件，数据资产与数据治理，BI与数据可视化，精准营销平台等数据产品。擅长大数据解决方案规划与产品方案设计。
本文原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自 Unsplash，基于CC0协议。