分布式计算演变

首发公众号:二进制社区


背景

数据是企业核心资产之一。

      我们的社会,当下处于大数据的时代,大数据的计算是当前非常火热的技术领域。各行业也处在逐渐从传统化管理模式到数字化变革过程中,企业数字化转型大都是从采购、生产、管理、销售等具体场景进行数字化,让所有流程都能比较清晰地呈现并管理,这个阶段主要是引入各种ERP、CRM、OA、KM、PM系统,这些系统运行过程中积累了海量的数据,需要依赖于分布式存储系统进行数据存储和分布式计算系统进行数据分析、行业知识构建等,本文就大数据存储和计算(分布式计算)的发展历史做一下分析和回顾。


分布式存储和分布式计算涉及的知识范围比较广泛,包括存储系统、计算引擎、消息中间件、调度系统等领域,其中各领域的细分知识更加的复杂和相互关联,后续会组建展开这一系列知识,本文主要介绍当前比较主流的分布式系统的发展状态和推进情况。


分布式存储

     数据计算首先依赖于数据存储,首先你要能存的下大数据。传统的文件系统是单机的,不能横跨不同的机器。当数据达到TB/PB级时,海量数据存储需要变更,由次发展出了Hadoop生态,其中包括分布式文件系统:HDFS(Hadoop Distributed FileSystem)。


     HDFS(Hadoop Distributed FileSystem)的设计本质上是为了大量的数据能横跨成百上千台机器,但是你看到的是一个文件系统而不是很多文件系统。比如你说我要获取/hdfs/tmp/file1的数据,你引用的是一个文件路径,但是实际的数据存放在很多不同的机器上。你作为用户,不需要知道这些,就好比在单机上你不关心文件分散在什么磁道什么扇区一样,HDFS为你管理这些数据。


分布式计算

     存下数据之后,你就开始考虑怎么处理数据。虽然HDFS可以为你整体管理不同机器上的数据,但是这些数据太大了。一台机器读取成TB上PB的数据(很大的数据哦,比如整个东京热有史以来所有高清电影的大小甚至更大),一台机器慢慢跑也许需要好几天甚至好几周。


     对于很多公司来说,单机处理是不可忍受的,比如微博要更新24小时热博,它必须在24小时之内跑完这些处理。那么我如果要用很多台机器处理,我就面临了如何分配工作,如果一台机器挂了如何重新启动相应的任务,机器之间如何互相通信交换数据以完成复杂的计算等等。


分布式计算 - 批处理系统

第一代计算引擎

     MapReduce,采用了很简化的计算模型,只有Map和Reduce两个计算过程(中间用Shuffle串联),用这个模型,已经可以处理大数据领域很大一部分问题。

分布式计算演变

                                                 图1 第一代计算引擎


     MapReduce的设计,采用了很简化的计算模型,只有Map和Reduce两个计算过程(中间用Shuffle串联),用这个模型,已经可以处理大数据领域很大一部分问题了。


什么是Map什么是Reduce?

     考虑如果你要统计一个巨大的文本文件存储在类似HDFS上,你想要知道这个文本里各个词的出现频率。你启动了一个MapReduce程序。Map阶段,几百台机器同时读取这个文件的各个部分,分别把各自读到的部分分别统计出词频,产生类似(hello, 12100次),(world,15214次)等等这样的Pair(我这里把Map和Combine放在一起说以便简化);这几百台机器各自都产生了如上的集合,然后又有几百台机器启动Reduce处理。Reducer机器A将从Mapper机器收到所有以A开头的统计结果,机器B将收到B开头的词汇统计结果(当然实际上不会真的以字母开头做依据,而是用函数产生Hash值以避免数据串化。因为类似X开头的词肯定比其他要少得多,而你不希望数据处理各个机器的工作量相差悬殊)。然后这些Reducer将再次汇总,(hello,12100)+(hello,12311)+(hello,345881)= (hello,370292)。每个Reducer都如上处理,你就得到了整个文件的词频结果。


第二代计算引擎

