导读： 本次分享主要介绍小米这几年在 BI 平台上的变革和演变发展的经验，分享题目为 BI 平台在小米的实践，主要包括四部分内容：

• 小米的 BI 平台发展演变
• BI 平台建设的探索和实践
• BI 平台目前的产品架构
• 未来规划和演进方向

分享嘉宾｜翁晓萍 小米 ⾼级产品经理
编辑整理｜王鑫民 同济大学
出品社区｜DataFun

01 小米的 BI 平台发展演变

首先和大家分享下小米 BI 平台的发展历史。

2019 年之前，小米各业务以主题式 BI 建设为主，没有一个全集团共同使用的 BI 平台，各个业务以自建的方式满足业务需要。

2020 年，随着小米成立大数据部，我们目标是完成整个数据中台的能力建设。当时脱胎于互联网体系，我们有打点统计、用户行为分析产品和 BI 可视化建站等产品，在不同的单点场景上去满足业务的需求。但由于产品太多，不同的产品之间不能拉通、数据不互通，为了统一数据平台完成了多个产品的整合，牵引底层数据采集能力和集团数仓能力的建设。

2021 年，BI 平台达到了一定的成熟度，集团大量的看板可视化需求涌现。在逐步支持大量需求的同时，切入了面向高管的集团看板场景，增强了移动化的能力和 IM 强集成。

2022 年，成为了集团公认的 BI 平台，从以往的互联网体系、电商体系这些泛互联网体系的业务上切入研产供财务体系的 BI 领域。原有的底层设计和产品形态无法支撑这么多不同行业体系下的交付，因此今年对整个底层架构包括产品形态进行重塑。另一方面以往看板的场景和形态下，消费和生产的链路很重，“如何去带动更多的数据消费，升级出更简单的产品场景”成为今年的工作目标。

从整个发展演变过程来看，2021 年之前，小米的 BI 平台是强贴合业务场景去做建设；2022 年之后，要真正成为一个集团级的 BI 平台，需要非常强的平台基建，包括底层架构、技术设计和产品形态。

02 BI 平台建设的探索和实践

那下面来介绍一下在这几年过程中小米 BI 平台经历的变化和打磨历程。

BI 平台建设的四个坑（难点）：

• 性能

BI 把查数和数据消费的形态搬到了产品界面上。用户在界面上操作，通常希望能够秒级返回。优秀的秒级性能表现依赖于数据量、OLAP引擎、查询服务、建模复杂度和可视化环环相扣的设计和联动，是建设BI平台的最大挑战。

• 建模

很多用户并不清楚到底哪些数据应该在数据处理环节解决，哪些应该在建模层的环节去解决，数据处理和建模有很多模糊地带。大家更倾向于把建模和算数的需求提到产品层面上。例如计算每个机型上市累计的销量，每个机型都有自己的上市时间，汇总累加的时间范围不同。这样的累计计算如果在建模层解决，非常消耗性能且查询体验不好，需要考虑在数仓层面解决。实际上很多算数的需求依赖于数仓和用户本身的建模能力，但是如果用户对这些背后逻辑和限制不了解的话，会天然觉得 BI 产品要解决所有算数需求。

• 可视化

可视化的需求是一个无底洞，因为可视化的标准是很难建立的。过往很多业务系统，根据业务需求做了大量定制的“看板”页面，但是这些定制的页面实现通用化是非常困难的。但是往往用户希望BI平台可以对标以往的定制页面，因为使用习惯有迁移成本。

• 权限

大部分的权限需求说起来很简单，“希望按照组织结构或者业务线开通权限”。但实际上在 BI 平台一侧，除了看板、数据模型有权限，看板上可能又需要设置某个人只能看到某一个国家或者某一个机型的细粒度管控，整套权限如何建设，又如何跟公司的组织结构挂钩，其实也是一个很复杂的过程。

下面详细讲一下围绕这些难点的 具体实践 。

数据系统选型上的尝试分为两部分：数据源的支持和引擎的选择。

小米 BI 平台建设之初，数据源只支持了 MySQL 和 Doris，因为这两个数据源在分析的场景下，性能以及查询的效果更好。由于业务需求过大，业务上频繁被问起为什么不能支持 Hive，因此做了 Hive 的支持，结果性能非常差，一个结果要离线跑个几分钟，在界面上是不可接受的。

反思：即便数据源要支持不同底层的数据类型，在引擎层要把不同的数据源类型性能做拉齐。BI 平台的终端用户是数据消费者，并不是数据生产者，数据生产者因为对背后的技术有了解对离线查询的性能可以接受，但数据消费者是很难接受的。

