货拉拉云台系统架构设计

5,506 阅读12分钟

一、货拉拉云台是什么

货拉拉云台是货拉拉内部自研BI(Business Intelligence(商业智能),简称:BI)可视化平台。

截至2022年12月,货拉拉业务范围已覆盖352座中国内地城市,月活司机达66万,月活用户达950万,随着公司业务不断扩张,对数据分析和数据价值转化的需求愈加明显,原先提供的数据分析平台在一定程度上已经无法满足业务的多样化需求,且无法直接与公司现有的权限管理系统、业务应用系统打通,更存在一定的数据权限管控和数据泄露风险,此时打造自研BI平台的迫切性越来越强,货拉拉云台便应运而生。

二、货拉拉云台系统架构介绍

其实“商业智能”(BI)一词最早出现在1865年,当时理查德·米勒·德文斯(Richard Millar Devens)在《商业趣闻百科全书》(Cyclopaediaof Commercial and Business Anecdotes)中用它来描述银行家亨利·福尼斯爵士(HenryFurnese)通过收集并利用数据信息,先于竞争对手采取行动,从而达到获利的目标。时至今日,BI经过了历史沉淀,被我们重新定义为:利用技术手段或方法,将数据转化为知识,用以支撑企业决策、发掘商业价值的一套解决方案。以数据为中心,BI的核心功能主要有 数据仓库 、数据ETL、数据分析、数据挖掘和 数据可视化

跟业务信息化对各个业务系统不同业务之间的用户数据处理不同的是,数据信息化是跨业务、跨系统之间的数据分析洞察与整体指标产出,它能够反向推动业务智能化建设,提高决策科学度,所以往往更依赖框架、模型和算力,而这也决定了企业数据信息化的高度。随着自然语言处理、人工智能、湖仓一体等技术的发展,已经有人提出了AI+BI的概念,Databricks(由 Apache Spark 创建者成立的大数据处理平台公司)也认为同时支持 BI 和 ML 的数据平台基础设施才是数据分析的未来。未来的BI只需要你对着计算机说出问题,即可获得答案。但是从“目前”和“国内”来说,真正地实现商业“智能”还是有很遥远的距离。

接下来我们看一下货拉拉大数据体系架构,简单划分如下:

基础层、平台层:通过数据仓库,算力平台等基础设施(包括数据接入,运算引擎和治理开发等)为公司提供数据存储、数据处理、数据开发等能力。

服务层、应用层:主要偏向数据价值挖掘类平台,充分利用基础层和平台层的能力,实现公司数据资产价值最大化。

除此之外,货拉拉大数据体系中还建立了数据安全防护体系,如:数据权限管控系统、数据安全审计、数据加密脱敏等。

可以看到整个云台可视化分析是数据与用户最直接的一个连接之一,在大数据业务体系中起到一个承上启下的作用。以数据为中心,向上直接对业务用户负责,向下依赖数据仓库、数据ETL、数据分析、数据挖掘等。

云台 系统的设计目标:让用户在几分钟内就能制作出专业的场景化的数据报表。

使用流程:添加数据源 → 创建数据模型(模型配置&自定义SQL分析)→ 可视化报表制作(报表制作&仪表盘制作)→ 发布(多业务系统共享&报表权限管控)

报表制作过程中使用了可视化开源组件Apach Echarts,用户仅需要通过拖拽图表组件以及数据字段就能非常容易地制作出一个报表。

对接多种数据源:

在数据源层面,云台可以对接的数据源主要以内部自用类型为主,比如MYSQL、PostgreSQL,Phoenix、Doris、Hive等,也可以支持Excel/CSV数据文件的上传,同时对接了公司内部系统快速报表、指标库,对公司内部数据源用户无需知道具体的账号密码也可以连接使用。

数据模型:

前边我们介绍到用户创建数据模型有两种方式,分别是模型配置和编写自定义SQL,模型配置对非技术人员比较友好,云台已抹平不同数据源查询语句之间的差异,可以做到零代码,用户不需要懂SQL语句的书写,通过拖拽的方式即可创建一个数据集和报表。自定义SQL的方式,除了一些必要的限制,用户可以非常灵活的创建数据模型。

报表制作:

在报表制作工作台,也就是制作报表的主要编辑页,目前支持14种图表类型,如指标卡、漏斗图、交叉表、散点图、堆叠图等。

用户可以使用拖拽维度和度量字段的方式进行数据绑定、全界面化的添加和修改图表组件,还可以进行自定义排序、合计、分组、topN、同环比分析等操作,简单灵活易用。

仪表盘制作:

在仪表盘界面,用户使用拖拽式选取一些已经编辑好的图表和过滤组件,即可生成交互式的可视化页面实现自助分析。

完成的报表支持数据下载,且通过发布后可以与大数据数据安全管控系统对接,实现报表权限的统一管理,对一些敏感数据要求比较高的用户比较友好,还可以共享到多个业务系统。

三、货拉拉云台可视化技术设计

数据源连接:

市面上可视化平台大多有个通病,就是数据源连接一般都需要填用户名和密码,因为很多商业智能BI工具考虑更多的是通用化,这点对业务用户来说其实不太好,因为数据源的用户名和密码只有技术开发才知道,用户每次使用都要向开发拿,其中沟通成本和数据安全无法避免。

作为内部自研系统,就能很容易地避免这种情况,用户甚至都不需要知道数据源连接串、密码等,仅知道所需数据在哪个库哪张表即可,这样也方便针对用户进行权限控制,而不是创建很多连接账号。

