关于大数据:3个步骤4大平台搞定大规模数据处理

本文由百度智能云大数据平台技术架构师——李莅在百度开发者沙龙线上分享的演讲内容整顿而成。本次分享围绕云原生数据湖架构的价值开展，深度数据湖计算和对立元数据的技术架构。心愿开发者可能通过本文对一站式大数据处理平台构建有初步意识。

文：李莅
视频回放：https://developer.baidu.com/l…

本次分享的主题是：数据湖架构下的大规模数据处理技术实际。内容次要分为以下 4 个方面：

• 背景介绍
• 大数据根底建设
• 数据湖数仓建设
• 一站式开发平台

01 背景介绍

什么是数据湖

数据湖的概念最早呈现在 2010 年，此时数据湖是一个集中式的存储系统，流入任意规模的结构化和非结构化的数据。但这些还是在关注它存储的相干个性。

随着对象存储（BOS）解决了海量数据和低成本存储问题，用户更关注开掘湖中数据的价值。数据湖的重点从存储转向数据的计算剖析，外围在于强化数据分析的能力。

2017 年随着 AI 的衰亡，深度学习应用大数据处理海量的训练数据输出。借助数据湖架构，能够更好地买通数据之间的壁垒，撑持 AI 模型的训练、推理以及数据的预处理。

数据化架构的演进

• 第一个阶段在 1980 年，过后还是传统的数仓模式：用户把关系型数据库的内容采集下来，通过 ETL 存储到专门的剖析型数据库中，而后在下层提供 BI、报表类的服务。
• 第二个阶段在 2011 年，此时开始引入数据湖的概念：源端的类型也变为更多结构化的数据和非结构化的数据，包含音频和视频等等，而后把这些数据全副都存到数据湖里。
  接下来会依照两种状况解决：第一种通过数据预处理之后为数据迷信或机器学习提供训练的数据输出。第二种通过传统的 ETL 解决，存到剖析型数据库或实时数据库里用来提供传统的报表或 BI 剖析。
• 第三个阶段在 2020 年，此时提出湖仓一体的概念，称为 Lakehouse。底层数据放弃不变，然而应用一个数据湖来对接下层所有利用，其中没有相干的剖析型数据库或实时数据库或数据预处理机制，数据湖能够间接对接 BI、报表、训练、数据迷信、流式剖析等剖析类的场景。

大数据我的项目实例

以一个理论的大数据我的项目为例来介绍一下如何在大规模数据的背景下建设一个数据湖的数仓。

客户的场景次要分为这四方面的内容。

• 进行采集传输。
  其中包含日志文件采集、数据库采集和实时音讯。
• 采集上来的数据须要进行荡涤加工。
  其中包含非结构化文本解析、数据荡涤、格局转换和初步加工校对。
• 将荡涤完的数据用来构建数仓。
  构建的形式包含实时聚合、天级聚合和按周按月聚合。
• 数仓里的数据须要提供给上游去进行数据生产。
  其中包含人员交互、各类报表和 API 服务。

面临新的挑战

在这个背景下会遇到一些新的挑战。

• 首先客户的数据量指数级地减少的，客户很冀望在数据量暴增的同时改善存储的老本并且进步计算能力。
• 其次客户的业务倒退之后，数据类型更加多样，原来可能以关系型数据库为主，起初减少了很多很难间接进行剖析和计算的数据库，用户也心愿可能对立治理。
• 最初，生产数据的利用类型更加简单，带来更大的并发访问量，wokload 和性能冀望是简单多样的。比方有的客户冀望毫秒级的提早，也有的客户冀望小时级然而数据吞吐量特地大。

用百度智能云来构建数据湖

应用百度智能运来构建数据湖，这是提供的一个数据湖仓解决方案。

其中最底层是湖仓引擎层，它的外围设计有三个产品：

• 托管大数据平台 BMR，用来构建传统的 Hadoop 生态
• 数据仓库 Palo，用来存储一些高性能拜访的数据
• 对象存储 BOS
  下层提供一个治理开发平台——大数据开发剖析平台 EasyDAP。

02 大数据基础设施建设

网络布局

