导读：本文将介绍翼支付大数据 BI 分析平台的建设实践。分享主要分为四个部分：
- 翼支付大数据在金融大数据分析的应用
- 翼支付大数据 BI 分析平台架构
- OLAP 引擎技术的实践
- 未来规划
分享嘉宾｜吴晓兵/唐晔 翼支付 大数据开发工程师
编辑整理｜Faye
出品平台｜DataFunSummit
01
翼支付大数据在金融大数据分析的应用
翼支付的数据分析场景主要包括如下四大场景：
- 数据探查：通过 Redash 对外提供服务，Redash 通过 JDBC 接入了 Hive 以及 Presto；Hive 主要是提供临时但比较耗时的提数需求。比如央行需要一个反洗钱数据，或者是事业群需要进行一些账目核对，通过 Hive 进行一个长时间的查询。同时业务侧也可以通过 Hive 进行 ETL 脚本的一个校验；Presto 这边则是用于查询或者是进行一些数据的采样。
- 数据可视化：数据可视化主要是通过 Tableau 以及报表平台对外提供服务；公司内部的数据分析人员会通过 Tableau 制作各类的日报、月报以及看板等。数据分析人员其实没有数仓的架构概念，他们会通过 Presto 查询数仓各层的表。有的时候甚至会基于 ODS 层的表查询，后面我们也引入了 Kylin，数仓通过 Kylin 进行建模，将一些加工好的数据，然后对外提供服务。
- 实时数据的快速查询：风控部门的实时数据查询，单表一般在 200 亿级的规模，数据延迟在 10s 内。查询的响应时间在 5s 以内。
- 离线数据的快速查询：基于离线用户的标签数据，通过任意标签构建一些交并的组合，进行一个人群的预估，以及对用户进行画像分析，响应时间需要在 5s 以内。因此引入了 Clickhouse ，通过 JDBC 的方式对外提供服务。
以上服务架构仍存在一些问题：
- 第一点是通过接 JDBC 或者 ODBC 底层直连引擎，是一种烟囱式的架构。各个平台各自为战，管理和维护也相对混乱。
- 第二点是各个平台的数据查询性能以及稳定性很难得到满足。
- 第三点是数据高度依赖数据分析师，用户整体自助式数据获取的门槛相对来说比较高。
- 第四点是数据权限的管控比较混乱，导致了数据泄露的风险。
- 第五点数据标准执行不到位，数据来源混乱，数据质量的低下，数据的协同以及共享会比较困难。
为了解决以上问题，BI 分析平台伴随着数据治理应运而生。
--
02
翼支付大数据 BI 分析平台架构
这张图展示了我们整个数据中台基础架构以及 BI 分析平台所处的位置。
数据会通过数据开发平台进行入仓，随后数仓会基于 ODS 层的数据进行维度建模。对于统一的维度和指标，会构建相应的维度和指标，进行数据的规范化和标准化管理。元数据平台会对整个数据中台的元数据进行统一的管理、数据血缘的分析，对外提供权限的服务。
我们希望分析平台能够集探查、分析、诊断、报告于一体，在统一的数据标准框架下来满足业务的多样性数据获取以及业务洞察的需求，并且构建完善的数据权限管控体系。
对 OLAP 引擎做整体的封装，目前其实已经是计划接入了 Kylin、Clickhouse、 Presto、Hive 和 Spark，在此之上我们构建统一的查询路由，用户查询分析，并且也通过缓存的管理来加速用户的查询，并对用户的查询进行安全审计。
基于 OLAP 引擎之上，我们会向用户提供数据洞察服务。用户也可以在我们的平台通过拖拉拽的方式去加工报表。生成的报表也可以固化成仪表盘，放在我们的平台，也可以内嵌到其他的业务系统。同时用户也可以基于外部的数据模型进行诊断服务，对一些指标进行归因分析，监测到异常指标的波动。
如果其他的平台想使用我们底层查询引擎的能力，也对外提供了 API 接口。
--
03
OLAP 引擎技术的实践
- 平台侧的权限管控
业务可以通过 JDBC 或者 API 来提交查询 SQL， 经过一个 SQL Parser 模块解析出资源详情，和元数据平台进行权限校验，如果通过，我们则会下发到底层的 OLAP 引擎进行查询。基于这样的方式去做用户 SQL 解析，提供定制化的能力来兼容不同的用户查询 SQL；对于 Presto 开发了一个 Presto 的权限插件，同样也是可以解析出用户所查询的库表列信息；Kylin 还是基于 Kylin 自己的 Project ACL 进行权限的管控。
后续我们也会考虑让 Kylin 可以直接对接我们的元数据平台，做到在元数据平台一处授权，处处都可以使用。
OLAP 引擎监控分为 OLAP 集群监控与告警以及 QUERY 层级监控与分析。
我们目前生产在用的 Clickhouse 版本为 21.8，而在 V21.11 及以前的代码考虑到了子查询的场景，但是它没有考虑到直接写表名的这种情况。不过这个问题在 V21.12 做了修复。
我们在实际生产中碰到一个性能比较严重的问题，就是 Global In 和 Not In 的问题。我们在查询场景中，Global In 里边会带子查询，这个子查询会带有一个 Where 条件。我们发现在生产上它的性能非常慢，甚至出现超时的情况。主要是三个问题导致了这个性能问题。
子查询的表通过 Filter 过后产生了大量的 Block 碎片。这些 Block 碎片的特点就是它有很多 Block，但是每个 Block 只有几行数据。
Clickhouse 的分布式查询，特别是像这种有 Global In 的这种方式，会先在驱动节点把查询中的主表从分布式表 Rename 成对应的 Local 表，然后再把 Rewrite 之后的 Query 发送到 Remote 节点，同时把 Global In/Not In 中的子查询以 External Table 的形式一起发送到 Remote 节点，然后在 Remote 节点去执行。前面所说的 Block 碎片在写入到缓存时，使用的是 Storage Memory 引擎来存储数据，这个引擎的特点是以写入时的 Block 原始形式来存储数据，粒度和写入时保持一致，不会进行碎片合并，所以这导致内存中有大量的 Block 碎片。
发送这个缓存的数据的时候，是按 Block 逐个进行发送的，所以这更加导致它在发送的过程性能非常低，相当于每一次只发几条数据。
知道这个问题的本质之后，我们只需要去添加一个能让 Block 碎片紧凑的功能，也就是借助于 SquashingBlockInputStream，这是 Clickhouse 里面自带的一个 Block Stream，其功能就是把碎片 Block 合并。
- PartialReplacingMergeTree
在精准营销场景中，标签表有 400 多个字段用来存储用户标签，数据量在几亿行。根据用户标签的任意维度，圈选人群。现有的一个架构由数仓层会有几十个标签组的生产任务，会把这些任务推送到 Hbase 里面。如上图所示的为全新的架构，仅加工增量数据，即变动的标签。推送时间在一个小时以内。
这个方案还是一个不可持续的方案。我们决定还是用比较简单直接的办法，扩展一个引擎，基于主键，按照指定的顺序，根据用户指定的字段的 Index 进行部分字段的更新。按照指定的顺序进行覆盖更新，而且可以支持只覆盖某些字段，并且支持删除功能。
ClickHouse 最大的短板在于执行计划及优化器模块。V20.4 以前，处理流程基本没有执行计划及优化器的概念。
从 V20.5 逐步到最新的版本，初步有了执行计划及优化器模块雏形，不过 QueryPlan的优化是基于简单的几条优化规则进行，暂时还是不具备 CBO 特征
- Green Plum
是一个比较经典的 MPP 数据库。SQL 语法进入到解析器，然后再解析成 AST。在 Analyze 阶段，会结合元数据，把抽象语法转成 Query Tree，把这个 Query 转化为逻辑树的概念，其实也就相当于是一个逻辑执行计划。然后做操作的等价变换，比如 Join 表的顺序交换，可以做等价的变换。接下来就是产生统计信息的阶段。再接下来就进入到 App Implementation 阶段，就是实现阶段，会把它的逻辑执行计划转成物理执行计划，再接下来才去应用真正的优化算法去基于这个物理执行计划优化，然后拿到最终的最优的执行计划。
- DuckDB
借助于 Postgre SQL，进行解析，然后生成语法树，Transform 的作用是把 Postgre SQL 抽象成语法树，把它转成 Duck DB 自己的一个 SQL Statement 接下来进入 Bind 阶段。这个 Bind 类似于 Green Plum 的生成 Analyze，这个阶段会结合 Metadata 去生成也是带源数据的语法树。随后这个语法树会被生成一个逻辑执行计划。接下来就是做优化，生成最优的执行计划，再转成物理执行计划。这里它跟 Green Plum 有一点区别，Green Plum 是在生成物理执行计划之后再去做优化的，而 DuckDB 是在逻辑逻辑执行计划的时候去做优化，然后再生成物理执行计划。
ClickHouse 具备性能强悍的算子，配合完善的优化器将更能发挥性能优势，能解决更多问题；对优化器的改造也进一步提升我们对 ClickHouse 的掌控度。
--
04
未来规划
未来规划包括以下几方面：
OLAP 引擎侧的全面原生化，像 ClickHouse 可能他自己有自己的存储，要做原生化可能还需要一些改造，我们规划去做一些尝试。
自助 BI 平台中有抽象层，相当于 SQL 的一个 Gateway 做路由层，对用户屏蔽不同语 SQL 的语法差异。因为我们知道不同的引擎，比如 Kylin、ClickHouse，或是一些其它的引擎，会有一些 SQL 语法差异。我们想在这一层能实现 SQL 语法的统一转换，对用户提供统一的 SQL 接口。
我们会对应 OLAP 不同的查询场景建设基于规则的智能路由引擎，让它能够把用户提交的 SQL，基于一些规则甚至基于一些机器学习模型，路由到最适合的那个引擎。
今天的分享就到这里，谢谢大家。
｜分享嘉宾｜
唐晔
翼支付 大数据开发工程师
9年数据库开发及DBA工作经验，5年大数据相关工作经验，热衷于数据库相关技术，目前专注OLAP引擎底层技术研究。
吴晓兵
翼支付 大数据开发工程师
2019年加入翼支付，已在大数据领域深耕6年，目前专注 OLAP 引擎底层技术研究。
｜DataFun新媒体矩阵｜
｜关于DataFun｜
专注于大数据、人工智能技术应用的分享与交流。发起于2017年，在北京、上海、深圳、杭州等城市举办超过100+线下和100+线上沙龙、论坛及峰会，已邀请超过2000位专家和学者参与分享。其公众号 DataFunTalk 累计生产原创文章800+，百万+阅读，15万+精准粉丝。
上一篇
