基於 Flink x TiDB，智慧芽打造實時分析新方案

摘要：本文整理自智慧芽數據倉庫架構師曲明星在 Flink Forward Asia 2021 實時數倉專場的分享。本篇內容主要分爲三個部分：

1. 產品架構

2. 技術架構

3. 未來計劃

01 產品架構

上圖是智慧芽 APP 的產品架構圖，包括後臺管理系統、AI、內容引擎、幫助中心，爲客戶提供知識產權信息化服務和科技創新情報系統。

02 技術架構

2.1 原實時分析方案

上圖是原來的實時分析方案。流程大致是客戶檢索一個條件，通過分析 API 把客戶檢索的相關條件發送到不同的搜索引擎。這種方案會產生 4 個問題：

• 對檢索性能產生影響；

• 複雜分析需要開發插件支持；

• 跨多個搜索引擎分析複雜度高；

• 不同維度的數據無法存儲。

在建立實時數倉前，收集了業務要求實時數倉特點：

• 秒級響應；

• 準實時數據更新；

• 能支持一定量的併發能力；

• 與搜索引擎數據保持一致；

• 支持複雜分析的能力；

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

• 支持與搜索引擎交互；

• 支持存儲容量橫向擴展的能力。

上圖是數據平臺概覽。從下往上看：

• 最下層是數據底座，包括數據存儲和數據計算，其中數據計算層由 Spark、Kafka、Flink 組成；

• 中間層是數據平臺，包括數據開發、數據分類、數據管理和數據服務；

• 上層是數據應用，主要有數據業務、外部分析服務和內部分析業務構成。

2.2 新實時分析方案

新的技術選型主要基於 TiDB，主要包括數據存儲、數倉服務兩個部分。數倉服務分爲安全檢查、驅動表管理、緩存管理、集羣負載檢查以及執行器等部分。

選擇 TiDB 是因爲它是雲原生並且社區活躍、滿足 TP 及 AP 業務場景、豐富的生態工具及多平臺以及其使用簡單，兼容 MySQL 以及大數據能力。

選擇 Flink 也是因爲它是一個開源的大數據計算引擎，並且有活躍的雲原生社區，能夠滿足對數據的及時性要求，一致性方面有 exactly-once 語義，同時具備低延遲高吞吐量。

在線業務數據寫入流程：把源頭的數據變更放到消息隊列中去，通過索引程序將數據分發到不同的搜索引擎，同時搜索引擎也會給索引程序發送消息。

離線分析技術體系：整個離線分析技術體系比較依賴於 oss。將每日的增量數據離線放到 oss 裏，對全量的數據進行一些比較複雜的分析。

離線業務數據寫入流程：數據變更會觸發持久流化至 oss，oss 同時會和歷史流進行合併在 oss 放一份全量數據。

2.3 原用戶行爲分析方案

原用戶行爲分析方案是非常複雜的方案，這個方案在前端有 JS 和 Java 的 API，JS 會將用戶的埋點數據放置到 Segment 中去，同時有 Gainsight 和 AMPLITUDE 兩個合成化引擎。

2.4 新用戶行爲分析方案

新的用戶行爲分析方案相對比較簡潔。首先收集用戶的行爲數據，通過 Kinesis 以流的方式接到到 Flink，再進行一些實時指標的計算，並將計算結果存放於不同的表中，給我們提供了可視化的開發。

2.5 Flink + Iceberge 探索

在 Flink + Iceberge 的探索中，將幾百 G 左右的表以流的方式放到 Kafka 中，再推送到 oss 中。目前，市面上缺乏成熟的解決方案，所以沒有把這個方式應用到生產環境上。

03 未來計劃

• 雲原生數據庫架構遷移；

• 提供更完善的指標和取數系統；

• 建設數據生產的全鏈路監控和預警；

• 供支撐公司數據消費和服務能力；

• 在線實時分析數倉及其數據處理管道的繼續演進；

• 打造雲原生數據技術體系和新一代大數據平臺；

• 提供數據網關入口，提供統一的數據出口、提高數據應用效率。

公司簡介：Patsnap 是一家科技創新情報 SaaS 服務商。通過機器學習、計算機視覺、自然語言處理（NLP）等人工智能技術爲全球領先的科技公司、高校和科研機構、金融機構等提供大數據情報服務。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/m6gkTqsAm0esyEL0XKurNA