当前位置: 首页 > 编程日记 > 正文

【Flink】字节跳动 Flink 基于 Slot 的资源管理实践

在这里插入图片描述

1.概述

转载学习:字节跳动 Flink 基于 Slot 的资源管理实践 仅供自己学习使用。

众所周知,Flink 在提交和运行 Flink 作业时,需要配置 Flink 资源信息,包括 TaskManager 的数量,每个 TaskManager 的 CPU 数、内存大小以及 Slot 数量。TaskManager 的数量,每个 TaskManager 的 CPU 数、内存大小都比较容易理解,主要是配置启动的计算进程数以及每个进程绑定的物理资源大小。

那么 Slot 是什么?为什么需要在 Flink 作业启动时配置?

一言以蔽之,Slot 是 Flink 集群管理资源的最小单位,也是 Flink 作业申请和释放资源的单位。本文主要分析 Flink 基于 Slot 的资源管理、作业资源申请以及释放流程。

阅读提示:字节跳动内部目前主要使用 Flink-1.11 版本,所以本文分析的 Flink Slot 资源管理实现部分内容将基于此版本展开。

2.资源流程分析

Flink 作业在运行过程中,整个 Flink 集群其实分为四个角色节点,分别为 Dispatcher、JobMaster、ResourceManager 以及 TaskManager,其中 Dispatcher、JobMaster 以及 ResourceManager 在同一个进程内启动和执行。

Dispatcher 接收各类查询请求,例如作业的各类 Metrics 等;
JobMaster 是作业的 AM,管理作业的执行状态;
ResourceManager 管理 Flink 集群的资源和资源分配;
TaskManager 管理 Flink 计算任务的执行。

Flink 作业被提交到资源管理器 (Yarn/K8s) 后,资源管理器根据作业所需的资源配置 (多少个 TaskManager,每个 TaskManager 分配多少 CPU / 内存) 为作业分配资源,并启动对应数量的 TaskManager 进程。

TaskManager 进程启动后,向 ResourceManager 节点注册信息,其中最关键的信息就是 Slot。

TaskManager 根据配置的每个 TaskManager 的 Slot 数,向 ResourceManager 汇报 Slot,而在 ResourceManager 节点内维护和管理所有的 Slot 列表。我们可以简单地将 Slot 理解为资源槽,这个资源槽会在 TaskManager 上跟作业具体的计算任务关联。

Slot 是一个逻辑概念,它不会跟具体的 CPU 核数绑定,例如一个 TaskManager 绑定了 N 个 CPU 和配置了 M 个 Slot,N 和 M 之间没有任何关联。

但是 Slot 跟内存资源相关,我们知道 TaskManager 启动时会指定进程的总内存大小,这块的内存会被分为堆内内存、堆外内存,其中堆外内存又被分为 Managed Memory 和 Direct Memory,对具体内存划分有兴趣的小伙伴可以通过 Flink 内存模型详细了解。

这里我们要说的是 Managed Memory,这部分内存不会预先分配,但是会按照 Slot 划分大小。简单来讲,就是将 TaskManager 中 Managed Memory 总大小除以 Slot 的数量,就是每个 Slot 可以使用的 Managed Memory 大小。

TaskManager 的每个 Slot 关联多个计算任务,每个计算任务由独立的 Java 线程执行,所以多个计算线程会跟一个 Slot 关联,也就是多个计算线程会共享一个 Managed Memory 内存。

3.Slot 申请流程

上文提到,TaskManager 根据配置的 Slot 数量,会向 ResourceManager 汇报它上面的 Slot 数据。ResourceManager 节点在内部维护 TaskManager 列表,每个 TaskManager 分别有哪些 Slot 以及目前空闲的 Slot 集合。

Flink 集群中的每个 Flink 作业会有一个 JobMaster 节点,JobMaster 节点将 Flink 作业解析成物理执行计划,向 ResourceManager 申请 Slot 资源,同时管理作业中每个计算任务的执行状态。当一个作业提交到 Flink 集群后,Slot 资源总体申请流程如下图所示。

