BI 报表正逐渐成为技术债，真的吗？

BI 报表是企业利用数据辅助业务经营和营销决策的利器，然而随着数字化转型的不断深入，许多企业已经进入“报表堆砌的时代”。尽管 BI 架构为业务用户带来了平民化的数据分析体验，但 IT 和数据团队依然面临着数据无法复用、指标口径不一致、开发效率低下等挑战，而这些逐渐演化为 BI 报表遗留下来的“技术债”。本文将从指标管理的角度出发，分享为什么说做好指标管理，才能真正发挥 BI 等数据分析技术的潜力。

1. 什么是技术债？

技术债是一个软件工程中的比喻，指开发人员为了加速软件开发交付，采用了一些不够严谨的短期方案，从而在未来给自己带来额外的开发负担。那么数据分析中的技术债是如何产生的？我们先从一个小故事开始。

Jack 是一家互联网公司增长团队的数据分析师，入职后他的第一个任务是配合增长经理为公司新产品制定邮件营销的策略。对于互联网产品而言，在用户对官网内容感兴趣留资后发送邮件是提升转化率的最常见手段之一，但如何设置邮件的发送频率和内容对“邮件打开率”这一指标的影响很大，Jack 需要分析过往数据，从中获取洞察和业务建议。

Jack 很快在公司数据湖 S3 中找到了过往邮件发送情况的数据集 edm_activities，而且是“清洗干净”的。但当他需要其他数据集时，例如网站访问数据，Jack 会仔细询问团队中的其他分析师这些数据的存储位置、数据的质量状况、指标的加工逻辑、数据权限申请的周期等等……

一边是寻找数据的过程艰难，一边是邮件营销任务刻不容缓。Jack 也不含糊，根据他从同事这里掌握的所有信息，一通操作猛如虎，完成了 ETL 和报表开发，顺利交差。Jack 心想：“我这次可是造福后人了，以后再有人分析邮件营销数据，可以直接用我的报表了。”

三个月以后，Jack 收到另一个任务，领导说团队本季度提交的 BI 系统扩容申请被拒了，要求他对系统做一次清理。Jack 激动地拿到 BI 平台的全局授权，但是眼前的一幕让他惊呆了：

• 自己的报表交差后再也没人查看过；
• 坐自己隔壁的数据分析师 Rose 上个月刚发布了一个相似度极高的报表；
• Rose 对“邮件打开率”的计算方式和自己并不一样，差异在是否把邮件退信的部分算入分母中。

Jack 赶紧找 Rose 商量是否可以合并报表以节省空间，两人却始终难以在指标口径达成共识，最后只能说“先放着吧，反正这只有两张报表，以后再说”。

2. 技术债从哪里来？

日复一日的“以后再说”，就渐渐累积成了技术债。Jack 和 Rose 故事中的公司采用的是最常见的数据开发流程，在这个流程中，每个报表都需要 ETL 开发、调度管理、存储资源来存储结果数据和临时数据、计算资源执行 ETL 任务。如果一张报表成为“技术债”，那么报表背后的一切都让技术债“雪上加霜”。

从更深层的角度看，这种乱象是由于长久以来企业对 BI 架构的思维方式造成的  ——  数据通过 ETL 流向数据湖或数据仓库，并通过报表实现可视化。每次需要一张新的报表时，就会向现有产品池加入一个新的 ETL 和一张新的报表；这种模式形成后，就会不断重复。随着业务的发展，更多像 Jack 一样的分析师和业务用户需要访问数据，更多报表被创建，也因此建立起更多的数据孤岛，各报表之间彼此重叠但又不完全一致，问题愈演愈烈。

在这种传统的 BI 架构中，企业数据与报表紧密耦合，并在报表粒度进行管理，势必会在不同报表间产生数据和指标的冗余和重复，久而久之就产生诸多技术债。

3. 如何避免技术债？

管理学大师德鲁克曾说过，没有指标就没有管理。如果对报表进行解剖，那么每个原子都是“指标”，可视化图表则只是展现形式。如果只堆砌报表，不管理指标，技术债就会越来越多。

以前，数据分析师都是以报表为核心进行开发与管理，因而上游数据和下游业务在报表层进行紧耦合，大多数指标难以共享。现在，我们可以试图转变一下思想，以“指标”为核心进行开发与管理，通过一个“指标中台”来解耦上游数据和下游业务，就可以很容易地实现报表间的指标复用。

Kyligence Zen 就是这样的一站式云端“指标中台”，用户只需要输入 S3 数据源链接，就可以自助地在 S3 之上定义业务指标，并与组织内其他成员共享协作，实现业务指标的对齐和复用。（访问 https://cn.kyligence.io/zen/ 即可免费试用）

Kyligence Zen 是基于核心 OLAP 能力打造的一站式云端指标中台，提供以下核心四大价值，解决企业在指标管理、应用、分析上的痛点。

• 高效协同管理：以指标作为企业共同的“管理语言”，对齐组织业务和管理，提高组织能力；
• 业务敏捷提升：数据需求更快响应，业务人员、开发人员皆可以摆脱低效流程和系统；
• 数据口径一致：集中管理指标，确保指标口径一致和数据可信，提高指标数据在不同业务间复用；
• 降低开发成本：业务人员自助创建、复用指标；数据团队摆脱繁重的 ETL 工作，只需聚焦指标管理，企业人效大幅提升。

4. 回到 Jack 和 Rose 的故事

使用 Kyligence Zen 以后，当 Jack 需要查看邮件营销数据时，可以自助在平台中看到所需的指标，例如营销邮件的邮件打开率、不同话题的访问热度等，并把自己计算的指标“等待周期”发布到平台中，供其他用户使用。

Rose 也可以完全信任 Jack。她可以在平台中清晰看到所有指标的定义和逻辑，放心地复用 Jack 的指标，对齐指标口径。Rose 还可以更快速地完成业务洞察，把用于寻找和开发数据的时间更多用在分析数据方面 —— 这才是数据分析师应该做的。

对 Jack 的领导来说，通过指标复用消除了技术债，系统利用率大大提高，也不用频繁申请扩容了。即使再申请时，也有说服力很强的数据支撑了。

了解更多云上数据分析与应用、指标中台趋势等内容，欢迎大家「报名」参加9月15日 Kyligence 秋季线上论坛。

关于 Kyligence

上海跬智信息技术有限公司 (Kyligence) 由 Apache Kylin 创始团队于 2016 年创办，致力于打造下一代企业级智能多维数据库，为企业简化数据湖上的多维数据分析（OLAP）。通过 AI 增强的高性能分析引擎、统一 SQL 服务接口、业务语义层等功能，Kyligence 提供成本最优的多维数据分析能力，支撑企业商务智能（BI）分析、灵活查询和互联网级数据服务等多类应用场景，助力企业构建更可靠的指标体系，释放业务自助分析潜力。

Kyligence 已服务中国、美国、欧洲及亚太的多个银行、证券、保险、制造、零售等行业客户，包括建设银行、浦发银行、招商银行、平安银行、宁波银行、太平洋保险、中国银联、上汽、Costa、UBS、MetLife 等全球知名企业，并和微软、亚马逊、华为、Tableau 等技术领导者达成全球合作伙伴关系。目前公司已经在上海、北京、深圳、厦门、武汉及美国的硅谷、纽约、西雅图等开设分公司或办事机构。