背景
从毕业到现在大概一年时间，主要从事后台开发工作，工作过程中也因为业务需要，逐渐接触了一些大数据组件，如HDFS、MapReduce、Spark、Hive、ElasticSearch、Impala、Kafka以及最近开始接触到的Flink，简单了解的Kylin、Clickhouse、Pulsar。在进行深入了解与学习、工作需求的评估与实现过程中，产生了对当前数据（或者说是大数据）存储、处理的一些看法，并且不可避免的产生了对未来数据领域的幻想。
鉴于本人工作时间有限，可能在于对历史的了解、对业务需求的认知还不全面，如有讲述不妥之处，请大家积极批评指正。
数据处理现状
“Lambda架构”
在当前大数据存储与处理整体架构来看，大多数公司使用的是Lambda架构，也就是：实时数据与离线数据分为两套逻辑，并且在给上游提供服务的时候，又是一套逻辑，合计起来有3套逻辑，3个Layer。当然不仅如此，我认为还应该增加一个Layer！请看下文分析。
1.实时数据处理（Real Time Layer）：我们可以依赖Storm、SparkStreaming、Flink等组件来实现，当然这几种组件各有千秋，Flink似乎是面向未来的better choice，这里就不展开讨论；
2.离线数据处理（Batch Layer）：我们可以依赖HDFS、Hive等组件，对数据按给定时间周期落库，并且提供上游业务进行查询与使用。
3.向上游提供服务（Serving Layer）：处理好的数据需要向上游输出，提供业务、数据分析人员使用，此时，对于实时性较高要求的在线业务（OLTP），我们可以使用MySQL、Redis、HBase来进行存储。
“Analyzing Layer”
基于上面三个层面的开发，我们已经将数据从仓库中，ETL到了业务所需的数据存储介质。但是在互联网红利逐渐消逝的今天，我们需要对每个业务需求的成本与性价比锱铢必较。
“这块业务做的好不好？做的值不值？转化率？是否需要针对性的突破一下？”
因此在一个业务完成设计与研发并历经千辛万苦上线之后，随之而来的就是工作量不亚于业务本身设计与研发的复盘与统计需求，我们通常需要从离线数据中清洗、聚合，生成让产品经理，运营，老板们能看的懂的数据集合。
也就是数据复盘、统计分析（Analyzing Layer）！对于统计分析型需求（OLAP），我们可以使用ElasticSearch、ClickHouse、Impala、Presto等组件来处理，数据通过这些组件进行多维度查询，可以快速的得到想要的统计结果。
但是写到这里，我们对于一个BigData的业务，已经涉及了4层！这种架构的缺点不言而喻：
每个Layer一套甚至N套逻辑，数据一致性很难保证，并且数据出现问题时，需要在多个层面清洗数据，是一个牵一发而动全身的活儿！
数据未来的臆想
“No More OLAP or OLTP”
随着计算机硬件、计算机网络的逐渐发展，我们拥有了更快速、更多内核的CPU、更大的内存、更快速的硬盘、更优质的网络。
我们是否可以认为，数据在存储过程中，不需要再向上面一样，通过N个层面，一套数据在多套系统中存储多次。
取而代之的是，我们有能够容纳足够多数据、足够快速的存储引擎，我们将数据都存储在一套存储引擎中，不管是业务操作还是数据统计，都从这一个数据库中获取数据。
这样就大大降低了业务开发成本，并且在业务上线的第一时间，数据分析同学就可以拿到相应指标，更快速的迭代我们的功能，创造更好的收益。
