哪些报表该放入报表系统，哪些又该放到业务系统里？
彭友们好，我是老彭啊。前两天有个彭友给我提了一个问题，我一看就知道得写篇小作文才能回答了：
没被这个问题折磨过的人，公司要么没有数据团队，要么双方的职责分的很清楚。
其实这个事情还是比较难以区分的，这涉及到技术部门和数据部门职责划分的事情。
千万不要以为跟“出数据”相关，就都是数据部门的事情。我作为数据部门的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部门下，你还要啥自行车？老老实实听老大安排就完了，扯那么多干啥？）
以上问题仅供参考，各位彭友可以多列几个，遇到新报表，按照这个问题列表唠几句就都心里有数了。
