关于前端:Datav从零开始的数据可视化大屏搭建系统

关注「Shopee 技术团队」公众号，摸索更多 Shopee 技术实际

目录
1. 现状剖析
2. Datav 设计与要害节点实现
   2.1 整体架构设计
   2.2 如何进步各角色之间的合作效率
   2.3 如何反对元数据计算
   2.4 如何反对页面疾速配置
   2.5 页面组件直连数据源
   2.6 反对组件联动和筛选查问
3. Datav 带来的收益

随着 Shopee 业务数据的不断扩大，仅通过表格这样的数据分析形式曾经无奈满足日常的数据分析需要，丰盛的图表剖析 Dashboard 就显得分外重要。然而，从事前端开发的同学都晓得，这种 Dashboard 页面纯手工开发会消耗比拟多的人力资源和工夫资源，在量比拟多的状况下，可能业务需要都没方法及时响应了。

如果能有一个能够主动生成这些 Dashboard 页面的工具平台，那么能够节俭大量的人力和工夫，效率晋升将会十分显著。本文将分享如何从零开始创立一个数据可视化大屏搭建零碎。

1. 现状剖析

先来看一份数据。咱们团队均匀每个季度会有 3-4 个 Dashboard 相干需要，均匀每个需要的我的项目周期约 40 天。目前曾经累计有 20+ 页面，每个页面的图表组件约 50+，另一个筹备重构的平台（Stella）Dashboard 页面 25+，波及到的图表组件更多，粗略统计 100+。

这些 Dashboard 页面绝大部分页面内容简单，交互也简单。依照传统的开发方式，一个页面的上线大概须要 PM、Dev、QA 共 50+ 人 / 日。

除开人力资源，接下来看看开发一个 Dashboard 的研发流程是怎么的。

这是一个再失常不过的开发流程。在整个流程中，用时最多的就是数据同步、接口数据聚合、页面开发、联调这四大块——大概占了 70% 的工夫。如果能有一个平台解决这几个问题，那么这个平台对于 解放人力瓶颈、缩短研发流程、进步研发效率 就有着十分大的意义。

目前市面上相似的平台十分多，咱们也做了很多横向比照。综合来看，思考到业务场景的贴近水平，以及开发投入和收益，最终咱们决定自研平台“Data Visualization”（下文简称“Datav”）。

咱们心愿这个平台可能承当的角色如下：

Datav 平台承载了两个次要指标：

• 缩短我的项目周期，从 40 天缩短至 20 天；
• 缩小人力老本，FE 从 10 人 / 日缩小到 3 人 / 日，PM 从 15 人 / 日缩小到 5 人 / 日，不再须要 BE 和 QA 参加。

2. Datav 设计与要害节点实现

为了可能达成以上两个指标，咱们将 Datav 要实现的性能形象成了五个关键点：

• 重塑整个我的项目流程，进步 PM 和开发之间的合作效率；
• 反对简略的元数据计算以及更加灵便的数据查问；
• 反对页面疾速配置；
• 反对页面组件直连数据源；
• 反对组件联动和筛选查问。

2.1 整体架构设计

接下来将一一介绍每个关键点的实现，下图是咱们的整体架构设计。

整个 Datav 平台蕴含五个十分重要的子系统和模块：

• Designer：设计器是 Datav 平台的外围与难点，反对页面布局配置、页面交互配置和组件数据配置等性能，另外还反对代码片段的配置，也能够称得上是一个低代码平台。
• Admin：是 Datav 的经营治理平台，蕴含了数据计算、作品治理、组件状态治理、页面公布、页面权限等等惯例的平台治理性能。
• UI Components：是整个平台最根底的模块，咱们在开源的图表库下面定义了一层规范的 DSL 协定，这个协定和接入 Designer 的协定是对应的，目前曾经有 50+ 相干组件，组件数量还在一直增长。
• Datav Server：是一个 node 服务，次要提供一些权限校验、数据聚合、动静 SQL 的生成等性能。
• Datasource Access Server：专门用于连贯不同数据源的服务，例如直连 MySQL、ClickHouse、Elasticsearch、Presto 等等，提供了不同的连贯 client。

从架构图能够看出，Datav 平台反对直连各种数据源，最终会产出一个 URL，能够不便地集成到任何平台上。下一步打算是反对生成源代码，可供使用方进行二次编辑。

