作者｜高正炎
本文主要介紹 BTC.com 團隊在實時 OLAP 方面的技術演進過程及生産優化實踐，内容如下：
- 業務背景
- 機遇挑戰
- 架構演進
- 架構優化
- 未來展望
一、業務背景
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 的優化
ClickHouse 不支援 Upsert ，主要在 SDK 方面做相容，之前是直接往 MySQL 寫資料，目标是通過 SQL 語句修改對應的 SDK 增加臨時小表的 join ，通過 join 臨時小表，進行 Upsert 的操作。
舉個例子，區塊鍊位址賬戶餘額，就像銀行的賬戶餘額，必須非常精确。
4.5 Kubernetes 方面優化
Kubernetes 方面的優化。Kubernetes 是一個很完整的平台。
- 高可用的存儲，在早期的時候，我們就盡可能的将服務部署在 Kubernetes，包括 Flink 叢集，基礎業務元件，币種節點，ClickHouse 節點，在這方面 ClickHouse 做的比較好，友善相容，支援高可用操作。
- 支援橫向擴充。
- 服務發現方面，我們做了一些定制。
4.6 如何保證一緻性？
- 采用 Final 進行查詢，等待資料合并完成。
- 在資料方面的話，實作幂等性，保證唯一性，通過主鍵排序，整理出來一組資料，再寫入。
- 寫入異常時就及時修複和回填，保證最終一緻性。
4.7 監控
使用 Prometheus 作為監控工具。使用友善，成本較低。
五、未來展望
5.1 從 1 到 2
- 擴充更多的業務和資料。之前我們的業務模式比較單一，隻有資料方面的統計，之後會挖掘更多資訊，包括鍊上追蹤，金融方面的審計。
- 賺更多的錢，盡可能的活下去，我們才能去做更多的事情，去探索更多的盈利模式。
- 跟進 Flink 和 PyFlink 的生态，積極參與開源的工作，優化相關作業。探索多 sink 方面的工作，原生 Kubernetes 的實踐。
5.2 從 2 到 3
- 資料模組化的規範，規定手段，操作。
- Flink 和機器學習相結合。
- 争取拿到實時線上訓練的業務，Flink 做實時監控，是非常不錯的選擇。大公司都已經有相關的實踐。包括報警等操作。
總的來說的話，路漫漫其修遠兮，使用 Flink 真不錯。更多 Flink 相關技術交流，可掃碼加入社群釘釘大群～
活動推薦：
僅需99元即可體驗阿裡雲基于 Apache Flink 建構的企業級産品-實時計算 Flink 版！點選下方連結了解活動詳情：
https://www.aliyun.com/product/bigdata/sc?utm_content=g_1000250506