数据指标两方面内容：数据指标的工具产品与梳理过程的方法论。

• 数据指标的工具产品：
  专门为数据指标服务的特定工具产品，在工具分类上，个人又分为“指标口径管理系统”和“指标数据查询系统”，这样的两种完全不同的数据指标工具产品。
• 梳理过程的方法论：
  数据指标梳理的过程，是一个和业务交流的过程，不需要依赖任何特定的工具，梳理过程中可以使用文档、脑图、Excel，来完成指标梳理的过程。而且，数据指标本身和数据分析，和业务结合的很深。个人并没有数据分析经验，这一部分主要写一些个人的理解。

1、为什么会有两种指标工具的区别

      个人对于数据指标工具有这样的区分，主要也是和个人的工作经历有关。之前做过数据开发，在开发数据模型的时候，曾经待过的一家企业也有过一个数据指标系统，当时的数据指标系统，能够实现数据指标的录入，可以理解为Excel维护的信息，在线化的进行维护。本来计划下一步，在建模型的时候，都使用数据指标系统里面管理的指标，在创建模型的时候以可视化的形式，下拉选择在数据指标系统里面管理好的指标，不允许手动输入模型字段，通过这种方式来保证所有建模的数据指标统一。但是这件事情并没有后续，随着时间也不了了之了。所以，现在每次听到数据指标系统，第一反应就是，这个数据指标系统，和我之前用的那个系统有什么区别那？也是想在创建数据模型的时候，不允许手动输入字段，通过下拉选择，从而保证模型里字段的唯一性吗？但是，有的数据指标系统，似乎又有数据查询的能力。如果通过这个指标系统能够查询数据的话，是不是就和上面说的是完全不同的两个系统了？所以，个人就对数据指标系统进行了一个分类。（这个分类很个人，目前没看到其他人这么分。）。这个分类就是，当说数据指标系统的时候，需要回答的第一个问题是：这个数据指标系统是一个指标口径管理系统，还是一个指标数据查询系统。指标口径管理系统，是面向数据加工者的，即主要是数据加工者使用。是在开发之前确定好指标名称，口径，取数方式等等，目的是让开发的数仓模型更加规范化。可以理解为一个在线的Excel，如果没有这个系统的话，指标信息的收集、保存都是通过Excel来完成。

指标数据查询系统，是面向数据消费者的，即主要是数据消费者使用。是让数据消费者能够更好的找到指标，并使用指标查询分析指标数据，甚至，想要直接通过指标数据查询之后，和BI可视化系统做关联，生成报表。目的是加速数据消费者的数据消费，统一指标口径，是一种数据消费的形式。这两个其实是完全不同的两个系统，或者说完全不同的内容。

2、“指标口径管理系统”的困境

      在上面也简单说了，指标口径管理系统，是一个在线的指标信息维护系统，保存的是梳理好的各个指标字段，算是一个指标库，它只保存最终的指标信息。而在指标梳理过程中，个人感觉仍旧是使用Excel更加方便、灵活一些。

这种在线版的指标口径管理系统有一个比较大的问题，就是除了一个在线Excel，起到一个指标口径保存的作用之外，怎么进一步的去使用这些指标是个大问题。

     目前想到的一种使用方式就是在建模型的时候，都使用指标口径管理系统里面管理的指标，在创建模型的时以可视化的形式，下拉选择已经管理好的指标，不允许手动输入字段创建模型。通过这种方式来保证所有建模的数据指标名称统一。但是，这种形式几乎不可行，如果要使用这种可视化建表的形式，则需要禁掉通过SQL创建表的权限。让所有的表，在创建、修改时，都使用可视化的形式。这种形式如果遇到几百个字段，都下拉选择，那么在交互形式上，在创建效率上，都是不可行的。而且，即使使用下拉在创建时选择了已经固定的指标。但是，指标名称统一，并不意味着指标口径就统一了。在两个选取了同一指标的模型中，维度设置的不同，那么虽然名字一样，口径仍然是不同一的。口径统一，意味这名称、粒度、维度等等的多种统一，下拉建表的形式并不能达到这个效果。这些在指标口径管理系统管理下的一个一个的数据指标中也没有办法体现。所以，即使采用上面说的建模形式，最终起到的效果也有限。且不说上面的形式会大大的限制开发的效率和灵活性。这就是指标口径管理系统的困境，似乎只能做一个指标信息保管库。没有特别明确的场景，来进一步使用。可能，能够在建模时，进行字段命名时，提供一些命名的思路。如果，提供命名思路的话，指标口径管理系统，还需要有一个对应缩写清单。什么样的中文，对应什么样的英文，对应什么样的缩写。在建模的时候能够参考这个清单，来确保建模的通用可读性。所以，结论就是，个人认为指标口径管理系统的使用场景有限。

3、“指标数据查询系统”的历史由来

“指标数据查询系统”，一般又都叫做指标平台。后续如果没有特殊的区分，那么指标平台就是指“指标数据查询系统”。

