服务架构:大数据架构

大数据架构是为处理超大数据量或复杂计算而设计的,流程上包括数据的获取、处理和分析。

大数据,可以简单理解为传统数据库无法处理的数据量,比如主从模式的MySQL在简单场景下可以存储和处理上亿条数据,但涉及到分析场景,能处理的数据量可能远远小于1亿。利用大数据架构,可以轻松处理上亿到千亿数据的分析需求。

大数据架构通常支持这些使用方式:

  • 离线静态数据的批处理
  • 实时动态数据的流式处理
  • 大数据的交互式查询(ad hoc query)
  • 机器学习训练和推理

多数大数据架构会包含下面这些组件:

数据源

所有大数据解决方案都必须从数据源开始,数据源有很多种,比如:

  • 应用的数据存储,比如传统关系型数据库MySQL等
  • 应用产生的静态文件,比如用户行为日志
  • 实时数据源,比如IoT设备

这些数据均来自于大数据系统外部,经过数据清洗等流程存储到大数据系统。

数据存储

离线批处理的数据通常存储在分布式文件系统里,这些文件系统可以以不同的格式存储大量的大文件,比如块存储HDFS上单个block的大小可以是256MB,总体可存储PB量级的数据。当然,存储也分为对象存储和块存储,比如AWS S3是Amazon闭源的对象存储方案,在扩展性和小文件支持上有一些优势。

最近几年,这类分布式块存储或文件存储有一个更时髦的名字:数据湖。

批处理

由于数据量特别大,体现在数据条数多和占用磁盘空间大,大数据架构在应对分析场景时,通常采用耗时的批处理作业去处理数据,处理逻辑包括但不限于转换、过滤、聚合等。这些批处理任务通常会 1)读取源文件,2)处理数据,3)将结果写入新文件。可选的技术有基于MapReduce/Spark的SQL,或使用Java/Scala/Python等编写的MapReduce/Spark任务。

实时消息采集

如果数据源是实时的,那么架构上必须支持捕获并存储实时消息,以方便后面进行流式处理。使用的存储可以非常简单,比如直接append到一个目录下的文件里。但现实中并不会采用这个方案,而是使用一个消息存储充当buffer。这样就能支持多个下游子系统进行独立处理、保障数据不丢失、并获取消息排队的能力。

可选的技术有:Kafka、RocketMQ、RabbitMQ 等。

流式处理

从Source采集到实时消息以后,还需要对消息进行过滤、聚合等操作,用于后续的分析场景。流式数据被处理以后写入Sink。

在这个领域,Flink是名副其实的第一,Flink SQL也是阿里最近几年推行的重点方向,除此之外还有 Spark Structured Streaming,Storm 等技术方案。对比而言,Flink的生态更为完善,Streaming Warehouse也是基于Flink构建的。

分析型数据库

大数据系统的数据源通常是半结构化的数据,分析场景下为了保证性能,通常查询的是结构化的数据表。在传统商业BI系统中,数仓通常以Kimball维度数据仓库理念进行建模,分析型数据库支持在这种数据关系上的查询。相对于Inmon理念,Kimball偏向于保持source不变,中间层做join,最终给业务提供一张大宽表,以满足复杂多样的分析需求。Kimball理念下的数据表关系呈现出典型的星型结构:

除了存算一体的分析型数据库,还有其他方式,比如:

  • 通过一个低延迟的NoSQL数据库去管理和展现数据,比如HBase
  • 基于分布式存储(HDFS、S3等)管理数据+ Hive metastore 管理结构化信息,支持交互式的查询

可选的技术有:交互式Hive、HBase、Spark SQL,目前流行的也有clickhouse、doris等能够榨干机器性能的报表工具。

数据分析和报表

大数据方案的目标多数是通过分析和报表提供对数据的洞察能力。为了增强分析功能,我们通常在架构中会包含一个数据建模层,比如一个多维OLAP cube表。基于Clickhouse 或 Excel,用户自己通过简单的拖拽或点点点,就能做报表。对于懂一些技术的数据科学家和分析师而言,Jupyter Notebook提供了更强大和弹性的交互式分析能力,使用Python或R 可以更自由地访问更大的数据集,可以更好地支持JOIN操作,也能将结果非常轻松地喂tensorflow/pytorch实现更高级的建模分析。

任务调度与编排

多数大数据方案都包含大量的重复计算。一个经典的工作流会包含:1)transform source 数据;2)在多个source和sink之间转移数据;3)将处理过的数据写入分析型数据库;4)将结果写入报表或仪表盘。为了把这些工作流自动化,我们可以使用一些编排工具,比如 Oozie、Sqoop 或大厂自研的那种。这些编排工具可以很好地处理任务的依赖关系,并严格按照依赖关系进行调度,通常也支持延迟报警、数据质量报警等功能。

上面讨论的这些功能组件,目前有很多开源的技术来支持,比如 Hadoop 系列中的 HDFS、HBase、Hive、Spark、Oozie、Sqoop、Kafka,向量分析数据库Clickhouse、Doris等。目前主流的云平台基本都支持这些开源组件,但也基本上都会自研一些,比如阿里的Max Compute等等。

应用场景

  • 存储和处理的数据量远远超过了传统数据库的上限;
  • 需要处理非结构化的数据,用于分析和报表;
  • 采集、处理、分析实时流数据,或要求低延迟的场景;