数据模型:

前面架构介绍也有提到,借鉴了业界可视化平台,云台也可以通过模型配置和写SQL的方式,创建数据模型,包括多表Join,通过拖拽的方式将SQL语句查询的结果绑定到可视化图表上。

数据模型会根据查询的字段属性自动生成维度和度量,自动识别字段类型,比如整数、小数、字符串、日期,其中数值类型默认识别为度量,用户也可以自行调整维度或者度量以及字段类型、字段备注等,度量可以进行常规的聚合操作,其中包括Sum、Count、Avg、Max、Min,去重计数等,维度和度量均可以编辑字段表达式对字段进行复制(Copy)、删除(Delete)和转换(Transform)等函数操作。对具体的使用字段,我们也提供了列级和行级的权限管控。

查询的灵活多样性:

可视化平台的查询需要非常灵活且多样化,比如SQL的Where查询,数据需要层层过滤,数据的格式转换,比如小数位/百分比,日期时间的年/月/日聚合计算,维度的分组,维度和度量的排序、图表与图表之间的下钻/联动,过滤器之间的联动等。

云台交互式的数据过滤目前主要分为单个图表的过滤和仪表盘的全局过滤两种,单个图表的过滤比较简单,就是数据模型的单一维度Set集合。而仪表盘的全局过滤就相对比较复杂了,每个筛选器之间都可能存在联动关系。

比如a联动bcd、a+b联动c,a+c联动d,仅仅这3种过滤联动关系,乍一看估计不太容易理解,但举个例子就非清晰了:假设a是大区、b是省份、c是城市、d是区域,那么广东省对应华南,a+b联动c就是华南区/广东省下所有的城市,a+c联动d实际上就是a+b+c联动d,那么d就等于华南区/广东省/深圳市下的所有区域。

当然除了数据的筛选和过滤器之间的联动以外,还有图表之间的联动、下钻。例如点击图表里的中山市,想让下边的某一个组件展现中山市的具体数据。而下钻有点类似多层级过滤器,这些都是过滤器之间的灵活交互使用。

数据计算:

用户具体可以做的计算操作包括:字段表达式转换、日期时间聚合计算、维度分组、合计、TopN等,这些最终都会转为SQL语句在数据库层面计算结果。

还有一种是基于SQL的查询结果,在内存中进行二次计算。比如交叉表,单次SQL请求得不到最终结果,需要在内存中进行二次计算。

性能优化:

页面查询依赖底层数据库引擎,比如查询Hive我们使用了Presto,性能方面就有了很大的提升,还有Doris、ClickHouse、ElasticSearch等。除了查询引擎,系统层面也有很多地方可以优化,比如以下几点:

  1. 源数据缓存 由于可视化平台的特殊性,除了报表的最终数据结果以外,整个报表制作过程中用户其实不太关注所有数据,所以只需对其中一部分数据查询即可,到了真正展示报表的时候才显示全部数据。比如一个日期维度的报表,在拖拽编辑时显示1个月的数据,而不是1年,这样对制作报表体验比较好,查询也比较快,云台这里主要使用了H2
  2. SQL查询结果缓存:利用了Redis缓存了SQL执行结果,可以达到较好的性能效果
  3. 筛选器下拉选项值的缓存:下拉选项值一般都变化较少,持久化到数据库,定时更新,对查询性能有很大帮助
  4. 连接池遇到并发高:当连接数打满且慢查询比较多时,新建连接池处理新请求,保证不影响新进来的查询,但需注意别超过数据库max_user_connections
  5. 交叉透视表的查询:由于行排序后前n条数据是固定的,那就可以把当前页行的结果作为查询条件,去查询匹配小的部分数据,这样性能提升比较大
  6. 中断大数据量查询:使用google concurrent SimpleTimeLimiter中断查询时间过长的线程,这种非常耗CPU和内存
  7. 异步多线程:比如异步下载数据

四、结语以及下一步规划

本文主要从开发人员的角度介绍了货拉拉云台可视化产品的架构设计思路。作为一个自研的可视化平台,云台在货拉拉仍处于内部孵化阶段,存在很多不足之处,比如有些数据源查询速度不够快、操作流程太繁琐、提示不够友好等等。但随着接入系统的增加以及用户量增长,我们会努力完善系统功能、优化用户体验,保证系统稳定,力争让云台成为企业降本增效的利器。

技术层面的下一步规划,大概有两点:

  1. 系统稳定性治理:系统稳定性压倒一切。老子曾说,“治大国若烹小鲜”,治理系统也类似,要掌握火候,精选食材,用料恰当,辅以煎炒烹炸煮,方能出一盘好菜。我们知道系统稳定性治理除了代码健壮性,主要有3个方面:监控告警、压测和演练,下一步计划会聚焦在系统代码的健壮性建设和监控告警降级等。
  2. 代码设计整合:随着系统功能越来越丰富,代码设计方面很难做到十全十美,性能与可读性之间往往是选择题,如何在多个选择之间权衡取舍,并不是一件简单的事情。所幸有一些这方面的书籍可供参考,比如《代码整洁之道》《设计模式》等。

笔者介绍:黄书劲 | 高级大数据工程师,曾就职于腾讯全资子公司,现任职于货拉拉大数据应用组,主要负责数据云台、实时分析等平台的开发设计以及维护工作。在大数据应用建设方面有着丰富的实战经验和较强的问题解决能力。