国产靠逼网站,日韩日韩日韩日韩AV,国产肏屄视频在线观看,殴美日韩中文在线中,青青草视频在线网站,午夜淫色,国产一级a爱做片免费看,久久综合久色欧美综合狠狠

整理：趙宇彤、苗文婷

摘要：本文主要介紹 BTC.com 團隊在實時 OLAP 方面的技術(shù)演進過程及生產(chǎn)優(yōu)化實踐，內(nèi)容如下：

業(yè)務背景
機遇挑戰(zhàn)
架構(gòu)演進
架構(gòu)優(yōu)化
未來展望

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

一、業(yè)務背景

1.1 業(yè)務介紹 - ABCD

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

1.2 業(yè)務介紹 - 區(qū)塊鏈技術(shù)方案提供商

區(qū)塊鏈通俗來講可以理解為一個不可逆的分布式賬本，我們的作用是讓大家能更好的瀏覽賬本，挖掘賬本背后的信息數(shù)據(jù)。目前比特幣的數(shù)據(jù)量級大概在幾十億到百億，數(shù)據(jù)量大概在數(shù)十T，當然我們也有其他的一些業(yè)務，如以太坊貨幣、智能合約分析服務等。

整體而言我們是一家區(qū)塊鏈技術(shù)方案的提供商，提供挖礦的服務。與金融行業(yè)的銀行一樣，我們也有很多的 OLAP 需求，比如當黑客攻擊交易所或供應鏈進行資產(chǎn)轉(zhuǎn)移或者洗錢時，需要經(jīng)過鏈上的操作，我們可以在鏈上對其進行分析，以及交易上的跟蹤，統(tǒng)計數(shù)據(jù)等，為警方提供協(xié)助。

二、機遇挑戰(zhàn)

2.1 之前的架構(gòu)

大概 2018 年的時候，競爭對手比較少，我們整體的架構(gòu)如上。底層是區(qū)塊鏈的節(jié)點，通過 Parser 不斷的解析到 MySQL ，再從 MySQL 抽取到 Hive 或者 Presto，從 Spark 跑各種定時任務分析數(shù)據(jù)，再通過可視化的查詢，得到報表或者數(shù)據(jù)。架構(gòu)的問題也是顯而易見的：

不能做到實時處理數(shù)據(jù)
存在單點問題，比方某一條鏈路突然掛掉，此時整個環(huán)節(jié)都會出現(xiàn)問題

2.2 遇到的需求與挑戰(zhàn)

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

2.3 技術(shù)選型我們需要考慮什么

在技術(shù)選型的時候我們需要考慮什么呢？首先是縮容，2020年行情不太好，大家都在盡力縮減成本，更好的活下去。在成本有限的情況下，我們?nèi)绾文茏龈嗟臇|西，必須提高自身的效率，同時也要保證質(zhì)量。所以我們需要找到一種平衡，在成本效率還有質(zhì)量這三者之間進行一定的平衡。

三、架構(gòu)演進

3.1 技術(shù)選型

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

我們實際調(diào)研以后，發(fā)現(xiàn) Flink 還是有很多優(yōu)勢，比方說靈活的窗口，精準的語義，低延遲，支持秒級的，實時的數(shù)據(jù)處理。因為團隊本身更熟練 Python ，所以我們當時就選擇了 PyFlink ，有專業(yè)的開發(fā)團隊支撐，近幾個版本變化比較大，實現(xiàn)了很多功能。在實時 OLAP 方面，數(shù)據(jù)庫我們采用了 ClickHouse 。

3.2 為什么使用 ClickHouse

為什么要使用 ClickHouse ？首先是快，查詢的效率高。字節(jié)跳動，騰訊，快手等大公司都在用。同時我們也有 C++方面的技術(shù)積累，使用起來比較容易，成本不是太高。

3.3 實時 OLAP 架構(gòu)

基于以上的技術(shù)選型，我們就形成了上圖的架構(gòu)，底層是數(shù)據(jù)源，包括區(qū)塊鏈的節(jié)點，通過 Parser 解析到 Kafka，Kafka 負責對接 Flink 和 Spark 任務，然后 Flink 把數(shù)據(jù)輸出到 MySQL 和 ClickHouse，支持報表導出，數(shù)據(jù)統(tǒng)計，數(shù)據(jù)同步，OLAP 統(tǒng)計等。