在这里插入图片描述

  1. TaskManager 向 ResourceManager 汇报 Slot 资源数据;

  2. JobMaster 向 ResourceManager 发起 Slot 资源申请;

  3. ResourceManager 根据 Free Slots 集合为 Slot 申请分配 Slot,然后向 TaskManager 发起资源确认;

  4. TaskManager 在进程内将指定 Slot 标记为指定作业使用,然后向 JobMaster 汇报 Slot 资源分配信息;

  5. JobMaster 接收到 Slot 资源分配信息后,将 Slot 资源跟作业中的计算任务关联;

  6. JobMaster 将计算任务描述信息发送到 Slot 所属的 TaskManager,部署计算任务。

4.ResourceManager

ResourceManager 在 Slot Pool Manager 中管理和维护 TaskManager 以及对应的 Slot 集合,每个 Slot 有三种状态:FREE、PENDING 和 ALLOCATED。

ResourceManager 处理 Slot 申请是一个异步过程,ResourceManager 接收到 Slot 申请后会先将请求放入到 Pending 列表中,然后给这些请求分配 Slot,最后向 TaskManager 发送请求确认资源申请,完成确认后会更新分配的 Slot 状态。主要流程和操作如下图所示。

在这里插入图片描述

5.JobMaster

JobMaster 申请资源也是一个异步申请加回调确认的过程,主要通过 Slot Pool 管理和实现资源申请。

Slot Pool 中管理 4 类 Slot 相关数据结构,分别为 waitingForResourceManager 列表结构、pendingRequests 列表结构、AvailableSlots 结构和 AllocatedSlots 结构。

1、waitingForResourceManager 数据

Flink 作业的 JobMaster 根据每个计算任务,生成一个 Slot 申请请求,并放入到一个 waitingForResourceManager 的请求列表内。这里需要注意的是会有 Slot 共享的问题,如果多个计算任务共享同一个 Slot,那么这些计算任务只会生成一个 Slot 申请请求。

每个 Slot 请求会生成唯一的 AllocationID,该 ID 会由 ResourceManager 发送给 TaskManager,并最终返回给 JobMaster。

当 JobMaster 跟 ResourceManager 建立连接时,从 waitingForResourceManager 中遍历获取每个 Slot 请求,然后逐个向 ResourceManager 发送 Slot 申请,同时将每个 Slot Request 放入到 Pending Request 列表中。

2、PendingRequests 数据

在上文我们提到,JobMaster 向 ResourceManager 发送申请 Slot 请求后,由于 ResourceManager 的异步申请机制,ResourceManager 并不会直接返回申请到的 Slot 数据,所以 JobMaster 会将 Slot 请求放入到 Pending Request 等待回调。

当 JobMaster 接收到 TaskManager 的 offerSlots 请求获取到申请的 Slot 信息时,才真正完成 Slot 的申请,在 offerSlots 请求中包含分配给该作业的 Slot 列表。JobMaster 会遍历每个 offer Slot,执行每个 Slot 的分配操作,具体可以分为以下几个步骤:

  1. 根据上文中每个请求的 AllocationID 从 pendingRequests 中移除指定的 Request;

  2. 通过异步回调,将 Slot 分配给指定的计算任务 (多个计算任务共享,则会分配多个计算任务);

  3. 在 AllocatedSlots 数据结构中增加分配的 Slot 信息。

3、AllocatedSlots 和 AvailableSlots 数据

AllocatedSlots 存放已经被分配给计算任务的 Slot 信息列表,
AvailableSlots 存放还未被分配给计算任务的 Slot 信息列表。

由于存在超时重新申请等异常情况,例如 JobMaster 申请 Slot 超时重新发起申请请求,所以存在 TaskManager 向 JobMaster 返回的 offerSlots 根据 AllocationID 在 pendingRequests 中找不到对应请求,或者在 LazyFromSource 过程中上游计算任务执行完成需要释放 Slot 等情况,所以会将这些未被分配的 Slot 放入到 AvailableSlots 中。

