對于一個即時數據產物人員、或者開闢人員來說，產物上呈現的即時數據，pv、uv、gmv等等，怎麼知道這些數據是不是準確的呢？當其他的小組開闢的產物的數據(或者其他的數據提供方)又是另有一個數字，那麼到底該如何判斷個人的數據還是別人的數據是準確的呢？這就需求一套即時數據對數計劃，本文重要從底細、即時數據算計計劃、對數計劃、結算四方面來介紹，說服老板或者讓其他人相信個人的數據是正確的、無誤的。
一、底細：
相信做過即時數據統計的友人，肯定會遭遇一個疑問，怎麼知道個人算的數據是不是對的呢？例如：pv、uv、dau、gmv、訂單等等統計數據。
二、即時數據統計計劃
上述流程圖繪出了通常的即時數據算計流程，收取日志或者MQ到kafka，用Flink進行處置和算計，將終極算計結局儲備在redis中，最后查詢出redis中的數據給大屏、看板等呈現。
不過在整個過程中，不得不思索一下，最后算計出來的儲備在redis中指標數據是不是準確的呢？怎麼能給用戶或者老板一個信服的理由呢？相信這個疑問一定是困擾所有做即時數據開闢的友人。
例如說：離線的同事說離線昨天的數據訂單是1，即時昨天的數據的確2，存在這麼大的誤差，究竟是即時算計出疑問了，還是離線出疑問了呢？運彩 網頁版
三、對數解決計劃
為了便捷懂得，還是拿上面離線和即時的下單金額為例。
某電商雙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人員。
