基於 kafka 的日誌資料建模測試

一、前言
我所參與的實際業務中，遊戲日誌鏈路為遊戲客戶端直傳，落入 HBase 中，中間會經歷一次 kafka 訊息佇列，正常提測的時候是對 HBase 中已經存入的資料做建模校驗，但是此時若發現資料不準確，資料丟失，就已經造成了反外掛服務在提取使用者資料分析時的一些不準確預測。針對這種資料鏈路的場景，我們需要提前介入測試，從遊戲客戶端直傳日誌的時候就要開始對遊戲日誌資料進行測試，因為遊戲資料是透過 kafka 直傳，所以我們需要直接對 kafka 中的遊戲資料進行直接測試。

二、什麼是 Kafka
相信很多同學在工作中或多或少都有接觸過訊息中介軟體，kafka 就是其中一種，Kafka 是最初由 Linkedin 公司開發，是一個分散式、分割槽的、多副本的、多訂閱者，基於 zookeeper 協調的分散式日誌系統（也可以當做 MQ 系統），常見可以用於 web/nginx 日誌、訪問日誌，訊息服務等等。
主要應用場景是：日誌收集系統和訊息系統。採用的是釋出 - 訂閱模式
這裡我們不做過多的 kafka 講解，介紹一下 kafka 中某些角色以及他們的作用
Broker：Kafka 叢集包含一個或多個伺服器，伺服器節點稱為 broker
Topic: 每條釋出到 Kafka 叢集的訊息都有一個類別，這個類別被稱為 Topic（物理上不同 Topic 的訊息分開儲存，邏輯上一個 Topic 的訊息雖然儲存於一個或多個 broker 上但使用者只需指定訊息的 Topic 即可生產或消費資料而不必關心資料存於何處）
Pritition: topic 中的資料分割為一個或多個 partition,儲存訊息的分割槽。
Producer：生產者即資料的釋出者，該角色將訊息釋出到 Kafka 的 topic 中。
Consumer: 消費者可以從 broker 中讀取資料。消費者可以消費多個 topic 中的資料
Consumer Group：每個 Consumer 屬於一個特定的 Consumer Group
kafka 的更詳細的介紹這裡就不展示了，感興趣的小夥伴可以去 kafka 官網學習

三、如何測試 Kafka 中的資料呢
由於上文已介紹了 Kafka，所以我們只需要開啟一個 Consumer 即可消費 kafka 中的資料進行資料測試，這裡採用了 kafka-python2.0.1，利用 KafkaConsumer 拉取資料

官方定義的配置 config 很多，具體配置還是要根據當前的業務調整，如上文中的 auto_offfset_reset='earliest'配置了即可消費到最早可以消費到的資料，若是要消費最新的資料，即可去掉這一條配置。
基於檢測任務，所以還是取最新未消費的資料進行拉取校驗。
消費程式開啟後，會不定的消費資料，我們的檢測任務需要一直執行而不停止嗎？在如此大批次的資料情況下，做到每條資料都檢查並做結果輸出是比較困難的，所有我們採取抽樣檢查，再啟動消費者的時候，可以控制消費的數量來達到一次任務需要檢查的日誌條數。
Kafka 叢集有帶認證和不帶認證的，小夥伴需要注意兩種叢集的配置方式。

如上，我們可以自定義採集需要的日誌數量，當日志數量採集完成後，對採集的日誌資料做一次日誌解析後進行資料建模測試，具體解析規則，建模規則校驗試具體建模需求而定。

如果我們採取了一直消費最新的日誌，定義的採集數量比較多，但是資料傳送過來比較少怎麼辦，那我們的採集校驗程式需要一直進行下去嗎，如何優雅的停止我們的消費程式呢？，上文的 Kafka_Consumer 中 consumer_timeout_ms 的配置可以解決這個問題，自定義超時時間，如果在設定的時間內未採集到資料，那麼會自動退出消費程式。
採集好需要檢查的日誌後，可以自定義異常方法去輪詢採集的資料，將不符合採集要求的異常資料以及異常原因保留下來即可完成資料建模測試，並且觀察結果可以快速觀察每條日誌中的資料建模的錯誤原因。
具體資料解析程式碼根據各個業務資料做規則解析，這裡就不貼程式碼了。

四、接入的日誌任務變多了呢？
這個時候，部門的核心宗旨就體現出來了，測試能力工具化，測試工具平臺化。
做成服務化，可以新建執行任務，任務進行週期排程

任務頁面可以實時查詢檢測結果，加入排程任務可對任務資料監控，驗證錯誤即可告警。

五、總結
本文只是從提測資料鏈路中的上一鏈路進行了資料保障，真正的資料保障需要做到全鏈路的資料保障，任重而道遠，若有小夥伴有更好的思路或者技術手段，歡迎賜教。