专栏首页数据社收藏|如何做一个好的大数据平台架构

收藏|如何做一个好的大数据平台架构

一、Lambda架构需求

Lambda架构背后的需求是由于MR架构的延迟问题。MR虽然实现了分布式、可扩展数据处理系统的目的,但是在处理数据时延迟比较严重。实际上如果内存和CPU足够强大,MR也可以实现近实时运算,但实际业务环境并非如此,因此我们需要权衡,选择实时处理和批处理所需要数据量和恰当的资源。

2012年Storm的作者Nathan Marz提出的Lambda数据处理框架。Lambda架构的目标是设计出一个能满足实时大数据系统关键特性的架构,包括有:高容错、低延时和可扩展等。Lambda架构整合离线计算和实时计算,融合不可变性(Immunability),读写分离和复杂性隔离等一系列架构原则,可集成Hadoop,Kafka,Storm,Spark,Hbase等各类大数据组件。

二、Lambda架构的关键

  • 横向扩容

可扩展性意味着为满足日益增长的用户服务需求,同时不用对底层架构或者代码,可以通过现有机器添加内存或者磁盘资源来实现(垂直扩展),或者可以通过在集群中添加机器实现(水平扩展)。无论是实时或者批处理,都应该能够不停服务的情况下,可以实施水平扩展。

  • 故障容错

系统需要妥善处理故障,确保系统在某些组件发生故障的情况下,整个系统服务的可用性。可能部分组件故障会导致集群中部分节点宕机,影响了整理的SLA,但是系统还是可以相应的,系统不能有单点故障。

  • 低延迟

很多应用对于读和写操作的延时要求非常高,要求对更新和查询的响应是低延时的。

  • 可扩展

系统需要足够灵活,能够实现新增和修改需求,又不需要重构整个系统。实时处理和批处理隔离开,能够灵活修改需求。

  • 易维护

开发部署不能够太复杂。

三、Lambda架构的分层

在Lambda架构中新数据到达时,会被同时分派到批处理层和快速处理层。一旦数据到达批处理层,按照常规批处理时间间隔,每次都从头开始重新计算并生成批处理视图。类似地,只要新数据到达快速处理层,快速处理层就会使用新数据生成快速视图。在查询到达服务层时,它会合并快速视图和批处理视图来生成适当的查询结果。生成批处理视图后,快速视图将被丢弃,除非有新数据抵达,否则只需要查询批处理视图,因为此时批处理层中拥有所有的数据。

Lambda架构定义主要层以及每个组件之间的集成。注意分为以下层:

  • 数据源

数据源指外部的数据库、消息队列、文件等,可以开发数据消费层,隐藏来自不同访问数据的复杂性,定义好数据格式。

  • 数据消费层

负责封装不能数据源获取数据的复杂性,将其转换可由批处理或者流处理进一步使用同一的格式进行消费。

  • 批处理层

这是Lambda架构核心层之一,批处理接受数据,持久化到用户定义好的数据结构中,维护着主数据。数据结构一般不做改变,只是追加数据。批处理还负责创建和维护批处理视图。比如我们常做的Hive ETL ,统计一些数据,最后将结果保存在hive表中,或者数据库中,就属于批处理层。

  • 实时层

这是Lambda另一个核心层。批处理在很多场景下能够满足需求,但是随着业务需求“苛刻性”,他们希望能够及时看到数据,而不是等到第二天才看指标变化和分析结果。所以引入了实时处理。实时层解决了一个问题,即只存储可立即向用户提供的一组数据,这样就不需要对全量数据进行处理,大大提供处理效率。比如流处理仅仅存储最近5分钟的数据,处理计算并形成结果,这就是我们用spark streaming中要有的时间窗口。

  • 服务层

这是Lambda架构的最后一层,服务层的职责是获取批处理和流处理的结果,向用户提供统一查询视图服务。

四、Lambda架构总结

Lambda数据架构曾经成为每一个公司大数据平台必备的架构,它解决了一个公司大数据批量离线处理和实时数据处理的需求。

数据从底层的数据源开始,经过各种各样的格式进入大数据平台,在大数据平台中经过Kafka、Flume等数据组件进行收集,然后分成两条线进行计算。一条线是进入流式计算平台(例如 Storm、Flink或者Spark Streaming),去计算实时的一些指标;另一条线进入批量数据处理离线计算平台(例如Mapreduce、Hive,Spark SQL),去计算T+1的相关业务指标,这些指标需要隔日才能看见。