2.2 如何进步各个角色之间的合作效率

在解决这个问题之前，咱们和各个角色之间进行了屡次沟通，剖析了各个角色在我的项目中的痛点以及破费的老本：

• PM 侧的痛点是画原型图，每个需要画原型图须要破费 10 天左右的工夫，而且还是动态的图片，跟开发对完需要后，还须要去改外面的一些静态数据，而后再进行 PRD 评审；
• BE 和 FE 次要的精力花在页面开发、接口开发、数据同步以及页面联调这些事件上。

从传统的开发流程来看，这些都是失常的流程，是最小开发门路。要解决这个问题，咱们就须要重塑整个我的项目的流程，让各个角色都能参加到配置中来，于是咱们一起从新定义了 Dashboard 我的项目的开发流程，如下图。

• PM 能够间接在 Datav 下面配置原型页面；
• Data Dev 也反对间接将数据计算的后果主动同步到 ClickHouse；
• FE 能够通过 Datav 直连数据源，并且能够复用步骤 1 外面 PM 配置的原型页面，进行配置优化；
• 最终生成页面的 URL，PM 能够间接拜访 URL 进行测试。

新的流程成果十分显著，整个我的项目周期缩短了一半，从 8 周缩短到了 4 周，也不再须要 BE 和 QA 的反对，FE 均匀只须要投入 3 天反对需要。

2.3 如何反对元数据计算

2.3.1 基础知识

反对元数据计算是个比较复杂且宏大的性能。数据是所有零碎的基石，任何平台和业务都离不开数据的流转。同时，数据的流转也是非常复杂的，特地是在数据量比拟宏大的状况下。

咱们先来认识一下数据的产生和流转都做了什么事件，以及从客户端产生数据开始，到 Dashboard 看到数据的聚合，都经验了哪些阶段。

上图是一个惯例的大数据平台的架构图，它分明地形容了数据产生到数据利用的整个过程。可能外面有一些专有词汇对于 FE 来讲有点生疏，但这里咱们只须要理解：用户所产生的数据，须要通过一系列的加工之后，才会有比拟大的价值。

上面再用一个更容易了解的流程图来阐明：

从图中能够看出，数据筹备有四个要害流程，数据采集、数据预处理、数据建模、数据服务，每个阶段都有一系列的事件要做，Data Dev 同学能够借助数仓以及相干工具，疾速产出业务所须要的数据，Datav 平台不会波及到这部分的性能，Datav 所解决的是在数据服务之后。

这里从数仓产出的数据，尽管通过了一系列的计算，然而往往也不是页面展现想要的数据。依据教训来看，一个 Dashboard 页面往往会有十分多的数据聚合逻辑，也就是说还须要依据数据服务产出的数据进行数据聚合。例如要计算同比、环比这样的指标等等。

2.3.2 Datav 买通数据直连通道

业务方须要做数据聚合，也就意味着须要后端开发提供 API 接口给前端。数仓产出的数据，因为环境隔离和权限等起因，目前无奈间接给业务团队应用，因而业务团队应用这些数据有一个特地波折的过程，使得整个流程比较复杂、链路也比拟长。

这个流程 BE Dev 阶段须要提供两个服务，一个数据同步服务，一个 API 接口服务。粗略统计，BE Dev 这一步须要破费整个我的项目流程 30% 左右的工夫，而且这些工作也是反复的。

因而 Datav 解决的第一个问题——买通数据直连通道，采纳的计划就是直连 ClickHouse。

Datav 提供了一个 直连数据源的服务，能够间接连贯 Data Infra 团队提供的 ClickHouse，这样一来，大部分 Dashboard 页面就有了直连数据源的能力，不再须要依赖 BE 团队提供 API，使整个我的项目周期缩短了 30% 左右的工夫。

下面提到，API 次要作用是用于一些数据聚合和数据逻辑计算的，那么 Datav 是如何反对这些性能的呢？这就是 Datav 面临的第二个大的挑战——反对数据聚合计算以及逻辑字段减少。

2.3.3 反对元数据计算

接下来用一个简略的例子来阐明：Datav 如何实现代替 API 接口反对一些数据聚合计算。例如，有一个销售表 tab_sales（这是数仓计算出来的离线数据），内容如下：

