魔百和数据可视化平台_数据平台可视化体系建设实践

最新推荐文章于 2022-11-15 19:36:27 发布

weixin_28940939

最新推荐文章于 2022-11-15 19:36:27 发布

阅读量476

点赞数 1

文章标签：魔百和数据可视化平台

本文链接：https://blog.csdn.net/weixin_28940939/article/details/112065982

版权

在大数据领域，数据可视化对于分析海量数据而言至关重要。关于数据可视化体系，每一个人都有自己的理解，相信大多数人会认为数据可视化就是一堆图表。过去两个多月，我们在直播业务数据需求的推动下构建了数据平台的可视化体系，本文将分享我们在构建过程中自己的一些思考和总结。

1. 背景

今年下半年公司决定研发微博直播，直播研发团队提了大量的业务数据需求，带来了一波业务数据需求的激增。

同时又赶上我们团队前端页面研发的人员流动，一时间没有了专职前端研发。原有的可视化系统，图表采用定制化的开发模式，增加或变更数据展示需求，都需要修改代码上线发版。新增页面开发周期长，短时间内很难支撑激增的数据可视化需求。

为了提高支撑数据可视化需求的效率，迫切需要平台化、体系化的构建数据可视化体系。

2. 用户需求分析

构建数据可视化体系，首先要从用户需求出发，解决用户看数的难题。

平台数据可视化系统的用户，根据需求，可以划分为两类，一类是读者，一类是作者。

读者用户数据可视化的需求明确，以查看数据报表为主。该类用户以中高层管理者为主。

作者用户除了查看数据报表以外，还需要探索数据。一部分数据需求不明确，需要借助数据可视化的工具来探索数据。比如多维度查看指标，查看指标的分布和上卷下钻分析等。这类用户的主力军是一线研发。

下图，可以形象的描述作者用户探索数据的需求。

综合两类用户，用户对数据可视化的核心需求可以总结为“看得到，能下载"。看得到是指可以看到数据，并能支持灵活选择各种图表展示数据。能下载是指用户的提数需求。

围绕“看得到，能下载”核心需求，用户对数据可视化还有一些衍生需求。

2.1 元数据

用户探索数据前，需要了解数据的元数据信息。

2.2 数据血统

用户在可视化系统里看到的数据，通常是经过数据平台加工后的数据。用户有了解该数据是哪些业务数据加工而来的需求。

2.3 指标库

同一个指标，不同角色的人员分析出来的结果可能会出入很大，需要有指标库来统一指标的算法，解决数据口径的问题。

2.4 模型负责人

用户在看数或探索数据时，如果对数据模型存有疑问，需要能很容易找到对应数据模型的负责人，进行咨询。

3. 自研&开源方案

页面定制的开发模式虽然对前端技术要求不高，但要快速支撑大量业务数据需求，需要在前端开发上投入大量研发人力。自研平台化、体系化可视化系统，通过拖拉拽的方式支撑业务数据需求，对前端技术栈又要求非常高，还存在研发周期过长的问题。而业界成熟的开源BI工具，基本可以满足公司用户对数据可视化的需求。基于开发周期，人力成本，技术栈等因素的综合考虑，我们决定采用开源方案解决数据可视化系统的问题。

目前业界成熟开源免费的BI工具有Superset、Redash和Metabase三款，三者对比如下表所示。

对比项	Superset	Metabase	Redash
编程语言	Python	Clojure	Python
github star数	30.6K	22.6K	17.5K
图表类型	多	少	少
透视表	支持	支持	支持
Join查询	不支持	支持	支持
生成图表方式	界面操作	界面操作+SQL	SQL
易用性	一般	非常好	好
界面美观程度	一般	非常好	较好
文档完整性	一般	好	好
数据源	SQLAlchemy	丰富	丰富

其中，在易用性和界面美观程度上Metabase做的最好，我们也最终确定使用Metabase，做平台数据可视化体系中可视化系统。

4. Metabase集成

数据平台集成Metabase，对外发布数据，实现数据可视化。主要分为数据准备和Metabase改进两大部分，以下是我们这两部分所做的主要工作。

4.1 数据准备

4.1.1 离线数据

平台业务数据的需求以T+1离线指标为主。数据平台的离线Hive数仓采用三层架构，核心架构设计如下图所示：

如图所示Hive离线数仓共分为数据运营层、数据仓库层和数据应用层，各层的功能和定位各不相同。

