大数据 -- 下一代数据处理技术

MapReduce

  1. 2014年之前,MapReduce是数据处理的默认标准,其主要缺点:维护成本高时间性能不足
  2. 2008年,FlumeJava诞生于Google西雅图研发中心,成为Google内部的数据处理新宠
  3. 假设在2008年,已知MapReduce的主要问题,应该如何设计下一代大规模数据处理技术?

让多步骤数据处理易于维护

  1. 维护协调多个步骤的数据处理在业务中非常常见,但复杂的数据处理在MapReduce中的维护成本很高
  2. 可以利用有向无环图(DAG,Directed Acyclic Graph)来抽象表达
  3. DAG能为多步骤的数据处理依赖关系,建立很好的模型

DAG

  1. 如果用MapReduce实现,图中的每个箭头都会是一个独立的Map或者Reduce
    • 为了协调那么多的Map和Reduce,需要做很多检查,系统将不堪重负
  2. 如果采用DAG建模
    • 每一个节点都可以被抽象表达成一种通用的数据集
    • 每一条都可以被抽象表达成一种通用的数据变换
    • 可以用数据集和数据变换描述一个极为宏大复杂的数据处理流程,而不会迷失在依赖关系中

简单配置 + 性能自动优化

  1. MapReduce的配置过于复杂,以至于错误的配置最终导致数据处理任务的效率低下
  2. 得益于上一步使用DAG对数据处理进行了高度抽象,这也成为了自动化性能优化的一个突破口
  3. 理想情况下,计算引擎要能够自动发现红框中的两条数据处理流程是重复的,并进行合并处理
  4. 另一种自动的优化:计算资源的自动弹性分配,在数据处理开始前,需要有一个自动优化的步骤和能力

解耦:数据描述 + 计算引擎

  1. 除了DAG表达需要数据处理描述语言计算引擎协商一致外,其他的实现都是灵活可拓展的
  2. 例如,数据描述可以用Python描述,由业务团队使用,计算引擎用C++实现,可以由数据底层架构团队维护并且高度优化
  3. 例如,数据描述在本地写,计算引擎在云端执行

统一的编程模型:批处理 + 流处理

  1. 批处理处理的是有界离散的数据,而流处理处理的是无界连续的数据
  2. MapReduce的一个局限是它是为了批处理而设计的,不善于流处理
    • 即便是后面的Apache Storm、Apache Flink也有类似的问题
    • Apache Flink进行批处理时用的是DataSet,而进行流处理时用的是DataStream
  3. 真正的业务系统,批处理和流处理常常是混合共生的,或者频繁变换
    • 因此在设计数据处理框架时,需要有更高层级的数据抽象
    • 不管批处理还是流处理,都用统一的数据结构表示,也需要统一的编程API
    • 即使业务需求改变,开发者也不需要频繁修改代码

异常处理 + 数据监控

  1. 在一个复杂的数据处理系统中,难的并不是开发系统,而是异常处理
    • 一个Google内部调研中表明,在大规模的数据处理系统中,90%的时间都花在了异常处理上
  2. 在数据处理系统,数据就是金钱,不能丢失
    • 因此需要设计一套具备基本的数据监控能力,对数据处理的每一步提供自动监控的平台

小结

0%