首先对客户做一个网络布局，其中 VPC 划分是最重点须要思考的，个别有以下几个内容：

• 在线业务 VPC
• 离线业务 VPC
• 研发测试 VPC
• 思考部门等组织构造情况进行更粗疏的 VPC 划分

• VPC 之间网络隔离，保障互不影响和安全性

  有些状况是须要跨 VPC 去传输数据的，通常会有两种形式去解决：

1）先将数据导入到公共服务比方 Kafka 或者 BOS 上，通过两头服务来上传和下载数据，公共服务保障各 VPC 能够拜访。

2）VPC 如果紧密联系也能够通过网络专线来买通。

计算集群布局

接下来对客户的计算集群做布局，这里应用 BMR 去疾速创立集群。次要思考以三个方面。

• 首先是 BMR 集群划分，其中为客户提供多种集群划分模式根据如下：
• 按业务划分，独立应用。

2. 不同集群之间是强物理隔离。
3. 便于审计资源耗费。

• 在 BMR 的节点布局上能够反对千台级别规模的集群，平时它也可动静扩缩容和升配。BMR 节点类型次要分为三种：
• 主节点，数量比拟少，次要是存元数据和管控。

2. 外围节点，通常是用来存 HDFS，所以心愿它保持稳定。
3. 工作节点，能够进行弹性扩缩容。

还能够为不同类型可设置不同规格硬件，以满足业务须要，

• BMR 的资源抉择上次要衡量 CPU 和内存的比例，其次配置 SSD 来优化 shuffle 的 IO 开销，这里次要应用云磁盘的可靠性和故障恢复能力。其中 CPU 和内存配比通常思考：
• 通用型，1：4。

2. 计算型，1：2。
3. 内存型，1：8。

BMR 组件介绍

BMR 主节点部署的是传统的 Hadoop 各种元数据服务，比方 NameNode、JournalNode、Zookeeper、ResourceManager 等。

外围节点次要是部署如 DataNode、HBase 的 RegionServer 这种存储服务，同时也会混合安排一些 NodeManager，以充分利用计算资源。

工作节点次要是部署 NodeManager，同时也会有一些计算的组件比方像 Hive 中的 Tes，Spark 中的 Presto。

集群中的存储次要应用 CDS，数据会存储到 BOS 中。

计算存储拆散

整体架构次要思考计算和存储拆散的思路，来缩小计算对存储的依赖，进步集群的弹性，以便取得更高的性价比来升高经营的老本。计算存储拆散次要做以下三件事件。

• 第一件是 BOS 代替 HDFS，这外面次要是把很多非结构化文件存到 BOS 中，外围离线数仓 Hive 也存到 BOS 中，针对 HBase 革新它的底层把其中 Hfile 也存到 BOS 中。
• 第二件是应用主动扩缩容机制，通过后面的存储让外围节点数量最小化，按需扩容工作节点，工作实现后通过主动策略机制及时开释，可应用绝对稳定性差但老本更低的竞价实例。
• 第三件是存储管理应用对象存储数据生命周期管理机制，短期长期的数据进行主动 TTL 清理，对长期存储的数据进行存储冷热分级，冷数据可能主动下沉到更低成本的介质中。

为什么选择对象存储

大数据场景数据是与日俱增的，所以存储通常要思考三个方面：

• 易于扩大。
• 低成本。
• 大数据场景下性能满足需要。

BOS 在存储弹性、存储老本、存储管理这三个方面都远胜过 HDFS。

• 在存储弹性方面，BOS 是按量付费的，存储空间简直有限，而 HDFS 须要布局机型大小，扩缩容老本高，相比之下对象存储就简略很多。
• 在存储老本方面，BOS 通过 EC 编码技术和规模效应，单 GB 成本低，而性能优良。冷数据能够专门归档存储，能够存到像磁带、蓝光这样的介质中来进一步取得更低的老本。
• 在存储管理方面，BOS 的存储管理功能齐全。能够按业务划分若干 Bucket，易于管理权限。配置生命周期规定等主动治理规定。领有监控报表，工具齐全，便于剖析审计应用状况。

大数据场景下对象存储性能