数据运营层，存放的是接入的原始业务数据。

ODS: 数据运营层，数据结构和业务数据几乎一致。

数据仓库层，是仓库核心层，定位于业务视角，提炼出对数据仓库具有共性的数据访问、统计分析需求，从而构建面向业务、支持共享数据访问的中间层数据。

DWD：数据明细层，这一层是关联后的业务过程明细数据，负责各业务场景垂直与水平数据关联、常用公共维度处理等；
DWS：数据服务层，这一层是聚合后的数据，负责按照主题对共性维度指标数据进行轻度或重度聚合；
DIM：维表层，这一层对需要共享的维度进行统一定义；

数据应用层，面向业务领域建立模型，存放的是面向业务定制的应用数据。

数据仓库分层的好处，主要有以下四点。

清晰数据结构：每一个数据分层都有它的作用域和职责，使用表时能更方便地定位和理解；
减少重复开发：规范数据分层，开发一些通用的中间层数据，能够极大的减少重复计算；
统一数据口径：通过数据分层，提供统一的数据出口，统一对外输出的数据口径；
简化问题：将复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤，比较简单和容易理解。当数据出现问题之后，不用修复所有的数据，只需要从有问题的步骤开始修复。

离线数仓，原则上只对外发布数据仓库层和数据应用层，数据运营层不对外发布。

4.1.2 实时数据

实时数据的计算使用Flink实时计算引擎，实时计算的数据源和中间过程数据存放Kafka消息队列里。实时数仓的核心架构如下图所示：

实时明细层，是由实时计算引擎消费业务数据消息队列，通过数据清洗、多数据源关联、流式数据与维表信息匹配等的组合操作而生成。这部分数据再发送到消息队列中，供下层计算使用。

轻度聚合层，与离线数仓的数据服务层不同，这里做轻度聚合，用于前端数据可视化系统复杂的OLAP查询场景，满足数据报表和交互分析的需求;

4.1.3 数据同步

离线计算的结果数据保存在Hive表，Hive表的查询性能无法达到秒级。实时计算聚合后的结果数据保存在Kafka消息队列中，Kafka本身不具备查询能力。总之，结果数据在Hive或Kafka中Metabase无法直接使用。因此需要数据同步功能将结果数据同步到OLAP引擎ClickHouse中。

离线计算结果数据通过Spark任务同步到ClickHouse，由调度系统保证作业间的先后顺序和数据数据一致性。

实时计算的结果数据保存在Kafka的Topic中，在ClickHouse创建一个Kafka引擎表，实时消费结果数据，然后通过物化视图同步插入到MergeTree表中。如下图所示：

上图整个过程是实时进行，数据处理的延迟在秒级以内。

4.1.3 整体数据处理流程

为了方便验证数据，整体数据处理的流程采用Lambda架构，离线和实时数据处理两条线，两条线相互独立没有依赖。整体数据处理流程图如下：

4.2 Metabase改进

4.2.1 Bug修复

解决Metabase连接ClickHouse数据驱动Bug。Metabase官方不支持ClickHouse数据源，连接ClickHouse需要安装社区开发的数据驱动插件。ClickHouse社区数据驱动插件存在按时间维度聚合查询出错的BUG。经过排查发现，数据驱动插件不兼容ClickHouse v20.3以前的版本。升级平台ClickHouse版本得到解决。

Metabase的报表使用API接口生成图片时不支持中文，我们修改了Metabase的源码重新编译，使报表功能支持了中文。

4.2.2 增加对中国地图支持

地图是性能监控大盘最常用的图表之，Metabase地图图表不支持中国地图。通过上传自定义经、纬度数据，我们在Metabase中增加了中国地图。

4.2.3 统一登录

Metabase有独立的用户账号体系，为了不给用户增加记忆用户名密码负担，我们在Metabase中集成新浪统一认证，实现了邮箱账号密码登录使用Metabase。

4.2.4 数据访问权限控制的增强

Metabase本身提供了基本角色的用户数据访问权限控制，功能齐全，可以精确到表级。

但放开让Metabase自身去访问ClickHouse所有数据，对ClickHouse压力太大(Metabase会定期扫ClickHouse全量表，同步元数据，缓存维度度量值等)。出于对ClickHouse保护，我们增加了一层数据访问权限控制，分业务创建ClickHouse用户，业务用户只能访问在ClickHouse中本业务的数据。并且所有ClickHouse业务用户，只能在只读状态下访问数据。