数据产品经理实战 - 数据门户搭建（上）

前言

在数据圈里各种数据产品的名称叫法层出不穷，很难直接从名称里看出该产品的定位。按照惯例还是得介绍下数据门户的定位及种类。笔者现在提到的数据门户系统指的是一站式集成的数据开发管理平台（以下简称数据门户），它包含了从数据生产，到数据加工，再到数据应用整个数据生命周期全过程的管理平台，它对分散且通用的功能进行抽象，将可以合并的链路进行打通，由点到面，一站式组合各种流程和组件，串联叠加配合完成对业务场景上的数据需求支持。数据门户系统本质上是后台产品，是后台逻辑梳理大于前台功能设计的产品，技术性比较强，本篇为数据门户搭建的上篇，重点讲述数据门户的定位以及需要解决的核心问题。

为什么需要这种产品

与数据相关的所有工种都是为了一个核心目标，即，让数据对业务产生价值。但这个目标的前提条件是得现有足量且符合应用标准的数据，这点在大业务体量的公司尤为常见，业务形态及策略千变万化，数据作为业务的下游得同步跟随业务的变化而迅速迭代，没有一套通用的开发管理平台无法赶上公司的快节奏发展，不停人力堆积肯定不是长久之计；同时，高阶数据应用生产源数据的过程在实际工程中十分费力，尤为在算法中，线性模型比树形模型的特征工程量大得多，而这个过程本身又和业务强绑定，无法进行全行业标准和通用化，那么统一且集成式数据开发管理平台的建立也就应运而生。

而从字面意思上看，所谓数据门户看似用一个简单的 web 导航入口就可以解决的问题，为什么会上升到系统级的解决方案呢？从需求层面讲，确实如此，每一款产品的诞生都是为了解决生产效率问题，都以用户觉得事情变简单作为目的。但回到产品本身，每个 web 入口后的用户体验统一，流程统一，服务统一若是真正做到了让每个用户觉得很简单，那项目背后的工程工作一定不简单。

数据门户支持的服务

具体项目背后的工程工作不简单到什么程度，和数据门户对外提供的具体服务为主。理论上是需要覆盖完整的数据链路过程，但是，集成并不代表没有分工，靠一个大而全的系统完成所有的功能，显然是不现实也是不科学的。我们走的不是一站到底直接构建一个大而全的系统的路，而是针对抽象通用的功能需求，分别构建独立的系统，在各个组件，服务，系统上做叠加完成业务的支持。

数据门户其核心关键点自在于各类服务组件是否融合顺畅。如要建设好公司的门户，对数据 pm 来说是非常大的挑战，它要求对整个大数据生态组件有着非常深刻的认识，因为不仅要考虑组件的分层结构，还要在系统功能丰富性和顺畅性做取舍，做到符合当前数据部，甚至也包括所有前台业务线当前数据管理开发流程的平衡状态。若功能过于丰富，很可能造成功能超前，暂不谈系统前期开发的人力成本投入，大量功能无人使用则该系统就会演变成为简单的功能堆砌，违背设计初心；若足够的顺畅，但功能性没跟上，久而久之用户依旧还会回归至各个组件与服务进行工作。所以，并不是把所有功能都集成到一起的全家桶就是最好的方案。

简而言之，每个用户都渴望自己的工作效率变高，数据质量变高，毕竟简单而便利是数据门户的重要目标。但提供服务简单而便利只是达成目的的手段，不可本末倒置，我们最终提供的服务最终目的还是要体现在其价值收益上，降低用户学习和使用成本，提高生产效率。

数据门户要解决的问题

首先有个前提，数据门户只是解决问题的一种答案，而且就算同样通过数据门户来解决问题，其系统后台逻辑很可能大不相同，下面笔者将通过几个较为典型的问题来描述数据门户的需求痛点，以小见大：

问题 1：统一入口，如果你是某企业数字化转型的数据架构师，带领团队负责新版大数据平台的部署及迁移工作，现在基本的 CDH 组件都已经搭建完毕，旧版老数仓中的数据报表，标签，模型，脚本逻辑等均已迁入新数仓，用户也已经接入使用，线上应用也已经正常跑起，算是整体数据平台的 1.0 搭建工作已完成。随着业务不断发展，迭代中的系统和平台使用用户也愈来愈多，流程也变得复杂，变得分散，该如何避免用户在多系统之间的来回跳转？

有了前面的铺垫，这里的发展方向自然是以一站式数据开发管理导航为目标。目的就是在一个系统里集中各类大数据开发平台的服务组件，方便用户的使用。这是可以通过一个简单的 web 导航入口就可以解决的，做好的用户登录信息的有效性，保证多路径下的功能层级统一，核心要点是产品设计和交互。

问题 2：集群管理，如果你是数据中台部门中平台开发组的 hadoop 集群管理人员，前台业务部门中有大量分析师想连到你 hdfs 中做些批处理工作，你得有效的确保集群服务的一致的同时还需要降低多租户的使用成本，而你的集群即将面临升级和迁移，你应该如何处理？

此时一般情况下会有以下几种方案：

1.对每个接入集群的租户信息都有专门的文档记录，集群变更配置，切分等人工进行通知

2.直接为租户提供 jar 包，通过提供定制的客户端 Jar 包来封装逻辑，避免租户直接配置环境变量和 Hadoop conf 文件

3.增加各种监控管理手段，对服务端的接口进行事前监控，并同步至租户端

