淺談實時數據開發
（一）技術路線圖
（二）典型應用場景
電商平臺大促期間成交金額；
廣告主實時報表（分鐘級更新）；
實時反作弊；
業務場景異常監控。
（三）流式技術架構
目前流式計算框架相對成熟，以Storm、Spark Streaming爲代表的開源組件也被廣泛應用。流式數據處理，簡單來講，就是系統每產生一條數據，都會被立刻採集併發送到流式任務中心進行處理，不需要額外的定時調度來執行任務。
流式框架具備以下優點：
時效性高：延遲通常在秒級；
任務常駐：流式任務一旦啓動，就會一直運行，直到人爲終止，且數據源是無界的；
處理性能高：流式計算通常會採用較好的服務器來運行任務，因爲一旦處理吞吐量趕不上採集吞吐量，就會出現數據計算延遲；
邏輯簡單：由於流式計算通常是針對單條數據做處理，缺乏數據之間的關聯運算能力，所以在支持的業務邏輯上相對簡單，並且處理結果會與離線存在一定的差異。
以Storm的Topology爲例來看一下流式數據處理過程：
（四）數據採集
流式數據的源頭，一般來自於各個業務的日誌服務器，有兩種，一種爲訪問日誌：網頁端Web日誌、客戶端日誌，另一種爲數據庫變更日誌：Mysql的binlog日誌、HBase的hlog日誌等。這些數據每採集一條。便會發送到消息隊列中間件中，供下游實時訂閱。
但很多時候，出於吞吐量及系統壓力上的考慮，很多數據並不是新增一條就處理一次，而是根據數據大小或者時間閥值，每收集到一個小的數據文件便處理一次，例如日誌512KB處理一次，或者是30秒寫一次。
在有一些情況下，爲了保證實時數據和離線數據的來源保持一致，一般都是通過消息隊列中間件的方式來採集數據，一方面發送給實時系統做統計，另一方面也是離線系統數據採集的源頭。
Kafka作爲Storm的好朋友，通常用在流式處理過程之前，用於緩衝過量的數據。在數據密集型的系統架構中，一般會使用Kafka作爲中間的緩衝，使用Storm做數據統計時，我們一般會從Kafka中消費消息，然後把最終的統計結果存儲到目標數據庫中，Storm-kafka模塊極大方便了我們在開發Spout時和Kafka的整合。
完整過程如下圖所示：
（五）數據處理
目前在業界比較廣泛採用的框架有Twitter的Storm、Apache的Spark Streaming，以及最近幾年流行的Flink。它們整體架構大同小異，但在實現細節上有諸多的不同，需要根據業務場景的特徵來靈活選擇框架。
當數據被實時加工處理後，會寫到存儲系統中，通常採用Redis存儲數據，一來速度非常快，二來落地到Mysql也非常方便。在流式處理框架中，數據的寫入通常是增量的方式進行。
流式基礎框架圖：
Storm涉及到的概念有：
拓撲(Topologies)；
元組(Tuple)；
流(Streams)；
噴口(Spouts)；
螺栓（Bolts）；
任務(Tasks)；
組件(Component)；
流分組(Stream groupings)；
可靠性(Reliability)；
10.工作進程(Workers)。
Storm組建關係及流程如下圖：
（六）去重
指標去重不僅是離線開發中常見的難題，也是實時系統中常見的問題。由於實時任務追求處理性能，一般的業務邏輯是在內存中完成的，如果數據量過大，勢必拖累系統性能並帶來異常隱患。
去重有兩種情況，一種是精確去重，另一種是模糊去重。精確去重需要特定的業務邏輯來處理，當數據量過大時需要分散到不同的服務器上完成統計，最後彙總統計結果；模糊去重可以採用一些算法模型，將內存的使用量降低到正常的千分之一左右。
常見的模糊去重算法有兩種：
布隆過濾器：布隆過濾器是數據算法的擴展應用，不保存真實數據，只存儲明細數據對應的哈希值標記位，計算的結果比真實值偏小，並且可以設定哈希碰撞的誤差率，每1億條數據大約需要100MB左右的空間即可完成去重計算；
基數估計：基數估計同樣應用了哈希原理，按照數據的分散程度來估計現有數據集的邊界，從而得出大概的去重值總和，該算法的結果可能偏大也可能偏小，但1億條數據只需要10KB即可完成計算。
（七）數據傾斜
數據傾斜也是常見的業務邏輯問題，假設在數據量非常大時，在某個節點需要通過區分key值來做不同的運算，便非常容易遇到數據傾斜的問題。解決實時處理中的數據傾斜問題通常有兩種方式：
去重指標分桶：通過對去重值進行分桶哈希，相同的值一定會落到同一個桶中，最後把每個桶的值進行加總，便得到了最終結果，該方式主要利用分散的內存資源；
非去重指標分桶：數據隨機分發到每個桶中，最後把每個桶的值進行加總，並得到了最終結果，該方式主要利用分散的CPU計算能力。
（八）冪等
冪等是一個數學概念，特點是任意多次執行所產生的影響均與一次執行的影響相同，例如setTrue()函數就是一個冪等函數，無論多次執行，其結果都是一樣的。
以Storm的Ack機制爲例：
Storm爲了保證數據能正確的被處理，對於Spout產生的每一個Tuple，Storm都會進行跟蹤。如果一個Tuple處理成功，則調用Spout的Ack方法；如果Tuple處理失敗，則調用Fail方法；如果在規定的時間內，沒有收到Ack響應Tuple，同樣觸發Fail方法，認爲該Tuple處理失敗。
Storm系統中有一組叫做Acker的特殊的任務，它們負責跟蹤DAG（有向無環圖）中的每個消息。Acker任務保存了Spout ID到一對值的映射。第一個值就是Spout的任務ID，通過這個ID，Acker就知道消息處理完成時該通知哪個Spout任務。第二個值是一個64bit的數字，我們稱之爲Ack val，它是樹中所有消息的隨機ID的異或計算結果。Ack val表示了整棵樹的的狀態，無論這棵樹多大，只需要這個固定大小的數字就可以跟蹤整棵樹。當消息被創建和被應答的時候都會有相同的消息ID發送過來做異或。每當Acker發現一棵樹的Ack val值爲0的時候，它就知道這棵樹已經被完全處理了。
在很多複雜情況下，例如網絡波動、Storm重啓等，會出現重複數據，因此並不是所有操作都是冪等的。
在冪等的概念下，我們需要了解消息傳輸保障的三種機制：At most once、At least once和Exactly once。
At most once：消息傳輸機制是每條消息傳輸零次或者一次，即消息可能會丟失；
At least once：意味着每條消息會進行多次傳輸嘗試，至少一次成功，即消息傳輸可能重複但不會丟失；
Exactly once：的消息傳輸機制是每條消息有且只有一次，即消息傳輸既不會丟失也不會重複。
Storm採用了上游數據備份和消息確認的機制，來保障消息在失敗之後能夠重新處理。Storm的消息確認原理是，每個操作都會把前一次操作處理消息的確認信息返回，同時，Topology的數據源還會備份它生成的所有數據記錄。當所有數據記錄的處理確認信息收到，備份即會被安全拆除；失敗後，如果不是所有的消息處理確認信息被收到，那數據記錄會被數據源數據替換。此舉能夠保障不會發生數據丟失事件，但是，也會帶來數據結果重複的問題，這就是At least once傳輸機制。
因此Storm的機制本身難以保持冪等，需要通過額外的業務處理邏輯來處理數據，在金融等行業尤爲要注意。
（九）多表關聯
在流式數據處理中，數據的計算是以計算增量爲基礎的，所以各個環節到達的時間和順序，既是不確定的，也是無序的。在這種情況下，如果兩表要關聯，勢必需要將數據在內存中進行存儲，當一條數據到達後，需要去另一個表中查找數據，如果能夠查到，則關聯成功，寫入下游；如果無法查到，可以被分到未分配的數據集合中進行等待。在實際處理中，考慮到數據查找的性能，會把數據按照關聯主鍵進行分桶處理，以降低查找的數據量，提高性能。
（十）維表加載
部分業務場景下，爲了加快數據的週轉速度，通常不會將所有信息都記錄到日誌中，部分維度信息需要從維表中加載，但通常會遇到兩種情況：
數據無法準備好，因爲離線系統是批量處理，勢必存在更新的延遲情況；
無法獲取全量最新數據，當維表也作爲一個實時流輸入時，由於到達的無序且時間不確定，容易產生關聯上的歧義。
解決方法有兩種：
全量加載：維表數據量較少時，建議全部加載到內存中進行關聯；
增量加載：如果維表數據很多，可以將熱門數據保留在內存中，通過每天增量更新冷門數據的形式進行處理。
（十一）洪峯挑戰
主要解決思路有如下幾種：
獨佔資源與共享資源合理分配：在一臺機器中，共享資源池可以被多個實時任務搶佔，如果一個任務80%的時間都需要搶資源，可以考慮分配更多的獨佔資源；
合理設置緩存機制：雖然內存的讀寫性能是最好的，但很多數據依然需要讀庫更新，可以考慮將熱門數據儘量多的留在內存中，通過異步的方式來更新緩存；
計算合併單元：在流式計算框架中，拓撲結構的層級越深，性能越差，考慮合併計算單元，可以有效降低數據的傳輸、序列化等時間；
內存共享：在海量數據的處理中，大部分的對象都是以字符串形式存在的，在不同線程間合理共享對象，可以大幅度降低字符拷貝帶來的性能消耗；
在高吞吐與低延遲間尋求平衡：高吞吐與低延遲天生就是一對矛盾體，將多個讀寫庫的操作或者ACK操作合併時，可以有效降低數據吞吐，但也會增加延遲，可以進行業務上的取捨。
熱門文章
