共计 7083 个字符，预计需要花费 18 分钟才能阅读完成。
导读：在大数据智能时代，数据分析的价值越来越重要，而数据分析可视化平台的能力要求也越来越高。本文从百度数据中心的数据可视化平台登程，介绍了配置化的数据可视化平台的利用价值，并对数据可视化平台的整体解决架构进行了拆解。基于可配置的数据可视化平台，能够高效反对简单的数据分析场景，晋升剖析效率，强化数据的价值。
全文 6999 字，预计浏览工夫 13 分钟。
一、背景与指标
1.1 背景剖析
在数据智能时代，BI（Business Intelligence，商业智能）曾经是古代数据经营的根底能力。以数据撑持业务，一方面须要咱们基于数据仓库建设业务相干的全面、权威、稳固的根底数据，另一方面也须要咱们建设数据分析的能力，通过图表对数据进行展现，从而进步数据展现的信息密度，而后辅以各种比照形式，让数据业务化、升华数据意义，赋能业务增长。
因而一个数据可视化平台的搭建就变得尤为重要，但因为简单业务之间的差别使得平台的设计及开发过程难度大且简单。思考到人群、业务的剖析习惯与业务各异的分析方法，数据可视化平台在报表的出现、数据的计算、数据的公布效率等方面都面临着重大的挑战。
1.2 问题与指标
以一个典型的广告商业化案例举例，客户基于投放目标抉择不同的广告商业产品模式（如微博热搜榜单，百度的搜寻置顶，各类视频网站的趣味举荐等等），哪些模式能促成客户更好的触达用户；客户提供的款式（如视频、图片、内容等物料个性）让浏览内容的用户产生什么样的偏差等问题，都须要数据做撑持进行剖析。联合分析师、看板用户的习惯和泛滥剖析场景构建数据可视化平台生成数据报表时会呈现以下问题：
1. 长期报表独立开发导致局部能力反复建设、反复开发；
2. 每个报表独立开发使得用户须要习惯多种款式、格调导致的体验差别；
3. 业务呈现变动时调整、匹配老本较大，导致一段时间内无奈无效赋能业务；
4. 平台计算能力有余导致的构建数据报表的工夫、人力老本较大；
5. 平台稳定性保障难度高，需测试、排查层出不穷的异样。
为了可能满足用户的报表需要，即便投入大量的人力也仅能解决上述开发成本带来的问题。系统化的打造 BI 与数据之间的桥梁，须要深刻到数据表白的各个环节，联合业务的个性，模块化、组件化各项能力，这样既能缩小反复开发的老本，同时也能进步代码复用、可扩展性、报表治理以及容错等各方面的能力，保障用户的应用体验及业务适配性。
因而，一个优良的数据可视化平台应满足以下几点：
1. 麻利：可能疾速响应需要；
2. 精确：可能保障平台数据的准确性，做到「所见即所得，所得皆所用」；
3. 多元：面向不同的业务属性、用户个性，例如比照计算、查问等形式可能通过模块组合、展示类型调整等形式满足需要；
4. 灵便：对于业务拓展或者变更，平台可能灵便变动以贴近业务的构造；
5. 简略易用：用户无论是在读、写数据，均能疾速满足；反对业务过程以「配置」取代「开发」；
6. 易拓展：笼罩大部分业务剖析场景，同时反对基于配置的二次开发前后端代码，易于扩大。
1.3 名词解释
1. 衍生指标：
基于根底指标，利用公式二次计算出来的指标，常见的例如以最近 10 天用户数计算出来的均匀用户数，或利用当天用户数量比照昨日用户数量计算出来的日环比等。
2. 下钻：
个别指业务须要通过拆分、细化来开掘或定位业务痛点，业务之间存在肯定的关联性，透过关联逐层的拆解在剖析时称之为下钻。在可视化场景中罕用树状构造表白相似的层级关系。
3. 上卷：
在可视化场景中指多个业务数据形成一个总数时，通过零碎利用业务间的关联性进行共计计算。
4. 维度剖析：
常见的基线比照形式，以一项或多项业务为基准，通过数值比照剖析以后业务情况。
5. 工夫比照剖析：
将工夫进行分段解决后，比照以后时间段与历史（或基线）时间段之间的数值变动，从而判断业务情况。
二、整体设计与思路
2.1 需要剖析与构思
2.1.1 场景剖析
一个残缺的数据分析闭环从剖析需要开始，蕴含了数据采集、数据荡涤、数据建模、数据出现、数据利用、论断输入，利用产出的论断落地或晋升业务。整个环节咱们能够看到两种角色：
1. 建设者：
进行剖析一个命题或业务场景时，首先基于业务寻找数据撑持，在此过程中须要采集数据、将数据整顿成具备业务含意的表达方式、提取出具备业务关联性的内容造成具备剖析意义的汇合，用更直观、形象的形式将数据进行展现等几局部工作。其次为了能更充沛的表白业务，过程中须要将一些数据进行组合构建成衍生指标或者建设维度之间的分割。这些工作实现后，一个残缺的业务场景会通过数字化、图像化的形式展现进去。
2. 剖析者：
针对业务的状况，透过数据开始剥离问题，以一个 APP 某商业化场景支出降落为例，分析师须要从 APP 的用户数开始逐层漏斗查看哪些环节导致的影响较大，也须要从各个维度进行下钻剖析定位业务根结，还有可能利用类比剖析、基线比照的形式横向比拟类似场景下影响的差别。
面对雷同的业务问题，不同方向的数据使用者可能也会有不同的行为，对业务了解的动向，剖析的数据层级等也会有所不同。当然，用户也能够同时承当这两种角色，实质上简略易用的平台更便于剖析型用户独立实现数据建设到剖析的闭环，从而缩小并开释人力，更快的解决业务问题。在以后数据无奈满足业务剖析时，剖析者又会进入到建设型场景，持续寻找量化撑持所需的数据论据。
2.1.2 业务形象与思考
实现多种业务场景的数据反对，须要技术为之创造条件，如果说建设者最终服务于剖析者，以报表后果为导向，建设者是否能够在建设过程中充沛表白剖析者的数据需要呢？这些报表建设能力转嫁或拆解成程序化、模块化语言到底是什么？平台配合建设者自身须要实现哪些工作、实现什么样的性能呢？同时，平台该如何保障为剖析者提供精确、高效、全面的数据呢？接下来咱们通过对数据的可视化过程拆解、形象对上述问题一一解答。
2.2 架构设计
2.2.1 过程形象
咱们将剖析者应用数据的全过程进行拆解，而后进行抽象化、组件化。剖析者通过平台输出查问条件、指标、维度等等，服务端依据平台输出进行数据 sql 的组装并查询数据库，而后计算相干衍生指标整合计算结果，最终依照相应的款式出现后果。整个逻辑过程拆解如图 1 所示。
△图 1 过程形象逻辑
2.2.2 整体架构
依据数据可视化的过程形象可知，一个残缺的可视化平台须要包含数据获取、数据计算、数据出现等几局部。数据如何获取、如何展现则须要进行对立配置管理，数据如何疾速、精确的计算则由通用计算服务负责。同时可视化平台还须要保证数据的品质问题，在数据存在问题或者提早时可能及时告诉建设者去解决数据问题，这些则由运维看板负责。咱们通过对数据可视化过程形象和对此类平台的经验总结，将数据可视化平台架构拆解成如图 2 所示。
△图 2 整体架构图
三、外围模块介绍
3.1 配置工具与报表出现
在未进行配置化以前，建设一个报表须要后端开发人员基于数据库开发计算逻辑、剖析、下载等性能，前端开发人员则基于数据以图表的模式进行渲染，代码冗余、开发成本高、周期长。对立配置工具是在数据库与报表出现之间搭建起来的一座桥梁，数据建设者在相熟数据逻辑的根底上通过配置工具的配置界面进行数据源、计算逻辑、出现内容、款式等相干信息的配置，而后将其公布上线, 各数据可视化平台的报表出现模块依据配置的款式和内容渲染相应的组件，用户即可在对应的平台查看报表、剖析或者下载数据。
△图 3 配置流程示意图
3.1.1 对立配置工具
为了缩小配置工具应用的复杂程度、升高用户学习老本，进步配置效率，针对业务以及数据需要绝对稳固的剖析场景设计固定的出现模板，用户抉择适合的模板配置相应的内容，且配置模板具备可扩展性，可灵便增删功能模块。
△图 4 对立配置工具组成
配置工具页面依据用户抉择的模板展现相应的配置内容，除了配置数据源、指标、维度等数据相干信息，还须要配置筛选控件、剖析组件等内容。同时配置工具还反对通过扩大配置减少以后模板不反对的性能，从而基于模板进行二次开发。一个残缺的配置工具除了根本的配置，还减少了指标治理、维度治理、配置校验等性能进步配置效率和用户体验的根底反对。
1. 指标治理：将指标、衍生指标的信息进行对立的治理，依据指标的属性特色提供各参数的默认值，配置人员在配置页面时能够间接应用指标治理模块的默认配置信息，实现了指标的一次配置屡次应用。这不仅进步了配置人员的配置效率，提供指标参数默认值也有利于标准对立平台格调；
2. 维度治理：依据数据源配置信息，生成维度模板信息，配置人员只须要简略调整维度显示名称和程序即可，不便高效；
3. 配置校验：校验用户配置的 sql 是否正确，疾速定位谬误配置。
3.1.2 报表出现
数据可视化平台为用户提供丰盛的图表组件（表格、趋势图、饼图、卡片、地图等等）和过滤条件（单选、多选、日期、输入框等等），丰盛的图表款式充沛满足简单的可视化需要。
△图 5 报表出现的架构
报表出现这部分的次要工作是将格式化后的数据以图表的模式渲染在浏览器中，供用户查问、剖析数据。报表出现的根底组件单元分为两类：
1. 管制组件 ：配置工具里配置的组件，比方筛选条件、日期类型等，这类组件在渲染组件时同时渲染组件内容；
2. 数据组件：须要渲染的具体数据，比方表格、折线图中的数据，这部分的数据是由通用计算模块来提供的。这类组件在渲染组件后，从新获取具体数据信息（数据起源不同）进行内容渲染。
为了满足简单的剖析场景，在报表出现时往往是多个款式组合在一起应用。在进行设计时综合思考代码的可复用性、通用性以及可扩展性将图表拆解成能够重复使用的最小单元，封装成组件。各组件最终如何组合排列出现则由建设者依据须要的剖析场景在配置工具里进行配置管理。
△图 6 报表出现的组成
针对业务以及数据需要绝对稳固的剖析场景报表出现共设计实现了 14 种出现模板，反对交互式查问、TOP 排序、实时数据等业务场景的配置。对于更简单的业务场景可能复用根底组件、开发上线。
△图 7 配置模板
3.2 通用计算服务
后面局部介绍了配置工具服务于计算和报表出现，报表出现图表的数据来源于计算服务。计算服务是整个数据可视化平台的大脑，次要负责将数据库中的原始数据依据不同的计算规定解决并生成用户须要的数据模式进行展现。不同的用户剖析数据的维度、视角、场景存在差别，例如：在 Top 场景下，剖析重点维度（如客户、产品等）数据的变化趋势；有的须要监控固定指标的稳定，依据不同的筛选条件，穿插剖析引起变动的起因、预测将来倒退的方向；有的须要长时间范畴的数据来剖析指标随工夫的变化规律；对于重点业务须要实时查看数据变动等等。计算服务除了要笼罩已知且简单的业务场景，还须要思考业务的一直扩大和对数据的深挖，疾速跟进业务的倒退，所以计算服务架构在设计时要充分考虑通用性和可扩展性。
3.2.1 架构实现
综合业务场景复杂性、代码复用性、服务通用性和可扩展性各方面的考量，咱们对通用计算服务架构做了分层设计，每层各司其职，标准整体代码构造、逻辑清晰易读且可能疾速反对新指标计算的扩大。
△图 8 计算整体服务架构
1. 参数校验层
对于不同业务场景的数据申请，计算服务所要求的参数不尽相同，咱们将参数校验局部独立进去，形象出独特的参数校验逻辑，对于各模板独有的参数进行独立校验。
2. 模板服务散发层
为了满足不同的业务场景和数据展现需要，咱们设置了模板服务散发层，依照业务场景进行分类，形象出多个服务类服务于不同的数据场景。散发层依据用户在配置工具配置的信息为后续计算筹备数据源、指标、维度等信息而后同计算申请一起散发到具体的服务类。
3. 多维合成层
为了反对数据上卷、下钻的数据分析维度之间的关系，咱们设计了多维合成层，依据数据的层级合成出多个并行计算过程。多线程并行计算使得不同层级计算互不烦扰、高效计算。
4. 数据获取层
为了可能反对多种类型的数据库且易于后续新增其余类型数据库，咱们形象了数据获取层，屏蔽下层数据获取逻辑、提供对立接口。底层数据库能够反对 mysql、palo、xdb 等，也能不便、疾速的扩大反对新的数据库类型。
5. 分层计算层
由多维合成层拆解进去的多个计算过程，每个计算过程是独立的模块，在数据获取层提供的原始数据根底上并行计算周同、日环、七天均值等衍生指标，满足剖析者多角度剖析场景。衍生指标独自计算、互不影响，易扩大且不影响计算效率。最初依据提早看板（该局部后边具体介绍）提供的数据提早、屏蔽信息，将计算结果进行屏蔽解决，避免平台出现异样数据。
△图 9 分层运算层
6. 格式化层
格式化层次要负责依据不同出现组件进行格式化，将数据处理操作放在服务端进行，前端拿来即用缩小前端性能耗费，进步前端数据出现和渲染效率。同时，格式化层屏蔽了底层计算逻辑，使得通用计算服务可能疾速接入新的报表出现平台，为其提供计算能力。
3.3 运维看板
数据可视化平台的外围是数据，平台底层保护了大量的数据流，这些数据来源于不同的上游，原始数据通过多层的数据抽取、加工、汇总，生成最终的前端表。在整个过程中可能呈现各种问题，比方多数据源先后到位导致页面数据展现不全，上游数据异样、数据荡涤过程中产生异样等。为了保证数据的准确性，在通用计算服务局部提到了须要对异样数据进行屏蔽解决，其屏蔽信息来源于运维看板。
△图 10 运维看板组成
运维看板监控数据到位状况、测验数据准确性，保障数据的失常产出，为整个平台数据的准确性和权威性保驾护航。其外围性能是数据提早监控、数据品质校验、平台布告治理。整体的工作流程如下：
1. 调度零碎负责所有 ETL 工作的调起和状态流转，在 ETL 工作运行实现后，通过音讯队列告诉到看板数据产出；
2. 看板调起数据校验服务执行校验工作，并将后果回传到看板；
3. 看板更新报表数据产出状态，依据校验规定校验数据稳定是否超阈值，而后将数据到位状况、校验后果通过音讯队列散发到对应的报表平台；
4. 各报表平台依据接管到的音讯，从新计算数据更新数据缓存。
△图 11 基于音讯核心的运维看板工作流程
3.3.1 数据提早监控
为了保障例行化的数据工作在 SLA 工夫内产出，提早监控模块依据报表的 ETL 工作、SLA 工夫信息对数据到位状况进行监控、报警。数据到位时提早监控模块第一工夫将音讯散发到各平台，保证数据缓存及时更新。对于多数据源的报表，提早监控反对配置数据全副到位或局部到位出现规定，看板基于配置规定进行数据屏蔽治理同时生成相应布告提醒报表平台用户数据到位状况。如果数据在 SLA 工夫内未产出则会告诉报表负责人及时跟进数据运行状况。
为了不便监控报表产出状况，看板同时提供了界面化的数据产出监控界面，报表负责人通过界面查看、统计数据产出状况、ETL 工作状态等。
△图 12 数据产出监控界面
3.3.2 数据品质校验
为保证数据的准确性和权威性，数据到位后运维看板会在平台数据出现之前对数据进行品质校验，依据校验规定生成屏蔽信息，通过音讯队列散发到各报表平台。当校验的数据异样时通过短信、电话、邮件等多种报警形式告知报表负责人，揭示跟进数据异样情况。
数据校验规定目前设计实现了三种类型：
1. 前端表校验：反对同环比、大小阈值等校验规定，在前端表数据到位后进行校验。
2. 数据源校验：反对同环比、大小阈值等校验规定，从上游拉取到数据后执行校验规定。
3. 自定义脚本扩大，反对用户自定义校验规定，提供 openapi 接口屏蔽数据。
3.3.3 屏蔽和布告治理
除了数据提早监控和数据品质校验可能屏蔽数据，运维看板还提供间接屏蔽数据性能，防止因为其余问题造成的异样数据出现给用户。当数据异样或非凡事件造成数据稳定较大时，布告治理模块上线布告告知用户数据稳定起因。
四、总结
基于模板配置的数据可视化平台由对立配置工具、通用计算服务、报表出现、运维看板等几局部组成。对立配置工具负责管理报表如何获取数据、以哪些图表款式出现报表；通用机算服务提供衍生指标（日环、周同、七天均值、QTD、MTD 等等），比照剖析，数据上卷、下钻等计算能力；运维看板提供提早监控、品质校验、屏蔽治理等性能保证数据的准确性、时效性；报表出现提供丰盛的图表组件（表格、趋势图、饼图、地图等等）和过滤条件（单选、多选、日期、输入框等等）满足简单的可视化需要。多种配置模板贴合业务需要，以配置取代开发疾速响应需要，同时易于扩大的架构可能灵便跟进业务变更或拓展。简略来说咱们的平台：
1. 相比自助 BI，辅助性能更弱小、数据品质有保障
借助组件化弱小的能力，咱们在放弃页面高自由度、灵便反对业务的同时，也构建了多种辅助比照的能力帮忙剖析者实现剖析。通过一个残缺的报表页面，能有零碎的剖析思路，也能取得多元的自助能力，强化了对业务的认知。其次缩小了用户对数据的相信问题，将异样数据前置治理，通过数据提早监控、数据品质校验、屏蔽、布告等一系列伎俩保证数据的准确性，防止剖析者对数据品质的质疑，做到「所见即所得，所得皆所用」。
2. 相比传统 BI，更疾速、高效
前文讲到，定制化的开发最大的毛病是开发效率工夫长、老本高，影响数据输入和剖析。咱们将计算能力、展现能力组件化、配置化，丰盛的衍生指标计算能力、出现组件使其尽量贴近定制化平台能力。即使是平台不反对的新业务场景这些高可用的开发组件也能参加到其剖析场景的搭建过程中。基于模板配置的数据可视化平台可能疾速响应业务需要、撑持剖析业务能力、为业务赋能。
举荐浏览
如何正确的评测视频画质
小程序启动性能优化实际
咱们是如何穿过低代码“⽆⼈区”的：amis 与爱速搭中的要害设计
挪动端异构运算技术 -GPU OpenCL 编程（根底篇）
云原生赋能开发测试
基于 Saga 的分布式事务调度落地