当作业需要新的 Slot 分配给指定的计算任务时,会优先从 AvailableSlots 中查找 Slot 资源,只有未找到才会向 ResourceManager 发起请求。

在 AvailableSlots 中的每个 Slot 会带有一个时间戳,后台线程会定时检查 AvailableSlots 中的每个 Slot,如果时间戳和当前时间超过一定阈值,该 Slot 会被主动释放掉,避免资源泄漏。

在这里插入图片描述

上述流程主要基于 1.11 版本分析 Slot 资源申请流程,在最新发布的 1.14 版本中 Flink 实现了 Declarative 资源申请,总体流程也是走 JM->RM->TM,但是具体实现有比较大的简化。

6.TaskManager

TaskManager 中有两个数据结构跟作业申请资源相关:TaskSlotTable 和 JobTable。TaskSlotTable 管理 TaskManager 中的 Slot 以及跟计算任务之间的关系,主要包含以下几类数据:

  1. TaskManager 中的 Slot 数量;

  2. taskSlots,根据 Slot 索引号管理该 Slot 的状态 (TaskSlot),TaskSlot 里包含该 Slot 的计算任务列表等数据;

  3. allocatedSlots,根据 AllocationID 管理该 Slot 的状态 (TaskSlot);

  4. taskSlotMappings,根据计算任务的 ID (ExecutionAttemptID) 管理计算任务和 TaskSlot;

  5. slotsPerJob,根据 JobID 管理属于该 Job 的 AllocationID 集合。

JobTable 管理和 JobMaster 的连接信息,当 TaskManager 获取到指定作业的 Slot 申请时,根据 JobMaster 的地址跟 JobMaster 创建连接,向 JobMaster 注册,并将连接信息保存到 JobTable 中。

TaskManager 在接收到 ResourceManager 发送过来的 Slot 申请后,会对 Slot 申请进行处理并更新 TaskSlotTable,在这个过程中会将 Slot 申请加入到定时检查中,释放超时未分配成功的 Slot 资源。具体流程如下图所示。

在这里插入图片描述
这里比较重要的一个流程是接收到指定作业的 Slot 申请后,会跟作业创建连接,然后将 TaskManager 注册到 JobMaster,JobMaster 接收到注册信息后会跟 TaskManager 创建连接和心跳监控,TM 和 JM 的心跳只监控连通性,相关流程如下图所示。

在这里插入图片描述

7.计算任务部署流程

JobMaster 将 Slot 资源分配给计算任务后,生成计算任务的部署信息,部署信息里包含作业信息、计算任务信息、上下游 Shuffle 信息以及计算任务所部署的 Slot 索引号信息等,然后 JobMaster 将部署信息发送给指定的 TaskManager。

TaskManager 接收到计算任务部署信息后,对计算任务进行校验、部署和执行,这个过程涉及到 TaskSlotTable 以及 JobTable 操作,具体流程如下图所示。

在这里插入图片描述
TaskSlot 有三个状态:

ACTIVE:正在被指定的作业使用;
ALLOCATED:创建时的初始状态,为某个作业创建,但是还没被使用;
RELEASING:正在被释放中。

在 TaskSlot 创建时,会初始化一个 MemoryManager,管理 Slot 中所有计算任务申请和释放 Managed Memory,共用 TaskSlot 的所有计算任务共享 MemoryManager,TaskSlot 管理了所有在上面运行的 Task 列表。

7.1 任务结束和 Slot 释放

TaskManager 中的计算任务完成计算后,会释放该计算任务申请和使用的资源,涉及到 Slot 相关的主要以下几个操作:

  1. 释放 MemoryManager 中指定计算任务申请的内存分片;
  2. 从 TaskSlotTable 中移除管理的计算任务。

