数据可视化性能优化(0)：各类可视化平台产品理念/架构-杂记
Author：zhoulujun Date：
数据驱动决策的理念已经在不断地深入人心，目前商业领域由数据驱动的程度与日俱增。小型和大型企业都利用数据来做出与销售、招聘、目标以及他们拥有数据的所有领域相关的决策。尽管大多数企业都能访问某种类型的数据，但在没有数据分析或统计学背景知识的情况下，尝试理解这些数据非常困难。
大鹅的数据平台类有 Beacon DataTalk、欧拉，外面的滴滴，贝壳找房，有赞等，都有很不错的指标平台建设实践
腾讯灯塔DataTalk
数据请求流程：
开放丰富的组件
其是各类平台，对于可视化平台的基础能力，个人认为最好的方式还是基于插件化。
画布
数据驱动UI
每一个数据应用都由一张张数据看板组合而成，每一个数据看板，都是由一张张数据图卡组合而成。而每张图卡的数据可能来源于不同的指标和维度，也可能来自于不同的数据源。然而真实的业务场景会存在全局筛选过滤、局部过滤、数据下钻、数据联动等功能，而这些数据之间的交互在DataTalk中是通过【变量】去实现。
看到这里，你觉得很牛逼，这就是是数据可视化的全部了？但是这一套并不能很好满足业务需求！
现有 BI 方案的痛点
在目前的数据平台方案中，指标通常是被定义在 BI 层或数据仓库层中的，这样的方式引发了以下的几个问题：
数据架构复杂度高，数据分析效率低下
用 SQL 定义指标太复杂，门槛太高
指标只能 BI 工具中使用，无法对接更多业务系统
指标定义口径不一致，无法支撑业务决策
数据架构复杂度高，数据分析效率低下
将指标物化在数据仓库层是目前来说常用的一个解法，数据仓库支持将指标定义在视图（View）中，然后让其他工具去查询视图。
我接触的不少企业目前就是在使用视图来解决分析最后一公里的查询问题。使用视图的问题是仅能针对一些查询需求进行物化，在各类查询需求繁多的时候，数据工程团队需要准备大量的视图，开发成本极高，数据管道复杂不说，还很容易出错。
当上游的数据出现问题的时候，下游系统很难知道，就无法及时同步修复，这会导致数据的消费者如数据科学家，工程师需要花费大量时间来 debug 数据不一致问题，这使得他们的工作效率非常低下。
上图为引入指标平台之前的 Airbnb 数据平台：建立在核心数据之上的衍生表大量激增，带来了一系列问题
用 SQL 定义指标太复杂，门槛太高
数据分析系统有些分析常用指标，比如用户 session 数，漏斗分析用户转化率。
如果用 SQL 来定义这些业务分析指标的话，企业通常需要依赖专业的数据工程师，来撰写上千行的 SQL 才能够完整定义出来。
指标只能 BI 工具中使用，无法对接更多业务系统
而且就算能用 SQL 定义出这些指标，业务人员使用指标的场景是非常广泛的，不是简单的 BI 分析就可以满足的。
比如当某用户在使用某公司产品快要达到容量限制的时候，销售人员希望接收到容量使用率指标的告警通知，从而及时联系用户；比如为了降低用户流失，运营人员希望及时获取近30天未活跃用户，采取激活策略，如给用户一个免费续用。
仅在 BI 中定义、分析指标是不能够满足这些需求场景的，这些场景会涉及对接下游的 CRM 系统，订单系统等。
我之前也提到过主流 BI 厂商如 Tableau，Power BI 等都有自己的语义层概念，你可以在其生态中定义常见的层级结构，计算指标等。
Tableau 的语义层和其他方案相比会更专注于其软件生态中的复用，当在企业内有其他 BI 平台存在时（不同部门拥有不同 BI 平台是很多大企业的常态），这个语义层能力很难在更大范围内复用。
Power BI 虽然提供了 XMLA 终端支持语义层在更大范围复用，其考虑的场景还是通用 BI 分析场景的延伸，比如将 Power BI 的数据集同步给 Excel，Tableau 等来分析，而没有展现用指标层来支撑其他业务场景的能力。
指标定义口径不一致，无法支撑业务决策
个很简单的业务问题在不同团队那里会得到不同的汇报数字。更糟糕的是，没有人知道究竟哪个数字是对的。
理想中的指标层
nkur Goyal 和 Alana Anderson 两位硅谷投资人在这篇博客中提出了 Headless BI 的概念
“Headless BI：指标只需定义一次，就可以统一地在仪表盘，以及自动化工具中使用”
他们认为理想中的指标层应该通过 Headless BI 的方式来实现，需要满足以下条件：
无需写 SQL 就能够轻松定义指标
指标可以被灵活的用在 BI 可视化，下游应用系统，并通过 API 消费
指标支持大规模查询，从而支持大量的自动化流程，比如触发邮件通知，支撑交互式产品体验等
于是在可视化和自动化流程中间就出现了一个空缺的市场机会，需要由 Headlesss BI 来填补。
Headless BI 倡导的理念是“指标一次定义，就可以支持 BI 工具或在其他应用简单有效的使用指标”，在大型组织中，通常存在多种 BI 工具，各类需要供数的下游系统，统一的指标定义，多工具复用就是一个共性的需求。
在现在的解决方案中，指标层和使用消费它的 BI 系统的紧耦合，限制了指标数据在更多应用场景发挥价值。
如果能够将指标层和 BI 解耦开，打造出 Single Source of Truth 的指标层，那么各类下游系统数据消费的时候，就可以达到真正的口径统一。
引入 Metrics layer，意味着使用指标的人不需要关心一个指标是怎么来的，只需要用文本描述想提取哪个指标。它向 self-service 用户隐藏的不是构建查询的复杂度，而是指标计算的逻辑，业务人员只需要做选择，而非创造。关于抽象，一个经典的说法是「计算科学中的所有问题都可以通过增加一层抽象来解决」。
Headless BI?
那么为什么会提出Headless BI的概念呢？我们来看看一般的BI系统的整体的一个图：
Data Staging Layer - 对于现在的敏捷BI系统来讲，一般数据的来源都是一个居中的云端数据仓库，用于存储客户已经整理好的数据。比如Snowflake, Redshift, BigQuery或者Dremio等等
Analytical storage - 敏捷BI为了保证自己的处理效率，一般会有一个自己的分析存储引擎，不同的敏捷BI实现不同。有的采用预先建立多维立方体来保证多维分析效率，有的则是内存MPP架构来支持多维分析。
Semantic Model - 由于敏捷BI都是面向KPI和报表的，因此在敏捷BI中会有一层语义模型。这个语义模型会定义数据集之间的关系，指标的加工算法和表达等等。
但是，在基于云端数仓的这个时代，敏捷BI这种把几个部分耦合在一起的架构模式存在一些问题。最常见的就是如果一个企业内有多个团队，每个团队都基于数据仓库构建自己的敏捷BI，就会存在指标重复计算，而且出现KPI计算结果不一致的问题。
因为以上的原因，在现代数据技术栈中，Headless BI的需求得以产生。希望通过把语义模型层与可视化层分开，去解决前面提到的问题。
Headless BI架构
在新的设计中，Semantic model这一层与数据应用层做了分离。语义建模解决面向业务的数据集的定义、事实表的定义、维度以及度量的定义，包括指标计算的逻辑等等。然后通过开放API的形式提供给数据应用使用。
Headless BI的概念与metrics store要解决的问题是一样的. Metrics store的图如下：
欧拉平台
数据治理似乎成了一个人人都似懂非懂的词，甚至大有“人人要参与治理数据”的趋势，人人都知道数据治理要做啥、要做成啥，但人人都不知道数据治理啥时候能有结局。我觉得数据治理的最终目标是实现数据生产和应用的工业化。要实现数据工业化，可能会有 2 种场景案例：
欧拉在数据接入治理工具 datamesh，作业调度平台 us，数据仓库 tdw，一站式机器学习平台 venus 之上构建了全链路数据血缘图谱，为我们的用户提供数据发现、资产工场、指标中台、治理引擎四大核心能力，其中 t-Metric 指标中台 是精粹！
一个简单可理解的量化目标，牵引业务和治理平台双向奔赴：
我们为什么要做指标中台？或者说指标中台是为了解决什么问题？
我们知道现有的架构通常是这种前后端分离的模式，后端就是我们生产、存储数据的地方，像数据仓库 Hive、关系型数据库 MySQL 以及 ClickHouse、StarRocks 这些 OLAP 引擎，前端就是我们消费数据的地方，典型的例如各种BI工具、实验平台、机器学习平台等等。
这种架构的特点是，对于同一个指标，我们无法跨平台复用，指标的度量公式是分散在不同平台的，它隐藏在各个仪表板中。这些指标在没有被监督或指导的情况下重复定义了多次。重复意味着难以维护、意味着发散式的修改，自然会带来同名不同义、同义不同名的情况。此外，数据开发具有一定的技术门槛，需要专业人员参与，分析人员无法做到自助生产，从提出需求到上线指标，时间周期较长。最后指标字典通常是开发人员人工维护在各种文档、wiki 中，很容易出现遗漏的情况，用指标的人也没有有效的检索方式快速找到自己想要的指标。
Headless BI
我们知道有几个重要的软件设计原则：DRY (Don’t Repeat Yourself)、封装、抽象。
Headless BI 就是借助软件设计的思想，在指标的生产者和消费者之间引入指标库 Metric-Store 以一种标准化方式来集中定义和管理指标，为指标使用方提供统一的查询服务，以此来消除指标重复定义的现象，收敛指标出口。此外 Headless BI 系统通常还具备物化加速、指标目录等功能。
建设思路
核心能力
基于 Headless BI 的理念打造了一套核心能力，涵盖指标的建、管、查、用四方面。
建，就是生产指标。支持用户基于单表或多表模型以一种规范化、标准化的配置驱动方式生产指标，以达到生产即治理的目的。我们还提供一些低代码的能力，方便用户不写或少写 SQL 即可生成物化任务。
管，就是管理指标。包括指标权限的管理，指标上下线、认证、审批等。如果指标有变更，我们会以消息通知的形式触达使用这些指标的用户。
查，就是发现指标。上线的指标即可被检索，我们提供基于关键词、维度、表、指标等级、业务主题等多种检索方式高效查找想要的指标。
用，就是使用指标。我们向使用方提供一套统一的 API，与整个 PCG 生态更好的打通。
指标中台，要为指标的生产者和消费者服务。我们为生产者提供了一套配置驱动的生产方式来生产指标。
我们如何表达一个指标呢，通常一个指标包含度量（原子指标）、维度、业务限定、统计周期四个部分，比如说最近7天各省市区体育类视频总播放时长这样一个指标，我们把它转换成 SQL，度量就是我们用什么样的聚合方式进行计算；维度对应的就是 group by 的部分；业务限定对应的是 where 条件；统计周期就是这个指标要以什么样的时间窗口，以什么样的粒度去做统计。语义层的作用就是把表和列映射到有意义的业务实体，用户可以用业务友好的语言定义指标。
我们支持 BG 内常用的四种存储引擎，包括 Hive、MySQL、ClickHouse 和StarRocks。维度建模是数仓开发过程中一个普遍需求。我们提供了可视化建模的能力，用户可以通过拖拽、点选等方式选择表和字段，配置多个表之间的关联关系，得到一个逻辑大宽表。当然，我们会对模型进行去重校验，以避免用户重复构建。
有了数据表和数据模型之后，接下来就可以定义指标了。对于简单的逻辑，可以在界面上选择字段、聚合函数和运算符以完成指标定义。对于比较复杂的计算逻辑，可以填写 SQL 片段，我们会进行语法校验，确保保存后能够正常使用。
t-Metric 架构
参考文章：
腾讯灯塔DataTalk——如同乐高，这是一个开放/自由的数据可视化世界 https://zhuanlan.zhihu.com/p/568942341
腾讯欧拉t-Metric指标中台实践 https://www.sohu.com/a/729941260_121124371
腾讯欧拉平台数据血缘架构及应用 https://www.51cto.com/article/783330.html
腾讯欧拉数据治理平台思考与实践 https://zhuanlan.zhihu.com/p/579654173
给 BI 砍头？聊聊指标平台的崛起 https://cloud.tencent.com/developer/article/1917593
有了自助 BI 还需要数据分析师吗？ https://zhuanlan.zhihu.com/p/370783097
转载本站文章《数据可视化性能优化(0)：各类可视化平台产品理念/架构-杂记》,
请注明出处：https://www.zhoulujun.cn/html/webfront/visualization/rudiment/9083.html