为什么业务逻辑不应该存在于 BI 工具中 - 图1
2021 年 11 月 22 日
罗克珊娜·普赞德
transform
不要误会我们的意思，我们喜欢并使用 BI 工具，但我们相信业务逻辑应该存在于更通用和更易于访问的地方。
大多数公司使用多种下游工具来可视化、报告、分析和处理数据，这已不是什么秘密。在下游，我指的是数据在数据仓库中被提取、加载和转换之后出现的工具。常见的下游工具示例有Mode、Tableau 和 Optimizely。

业务消费者或数据团队可能会使用许多其他工具。这篇博文将关注下游商业智能 (BI) 产品。

大多数组织拥有不止一种商业智能工具

SAP的 2020 年商业智能趋势研究表明，企业平均使用 3.8 种不同的 BI 解决方案。让它沉入水中。3.8！这是平均值，这意味着有许多公司使用四种或更多的 BI 工具。这对某些人来说可能并不意外，也许您的公司已经找到了使用五种或更多 BI 工具的最佳状态，但这个统计数据让我大吃一惊。
这就是为什么它也应该吓到你（提示：这不是因为钱）……

更好的决策，更少的痛苦过程

无论您是像数据分析师、数据科学家、分析工程师或数据工程师这样的数据生产者，还是像业务分析师、经理或高管这样的数据消费者，您都可能遭受过以下方面的痛苦：在您的公司拥有多个 BI 工具。将关键业务逻辑存储在商业智能层中，并使该逻辑在工具之间有所不同，这会造成混乱并削弱信任。
让我们从数据消费者的角度开始……

您是使用数据向华尔街报告的人，为您公司的销售动议做出关键决定，或者呼吁在产品主导的增长计划上投资多少. 您试图了解为什么 Mode 仪表板和 Tableau 仪表板中的指标显示不同的数字。
为什么业务逻辑不应该存在于 BI 工具中 - 图2
你知道这些问题：

  • “哪一个是正确的和最新的？
  • 他们两个都错了吗？
  • 这些仪表板完全腐烂了吗？”

我们都去过那里。

这可能是一种麻痹的体验，它显然会减慢您的决策速度。当您的工作是在数据的驱动下为业务做出正确的决策，但您不知道下一步该做什么时，您会担心自己没有完成工作所需的信息或上下文。

很可能，您的下一步行动是寻找可能有上下文来获得正确答案的人。也许您找到了您过去依赖的数据主管、数据分析师或数据科学家，并试图让他们帮助您找到正确的指标值。
转向数据生产者的立场……

数据人可能正在微笑着向您打招呼并提供帮助。不过，在内部，他们对你每隔几周就不断地问一组类似的基本问题感到恼火（“再次？！”）。他们宁愿专注于有助于推动产品创新的探索性分析，也不愿回答你无聊的问题（严厉，但真实）。

数据人员调整他们的优先级并能够计算您正在寻找的指标，但实际上并没有意识到他们用于计算指标的字段与公司其他数据人员用于计算的字段不同相同的指标。迷人的！这意味着在 SQL 和这个同名 - 不同 - 逻辑指标的仪表板中存在多个定义，所有这些定义都与组织相关，并且可能被报告出来并用于做出决策 (oops)。
你现在可能明白了。无论您在数据的哪一边，这种冗长的文章都很糟糕。每个人都浪费时间来处理有价值的事情，仪表板不值得信赖，没有人会对数据感到自信，以一种孤立的方式延续相同的计算指标循环（即，“我只会问这个帮助过的人我之前”）。
当您遇到这些情况时，没有简单或可扩展的方法来对您的数据充满信心。要确保业务逻辑在业务使用的所有工具中完全一致，将需要大量的手动开销和资源。
这正是请扩音器的原因——为您的业务定义关键指标的逻辑不应该存在于 BI 工具中！

避免仪表板蔓延