4.以代理的方式，通过特定接口提供对象存储服务来屏蔽底层的集群，甚至直接进行对接口进行抽象封装，屏蔽接口直接对外提供服务

以上方案复杂性依次加强，通用性也依次加强，方案 1 与方案 2 本质上没有太大区别，均无标准和通用性；方案 3 是数据门户中多租户管理常见的一个监控配置项，系统提供专门的数据一致性监控功能，事前监控的同时甚至可直接同步至租户端；而方案 4 将直接屏蔽一切的集群接入信息，甚至将 hdfs，hbase，kakfa，es 等不同存储侧都抽象出来，对外提供服务，真正的让用户做到开箱即用。而这就有点数据中台的意思了，这里不做展开。

总之，对集群的统一管控，着眼的目标，不光是从运维的角度出发，提高部署效率和安全稳定性，也需要从业务的角度出发，尽可能屏蔽底层细节，降低业务耦合度，留出腾挪空间，提升系统监管能力。

问题 3：全链路开发协同，还是上面的场景，如若数据平台中来自某业务线分析师由于误操作导致提交至集群运行的脚本进行了非常规操作，污染了数仓聚合层的一个关键表，导致凌晨批处理操作的下游任务均受到了影响，不过好在影响范围可控，需要即刻进行恢复。那在服务恢复之后，事故复盘阶段，数据平台的管理层面如何进行事前的预防？

当然避免这样的异常远不止在数据平台的管理层面就可解决，这里只是描述数据门户在此种问题下可提供的服务。

1.多租户的脚本管理，避免片面的管理模式，数据门户需提供集中式的脚本编辑，储存和运行环境，便可做到事前的操作限制，避免误操作的可能

2.业务信息积累，有了脚本库的集中式存储后，相当于整个公司的业务脉络了然于胸，基于这样的海量存储信息，可以做到事中的脚本兼容性评估，自动化改写替换；事后的业务血缘关系解析，监控代码质量等。

3.脚本与任务的协同，要让脚本的编辑管理和任务的生命周期尽可能的无缝对接，从一个数据同步，主题表生成脚本，标签脚本，报表脚本的编辑，发布，调度依赖配置，尽可能的做到统一。要让个 dag 中变动信息及时反馈至整个数据链路，诸如可直接从从任务执行流水快速反向定位到对应的脚本等。

总之，要上几点内容可能在不同公司中均有不同的涉及，完善程度和融合程度均有不一，但理论上是越完善越好，融合程度越高越好。

（美团数据门户中的离线开发平台，资料来自“美团大数据平台架构实践”）

问题 4：合理的用户权限设计，如果目前数据平台发展的越来越大，组件也变得诸多繁重，针对每个用户权限也会管得严格起来，但与此同时带来的是业务不流畅，用户不开心；倘若进一步放宽权限，又无法明确具体的控制程度，应该如何设计数据平台下的用户权限方案，在尽可能保证用户体验及工作效率的情况下，确保安全性？

首先要提的是，这个权限设计方案是非常复杂的，因为本身大数据平台组件，服务众多；架构，流程复杂，想要在一个入口完成用户 id 的认证，授权，并映射平台其他所有组件十分麻烦，不是每个组件都会提供这样的接口供自定义更改，需要进一步到源码层面进行开发。而且不同公司不同部门负责的内容不同，即使有了解决方案也未必能顺利推行，所以他不仅是有技术上的难点需要突破，还有管理流程的推行问题。

自由意味着责任，责任意味着后果，不通过有效的规则和流程来对用户的操作进行标准化管理和管控，即使操作流程多么规范的用户也会出现问题，设计有效的流程管理和权限管理方案虽复杂，但它一定是必要的。

这就需要了解公司针对权限管理模块的期望程度，不同业务对于安全性的要求不一，需要分门别类进行梳理。每个用户的权限范围一方面需要业务自身定义，一方面也需要与第三方部门协同制定，共同制定一套经得起实际推敲和可供解释的方案，然后再基于一定的期望值，做合理的取舍，同步梳理流程定好制度，进行技术层面的工程化。

最后，集成开发环境本质上就是一个黏合剂，四通八达，对各组件做联动性增益，通过流程的建设和管理，在复杂的开发环境中为用户清晰的画出一条明朗的道路，实现开发效率，管理效率的提升。

结语

技术并不能解决所有问题，很多问题需要管理机制配合完成，但是技术本身可以降低管理的复杂性，增强管理的可落地性。

数据门户整个建设过程十分漫长，本篇也是将重点放在讲述数据门户背景及产品核心定位，由于产品其背后涉及的方方面面太广，太杂，讲的有些宽泛且落地性不强。一方面是的确是业内没有统一认可的标准，都是在公司内部因具体场景而异。另一方面是大部分具体问题都涉及到技术层面的架构优化，逻辑优化，这也不是本篇的核心内容。如若真的想做好数据门户，笔者建议负责该产品的数据 pm 有条件的话，亲身转岗至数据开发组与平台开发组一段时间，亲生感受实际应用场景，与目标用户面对面交流，更深层次的介入技术开发阶段，发现实际过程中的痛点，为建设系统做下足够多的铺垫。

原本计划是打算用一个篇章完整讲述完数据门户实战搭建的全过程，但现在看来一个篇幅是讲不完了，后续会单开一篇实战内容。下篇我们聊聊公司 C 端用户的运营体系搭建，数据产品经理实战-用户运营体系建设。