小米数据生产平台的产品设计方法与实践

导读 本文将分享小米数据生产平台的设计与实践。

文章将围绕下面四点展开：

1. 数据生命周期全流程介绍

2. 技术驱动型产品的设计与协同经验方法论

3. 小米一站式数据生产平台的产品建设思路

分享嘉宾｜刘莹 小米科技 计算平台产品负责人

编辑整理｜彭爽

内容校对｜李瑶

出品社区｜DataFun

01数据生命周期全流程介绍

首先，从产品经理的角度，给大家用浅显易懂的方式介绍一下数据的生命周期全流程是什么。

1. 数据全生命周期流程

数据从生产到应用全流程大致可以分为 5 个步骤，首先是数据的产生，接下来对产生的数据进行收集，再找个容器存储起来，存储后进行处理加工，最后把数据投入应用。大部分数据产品都对应这五个环节。而今天要介绍的小米数据生产平台重点在前四个环节，我们将前面四个环节统称为数据生产链路。

数据生产的过程，可以用水的产生到应用做一个类比。首先，水产生于雨水、以及江河湖海中自然产生的源源不断的水资源（产生），因为我们需要利用水资源，所以人为修建堤坝、水渠、水库来将这些水分流收集并且存储起来（收集&存储）。希望这些水可以为我所用，就需要一些处理流程，进行水净化、过滤、消毒、去污等一系列操作（处理），最终不同处理方式的水可以分别用于饮用水、灌溉、工业生产生活等场景中（应用）。数据的流程和水的生命流程是类似的。

2. 数据的产生

生活中的行为会产生各种各样的数据，互联网时代，线上数据较为常见，例如使用手机、电脑、手表等电子用品，人们在以上的终端进行各种操作，就会产生行为数据；另一类是和生活更密切相关的线下数据，例如逛商店、做运动、听歌、拍照、录视频等线下实体行为，同样会产生数据。

3. 数据的收集

数据产生后，根据不同的终端或者维度，进行数据收集。数据的收集是将不同的业务系统、终端、源头的数据实现互联互通。

线上数据采集分为客户端和服务端，客户端与用户联系更紧密，常见的有 Web 端、网页端、安卓和苹果手机的操作系统等。

线下会通过物联网工具去进行信息的采集，例如，摄像头、传感器或者 Wi-Fi。另外一种传统途径，例如在之前特殊时期，会通过线下问卷或者表格的方式去登记信息，也是一种数据收集过程。

第三类是较为特殊的数据收集过程，通过爬虫采集外部数据，这类数据不是直接产生，而是在合法合规的前提下爬取已有的数据。另外，业务系统的跨源同步，也可以认为是数据收集的过程，把不同的数据类型汇集到一个更易于应用的大数据系统中。

4. 数据的存储

我们在日常生活中，选择存储容器的时候，会考虑很多因素，例如：被存储物件的形状、样式、形态、规模和使用场景，常用的物品希望存得近一点，成本也需要考虑，要权衡花费多少性价比最高。

数据存储容器的选择也是类似的逻辑，数据的结构以及存储的格式，数据大小和条数，在使用场景中，希望是查询性能更高，还是可扩展性更好，还是并发度更高，在数据的存储和计算过程中有多少损耗，还有技术上的考量等等，决定了我们用什么存储系统来存数据最合适。

根据不同的数据结构、规模、使用场景，会选择不同的存储类型。大致可以分为五类：关系型数据库、NoSQL 存储、网络及消息队列、文件系统和大数据存储。图中高亮出来的是常见的存储方式，小米用的是 Iceberg 和 Hologres。

5. 数据的处理

存储完成之后进入到数据加工环节，它是将原始的、堆砌的数据进行数据资产建设，加工后服务于数据应用场景，使其产生业务价值的过程。处理过程分为三个方向：数据ETL和分层建设、对关键内容进行清洗、用不同的数据处理方式进行计算

ETL(
Extraction-Transformation-Loading)，中文名为数据抽取，转换和加载的组合，利用 SQL 语句，所有关系型数据库的公共语句，将数据抽取出来，经过格式转换与清洗，再加载到目标库中。形成数仓分层的表，对数据进行归纳整理，简化数据，去重，提升数据使用效率。这是 ETL 的过程及产出价值。

