一、背景

BI 分析系统市面上已非常成熟，从国内外开源和商业化各类组件百花齐放，也是互联网公司的最基础的数据基建之一，足够基础也足够经典。该系统承载的价值主要是提供业务监控工具的能力，由业务方，数据开发，数据分析，算法等有数据内容诉求的人进行使用。所以本文虽说名称叫做“BI 系统建设”，但也不会仅限于 BI，会按照业务监控体系的方向进行讲述。惯例下面还是简单介绍基本概念

BI（ Business Intelligence ），即商业智能。商业智能一词最早是由国际知名的 IT 咨询机构 Gartner 在 1996 年提出的，指的是用数据仓库技术、联机分析处理、数据挖掘和数据展现技术进行数据分析以实现商业价值。外界也有将商业智能定义为“使用基于事实的决策支持系统，来改善业务决策的一套理论与方法”

BI 最初始的概念就是报表和分析，现在包括了更广泛的技术内容，比如决策支持、管理驾驶舱、仪表盘、数据可视化、多维分析、数据整合、数据仓库、数据集市、数据挖掘

BI 分析系统指的是将商业智能这套理论进行产品化系统，包括管理驾驶舱、仪表盘、数据可视化、多维分析等

二、BI 的价值

两个核心，解决哪类目标用户的哪些问题？如上所述，目标用户的诉求是要有业务监控（报表，指标），那围绕着业务监控，就会有以下几个方面的使用诉求，

业务监控的用户诉求

场景

业务监控的场景，满足 pc 的场景下还有各类移动终端，手机，iPad

时效

数据时效性，常规的跨时间周期较长的报表统一是批处理的 T+1，同时也应有当日准实时的时效，无论是通过监听日志的流计算，还是提高离线同步频次到 T+1（小时）

功能 &数据

功能和数据放在一起，主要分为以下几点：

找数据

问题：业务部门在做各类汇报以及统计，在海量数据指标里做目标数据的查找。但有可能会出现是目标也不明确，口径也尚未统一，导致找到想要的数据非常困难，一般情况下只能通过数据产品或分析介入，人工多次沟通确认需求。

解决：报表中心搜索自己想看的数据,申请权限；自助提数，通过已有的指标及维度进行自由组合，或通过现成 sql 临时性查数据

看数据

问题：能有可以量化的业务指标进行查看，能及时监控业务的策略调整，要求数据的图形化表达足够丰富。

解决：多样的数据可视化组件，便于其个性化的数据内容表达，便于数据用户理解

读数据

问题：理解数据对应在业务链路中的关系，能将数据变化与业务策略挂上钩联系起来

解决：在看板里进行对筛选器进行细分条件的级联查询，并且在汇总数据里可进行多维拆解分析，由汇总移动拆解到明细，追根溯源

用数据

问题：通过报表查看，以及结合对应的数据分析输出有价值的业务决策 &预测信息

解决：数据主动触达，通过邮件看板订阅，IM 推送给到用户

目标用户

• 报表开发者：一般是 BI 分析师和数据开发同学

• 报表使用者：包括但不限于运营、服务、产品等任何对数据有可视化分析需求的同学

• 其他内部应用：有数据展示或数据分析需求的其他产品，比如用户画像标签，数仓表建模可视化进度跟踪

三、产品化解决方案

业务前台的数据监控诉求，在不同的业务（数据）规模阶段，根据人力现状及时间周期，各有不同，数据产品经理也应该具备灵活选型的技术方案，下面说一下如何进行开源产品的选择，便于实际工作中上手可用：

第一阶段：实现数据的基本展示

对数据指标的简单陈列堆叠。实现从 0→1 的系统化输出，以快速响应业务方查看数据的需求为目的。数据展示工具一般为简单的 excel 表格或截图，数据也直接从贴源层出，数据工程师被动式承接数据需求，基于各类需求的快速实现逐渐开始沉淀中间表。

特点：有基本的数据内容以及内容承载工具，数据时效性能得到基本满足

推荐产品：kettle，crontab+shell