类似还有 Excel 支持的需求，刚开始很多业务反馈有些数据是本地文件的形式，需要支持；但是上线了之后，Excel 能力没有得到业务线的广泛使用。因为本地文件的数据依赖于用户自己手工维护以及追加数据，较为麻烦，成本上用户不愿意去持续地去做；因此在数据源以及查询的过程中，自动更新的能力非常重要。

今年切到研产供体系，非互联网体系的数据有非常大不同。以前接触到的数据类型都是比较开放的生态。研产供体系更多是 SAP 比较封闭的生态，例如今年使用的 HANA 数据库跟原有的数据类型非常不一样，语法要支持斜杠，在其他数据源上斜杠代表除号，在语法上要做特别的兼容。

引擎的选择决定了 BI 平台的性能、稳定性以及灵活性，不仅影响到技术层面，也会影响到查询功能产品层面。小米最开始用 Kylin 的方案做面向主题式的报表，后面做通用的 BI 平台，查询的灵活性 Kylin 是无法支持的，转到了 Kudu，但因为 Kudu 太贵，然后又转到了 Doris。Doris 对宽表 JOIN 的分析场景是比较易用的。2019 年引入了 Doris，2020 年开始全面推广，但当时 Doris 的成熟度不高，经常几个大查询，可能就会把集群搞挂，线上事故和稳定性是很大的问题，存在很大的运维成本。今年 Hive 使用 Presto 引擎支持，性能有了很大的提升。BI 平台的加速能力非常重要。

不管是数据源还是引擎的设计，对整个 BI 框架都有非常重要的影响，决定了 BI 平台的性能和稳定性表现。

• 数据量和查询策略

具体工作包括裁剪数据量、聚合维度、缩减时间范围、数据抽样、根据集群忙闲程度调度；把不同的查询区分成大查询还是小查询、做实时或离线查询的拆分、查询排队机制，以及大量的 SQL 优化工作。

• 产品功能优化

耗时预估的功能能够大幅地降低用户在查询上的焦虑感；提供性能分析功能，让用户知道真正的查询耗时在什么地方，是查询条件很复杂或者本身数据量就是比较大。其他细节优化还包括去重合计功能拆分、去掉模糊匹配的 Like 和正则匹配的查询、维度值查询和更新策略，在查询需求和性能上取得一个平衡。

• 前端加载优化

包括重点保障首屏加载，首 Tab 加载和分页加载策略等。

在查询体验优化上，环环相扣的设计非常重要，涉及数据底层、查询策略、前端和产品功能设计的匹配，是一个相当精密复杂的过程。

建模层面，去年之前以 SQL 的方式建模。每一个查询条件通过 SQL 拼接的方式查询，复杂的计算通过 SQL 片段实现；但是今年发现切入到研产供体系了之后，大量的算数需求增多，尤其是年度累计、季度累计、各种同环比的指标，SQL 的支持门槛较高。

今年转向 MDX 的语法查询和建模能力。MDX 是多维查询表达式，也是 PowerBI 和 Tableau 使用的建模方案，其优势是对复杂指标 MDX 天然支持了很多的函数，减少了很多开发成本。同时，在时间层级和维度层级上，MDX 天然地支持了很多上卷下钻的能力。架构演进上，业界已经有一些很好的实践，实践中应该去做靠齐。虽然今年转到 MDX 的查询和建模上，但是实际上也兼容了原来 SQL 的方式。

可视化是 BI 平台最核心的能力。

图表的可视化是业界很成熟的能力，但为什么很多图表在 BI 平台上还是画不出来呢？核心原因是这些图表基础组件只解决了最基础的展示需求，只是把数据能够描绘和展示出来。但是很多业务有自己看数或可视化的习惯，这是很业务领域的一件事情。

小米 BI 平台在样式上进行了大量工作，如各种可配置线条、颜色、条件格式等，但仍然只解决了一些相对通用和基础的能力，还有大量业务的样式无法支持，样式是非常难以通用化的。

不同的展示又有不同的需求，移动端场景与 PC 有明显不同。在 PC 的场景中，用户可以接受图表平铺，但在移动的场景下，联动和筛选的交互非常重要，对提升看板体验有很大的影响。

总结来说，大量定制的需求其实很难通用，或者说通用成本是非常高的。如果可以满足业务定制的需求，其实体验会非常好，比提供通用基础的组件在数据消费和使用上是更符合业务习惯的。在通用的架构上怎么能更好地跟定制结合，我们希望通过支持三方组件引入的方式来解决，也是后面要继续去做的事情。

权限方面小米实现了数据资源、功能资源以及 RBAC 管理的整套体系：数据资源自定义，包括维度分组、指标分组和模型关联；页面和看板操作资源细粒管控，区分看板作为页面资源管理编辑、查看的权限；权限 RBAC 管理，包括用户跟角色如何对应、角色跟资源如何绑定等等。