可以联想到生活中洗衣的过程，去污渍、去原本多余的内容、补好衣物、晒干叠好。数据清洗的核心有：将问题数据修补完整，剔除冗余数据、将数据统一整理，将原始低质量的数据转变成高质量的数据。

• 离线和实时开发

此处对离线开发和实时开发做一个简单介绍，还是类比水的概念。离线开发就如水用于发电或发热，需要达到一定的量级才能实现能量转换，具有更高的输出效率，离线的过程需要量的积累，再来批量处理。而实时开发就如落雨后直接进行分流、去污处理，没有中间蓄积的过程，数据的产生和加工、应用是同步进行的。所以，离线开发是批处理，而实时开发是流式处理。面对不同的业务场景和开发诉求，我们可以选择不同的开发模式。

6. 小米的数据生产平台架构

小米平台覆盖了数据的产生、收集、存储和处理四个环节，基于计算引擎和存储引擎，在元数据、权限、调度以及集成引擎的基础服务上。该平台提供了四大核心能力：统一的数据采集与集成，对采集到的数据进行多引擎的存储，对其进行离线或实时计算，数据输出用于分析运维等应用。应用一方面是在平台内部，一方面是提供给更上层的服务，例如 BI 工具、API 接口服务、系统平台的打通等多场景支持。

02技术驱动型产品的设计与协同经验方法论

1. 数据生产平台是技术驱动型产品

以上提到了很多技术概念，包括流批一体、SDK、引擎、Iceberg 等，我们可以说整个数据生产平台是一个技术驱动型产品。

技术驱动产品有两大核心特征：

首先，产品是以技术为核心竞争力，强烈依赖底层技术架构和技术创新为主要方向，更注重系统性能和稳定性。

同时，用户以技术人员为主，无论是写 Java,SQL 还是 python 的程序员，他们都是比产品经理更懂底层技术逻辑的用户。

• 技术型产品常问的几个问题

• 本文地址：小米数据生产平台的产品设计方法与实践
• 本文版权归作者和AIQ共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出

如何在技术型产品中凸显产品经理的作用？

产品经理是做桥梁的，我们需要把技术语言转化成产品语言，把用户语言转化为产品方案。另外设计落地、顶层规划、产品拆解、项目管理和后续的运营推广等工作，同样是产品经理的专业职责所在。做好这些我们擅长的事，就能发挥很多价值。

如何衡量技术型平台的产出价值？

从需要解决的核心问题出发，不同阶段有不同的定位，衡量标准也会动态变化。例如小米数据生产平台，最初是因为小米内部有很多类似的数据开发平台，而每个平台只能解决小部分问题，开发者需要跨 N 个平台才能完成一系列的开发工作，所以才会建立新的一站式数据开发平台，来统一解决数据开发过程中的问题，那么平台的核心考量指标就是旧平台的下线率、已有业务的迁移率、新平台被用户使用起来的资源覆盖率等等；在统一平台之后，希望被更多的用户使用，所以使用频率以及用户的渗透率变为核心考量指标。再继续发展，我们成为一个成熟的产品，一样会开始关心用户留存率、访问量、粘性、甚至满意度等等，衡量产出价值的方式有很多。

工作方法上会不一样吗？是否更加需要产品做更终局的思考？

任何事情都没有真正意义上的终局，局部最优解也是最优解，规划的时候整体思考，但是落地的时候需要小步快跑，快速验证，重要的是在不同阶段不断地更新业务认知。所有工作本质上和其他类型的产品经理是没有区别的。

• 技术驱动型产品中，产品经理该怎么做？

总而言之，让专业的人去做专业的事情，所有的事情都是由价值来牵引的。产品为用户产生价值，是最终的落地点。拥抱变化，更新自己的认知和策略，才能让我们走得更远、更稳。

2. 小米实践案例分析

• 案例一：技术驱动架构升级