kettle 是非常好用的轻量级的 ETL 工具之一，java 系，源码层次结构也较为清晰，阅读门槛不高；调度层面能实现最基本的任务编排和依赖和定时任务，程序编写层面也支持各类 shell，python，mr，sql 脚本的编写和上传，数据输出支持邮件正文的 html 展示表格以及 excel 附件；通过多资料档案库的部署可实现数据开发小组多人编辑，使用足够轻便，比较适合数据基本发送，整体数据量不大的情况。或或直接通过手写 shell 直接在 crontab 上进行调度的方式，也能解决具体问题。

这里说点其他的，建议每个数据产品经理都具备基本的数据开发能力，sql，python，kettle 多档案部署等，有了这些技能后可以凭一己之力搭建起业务部门的报表任务（尤其是当你空降在一片业务数据沼泽中，需要迅速拉起一套小型数据平台，笑哭），这些难度不高，实际集中训练一周时间就可，但关键时候可以解决大问题。

当然存在的问题也是很多的，因为本章只讨论上层的数据应用，那这里我们只讲数据层面的问题：

• 缺乏基本的数据可视化，无法快速做定性的分析；

• 大量数据指标简单堆砌，缺乏合理的归类整理和关联关系；

• 仅提供数据源，未对数据进行任何解释。

第二阶段：实现数据展示多样化

数据展示样式的多样性以及使用场景和时效性均由了一定提升，已经有了专门的报表系统提供统一的可视化入口，数据指标也更为丰富，数据按照门类进行摆放直接展示，也有了一定的数据中间结果的沉淀，计算效率有所加快。

特点：业务监控已工具化，数据初具体系化

推荐产品：ReportServer，Redash，superset，

Redash，superset 这些国外的 BI 工具，比较重视所见即所得，即如下图所示，输入 sql，直接根据 sql 结果就可以任意出图和数据，但这种情况在国内这种数据模型建设较为落后的大环境下，可能不符。但之所以这些工具会被推荐本质上还是较为符合第二阶段这种场景。即，如果你所在的团队对数据样式有一定要求，但又无明显的数仓，数据模型概念，也不想花费过多人力在数据资产内容建设上，只是单纯的做统计看报表，那上述工具就适合你

当然存在的问题也是很多的，这里我们只讲数据报表层面的问题：

它虽然有分析，但分析的结果并没有显性化，还需要具备一定背景的人进行解读

它提供了足够多的维度与事实组合，但依旧需要一定的手工配置成本

对于具体的问题进行抽丝剥茧分析时，依赖于手工配置，无法实现自助下钻

第三阶段：实现数据能力工具化

BI 系统中有了数据集合的概念，基于数仓建设规范进行数据模型的对接，上层应用分析以数据集的形式进行自由组合输出、满足各类 OLAP 的交互式查询分析，将指标按照业务场景进行重组串联，提高单个数据模型的复用性，减少碎片化报表的创建个数以及临时提数次数，降低报表的创建门槛及时间。

特点：数据模型引入，交互式 OLAP，通用性强

推荐产品：对于交互式分析需求有一定要求的，且具备二次开发能力，可利用 cboard 设计思路进行重构，没有二次开发能力的，建议使用 Davinci，两者都容易部署上手。当然，已

cboard：交互设计的不错，拖拽模式，支持邮件订阅 Java 系，且市场二三线企业有大量使用和企业二次开发版本，腾讯原 omg 事业群，酷狗，交通银行，vivo 等等大厂，有较好的社区环境但前端框架较为陈旧，展示 UI 不够美观，产品功能架构需要调整。

地址：https://peter_zhang921.gitee.io/cboard_docsify/#/

davinci：宜信开源的报表平台工具（现在这个组已经单独切出来作为一单独的解决方案公司），以拖拽模式的交互式，体验足够好，且在数据接入过程中提供数据调试页面，相较于 Cboard 有类数据库查询的客户端，可充当 ide 进行 sql 调试，对数据开发人员足够友好，Java 系，但业内没有成熟的二次开发经验，社区经验较少，权限管理模块不够成熟，授权较为复杂。

地址：https://github.com/edp963/davinci/blob/master/README-CH.md

以上各类解决方案都是笔者亲身经历过，对应的是如何低成本快速做出成果而言，尤其像 kettle，python sql 脚本这种方式，非常适合数据团队初见规模但需要迅速做出成绩的场景，而像 davinci，cboard，以及 redash 部署成本也都非常低，让运维同事帮忙部署后数据团队直接用即可。当然，如果有充足的产品预算以及时间周期，无论是自研，还是采购选择都非常多的选择，包括数 CDH 各类组件，批处理引擎，以及 OLAP 即席查询，对应的 azkaban 调度工具等等，这就需要专业的数据平台工程师来搭建了，不在本文的讨论范围内。