架构优势

  • 技术选型比较多:可以采用Apache开源技术,也可以使用云服务商的闭源技术,或者混用;
  • 并行带来的极致性能:大数据架构充分利用了并行计算技术,能够高性能地处理大批量数据;
  • 弹性扩容:大数据的绝大多数组件都支持扩容,可以根据数据量和业务要求选择物理资源,数据量增长时扩容的成本也不高;
  • 与现存方案的兼容性:大数据组件既可以用于原始数据的采集,也可以用于顶层业务的数据分析,资源可以混合部署。

有哪些挑战

  • 架构复杂度高:大数据架构需要采集多个数据源的大量数据,包含了很多组件,非常复杂。一方面构建、测试和调试大数据处理任务比较麻烦;另一方面,由于组件太多,多个组件的配置需要协同更改,才能达到优化性能的目的;
  • 技术栈多:很多大数据技术比较专,使用的框架和语言也多种多样。好的一点是,大数据技术构建新的API时,采用了业界广泛推行的语言,比如SQL;
  • 技术成熟度不够高:大数据技术仍然在不断演进。随着Hadoop的核心技术逐渐稳定下来,比如Hive、Pig、HDFS。新技术又不断产生,比如Spark每次迭代都发布了大量的新特性。随着Spark逐渐稳定,Flink、Clickhouse、Doris又崛起成为新的热点;
  • 安全性:大数据架构中,数据通常被存储在一个中心化的数据湖里。安全合规地访问这些数据却愈发重要,在多个应用或平台生产和消费数据的场景下尤其重要。

最佳实践

  • 充分利用并行计算。大数据架构通常会充分利用多台机器的多核特点,将计算任务并行化,以提升性能。并行计算对数据的存储格式有一定的要求,比如数据必须以能够分隔的格式存储。分布式文件系统(比如HDFS)能够优化读写性能,在实际数据处理中由多个计算节点并行执行,减少了作业的整体运行时长。
  • 利用分区。离线数据处理通常按照固定的周期,比如天/周/月级定期执行。把数据文件放到不同的日期分区里,用分区表把数据管理起来,分区的粒度可以与任务执行的时间频率保持一致。这种模式简化了数据采集和作业调度,问题排查也会比较简单。目前主流的框架都支持分区概念,比如Hive分区表,分区作为过滤条件也可以大大缩减计算时扫描的数据量。现在流行的数据湖技术,在分区维度也做了很多优化,比如隐藏分区、bloomfilter索引、hash索引等。另外,在分区的基础上,Spark 3 通过 bucket 优化shuffle数据量。
  • 使用 schema-on-read 语义:数据湖概念出现以后,我们可以给文件定义不同的数据格式,数据格式是结构化、半结构化,或非结构化的。通过 schema-on-read 语义,我们可以在处理数据时,动态地给数据赋予格式,而不是在存储时使用定义好的格式。这给我们的架构带来了很多弹性,数据采集这一环,一定程度上避免了数据校验或类型校验带来的问题。业界主流的方式仍然是在Hive提前创建好表结构,数据写入时必须满足结构限制,这样下游的理解和接入成本比较低;另外,metadata使用中心化地存储,还是去中心化,有很多考量因素,选择schema-on-read模式前一定要慎重考虑。
  • 就地处理数据。传统的BI解决方案通常会通过extract-transform-load(ETL)任务将数据写入数仓。对于数据量特别大、格式多种多样的数据而言,通常会使用ETL的变种,比如 transform-extract-load (TEL)。使用这种方式,数据在分布式存储内部被转换为目标格式,这个过程可以存在多个任务,产出多个中间表。我们一般用数仓分层理论来规范表的名字和属性,比如ODS、DWS、DWD、APP等。APP层的数据表符合分析场景的格式要求,可以将其数据拷贝到分析型数据库(Clickhouse、ElasticSearch等)。
  • 资源使用率 vs 运行时间。在创建批处理任务时,通常要考虑两个方面:1)计算节点上每个计算单元(CPU核)的价格,2)完成一个作业使用的计算节点一分钟花多少钱。举个例子,一个批处理任务,用4个计算节点需要执行8小时。但仔细观察发现,这4个节点在头2个小时满负荷运行,之后只有2个节点满负荷运行。这种情况下,如果使用2个计算节点,作业总的执行时间变成10个小时,并没有加倍;但花的钱变少了。为了缓解这个问题,多个用户/业务共用一个队列是一个简单但不完美的方案,但从更高的层面上,离线/在线资源混合调度才是更大的全局最优解。
  • 独占资源。为了保障业务的正常运行,我们可以给不同类型的任务或业务分配独占资源,包括计算和存储。比如,对于离线处理,Spark/MapReduce 可以使用独立的yarn队列;对于Flink/Structured Streaming 任务,也使用独立的yarn队列;对于工作日上班时间的ad-hoc查询,也可以分配独立的队列。当然,业务稳定运行、开发/调试方便和省钱有天然的冲突,要解决这个问题,需要付诸很多努力。
  • 对数据采集任务进行编排。在一些简单场景中,业务应用可以直接把文件写入分布式存储,然后供分析工具使用。但在大型互联网公司中,通常不会这么干,而是把外部数据源的数据落到数据湖里,然后使用编排工具把作业统一管理起来,依赖关系同时被管理起来,以便稳定产出、高效地复用在下游复杂的业务场景里。任务开发、定期调度、依赖管理、延迟报警、失败debug,这一切通常被维护在一个有Web页面的公司级平台里。
  • 及早清理敏感数据。数据采集过程中,我们可以及早清理掉敏感数据,避免落库。

当前标题:服务架构:大数据架构
当前网址:http://www.shufengxianlan.com/qtweb/news31/334681.html

网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等

广告

声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联