假设团队或公司正在使用的给定 BI 产品将成为消费和分析数据的终极目标是不现实的。总会有另一个工具。因此，BI 工具不是捕获定义指标的重要逻辑的正确层，因为公司经常使用其中的许多工具。这是分析师和其他消费者可能使用的其他下游工具（如实验或 CRM 工具）的补充。

因为没有很好的方法来维护所有这些工具的定义，公司最终将处于仪表板蔓延的状态——多个仪表板代表类似的事物——没有人对哪个是真正的“真实”有信心。如上所述，这使业务团队处于瘫痪状态，并导致数据消费者和数据生产者浪费时间寻找“正确”答案。
我们建议数据堆栈需要一个独立于任何 BI 工具的度量存储来捕获业务逻辑并使下游消费保持一致。转换是堆栈中的一致性层，它允许业务用户在代码中断言他们的指标，使这些关键指标在所有下游工具中都是准确的，无论组织或团队使用什么。也许您的分析团队喜欢 Mode，而您的客户成功团队喜欢 Tableau — 这没关系！当指标逻辑在数据消费者使用的所有工具之前定义时，您就可以消除仪表板蔓延、指标不一致和对数据缺乏信任的情况。

如何在 Transform 的指标存储中定义指标逻辑

Transform 解决了这个问题，因为它允许您在一个地方定义指标，在每个下游工具中使用相同的定义，并像对任何其他软件产品一样对它们进行版本控制。此外，Transform 还主张对指标的所有权和批准，因此有一个负责的团队或人员来确保指标的正确性和可用性。

在高层次上，这是 Transform 在数据堆栈中的位置：
为什么业务逻辑不应该存在于 BI 工具中 - 图3
为了定义您的数据源和指标，MetricFlow具有简洁的 YAML 格式。继续使用相同的收入示例，假设您要从包含交易价值、交易金额和交易来源的产品线的表中定义收入。

首先，定义包含表中度量（如交易价值）和维度（如产品线）的数据源。该数据源将作为将在其之上创建的指标的构建块。您无需在其他任何地方定义此数据，数据模型的逻辑现在存在于代码中，未经批准不得更改。

  1. data_source:  
  2.   name: transactions
  3.   description: Transaction table
  4.   owners:   
  5.    - finance@company.com  
  6.   sql_table: finance.txns
  8. identifiers:
  9.   - name: transaction_id      
  10.     type: primary
  12. measures:
  13.   - name: transaction_value
  14.     description: The total USD value of the transaction.
  15.     agg: sum
  16.   - name: transactions
  18.      description: The total number of transactions.
  19.      agg: sum
  20.      expr: 1
  22. dimensions
  23.   - name: txn_date
  24.     type: time
  25.   - name: product_line
  26.     type: categorical

这就是您的数据源——您可以在其上构建一个或多个指标。现在，我们可以定义收入指标了！同样，一旦在此处定义，就无需在其他任何地方定义它，您可以使用Transform 的 Metric API将此数据移动到您喜欢的任何下游工具中。

现在您已经有了数据源，下面将介绍如何定义收入，计算为交易价值乘以交易数量的表达式。

  1. metric:
  2.   name: revenue 
  3.   description: Revenue from all products
  4.   owners:
  5.    - finance@company.com
  6.   type: expr
  7.   type_params:
  8.     expr: transaction_value * transactions  
  9.     measures:     
  10.       - transaction_value
  11.       - transactions

无论您是在生产还是使用数据，转换都可以帮助减轻仪表板蔓延所带来的痛苦。通过简化指标定义并允许业务用户以自助方式获取有关指标的上下文，这可以减少由于指标不一致而做出的不准确决策，并减少数据团队处理重复和平凡请求的时间，从而提高生产力并专注于您的团队关于更高价值的举措。

在一个地方定义逻辑是确保整个组织的准确指标的最佳方式。这也意味着您正在为您的业务做出最佳决策，无论您的公司使用哪些工具进行可视化、报告或分析。
我们知道能够与他们的所有 BI 工具集成对我们的客户来说是多么重要。这就是我们忙于构建集成的原因（我们最近推出了一流的模式集成）。关注我们的博客以跟上新版本！