随着企业级海量数据爆发，数据处理分析模式的多样化，数据是如何加工、分析、处理的？
数据计算技术百家争鸣，不可一枝独秀海量数据或者大数据是近十年非常流行的名词，与之相伴的是各种眼花缭乱的框架例如Hadoop、Spark、Hive、Storm、Flink等等，让企业和他们的IT工程师们应接不暇。每一种技术都声称自己的革命性创新，可以大幅度提升性能，颠覆既有框架。但时间证明它们谁也取代不了谁，只是各自适用不同的场景和问题。这背后的根本原因是大数据不仅仅是指数据量大，更重要的是数据处理模式和应用场景的多样性。
举个“栗子”
Hadoop Map/Reduce擅长海量数据的统计分析；
Spark基于内存的RDD更适用于迭代计算；
当处理大量关联的图数据时则不得不采用Pregel的计算模式；
在计算的某些阶段，涉及到小数据量的复杂计算，传统MPI更胜一筹；
当数据处理完成后，用户可能需要对处理结果进行机器学习，此时Tensorflow/Pytorch则更为合适。
企业如何在成本范围内，应对数据处理的多样性？不考虑成本的话，可以购买足够的硬件，雇佣足够数量的工程师，应对所有可能的变化。这在事实上不可行。真正可行的是构建一套融合计算系统，充分利用硬件资源，兼容所有框架，且能简化用户编程。这套系统需要在调度层面实现硬件资源共享、异构资源调度和异构数据访问，且提供简单可扩展的编程模型。
首先，需要在技术层面让不同的计算框架动态共享同一套硬件。由于很多数据中心部署了分离的Hadoop集群、MPI高性能计算集群、GPU机器学习训练集群，各个集群承载单类任务，硬件的资源利用率极低。较新的云计算架构使用虚拟化技术可以在同一套硬件上混合部署多个虚拟机集群，一定程度上解决了这个问题。
其次，虚拟机的运行和部署降低了计算的效能和实时性。虽然应用层解决方案通过两级调度实现了多框架共享资源，例如YARN或Mesos，但还需要开发人员将每个应用编写成一个框架去对接调度器，增加了开发成本。
另外，YARN和Mesos彼此不兼容，容器技术产生后，k8s通过将不同的框架容器化来作为应用服务部署。这虽然实现了共享，但依旧是静态共享，在用户使用方式上和虚拟机集群没有本质区别。
硬件资源的动态共享带来的资源异构和数据异构问题集群中存在不同种类和配置的CPU、GPU、FPGA、内存等硬件，调度系统需要挖掘这些硬件的多维度特性，为计算任务匹配最合适的硬件资源，最大化用户体验。例如GPU集群不但要按照卡调度，还应该支持按照显存调度，调度的时候还需要考虑NVlink、PCIe等互连结构。
CPU调度也应当考虑主频和核数对性能的不同影响，数据的异构问题更为复杂。企业的海量数据可能存在于不同的存储介质中（例如硬盘、SSD、内存），需要通过不同协议访问（POSIX接口、对象协议、KV），对访问性能的要求也千差万别（高带宽或者低延迟）。
因此将所有数据存储系统简单互联只能实现可访问，不能有效的解决计算问题。数据处理系统需要根据应用的不同数据访问协议、不同数据访问模式优化数据访问，在调度计算资源的同时调度存储，为计算任务选择最优的存储空间和访问方式。
举个“栗子”
调度系统发现一个计算任务使用POSIX文件，但它的目标数据存储在对象存储上，则应当先将数据下载到文件存储上，然后再启动任务。如果一个计算任务计算过程中产生大量的小文件，计算结束后会删除这些数据，调度系统应该优先选择在本地存储上缓存这些数据，降低对共享存储的访问。
真正有效的海量数据系统应该在系统层面自动屏蔽这些问题。目前绝大多数系统都依靠用户解决这些资源和数据异构问题，其原因是所谓的语义鸿沟（Semantic Gap），即调度器层面丧失了用户的语义需求。解决问题的根本之道是实现调度系统和用户级别的执行引擎的有效配合，实现应用感知，以及计算、存储的协同设计。执行引擎靠近用户，分析用户程序需求，将需求量化传递到调度器，调度器在调度资源同时调度数据，最终提升用户体验但不给用户增加额外的编程代价。
计算模式的多样性意味着用户需要组合多种框架、语言或者算法解决复杂的业务问题，使得这些框架可以像搭建积木一样被组合起来。这就是编程模型的问题。Hadoop和Spark提供了Map/Reduce的编程接口，Tensorflow提供了丰富的API帮助用户实现符号计算。这些都是特定框架的编程模型，可以帮助用户编写积木。但是要实现多框架融合计算，需要更高层次的领域编程语言和执行引擎。
专业程序员可以通过传统编程语言编写积木，非专业用户可以使用领域编程语言表达积木之间的数据依赖关系和资源需求。执行引擎负责解析用户提交的程序，根据数据依赖生成动态执行图，实现最大化并行性，并根据每一个计算任务的需要动态构建和销毁计算框架，优化数据访问性能，向终端用户屏蔽所有的细节。所以优秀执行引擎是真正简化企业海量数据处理的利器，使得大数据惠及一般企业和开发人员。