實時 OLAP，從 0 到 1-有解無憂

整理：趙宇彤、苗文婷

摘要：本文主要介紹 BTC.com 團隊在實時 OLAP 方面的技術演程序序及生產優化實踐，內容如下：

業務背景
機遇挑戰
架構演進
架構優化
未來展望

Tips：點擊文末「閱讀原文」即可回顧作者原版分享視頻～

一、業務背景

1.1 業務介紹 - ABCD

BTC.com 是一家區塊鏈技術方案提供者，我們的業務主要分為四個部分，總結來說就是 ABCD：A 是人工智能機器學習，B 是區塊鏈，C 代表云，D 是資料，這些模塊不僅相互獨立的，也可以互相結合，近幾年人工智能、區塊鏈的加速發展與大資料在背后提供的支持息息相關，

1.2 業務介紹 - 區塊鏈技術方案提供商

區塊鏈通俗來講可以理解為一個不可逆的分布式賬本，我們的作用是讓大家能更好的瀏覽賬本，挖掘賬本背后的資訊資料，目前位元幣的資料量級大概在幾十億到百億，資料量大概在數十T，當然我們也有其他的一些業務，如以太坊貨幣、智能合約分析服務等，

整體而言我們是一家區塊鏈技術方案的提供商，提供挖礦的服務，與金融行業的銀行一樣，我們也有很多的 OLAP 需求，比如當黑客攻擊交易所或供應鏈進行資產轉移或者洗錢時，需要經過鏈上的操作，我們可以在鏈上對其進行分析，以及交易上的跟蹤，統計資料等，為警方提供協助，

二、機遇挑戰

2.1 之前的架構

大概 2018 年的時候，競爭對手比較少，我們整體的架構如上，底層是區塊鏈的節點，通過 Parser 不斷的決議到 MySQL ，再從 MySQL 抽取到 Hive 或者 Presto，從 Spark 跑各種定時任務分析資料，再通過可視化的查詢，得到報表或者資料，架構的問題也是顯而易見的：

不能做到實時處理資料
存在單點問題，比方某一條鏈路突然掛掉，此時整個環節都會出現問題

2.2 遇到的需求與挑戰

效率，效率問題是非常常見的，我們的表大概在幾十億量級，跑這種 SQL ，可能需要很長時間， SQL 查詢比較慢，嚴重影響統計效率，
實時，資料不是實時的，需要等到一定的時間才會更新，如昨天的資料今天才能看到，
監控，實時需求，如實時風控，每當區塊鏈出現一個區塊，我們就要對它進行分析，但是區塊出現的時間是隨機的，缺乏完整的監控，有時候作業突然壞了，或者是沒達到指標，我們不能及時知道，

2.3 技術選型我們需要考慮什么

在技術選型的時候我們需要考慮什么呢？首先是縮容，2020年行情不太好，大家都在盡力縮減成本，更好的活下去，在成本有限的情況下，我們如何能做更多的東西，必須提高自身的效率，同時也要保證質量，所以我們需要找到一種平衡，在成本效率還有質量這三者之間進行一定的平衡，

三、架構演進

3.1 技術選型

俗話說，工具選的好，下班下的早，關于是否引入 Flink，我們想了很久，它和 Spark 相比優勢在哪里？

我們實際調研以后，發現 Flink 還是有很多優勢，比方說靈活的視窗，精準的語意，低延遲，支持秒級的，實時的資料處理，因為團隊本身更熟練 Python ，所以我們當時就選擇了 PyFlink ，有專業的開發團隊支撐，近幾個版本變化比較大，實作了很多功能，在實時 OLAP 方面，資料庫我們采用了 ClickHouse ，

3.2 為什么使用 ClickHouse

為什么要使用 ClickHouse ？首先是快，查詢的效率高，位元組跳動，騰訊，快手等大公司都在用，同時我們也有 C++方面的技識訓累，使用起來比較容易，成本不是太高，

3.3 實時 OLAP 架構

基于以上的技術選型，我們就形成了上圖的架構，底層是資料源，包括區塊鏈的節點，通過 Parser 決議到 Kafka，Kafka 負責對接 Flink 和 Spark 任務，然后 Flink 把資料輸出到 MySQL 和 ClickHouse，支持報表匯出，資料統計，資料同步，OLAP 統計等，