当初有一个需要：要求计算每个 category 的领取成功率。

依照以前的形式，API 接口会依照类型先把数据查出来，查问 SQL：

失去原始数据后须要进行计算，失去最终右侧的数据结构给到前端：

试想，如果 Datav 可能产生这样一条 SQL，查问进去的后果也可能返回同样的数据结构，是不是就能够不必依赖 API 接口了？带着这样的疑难，咱们做了很多的尝试。

最终论断证实，在大部分场景下，齐全可能不必依赖 API 接口。就如同下面的例子，咱们将 SQL 变动一下，就可能失去雷同的数据结构：

2.3.4 Datav 数据管理

为了解决上述两大问题——如何买通数据直连通道、如何反对元数据逻辑计算，Datav 建设了数据管理模块。

数据管理是比拟重要的一个模块，在配置页面之前，第一步想到的应该是这个页面的数据都来自哪，页面中每个组件的数据都来自哪张表，是否是通过某些字段计算失去的等等问题。

因而，数据管理模块应该蕴含几大块：数据源治理、数据字段编辑（包含字段名别名、新增字段、反对字段间的计算、字段格式化、字段展现权限等）、数据主题治理（反对多表间关联产生逻辑数据宽表，以及自定义 SQL 查问生成数据主题）。流程如下：

1）数据源治理

目前数据源反对直连离线数据源（MySQL、ClickHouse），行将反对直连实时数据源（Kafka、Elasticsearch、Prometheus 等）。

2）数据字段编辑

字段编辑提供了针对表以及表字段的别名设置、表字段权限设置、新增逻辑字段、字段逻辑计算、字段格式化等一些列高级性能。

3）数据主题治理

数据主题目前反对可视化配置和自定义 SQL。目前可视化配置仅反对单表设置，行将反对多表关联造成逻辑宽表。

多表关联性能如图：

自定义 SQL 查问如图：

2.4 如何反对页面疾速配置

反对页面疾速配置的外围就是 Designer 的实现。跟目前业界低代码平台实现的思路相似，都是通过将页面组件的地位信息、属性用一种通用的两头协定 DSL 来形容，而后通过解析引擎在运行时动静去解析 DSL，再渲染到页面中。

架构如下图：

为了进一步提高 UI 和 FE 之间的合作效率，咱们预留了一些高级性能。

• 例如实现一个 Figma 插件，能够让 UI 在设计页面的时候就用到咱们的组件，而后通过这个插件生成页面的 DSL 产物，再交给 Datav 解析引擎去做页面渲染；
• 还有一种更加大胆的想法，就是通过机器学习的形式，将图片中的组件辨认进去，主动生成页面的 DSL 产物，最终再交给 Datav 解析引擎去做页面渲染。

这两种计划都还处于设计阶段，临时还没有实现。

Designer 这一块性能比拟多，而且比较复杂，这里就不开展细节讲。咱们目前曾经实现了两种页面布局的形式：相对布局和 Flex 布局。针对不同的场景，采纳不同的布局形式，页面配置效率会十分高。

Flex 布局：实用于页面构造简略且清晰，相似 Admin 表单类型页面的配置场景。

相对布局：页面结构复杂且组件布局毫无法则的页面配置，大屏页面就特地合乎。

2.5 页面组件直连数据源

组件直连数据源的关键点包含：

• 了解维度和指标；
• 了解如何生成一个 SQL 语句。

接下来先用两个例子直观阐明：

这是一个二维一指标的图表，一个维度是日期，即 X 轴；另一个维度是柱子的分类，指标就是 Y 轴的数据。

如果要生成这样一个图表，那咱们的 SQL 语句应该这样写：

Select [indicator] from [table_xxx] group by [dimension1], [dimension2]

从 SQL 语句中能够发现，维度属性放在 group by 前面，指标属性放在 Select 前面。

再来看一个例子：

同理，这是一张一维一指标的图，对应的 SQL 如下：

Select [indicator] from [table_xxx] group by [dimension1]

了解了维度和指标，以及 SQL 的生成规定后，基于这样的思路，咱们实现了一个 Data-Connector 组件，这个组件能够配置维度、指标、分页、排序等等字段，最终再依据这些配置生成一个对应的 SQL 语句。

