基于 Flink x TiDB，智慧芽打造实时分析新方案

摘要：本文整理自智慧芽数据仓库架构师曲明星在 Flink Forward Asia 2021 实时数仓专场的分享。本篇内容主要分为三个部分：

1. 产品架构

2. 技术架构

3. 未来计划

685-383.jpg

一、产品架构

图片 1.png

上图是智慧芽APP 的产品架构图，包括后台管理系统、AI、内容引擎、帮助中心，为客户提供知识产权信息化服务和科技创新情报系统。

二、技术架构

2.1 原实时分析方案

2.jpg

上图是原来的实时分析方案。流程大致是客户检索一个条件，通过分析 API 把客户检索的相关条件发送到不同的搜索引擎。这种方案会产生 4 个问题：

• 对检索性能产生影响；

• 复杂分析需要开发插件支持；

• 跨多个搜索引擎分析复杂度高；

• 不同维度的数据无法存储。

在建立实时数仓前，收集了业务要求实时数仓特点：

• 秒级响应；

• 准实时数据更新；

• 能支持一定量的并发能力；

• 与搜索引擎数据保持一致；

• 支持复杂分析的能力；

• 支持统一使用方式及主流特性；

• 支持与搜索引擎交互；

• 支持存储容量横向扩展的能力。

3.jpg

上图是数据平台概览。从下往上看：

• 最下层是数据底座，包括数据存储和数据计算，其中数据计算层由 Spark、Kafka、Flink 组成；

• 中间层是数据平台，包括数据开发、数据分类、数据管理和数据服务；

• 上层是数据应用，主要有数据业务、外部分析服务和内部分析业务构成。

2.2 新实时分析方案

4.jpg

新的技术选型主要基于 TiDB，主要包括数据存储、数仓服务两个部分。数仓服务分为安全检查、驱动表管理、缓存管理、集群负载检查以及执行器等部分。

选择 TiDB 是因为它是云原生并且社区活跃、满足 TP 及 AP 业务场景、丰富的生态工具及多平台以及其使用简单，兼容 MySQL 以及大数据能力。

选择 Flink 也是因为它是一个开源的大数据计算引擎，并且有活跃的云原生社区，能够满足对数据的及时性要求，一致性方面有 exactly-once 语义，同时具备低延迟高吞吐量。

5.jpg

在线业务数据写入流程：把源头的数据变更放到消息队列中去，通过索引程序将数据分发到不同的搜索引擎，同时搜索引擎也会给索引程序发送消息。

离线分析技术体系：整个离线分析技术体系比较依赖于 oss。将每日的增量数据离线放到 oss 里，对全量的数据进行一些比较复杂的分析。

离线业务数据写入流程：数据变更会触发持久流化至 oss，oss 同时会和历史流进行合并在 oss 放一份全量数据。

2.3 原用户行为分析方案

原用户行为分析方案是非常复杂的方案，这个方案在前端有 JS 和 Java 的 API，JS 会将用户的埋点数据放置到 Segment 中去，同时有 Gainsight 和 AMPLITUDE 两个合成化引擎。

6.jpg

2.4 新用户行为分析方案

7.jpg

新的用户行为分析方案相对比较简洁。首先收集用户的行为数据，通过 Kinesis 以流的方式接到到 Flink，再进行一些实时指标的计算，并将计算结果存放于不同的表中，给我们提供了可视化的开发。

2.5 Flink + Iceberge 探索

在 Flink + Iceberge 的探索中，将几百 G 左右的表以流的方式放到 Kafka 中，再推送到 oss 中。目前，市面上缺乏成熟的解决方案，所以没有把这个方式应用到生产环境上。

8.jpg

三、未来计划

• 云原生数据库架构迁移；

• 提供更完善的指标和取数系统；

• 建设数据生产的全链路监控和预警；

• 供支撑公司数据消费和服务能力；

• 在线实时分析数仓及其数据处理管道的继续演进；

• 打造云原生数据技术体系和新一代大数据平台；

• 提供数据网关入口，提供统一的数据出口、提高数据应用效率。