当说起指标平台的来源的时候，其实还和BI系统有一定的关系。可以通过BI系统的演化路径，来关联出指标平台。（不可否如BI可视化，是数据应用中的一个大头。）

我们先看看BI系统的一个演化路径，通过BI系统的演化路径，来看看为什么需要一个指标平台。

BI系统一共有几代，这个也没有一个唯一的标准，个人认为到现在是三代：第一代：传统式BI、自助式BI、Headless BI。

个人认为，ChatBI或者智能BI，仅仅是一种交互形式的增强，本质上没有什么变化。

• 第一代：传统式BI

• 此时，数据指标都保存在数据仓库中。（此时数据仓库可以理解为在Oracle或者MySQL上面构建的一个数仓）。而传统式BI只负责展示。代表产品：SAP BusinessOjects，IBM Cognos，OBIEE，MicroStrategy。依赖 IT 人员开发固定报表，灵活性差。

• 这种传统BI，基本上和传统的数仓相结合，是在大数据生态繁荣起来之前的一个BI解决方案。整个数据仓库的加工，BI报表的制造都是有IT部门来承担。业务人员只是使用最终加工好的报表。有新的需求也是再提给IT人员，由IT人员再进行加工调整。

• 第二代：自助式BI

        业务人员可自助分析，但指标口径分散在 BI 工具中。现在，自助式BI产品是一个较为主流的BI解决方案，不管是各个云厂              商还是国内的BI公司，基本都是自助式BI。传统式BI主要问题是什么？是灵活性不足，所有的BI报表展示需求都     需要统一          提交给IT部门，由IT部门来制作。所以，自助式BI也主要是想解决传统式BI的灵活性的问题。因为是自     助式BI，所以BI报          表的制造就不再归由IT部门来承担了。而是让各个      业务线的业务人员能够自助的创建BI。随着自助创建BI能力一同下放            的还有数仓里面的一表权限，也被下放给业务人员了。此时，自助式BI里面展示的数据指标，主要是将下放给业务人员表，            加载在自助式BI系统中，生成数据集，在数据集的基础上进行展示。     数据集也会进行一定程度的加工，生成新指标。代表          产品：Tableau、帆软等。

• 第三代：Headless BI
  通过独立语义层统一管理指标，支持 API 或 JDBC 协议对接多种消费工具（如 BI、营销系统），实现“一处定义，处处使用”。HeadlessBI是下一个阶段的BI产品，这个产品会需要和，NoETL、统    一语义管理，的基础上一个BI形态。目前个人并没有接触到特别好的    此类产品，听说Aloudata 有类似的能力（并未考证）。那Headless BI主要想解决什么问题呢？我们可以看到，在自助式BI将报表制作的权限下放给业务人员的同        时，也把数仓中的表一同下放给了业务人员，业务人员将下放的表加     载到自助式BI之后，进行指标加工后，进行展示。此时，最大的问题     就是被下放的数据表，由不同业务的不同人进行加工，所以加工出来     的数据指标没有办法统一。最终，造成的问题就是展示的BI报表指标     口径不一致。而HeadlessBI就是想解决这个问题，即能够让业务自助BI分析，又不    允许让业务自由的在数据表（数据集）进行新指标的加工，从而保证     指标的统一。而为了保质指标的统一，就需要有一层统一的数据指标     层，这也就是“指标平台”了。可以看出来，指标平台是位于，下层表（数据仓库）和上层应用（BI     应用或其他）中间的一层。代表产品：待确定。通过，BI的历史演进，我们看到为什么需要“指标平台”。如果再进一步总结一下。

这里可能会有一个疑问，第三代是否可以直接在数据仓库上构建BI，让数据仓库承担统一数据指标的定位。理论上可行，实际上不行。一方面，就是存储介质不同，大数据时代的数据仓库存储介质一般查询较慢，而BI类产品又需要能够较快的返回结果。

另一方面，就是有统一指标需求的公司，现实情况下的数据仓库已经庞大的无从下手了，能够从头再来，有一个干净的指标层是一个更好的选择。但是，反过来说，个人认为这种情况也一定程度上，意味着数据治理或者数据管理本身已经失败了，已经没有办法在数仓层面来做到数据指标的统一了。

指标平台的由来，就是为了解决业务自助分析时的指标不一致问题的。是在数据仓库和上层应用之间，增加的新的一层。即可完整的实现指标的规范化开发管理，也能解决指标口径不一致的问题。同时，通过调整存储介质，解决指标查询性能问题。

4、“指标数据查询系统”和现状的冲突

• 第一个冲突就是，如何让指标平台和自助式BI平台之间进行兼容。

  因为自助式BI的成熟，现在大部分企业均采购一套BI产品，这就注定了没办法通过企业内部自研来解决这个兼容问题，所以，只能等采购的BI系统在能力升级，抛弃将表导入生成数据集这种形式，而是直接引用第三方数据集的形式了。

   如果重头自研一套BI系统，那么成本时间又是非常大的了。