Lambda架构经历多年的发展,非常稳定,对于实时计算部分的计算成本可控,批量处理可以用晚上的时间来整体批量计算,这样把实时计算和离线计算高峰分开,这种架构支撑了数据行业的早期发展,但是它也有一些致命缺点:

  • 实时与批量计算结果不一致

因为批量和实时计算走的是两个计算框架和计算程序,算出的结果往往不同,经常看到一个数字当天看是一个数据,第二天看昨天的数据反而发生了变化。

  • 批处理的健壮性

随着数据量级越来越大,经常发现夜间只有4、5个小时的时间窗口,已经无法完成白天20多个小时累计的数据,保证早上上班前准时出数据已成为每个大数据团队头疼的问题,同时做个任务并行执行对于大数据集群的稳定性也是巨大的考验,经常会有任务因为资源不足没有定时启动或者报错。

  • 开发和维护的复杂

Lambda 架构中对同样的业务逻辑进行两次编程:一次为批量计算的ETL系统,一次为流式计算的Streaming系统。针对同一个业务问题产生了两个代码库,各有不同的漏洞。

  • 存储增长快

数据仓库的设计不合理,会产生大量的中间结果表,造成数据急速膨胀,加大服务器存储压力。比如我们经常纠结于数据仓库到底怎么分层,是直接ODS层到应用呢?还是ODS层要景观DWS、DW等,最后才到应用呢?

Lambda架构虽然有缺点,但是在很多公司依然适用,有时候我们没有那么大的业务量,实时业务需求并没有那么明显,用着Lambda架构依然很爽。对于超大数据量的业务或者实时业务同样多的情况,可以探索改良Lambda,业内也提出了Kappa架构,感兴趣的小伙伴可以搜索学习下。

本文分享自微信公众号 - 数据社(DataClub),作者:数据社

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2020-09-14

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 数据挖掘从入门到放弃(六):K-means 聚类

    所谓物以类聚-人以群分,“类”指的是具有相似性的集合,聚类是指将数据集划分为若干类,使得各个类之内的数据最为相似,而各个类之间的数据相似度差别尽可能的大。聚类分...

    数据社
  • 如何设计数据中台

    横向规划即在数据中台规划初期,需要打通企业各个业务系,打破数据孤岛现象。其实就是我们建设数据仓库的阶段。比如电信业务,我们要把客户、账务、客服、营销等业务板块打...

    数据社
  • 数据中台设计方法论

    横向规划即在数据中台规划初期,需要打通企业各个业务系,打破数据孤岛现象。其实就是我们建设数据仓库的阶段。比如电信业务,我们要把客户、账务、客服、营销等业务板块打...

    数据社
  • Express框架之静态文件服务

    在之前讲述过使用node元素处理静态web服务,就是一个访问页面的功能,处理文件mime类型,读取文件,麻烦要死,在express框架使用静态web服务其实就是...

    十月梦想
  • 分享个打开a页面自动跳转到b页面的HTML代码

    代码如下: <html> <head> <title>页面跳转</title> <script language="javascript"> location....

    小小鱼儿小小林
  • 如何使用Python连接ldap

    好多使用ldap认证的软件都是Python的,比如superset和airflow, 好吧,他们都是airbnb家的。在配置ldap的时候可能会出现认证失败,你...

    Ryan-Miao
  • Xcelsius(水晶仪表)系列5——统计图综合运用

    今天继续跟大家分享水晶仪表系列的第5篇——统计图的综合运用。 本例是一个通过展现某银行前八年的存款储蓄以及贷款数据,通过预计后两年的存款储蓄增长率、贷款增长率等...

    数据小磨坊
  • 全球隐私及数据保护法律政策动态报告

    全球隐私及数据保护法律政策动态报告 A Global Report on Laws and Public Policies Relating to Pri...

    腾讯研究院
  • 运维对网站架构的一点看法

    图片中的人物是Jeff Dean ,google分布式系统的灵魂式人物,具体的内容大家可以google一下,他的很多分布式系统设计思想都在影响着技术趋势,...

    用户1593318
  • 一文带你秒懂数据结构与算法的三大要素、五大特征!

    想来我应该是惹人怜爱的吧(认真脸),因为我仿佛听到了无数个初入计算机世界的同学的呐喊声(?)。

    roobtyan

扫码关注云+社区

领取腾讯云代金券