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

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

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

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

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

背景介绍
大数据基础建设
数据湖数仓建设
一站式开发平台

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

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

2017年随着AI 的兴起，深度学习使用大数据处理海量的训练数据输入。借助数据湖架构，可以更好地打通数据之间的壁垒，支撑AI 模型的训练、推理以及数据的预处理。

第一个阶段在1980年，当时还是传统的数仓形式：用户把关系型数据库的内容采集下来，通过ETL存储到专门的分析型数据库中，然后在上层提供BI、报表类的服务。
第二个阶段在2011年，此时开始引入数据湖的概念：源端的类型也变为更多结构化的数据和非结构化的数据，包括音频和视频等等，然后把这些数据全部都存到数据湖里。接下来会按照两种情况处理：第一种通过数据预处理之后为数据科学或机器学习提供训练的数据输入。第二种通过传统的ETL处理，存到分析型数据库或实时数据库里用来提供传统的报表或BI分析。
第三个阶段在2020年，此时提出湖仓一体的概念，称为Lakehouse。底层数据保持不变，但是使用一个数据湖来对接上层所有应用，其中没有相关的分析型数据库或实时数据库或数据预处理机制，数据湖可以直接对接BI、报表、训练、数据科学、流式分析等分析类的场景。

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

进行采集传输。其中包括日志文件采集、数据库采集和实时消息。
采集上来的数据需要进行清洗加工。其中包括非结构化文本解析、数据清洗、格式转换和初步加工校对。
将清洗完的数据用来构建数仓。构建的方式包括实时聚合、天级聚合和按周按月聚合。
数仓里的数据需要提供给下游去进行数据消费。其中包括人员交互、各类报表和API服务。

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

首先客户的数据量指数级地增加的，客户很期望在数据量暴增的同时改善存储的成本并且提高计算能力。
其次客户的业务发展之后，数据类型更加多样，原来可能以关系型数据库为主，后来增加了很多很难直接进行分析和计算的数据库，用户也希望能够统一管理。
最后，消费数据的应用类型更加复杂，带来更大的并发访问量，wokload和性能期望是复杂多样的。比如有的客户期望毫秒级的延迟，也有的客户期望小时级但是数据吞吐量特别大。

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

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

首先对客户做一个网络规划，其中VPC划分是最重点需要考虑的，一般有以下几个内容：

在线业务VPC
离线业务VPC
研发测试VPC
考虑部门等组织结构状况进行更细致的VPC划分
VPC之间网络隔离，保证互不影响和安全性
有些情况是需要跨VPC去传输数据的，通常会有两种方式去解决：

1）先将数据导入到公共服务比如Kafka或者BOS上，通过中间服务来上传和下载数据，公共服务保证各VPC可以访问。

2）VPC如果紧密联系也可以通过网络专线来打通。

接下来对客户的计算集群做规划，这里使用BMR去快速创建集群。主要考虑以三个方面。

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

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

在BMR的节点规划上可以支持千台级别规模的集群，平时它也可动态扩缩容和升配。BMR节点类型主要分为三种：
主节点，数量比较少，主要是存元数据和管控。

核心节点，通常是用来存HDFS，所以希望它保持稳定。
任务节点，可以进行弹性扩缩容。

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

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

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

核心节点主要是部署如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每个对象，内部重试尽可能达到最终一致。

规则引擎分为两种，一种是时间触发规则，还有一种是监控触发规则，监控规则触发支持节点的资源监控比如CPU或者Hadoop集群队列的监控，然后为了避免规则引起的震荡引入冷却时间的机制，一般来说每条规则触发5-10分钟之后才会触发下一条规则。

然后在进行节点变更时，考虑到存储的稳定性，自动策略不会触发到核心节点的自动扩缩容，主要是针对任务节点，任务节点在扩容的时候会去购买虚机，然后部署yarn服务，然后自动把作业给调度上去，缩容的时候可以确保节点作业任务跑完，不让新的节点调度上去，最后作业跑完之后才会释放这个节点。

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

规律性的定时报表作业，按时间扩容，运行完缩容。
辅助以集群负载指标，和队列等待指标，来应对更多突发的情况。
非核心业务部分应用竞价实例获得更低的成本。

整体应用弹性扩缩容之后，成本下降40%。

ODS，贴源层，主要用来管理收集整理的原始数据。客户的各种数据，比如日志、关系型数据库、API等，都会通过入湖最终进到ODS层。
DW，数据仓库层，一般是比较典型的库表形式，在此基础
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时直接查询数据源，这种情况跟入湖一样同时支持丰富的数据源访问能力。

联邦分析的优势有以下几个方面：

避免拖数据带来的开销，尤其是传统数仓里的数据本身就很大，拖数据会产生计算、网络方面的开销，同时也有实时性问题。
比较适合访问小表，维度表。
对于数据源本来就是数仓的情形，避免拖数据造成重复消耗。

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

对数据源有直接的访问压力，需要谨慎规划。
性能依赖源库的计算能力，和算子谓词下推的能力。

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

传统入湖，需要校验避免引入脏数据，管理成本高，性能差。
实时入湖需要 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优化。

数据集成。
数据开发运维。
数据湖分析。
数据服务。
数据应用。
数据治理。

这个平台可以将前面所有介绍到的大数据开发操作都界面化，然后在同一个平台上去操作完成。

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

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

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

全局逻辑时钟和每个作业的基线时钟，作业调度的基线时钟通过逻辑时钟来表达。
实现了自动化的上下游重算机制。
支持事件通知机制。

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