1.查詢等待時間縮短數秒: 之前幾秒現在幾秒 做了哪些方面的優化？
答：之前少則5秒多則10秒以上，現在一般情況下3秒內就會響應。
直播模塊是針對直播節目數據的統計查詢，涉及指標主要是vv和uv，要做的事情就是針對這兩個指標在時間、業務線、鏡頭等多個維度下進行展示，具體表現形式是指定維度下指標占全局的百分比、指標隨時間的變化趨勢，以及日vv/uv、總vv/uv等。
前端和后臺的隔離是指，在前端通過刷新頁面請求在線人數和vv、uv的變化趨勢時，后臺每5分鐘處理一次請求，這樣就保證了當用戶頻繁刷新前端頁面時，不至于給服務器帶來過于繁重的壓力。這種處理方式也決定了vv/uv/在線人數這幾個指標的數據粒度為5分鐘。
實時和離線的隔離是指，對于正在播放的直播節目，vv/uv/在線人數的變化趨勢是時間敏感的，需要實時監測數據，這就要求服務器需要盡量實時地對數據進行處理和響應。而對于已經結束的節目，它們的數據沒有意外的話是不會再變化的，這個時候我們就把它們存放在服務器的磁盤中，當服務器負載較低的時候再按照預先配置的計劃任務進行離線處理，這跟計算日vv/日uv等實時性不強的數據是一個道理。
2.產品上線數據準確率達95+%：以前準確率是多少，低了大概會有哪些問題，如何處理？處理的難點？
答：從測試團隊反饋過來的問題數量來看，之前的準確率大概80%左右，甚至還有一些測試團隊沒有發現的問題，這跟團隊架構有關，測試團隊負責整個研發中心所有項目組的產品驗證，針對各個產品的業務并不能做到百分百的理解，這種情況下就很容易出現我們的魔方數據有些問題他們卻未發現的狀況。所以我加入魔方團隊后就一直負責產品內部驗證，加了這么一個流程之后再上beta版本那邊就很少提問題過來了，因為我在檢查數據問題時功能性問題也一并處理了。;)
準確率低地后果當然嚴重啊，這是拿給業務方作為參考決策的，又是給上面領導看的，如果錯誤率很高那么所有決策就是在錯誤的數據基礎上做決策。
如何處理：大體思路首先是看運算規則是否正確，然后同一指標在不同頁面的數據本該相同的實際上是否相同？
處理的難點：像vv這種指標因為不涉及到去重所以基本上不存在很嚴重的問題，但是uv、在線人數這種就不一定，各個鏡頭或者業務線加起來跟總的一般是不一樣的，uv過濾指標在pc上是按照cookie，業務線上是按照設備號，如果一個用戶在登陸情況下既用pc看又用手機看怎么處理呢，這就涉及到算法選擇的問題。沒有絕對的準確。這個時候需要有清晰的邏輯思維和不屈不撓的堅持精神。;)
3.產品由社交轉型為本地服務平臺：為啥轉型，轉型的結果？
答：因為一上來就做遠距離社交真的很困難，平臺信息和用戶密度過低，用戶上來沒有內容可看，自然沒有欲望去創造去互動，所以雖然我們通過推廣在首周獲取了500+種子用戶，但是后續發展不怎么樣。所以覺得轉型為本地服務，這樣的優勢是我們可以專耕一小塊，先把一個地方的內容做起來，通過地推的方式納入商家，為他們提供免費的推廣和溝通渠道。
轉型的結果是產品變得不倫不類，失去了原先的小清新，不夠專業的商業平臺也不能給商戶或是用戶帶來很大的價值，所以最后不了了之。