它对应生成的 SQL 语句是这样的：

SELECT field1 FROM Demo-Table GROUP BY date_day LIMIT 1000 OFFSET 100 ORDER BY  field3  ASC

这样，咱们就实现了组件直连数据源，展现对应的动态数据。

2.6 反对组件联动和筛选查问

在绝大部分的场景下，咱们配置进去的页面不是一个动态页面，它须要动态数据，也须要各种交互，最常见的就是筛选这种交互。

交互对于页面配置来讲是一个难点，因为交互特地多，有些交互也特地简单。Datav 目前只反对了局部交互，例如组件数据筛选、按钮点击事件、弹窗、tab 切换等等比拟常见的性能。

咱们先看一个例子，为什么肯定要反对组件间的交互呢？

这是咱们利用组件直连数据源查问进去的数据，你会发现数据量十分大。

这个时候，有可能会导致组件解体或者页面卡死。因而，解决这种问题最好的形式就是反对数据筛选，即反对一个组件能够筛选另一个组件的数据，如下图。

这就是咱们心愿取得的成果：用一个筛选组件管制图表组件的数据量。那么如何实现呢？

咱们也调研了业界的相似计划，最罕用的就是反对写代码，利用公布订阅设计模式来实现。实现原理大抵如图：

这样做的劣势非常明显——简略，然而同样也存在一些有余：

• 须要写 JS 代码，只对前端同学比拟敌对；
• 如果关联组件比拟多，那代码保护将会变得非常复杂；
• 页面配置的效率也会大大降低。

因而，为了解决这些问题，Datav 实现了可视化配置组件联动，对于简单的状况，也反对写代码的形式。实现原理也不简单，总结起来分成四个步骤：

• 建设筛选组件和展现组件的关联关系，以及筛选组件和筛选参数的关系；
• 监听筛选参数的变动；
• 一旦筛选参数发生变化，告诉所有相关联的展现组件，并将新的值传递给它；
• 告诉工具函数拉取新的数据并从新渲染。

原理架构图如图：

整个 Datav 平台比拟宏大，有十分多的性能点，很多性能点的设计都能够独自写一篇文章来介绍。而本篇文章次要围绕 Datav 解决的一些关键问题来开展，咱们心愿通过这篇文章让大家理解到 Datav 是一个什么平台，能解决哪些问题，实用于哪些业务场景。因而在技术细节下面并没有太多的开展，后续会另写文章介绍。

3. Datav 带来的收益

Datav 我的项目带来的收益能够从流程优化、开发效率，和根底建设等方面来考量。

3.1 流程优化

整个我的项目流程的周期从原来的 40 天左右缩小到了当初的 20 天左右。消耗的人力也有所缩小，不肯定须要 BE 和 QA 同学的退出了，我的项目周期缩短了 100%。

这是因为 PM 同学能够间接通过 Datav 平台配置页面的原型，确定好需要后，这个原型配置能够间接交给 FE 同学进行加工，加上一些交互和数据相干配置，就能够间接提测。

3.2 开发效率

单从前端的开发效率来看，均匀 10 人 / 日缩短到了均匀 3 人 / 日，效率晋升 200%+。

从整个研发阶段的效率来看，以前须要参加的人力总和为：(Data dev) 10 人 / 日 + (BE Dev) 13 人 / 日 + (FE Dev) 10 人 / 日 = 33 人 / 日。

当初人力总和为：(Data dev) 10 人 / 日 + (FE Dev) 3 人 / 日 = 13 人 / 日，从 33 人 / 日缩短到了 13 人 / 日，效率依然晋升了 150%+。因而 Datav 对于研发效率的晋升来讲，也是意义不凡的。

3.3 根底建设

除了下面提到的量化收益，Datav 还带了比拟多的隐性收益，例如在团队根底建设上的：

• 制订了组件开发标准；
• 建设了一套规范组件库以及组件平台；
• 积淀了一些规范的 Node 中间件，例如 logger；
• 积淀了一套规范的自动化脚本，组件创立、主动编译、自动化生成文档、代码标准检测等等；
• 更细粒度的权限管理系统（建设中）。

本文作者

Shopee Digital Purchase & Local Services 前端团队。