## 一、引言 ### 1.1 什麼是MySQL Shell ? MySQL Shell 是 MySQL 的一個高級客戶端和代碼編輯器,是第二代 MySQL 客戶端。第一代 MySQL 客戶端即我們常用的 MySQL 。除了提供類似於 MySQL 的 SQL 功能外,MySQL Shell 還提供 ...
Flink是一款非常優秀的流式計算框架,而ClickHouse是一款非常優秀的OLAP類引擎,它們是各自所處領域的佼佼者,這一點是毋庸置疑的。Flink除了各種流式計算場景外也必然可以用於流式統計,ClickHouse同樣也可以用於流式統計,但我不認為它們是優秀的流式統計工具。XL-Lighthouse在流式統計這個細分場景內足以完勝Flink和ClickHouse。在企業數據化運營領域,面對繁雜的流式數據統計需求,以Flink和ClickHouse以及很多同類技術方案為核心的架構設計不能算是一種較為優秀的解決方案。
一、從流式統計的特點說起
1、 流式統計是流式計算中的一種特殊運算形式
一個Flink任務只能並行處理一個或少數幾個數據流,而XL-LightHouse一個任務可以並行處理數萬個、幾十萬個數據流;一個Flink任務只能實現一個或少數幾個數據指標,而XL-LightHouse單個任務就能支撐大批量、數以萬計的數據指標。
流式計算是一個很寬泛的概念,目前沒有辦法用特定的某些運算操作類型將其抽象出來。流式計算是基於事件流驅動的運算方式,常見的應用場景有:計算用戶實時畫像、實時推薦、監控告警、實時電信反詐騙等等。正是因為目前流式計算沒有辦法通過某些運算操作類型將其抽象,所以只能從“流式數據處理過程”這種寬泛的視角來解決此類問題。因此我們可以看到不管是Flink還是Spark,都有類似數據源(Source)、轉化操作(Map)、執行操作(Action)、視窗(Window)、結果處理(Sink)這類概念,因為這些概念都是圍繞著“流式數據處理過程”而衍生出來的。當然Flink的工程師為了擴充其適用場景、提高產品的完善度,提供了類似狀態管理、水印、聚合函數等等功能,但也都不可能脫離流式數據處理過程的主線。
而反觀流式統計雖然是屬於流式計算的一種計算形式,但它其實是一種完全可以被抽象成幾種運算操作類型的計算形式。絕大多數的流式統計無外乎Count運算、Sum運算、Bitcount運算(count distinct)、Max運算、Min運算、Avg運算、Seq運算(時序數據)、Dimens運算(維度劃分)、Limit運算(topN/lastN),然後再結合時間視窗(滾動視窗、滑動視窗)的劃分就可以完成一個個的流式數據統計需求。任何一類業務需求只要可以被抽象成若幹種運算操作類型,那就一定可以為此類業務需求設計出一種與其適配的通用化解決方案。這個過程就像Photoshop將所有圖片處理的操作抽象出移動工具、鋼筆工具、圈選工具、裁剪工具、橡皮擦工具等,關係型資料庫將所有數據相關操作抽象出增加、刪除、修改、查詢、事務、索引等過程類似。而很顯然Flink、Spark面對流式計算場景,自身都沒有基於這種“功能抽象”的概念來實現。
正因為Flink、Spark在流式處理方面都是基於寬泛的流數據處理過程所設計,所以流式計算的實現並不是一種“通用化”解決方案。每個Flink任務只能並行處理一個或少數幾個數據流,而視窗則對應與之相應的數據流。這種設計如果從流式計算的角度來看並無問題,但如果從流式統計這個細分領域的角度來看卻明顯先天不足。從某種程度上來說Flink和Spark由於其自身定位,它們的這種設計方案只能將流式計算中的非流式統計任務的執行效率發揮到極致,而遠遠不可能將流式統計的效率發揮到極致。所以我一直認為:Flink和Spark稱得上是優秀的流式計算工具,但根本不能算是優秀的流式統計工具。流式統計是一種可以被抽象的計算形式,所以必然能夠為其設計出一套通用型且性能遠遠超過Flink和Spark的技術方案。這個原因就好比是專用的水果刀用來削蘋果要比功能繁雜的瑞士軍刀好用一樣。
而XL-LightHouse作為適配流式統計的技術方案,它不再是圍繞著“流數據處理過程”這條主線,而是圍繞著“運算操作類型”來實現,這種設計更加貼合流式統計的運算特點,徹底打破了流式計算的束縛,也正因為如此,XL-LightHouse一個任務就可以同時並行處理十幾萬條、數十萬條的數據流,每個數據流本身的運算過程中不再有視窗的概念,而XL-LightHouse單個任務就能夠支撐大批量、數以萬計的數據指標,這種優勢是Flink和Spark刻板的使用流式計算的方式去解決流式統計的問題之類方案永遠都無法比擬的。
XL-LightHouse每個統計項配置包括了其計算規則、維度信息和統計周期等元素,在系統接收到統計消息後,系統將原始消息按照統計項標識、運算函數類型、維度信息和統計周期劃分成一個個的運算元。這些運算元分屬於眾多的統計指標,它們之間彼此獨立,但卻可以同時並行運行在一個進程當中,這種模式已然完全不同於Flink任務和Spark任務這種流數據彼此之間處於資源隔離的運算形式,大大提高了集群資源的利用效率。
XL-LightHouse雖然目前是基於Structured Streaming實現,也會按視窗批次來處理消息,但這個視窗跟Flink任務中的視窗已有本質區別,這裡的視窗是相對於大批量的數據指標彙總的數據流整體來說的,更多的只是作為事件觸發的功能而已。而Flink和Spark在處理流式統計任務時依舊刻板的按照流式計算的形式為每個統計指標所對應的數據流單獨來劃分視窗,執行聚合數據等操作,不同的統計指標需要單獨啟動不同的Job來實現,任務彼此間資源隔離,這嚴重製約了流式統計的運行效率。很多時候無關乎技術,一個軟體本身的定位就已經決定了它在某個領域所能企及的上限。軟體自身或許並無優劣,而只是側重點不同而已。在流式統計這個細分領域,面對企業繁雜的流式數據統計需求,XL-LightHouse的運算性能瞬間就可以秒殺Flink和Spark之類的解決方案。
2、 流式統計應用場景廣泛,應該擁有與其市場價值匹配的通用型解決方案。
一類業務需求即便是能夠被抽象成若幹種運算操作類型,也要同時考慮是否有將其適配成一種通用型解決方案的必要。如果應用場景較少、市場價值有限,將其適配成一種通用型解決方案是完全沒有必要的,然而流式統計明顯不是這一類。
流式統計應用場景廣泛,隨著企業數據化運營理念的不斷滲透,企業對數據指標的需求越來越多,粒度越來越細,幾乎可以遍佈企業運轉的方方面面,這是科技發展的必然趨勢。
隨著流式統計技術的日益普及,它將在所有流式計算需求中占有越來越高的比例。由於流式計算中的非流式統計問題和流式統計問題從運算特點的角度來看具有顯著差異,所以應該被分開應對,刻板的按照流式計算的固有模式去解決流式統計的問題是一種低效的表現。
當前大數據領域所恪守的SQL規範由於其自身的瓶頸已經制約流式統計的快速普及和大規模應用,而只要打破這種桎梏,流式統計或將迎來井噴式增長。XL-LightHouse依據流式統計的計算特點,為流式統計量身打造的自定義配置規範(XL-Formula),用於描述形式各樣的流式統計運算方式,在該領域使用遠比SQL規範要簡潔高效的多。
在軟體研發領域,我認為通用型流式統計將會對現在的軟體類產品研發產生較為巨大的影響,它會發展成為如同日誌一樣的重要角色,通用型流式統計或將成為獨立於日誌之外且重要程度不亞於日誌的另一套輔助類工具體系,各種工種的程式員將會在任何有必要的地方加上流式統計的代碼就像加日誌一樣司空見慣、習以為常。
在企業級服務市場,我認為通用型流式數據統計將憑藉其龐大的應用場景和巨大的業務價值而成為企業最核心的基礎服務之一,而以通用型流式數據統計為核心理念、以其他技術方案為輔助手段的數據化運營類產品將成為企業級B端市場不可或缺的中堅力量。
二、Flink用於流式統計存在哪些問題
如上所述,Flink是針對流式計算領域中各類運算場景相對寬泛的解決方案,而對比XL-LightHouse,Flink在應對流式統計問題方面存在著以下問題:
1、資源利用率低
Flink的資源利用率低要從兩個角度來看,一個是集群運行的拓撲結構,另一個是Flink任務執行的特性。
從集群運行的拓撲結構來看,Flink一個Job只能處理一個或少數幾個統計指標,每個Job都需要單獨向集群申請運算資源,不同Job的運行處於資源隔離的狀態。那這個過程至少存在幾個方面的資源浪費:
-
每個Job除了運算必須的資源外,還需要維持一定比例的“空閑資源”,空閑資源是為了保障在流量上漲時程式的穩定運行。由於Flink一個任務只能實現少量的數據指標,而大批量的數據指標需要依靠大量的Job來實現,而這些Job的空閑資源的疊加是相當大的一筆浪費。
-
流式統計任務大多處於長期運行的狀態,而諸如Flink和Spark之類的解決方案,一個流式統計任務即便一天只有零星幾條的消息數據也依然要為其分配額定的運算資源,反觀XL-LightHouse,系統中的所有統計指標沒有資源隔離的束縛,系統的資源分配是按照整體運行狀況進行分配的,對於沒有消息數據的統計指標則絲毫不必占用任何運算資源。
-
對於有明顯波峰和波谷的統計需求來說,Flink任務需要為波峰時段分配較高的運算資源,而這些運算資源在波谷時段基本處於閑置狀態(雖然像Flink/Spark以及Yarn這種任務管理平臺不斷地優化資源利用率,提供動態的擴容和縮容功能,但其實實際效果並不明顯)。
-
實現不同的統計任務需要研發人員在Flink集群開發並提交相應的計算任務,而如果研發人員資源參數配置不當,也將造成的較大的資源浪費。
-
很多Flink任務需要依據數據量、數據傾斜狀況、統計周期粒度等因素進行特定的優化,而很多研發人員對相應優化未必有充沛的時間和相關經驗,這就導致低效任務運行間接浪費了大量運算資源。
而從Flink任務執行的特性來看,不管是基於FlinkSQL還是它基礎的API,比如keyBy、WindowProcess、aggregate等函數,這些函數處理的過程都是採用將數據轉移到某個特定分區統一處理,這個過程除了會導致數據傾斜之外,也必然產生大量的運算資源浪費。
我舉一個可能不是非常嚴謹的例子來說明:一個Flink任務並行度為5,每個運算進程的數據量假設為1G,那正常來說只需要給它分配5G的記憶體就足夠了。而如果在指標統計時需要使用keyBy之類的函數,程式則必然發生數據傾斜。我們假設任務發生了最嚴重的數據傾斜,那每個進程我們至少要給它分配5G的資源才能防止出現記憶體溢出的狀況,也就是說實際上這個任務運行耗費了25G的記憶體。而相比較XL-LightHouse依據流式統計的運算特點,採用完全規避shuffle,將中間態數據和結果數據均放在外部存儲中,不同運算節點之間互不影響,所以完全不會出現數據傾斜的狀況。
目前業內針對集群資源利用率的觀測,大都是基於操作系統層面的記憶體和CPU參數,但這種觀測其實並不能發現更深層次的資源浪費問題。大數據集群的資源浪費問題遠比很多朋友想象中要嚴重的多得多。而相比之下XL-LightHouse自身設計更能將集群算力發揮到極致。
2、運算性能低
我們總能看到很多文章在渲染Flink運算性能的優勢,當然這是沒有問題的。Flink作為一個業內優秀的流式計算引擎,確實在性能方面技藝精湛且已經達到了相當高的程度。但是作為一個流式統計工具,與XL-LightHouse相比的話,它的表現其實乏善可陳。
Flink受限於自身的定位,依舊刻板的選擇流式計算那一套臃腫笨重的計算方式來實現流式統計,而它針對流式統計各種運算單元的優化也只能在其現有的運行機制體系下有限的範圍內進行。
它的一個Job只能同時處理一兩個或很少量的數據流,數據消費邏輯只能機械的依賴視窗時間和水印時間執行,它所有的設計方案出發點只能從流式計算各類場景綜合角度去考慮,而不可能只從貼合流式統計的角度去考慮,它也不可能引入更加高效、但較重的方案來實現各種流式統計函數,它的執行邏輯不可能規避shuffle,也不可能規避數據傾斜。所以受限於自身定位,Flink和Spark都不能算是優秀的流式統計工具,將來也不可能成為優秀的流式統計工具。
3、接入成本較高
雖然各種大數據平臺越來越多,研發人員可以提交Flink Jar任務和FlinkSQL任務,而不少互聯網大中型企業在堅定的朝著這個方向努力。
在所有Flink任務當中有較大比例的任務只是進行流式統計,隨著企業數據化運營理念的不斷推進,使用流式統計的業務需求數量會越來越多,占比會越來越高。
而對比XL-LightHouse一行代碼的接入方式來說,Flink的接入成本太高了,體現在幾個方面:
(1)、Flink面向專業的大數據研發人員,大量統計指標的實現需要耗費大量的研發成本。
(2)、由於Flink自身在流式統計領域的基礎功能並不完善,所以很多場景下都需要研發人員依據統計任務的數據量、統計周期的粒度、數據傾斜狀況等因素進行特定的優化。所以使用Flink實現很多相類似的功能,由於數據量差異、統計周期的不同,程式的實現方式也可能截然不同。
4、運維成本高、運算資源成本高
對比XL-LightHouse,Flink的運維成本更高,體現在幾個方面:
(1)、實現相同的流式統計需求,Flink集群規模要明顯大於XL-LightHouse的集群規模,導致運維成本增加。
(2)、由於Flink集群面向專業的研發人員,Flink集群的運轉是由集群維護人員和Flink任務的研發人員共同參與,如果集群要進行版本升級、集群擴容、日常維護、數據遷移等操作均需要與研發人員事先溝通、達成默契,很多類似版本升級的操作會涉及相關任務的升級改造。如果集群規模龐大、涉及研發人員、相關任務較多的話,那這個過程也必然會耗費了較大的維護成本。
三、ClickHouse用於流式統計存在哪些問題
ClickHouse是OLAP類引擎,其實與XL-LightHouse是有著本質不同的,應用的場景也不相同。
-
ClickHouse適用場景的特點
(1)單個或較少數量的應用場景,且每個應用場景都有海量的數據;
(2)業務場景有大量的維度欄位,可能需要按照十幾個甚至幾十個以上的維度隨意組合進行多維度即席查詢操作;
(3)業務場景有明細查詢的需求;
(4)不同數據源之間可能有join查詢的需求; -
ClickHouse的缺點
(1)由於每次查詢都需要遍歷海量數據,所以併發度支持有限;
(2)由於系統記憶體儲著海量的明細數據,集群規模龐大、結構複雜,維護成本高昂;
(3)每次查詢都要遍曆數據,進行實時統計運算,需要耗費的大量的記憶體和CPU資源;
(4)數據接入需要進行各種層面的優化,使用門檻較高、面向專業的大數據研發人員使用;
(5)接入成本高、維護成本高、伺服器成本高,使用門檻高,對中小企業不太友好;
四、XL-LightHouse的優勢
XL-LightHouse是一套通用型流式大數據統計平臺,致力於推動流式統計的快速普及和大規模應用,定位是以一套服務使用較少的伺服器資源同時支撐數以萬計、數十萬計流式數據統計需求的大數據平臺。XL-LightHouse面向企業自上而下所有職能人員共同使用,倡導以通用型流式數據統計技術為切入點,傾向於選擇輕巧的技術方案幫助企業以更低的成本,更快速的搭建起一套猶如我們人體神經系統一樣遍佈全身的、較為完善、穩定可靠的數據化運營體系。
XL-LightHouse拋棄了Flink和Spark這種基於流數據處理過程的實現方案,打破了流式計算的束縛,採用“多流並行處理”的計算模型更加貼合流式統計運算特性。拋棄SQL語言這種臃腫笨重的業內標準,自定義更加簡潔高效,符合流式統計運算特點的配置規範。XL-LightHouse一個任務可並行處理數十萬個數據流,單個任務就可以支撐大批量的數據指標。XL-LightHouse儘可能避免資源浪費,充分發揮集群的運算能力,並對流式統計的各種運算單元進行反覆優化以提高數據的處理能力。
XL-LightHouse適用場景及優缺點:
- 面向企業繁雜的流式數據統計需求,一套系統可以在超短的時間內快速實現成千上萬個數據指標,指標體系可以遍佈企業運轉的方方面面;
- 對單個流式統計場景的數據量無限制,既可以非常龐大,也可以非常稀少。您既可以使用它完成十億級用戶量APP的DAU統計、十幾萬台伺服器的運維監控、一線互聯網大廠數據量級的日誌統計、也可以用它來統計一天只有零星幾次的介面調用量、耗時狀況;
- 流式統計時間視窗最大範圍是1天,所以不支持月活躍用戶數之類的長統計周期指標;
- 可以支持高併發查詢統計結果;
- 不支持明細查詢,如果想要支持明細查詢需要藉助於其他工具實現;
- 由於不存儲明細數據,只存儲統計結果,所以相對於ClickHouse之類的OLAP引擎來說維護的總數據量級要少得多,運維成本低;
- 一鍵部署、一行代碼接入,普通工程人員就可以輕鬆駕馭。
- 有完善的Web端功能,提供數據指標可視化、數據指標的許可權管理等功能;
- 接入成本低、維護成本低、伺服器成本低,使用門檻低,對中小企業友好;