對于一個實時資料産品人員、或者開發人員來說，産品上展示的實時資料，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人員。