一、技术转产品的思考
贺老师毕业于计算机软件专业，曾接触过软件开发、图像识别、数学挖掘等专业知识，毕业后成为了一名程序员。后经历了团队从业务的数据研发工作到中台的数据平台研发的转型，积累了丰富的大数据研发经验。由于个人兴趣以及团队角色的需求，在同一个项目内逐步转型为数据平台产品经理。
因此，技术到产品的转型，需要结合内在性格、外部机遇和自我培养等多方因素才能实现。
产品与研发的区别主要体现在职能、思维和研发上，两者需要相互配合共同实现价值。数据平台属于技术型平台，对产品经理的要求更高，既要有产品经理的必备素养，又要有大数据领域的专业技术。
技术转型产品需要做如下一些准备工作：
- 首先是判断。从专业知识、好奇心、是否对负责任的事情操心、积极的心态、善于挑战目标、沟通能力等角度判断是否适合转型。并判断是否有足够好的机会，比如在同一项目内部进行转型就是一个比较好的机会。
- 第二尝试。在转型之前，是从产品的视角对需求进行思考，做一些思维上的简单训练和尝试。从简单的需求入手，进行原型图绘制，需求文档撰写等。
- 第三是学习。培养自身产品经理所需要的一些素养，提升自身产品力，太过于技术的思维方式会阻碍产品力的发展，如果总是考虑实现的难度就可能会丢失一些好的想法。
二、深度理解数据工作者的需求
接下来分享如何由浅入深地理解数据平台的用户需求。
以内容类 APP 为例，它是通过内容连接用户和平台，即作者使用 APP 发布内容，APP 再通过推荐算法将合适的内容推荐给用户。在算法推荐、用户精细化运营、业务决策环节都需要用到数据生产资料，尤其对于算法模型而言，数据决定了一个算法的上界。由此可见，数据非常重要。
在这种背景下，数据层面却仍然面临着很多问题。面向数据开发的工具非常多，但是围绕数据资产本身的工具缺乏，导致数据的管理和使用混乱。数据需要反复验证，查询速度非常慢导致数据分析师效率低。对于策略产品经理而言，只能查到基础的表结构，没有功能去了解表的更多数据信息。公司内的数据工具和平台非常多，但没有协同效应，连集群都是割裂的，这非常不利于数据工程师的工作。表名乱，没有数据规范，数据质量差，出了问题新入职的数据工程师也不知道能找谁。
为了解决这些问题，我们以建设数据资产为目标，来搭建数据平台能力。当一份数据较为规范、易于理解、质量可靠，我们可以称之为数据资产。当数据资产能方便地被下游使用时，才可能发挥出数据中更大的价值。
因此早期欧拉平台着力于打造一个数据资产管理平台，用于沉淀出业务的核心数据资产，面向数据工程师提供数据管理、数据质量监控能力。欧拉先采集表的技术元数据并做一些加工，然后提供一些管理工具给用户登记业务元数据来丰富表的描述，让数据变得更易理解。数据科学家或数据分析师在充分了解数据后，再使用 Presto 这样的高速查询引擎来快速获取分析结果。
平台上线后运行效果并没有完全达到预期，主要有以下问题。首先，问题产生后再解决比较棘手，例如开发一张表，表名已经建好甚至数据已经被下游使用，这时修改会很麻烦，只能做简单的数据管理。其次，数据已经产生甚至已经交付后治理的动力明显不足，导致最终业务的信息登记更少，无法形成一个有效的元数据管理氛围，周期性运动式的治理难以持续。
那么 DE 到底需要什么呢？
- 通过 Presto 引擎将查询速度提升了，但产品体验也是决定工作效率的核心因素。
- 技术元数据更丰富，拥有了数据地图的检索能力，但业务元数据很难沉淀，找到表之后缺乏描述表业务信息的内容。
- 数据质量问题能被有效监控，但很难定位到根因。
- 数据管理、质量监控等能力在功能矩阵上新增了，但生产流程与管理流程依然割裂。
针对上述问题，有如下解法：
解法1：把一些治理动作提前到生产过程中，不仅规范了表名，也规范了整个开发流程，从而推动整个新表资产化的程度，旧表通过引入的方式进入到治理过程。
解法2：有机整合在整个生产过程中用到的平台工具，来提升数据工程师的效率，元数据信息也因此不会被重复冗余登记。
解法3：构建数据资产化程度的评价指标，从规范、安全、成本、应用等角度设计此评价体系，持续驱动存量和新增数据的治理。
解法4：从上游提前规避数据质量问题。在上游开发阶段充分进行数据测试，核心节点出现问题时能阻断下游传播，防止对下游数据的污染。对于报表延迟风险，在上游出现变慢或失败等突发状况时，评估下游的一些核心保障节点是否有延迟风险。
解法5：将软件工程领域有效的经验进行转换吸收应用到数据工程领域。比如 DataOps 是从敏捷、Devops、精益制造吸收的灵感。通过落地 DataOps 可以提升整体协同效率，保障数据质量，减少开发工作量。
按照“组合创新&错位竞争”的思路，将解决用户需求的方向，从数据资产管理平台，最终转向成了打造一站式数据资产开发平台（资产工场），把管理过程前置到开发，借鉴软件工程思想，目标群体也更专注在数仓工程师、而不是所有的数据研发。
三、腾讯欧拉资产工场实践
接下来介绍腾讯欧拉资产工场的落地实践。
腾讯欧拉资产工场是基于 DataOps 的一站式数据开发平台。通过提前制定流程规范、设定数仓配置，大大增强了整个数据仓库的规范性，并同时兼顾开发效率。
功能矩阵如下图所示：
首先是数据规划。对包括业务域、主题域在内的数仓架构进行设计，对 Hive 以外的数据源进行统一管理。
第二是数据开发。开发阶段支持表与任务同时开发，提供丰富的数据同步组件与上下游外部数据进行对接，还拥有智能解析依赖的能力。
第三是数据调试与发布。提供测试模式这样的方式隔离线上环境，在发布阶段走代码评审，在发布上线时同时发布到任务调度平台以及 GIT 代码仓库。
最后是数据运维与质量。数据上线后，提供运维大盘、DAG 图等功能对数据运维提供基线预警与质量监控等功能，从而观测和提升整个数据仓库的健康状况。
在敏捷、标准化、自动化程度高的数据开发流程下，
- 角色得到进一步细分。比如有数据规划者由此能够把数据当作产品一样进行精益化生产，从而构建规范、更高质量的数据仓库，使得下游数据使用者更加满意。
- 重点打磨数据开发面板。增强团队内部协同效率，实现了配置化开发；强化了数据版本控制，把所有影响生产的内容，包括表结构任务的代码、调度配置、以及依赖了什么上游任务等等都当作代码，并对版本内容进行可视化；实现自动化上线，发布后同时上线 Hive 集群、调度平台和 Git 仓库；构建出正式环境与测试环境的简单隔离，智能解析上游依赖，自动抓取 Python 中的 SQL 等自动化能力。
- 随着时间的推移，业务数仓规模不断膨胀，运维压力加大，采取分层保障来提升数据质量，降低运维起夜率。对于大部分日常任务数据可以自动监控，保证基本正常运维。对于重点数据的内容进行质量监控，必要时设定强规则，在告警后可以阻断下游执行，避免污染下游更多数据。对更核心的数据，还提供及时性方面的基线保障，支持追踪监控整个上游任务链路，提前预测产出延迟风险。
- 除了平台上的设计落地外，还搭配与资产工场相关的课程体系。比如在数据工程职位上开设了《DataOps》，《SQL 代码规范》，《数仓设计》还有《数据测试》等四门必修课。策略产品职位则开设了《SQL 实操应用》，从而使提数据需求的产品经理对数仓和 SQL 的认识更深刻，从而方便他与 DE/DS 更好地沟通。通过这些课程，提升用户对资产工场的使用效果。
意识、平台工具、组织保障等多方面的叠加，使得在各个业务线实现了生产及治理的效果。生产前，通过规范标准来系统化预约束，增强数仓整体规范性。生产中，通过数仓属性和业务元数据的登记，增强数据可理解性。生产后，关注数仓的质量和即时性，提升数据内容质量和任务产出时效。最后将数据在各种数据应用中进行呈现，发挥数据的价值。
在落地整套方案的过程中，一站式的功能的不断补齐，在具体应用场景上也下了不少功夫，从某种程度上来说降低了数据开发的门槛，使得潜在客户群体不断扩大，目前非DE的用户占比达到 1/3。
四、数据平台产品方法论
1、平台创新方法论
无论是从 0 到 1 做一个新的平台，还是对已有平台进行自我革命，作为产品经理首先要关注行业前沿，与研发、技术用户始终保持在基本相同的技术认知上，才有可能一起找到一个新兴技术方向，沿着方向做强，打造出新的核心竞争力。
在设计方案时，要尝试把要素拆解得足够细，例如从需求角度重新理解当下的平台已经提供了哪些功能，把这些功能及用户需求拆解得足够细，再进行有机组合，达到人无我有，人有我优的境地。找准一个方向，着力于打造一个核心竞争力，错位竞争。比如我们找准了 DE 这一方向，在数仓领域做大做强。在一开始功能的质量比用户规模更重要。另外，做平台不是做工具，功能不能靠简单的堆叠，而是有机地进行整合。
2、规范和效率如何兼顾？
首先，可以在日常大功能需求的迭代中，插入一些小而美的需求，这些需求可能是日常不断和用户沟通反馈收集而来的。这些需求还需要足够通用，才会有更多用户受益。
另外，在规范上约束用户行为时，需要考虑是否已提供给用户足够多的辅助工具。比如强制代码评审，那么需要考虑代码的对比能力是否将改动前后的差异清晰呈现，从而加速整个 CR 流程提高整个开发效率。
3、目标驱动
平台的驱动力：首先定义几个核心目标，然后考虑如何度量。平台对效率的提升起初没有找到很好的办法直接定量度量，但用户可以直观感受到。我们可以从用户规模、用户留存对效率进行定性，反映出平台的吸引力。对于刚接入的新用户可以询问原因，提炼吸引点来拉动更多新用户。
用户的驱动力：一为推力驱动，通过拉通各个业务团队共同制定一个评价机制，来评价整个资产化过程，形成平台分资产分评价体系。如果有规则没有达标，则会呈现为待治理状态。二为拉力驱动，把一些工作成果直观地统计出来，例如近 7 天开发了多少表、处理了多少任务异常情况等等，对用户进行激励。
4、用户运营层面讲究策略
首先，用户运营需要与业务同学建立有效连接，可以搭建一套数仓对用户进行细粒度分析，通过对用户的分析来充分了解用户。用自己的平台搭建数仓，也能从用户角度思考平台还有什么不完善的地方。第二，与用户沟通时，要建立信任感，做到事事有回音。第三，抓住比较主动的新用户，耐心地与用户沟通，解答平台内部一些细节问题，使得新用户认可平台，从而带他们整个团队更多人来使用。最后，运营要有节奏感，合适的产品推荐给合适的用户。此外，平台的 PRD 方案可以拉上一些用户进行预评审，在实际沟通中我会发现用户非常乐于参与到方案的制定当中。
5、个人产品力的提升
首先多实践，在实践中思考。通过数据分析、研究竞品、研究用户和自己的直觉来发现问题。提出问题，界定要解决的问题边界，论证问题的一些限制条件，问题解决后会有怎样的价值。运用产品工具来解决问题，把功能上线后，定期对平台运行情况复盘。多看成功案例实践，有些看似有用的功能通过数据监控发现用户量非常少，需要多反思。最后，从微观到宏观、从局部到整体多思考。另外，最重要的一点的是，热爱自己所负责的事情，这是做好它的动力源泉。
五、问答环节
Q1：数据模型如何迭代？市面上有什么工具可以使用？
A1：数仓工程师应该更适合来回答这个问题。我对于该问题的理解是，首先在做一套生产及治理流程时，很多业务团队会趁机复盘整个数据仓库存在的问题，重新对数仓的主题域、业务域划分，制定标准。旧的数仓中核心根据数据这套标准直接挂到更合适的业务域或主题域节点上，本身设计不合理的数据表进行重新设计，达到对整个数仓模型的迭代目的。其次，我们会通过资产分的度量方式关注数仓内部整体的状况，给数据模型迭代提供指导。:
Q2：您提到的治理方法的基本归纳为先定规范再按规范执行，对于介入治理时已经存在的质量问题如何处理？
A2：如果重新定义一套新的数仓规范，旧表会产生冲突，因此导入的时候提供选分层，业务域、主题域直接挂载上去，不对表名重新命名，因为下游已经很多任务在使用。
Q3：查询引擎从 Hive 切换到了 Presto 效率提升了，但成品也是呈量级增长，这是否真的产生了价值？
A3：关于成本这一块，我们后面打造出一个治理引擎的模块，把日常开发的表建立的任务以及查询记录的具体成本明细通过各种方法统计出来，帮助用户结合自身考虑是否要优化使用。
Q4：日常经常用到的表或数据只占业务所有数据量的 10% 以内，有些业务数据因为业务逻辑变更已经失效，这方面在治理上有什么办法？
A4：由于每个人的精力有限，通过像基线监控，阻断的这些能力应用在核心数据上，相当于对数据的重要程度打上标记，在运维的模块会看到整个基建的安全产出率，即核心数据产出状况，针对这些数据来更好的治理。
Q5：软件工程思想的核心及工作中带来的帮助有哪些？
A5：软件工程领域有整体像 DevOps 流程的，应用在 DataOps 领域希望整个环节从规划生产到交付，有一些自动化的处理，另外更希望有一些协同的能力，比如有公共 python 的管理，可以在 python sql 开发时通过公共 python 进行代码复用，提升协同效率。另外软件工程注重整体的质量，在数据工程领域利用落地一些数据，测试数据质量来提升整体质量。
Q6：政务相关的业务相对成熟，有必要建数据平台吗？
A6：我们分析用户需求，了解业务里面的数据平台工具是否已经解决这些问题，没有解决的话尝试能否在已有的系统上重新把功能，比如通过 API 的方式重新组合，代价会相对比较小。
