省赛初赛(大数据)
本人系第九届华为ICT大赛实践赛云赛道选手,曾包揽省赛、中国总决赛及全球总决赛三项一等奖,并持有HCIE-Cloud Service认证。现通过本平台分享备赛经验与参赛心得,供各位同学参考。文中所述内容若有疏漏之处,恳请各位不吝指正,在此先行致谢!(建议首先阅读专栏首篇文章——【备赛指南】华为ICT大赛 实践赛 云赛道01,之后再逐步阅读后续内容)
十二、Flume
1. Flume的定义
Flume是流式日志采集工具,Flume提供对数据进行简单处理并写到各种数据接收方的能力
2. Flume的功能
(1) Flume提供多种数据源上收集数据的能力
①本地文件(spooling directory source从目录里采集新的文件内数据)
②实时日志(taildir从目录或文件中采集增量数据,exec执行Linux命令的结果被采集)
提供实时采集日志(taildir)到目的地能力
③REST消息
④Thrift
⑤Avro
⑥Syslog
⑦Kafka(消费Kafka上未读取的数据,相当于客户端)
(2) Flume提供从固定目录下采集日志信息到目的地(HDFS、HBase、Kafka)能力
(3) Flume支持级联(多个Flume对接起来),合并数据的能力,用于源端本端。Flume支持多级级联和多路复制
①多级级联:支持将多个Flume级联起来
Flume级联节点之间的数据传输支持压缩和加密,提升数据传输效率和安全性
(1)Flume API压缩加密
(2)RPC解压解密
(3)Flume
(4)HDFS/Hive/HBase/Kafka
②多路复制:级联节点内部支持数据复制
(4) Flume支持按照用户定制采集数据的能力
(5) Flume支持数据监控,基于华为云MRS Manager监控Source(接受量)、Channel(缓存量)、Sink(发送量)
3. Flume的架构
由Source+Channel+Sink=Agent
①Source:负责接收events或通过特殊机制产生events,并将events批量放到一个或多个Channels。Source必须至少和一个Channel关联
驱动型Source:外部主动发送数据给Flume,驱动Flume接受数据
轮询Source:是Flume周期性主动去获取数据
②Channel:位于Source和Sink之间,其作用类似队列,用于临时缓存进来的events,当sink成功地将events发送到下一跳的Channel或最终目的,events会从Channel移除
Channels支持事务,提供较弱的顺序保证,可以连接任何数量的Source和Sink
(1)Memory Channel:不会持久化,最快但不安全
消息存放在内存中,提供高吞吐,但不提供可靠性,可能丢数据
(2)File Channel:基于WAF(预写式日志Write-Ahead Log)实现。最安全但慢
对数据持久化,但配置麻烦,需要配置数据目录和checkpoint目录。不同的File Channel均需要配置一个checkpoint目录
(3)JDBC Channel:基于嵌入式Database实现,兼容两者,不支持数据库扩展
内置的derby数据库,对event进行了持久化,提供高可靠性,可以取代同样具有持久特性的File Channel(简单取代,文件系统容量还是大)
③Sink:负责将events传输到下一跳或最终目的,成功完成后将events从Channel移除。Sink必须作用于一个确切的Channel
(1) Flume基础架构:可以单节点直接采集数据,用于集群内数据
Log -> Agent(Source->Channel->Sink) -> HDFS(HBase、Kakfa)
(2) Flume多Agent架构:将多个节点连接起来,将最初的数据源经过收集,存储在最终的存储系统中。用于集群外数据导入集群内
Log -> Agent(Source->Channel->Sink) -> Agent(Source->Channel->Sink) -> HDFS
(3) Flume多Agent合并
Log -> Agent1(Source->Channel->Sink) ->
Log -> Agent2(Source->Channel->Sink) ->
Agent3(Source->Channel->Sink) -> HDFS
4. Flume的架构图
在Flume传递的数据叫“事件events”,是事务管理方式
十三、Kafka
1. 分布式消息传递:是基于可靠的消息队列,在客户端应用和消息系统之间异步传递消息
(1) 点对点传递模式
消息持久化到队列,此时,会有一个或多个消费者消费队列中的数据。但一条消息只能被消费一次。当一个消费者消费了队列中的某条数据后,该条数据会从队列中删除。该模式即使由多个消费者同时消费数据,也能保证数据处理的顺序
(2) 发布-订阅消息传递模式(Kafka)
消息持久化到一个topic中,消费者可以订阅一个或多个topic,消费者可以消费该topic中所有的数据,同一条数据可以被多个消费者消费,数据被消费后不会立马删除
消息生产者叫发布者
消费者叫订阅者
2. Kafka的定义
Kakfa分布式消息订阅系统,强依赖ZooKeeper,最初由Linkedln公司开发,是基于ZooKeeper协调的分布式日志系统
主要应用场景:日志收集系统、消息系统
Kafka不支持消息随机读取
3. Kafka的特点
(1) 以时间复杂度为O(1)(常量,不会随数据量变大时间变小)的方式提供消息持久化能力,即使对TB以上数据也能保证常数时间访问
(2) 高吞吐率,即使在廉价机器也能单机每秒100K条消息传输
(3) 支持消息分区,分布式消费,同时保证每个分区内消息顺序传输
(4) 同时支持离线数据处理和实时数据处理
(5) Scale out:支持在线水平扩展
4. Kafka的拓扑结构图
(1) Broker:服务实例,可以动态添加
(2) Topic:每条发布到Kafka集群的消息都要由类别、主题
(3) Partition:Kafka把Topic分成一个或多个Partition分区,每个分区在物理上对应一个文件夹,该文件夹下存储这个Partition所有消息和索引文件
-
Partition分区支持被消费者并行读取,先读新的再读旧的
(4) Producer:负责发布消息到Kafka Broker
(5) Consumer:消费者(记录Offset,数据偏移量)
-
每条消息在文件中的位置叫offset偏移量
-
offset存储机制:Consumer在从Broker读取消息后,可以选择commit,该操作会在Kafka中保存该Consumer消费者在该Partition中读取的消息offset。该Consumer下一次再读该Partition时会从下一条开始读。(保证同一消费者从Kafka中不会重复消费数据)
-
-
消费者通过offset、partition、topic跟踪记录
(6) Consumer Group:每个消费者属于一个特定的Consumer Group,组内消费者对于数据是竞争,组间的消费者对于数据是共享
5. Kafka的其他重要概念(默认HA)
(1) Replica:是Partition的副本,保障Partition分区的高可用
每个Partition有一个至多个Replication副本,且该副本分布在集群不同Broker上来提高可用性。Partition分区的每个Repilication副本在逻辑上抽象为一个日志(Log)对象,是一一对应的
①分区分布在不同服务节点上
②Broker挂了,该Broker上的分区不可以被消费,同时Producer不能写入
(2) Leader和Follow:在既有分区又有副本的情况下,对外服务的肯定只有一个。这两都是“Repilica”的角色
①Leader负责跟Producer和Consumer交互
②Follow从Leader复制数据
Kafka的Leader和Follow消息同步:Follow从Leader那拉取高水位以下的已经存储的消息到本地Log(日志)
如果Follower与Leader的数据相同就会进入ISR同步副本机制队列,代表与主相同,会优先变成Leader
对于f+1个Replica副本,Partition可以容忍f个Replica失效的情况下保证消息不丢失
当所有Replica副本都不工作
(1)等待ISR中任一Replica活过来,并选它为Leader。可保障数据不丢失但时间可能相对较长
(2)选择第一个活过来的Replica(不一定是ISR成员)作为Leader。无法保障数据不丢失,但相对不可用时间较短
选择更多是第二种,第一种不一定能活过来
(3) Controller:Kafka集群中的服务器,用来进行对Leader的选举,当Leader挂了
6. 消息传输语义
(1) At most once最多一次
-
消息可能丢失
-
消息不会重复发送和处理
(2) At Least once最少一次
-
消息不会丢失
-
消息可能会重复发送和处理
(3) Exactly once仅有一次
-
消息不会丢失
-
消息仅被处理一次
7. 可靠性保证
(1) 幂等性
被执行多次造成的影响和只执行一次造成的影响一样
原理
(1)每发送到Kafka的消息都含有一个序列号,Broker使用这个序列号来删除重复数据
(2)这个序列号被持久化到副本日志,即使分区的Leader挂了,其他Broker接管了Leader,新Leader仍可以判断重复发送的是否重复
(3)这种机制开销非常低,每批消息只有几个额外的字段
(2) acks机制
Producer生产者需要Server接收到信号之后发出确认接收的信号,此项配置指Producer需要多少个这样的确认信号(实际代表了数据备份的可用性)
(1)acks=0:Producer不需要信号
(2)acks=1:至少要等Leader成功将数据写入本地Log,但并没有等待所有Follower是否成功写入。如果该Leader挂了,消息会丢弃
(3)acks=-1/all:Leader要等所有备份都成功写入日志,这种策略会保证只要有一个备份存活就不会丢数据(Leader接收数据,Follower拉取数据)
8. 旧数据处理方式 (默认Kafka存储168小时,过了就删)
Kafka把Topic中的一个Parition分区大文件分为多个小文件段,通过多个小文件段就容易定期清除活删除已经消费完文件,减少磁盘占用
.index数据的偏移量,.log实际数据。两个组成一批数据,存在一批批数据。寻址开销最大20000
Kafka集群会保留所有消息,无论其被消费与否,但因磁盘限制肯定要删
(1) 日志的清理方式
①delete
②compact:压缩,旧数据删除,key相同留下最大的values
-
(2) 删除的阈值
①过期的时间
②分区内总日志大小
触发都会删除老数据
日志数据文件保留最长时间168小时
每个Partition上的日志数据所能达到的最大字节,默认不限制-1,可以修改
十四、ElasticSearch
1. ElasticSearch的定义
ElasticSearch是一个高性能,基于Lucene的全文检索服务,是一个分布式的Restful风格的搜索和数据分析引擎,也可以作为NoSQL数据库使用
(1) 对Lucene进行了扩展
(2) 原型环境和生产环境可无缝切换
(3) 能够水平扩展
(4) 支持结构化和非结构化数据
2. ElasticSearch的特点
(1) 高性能:能立即获得搜索结果,实现了用于全文检索的倒排索引
(2) 扩展性:支持水平扩展,可运行于成百上千台服务器上,原型环境和生产环境可无缝切换
(3) 相关性:搜索所有内容,基于各项元素(从词频或近因到热门度等)对搜索结果进行排序
(4) 可靠性:自动检测故障(如硬件故障、网络分割)并保障的集群(和数据)的安全性和可用性
3. ElasticSearch的应用场景:用于日志搜索和分析、时空检索、时序检索、智能搜索等场景
(1) 检索的数据类型复杂:如需要查询的数据有结构化数据、半结构化数据、非结构化数据等ElasticSearch可以对以上数据类型进行清洗、分词、建立倒排索引等一系列操作,然后提供全文检索的能力
(2) 检索条件多样化:全文检索条件可以包括词或短语
(3) 边写边读:写入的数据可以实时的进行检索
4. ElasticSearch的生态圈
ELK/ELKB提供了一整套解决方案,并且都是开源软件,之间互相配合使用,完美衔接,高效的满足了很多场合的应用
(1) 用户接入层:Klbana
(2) 数据持久化与分析层:ElasticSearch
(3) 数据接入层:Logstash、Beats
(4) 插件扩展层
5. ElasticSearch的架构
(1) ElasticSearch的系统架构
①Client(文件索引和搜索操作)
②Cluster:单个EsMaster和多个EsNode(读取索引文件)
③磁盘
(2) ElasticSearch的内部架构
①通过RESTfuL API或者其他语言(比如Java)API提供丰富的访问接口
②集群发现机制
③支持脚本语言
④底层基于Lucene,保持Lucene绝对的独立性
⑤通过本地文件、共享文件、HDFS完成索引存储
6. ElasticSearch的核心概念
(1) Index:索引,是ElasticSearch中的一个逻辑命名空间
(2) Type:文档类型,用于存储不同类型的文档。ElasticSearch7已删除Type
(3) Document:文档,是可以被索引的基本单位
(4) Mapping:映射,用来约束字段的类型
(5) Cluster:代表一个集群,集群中有多个节点,其中有一个为主节点,这个主节点是可以通过选举产生的,主从节点是对于集群内部来说的
(6) EsNode:ElasticSearch节点,一个节点就是一个ElasticSearch实例
(7) EsMaster:主节点,可以临时管理集群级别的一些变更,例如新建或删除索引、增加或移除节点等。主节点不参与文档级别的变更或搜索,在流量增长时,该主节点在流量增长时,该主节点不会成为集群的瓶颈
(8) shards:代表索引分片,ElasticSearch可以把一个完整的索引分成多个分片,这样的好处是可以把一个大的索引拆分成多个,分布到不同的节点上
(9) replicas:代表索引副本,Elasticsearch可以设置多个索引的副本,副本的作用一是提高系统的容错性,当某个节点某个分片损坏或丢失时可以从副本中恢复。二是提高ElasticSearch的查询效率,ElasticSearch会自动对搜索请求进行负载均衡
(10) Recovery:代表数据恢复或叫数据重新分布,Elasticsearch在有节点加入或退出时会根据机器的负载对索引分片进行重新分配,挂掉的节点重新启动时也会进行数据恢复
(11) GateWay:代表Elasticsearch索引快照的存储方式,ElasticSearch默认是先把索引存放到内存中,当内存满了时再持久化到本地硬盘Gateway对索引快照进行存储,当这个Elasticsearch集群关闭再重新启动时就会从GateWay中读取索引备份数据
Elasticsearch支持多种类型的GateWay:
①有本地文件系统(默认)
②分布式文件系统
③Hadoop的HDFS
④amazon的s3云存储服务
(12) Transport:代表Elasticsearch内部节点或集群与客户端的交互方式,默认内部是使用TCP协议进行交互,它也支持http协议(Json格式)Thrift、Servlet、memcached、zeroMQ等的传输协议(通过插件方式集成)
7. Elasticsearch的倒排索引
(1) 正排索引:是通过Key寻找Value,即从关键点出发,然后再通过关键点找到信息中满足搜索条件的特定信息
(2) 倒排索引:ElasticSearch所采用得排序方式,是通过Value找Key。而在全文搜索中Value就是要搜索的关键词,通过Value找到对应的文档
8. Elasticsearch的访问接口
Elasticsearch可通过RESTful请求来对数据进行操作。请求分5种:GET、POST、PUT、DELETE、HEAD,以实现对文档和索引增删改查
9. Elasticsearch的算法
(1) Elasticsearch的路由算法
①默认路由:shard=hash(routing)%number_of_primary_shards,这里路由策略扩展受到shards个数的限制,扩容的时候需要成倍扩容(ES6.x),并且在创建index的时候要指定未来允许扩容的规模
ES5.x不支持扩容;ES7.x可以自由扩容
②自定义路由:该路由方式,通过指定routing的方式,可以影响文档写入到哪个shard,也可以仅仅检索特定的shard
(2) Elasticsearchd的平衡算法:Elasticsearch中提供了自动平衡功能,适用场景:扩容、减容、导入数据场景
①weight_index(node, index)= indexBalance * (node.numShards(index)- avgShardsPerNode(index))
②weight_node(node, index)=shardBalance * (node.numShards()- avgShardsPerNode)
③weight(node, index)= weight_index(node, index)+ weight_node(node, index)
10. Elasticsearch的扩容和减容
(1) Elasticsearch的扩容
①扩容场景
(1)物理资源消耗过大,即ElasticSearch的服务节点的CPU、内存占用率过高、磁盘空间不足
(2)ElasticSearch单实例的索引数据太大,索引的数目达到10亿条或是数据大小达到1TB
②扩容方式
(1)增加EsNode实例
(2)增加节点,在新节点增加EsNode实例
③扩容后,采用自动均衡策略
(2) Elasticsearch的减容
①减容场景
(1)节点需要重新安装操作系统
(2)集群数据量减少
(3)退服场景
②减容方式
(1)在CloudSearch Service管理界面上删除ElasticSearch实例
③减容注意事项
(1)确保要删除的实例上的shard下的replica在其他实例存在
(2)确保要删除的实例上的数据已经迁移到其他节点
11. ElasticSearch索引HBase数据
Elasticsearch索引HBase数据是HBase数据写入的同时,在Elasticsearch建立相应的HBase索引数据。其中索引id与HBase数据的rowkey对应,保证每条索引数据与HBase数据的唯一,实现HBase数据的全文检索
批量索引:针对HBase中已有的数据,通过提交MR任务的形式,将HBase中的全部数据读出,然后在Elasticsearch中建立索引
12. Elasticsearch单节点多实例部署
在同一个节点上部署多个Elasticsearch实例,根据IP和不同的端口号来区分不同的Elasticsearch实例。可以提高单节点CPU、内存和磁盘的利用率,同时提高Elasticsearch的索引和搜索能力
13. Elasticsearch副本自动跨节点分配策略
单节点多实例部署下,多副本时,如果只做到跨实例分配,存在单点故障,增加默认配置cluster.routing.allocation.same shard.host:true即可
14. Elasticsearch的其他特性
(1) HBase全文索引特性:通过建立HBase表和ElasticSearch索引的映射关系,支持索引存储ElasticSearch,而原始数据存储HBase。通过HBase2ES工具离线索引
(2) 加密鉴权特性:对于安全集群,支持对Elasticsearch访问的加密和鉴权
十五、华为大数据平台MRS
1. 华为MRS服务的定义
MRS(MapReduce服务)是一个在华为云上部署和管理Hadoop系统的服务,一键即可部署Hadoop集群
MRS提供租户完全可控的一站式企业级大数据集群云服务,完全兼容开源接口,为客户提供全栈大数据平台,轻松运行Hadoop、Spark、HBase、Kafka、Storm等大数据组件,并具备在后续根据业务需要进行定制开发的能力,帮助企业快速构建海量数据信息处理系统,并通过对海量信息数据实时与非实时的分析挖掘,发现全新价值点和企业商机
2. MRS的优势
(1) 存算分离架构:计算和存储分离,统一数据湖,消除数据孤岛,一份数据,无需多次拷贝,多种计算引擎,存储和计算资源灵活配比,各自按需扩缩,性价比领先业界30%
(2) 领先开源技术:主流引擎Spark、Hive、Flink等深度改造,拥有索引缓存、元数据等关键技术;自研CarbonData毫秒级点查,Superior调度突破单集群20000节点+
(3) 极致性能体验:通过结合硬件、数据组织、计算引擎、AI智能调优四级垂直优化,全栈式性能加速,同时具备百万规模元数据毫秒级响应,为用户提供极致性能体验
(4) 高安全高可用:支持单集群跨AZ高可用,无单点故障,滚动补丁/升级,任务断链重连,业务0中断;具备网络资源隔离、账号安全、数据安全管控等多级安全保障能力
3. MRS的架构
(1) 云原生架构,快速构建数据湖
①易部署:一键式集群申请,半小时级发放
②快速构建:统一入湖;统一元数据管理;统一安全管理
③存算分离,架构领先,计算不足扩计算,存储不足扩存储,更好的扩展和部署高阶服务如DataArts Studio、GES等
(2) 一架三湖,业务场景更丰富
①离线数据湖、实时数据湖、逻辑数据湖
(1)离线数据湖
高性能交互式查询引擎,数据不出湖
统一元数据,数据全局可视
融合分析,湖内统一SQL查询
(2)实时数据湖
时效快:分钟级实时增量入湖,从T+1到T+0
资源利用率高:增量分散入湖,资源利用率提升2倍+
流批一体,批流SQL接口统一
(3)逻辑数据湖
跨湖、跨域、跨仓、全域数据协同分析
减少数据搬迁,数据不动计算动,分析效率提升50倍+
业务上线效率提升10倍(周->天)
②丰富的专题集市:Lakehouse湖内建仓,分析链路短,建设周期快
(1)湖+集市共集群,统一管理,无缝对接
(2)全自助、毫秒级Clickhouse实时OLAP分析
(3)高吞吐、低延迟的时序数据库IoTDB
(3) 持续演进的企业级版本
①多引擎融合分析,分析提效30%
②单集群21K,支持集群联邦
③滚动升级,持续演进,业务不中断
④容灾:两地三中心高可用
4. Hudi
(1) Hudi的定义
Hudi是一种数据湖的存储格式,在Hadoop文件系统之上提供了更新数据和删除数据的能力以及消费变化数据的能力。支持多种计算引擎,提供IUD接口,在 HDFS的数据集上提供了插入更新和增量拉取的流原语
Hudi是数据湖的文件组织层,对Parquet格式文件进行管理提供数据湖能力,支持计算引擎,提供IUD接口
(2) Hudi的主要特性
①通过插拔式索引支持快速Update操作
②数据写入与数据查询支持Snapshot隔离
③基于统计信息管理文件大小和布局支持Timeline
④支持数据回滚
⑤支持数据恢复的Savepoints
⑥异步数据合并
⑦通过clustering机制优化数据湖存储
(3) Hud的架构:批量与实时入湖、兼容多生态组件、存储格式开源
①存储模式
-
COW模式:写时复制,写相对MOR慢,读性能高
-
MOR模式:读时Merge,写性能高,读性能略低
②存储格式
-
存储格式支持开源Parquet、Hfile格式,ORC计划中
③存储引擎
-
支持开源HDFS存储引擎和华为云OBS对象存储
④视图
-
读优化视图、增量视图、实时视图
5. 大数据生态缺乏支持交互式查询、统一SQL访问能力
(1) 业务往往需求亚秒级/秒级交互式分析性能,导致数据多份拷贝
(2) 面对数据组件多样化的数据湖生态,亟需基于大数据生态的统一SQL访问能力
6. HetuEngine
HetuEngine的定义
(1) HetuEngine是华为自研高性能分布式SQL查询&数据虚拟化引擎。与大数据生态无缝融合,实现海量数据秒级查询;支持多源异构协同,使能数据湖内一站式SQL融合分析
①云服务层
②引擎层:计算引擎
③数据层:Hive/HDFS/OBS、ClickHouse、HBase、Elasticsearch、DWS
(2) 跨域
①跨域服务入口
②去中心分布式组网
③GB/s高性能跨域传输
④零元数据同步
⑤数据受控开放
⑥跨域计算下推
⑦极简配置,极速上线
(3) 跨源
①数据虚拟化
②物化视图
③用户级、数据源级UDF
④子查询下推
⑤小表漫游
⑥兼容HQL语法
⑦支持常见BI工具对接
(4) 云原生
①云服务入口
②资源、权限集中运维
③数据源信息可视化定义&即时生效
④弹性伸缩
⑤多实例、多租户
⑥带业务滚动重启
⑦容灾备份
7. Ranger
(1) Ranger的定义
Apache Ranger提供一个集中式安全管理框架,提供统一授权和统一审计能力。它可以对整个Hadoop生态中如HDFS、Hive、HBase、Kafka、Storm等进行细粒度的数据访问控制。用户可以利用Ranger提供的前端WebUl控制台通过配置相关策略来控制用户对这些组件的访问权限
(2) Ranger与其他组件的关系
Ranger为组件提供基于PBAC的鉴权插件,供组件服务端运行,目前支持Ranger鉴权的组件有HDFS、Yarn、Hive、HBase、Kafka、Storm和Spark2x,后续会支持更多组件
8. LDAP和Kerberos
(1) LDAP
LDAP是轻量目录访问协议(Lightweight Directory Access Protocol)的缩写,是一种基于X.500目录访问协议的集中账号管理架构的实现协议标准
华为大数据解决方案中,LdapServer作为目录服务系统,实现了对大数据平台的集中账号管理
LDAP协议的特点:
①LDAP运行在TCP/IP或其他面向连接的传输服务之上
②LDAP同时是一个IETF标准跟踪协议,在“轻量级目录访问协议(LDAP)技术规范路线图”RFC4510中被指定
(2) Kerberos
Kerberos这一名词来源于希腊神话“三个头的狗--地狱之门守护者”,后来沿用作为安全认证的概念,该系统设计上采用客户端/服务器结构与DES、AES等加密技术,并且能够进行相互认证,即客户端和服务器端均可对对方进行身份认证
华为大数据平台中使用KrbServer为所有组件提供了Kerberos功能。为了管理集群中数据与资源的访问控制权限,推荐以安全模式安装集群。在安全模式下,客户端应用程序在访问集群中的任意资源之前均需要通过身份认证,建立安全会话链接。MRS通过KrbServer为所有组件提供Kerberos认证功能,实现了可靠的认证机制
(3) LDAP+Kerberos开源增强特性
①集群内服务认证:在使用安全模式的MRS集群中,任意服务间的相互访问基于Kerberos安全架构方案。集群内某个服务(例如HDFS)在启动准备阶段的时候,会首先在Kerberos中获取该服务对应的服务名称sessionkey(即keytab,用于应用程序进行身份认证)。其他任意服务(如YARN)需要访问HDFS并在HDFS中执行增、删、改、查数据的操作时,必须获取对应的TGT和ST,用于本次安全访问的认证
②应用开发认证:MRS各组件提供了应用开发接口,用于客户或者上层业务产品集群使用。在应用开发过程中,安全模式的集群提供了特定的应用开发认证接口,用于应用程序的安全认证与访问
③跨系统互信特性:MRS提供两个Manager之间的互信功能,用于实现系统之间的数据读、写等操作
9. 华为云Stack Fusionlnsight MRS云原生数据湖基线方案全景图
数据湖:企业内多种格式数据源汇聚的大数据平台,通过严格的数据权限和资源管控,将数据和算力开放给各种使用者,为数据湖。一份数据支持多种分析,是数据湖最大的特点
(1) 离线数据湖:数据从数据源产生后到进入到数据湖存储,无法做到实时,通常超过15分钟,为离线
(2) 实时数据湖:数据从数据源产生后,可以实时进入到数据湖存储,通常1分钟以内,为实时,1到15分钟之内,为准实时
(3) 逻辑数据湖:数据并不是在物理上汇聚到了一个数据平台上,而是若千个物理分开的数据平台形成一个虚拟数据湖,称为逻辑数据湖