XL-LightHouse是針對互聯網領域繁雜的數據統計需求而開發的一套集成了數據寫入、數據運算、數據存儲和數據可視化等一系列功能，支持大數據量，支持高並發的【通用型流式大數據統計平台】。
-
XL-LightHouse目前已基本涵蓋了常見的流式數據統計場景，包括count、sum、max、min、avg、bitcount、topN/lastN等多種運算，支持多維度計算，支持分鐘級、小時級、天級多個時間粒度的統計，支持自定義統計週期的配置。
-
XL-LightHouse內置豐富的轉化類函數、支持表達式解析，可以滿足各種複雜的條件篩选和邏輯判斷。
-
XL-LightHouse是一套功能完備的流式大數據統計領域的數據治理解決方案，它提供了比較友好和完善的可視化查詢功能，並對外提供API查詢接口，此外還包括數據指標管理、權限管理、統計限流等多種功能。
-
XL-LightHouse支持時序性數據的存儲和查詢。
背景
以互聯網行業來說，在移動互聯網發展比較成熟的現在，流量見頂，紅利消失，企業競爭日趨慘烈，獲取新增用戶的成本日益增高。很多企業開始意識到不能一味的通過補貼、價格戰、廣告投放這種簡單粗暴的方式搶占市場，這樣的運作模式很難長時間維繫。而通過精細化和數據化運營來降低成本、提升效率、最大化單用戶價值的理念逐漸被越來越多的企業所接受。精細化和數據化運營的前提是要建立起一套完善的數據指標體系，借助這個數據指標體系企業可以有多方面的用途:
-
1、排查問題：數據化運營是讓企業業務進入到一種”可控”的狀態，幫助企業在業務運轉不正常的時候，能夠快速的判斷出問題所在。
-
2、業務洞察：數據化運營是讓業務運轉的各個環節更加透明，幫助企業更清晰的看到目前的”短板”是在什麼地方，輔助產品的優化迭代。
-
3、明確方向：數據化運營是培養敏銳的嗅覺，讓企業可以更加準確的判斷出市場的走勢、捕捉到其中具有業務價值的信息。
-
4、科學試錯：在試錯成本日益高企的今天，數據化運營是幫助企業改變以往靠”拍腦袋”來做決定的方式，打破過往的經驗主義，輔助決策者思考，快速驗證想法，讓企業減少成本更加科學的”試錯”。
隨著企業對數據化運營重視程度的日益增加，必然會衍生出大量的數據統計需求。而XL-LightHouse是以流式大數據統計為切入點，推動流式統計在諸多行業內的快速普及和大規模應用，定位是以一套服務使用較少的服務器資源同時支撐數以萬計、數十萬計的流式數據統計需求的大數據平台，致力於應對這種呈現”井噴”態勢的流式數據統計需求所帶來的一系列問題，寄希望於通過更加貼合場景、更具有實用價值的技術方案幫助企業降低數據化運營方面的成本。
收益
XL-LightHouse可以幫助企業更快速的搭建起一套較為完善的、穩定可靠的數據化運營體系，節省企業在數據化運營方面的投入，主要體現在以下幾個方面：
-
減少企業在流式大數據統計方面的研發成本和數據維護成本。
-
幫助企業節省時間成本，輔助互聯網產品的快速迭代。
-
為企業節省較為可觀的服務器運算資源。
-
便於數據在企業內部的共享和互通。
此外，XL-LightHouse對中小企業友好，它大大降低了中小企業使用流式大數據統計的技術門檻，通過簡單的頁面配置和數據接入即可應對繁雜的流式數據統計需求。
架構
XL-LightHouse包括如下幾個模塊：
-
Client模塊，業務方接入SDK，用於上報統計原始消息數據；
-
RPC模塊，功能包含接收客戶端上報的統計消息數據，對外提供統計結果查詢接口；
-
Tasks運算模塊，功能包含封裝各種流式統計運算場景，執行限流規則判斷，解析各統計項的配置信息，消費消息數據並按統計配置進行計算以及保存統計結果；
-
Web模塊，功能包含對統計組和統計項進行管理維護、查看統計結果、設置限流規則和管理統計指標訪問權限。
系統設計
XL-LightHouse是通用型流式大數據統計平台，它將流式數據統計需求抽象分類成多種運算場景，並對各種運算場景進行高性能的實現從而讓每一種運算可以達到無限制復用的效果。
XL-LightHouse使用【統計工程-統計組-統計項】的三層結構來管理所有統計需求。每一個統計需求叫做一個統計項，每個統計項都是基於一種或多種運算場景。用戶可根據需要創建若干個統計工程，每個統計工程可包含多個統計項，而基於同一份元數據的多個統計項叫做一個統計組。
Web模塊可管理統計項的運行狀態，用戶可在Web端頁面啟動、停止、刪除指定的統計項，處於運行狀態的統計項正常執行統計運算，非運行狀態的統計項不執行統計運算。接入系統首先需要用戶在Web端進行相應配置，然後通過SDK上報原始數據。系統將統計原始消息數據按照統計週期劃分成若干個批次再依據統計配置進行相應計算。
1、自定義流式統計規範(XL-Formula)
SQL規範在大數據查詢和統計分析方面被廣泛應用，SQL在離線數據分析、OLAP、OLTP等領域都具有不可撼動的地位。而且隨著FlinkSQL和SparkSQL等組件功能的日趨完善，SQL在流式統計領域也開始被越來越多的使用。但是由於SQL本身是基於數據表的概念進行數據處理，不可避免需要存儲較多的原始數據和中間態數據在內存中，造成較高的內存浪費；分佈式SQL在數據處理過程中會觸發Shuffle，造成大量的網絡傳輸，影響執行效率；SQL在一些分組聚合操作可能引起較為嚴重的數據傾斜，對程序的正常執行造成影響，很多SQL計算任務需要依據數據量和運算邏輯進行特定優化；針對特定的統計需求需要執行單獨的計算任務，不同統計任務之間運算資源不能共用，從而造成較高的計算資源浪費；SQL語法過於臃腫和復雜、不夠清晰簡潔、多過濾條件的組合邏輯需要依賴較長的SQL語句來實現，不便於理解，書寫較長SQL語句容易出錯；SQL函數定制化功能擴展不夠方便；SQL開發相對較複雜，實現相同功能SQL可能會有多種寫法，不同寫法執行和解析效率也各有差異。這些問題使得相應功能的實現需要依賴專業的數據研發人員，導致流式統計任務研發成本高、週期長。當企業數據指標呈現指數級增長時，SQL規範的瓶頸也將凸顯出來，需要耗費大量的研發成本、數據維護成本和服務器運算成本。我認為SQL規範的這些問題限制了它在流式統計這個細分場景內的快速擴張，使得SQL在這個細分領域內的應用基本局限在定制化需求開發的範圍之內。從一定程度上來說SQL規範已經阻礙了流式統計的發展，制約了流式統計在各行業內的快速普及和大規模應用。 XL-LightHouse作為一個通用型流式大數據統計平台，側重於幫助企業解決繁雜的流式數據統計問題。 XL-LightHouse並沒有拘泥於現行的大數據領域的業內標準，而是寄希望通過使用更為輕巧的技術方案解決目前企業所面對的問題。它定義了一套較為完善的用於描述形式各樣的流式統計需求的配置規範，通過各個屬性的組合可以實現非常強大的統計功能，從而幫助企業更快速的搭建起一套較為完善的、穩定可靠的數據化運營體系。
2、消息聚合處理
系統將整個數據消費鏈路分成以下基本環節：Client模塊上報消息數據環節、RPC模塊處理消息數據環節、運算模塊執行展開和分組操作環節、統計結果存儲環節。在每個環節系統使用異步處理、批量消費、對重複性計算進行聚合處理的方案。各環節接收到消息後放入消息緩衝池，系統依據各環節的預定義聚合邏輯將消息劃分成不同的計算類型，對單節點單進程內相同類型的消息進行聚合處理。這種設計可以減少數據向下游傳輸、提升網絡IO效率、又可以直接減少下游運算量以及DB的寫入壓力。從Client端發送消息到最終的統計結果入庫中間的每個環節都對重複性消息進行聚合處理盡可能減少消息量，並且將與下游運算無關的參數都會儘早拋棄掉，XL-LightHouse的數據消費鏈路是一個逐層遞減的結構。各個環節的消息聚合邏輯略有不同，以Client模塊為例消息聚合主要包括以下內容：
（1）消息體參數裁剪
為了提高消息的傳輸速度並提升後續步驟消息聚合效率，Client模塊需要對原始消息進行裁剪操作，其目的是去掉統計無關字段。統計無關字段是系統根據各統計組下所有有效統計項計算得來，對於與所有有效統計項均不相關的字段在Client模塊上報數據之前將其過濾掉，避免非必要的數據傳輸。
（2）篡改消息體時間戳
Client模塊上報消息環節在執行聚合操作前修改消息原始時間戳為最小批次時間，其目的是為了後續步驟中在保證數據準確性的前提下能夠將盡可能多的消息聚合到一起，減少網絡傳輸和下游運算量。 Client模塊以當前統計組下所有有效統計項的統計週期的最大公約數為時間窗口，按照該時間窗口和消息原始時間戳計算得到消息所對應的最小批次時間。 Client模塊將消息原來的時間戳修改為最小批次時間然後放入緩衝池。
（3）聚合操作
聚合操作即為將同類型消息按預定義聚合邏輯合併到一起。不同環節的聚合邏輯略有不同，Client模塊的聚合邏輯是指消息內容一致的消息，即為相同統計組、相同參數值的消息。原始消息發送到緩衝池後消費線程組定時從緩衝池中批量讀取消息，並將其中符合聚合規則的消息聚合到一起。經過聚合操作後消息體的數據結構由單條消息體內容變更為消息體內容和消息體重複次數兩個屬性。
3、消息展開與分組
在XL-LightHouse中集群內的所有統計任務共用集群運算資源，運算模塊接收到數據後對統計消息進行展開和分組操作。
在大多數業務場景中針對一份元數據往往有多個數據指標，統計組下的所有統計項共用一份原始數據消息。展開操作即為查詢統計組下所有有效統計項，提取各統計項的關聯字段，為各統計項複製一份單獨的消息數據並只保留其運算相關字段的過程。展開操作的目的是為了避免各統計項的後續運算邏輯相互之間產生影響。
分組操作即為提取統計項的統計週期屬性，依據統計週期劃分時間窗口並按時間窗口對展開操作後的消息進行分組；然後判斷統計項是否包含多個統計運算單元，如果包含多個統計運算單元則按統計運算單元進行再分組；判斷統計項是否包含維度屬性，如包含維度屬性則提取維度信息並按維度進行再分組。分組操作的目的在於將各統計任務的運算過程進行分解，拆分成不同的計算類型，同類型消息聚合處理，不同類型的消息運算過程互不影響。
4、消息緩衝池
系統聚合處理所依賴的消息緩衝池實現方案基於有界優先阻塞隊列。系統將消息緩衝池分成若干個Slot，每個Slot的組成結構包括一個BoundedPriorityBlockingQueue（有界優先阻塞隊列）和Slot對應的最後訪問時間戳。消息緩衝池的處理邏輯包括以下步驟：
（1）Producer按照不同環節的聚合邏輯生成消息事件的Key，Key用於區分是否為相同類型的消息；
（2）消息緩衝池依據消息Key按照Hash取餘分配對應的Slot；
（3）按照預定義時間窗口將消息劃分到不同的處理週期；
（4）Slot對相同處理週期的消息按照Key進行優先排序，不同處理週期的消息按窗口時間排序；
（5）消費線程組定時輪詢各個Slot；
（6）判斷Slot的使用容量是否超出閾值，閾值為batchsize * backlog_factor，其中batchsize為指定的單次消費最大消息數量，backlog_factor為指定的消息積壓係數；
（7）如果Slot使用容量沒有超出閾值，則繼續判斷Slot的上次消費訪問時間，如果超出時間閾值則讀取消息批量消費，否則跳過本次任務。消費Slot消息後同時更新Slot使用容量以及最後訪問時間。
該消息緩衝池實現可以將盡可能多的相同計算類型的消息聚合到一起處理，減少對下游運算量和DB的寫入壓力。
5、基數運算
bitcount基數運算是指distinct（非重複值數量統計），系統使用基數過濾裝置過濾已存在的基數值，通過判定在過濾裝置中不存在的基數數量然後更新DB中的統計結果從而實現基數統計。基數過濾裝置包括內存基數過濾裝置和分佈式基數過濾裝置兩部分。內存基數過濾裝置的作用在於初步判斷基數值是否已存在，其作用在於內存判斷效率更高，從而盡可能避免重複性的基數判斷對整體性能的影響。內存基數過濾裝置使用RoaringBitMap工具包實現。分佈式基數過濾裝置內含多個分片，每個分片對應一個RoaringBitMap數據存儲結構，分片數可根據實際需要指定，通過提高分片數可以提高基數運算的準確度。分佈式基數過濾裝置的實現方案包括如下步驟：
（1）將原始數值經過MurmurHash-128Bit生成原始數值對應的Long類型的Hash值。
（2）設置統計任務所需的分片數，每個分片對應一個RoaringBitMap數據結構，本系統過濾裝置採用Redis擴展Redis-Roaring插件的方式實現，原始數值對應的分片可通過Hash取餘獲得。
（3）將Long類型的Hash值按高32bit和低32bit拆分成兩個Int類型整數，如果為負數取其絕對值，兩個Int值的組合對應原始值在RoaringBitMap數據結構中的Index值。
（4）批量將多個基數值對應的Int值組合發送到Redis，將基數判斷的多個操作使用Lua腳本合併執行。判斷Int值組合是否在過濾裝置中存在，如果兩個Int值都在過濾裝置中存在，則表示原始值已存在，否則為原始值不存在，如果原始值在過濾裝置中不存在系統在判定完成後更新相應Index值。
（5）統計在過濾裝置中不存在的原始值的數量並更新到DB中。
該實現方案的好處在於基數運算不需要存儲原始值可減少對內存的佔用；使用MurmurHash-128Bit生成Index值從而不需要維護原始數值和Index的映射關係；RoaringBitMap算法本身俱有壓縮位圖功能可以減少基數稀疏情況下的內存浪費的問題；使用Lua腳本實現基數過濾功能可以減少對Redis的訪問次數提升整體性能；使用內存基數過濾裝置進行初篩可以避免不必要的重複判定；通過調整分片數可以很方便的提升基數統計的準確率。
6、避免shuffle
在大數據任務的執行過程中shuffle是影響性能比較主要的一個因素，Shuffle除了會帶來大量的網絡開銷還可能引起數據傾斜甚至OOM等問題。系統採用避免Shuffle這種不可控的因素從而規避Shuffle可能帶來的不可預料的問題。運算模塊基於Structured Streaming開發，採用完全規避Shuffle的計算方式，通過設置運算節點數量調整任務執行並行度，系統將單運算節點內的統計消息依據統計項標識、維度標識、時間批次、統計運算單元拆分成不同的計算類型。統計結果數據和中間態數據基於外部存儲實現。本系統中統計結果存儲在HBase中，bitcount基數運算的中間態數據存儲在Redis中、limit運算的排序數據存儲在Redis中。每個運算節點在運算過程中只與外部存儲通信，不同運算節點之間互不影響。
7、統計限流
為了避免因為某個大數據量的統計需求的突然接入或某個統計項的流量暴漲而導致系統的不穩定，系統針對統計組消息量、統計項結果量、統計項運算量等維度的熔斷保護機制。該限流保護機制的作用在於可以更好的保障整體服務的穩定性，目前包含以下策略：
（1）統計組消息量限流
統計組消息量限流是針對單位時間內接收到的統計組消息數量的限流策略。系統內置統計組消息量計數裝置用於計算單位時間內接收到的統計組消息數量。當單位時間內消息量超出閾值後觸發限流，使當前統計組進入限流狀態。 Client模塊以及Tasks模塊自動拋棄非正常狀態下的統計組消息。由於一個統計組可對應一個或多個統計項，所以該限流策略會影響統計組下所有統計項的正常統計。統計組進入限流狀態後在指定時間內（默認20分鐘）自動拋棄相應消息，當限流時間達到時間閾值後統計組自動恢復到正常狀態。
（2）統計項結果量限流
統計項結果量限流是針對單位時間內統計項生成的統計結果數量的限流策略。系統內置統計項結果量計數裝置用於計算單位時間內生成統計結果的數量。當單位時間內結果量超出閾值後觸發限流，使當前統計項進入限流狀態。統計項結果量跟兩個因素有關，一是統計週期的時間粒度，統計週期粒度越細的指標數據量越多，比如秒級和分鐘級統計單位時間內生成的統計結果要多於小時級和天級的統計。第二個影響因素是維度，維度數量越多的統計項單位時間內生成的統計結果更多，比如以城市為維度的統計指標生成的統計結果量要高於以省份為維度的統計指標。統計項結果量限流是針對當前統計項的限流策略，所以只對當前統計項有影響，對統計組下其他統計項沒有影響。當統計項進入限流狀態後在指定時間內（默認20分鐘）自動拋棄相應相應消息，當限流時間達到時間閾值後當前統計項自動恢復到正常狀態。
8、時間戳壓縮
系統針對流式統計場景對數據存儲格式進一步優化，目的在於提高DB的數據吞吐量。系統統計結果數據存儲采用時間戳壓縮，根據統計週期劃分成不同的時段，將每個統計項相同維度下的同一時段內的多個統計結果數值存儲在不同的column內，列名採用delta壓縮，同一時段內的數據使用相同的Key，減少Key值的重複。
9、異常熔斷
熔斷機制是為了保障業務方自身服務的穩定性，避免因統計服務的不穩定而對業務方自身服務產生影響。異常熔斷機制是指在調用client接口時，如果單位時間內的失敗次數或超時次數超出閾值，則進入熔斷狀態，此時client模塊自動跳過統計消息發送邏輯。進入熔斷狀態後，client模塊週期性檢測統計服務狀態是否恢復正常，如果統計服務恢復正常則自動重連。
系統功能邊界
-
（1）、不支持原始數據明細查詢；
-
（2）、暫時只涉及流式滾動窗口數據統計(滑動窗口統計將在後續版本中支持)；
-
（3）、暫時不支持秒級粒度數據統計（將在後續版本支持）；
-
（4）、不涉及原始數據採集細節，系統所有的計算都基於接入方上報的原始消息，每一條原始消息數據都需要接入方組裝好再通過SDK上報。此外目前只提供Java版本的SDK,針對JVM語言的服務，接入方可以在服務中直接調用。由其他語言開發的服務，可以將數據採集後存入kafka等消息隊列再通過消費數據的形式接入XL-LightHouse。
項目地址
依賴組件
本項目所依賴的組件主要有：
Hadoop(Apache2.0)、HBase(Apache2.0)、Spark(Apache2.0)、Kafka(Apache2.0)、Zookeeper(Apache2.0)、Redis(BSD3)、Redis-Roaring(MIT)、Guava(Apache2.0)、Caffeine(Apache2.0)、、ZeroICE(GPLv2)、ECharts(Apache2.0)、AdminLTE(MIT)、Aviator、SpringBoot(Apache2.0)、MySQL(GPLv2)、LayUI(MIT)、ZTree(MIT)、JQuery(MIT)、Jedis(MIT)、Freemarker（Apache2.0）、RoaringBitMap(Apache2.0)、Redisson(Apache2.0)、Jackson(Apache2.0)、ACE Editor(BSD)、Disruptor(Apache2.0)
交流反饋
寫在最後的一些話
XL-LightHouse是一套通用型流式大數據統計平台，致力於推動流式統計的快速普及和大規模應用，定位是以一套服務使用較少的服務器資源同時支撐數以萬計、數十萬計流式數據統計需求的大數據平台。 XL-LightHouse面向企業自上而下所有職能人員共同使用，倡導以通用型流式數據統計為切入點，傾向於選擇更為輕巧的技術方案幫助企業更快速的搭建起一套猶如我們人體神經系統一樣遍布全身的、較為完善穩定可靠的數據化運營體系。
流式統計技術並不完美，確實有一些場景不適合使用流式統計實現，所以它也不可能完全取代了其他的技術方案。但是我依然認為在企業數據化運營領域在所有的技術方案中，能夠發揮中流砥柱作用的只有可能是通用型流式數據統計。時效性是流式統計得以青睞的一個原因，但我認為最根本原因在於一項技術能夠普及到什麼程度，很多時候使用的成本決定了一切。
在軟件研發領域，我認為通用型流式統計將會對現在的軟件類產品研發產生較為巨大的影響，它會發展成為如同日誌一樣的重要角色，通用型流式統計或將成為獨立於日誌之外且重要程度不亞於日誌的另一套輔助類工具體系，各種工種的程序員將會在任何有必要的地方加上流式統計的代碼就像加日誌一樣司空見慣、習以為常。
在企業級服務市場，我相信通用型流式數據統計將憑藉其龐大的應用場景和巨大的業務價值而成為企業最核心的基礎服務之一，而以通用型流式數據統計為核心理念、以其他技術方案為輔助手段的數據化運營類產品將成為企業級B端市場不可或缺的中堅力量。此外，伴隨著軟硬件技術的協同發展以及物聯網時代的即將到來，我認為通用型流式數據統計也將滲透於現實世界各個方面，成為社會的一種基礎運算能力在各類行業中得到較為普遍的應用。
Author：雪靈 Contact：better_xueling@126.com
#XLLightHouse首頁文檔和下載 #通用型流式大數據統計平台 #科技資訊