主流大数据系统在后台的层次角色及数据流向最近有不少质疑大数据的声音,这些质疑有一定的道理,但结论有些以偏概全,应该具体问题具体分析。对大数据的疑问和抗拒往往是因为对其不了解,需要真正了解之后才能得出比较客观的结论。大数据是一个比较宽泛的概念,它包含大数据存储和大数据计算,其中大数据计算可大致分为计算逻辑相对简单的大数据统计,以及计算逻辑相对复杂的大数据预测。 典型的离线计算平台有: 1、作为通用并行计算模型的hadoop MapReduce、Spark; 2、高性能并行计算的MPI; 3、数据仓库式计算的Hive、Impala、Shark; 4、图模型计算的Pregel、Bagel、GraphX等。 在线计算/实时计算平台通常用来处理流式数据,适用于计算量一般较轻,且时效性需求高或永不间断的计算场景。 常见的实时计算平台有:Storm、S4、Spark Streaming等。消息队列平台一般用于上下游计算的数据衔接,特别是时效性要求较高的计算流程,每个计算步骤的输出结果写入消息队列平台后,下游计算可立即感知并启动计算,缩短反应时间。业界用得较多的平台包括轻量级的Kestrel,以及重量级、容错性好的Kafka。 业务逻辑层承载着各个业务具体的计算逻辑,一般来说有日志处理、离线分析、深度挖掘、分类聚类、预测建模等离线业务,也有实时挖掘、实时监控等实时处理业务。 最外的服务层就是直接对外提供服务的各个业务的线上服务器集群。 位于后台的各个大数据平台,为了容灾、资源复用、例行维护的考虑,其服务访问入口可能会发生变化,因此往往需要一个资源定位系统来获取各个平台当前最新的服务访问入口。通过资源定位系统提供的自动定位服务能力,各个平台服务接口的迁移就可以对使用者透明。 在大数据各平台的整体层次结构中,最不可或缺的配套系统就是自动监控运维系统。海量数据的处理,对存储和计算的压力都是非常巨大的,所以各个平台出现硬件异常和软件异常的概率急速上升,因此需要一套自动监控运维系统来不断监控各个服务器的硬件状况,操作系统层面的CPU、内存、IO、网络等各个指标,大数据平台层面的运作情况,业务逻辑层面的服务状态等。 另外一方面,虽然各个大数据平台都具有一定的容错能力,但是并不是所有类型的错误都能够容忍,并且当出现了可容忍的小错误时,往往预示着更致命的错误隐藏在背后,若不及时发现,就很可能导致非常严重的后果。因此需要监控运维系统将这些小问题提前预警出来,以便将事故扼杀在萌芽中。自动监控运维系统一般具有系统状态检测、性能分析、监控报警、自动发布与回滚等能力。尤其是自动发布与回滚能力,对于海量用户的业务来说,是必不可少的,可以大大减轻运维的工作量,消除容易出错的人工环节,增加业务的稳定性。 前面给出了各个大数据系统在后台的层次结构,接下来介绍一下业务数据在各个平台之间的流向关系。 如上图所示,数据的来源一般有三种:第一种是线上的实时日志流;第二种是定期批量收集和更新的数据;第三种是长期不变的静态数据。前两种数据通常发布到订阅发布系统当中,以通知下游消费者进行消费。静态数据一般直接保存在离线存储系统中,供需要时访问。 发布订阅系统负责管理数据的发布和收集下游的订阅需求,将数据分发给对应的消费者,一部分数据会发送到在线计算平台,另一部分数据会落入离线存储平台。发布订阅系统可分为持久式和非持久式,可根据业务的特性选用。 对于在线处理部分,在线计算平台所需的数据一部分来自从发布订阅系统中获取实时数据,另一部分来自在线存储系统。在线计算平台常见的计算类型有在线服务、流式计算、实时回馈等,分别服务于数据抓取、实时统计、实时监控、在线分析、实时推荐等应用。在线存储平台中的数据一般分为临时缓存数据和持久化数据,这些数据通常来自在线计算平台和离线计算平台。在线存储平台承载的应用有:KV缓存、数据库缓存、流式数据、字典服务等。 对于离线处理部分,离线存储平台负责对文件、对象、结构化数据的存储,服务于日志、网页、关系链、多媒体、字典、数据库等应用,它的数据来源非常丰富。而离线计算平台的数据一般来自离线存储和在线存储,计算结果往往也写回离线和在线存储平台。离线计算平台上的计算分为IO密集型、计算密集型、迭代型、类SQL型等类型,分别对搜索排序、广告算法、个性化推荐、安全检测等应用提供支持。 这里不得不提的是用在离线处理中的任务依赖控制系统。在线处理的各系统由于基本上是数据流驱动或者是事件驱动的,所以不需要显式地设置各个任务的上下游依赖关系,数据和事件的流式传播即触发了对应的计算。而对于离线处理,各个任务都是批量处理的方式,因此需要等上游完成批量处理,下游才能开始接着处理。 现实中往往采用定时器+预估完成时间的方式来粗略地隐式地配置任务依赖,这样带来的问题是: 第一,预估时间不准确,造成时间的浪费或是无效的计算; 第二,上游的延迟会引起下游的连锁反应,不具有弹性的容忍机制; 第三,随着任务增多,依赖关系配置和执行时间的预估变得越发复杂和不可控,而且任务迁移时很容易发生任务丢失和依赖失效的问题。任务依赖控制系统正是为了解决这些问题而诞生的,它把所有任务的依赖拓扑关系放到全局统一的视图中,将这些任务集中起来管理,可视化地配置它们的依赖关系,任务的迁移变得简单可靠。同时,它负责监控每个任务的完成情况,如果成功完成,则马上触发下游的任务;如果失败,则进行重试,直到执行成功才触发下游任务,或者超过重试次数阈值后进行告警。这种自动化的依赖触发方式,缩短了整体业务耗时,并具有弹性容忍延时能力。 对于大数据处理来说,数据是素材,平台是工具。工欲善其事,必先利其器。大数据各个层次的平台已经日臻成熟,我们对其原理与架构也清晰明了。而海量数据中蕴含的巨大价值能否被有效挖掘,就看使用者们的功力了。 责编:樊晓婷 微信扫一扫实时了解行业动态 微信扫一扫分享本文给好友 著作权声明:kaiyun体育官方人口
文章著作权分属kaiyun体育官方人口
、网友和合作伙伴,部分非原创文章作者信息可能有所缺失,如需补充或修改请与我们联系,工作人员会在1个工作日内配合处理。 |
最新文章
|