完成上述操作后,会向 JobMaster 发送计算任务更新。JobMaster 收集到所有计算任务的更新消息后,完成作业执行并跟 ResourceManager 断开连接,然后遍历申请到的 Slot 并向指定的 TaskManager 发送资源释放请求。

TaskManager 接受到 Slot 释放请求后,会从 TaskSlotTable 移除指定的 Slot 信息并向 ResourceManager 释放 Slot 信息,如果作业所有 Slot 都被删除,会关闭跟 JobMaster 的连接。TaskManager 处理的总体流程如下图所示。

在这里插入图片描述
ResourceManager 接收到指定 Slot 释放请求后,会从资源申请列表中查找与该 Slot 匹配的申请请求并处理,若申请列表没有请求则将 Slot 放入到空闲 Slot 列表中。

8.资源管理优化

开源社区在 1.11 版本之后,对资源申请和释放流程具体的代码实现做过比较大的重构和优化。在资源管理和流程实现上,主要是支持细粒度资源管理 (FLIP-56: Dynamic Slot Allocation - Apache Flink - Apache Software Foundation) 和声明式资源申请 (FLIP-138: Declarative Resource management - Apache Flink - Apache Software Foundation)。

9.细粒度资源管理

在上文我们提到,TaskManager 会将 ManagedMemory 会按照里面的 Slot 进行等分,这会带来资源浪费。

作业的每个计算节点都可以设置不同的并发度,所以每个 Slot 内部执行的计算任务类型和数量有可能是不同的。这意味着每个 Slot 的计算任务所需的内存资源会存在比较大的不同,比如有些 Slot 有 Join 等计算任务,有些 Slot 没有。

原先按照 Slot 平均划分内存大小的方式会造成资源浪费,为了提升资源使用率,从 Flink 1.14 版本开始支持细粒度资源申请

JobMaster 向 ResourceManager 申请 Slot 时,会向 ResourceManager 指定资源数量,包括 CPU、内存等。ResourceManager 根据当前维护的资源列表,为作业分配指定资源的 Slot,同时向指定的 TaskManager 发送请求。TaskManager 接收到带有资源信息的 Slot 申请后,会创建 Slot,并向 JobMaster 确认资源申请。

所以从 Slot 总体申请流程上,新版本跟原先的处理是相同的,这块主要是支持在 Slot 申请时带上相应的资源信息,ResourceManager 会根据管理的 TaskManager 剩余资源信息为计算任务分配 TaskManager。

10.声明式资源申请

在上面的 Slot 申请流程中,一个 Flink 作业会申请若干个 Slot 资源,但是在申请过程中是按照单个 Slot 独立申请的。Flink 作业,特别是流式作业,通常需要完成所有所需的 Slot 资源申请后,作业才能正常运行。

所以在 Flink 新版本中支持了声明式资源申请,JobMaster 向 ResourceManager 申请资源时,会将所需的多个 Slot 打包成一个 Batch,向 ResourceManager 发起资源申请。

ResourceManager 接收到作业的多个 Slot 申请后,会处理 SlotManager 中管理的资源,然后根据 Slot 逐个向指定的 TaskManager 发起资源请求。

每个作业所需的 Slot 数量,目前是在 JobMaster 资源申请时进行打包处理,后续可能会根据 JobGraph 执行计划中每个计算节点的并发度直接计算。

11.总结

总体上来讲,Flink 整个资源管理、申请和分配围绕 Slot 展开,同时每个 TaskManager 中的 Slot 数量决定了作业在该 TaskManager 中运行的并发计算任务数量。

本篇文章主要介绍了 Slot 对资源分配、释放以及计算执行的影响,希望可以帮助大家更好地决策每个 TaskManager 中的 Slot 数量,对 Flink 作业进行调优。

目前,字节跳动流式计算团队同步支持的火山引擎流式计算 Flink 版正在公测中,支持云中立模式,支持公共云、 混合云 及多云部署,全面贴合企业上云策略,欢迎申请试用:www.volcengine.com/product/flink

相关文章:

Springboot整合HBase——大数据技术之HBase2.x

