實(shí)時(shí) OLAP， 從 0 到 1

• 不能做到實(shí)時(shí)處理數(shù)據(jù)

• 存在單點(diǎn)問(wèn)題，比方某一條鏈路突然掛掉，此時(shí)整個(gè)環(huán)節(jié)都會(huì)出現(xiàn)問(wèn)題

• 效率，效率問(wèn)題是非常常見(jiàn)的。我們的表大概在幾十億量級(jí)，跑這種 SQL ，可能需要很長(zhǎng)時(shí)間， SQL 查詢比較慢，嚴(yán)重影響統(tǒng)計(jì)效率。

• 實(shí)時(shí)，數(shù)據(jù)不是實(shí)時(shí)的，需要等到一定的時(shí)間才會(huì)更新，如昨天的數(shù)據(jù)今天才能看到。

• 監(jiān)控，實(shí)時(shí)需求，如實(shí)時(shí)風(fēng)控，每當(dāng)區(qū)塊鏈出現(xiàn)一個(gè)區(qū)塊，我們就要對(duì)它進(jìn)行分析，但是區(qū)塊出現(xiàn)的時(shí)間是隨機(jī)的。缺乏完整的監(jiān)控，有時(shí)候作業(yè)突然壞了，或者是沒(méi)達(dá)到指標(biāo)，我們不能及時(shí)知道。

• 為什么演進(jìn)這么慢，因?yàn)閰^(qū)塊鏈的發(fā)展還沒(méi)有達(dá)到一定量級(jí)，無(wú)法像某些大公司有上億級(jí)別或者 PB 級(jí)別的數(shù)據(jù)量。我們的數(shù)據(jù)量沒(méi)有那么大，區(qū)塊鏈?zhǔn)且粋€(gè)新鮮的事物，沒(méi)有一定的歷史。另外的問(wèn)題就是資源問(wèn)題，由于人員不足，人員成本上也有所控制。

• 剛才講的架構(gòu)，我們總結(jié)了它適合怎樣的企業(yè)。首先是有一定的數(shù)據(jù)規(guī)模，比說(shuō)某個(gè)企業(yè) MySQL 只有幾千萬(wàn)的數(shù)據(jù)，用 MySQL , Redis , MongoDB 都可以，就不適合這套架構(gòu)。其次是需要一定的成本控制，這一整套成本算下來(lái)比 Spark 那一套會(huì)低很多。要有技術(shù)儲(chǔ)備，要開(kāi)發(fā)了解相關(guān)的東西。

• 區(qū)塊鏈數(shù)據(jù)的特點(diǎn)。數(shù)據(jù)量比較多，歷史數(shù)據(jù)基本上是不變的，實(shí)時(shí)數(shù)據(jù)相對(duì)來(lái)說(shuō)是更有價(jià)值的，數(shù)據(jù)和時(shí)間存在一定的關(guān)聯(lián)。

• 適合的是最好的，不要盲目追求新技術(shù)，比如數(shù)據(jù)湖，雖然好，但是我們的數(shù)據(jù)量級(jí)實(shí)際上用不到。
• 我們不考慮建設(shè)技術(shù)中臺(tái)，我們的公司規(guī)模是中小型，部門溝通起來(lái)比較容易，沒(méi)有太多的隔閡，沒(méi)有發(fā)展到一定的組織規(guī)模，所以我們沒(méi)有打算發(fā)展技術(shù)中臺(tái)，數(shù)據(jù)中臺(tái)，不盲目跟風(fēng)上中臺(tái)。
• 我們達(dá)到的效果是縮短了開(kāi)發(fā)的時(shí)長(zhǎng)，減少作業(yè)的運(yùn)行時(shí)間。

• 自定義 sink 。

• ClickHouse 要一次性插入很多數(shù)據(jù)，需要控制好寫(xiě)入的頻次，優(yōu)先寫(xiě)入本地表，耗時(shí)比較多。

