关注「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（这是数仓计算出来的离线数据），内容如下：

datecategorynameorder_countpay_succ_orders
20220701衣服A 品牌 T 恤500200
20220701衣服B 品牌 T 恤1000500
20220701数码A 品牌手机1000600
20220701数码B 品牌手机1500800

当初有一个需要：要求计算每个 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 前端团队。