这个体系看起来很对，但是实际上非常复杂又很难用。在日常的工作当中，并不是很多权限真的按照组织架构开就可以的，很多时候的数据是一种横向协作的方式，很多协作导致权限要足够的灵活，粒度也要足够的简单。

BI 平台建设最大的挑战，是产品边界问题。在 BI 平台建设的过程中，业务侧希望一个平台能解决所有看数和可视化的问题，产研侧也曾经以为所有的查数和可视化需求都应该是BI 平台服务范畴，造成的结果就是：A 业务拿他们的一个定制的系统提需求，BI 平台要对标 A 系统，B 业务找另外一个他们定制的系统，对标 B 系统。对于 BI 平台建设而言这是一个很可怕的无底洞，因为所有的功能都在做加法的堆砌，导致系统复杂度非常高，维护起来也非常困难。

BI 平台解决的终极问题不是一个平台所有看数查数可视化的问题，而是要解决报表生产和数据消费效率问题，如何能带动更多的数据消费让公司数据化。

03 BI 平台目前产品架构

小米 BI 平台的产品结构，一共分为四层：数据源层、语义模型层、能力层、场景层。

最下是数据源层，支持离线的 Hive、Iceberg 类型数据，也支持在线的 MySQL、Doris 以及刚提到的 SAP Hana 数据库，包括本地文件和在线表格等。

语义模型层，对数据源进行建模、定义指标维度，支持日期转换、层次结构，以及拥有强大的函数处理能力。支持在建模之后做自动的数据加速，自动加速能力包括本身的加速库，查询引擎选择和查询层的缓存。

能力层，不只是可视化能力。可视化其实是相对比较成熟的能力模块，近期重点发展的是数据百科和智能分析的能力。平台当前已经支持那么多数据看板的建设，但是整个集团或者各个业务领域的数据还是无法打通。数据百科是基于语义模型能力，去自动构建指标体系和口径认证，通过在模型和看板层的数据，实现血缘溯源和指标分发。智能分析算法包括异常检测/根因分析、智能预警等能力。数据分析效率的提升强烈依赖数据智能。以往的报表量可控，但随着公司数据化的进程，报表量在膨胀和增长，怎么能更有效率地去做数据分析和数据消费，智能分析是一条必经之路。

最上层的场景层包括三种场景。第一是原始的报表场景，包括 PC、移动看板和交互式探索的能力。第二是报告场景，包括在线文档和订阅简报。第三是智能场景，通过智能分析和数据机器人，带动整个数据智能的场景。

右侧是权限模块。目前权限的实现是以分享为核心做的整套设计，包括的看板支持分享、模型知识分享、简报百科知识分享，以及跟 IM 强集成，背后是数据中台体系统一的权限服务，负责统一鉴权和统一登录能力。

04 未来规划和演进方向

整体来讲，未来的数据消费趋势一定是从数据分析到数据智能。数据分析其实已经提了太多年，但是整体的产品形态还是偏静态、固定式的报表或看板查询，更多的是一种人找数据的状态。

但在 ToC 领域，内容找人已经相当成熟了，很多的消费和分发的方式大家已经炉火纯青。但数据层其实更多的还是在固化的内容消费上其实是不对的，所以后面更多的是考虑是怎么去做一种互动式的消费。

一般想获取一份数据的时候，背后其实是想要获取具体的数值或者想知道它的波动原因是什么？通过机器人触点和简报推送的场景去牵引碎片式、互动式的数据消费方式。

未来的规划两个关键词——更业务，更简单。

更业务 ：作为集团级的 BI 平台，一定是要去解决业务问题。当转向研产供财领域时，不同行业领域上还存在很大的差距。怎么去支撑规模化的交付，能让业务跑得更快，要考虑怎么能够结合更灵活的定制能力，在基础架构上够支撑更大体量的业务。

更简单 ：基于怎么能让集团的员工在数据使用上更简单、效率更高来思考。这非常依赖于产品力的更新，以及整个产品形态是不是更符合比较轻的消费方式。目前看板的消费方式有很长的生产链条，用户需要经历开发数据表、建模、搭报表各种环节的研发才能获取到数据。怎么可以让数据获取链路更短，让分析变得更简单，是我现在在考虑的路线，打破原有的传统报表模式、引入智能能力、结合小米的场景创造一个更易用的消费形态。

｜分享嘉宾｜

翁晓萍

小米 ⾼级产品经理

2016年加入小米，一直致力于数据应用和平台的建设，目前为小米数据中台应用平台产品负责人。