应用两种办法比照了大数据场景下对象存储性能。

• 一是比拟传统的 SQL 剖析，应用 10TB 的 TPC-DS，能够从图表中看出性能基本上没有太大的差距，各有千秋，然而差距又很小。
• 另一种是在 HBase 在线拜访，On BOS 和 On 两种 CDS 相比，数据中能够看出差距很小，所以 BOS 在大数据场景上面是能够满足性能须要的。

大数据组件适配对象存储

大数据组件适配对象存储的时候做了以下的革新工作：

• 首先适配 Hadoop 接口其中包含 FileSystem 接口和 AbstractFileSystem 接口

保障在门路写法上兼容，之前 Hadoop 生态外面能间接应用 HDFS 的门路个别能应用 BOS。

• 其次在 BOS 数据读写上应用 BOS 的分块并发上传来进步性能

这样做不占用本地缓存间接写入 BOS，保障文件传完才可见，这样可能防止存储一些脏数据，确保了操作的原子性。

• 元数据，BOS 相比于其余友商的益处就是单个文件能够保障强一致性，同时还能反对 rename。应用 List 对象名的前缀来实现，如果目录层级很深，在高层级做 ls 的时候性能较差。然而目录 rename 不是原子操作，其底层遍历整个目录，而后递归，并发 rename 每个对象，外部重试尽可能达到最终统一。

弹性扩容

利用 BOS 之后能够进行弹性扩缩容，例如图的右侧，从底层采集集群的指标，聚合之后存到监控数据库，而后规定引擎会一直去剖析规定数据库中的指标数据，最初利用各种用户配置的数据规定和策略对节点进行扩缩容治理。

规定引擎分为两种，一种是工夫触发规定，还有一种是监控触发规定，监控规定触发反对节点的资源监控比方 CPU 或者 Hadoop 集群队列的监控，而后为了防止规定引起的震荡引入冷却工夫的机制，一般来说每条规定触发 5 -10 分钟之后才会触发下一条规定。

而后在进行节点变更时，思考到存储的稳定性，主动策略不会触发到外围节点的主动扩缩容，次要是针对工作节点，工作节点在扩容的时候会去购买虚机，而后部署 yarn 服务，而后主动把作业给调度下来，缩容的时候能够确保节点作业工作跑完，不让新的节点调度下来，最初作业跑完之后才会开释这个节点。

指标采集

主动扩缩容是十分依赖指标采集，这里设计了一套主动采集的零碎，它会把 Agent 部署到每一台 BMR 外面的虚机上，并跟集群放弃一体化部署，而后采集的指标涵盖机器指标、服务指标、集群聚合等各种集群级的指标，最初下发采集工作之后拉取指标数据，并且把这些存到百度云的监控云存储外面。

之后其余的中央就能基于这些指标进行 devops 的操作，为运维人员和客户提供监控报警，同时也能够反馈到弹性伸缩扩容决策上。

理论利用

存算拆散整体利用到具体的业务场景上，须要依据业务制订一些策略比方

• 规律性的定时报表作业，按工夫扩容，运行完缩容。
• 辅助以集群负载指标，和队列期待指标，来应答更多突发的状况。
• 非核心业务局部利用竞价实例取得更低的老本。

整体利用弹性扩缩容之后，老本降落 40%。

03 数据湖仓建设

数据仓库布局

首先对客户的数据仓库做一个布局，这里套用一些传统的数仓概念，基本上分为三层：

• ODS，贴源层，次要用来治理收集整理的原始数据。客户的各种数据，比方日志、关系型数据库、API 等，都会通过入湖最终进到 ODS 层。

• DW，数据仓库层，个别是比拟典型的库表模式，在此基础

      1. uDWD 明细层，寄存明细数据。2. uDWS 服务层，足够加工的数据，为利用提供服务，保障时延和并发满足要求。

• DM，数据集市层，其状态偏差 API 服务，跟利用状态耦合更加严密。

典型场景

典型的利用场景就在对立元数据的框架下都是一套库表的构造，大略分为两种人员，一种是运维人员，一种是剖析人员。