由技术驱动整个架构升级，产品做配合落地工作。一站式数据生产平台，以前没有数据湖的概念，是基于 Hadoop 体系，利用 Hive 或者 Spark 建设的传统数仓。随着数据量的扩展，性能和成本问题显现，原有的模式无法适应新的数据使用场景，所以由技术牵头，引入数据湖的概念，来解决传统数仓的成本以及事务型问题，在数据湖的选型环节，技术同事做了很多调研与分析，选型确定为 Iceberg,基于 Iceberg 选型的基础，产品团队结合数据生产全流程的链路的能力环节，规划出在其中哪些环节将 Iceberg 数据湖的形式落地，在流程上实现产品能力。

• 案例二：产品驱动体验效率优化

案例二是由产品来驱动，技术来实现的案例。小米内部有上百个业务团队，业务场景复杂，不同的数据开发与产出都有前后依赖关系，因为依赖关系建立过程极其繁琐，从产品视角，希望在建立血缘关系的过程中，提升用户效率。通过业界的产品调研，我们计划将依赖关系做成拖拽式，将节点拉入画布中，连线建立依赖关系，选中某个节点，可以快速聚焦关键节点的关键链路，除了手动配置，也可以解析 SQL 语句，判断依赖关系，做智能和自动的依赖动作，用户只需要二次确认，就能快速完成一系列复杂的依赖配置。这些都是由产品调研与交互体验分析出发来决策功能形态，技术团队在此基础上完成具体实现的例子。

• 案例三：技术的升级使得产品能持续完善

案例三，Hive 引擎的查询机制受限，查询平均耗时有 888 秒，原有的查询耗时过长。新的平台，技术同事引入 Presto+Spark3.X 的升级，查询效率大幅上升。在技术和架构的升级之上，产品能够持续完善与扩张，例如多引擎多表的联查以及根据 SQL 语句表的范围，智能路由到最佳引擎上。在日志诊断上有风险提示等扩展功能，产品经理突破原有架构的限制，引入了大量交互式查询的设计，使得整体用户体验有了较大的提升。

03小米一站式数据生产平台的产品建设思路

1. 小米数据生产平台的推进思路

小米数据生产平台建设的起因是，小米内部存在很多烟囱式开发，有很多同类型的数据开发平台，每个平台功能有限，且平台之间不连通，用户会遇到权限、性能、统一数据管理等各种问题，因此需要一个统一的平台，来收敛并打破烟囱。

推动统一需要在旧平台基础上有一定的能力扩展，并且有新的功能吸引原有的用户群体。在用户都引入一站式平台之后，我们并不希望用户在新的平台上野蛮生长，所以建立了通用的规范化的流程，来提升数据开发的质量和效率。一站式是一个持续的过程，工具好用才是最终的发展方向。

小米集团对数据开发的核心目标汇聚在质量、安全、成本、效率这四个方向。

• 基础服务的统一为"破烟囱"奠定基础

上文有提到数据生成平台的架构，对架构精细化拆解，来说明我们能做好一个统一数据平台的建设。首先，技术侧牵头，梳理出一个稳定的技术架构，能支持多种存储引擎和计算引擎的接入，通过统一的元数据、权限、调度以及集成服务的能力，才能形成功能的落地。

• 可扩展性高的产品形态

在大的技术架构之上，由产品同学提供核心输出，无论未来接入多少种存储、计算和跨源数据引擎，都希望产品的体验是一致的，并且在开发和使用的过程中，不需要有太多额外的学习成本，这样有利于提高开发效率，降低用户的心智培养成本。此阶段又对产品提出核心要求，由技术人员来实现，最终建设一个可扩展性高的产品形态。

• 特色化的生产开发流程

将规范化的流程落地，由技术来梳理。小米目前的模型，是否能参照业界的隔离机制，技术决策后，由产品来制定小米自己的数据生成开发流程。这个流程的关键点是以什么形式进行开发与生产的隔离，数据上和流程上的隔离。小米用工作量的概念，进行开发态和生产态的区分，补充流程环节的检验。产品针对业务的使用情况和痛点问题，来设计数据管理流程。

• 一站式的数据生产体验

