編 輯：彭文華
彭友們好，我是老彭啊。前兩天有個彭友給我提了一個問題，我一看就知道得寫篇小作文才能回答了：
沒被這個問題折磨過的人，公司要麼沒有資料團隊，要麼雙方的職責分的很清楚。
其實這個事情還是比較難以區分的，這涉及到技術部門和資料部門職責劃分的事情。
千萬不要以為跟“出資料”相關，就都是資料部門的事情。我作為資料部門的Leader幹過太多類似的事情了，簡直變成背鍋俠了。
OLTP & OLAP
玩資料的都知道，咱把資料分為OLTP（聯機事務處理）和OLAP（聯機分析處理），他們的方向是截然不同個。
OLTP主要負責資料的“增删改查”，簡單了解就是對資料本身進行記錄額沉澱，是資訊部門幹的活兒。
OLAP主要負責對資料的“清洗、轉換、分析、挖掘”，簡單了解就是對OLTP沉澱的資料進行價值提取，是資料部門幹的活兒。
是以事務處理技術發展趨勢就是滿足事物四大特性：ACID，即原子性、一緻性、持久性、隔離性。而分析處理技術發展趨勢就是滿足資料價值挖掘的需求。
但是到這裡，依然沒有解決本文的核心問題：報表應該放在那裡？
OLTP側的報表
OLTP側也是有報表的。在數倉建設之前就有報表了，到現在依然如此。幾乎所有系統都有基本的統計功能子產品，有些業務系統的統計子產品裡的報表還非常豐富。
OLTP側的報表有得天獨厚的優勢：與業務和業務系統無縫對接。它們可以輕而易舉地做到完全實時——本來麼，OLTP側的報表可以直接從業務表裡取數，當然是實時的了。
由于OLTP側完全服務于目前業務流程，是以OLTP側的報表研制目标的非常明确且穩定。君不見很多業務系統裡的報表好幾年都不變。
但是TP側的報表也有很多根深蒂固毛病，這些毛病源自于開發報表的人大多都是程式員，他們對資料的了解依然停留在“增删改查”的階段。
舉兩個例子：
1、時間戳；
2、狀态變化；
3、不輕易對資料做操作（避免影響業務系統性能）。
很多TP側的報表都隻能根據系統中資料現在的狀态進行查詢，對曆史狀态變化沒有進行記錄和留痕。
這就會導緻同一個查詢條件在昨天和今天查的結果是完全不一樣的。原因是業務表中某個篩選條件的狀态資料發生變化了。
還有就是，TP側的報表雖然貼近業務，但是也受限于本業務。跨系統進行資料內建就非常困難，往往會在N個系統之間打“老鼠洞”。不僅管理難度大，安全性也受到挑戰。
OLAP側的報表
是的，你猜到了。資料倉庫就是為了解決上述問題而誕生的。是以你現在再去看看資料倉庫的定義，就能了解為啥這麼寫了：
資料倉庫（Data Warehouse）是一個面向主題的（Subject Oriented）、內建的（Integrated）、相對穩定的（Non-Volatile）、反映曆史變化（Time Variant）的資料集合。
OLAP側的報表是基于數倉、資料集市而建設的。失去了實時性（不過現在也有實時數倉，但是技術複雜度和成本都很高），但是獲得了跨系統資料內建、曆史狀态、穩定等特性。
在OLAP側，由于資料已經搬過來了，就可以随便玩了，可以搞的花樣也就很多了。
與OLTP側的範式模組化不一樣，在AP側往往采用次元模組化，這樣的好處就是可以實作報表的自定義化。“拖拉拽”就是在這個技術背景下産生的。
OLAP側的報表好處就不說了，它能讓人從Excel中來，往Excel中去（别笑，這個評價很高，懂的人自然就懂——老彭）。
到底放在那裡？
OLAP的A就是Analysis-分析，是以OLAP側的報表就是為了分析而生的。對于查賬單這類和業務目的強、實時性高、和業務流程結合緊密的需求來說，OLAP報表明顯是不符合要求的。
但是OLTP側由于資料模組化的方式，注定實作不了次元和度量的自由搭配，即便做了“拖拉拽”，也是徒有其型的銀槍蠟頭，樣子貨。很難跨N個系統進行資料彙聚後的分析，更是難以支撐海量資料的統計、分析、挖掘需求。
但是終究得切分一下，對吧？
老彭簡單整理了幾個問題，問完之後自然就知道應該放在那邊了：
1、資料來源是否來自單一業務系統？是：OLTP+1；否：OLAP+1。
2、資料更新頻率是否要求實時？是：OLTP+1；否：OLAP+1。
3、報表更偏向業務流程還是業務分析？流程：OLTP+1；分析：OLAP+1。
4、報表是否涉及曆史狀态資料？不涉及：OLTP+1；涉及：OLAP+1。
5、資料部門是否獨立部門？是：OLTP+1，否：OLAP+10（沒寫錯，資料部門在IT部門下，你還要啥自行車？老老實實聽老大安排就完了，扯那麼多幹啥？）
以上問題僅供參考，各位彭友可以多列幾個，遇到新報表，按照這個問題清單唠幾句就都心裡有數了。