四、由商业智能到业务洞察

至此，如上所述，我们利用低成本的方式帮助业务用户在数据的找→看→读→上已实现基本覆盖，并且在场景，功能和数据上都有了支持，但仍有优化方向，它虽然有分析，但分析的结果并没有显性化，还需要具备业务背景的人进行解读；也提供了足够多的维度与事实组合，但依旧需要一定的手工配置成本，对于具体的问题进行抽丝剥茧分析时，依赖于手工配置，无法实现主动性的数据归因，到这里，BI 系统也就超越了它原有的【报表分析】范畴，产品形态也会发生变化。

第四阶段：实现数据监控业务洞察

对于业务部门来说，他们对数据的看→读→用的目的是为了实现业务的描述→诊断→决策，抛开整个需要基于用户最基本的业务诉求重新思考整个产品的设计方案。

想看数据的人潜意识里是要成“体”的数据的，只是沟通过程中变成了一个一个“点”的需求，因为“点”简单容易讲明白，也便于我们去实现。就和我们读书和学习某项技能一样，书里总是一个个点的技能教我们，随着“点”技能的增多，知识点串联起来就形成了体系化的技能树，我们就有了解决复杂问题的能力。所以“体”的数据才是真的意义上的用户诉求，核心报表的 OLAP 多维分析，级联筛选，上卷下钻，都是在解决由“点”到“体”的问题。

之前单个的报表都是在解决“点”的问题，多张报表是可以形成“体”，但是层次解构和易读性特别差，所以需要将报表中的“点”的指标抽离出来按照逻辑结构进行层次划分，形成指标逻辑树，解决“体”的问题

所以，BI 系统需要进行产品形态的升级，既要满足对整体业务大盘做清晰洞察，最快方式了解哪里出了问题以及对应原因，同时也要对单个数据指标做周期性查看，同时操作要足够简化，流程要足够简单，则

需要满足以下功能：

1、“体”分析：通过结构化的指标串联起所有业务分析过程，形成指标监控链路图，上层汇总主指标（原子）可进行子指标(派生指标)的归因分析

2、“点”深入：单个指标可展示日环比，周同比的异动趋势，一键生成归因分析报告，进行数据异动的解释原因

解决方案

“体”分析

对于体分析来说，用户的需求是能看到层级结构明确的数据指标，那产品设计思路就是按照业务流程和逻辑将整个数据链路铺展开来，提供可定制化的数据指标地图，以及相关的同环比异常高亮和预警功能，一目了然。同时当看到整个链路中某指标同环比上升或下降严重，则会根据单维度下钻拆解以及多维度分别拆解进行归因分析，定位到指标地图的叶子节点，找到其数据波动原因。

“点”深入

当我们打开整个数据链路看到看到业务全景流程的数据运营情况后，也会对个别节点的历史变动趋势做监控和查看，让各类运营同事做相应的细节追踪，同时针对具体的指标异动情况一键生成归因分析报告，进行数据异动，解释其原因，因为我司的智能洞察平台还在开发中（狗头保命），所以先贴几个火山引擎 datawind 的图：

--以上截图来自火山引擎 datawind

有了如上产品后，便可以将各类描述业务的数据报表，抽象成各种单指标多维度分析模型，与多指标相关分析模型，而通过整个全链路指标矩阵展开，使得业务同学不需要了解背后复杂的计算逻辑，直接可以看到分析结果，分析效率大大提升。继续留个坑，本阶段的产品正在开发当中，后续等推广运营有一定成效后，会专门开篇讲“第四阶段”的产品落地实战

五、结语

至此，在数据产品层面，从最简单的数据基本展示→BI 分析系统→业务洞察在功能，以及如何短时间落地的过程就基本讲完了，像数据平台搭建等实现技术细节，ClickHouse 等各类 OLAP 查询引擎中这些不在本次讨论范围之内，如果你的需求是在开发资源非常有限的情况下，需迅速拉起一套业务监控体系，或者说在在思考 BI 分析系统下一个版本的迭代方向，希望本文能为你带来一些启发和帮助。