• 第二个冲突就是和开发过程的冲突。

  这个在之前的章节中也介绍过，一般的数据开发过程为“数据导入--数据加工--数据应用”。可以看到，这个过程中，数据消费者是直接使用最终的加工产物的，仅仅消费数据，而不会产生新的数据。

  而指标平台一般还会承诺，导入基础指标，能够进行复合指标的加工生产，这就承担了一部分数据加工的能力了。

所以就有一个边界的问题了。哪些数据在数据仓库中进行加工？哪些     数据在指标平台中进行加工？会不会出现同一个指标，即在数据仓库     加工了，又在指标平台加工一遍的问题？上面两个冲突，就是指标平台在落地时和现状的实际问题，是需要解决的。

5、“指标数据查询系统”的冲突解决方案

既然上面说到指标的冲突，那么，如果要让指标平台能够在企业内顺利落地就需要解决上面提到的两个冲突。

• 第一个冲突：和现有自助式BI的冲突

  解决这个冲突，可以是等待自助式BI能够更加灵活的和指标平台这一层进行关联，而不使用导入内部自建数据集这种形式。只要自助式BI升级了这个能力，问题就解决了。

  也可以自研一套自助式BI，不用等现有的BI厂商的升级。当然，这个成本就高许多了。

  你觉得哪种方案合适？

  或者，可以直接跳过BI系统，直接采购指标平台，因为很多指标平台，除了定义和开发指标外，也具有指标应用能力，支持简单的指标可视化，以及指标拆解。这样既可解决指标规范化管理问题，也帮助企业节约了BI的软件采购成本。不过也依赖于指标平台的数据应用能力是否足够，解决大部分可视化的问题，个人对这也是存疑的。而且，没有BI平台的话，需要有打破历史惯性的魄力。

• 第二个冲突：和数据仓库开发的边界问题

  个人认为，这个问题就需要有一个统一的体系化的数据指标目录了，能够在目录中快速找到需要的指标，并能够显示对应数据指标所在的位置。通过所有的指标，来对应出来存储的边界问题。

  从而，让指标平台能够存储所有的关键指标，作为一个数据指标标准化的单一可信源。

上面两个冲突的解决，都需要比较大的投入，所以本质上当前阶段的指标平台的落地，个人还是比较悲观的。但是，对于chatBI如果能够有一个更加规范的指标平台，来作为大模型的输入，对于提升chatBI的准确性又是有极大帮助的。所以，似乎这又是一个历史的方向。很多时候，要做什么这件事情的决定是复杂的，可能做的时候还没有想起楚，先做起来，边做边找路也可以。毕竟，先发占位也是一种思路。

6、现实中的“指标数据查询系统”是不是都做成了“指标口径管理系统”

在开篇的时候，就提到当提到数据指标工具的时候，会有这样两种划分。

实际上现在大部分企业都想要一个指标平台（指标数据查询系统），但是第一步不是想的怎么打通和BI系统的对接链路，不是想怎么和现有的数据加工做定位区分，而是第一步想着先把有多少指标给收集起来，在系统里面能够查询到。这就一下子变成了指标口径管理系统了。这些收集起来的指标没有和其他系统有联动，甚至单纯的做了登记的功能，完全没有下一步的应用了。这就是企业在做数据指标系统的时候，可能面临的一个问题，本质上还是没有分清楚两者的定位。

7、数据指标的流程性很重要

不管哪种工具，是“指标口径管理系统”，还是“指标数据查询系统-指标平台”，其中添加的数据指标，都是已经梳理好的指标，在添加指标的过程中，都需要一个流程化的审批流，才能够保证数据指标的稳定性。这两个系统中，管理登记的数据指标，会在下一章中介绍的数据指标体系的梳理过程，在指标口径管理系统中，指标的创建、指标的评审、指标的废弃等等流程，都是线上发起。且线上能够留痕，一直进行查询，一直进行升级。有的时候，这一部分和数据模型的发布审核过程类似，因为模型的新增，也是需要对应的数据管家进行审核的。

8、数据指标工具缺失的尴尬

上面介绍了两个数据指标工具，也表达了对这两个工具的态度，不管是“指标口径管理系统”还是“指标数据查询系统-指标平台”，在现阶段的落地情况，个人都是比较悲观的。要不就是缺少下一步的应用场景，要不就是和现有的现状冲突较大。但是，尴尬的一点就是，数据指标这样重要的一个模块，居然没有一个特别好的工具来保证统一的管理。梳理过程使用简单的excel或者脑图来梳理，没有特别好的工具。梳理结束之后，最终的指标结果没有一个特别好的保存位置。这不得不说还真是多少有点尴尬了。

9、总结

本章主要介绍了数据指标的相关工具，指出了数据指标工具，有两种形式，一种是面向开发的指标口径管理系统，一种是面向数据应用的指标数据管理系统，或者称为指标平台。