• 运维人员次要负责将数据入湖，并且通过 ETL 对数据进行荡涤、加工等。
• 剖析人员次要是进行初步生产数仓外面的数据，进行一些交互式查问、报表制作之类的操作。

对立元数据

在这个场景下，咱们为数据提供对立的元数据服务。

这是自研的一套全局元数据服务，其中提供全局的 REST API 服务，十分不便在云上各处拜访而不受网络的限度，它的底层跟 Hive，Spark，Presto 等买通，相比于原来的 Hive 元数据能够做到无缝切换，存储底层采纳 NewSQL 存储，横向扩大能力强，撑持海量库表和分区。有了这样一套对立的元数据之后能够更好地跟下层数据治理服务相结合。

对立元数据外面次要分为两种表构造，一种是物理表，跟 hive 表差不多，它的数据存在对象存储上，用起来也像 Hive。另一种是映射表，通常是面向关系型数据库或者 NoSQL，只存储映射规定不存储数据，通过 SQL 查问的时候底层间接连源库去查问。

访问控制

在对立元数据的根底之上，还依据客户的需要制订了访问控制的机制，因为客户要对不同人员做细粒度权限的管控和审计，这里实现了行列权限，实现的思路是：

• 仿照 Ranger 的机制，实现成插件的模式，集成到 Hive 或者 Spark 引擎中。
• 对引擎提供权限查问接口，让引擎依据情景做判断。
• 同时买通了云 IAM 和 Hadoop UGI 体系，这样在页面上的操作同时能够带入到 Hadoop 集群外面。
• 提供界面化的权限治理流程（受权，审批等）

此外还提供数据脱敏机制，将用户密级和数据密级进行定义（L0~L5），用户只能拜访对应密级的数据。

如果用户要拜访比他高的数据就须要进行脱敏拜访，脱敏拜访分为两种：

• 动态脱敏，入湖时通过 ETL 可利用脱敏 UDF 解决。
• 动静脱敏，剖析时选取密级适配的脱敏 UDF，做 SQL 改写。

入湖剖析 & 联邦剖析

数据湖剖析首先要剖析湖里的数据，然而很多用户通常有一些存量的数据不想入湖，比方以前购买的传统数仓中的集群，然而业务上又心愿可能把这些数据跟数据湖里的数据一起剖析。这里引入一个联邦剖析的概念，个别通过映射规定将数据源注册成库表模式，而后底下引擎运行 SQL 时间接查问数据源，这种状况跟入湖一样同时反对丰盛的数据源拜访能力。

联邦剖析的劣势有以下几个方面：

• 防止拖数据带来的开销，尤其是传统数仓里的数据自身就很大，拖数据会产生计算、网络方面的开销，同时也有实时性问题。
• 比拟适宜拜访小表，维度表。
• 对于数据源原本就是数仓的情景，防止拖数据造成反复耗费。

联邦剖析的劣势有以下几个方面：

• 对数据源有间接的拜访压力，须要审慎布局。
• 性能依赖源库的计算能力，和算子谓词下推的能力。

数据入湖

数据入湖分为两种。
一种是批量入湖，通常都是定时作业的模式，间接扫描源库，写入数据湖存储，批量作业通常都是整库迁徙的场景，所以要依据数据图表构造生成很多批量作业来进行正当的调度来让它整体运行起来，在这个过程之中也反对 Spark 算子进行数据荡涤。
另一种实时入湖，通过数据传输服务 DTS，应用 CDC 技术采集 MySQL、Oracle、SQLServer 这些关系型数据库的增量日志，而后把这些日志实时写入 Kafka，实时写入到数据湖的库表外面，通常还会定期将增量日志合入全量表。

湖仓一体

在入湖的时候会遇到一些问题：

• 传统入湖，须要校验防止引入脏数据，治理老本高，性能差。
• 实时入湖须要 T+1 merge，数据不能及时可见。
• 传统数据库的格局的分区治理在对象存储上性能差，因为它依赖数据存储的各种元数据的治理。

这样咱们就引入了湖仓一体的技术，首先采纳湖仓一体的存储格局 Iceberg 可能带来以下几方面的益处：

