不得不说，在数据技术大发展的今天，各种名词层出不穷。今天我就来聊聊一个比较新的名词-Headless BI。以及跟它相关的一些其他名词和关系。
在理解Headless BI之前，我们需要先理解一下什么叫做Headless? Headless的概念最初的来源与内容管理平台有关，一般是指内容管理平台中的一些应用不提供可视化界面，只是通过API方式把内容以数据的方式给前端。前端根据不同的设备类型，可以再去进行针对性地渲染和展现。
从这里，可以理解Headless实际上是把GUI部分跟数据部分进行了分离，这实际上比较符合现在技术的一种发展趋势，尤其是数据要去在不同的环境中去显示的时候。
现在回到什么是Headless BI？实际上就是把BI的数据指标层和展示层做了分离，把BI提供数据的部分以数据服务的方式提供服务，与可视化部分进行分离。
01
为啥要提出Headless BI?
那么为什么会提出Headless BI的概念呢？我们来看看一般的BI系统的整体的一个图：
上图来自于Gooddata在介绍Headless BI的博客文章。
在这个图里，有几个核心的模块：
Data Staging Layer - 对于现在的敏捷BI系统来讲，一般数据的来源都是一个居中的云端数据仓库，用于存储客户已经整理好的数据。比如Snowflake, Redshift, BigQuery或者Dremio等等
Analytical storage - 敏捷BI为了保证自己的处理效率，一般会有一个自己的分析存储引擎，不同的敏捷BI实现不同。有的采用预先建立多维立方体来保证多维分析效率，有的则是内存MPP架构来支持多维分析。
Semantic Model - 由于敏捷BI都是面向KPI和报表的，因此在敏捷BI中会有一层语义模型。这个语义模型会定义数据集之间的关系，指标的加工算法和表达等等。
但是，在基于云端数仓的这个时代，敏捷BI这种把几个部分耦合在一起的架构模式存在一些问题。最常见的就是如果一个企业内有多个团队，每个团队都基于数据仓库构建自己的敏捷BI，就会存在指标重复计算，而且出现KPI计算结果不一致的问题。
因为以上的原因，在现代数据技术栈中，Headless BI的需求得以产生。希望通过把语义模型层与可视化层分开，去解决前面提到的问题。
02
Headless BI架构
下图是Headless BI的架构设计：
大家可以看到，在新的设计中，Semantic model这一层与数据应用层做了分离。语义建模解决面向业务的数据集的定义、事实表的定义、维度以及度量的定义，包括指标计算的逻辑等等。然后通过开放API的形式提供给数据应用使用。
大家看到这里，可能会发现Headless BI的概念与metrics store要解决的问题是一样的. Metrics store的图如下：