MapReduce的简单模型,计算很慢,主要是因为I/O对数据换入换出,消耗了很大的时间。为了改善这一现状,就出现了第二代计算引擎,Tez和Spark,除了内存Cache之类的新feature,本质上来说,是让Map/Reduce模型更通用,让Map和Reduce之间的界限更模糊,数据交换更灵活,更少的磁盘读写,更方便地描述复杂算法,取得更高的吞吐量。

           分布式计算演变

                                                       图2 第二代计算引擎


     MapReduce模型虽然很厉害,但是它不够的灵活,一个简单的join都需要很多骚操作才能完成,又是加标签又是笛卡尔积。Tez采用了DAG(有向无环图)来组织MR任务(DAG中一个节点就是一个RDD,边表示对RDD的操作)。它的核心思想是把将Map任务和Reduce任务进一步拆分,Map任务拆分为Input-Processor-Sort-Merge-Output,Reduce任务拆分为Input-Shuffer-Sort-Merge-Process-output,Tez将若干小任务灵活重组,形成一个大的DAG作业。


计算DSL语言

               分布式计算演变

                                                      图3 计算DSL语言


     有了MapReduce,Tez和Spark并在实践过程中发现,MapReduce的程序写起来真麻烦。程序员们希望简化这个过程,比如有个更高层更抽象的语言层来描述算法和数据处理流程。于是就有了Pig和Hive。Pig是接近脚本方式去描述MapReduce,Hive则用的是SQL,至此可以用更简单更直观的语言去写程序了。计算引擎将脚本和SQL语言翻译成MapReduce程序,丢给计算引擎去计算。


     有了Hive之后,人们发现SQL对比Java有巨大的优势。一个是它太容易写了。用SQL描述就只有一两行,MapReduce写起来大约要几十上百行。而更重要的是,非计算机背景的用户终于感受到了爱:我也会写SQL了!于是数据分析人员终于从乞求工程师帮忙的窘境解脱出来,工程师也从写奇怪的一次性的处理程序中解脱出来。


轻量级查询和分析引擎

     自从数据分析人员开始用Hive分析数据之后,它们发现,Hive在MapReduce上跑,太慢了!数据分析希望数据能跑的更快一些,于是Impala,Presto,Drill诞生了(当然还有无数非著名的交互SQL引擎,就不在此列举了),MapReduce引擎太慢,因为它太通用,太强壮,太保守,我们SQL需要更轻量,更激进地获取资源,更专门地对SQL做优化,而且不需要那么多容错性保证(因为系统出错了大不了重新启动任务,如果整个处理时间更短的话,比如几分钟之内)。这些系统让用户更快速地处理SQL任务,牺牲了通用性稳定性等特性。

           分布式计算演变

                                                         图4 轻量级查询和分析引擎



     上面基本就是一个数据仓库的构架了。底层HDFS,上面跑MapReduce/Tez/Spark,再上面跑Hive,Pig。或者HDFS上直接跑Impala,Drill,Presto。这解决了中低速数据批处理的要求。


分布式计算 - 流计算系统

     上面部分介绍了中低速数据处理引擎,那如果我们要更高速的处理呢?

     如果我是一个类似微博的公司,我希望显示不是24小时热博,我想看一个不断变化的热播榜,更新延迟在一分钟之内,上面的手段都将无法胜任。于是又一种计算模型被开发出来,这就是Streaming(流)计算。

       分布式计算演变

                                                               图5 流计算引擎


     Storm是最流行的流计算平台。流计算的思路是,如果要达到更实时的更新,我何不在数据流进来的时候就处理了?比如还是词频统计的例子,我的数据流是一个一个的词,我就让他们一边流过我就一边开始统计了。流计算很牛逼,基本无延迟,但是它的短处是,不灵活,你想要统计的东西必须预先知道,毕竟数据流过就没了,你没算的东西就无法补算了。因此它是个很好的东西,但是无法替代上面数据仓库和批处理系统。


分布式计算 - 流/批计算引擎

            分布式计算演变

                                                              图6 流/批计算引擎