• 我們主要用在智能合約的交易分析，新增的數(shù)據(jù)比較多，比較頻繁，每幾秒就有很多數(shù)據(jù)。數(shù)據(jù)上關(guān)聯(lián)比較多。

• 批量導(dǎo)入時(shí)失敗和容錯(cuò)。

• Upsert 的優(yōu)化。

• 開(kāi)發(fā)了常用 UDF ，大家知道 ClickHouse 官方是不支持 UDF 的嗎？只能通過(guò)打補(bǔ)丁，保證 ClickHouse 不會(huì)掛。

我們也在做一些開(kāi)源方面的跟進(jìn)，做一些補(bǔ)丁方面的嘗試，把我們業(yè)務(wù)上，技術(shù)上常用的 UDF ，集合在一起。

• 歷史數(shù)據(jù)，可以認(rèn)為是一種冷數(shù)據(jù)，相對(duì)來(lái)說(shuō)不會(huì)經(jīng)常改變。導(dǎo)入的時(shí)候按照大小切分，按照主鍵排序，類似于 bitcoind ，底層的 Checker 和 Fixer 工作，導(dǎo)入過(guò)程中及時(shí)進(jìn)行報(bào)警和修復(fù)。比如導(dǎo)入某一數(shù)據(jù)失敗了，如何更好的及時(shí)發(fā)現(xiàn)，之前就只能人肉監(jiān)控。

• 實(shí)時(shí)數(shù)據(jù)，我們需要不斷解析實(shí)時(shí)數(shù)據(jù)，大家可能對(duì)重組，51%的概念不太熟悉，這里簡(jiǎn)單講一下，上圖最長(zhǎng)的鏈也是最重要的鏈，它上面的一條鏈?zhǔn)且粋€(gè)重組并且分叉的一條鏈，當(dāng)有一個(gè)攻擊者或者礦工去挖了上面的鏈，最終的結(jié)果會(huì)導(dǎo)致這條鏈被廢棄掉，拿不到任何獎(jiǎng)勵(lì)。

• 高可用的存儲(chǔ)，在早期的時(shí)候，我們就盡可能的將服務(wù)部署在 Kubernetes，包括 Flink 集群，基礎(chǔ)業(yè)務(wù)組件，幣種節(jié)點(diǎn)，ClickHouse 節(jié)點(diǎn)，在這方面 ClickHouse 做的比較好，方便兼容，支持高可用操作。

• 支持橫向擴(kuò)展。

• 服務(wù)發(fā)現(xiàn)方面，我們做了一些定制。

• 采用 Final 進(jìn)行查詢，等待數(shù)據(jù)合并完成。

• 在數(shù)據(jù)方面的話，實(shí)現(xiàn)冪等性，保證唯一性，通過(guò)主鍵排序，整理出來(lái)一組數(shù)據(jù)，再寫(xiě)入。

• 寫(xiě)入異常時(shí)就及時(shí)修復(fù)和回填，保證最終一致性。

• 擴(kuò)展更多的業(yè)務(wù)和數(shù)據(jù)。之前我們的業(yè)務(wù)模式比較單一，只有數(shù)據(jù)方面的統(tǒng)計(jì)，之后會(huì)挖掘更多信息，包括鏈上追蹤，金融方面的審計(jì)。
  

• 賺更多的錢，盡可能的活下去，我們才能去做更多的事情，去探索更多的盈利模式。

• 跟進(jìn) Flink 和 PyFlink 的生態(tài)，積極參與開(kāi)源的工作，優(yōu)化相關(guān)作業(yè)。探索多 sink 方面的工作，原生 Kubernetes 的實(shí)踐。

• 數(shù)據(jù)建模的規(guī)范，規(guī)定手段，操作。

• Flink 和機(jī)器學(xué)習(xí)相結(jié)合。

• 爭(zhēng)取拿到實(shí)時(shí)在線訓(xùn)練的業(yè)務(wù)，F(xiàn)link 做實(shí)時(shí)監(jiān)控，是非常不錯(cuò)的選擇。大公司都已經(jīng)有相關(guān)的實(shí)踐。包括報(bào)警等操作。