好几天没写了，最近忙，今天告一段落。再不写本周就没产出了，这不是我风格啊。

     今天帮一个开发看了一个场景，一个报表场景，一个SQLIO几乎用尽。5分钟一次，一次2分钟。可能大家认知中报表就应该这样。或者在hadoop中经历涅槃最后展现一个结果（后台服务器累的要死）。其实这是不对的，但是大家认知是这样很难改变。以前我也认为这样，但是随着原理通透以及思路清晰，有时候我会说一些可能“反”认知的观点。可能“砖家”就这样，和大家一样的观点没什么好说的。以今天这个为例，我让他做了一个小小的改动，120秒，变成60毫秒。2000倍的提升对于我来说一点也没有兴奋。20万倍以下的提升我已经没有兴奋点了。我仅仅想表达，大家不要以为报表天生就该慢，这个认知要转变。

   不少时候是一个错误的结论，然后以讹传讹就固化了下来。比如有人说MySQL1000万以上性能极度衰减（如果说是全表查询这个成立，但是这绝对不是数据库的问题），我现在手里就有一个十几亿的表。有人说Oracle处理不了大数据（可能对大数据有误解，如果10TB的全表，的确不快。但是exadata可以做），我以前就有过一个表上百亿数据，没问题呀。

   所以千万不要听非数据库专业的人和你谈这些，会带偏的。

   今天我听到最多的是实时数仓和HATP。实时数仓有三种路线：

第一种是Lambda架构，存在离线和实时两条链路。实时部分以消息队列的方式实时增量消费，一般以Flink+Kafka的组合实现，维度表存在关系型数据库或者HBase；离线部分一般采用T+1周期调度分析历史存量数据，每天凌晨产出，更新覆盖前一天的结果数据，计算引擎通常会选择Hive或者Spark。优点是数据准确度高，不易出错；缺点是架构复杂，运维成本高。这样干的基本是公司花很大代价的钱，效果好不好不知道了。谁用谁知道。

第二种是Kappa架构，相较于Lambda架构，它移除了离线生产链路，思路是通过传递任意想要的offset(偏移量)来达到重新消费处理历史数据的目的。优点是架构相对简化，数据来源单一，共用一套代码，开发效率高；缺点是必须要求消息队列中保存了存量数据，而且主要业务逻辑在计算层，比较消耗内存资源。这样干的是公司机器多，当然也是谁用谁知道。

以上两种投入人力物力都不小。

第三种是实时OLAP变体架构，是Kappa架构的进一步演化，它的思路是将聚合分析计算由OLAP引擎承担，减轻实时计算部分的聚合处理压力。优点是自由度高，可以满足数据分析师的实时自助分析需求，减轻了计算引擎的处理压力；我个人觉得像HATP。比如OB、TiDB、Oracle、heatwave等等。

     好了不管哪种吧。我们退一万步以上都好，都没有问题（我觉得除了第三种问题少点，其他两种怎么可能没问题？）那么都做到了实时传输或者准实时传输。接下来见真章的时候来了，该出报表了，体现出数仓的作用了。结果最后一下拉胯了，数据实时送到仓库了，结果一个报表出了1个小时。这还能叫实时吗？

  所以实时数仓（我个人观点）是实时传输和实时报表两个方面。如何实时传输（HATP这种主从转换以及行列转换，效率最高问题最少）、如何实时报表，那完全是建模和实现逻辑的问题。设计是关键。