分布式计算大概的演进流程:

  1. 传统数据仓库派说:MapReduce修炼太复杂,我不会编程,以前用SQL吃遍天下,为了将这拨人收入门下,并降低大数据修炼难度,遂出了Hive,Pig、Impla等SQL ON Hadoop的简易修炼秘籍;
  2. 伯克利派说:MapReduce只重招数,内力无法施展,且不同的场景需要修炼不同的技术,太过复杂,于是推出基于内力(内存)的《Spark》,意图解决所有大数据计算问题。
  3. 流式计算相关门派说:你hadoop只能憋大招(批量计算),太麻烦,于是出了SparkStreaming、Storm,S4等流式计算技术,能够实现数据一来就即时计算。
  4. Apache看各大门派纷争四起,推出flink,想一统流计算和批量计算的修炼;


分布是计算 - 流/图计算系统

     由于数据越来越复杂,数据维度越来越多,数据围绕着主ID建立的关系网络也越来越复杂,下一代计算引擎将围绕知识图谱继续向前推进。通过关系的分析推理去发现和挖掘数据的商业价值,后续在单独的章节中展开介绍。


分布式计算 - KV存储

           分布式计算演变

                                                               图7 计算引擎中的KV存储


     KV Store本质是说,我有一堆键值,我能很快速滴获取与这个Key绑定的数据。比如我用身份证号,能取到你的身份数据。这个动作用MapReduce也能完成,但是很可能要扫描整个数据集。而KV Store专用来处理这个操作,所有存和取都专门为此优化了。从几个P的数据中查找一个身份证号,也许只要零点几秒。这让大数据公司的一些专门操作被大大优化了。


分布式计算 - 数据中间件和调度

     除了上述介绍之外,分布式计算还需要一些更特制的系统/组件,比如Mahout是分布式机器学习库,Protobuf是数据交换的编码和库,ZooKeeper是高一致性的分布存取协同系统。


     有了这么多工具,都在同一个集群上运转,大家需要互相尊重有序工作。所以另外一个重要组件是,调度系统,现在最流行的是Yarn,你可以把他看作*管理,负责执行工作的安排。

           分布式计算演变

关联知识

三本秘籍

《Google file system》:论述了怎样借助普通机器有效的存储海量的大数据;

《Google MapReduce》:论述了怎样快速计算海量的数据;

《Google BigTable》:论述了怎样实现海量数据的快速查询;

以上三篇论文秘籍是大数据入门的最好文章,通俗易懂,先看此三篇再看其它技术;


Hadoop

Hadoop包括三大部分,分别是hdfs、MapReduce和hbase:

  • hdfs解决大数据的存储问题。
  • mapreduce解决大数据的计算问题。
  • hbase解决大数据量的查询问题。


写在最后

     学习很重要的是能将纷繁复杂的信息进行归类和抽象。对应到大数据技术体系,虽然各种技术百花齐放,层出不穷,但大数据技术本质上无非解决4个核心问题。

  • 存储,海量的数据怎样有效的存储?主要包括hdfs、Kafka;
  • 计算,海量的数据怎样快速计算?主要包括MapReduce、Spark、Flink等;
  • 查询,海量数据怎样快速查询?主要为Nosql和Olap,Nosql主要包括Hbase、 Cassandra 等,其中olap包括kylin、impla等,其中Nosql主要解决随机查询,Olap技术主要解决关联查询;
  • 挖掘,海量数据怎样挖掘出隐藏的知识?也就是当前火热的机器学习和深度学习等技术,包括TensorFlow、caffe、mahout等;


后续内容列表,欢迎继续关注!

1、分布式存储系统的应用

  • 文件存储
  • KV存储
  • 时序存储

2、分布式计算系统的应用

  • 流式计算
  • Spark系统
  • Flink系统
  • 时序计算

3、知识图谱系统的构建和应用

  • 图数据库
  • 图计算
  • 分析推理
  • 时序计算

4、数据立方



更多深度知识,关注公众号:二进制社区,转载联系:[email protected]