一站式数据生产体验，由产品来主导。我们是一个工具平台，需要始终以用户使用起来更趁手，为业务助力为目标。作为一个开发工具，我们也计划向 IDE 形式靠拢，在研发体系中引入 DataOps 的概念，更高阶的功能，实现智能写 SQL 的功能等等，有更多的产品突破。

• 在更大的维度上做全景扩展，提供更多完善的服务支持

整个的产品不应该是独木成林的，数据生成平台在数据链路上处于底层环节，核心是数据采集、存储、计算、查询与运维能力，数据生产后，如果能被数仓更好地建设起来，对数据进行分层梳理，才能为上层的应用提供服务。建设好以后的数据，通过统一的资产管理，对成本、质量、安全进行把控，并且在应用场景上支持标签的构建，提升效率和可利用性，为最上层使用，可以做BI可视化报表，数据智能支撑，人群圈选、行为分析等应用场景的结合，融合专业的数据分析团队，针对性地制定一套产-建-管-用的解决方案，为公司内部提供一套完整的服务，与更多的能力联合，才能发挥更大的价值。

2. 层次递进的平台建设思路

最后总结一下平台建设思路，整体上是层次递进的过程。

从复杂的 N 个产品中，找到唯一收敛的方向，这是一个从 N 到 1 的收敛过程，过程中需要详尽的分析调研，抽丝剥茧，求同存异，来找到唯一突破口；

方向确认后，将平台从 0 到 1 构建起来，MVP 逐步拆解，小步快跑去验证是否可行；

验证可行后，进入 1 到 10 的扩张阶段，在规范化的基础上，不断扩大产品边界，扩大能力范围来促进所有业务和场景的深度使用，同时把历史问题快速收敛；

收敛和历史问题都解决完成后，就要回归本心，一开始就是面向技术人员的工具平台，核心解决的是工具的效率，对业务产品价值的支持，一边克制一边创新，寻找符合定位的更多可能性，使得产品发挥更大价值。

04问答环节

Q1：小米数据生产平台的监控机制是怎样的？

A1：有专业的数据监控模块去把控数据质量。基础作业运行成功/失败，数据内容是否符合预期，设定数据预期，不符合预期，产生告警。小米有重要保障的数据，在问题发生之前预警，有基线机制，在部分任务资源上有倾斜，任务能优先运行完成，且链路上游环节资源保障，在任务没有运行完的时候提前预警，把风险暴露出来，尽快去解决。

Q2：Presto 和 Doris 在平台上都有，它们是如何分工的？

A2：Presto 和 Doris，取决于引擎本身的特性。Presto 的查询效率非常高，缺点是业务逻辑复杂或者遇到大宽表 Presto 无法做很好的支撑。Doris 更多应用于分析型的场景，BI 分析或者业务分析，查询数据产品报表的场景，应用更广泛。所以在数据即时查询用的是 Presto 引擎，直接出结果；对于特殊的表，用 Doris 查询，且用 Doris 做数据开发，同时推送到 BI 平台用于报表展示。

Q3：数据湖和数据仓库在平台中分别起什么作用？

A3：数据湖可以实现流批一体，实时计算和离线计算可以交叉运行，一体化完成数据湖的建设；数据仓库更多是用于离线开发，对于时效性要求不高的数据，例行化执行，进行基础的仓库建设。

Q4：平台各模块的技术选型，作为产品经理如何参与选型过程？

A4：从需求出发，作业链路的调度，判断业务规模以及对并发度的要求，还有对实时和离线场景的要求，来提出具体诉求。另外，调度中的模型是否需要依赖关系来进行作业逻辑的编排，并由研发同事去调研，哪些调度方式更适合，小米用的是自研调度器，为了适应小米的数据特性而研发的。质量监控告警的核心偏产品层面设计，监控告警对作业本身的运行没太大影响，相对来说是一个事后监控机制，其实和应用场景类似，数据产生之后，查数看是否符合质量监控预期，质量监控选型更多从产品角度出发，去设计功能，技术要求并不高，更多的是和已有的技术开发与生产环节融合，提高技术兼容性。

以上就是本次分享的内容，谢谢大家。