• 反对 ACID 事务（反对 insert，update，delete），防止引入脏数据。
• 对象存储敌对，因为它有一个清单文件去治理外面的文件，所以防止 list，rename 等升高对 BOS 元数据的依赖。
• 同时反对 Merge on read 实现实时可见。
• 还能通过对立元数据，对立查问入口，多场景工作负载（ad-hoc，报表等）性能优化，保障性能和对立的拜访体验，性能优化次要有两方面：
• 自研存储缓存零碎，通过缓存去减速对对象存储下面数据的拜访。
• 对存储格局进行优化，引入了 SortKey 机制，拜访特定模式时能够取得更好的性能。

对立数据湖剖析

在对立元数据的根底上，基于 Trino 的引擎去做革新，从而实现了对立的数据湖剖析，实现了自研的数据湖剖析引擎。
通过对立元数据，将底层 Hive 表、PALO 表和源库都包装成对立的视图造成对立的查问入口，而后应用 Presto SQL 进行剖析，升高各种 SQL 的学习老本，而后通过配套的数据资产疾速检索，找到用户想去查问的库表信息，这样就给对立数据湖剖析带来一些益处。
其中实现了以下几个方面的外围能力：

• 革新 trino 引擎让它能够 on 容器的计算节点治理，即申请即用的资源弹性。
• 反对丰盛的数据源类型，涵盖大部分 DB，传统数仓和 NoSQL。
• 引擎下推优化，CBO 优化。

04 一站式开发平台

EasyDAP 一站式全流程治理

EasyDAP 一站式开发平台次要涵盖以下几个性能板块，

• 数据集成。
• 数据开发运维。
• 数据湖剖析。
• 数据服务。
• 数据利用。
• 数据治理。

这个平台能够将后面所有介绍到的大数据开发操作都界面化，而后在同一个平台下来操作实现。

低代码开发 Studio

这个平台提供低代码的开发 studio，通过插件化的算子，能够在画布上进行可视化的拖拽和配置，是以节点的模式把线连起来去构建数据流，同时还有在线文档展现。它是可插拔和热加载的，还有专用的 Classloader 解决 jar 版本抵触。
反对丰盛的数据源类型和两头算子：

• 关系型数据库、NoSQL、大数据存储 hive 等。
• 常见的抽取和聚合算子，如格局解析，Join，GroupBy 等。
• 反对用户应用 js，python，spark，sql 等语言的自定义算子。

作业调度

作业调度，次要形象了三种作业依赖模式：

• 将不同的作业包装成一个作业组，作业组内不同作业间有一个 DAG 的依赖关系。
• 跨我的项目作业间的依赖。
• 时空依赖（周报表依赖天报表）。

而后在作业调度这一块重点建设以下三个方面：

• 全局逻辑时钟和每个作业的基线时钟，作业调度的基线时钟通过逻辑时钟来表白。
• 实现了自动化的上下游重算机制。
• 反对事件告诉机制。

数据血统

在平台上构建的作业也为其提供数据血统的服务，作业运行的时候通过作业调度或者用户交互式运行会触发工夫告诉。
数据血统剖析模块收到告诉之后就会剖析作业字段的解析，SQL 行列的解析，用户本人标识的血统信息也能够提取进去。
基于这些血统剖析的信息，把库表作位点存储，把运行的作业作位边存储，这样能够构建一个血缘关系图，而后存到图数据库外面，能够基于此进行搜寻。
最初通过界面把这些血缘关系展现进去，能够在界面下来搜寻库表，而后展现以库表为核心的血统（能够反对到列的粒度），也反对整颗依赖树的展现。

数据品质

数据作业还提供数据品质图，咱们给库表去配置一些品质相干的算子，这样用户能够定时去跑作业剖析库表的四个特色维度，而后依据这四个特色维度去造成对应的品质报表和监控数据。

以上是老师的全副分享内容，有问题欢送在评论区提出。

往期举荐
🔗
可视化神器背地的神秘
6000 字，详解数据仓库明星产品背地的技术神秘

扫描二维码，备注：大数据开发，立刻退出大数据产品 & 技术交换群。