Fork me on GitHub

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

以下文章来源于 https://zhuanlan.zhihu.com/p/670774744

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

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

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

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

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

  4. 问答环节

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

编辑整理|彭爽

内容校对|李瑶

出品社区|DataFun

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

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

1. 数据全生命周期流程



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

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

2. 数据的产生



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

3. 数据的收集



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

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

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

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

4. 数据的存储



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

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



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

5. 数据的处理



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

  • ETL


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

  • 清洗


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

  • 离线和实时开发


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

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



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

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

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

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



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

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

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

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


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

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

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

从需要解决的核心问题出发,不同阶段有不同的定位,衡量标准也会动态变化。例如小米数据生产平台,最初是因为小米内部有很多类似的数据开发平台,而每个平台只能解决小部分问题,开发者需要跨 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:从需求出发,作业链路的调度,判断业务规模以及对并发度的要求,还有对实时和离线场景的要求,来提出具体诉求。另外,调度中的模型是否需要依赖关系来进行作业逻辑的编排,并由研发同事去调研,哪些调度方式更适合,小米用的是自研调度器,为了适应小米的数据特性而研发的。质量监控告警的核心偏产品层面设计,监控告警对作业本身的运行没太大影响,相对来说是一个事后监控机制,其实和应用场景类似,数据产生之后,查数看是否符合质量监控预期,质量监控选型更多从产品角度出发,去设计功能,技术要求并不高,更多的是和已有的技术开发与生产环节融合,提高技术兼容性。

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




本文地址:https://www.6aiq.com/article/1701866141364
本文版权归作者和AIQ共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出