對于一個實時數據產品人員、或者開發人員來說，產品上展示的實時數據，pv、uv、gmv等等，怎么知道這些數據是不是正確的呢？當其他的小組開發的產品的數據(或者其他的數據提供方)又是另外一個數字，那么究竟該如何判斷自己的數據還是別人的數據是正確的呢？這就需要一套實時數據對數方案，本文主要從背景、實時數據計算方案、對數方案、總結四方面來介紹，說服老板或者讓其他人相信自己的數據是準確的、無誤的。 一、背景： 相信做過實時數據統計的朋友，肯定會遇到一個問題，怎么知道自己算的數據是不是對的呢？比如：pv、uv、dau、gmv、訂單等等統計數據。 二、實時數據統計方案 上述流程圖描述了一般的實時數據計算流程，接收日志或者MQ到kafka，用Flink進行處理和計算，將最終計算結果存儲在redis中，最后查詢出redis中的數據給大屏、看板等展示。 但是在整個過程中，不得不思考一下，最后計算出來的存儲在redis中指標數據是不是正確的呢？怎么能給用戶或者老板一個信服的理由呢？相信這個問題一定是困擾所有做實時數據開發的朋友。 比如說：離線的同事說離線昨天的數據訂單是1w，實時昨天的數據確實2w，存在這么大的誤差，到底是實時計算出問題了，還是離線出問題了呢？ 三、對數解決方案 為了方便理解，還是拿上面離線和實時的下單金額為例。 某電商雙11實時數據大屏最終展示的GMV是200億，小李當晚匯報給老板，雙11GMV是200億。第二天晨會，離線的同事小王匯報給老板，雙11GMV是300億。同時又有一個數據部門的同事小趙說，我們這邊計算的是192億。老板聽到這么多數據，一瞬間就不知道該相信誰的呢？然后就說，小李、小王你們兩數據差距最大，你們對一下吧，匯報我一個最終結果。 于是，小王看著自己數據告訴小李：某人在我們平臺下了30個iphone x合計多少錢、某人又在我們這里買了10臺聯想筆記本電腦合計多少錢 ....... 小李看著最終展示在大屏上的200億GMV，瞬間就蒙了，心里想道：我這里不知道誰買了多少個iphone呀，也不知道他們花了多少錢呀？ 于是小李回去請教了自己的導師，導師說你把上面的實時寬表數據存儲下來，就可以和他們對了，就知道誰買了多少個iphone x了，誰有買了多少個聯想電腦了。 小李想了想，按照導師的思路開發如下的寬表加工方案： (1)用Flink將實時寬表數據存儲至elasticsearch 將加工的寬表數據通過Flink寫入es，這樣可以得到所有數據的明細數據，拿著明細和其他數據提供方進行比對即可。 (2)用Flink實時寬表數據存儲至HDFS，通過Hive進行查詢 但是有一些朋友可能會說，es對應的sql count、group by語法操作，非常復雜，況且也不是用來做線上服務，而只是用與對數，所以時效性也不需要完全考慮，這樣的話，就可以考慮將數據回寫至HDFS了。 因此可以考慮采用下圖的方案，將加工的寬表通過Flink寫入到HDFS，然后新建hive表進行關聯HDFS數據進行關聯查詢。 寫HDFS與es相比，存在非常明顯的優點： a.學習成本低、會sql的基本就可以了，而不需要重新學習es負責的count、group by 等語法操作 b.可以非常方便地和離線表數據進行關聯查詢(大多數情況下都是和離線數據比對)，兩張Hive表的關聯查詢，容易找出兩張表的數據差異 最終小李拿著自己存儲的明細數據和小王對了一下，發現是小王的口徑不一樣，沒有排除一些預售訂單，最終小李將匯報給老板，得到了老板的嘉獎。 四、總結 實時計算能提供給用戶查看當前的實時統計數據，但是數據的準確性確實一個很大的問題，如何說服用戶或者領導數據計算是沒有問題的，就需要和其他的數據提供方進行比對了。問題的關鍵就在于，只要有明細數據，就可以和任意一方進行比對，畢竟有明細數據。不服？我們就對一對啊。 明細數據的存儲、設計也很有講究，可以和離線或者其他提供方的數據字段進行對齊，這樣就非常方便進行比對了，而采用hive這種方式又是最簡便的方式了，畢竟大多數人都是會sql的，無論開發人員還是數據人員或者BI人員。