Apache HBase 是以hdfs为数据存储的,一种分布式、可扩展的noSql数据库。是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统,利用HBase技术可在廉价PC Server上搭建起大规模结构化存储集群。HBase使用与BigTable(BigTable是一个稀疏的、分布式的、持久化的多维排序map)非常相似的数据模型。用户将数据行存储在带标签的表中。数据行具有可排序的键和任意数量的列。该表存储稀疏,因此如果用户喜欢,同一表中的行可以具有疯狂变化的列。

终于有人把Web 3.0和元宇宙讲明白了

分散的数据网络使个人数据(例如个人的健康数据、农民的作物数据或汽车的位置和性能数据)出售或交换成为可能,与此同时,不会失去对数据的所有权控制、放弃数据隐私或依赖第三方平台来管理数据。Web 3.0的目标是在创作者经济中取得更好的平衡。互联网第二次迭代(Web 2.0)的缺陷,加上公有区块链技术的诞生,帮助我们朝着更加去中心化的Web 3.0 迈进,元宇宙和更广泛的去中心化网络都是关于现实世界和虚拟世界的融合。此时的网络中不再是静态内容,而是动态的内容,用户现在可以与发布在网络上的内容进行交互。

万字详解数据仓库、数据湖、数据中台和湖仓一体

数字化转型浪潮卷起各种新老概念满天飞,数据湖、数据仓库、数据中台轮番在朋友圈刷屏,有人说“数据中台算个啥,数据湖才是趋势”,有人说“再见了数据湖、数据仓库,数据中台已成气候”……企业还没推开数字化大门,先被各种概念绊了一脚。那么它们 3 者究竟有啥区别?别急,先跟大家分享两个有趣的比喻。1、图书馆VS地摊如果把数据仓库比喻成“图书馆”,那么数据湖就是“地摊”。去图书馆借书(数据),书籍质量有保障,但你得等,等什么?等管理员先查到这本书属于哪个类目、在哪个架子上,你才能精准拿到自己想要的书;

什么是数据中台?

说完了数据中台诞生的历史背景,现在,我们应该对数据中台有了一定的了解,那我们现在给数据中台下个定义。自2016年,数据中台被提出以来,不同的人对数据中台有不同的理解,就像一千个读者心中有一千个哈姆雷特,因此也有许多不同的定义,以下是我从一些文章、书籍中搜集到的关于数据中台的定义:数据中台是DT时代的大背景下,为实现数据快(快速)、准(准确)、省(低成本)赋能业务发展的目标,将企业的数据统一整合起来,基于Onedata方法论借助大数据平台完成数据的统一加工处理,对外提供数据服务的一套机制。

Git 的基本概念、使用方式及常用命令

Git的基本概念、使用方式及常用命令

怎么选择数据安全交换系统,能够防止内部员工泄露数据?

数据泄露可能给企业带来诸多风险:财产损失、身份盗窃、骚扰和诈骗、经济利益受损、客户信任度下降、法律风险和责任等,《2021年度数据泄漏态势分析报告》中显示,在数据泄露的主体中,内部人员导致的数据泄漏事件占比接近60%。飞驰云联文件安全交换系统,可以满足企业多场景下的文件交换需求,帮助企业终结多工具、 多系统并行使用的局面,减少因文件交换行为分散带来的数据管理不集中、难以管控的问题, 帮助企业内部构建统一、安全的企业数据流转通道。对于不能下载保存的数据,使用截屏、录屏的方式窃取并外泄数据;

弹性搜索引擎Elasticsearch:本地部署与远程访问指南

本文主要讲解如何使用Elasticsearch分布式搜索分析引擎本地部署与远程访问。

Hive(总)看完这篇,别说你不会Hive!