數(shù)據(jù)治理方面，我們參考了業(yè)界的分層，分成了原始層、明細層、匯總層以及應用層。我們還有機器學習的任務，這些都部署在 K8s 平臺之上。

3.4 架構(gòu)演進歷程

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

3.5 架構(gòu)演進思考

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

3.6 實時 OLAP 產(chǎn)生的價值

在實時 OLAP 上線后，基本滿足了業(yè)務需求，同時成本也在可控的范圍內(nèi)。

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

四、架構(gòu)優(yōu)化

4.1 Flink 和 ClickHouse

Flink 和 ClickHouse 之間有一些聯(lián)動，我們自定義了三個工作。

自定義 sink 。
ClickHouse 要一次性插入很多數(shù)據(jù)，需要控制好寫入的頻次，優(yōu)先寫入本地表，耗時比較多。
我們主要用在智能合約的交易分析，新增的數(shù)據(jù)比較多，比較頻繁，每幾秒就有很多數(shù)據(jù)。數(shù)據(jù)上關(guān)聯(lián)比較多。

4.2 ClickHouse 遇到的問題

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

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

4.3 批量導入策略

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

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

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

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

4.4 Upsert 的優(yōu)化

ClickHouse 不支持 Upsert ，主要在 SDK 方面做兼容，之前是直接往 MySQL 寫數(shù)據(jù)，目標是通過 SQL 語句修改對應的 SDK 增加臨時小表的 join ，通過 join 臨時小表，進行 Upsert 的操作。

舉個例子，區(qū)塊鏈地址賬戶余額，就像銀行的賬戶余額，必須非常精確。

4.5 Kubernetes 方面優(yōu)化

Kubernetes 方面的優(yōu)化。Kubernetes 是一個很完整的平臺。

高可用的存儲，在早期的時候，我們就盡可能的將服務部署在 Kubernetes，包括 Flink 集群，基礎(chǔ)業(yè)務組件，幣種節(jié)點，ClickHouse 節(jié)點，在這方面 ClickHouse 做的比較好，方便兼容，支持高可用操作。
支持橫向擴展。
服務發(fā)現(xiàn)方面，我們做了一些定制。

4.6 如何保證一致性？

采用 Final 進行查詢，等待數(shù)據(jù)合并完成。
在數(shù)據(jù)方面的話，實現(xiàn)冪等性，保證唯一性，通過主鍵排序，整理出來一組數(shù)據(jù)，再寫入。
寫入異常時就及時修復和回填，保證最終一致性。

4.7 監(jiān)控

使用 Prometheus 作為監(jiān)控工具。使用方便，成本較低。

五、未來展望

5.1 從 1 到 2

擴展更多的業(yè)務和數(shù)據(jù)。之前我們的業(yè)務模式比較單一，只有數(shù)據(jù)方面的統(tǒng)計，之后會挖掘更多信息，包括鏈上追蹤，金融方面的審計。
賺更多的錢，盡可能的活下去，我們才能去做更多的事情，去探索更多的盈利模式。
跟進 Flink 和 PyFlink 的生態(tài)，積極參與開源的工作，優(yōu)化相關(guān)作業(yè)。探索多 sink 方面的工作，原生 Kubernetes 的實踐。

5.2 從 2 到 3

數(shù)據(jù)建模的規(guī)范，規(guī)定手段，操作。
Flink 和機器學習相結(jié)合。
爭取拿到實時在線訓練的業(yè)務，F(xiàn)link 做實時監(jiān)控，是非常不錯的選擇。大公司都已經(jīng)有相關(guān)的實踐。包括報警等操作。

總的來說的話，路漫漫其修遠兮，使用 Flink 真不錯。更多 Flink 相關(guān)技術(shù)交流，可掃碼加入社區(qū)釘釘大群～

▼ 關(guān)注「Flink 中文社區(qū)」，獲取更多技術(shù)干貨 ▼

戳我，回顧作者分享視頻！

實時 OLAP， 從 0 到 1

實時 OLAP，從 0 到 1