資料治理方面，我們參考了業界的分層，分成了原始層、明細層、匯總層以及應用層，我們還有機器學習的任務，這些都部署在 K8s 平臺之上，

3.4 架構演進歷程

我們的架構演程序序如下圖，從 2018 年的 Spark 和 Hive ，到后來的 Tableau 可視化，今年接觸了 Flink ，下半年開始使用 ClickHouse ，后來 Flink 任務比較多了，我們開發了簡易的調度平臺，開發者只需要上傳任務，就會定時或者實時的跑任務，

3.5 架構演進思考

為什么演進這么慢，因為區塊鏈的發展還沒有達到一定量級，無法像某些大公司有上億級別或者 PB 級別的資料量，我們的資料量沒有那么大，區塊鏈是一個新鮮的事物，沒有一定的歷史，另外的問題就是資源問題，由于人員不足，人員成本上也有所控制，
剛才講的架構，我們總結了它適合怎樣的企業，首先是有一定的資料規模，比說某個企業 MySQL 只有幾千萬的資料，用 MySQL , Redis , MongoDB 都可以，就不適合這套架構，其次是需要一定的成本控制，這一整套成本算下來比 Spark 那一套會低很多，要有技術儲備，要開發了解相關的東西，
區塊鏈資料的特點，資料量比較多，歷史資料基本上是不變的，實時資料相對來說是更有價值的，資料和時間存在一定的關聯，

3.6 實時 OLAP 產生的價值

在實時 OLAP 上線后，基本滿足了業務需求，同時成本也在可控的范圍內，

適合的是最好的，不要盲目追求新技術，比如資料湖，雖然好，但是我們的資料量級實際上用不到，
我們不考慮建設技術中臺，我們的公司規模是中小型，部門溝通起來比較容易，沒有太多的隔閡，沒有發展到一定的組織規模，所以我們沒有打算發展技術中臺，資料中臺，不盲目跟風上中臺，
我們達到的效果是縮短了開發的時長，減少作業的運行時間，

四、架構優化

4.1 Flink 和 ClickHouse

Flink 和 ClickHouse 之間有一些聯動，我們自定義了三個作業，

自定義 sink ，
ClickHouse 要一次性插入很多資料，需要控制好寫入的頻次，優先寫入本地表，耗時比較多，
我們主要用在智能合約的交易分析，新增的資料比較多，比較頻繁，每幾秒就有很多資料，資料上關聯比較多，

4.2 ClickHouse 遇到的問題

批量匯入時失敗和容錯，
Upsert 的優化，
開發了常用 UDF ，大家知道 ClickHouse 官方是不支持 UDF 的嗎？只能通過打補丁，保證 ClickHouse 不會掛，

我們也在做一些開源方面的跟進，做一些補丁方面的嘗試，把我們業務上，技術上常用的 UDF ，集合在一起，

4.3 批量匯入策略

歷史資料，可以認為是一種冷資料，相對來說不會經常改變，匯入的時候按照大小切分，按照主鍵排序，類似于 bitcoind ，底層的 Checker 和 Fixer 作業，匯入程序中及時進行報警和修復，比如匯入某一資料失敗了，如何更好的及時發現，之前就只能人肉監控，

實時資料，我們需要不斷決議實時資料，大家可能對重組，51%的概念不太熟悉，這里簡單講一下，上圖最長的鏈也是最重要的鏈，它上面的一條鏈是一個重組并且分叉的一條鏈，當有一個攻擊者或者礦工去挖了上面的鏈，最終的結果會導致這條鏈被廢棄掉，拿不到任何獎勵，

如果超過51%的算力，就會達到這樣的效果，成為最長的鏈，這個是累計難度比較高的，此時我們會認為資料匯入失敗，同時我們會利用回撤的功能，不斷將其回滾和重組，直到滿足最完整的鏈，當然我們也會設定一些記錄和 CheckPoint ，這里的 CheckPoint 和 Flink 的 CheckPoint 的概念也有所區別，

它是區塊鏈方面的 CheckPoint ，區塊鏈有一個幣種叫 bch ，會定義 CheckPoint，當滿足一定的長度時，它就無法再進行回滾，避免了攻擊者的攻擊，我們主要是利用 CheckPoint 記錄資訊，防止回滾，同時還會按照級別/表記錄批量插入的失敗或者成功，如果失敗則會進行重試，以及報警回滾等操作，

4.4 Upsert 的優化