大数据|Snowflake 如日中天是否代表 Hadoop 已死？大数据体系到底是什么？( 三 )

如何智能/透明的将数据存储分层，找到成本与性能的Trade-off ，是多层存储系统的关键挑战。这领域起步不久，开源领域没有显著好的产品，最好的水平由几个大厂的自研数仓存储系统引领。
(图：阿里巴巴 MaxCompute 的多层一体化存储体系)
在上述系统之上，有一层文件存储格式层（File Format layer），与存储系统本身正交。
存储格式第一代，包含文件格式、压缩和编码技术、以及Index支持等。目前主流两类的存储格式是Apache Parquet和Apache ORC ，分别来自Spark和Hive生态。两者均为适应大数据的列式存储格式， ORC在压缩编码上有特长， Parquet在半结构支持上更优。此外另有一种内存格式Apache Arrow ，设计体系也属于format ，但主要为内存交换优化。
存储格式第二代 - 以 Apache Hudi/Delta Lake 为代表的近实时化存储格式。存储格式早期，是大文件列存储模式，面向吞吐率优化（而非latency）。随着实时化的趋势，上述主流的两个存储模式均向支持实时化演进， Databricks推出了Delta Lake ，支持Apache Spark进行近实时的数据ACID操作；Uber推出了Apache Hudi ，支持近实时的数据Upsert能力。
尽管二者在细节处理上稍有不同（例如Merge on Read or Write），但整体方式都是通过支持增量文件的方式，将数据更新的周期降低到更短（避免传统Parquet/ORC上的针对更新的无差别FullMerge操作），进而实现近实时化存储。因为近实时方向，通常涉及更频繁的文件Merge以及细粒度元数据支持，接口也更复杂， Delta/Hudi均不是单纯的format、而是一套服务。
存储格式再向实时更新支持方向演进，会与实时索引结合，不再单单作为文件存储格式，而是与内存结构融合形成整体方案。主流的是实时更新实现是基于LogStructuredMergeTree（几乎所有的实时数仓）或者Lucene Index（Elastic Search的格式）的方式。
从存储系统的接口/内部功能看，越简单的接口和功能对应更开放的能力（例如GFS/HDFS），更复杂更高效的功能通常意味着更封闭，并逐步退化成存算一体的系统（例如AWS当家数仓产品RedShift），两个方向的技术在融合。
展望未来，我们看到可能的发展方向/趋势主要有：
1）平台层面，存储计算分离会在两三年内成为标准，平台向托管化和云原生的方向发展。平台内部，精细化的分层成为平衡性能和成本的关键手段（这方面，当前数据湖产品还做得远远不够）， AI在分层算法上发挥更大的作用。
2）Format层面，会继续演进，但大的突破和换代很可能取决于新硬件的演进（编码和压缩在通用处理器上的优化空间有限）。
3）数据湖和数仓进一步融合，使得存储不仅仅是文件系统。存储层做的多厚，与计算的边界是什么，仍然是个关键问题。
2.2 分布式调度，基于云原生，向统一框架和算法多元化发展
计算资源管理是分布式计算的核心能力，本质是解决不同种类的负载与资源最优匹配的问题。在“后红海时代” ， Google的Borg系统，开源Apache Yarn 依旧是这个领域的关键产品， K8S在大数据计算调度方向上仍在起步追赶。
常见的集群调度架构有：
中心化调度架构：早期的Hadoop1.0的MapReduce、后续发展的Borg、和Kubernetes都是中心化设计的调度框架，由单一的调度器负责将任务指派给集群内的机器。特别的，中心调度器中，大多数系统采用两级调度框架通过将资源调度和作业调度分开的方式，允许根据特定的应用来定做不同的作业调度逻辑，并同时保留了不同作业之间共享集群资源的特性。 Yarn、Mesos都是这种架构。共享状态调度架构：半分布式的模式。应用层的每个调度器都拥有一份集群状态的副本，并且调度器会独立地对集群状态副本进行更新。如Google的Omega、Microsoft的Apollo ，都是这种架构。全分布式调度架构：从Sparrow论文开始提出的全分布式架构则更加去中心化。调度器之间没有任何的协调，并且使用很多各自独立的调度器来处理不同的负载。混合式调度架构：这种架构结合了中心化调度和共享状态的设计。一般有两条调度路径，分别为为部分负载设计的分布式调度，和来处理剩下的负载的中心式作业调度。(图：The evolution of cluster scheduler architectures by Malte Schwarzkopf)