2014年之前的大数据时代是以MapReduce作为数据处理的默认标准的时代,随着业务逻辑的日益复杂,MapReduce维护成本高和时间性能不足的缺点被不断放大,那么在已经清楚了MapReduce的现有问题的情况下,我们应该怎么设计下一代大规模数据处理技术呢?
(一)我们需要一种技术抽象让多步骤数据处理变得易于维护
为了解决这个问题,我们或许可以用有向无环图(DAG)来抽象表达(在图论中,如果一个有向图无法从某个顶点出发经过若干条边回到该点,则这个图是一个有向无环图(DAG图))。因为有向图能为多个步骤的数据处理依赖关系建立很好的模型,有向无环图参考链接:
西红柿炒鸡蛋这一道菜就是一个有向无环图概念的典型概念,如果使用MapReduce来实现的话,在这个图里,每一个箭头都会是一个独立的Map或者Reduce,为了协调那么多的Map和Reduce,我们又必须去做很多检查,确定依赖关系的正确,最后这个系统就不堪重负了。
如果使用有向图建模,图中的每一个节点都可以被抽象地表达成一种通用的数据集,每一条边都被表达成一种通用的数据变换。如此就可以用数据集和数据变换描述宏大复杂的数据处理流程,而不用在依赖关系中迷失
(二)我们不想要复杂的配置,需要能自动进行性能优化
MapReduce的另外一个问题就是配置过于复杂,以至于错误的配置最终导致数据处理任务效率低下,那么解决这种问题最自然的思路就是:如果人容易犯错,就让人少做,让机器多做。另一种自动的优化就是计算资源的自动弹性分配,也就是在数据规模庞大时,优化系统要有可以处理这种问题的弹性的劳动力分配机制,他要可以自动分配任务。
也就是说在数据处理开始前,我们需要有一个自动优化的步骤和能力,而不是按部就班地把每一个步骤就直接扔给机器去执行
(三)我们要能把数据处理的描述语言,与背后的运行引擎解耦合开来
用有向图进行数据处理描述的话,实际上数据处理描述语言部分完全可以和后面的运算引擎分离了。有向图可以作为数据处理描述语言和运算引擎的前后端分离协议
(四)我们要统一批处理和流处理的编程模型
批处理处理的是有界离散的数据,比如处理一个文本文件。流处理处理的是无界连续的数据,比如每时每刻的支付宝交易数据。
(五)我们要在架构层面提供异常处理和数据监控的能力
在一个复杂的数据处理系统中,难的不是开发系统,而是异常处理。
在数据处理系统中,数据就是金钱,因此对于任何数据都不能随便丢弃,因此要设计一套基本的数据监控能力。
(六)小结