KubeEdge 架构与核心理念
一、简介随着5G通信的商用,万物互联时代快速到来,网络边缘的设备数量、产生的数据爆发增长,集中式的数据中心(包括公有云服务)将面临实时性、带宽、能耗、数据隐私的挑战,越来越多的场景需要应用边缘计算。
KubeEdge 是华为云开源的云原生边缘计算平台项目,将 Kubernetes 原生的容器编排和调度能力拓展到边缘,并为边缘应用部署、云与边缘间的元数据同步、边缘设备管理等提供基础架构支持。KubeEdge 于2019年3月正式进入CNCF成为沙箱级项目(Sandbox),也成为 CNCF 首个云原生边缘计算项目,并于 2020年9月晋级为孵化项目。
1.1. 核心理念1.1.1. 云边可靠协同双向多路复用消息通道,支持边缘节点位于私有网络
Websocket + 消息封装,大幅减少通信压力,高时延下仍可正常工作
云边消息校验,网络不稳定时不丢数据
1.1.2. 边缘离线自治节点元数据持久化,实现节点级离线自治
节点故障恢复无需List-watch,降低网络压力,快速ready
1.1.3. 边缘极致轻量重组Kubelet功能模块,极致轻量化(~70mb内存占用)
支持CRI集成Cont ...
数仓平台架构演进
数据仓库是⼀个各种数据的中⼼存储系统(包括历史数据和当前数据),是BI的核⼼组件。这⾥所说的数据包括来⾃ 企业内部的各种业务数据,例如订单、库存、交易流、账⽬、客户、供应商等,同时也包括从外部获取的各种数 据,例如爬⾍通过合法⼿段爬取得数据。
一、数仓概述1.1. 数仓&BI商业智能通常被理解为将企业中现有的数据转化为知识,帮助企业做出合理的、明智的经营决策的⼯具,是企业数 字化转型的关键系统。为了将数据转化为知识,需要利⽤数据仓库、联机分析处理(OLAP)⼯具和数据挖掘等技术。
1.2. OLTP vs OLAP1.2.1. OLTPOLTP(Online Transaction Process) 联机事务处理,侧重于数据库的增删查改等常⽤业务操作,强调事物和并发。
1.2.2. OLAPOLAP(Online Analytical Process) 联机分析处理,即以多维的⽅式分析数据,强调磁盘IO吞吐,⼀般采⽤分区技术、并⾏处理技术。 OLAP是⼀种软件技术,它使分析⼈员能够迅速、⼀致、交互式的从各⽅⾯观察数据,以达到深⼊理解数据的⽬ 的。从各⽅⾯观察数据,也 ...
基于Hudi的湖仓一体化解决方案
数据湖是⼀个以原始格式(通常是对象块或⽂件)存储数据的系统或存储库。数据湖通常是所 有企业数据的单⼀存储。⽤于报告、可视化、⾼级分析和机器学习等任务。数据湖可以包括来⾃关系数据库的结构 化数据(⾏和列)、半结构化数据(CSV、⽇志、XML、JSON)、⾮结构化数据(电⼦邮件、⽂档、pdf)和⼆进制数据(图 像、⾳频、视频)
原始格式:数据不做预处理,保存数据的原始状态
单⼀存储:存储库中会汇总多种数据源,是⼀个单⼀库
⽤于机器学习:除了 BI 、报表分析,数据湖更适⽤于机器学习
一、概述1.1. OLTP -> OLAP -> HTAP -> 数据湖
概念
场景
典型代表
主要优缺点
数据库
OLTP
三大数据库(Oracle、 MySQL、SQLServer)
OLTP支持的非常好, OLAP支持弱
数据仓库
OLAP
Teradata、Greenplum、 Hive+HDFS、ClickHouse、 Kylin
OLAP支持非常好,OLTP 不支持或者支持的弱
混合数据库
HTAP=OLTP+OLAP
Kudu(先OLAP在OLTP) ...
Flink-源码-Graph演变-ExecutionGraph构建
JobManager 根据 JobGragh 生成 ExecutionGragh, ExecutionGragh 是 JobGragh 的并行化版本,是调度层最核心的数据结构。来到 ExecutionGraph 构建源码分析~,有点难~~~
一、概述JobManager 根据 JobGragh 生成ExecutionGragh, ExecutionGragh是JobGragh的并行化版本,是调度层最核心的数据结构,每个 ExecutionGraph 都有一个与其相关联的作业状态。此作业状态指示作业执行的当前状态
ExecutionJobVertex
和 JobGraph 中的 JobVertex一一对应。每一个 ExecutionJobVertex 都有和并发度一样多的 ExecutionVertex。
ExecutionVertex
表示 ExecutionJobVertex 的其中一个并发子任务,输入是ExecutionEdge,输出是 IntermediateResultPartition。
IntermediateResult
和JobGraph中的Inte ...
Flink-源码-Graph演变-JobGraph构建
JobGraph 数据结构在本质上是将节点和中间结果集相连得到有向无环图。JobGraph 是客户端和运行时之间进行作业提交使用的统一数据结构,不管是流式 (StreamGraph) 还是批量 (OptimizerPlan),最终都会转换成集群接受的 JobGraph 数据结构。
一、概述StreamGraph 经过优化后生成了 JobGraph,提交给 JobManager 的数据结构它包含的主要抽象概念有:
Jobvertex
经过优化后符合条件的多个 StreamNode 可能会 chain 在一起生成一个 Jobvertex, 即一个 JobVertex 包含一个或多个 operator, JobVertex 的输入是 JobEdge,输出是 IntermediateDataSet。
IntermediateDataSet
表示 JobVertex 的输出,即经过 operator 处理产生的数据集。producer 是 Jobvertex, consumer 是 JobEdge
JobEdge
代表了job graph中的一条数据传输通道。sour ...
Flink-源码-Graph演变-StreamGraph构建
根据用户通过 Stream API 编写的代码,从 Source 节点开始,每一次 transform 生成一个 StreamNode,两个 StreamNode 通过 StreamEdge 连接在一起,形成 DAG
StreamNode 用来代表 operator 的类,并具有所有相关的属性,如并发度、入边和出边等。
StreamEdge表示连接两个StreamNode的边。
一、概述StreamGraph 结构是由 StreamGraphGenerator 通过 Transformation 集合转换而来的,StreamGraph 实现了Pipeline的接口,且通过有向无环图的结构描述了 DataStream 作业的拓扑关系。StreamGraph结构包含 StreamEdge 和 StreamNode 等结构,此外,StreamGraph结构还包含任务调度模式 ScheduleMode 及 TimeCharacteristic 时间概念类型等与作业相关的参数。
StreamGraph 中存储了这个 StreamGraph 中的所有 StreamNode, 在 ...
Flink CDC 2.0
CDC 的全称是 Change Data Capture ,在广义的概念上,只要是能捕获数据变更的技术,我们都可以称之为 CDC 。目前通常描述的 CDC 技术主要面向数据库的变更,是一种用于捕获数据库中数据变更的技术。CDC 技术的应用场景非常广泛:
数据同步:用于备份,容灾;
数据分发:一个数据源分发给多个下游系统;
数据采集:面向数据仓库 / 数据湖的 ETL 数据集成,是非常重要的数据源。
一、CDC 概述CDC 的技术方案非常多,目前业界主流的实现机制可以分为两种:
1.1. 基于查询的 CDC
离线调度查询作业,批处理。把一张表同步到其他系统,每次通过查询去获取表中最新的数据;
无法保障数据一致性,查的过程中有可能数据已经发生了多次变更;
不保障实时性,基于离线调度存在天然的延迟。
1.2. 基于日志的 CDC:
实时消费日志,流处理,例如 MySQL 的 binlog 日志完整记录了数据库中的变更,可以把 binlog 文件当作流的数据源;
保障数据一致性,因为 binlog 文件包含了所有历史变更明细;
保障实时性,因为类似 binlog 的日志文件是可以流式 ...
Flink-源码-Graph演变
一个 Flink 流式作业,从 Client 提交到 Flink 集群,到最后执行,总共会经历四种不同的状态。总的来说:
Client 首先根据用户编写的代码生成 StreamGraph,然后把 StreamGraph 构建成 JobGraph 提 交给 Flink 集群主节点
然后启动的 JobMaster 在接收到 JobGraph 后,会对其进行并行化生成 ExecutionGraph 后调度 启动 StreamTask 执行。
StreamTask 并行化的运行在 Flink 集群,就是最终的物理执行图状态结构。
一、概述Flink 中的执行图可以分成四层:StreamGraph ==> JobGraph ==> ExecutionGraph ==> 物理执行图。
StreamGraph
根据用户通过 Stream API 编写的代码生成的最初的图。用来表示程序的拓扑结构。
JobGraph
StreamGraph 经过优化后生成了 JobGraph,提交给 JobManager 的数据结构。主要的优化为,将多个符合条件的节点 chain 在一起 ...
JIT
Java 的源代码文件变成计算机可执行的机器指令的过程中,需要经过两段编译,第一段是把.java文件转换成.class文件。第二段编译是把.class转换成机器指令的过程。
第一段编译就是 $javac$ 命令。在第二编译阶段,JVM 通过解释字节码将其翻译成对应的机器指令,逐条读入,逐条解释翻译。很显然,经过解释执行,其执行速度必然会比可执行的二进制字节码程序慢很多, 为了解决这种效率问题,引入了 JIT(即时编译) 技术。
引入了 JIT 技术后,Java程序还是通过解释器进行解释执行,当JVM发现某个方法或代码块运行特别频繁的时候,就会认为这是“热点代码”。然后 JIT 会把部分 热点代码 翻译成本地机器相关的机器码,并进行优化,然后再把翻译后的机器码缓存起来,以备下次使用。
HotSpot VM 采用解释器与即时编译器并存的架构。在 Java 虚拟机运行时,解释器和即时编译器能够相互协作,尽力去选择最合适的方式来权衡编译本地代码的时间和直接解释执行代码的时间。
1. 编译器分类HotSpot 虚拟机中内置了两个 JIT 编译器: Client Complier 和 Serve ...
三色标记法
垃圾回收器其主要的目的是为了实现内存的回收,在这个过程中主要的两个步骤就是:内存标记,内存回收。
一、简介三色标记法,主要是为了高效的标记可被回收的内存块。从 GC Roots 开始进行遍历访问,可达的则为存活对象。将遍历对象图过程中遇到的对象,按 “是否访问过” 这个条件把对象标记成以下三种颜色:
白色:尚未访问过
黑色:本对象已访问过,而且本对象引用到的其他对象 也全部访问过了
灰色:本对象已访问过,但是本对象引用到的其他对象 尚未全部访问完。全部访问后,会转换为黑色
假设现在有白、灰、黑三个集合,其遍历访问过程为:
初始时,所有对象都在 白色集合 中
将 $GC\ Roots$ 直接引用到的对象挪到 灰色集合中
从灰色集合中获取对象
将本对象引用到的其他对象全部挪到灰色集合中
将本对象挪到 黑色集合 里面
重复步骤 $3$,直至灰色集合为空时结束。
结束后,仍在白色集合的对象即为 $GC\ Roots$ 不可达,可以进行回收。
注:如果标记结束后对象仍为白色,意味着已经“找不到”该对象在哪了,不可能会再被重新引用。
三色标记算法可能出现对象多标与漏标。所谓 ...