Hive:由Facebook开源用于解决海量结构化日志的数据统计。Hive是基于Hadoop的一个数据仓库工具,可以将结构化的数据文件映射为一张表,并提供类SQL查询功能。本质是:将HQL转化成MapReduce程序1)Hive处理的数据存储在HDFS2)Hive分析数据底层的实现是MapReduce3)执行程序运行在Yarn上创建一个数据库,数据库在HDFS上的默认存储路径是/opt/hive/warehouse/*.db避免要创建的数据库已经存在错误,增加if not exists判断。

什么是HBase?终于有人讲明白了

在 HBase 表中,一条数据拥有一个全局唯一的键(RowKey)和任意数量的列(Column),一列或多列组成一个列族(Column Family),同一个列族中列的数据在物理上都存储在同一个 HFile 中,这样基于列存储的数据结构有利于数据缓存和查询。HBase Client 为用户提供了访问 HBase 的接口,可以通过元数据表来定位到目标数据的 RegionServer,另外 HBase Client 还维护了对应的 cache 来加速 Hbase 的访问,比如缓存元数据的信息。

数据仓库系列:StarRocks 入门培训教程

StarRocks 是一款MPP DB, 对标ClickHouse、Vertica、Teradata、Greenplum,在查询性能上远超当代最快的开源数据库 clickhouse,目前已经被一众互联网企业在生产环境中采用。提供千亿级大数据的在线多维分析和分布式存储。新一代极速全场景 MPP (Massively Parallel Processing) 数据库是forkdoris后独立运营的商业化版本StarRocks。

ClickHouse & StarRocks 使用经验分享

总结一下,如果是需要分析日志流数据,更加推荐 ClickHouse ,因为 ClickHouse 单机强悍,可以支撑亿级别数据量,架构简单,相比于 StarRocks 也更加稳定,相比集群,更推荐单机 ClickHouse。如果是分析业务流数据,更加推荐 StarRocks ,因为 StarRocks 对于更新场景性能更加,而且 JOIN 性能更好,而且更加推荐部署 StarRocks 集群,可以充分发挥 StarRocks 的性能。

大数据Hadoop、HDFS、Hive、HBASE、Spark、Flume、Kafka、Storm、SparkStreaming这些概念你是否能理清?

hive是基于Hadoop的一个数据仓库工具,用来进行数据提取、转化、加载,这是一种可以存储、查询和分析存储在Hadoop中的大规模数据的机制。Hadoop是大数据开发的重要框架,是一个由Apache基金会所开发的分布式系统基础架构,其核心是HDFS和MapReduce,HDFS为海量的数据提供了存储,MapReduce为海量的数据提供了计算,在Hadoop2.x时 代,增加 了Yarn,Yarn只负责资 源 的 调 度。当计算模型比较适合流式时,storm的流式处理,省去了批处理的收集数据的时间;

HDFS对比HBase、Hive对比Hbase

Hive和Hbase是两种基于Hadoop的不同技术Hive是一种类SQL的引擎,并且运行MapReduce任务Hbase是一种在Hadoop之上的NoSQL的Key/value数据库这两种工具是可以同时使用的。就像用Google来搜索,用FaceBook进行社交一样,Hive可以用来进行统计查询,HBase可以用来进行实时查询,数据也 可以从Hive写到HBase,或者从HBase写回Hive。

ClickHouse 与mysql等关系型数据库对比

先用一张图帮助理解两者的本质上的区。

牢牢把握“心价比”,徕芬的业绩爆发是一种必然?

业绩突破背后也有消费复苏的激励作用,但具体到电吹风市场,竞争态势在持续加剧,且有戴森这样的国外品牌盘踞于此。徕芬究竟是如何越走越稳的?

java中如何使用elasticsearch—RestClient操作文档(CRUD)

去数据库查询酒店数据,导入到hotel索引库,实现酒店数据的CRUD基本步骤如下。新建一个测试类,实现文档相关操作,并且完成JavaRestClient的初始化。方式一(全量更新):再次写入id一样的文档,就会删除旧文档,添加新文档。根据id查询到的文档数据是json,需要反序列化为java对象。(2)根据id查询数据库数据,并转换。方式二(局部更新):只更新部分字段。(1)创建文档对应实体。修改文档数据有两种方式。

获得JD商品评论 API 如何实现实时数据获取

随着互联网的快速发展,电商平台如雨后春笋般涌现,其中京东(JD)作为中国最大的自营式电商平台之一,拥有庞大的用户群体和丰富的商品资源。为了更好地了解用户对商品的反馈,京东开放了商品评论的API接口,允许开发者实时获取商品评论数据。本文将介绍如何通过JD商品评论API实现实时数据获取,并给出相应的代码示例。JD商品评论API提供了一系列的接口,允许开发者根据需要获取不同维度的评论数据。通过该API,开发者可以获取到商品的详细评论信息、评论的统计数据以及用户的评论行为数据等。

基于神经网络——鸢尾花识别(Iris)

鸢尾花识别是学习AI入门的案例,这里和大家分享下使用Tensorflow2框架,编写程序,获取鸢尾花数据,搭建神经网络,最后训练和识别鸢尾花。

深度学习知识点全面总结

深度学习定义:一般是指通过训练多层网络结构对未知数据进行分类或回归深度学习分类:有监督学习方法——深度前馈网络、卷积神经网络、循环神经网络等;​ 无监督学习方法——深度信念网、深度玻尔兹曼机,深度自编码器等。深度神经网络的基本思想是通过构建多层网络,对目标进行多层表示,以期通过多层的高层次特征来表示数据的抽象语义信息,获得更好的特征鲁棒性。神经网络的计算主要有两种:前向传播(foward propagation, FP)作用于每一层的输入,通过逐层计算得到输出结果;

光伏发电模式中,分布式和集中式哪种更受欢迎?

5.可实现远距离输送,集中式光伏电站发出的电经高压并网,将电一层层的输送到更高的电压等级,如将高压电输送到华东等地区,以实现西电东输。分布式光伏发电:一般建在楼顶、屋顶、厂房等地方,较多的是基于建筑物表面,就近解决用户的用电问题,通过并网实现供电差额的补偿与外送。1.光伏电源处于用户侧,自发自用,就近发电,就近用电,发电供给当地负荷,视作负载,可以减少对电网供电的依赖,减少线路损耗。4.分布式光伏一般就近并网,线路的损耗很低或者可以说没有,可非常方便的补充当地的电量,供当地及附近的用电用户使用。

深度学习与神经网络

神经网络是一种模拟人脑神经元行为的计算模型,神经网络由大量的神经元(在计算领域中常被称为“节点”或“单元”)组成,并且这些神经元被分为不同的层,分别为输入层、隐藏层和输出层。每一个神经元都与前一层的所有神经元相连接,连接的强度(或权重)代表了该连接的重要性。神经元接收前一层神经元的信息(这些信息经过权重加权),然后通过激活函数(如Sigmoid、ReLU等)处理,将结果传递到下一层。输入层接收原始数据,隐藏层负责处理这些数据,而输出层则将处理后的结果输出。

一篇文章讲清楚!数据库和数据仓库到底有什么区别和联系?

数据库的数据来源来自各种业务系统软件程序的产生的数据,或者是由和这些业务系统软件交互的用户产生的数据,而数据仓库的数据来源则直接是这些业务系统的一个或者多个数据库或者文件,比如 SQL Server、Oracle、MySQL、Excel、文本文件等。也可以简单理解为很多个业务系统的数据库往数据仓库输送数据,是各个数据库的集合体,一个更大的数据库,数据仓库的建立是要打通这些基础数据库的数据的。所以,业务系统的数据库更多的是增删改操作,而数据仓库更多的是查询操作,这就决定了建模方式会有很大的差异。

一文读懂数据仓库、数据湖、湖仓一体

一个数据湖可以存储结构化数据(如关系型数据库中的表),半结构化数据(如CSV、日志、XML、JSON),非结构化数据(如电子邮件、文档、PDF)和二进制数据(如图形、音频、视频)。这套架构,以数据湖为中心,把数据湖作为中央存储库,再围绕数据湖建立专用“数据服务环”,环上的服务包括了数仓、机器学习、大数据处理、日志分析,甚至RDS和NOSQL服务等等。从数据含金量来比,数据仓库里的数据价值密度更高一些,数据的抽取和Schema的设计,都有非常强的针对性,便于业务分析师迅速获取洞察结果,用与决策支持。

绝地求生电脑版的最低配置要求?

更好的方式是通过官方的渠道购买游戏账号,并遵守游戏的规则和使用协议,以保证自己的游戏体验和账号安全性。但请注意,游戏的配置要求可能随着游戏的更新而有所改变,建议您在购买或升级电脑时,参考官方的配置要求以获得最佳游戏体验。如果您的电脑配备了更高性能的处理器,游戏的运行体验将更为流畅。绝地求生是一款较为复杂的游戏,需要较大的内存来加载游戏资源并确保游戏的流畅运行。所以在安装游戏之前,确保您的电脑有足够的存储空间。这些推荐配置可以使您在绝地求生中获得更高的帧率和更好的画面表现,提供更加顺畅和逼真的游戏体验。

什么是 ClickHouse(实时数据分析数据库)

1、ClickHouse是俄罗斯搜索巨头 Yandex 公司早 2016年 开源的一个极具 " 战斗力 " 的实时数据分析数据库,开发语言为C++2、是一个用于联机分析OLAP:Online Analytical Processing) 的列式数据库管理系统(DBMS:Database Management System),简称CK3、工作速度比传统方法快100-1000倍,ClickHouse 的性能超过了目前市场上可比的面向列的DBMS。每秒钟每台服务器每秒处理数亿至十亿多行和数十千兆字节的数据。

数据仓库介绍

​ 1、什么是数据仓库?​ 存储数据的仓库, 主要是用于存储过去既定发生的历史数据, 对这些数据进行数据分析的操作, 从而对未来提供决策支持​ 2、数据仓库最大的特点:​ 既不生产数据, 也不消耗数据, 数据来源于各个数据源​ 3、数据仓库的四大特征:​ 1) 面向于主题的: 面向于分析, 分析的内容是什么 什么就是我们的主题​ 2) 集成性: 数据是来源于各个数据源, 将各个数据源数据汇总在一起。

【Flink】官宣|Apache Flink 1.17 发布公告

仅供自己学习。因为我们开始用Flink 17了。Apache Flink PMC(项目管理委员)很高兴地宣布发布 Apache Flink 1.17.0。Apache Flink 是领先的流处理标准,流批统一的数据处理概念在越来越多的公司中得到认可。得益于我们出色的社区和优秀的贡献者,Apache Flink 在 Apache 社区中一直保持着快速增长,并且是最活跃的社区之一。

【Flink】如何在 Flink 中规划 RocksDB 内存容量?

主要是自己学习。本文描述了一些配置选项,这些选项将帮助您有效地管理规划 Apache Flink 中 RocksDB state backend 的内存大小。在前面的文章 [1] 中,我们描述了 Flink 中支持的可选 state backend 选项,本文将介绍跟 Flink 相关的一些 RocksDB 操作,并讨论一些提高资源利用率的重要配置。

【redis】Redis 架构演化之路

里面大致说了redis的架构演进。开始学redis架构的时候,总是感觉架构好多,迷迷糊糊的,但是你知道Redis 架构演化之路之后,就明白了前因后果,这样学习更加深入以及搞笑。这篇文章我想和你聊一聊 Redis 的架构演化之路。现如今 Redis 变得越来越流行,几乎在很多项目中都要被用到,不知道你在使用 Redis 时,有没有思考过,Redis 到底是如何稳定、高性能地提供服务的?如果你对 Redis 已经有些了解,肯定也听说过。

Elasticsearch分布式搜索分析引擎本地部署与远程访问

本文主要讲解如何使用Elasticsearch分布式搜索分析引擎本地部署与远程访问