2 月 2023 - Page 4 of 5

Ceph 基础简介

ceph是⼀种分布式存储系统，可以将多台服务器组成⼀个超⼤集群，把这些机器中的磁盘资源整合到⼀块⼉，形成⼀个⼤的资源池（⽀持PB级别），然后按需分配给客户端应⽤使⽤ ,Ceph项目最早起源于Sage就读博士期间的工作（最早的成果于2004年发表），并随后贡献给开源社区。

Ceph项目最早起源于Sage就读博士期间的工作（最早的成果于2004年发表），并随后贡献给开源社区。在经过了数年的发展之后，目前已得到众多云计算厂商的支持并被广泛应用。RedHat及OpenStack都可与Ceph整合以支持虚拟机镜像的后端存储。随着OpenStack的快速发展，越来越多的人使用Ceph作为OpenStack的底层共享存储

Ceph是什么？

ceph是⼀种分布式存储系统，可以将多台服务器组成⼀个超⼤集群，把这些机器中的磁盘资源整合到⼀块⼉，形成⼀个⼤的资源池（⽀持PB级别），然后按需分配给客户端应⽤使⽤。

DAS 直连存储服务器使用 SCSI 或 FC 协议连接到存储阵列、通过 SCSI 总线和 FC 光纤协议类型进行数据传输；例如一块有空间大小的裸磁盘：/dev/sdb。DAS存储虽然组网简单、成本低廉但是可扩展性有限、无法多主机实现共享、目前已经很少使用了。

NAS网络存储服务器使用TCP网络协议连接至文件共享存储、常见的有NFS、CIFS协议等；通过网络的方式映射存储中的一个目录到目标主机，如/data。NAS网络存储使用简单，通过IP协议实现互相访问，多台主机可以同时共享同一个存储。但是NAS网络存储的性能有限，可靠性不是很高。

SAN存储区域网络服务器使用一个存储区域网络IP或FC连接到存储阵列、常见的SAN协议类型有IP-SAN和FC-SAN。SAN存储区域网络的性能非常好、可扩展性强；但是成本特别高、尤其是FC存储网络：因为需要用到HBA卡、FC交换机和支持FC接口的存储。

Object Storage对象存储通过网络使用API访问一个无限扩展的分布式存储系统、兼容于S3风格、原生PUT/GET等协议类型。表现形式就是可以无限使用存储空间，通过PUT/GET无限上传和下载。可扩展性极强、使用简单，但是只使用于静态不可编辑文件，无法为服务器提供块级别存储。

三种存储接口

它能够提供企业中三种常见的存储需求：块存储、文件存储和对象存储，正如Ceph官方所定义的一样“Ceph uniquely delivers object, block, and file storage in one unified system.”，Ceph在一个统一的存储系统中同时提供了对象存储、块存储和文件存储，即一个统一存储，能够将企业企业中的三种存储需求统一汇总到一个存储系统中，并提供分布式、横向扩展，高度可靠性的存储系统，Ceph存储提供的三大存储接口：

1、CEPH OBJECT STORE对象存储，包含功能，特性如下：

RESTful Interface RESTful风格接口；
S3- and Swift-compliant APIs 提供兼容于S3和Swfit风格API；
S3-style subdomains S3风格的目录风格；
Unified S3/Swift namespace 统一扁平的S3/Swift命名空间，即所有的对象存放在同一个平面上；
User management 提供用户管理认证接入；
Usage tracking 使用情况追踪；
Striped objects 对象切割，将一个大文件切割为多个小文件（objects）；
Cloud solution integration 云计算解决方案即成，可以与Swfit对象存储即成；
Multi-site deployment 多站点部署，保障可靠性；
Multi-site replication 多站点复制，提供容灾方案。

2、CEPH BLOCK DEVICE块存储，包含功能，特性如下：

Thin-provisioned 瘦分配，即先分配特定存储大小，随着使用实际使用空间的增长而占用存储空间，避免空间占用；
Images up to 16 exabytes 耽搁景象最大能支持16EB；
Configurable striping 可配置的切片，默认是4M；
In-memory caching 内存缓存；
Snapshots 支持快照，将当时某个状态记录下载；
Copy-on-write cloning Copy-on-write克隆复制功能，即制作某个镜像实现快速克隆，子镜像依赖于母镜像；
Kernel driver support 内核驱动支持，即rbd内核模块；
KVM/libvirt support 支持KVM/libvirt，实现与云平台如openstack，cloudstack集成的基础；
Back-end for cloud solutions 云计算多后端解决方案，即为openstack，kubernetes提供后端存储；
Incremental backup 增量备份；
Disaster recovery (multisite asynchronous replication) 灾难恢复，通过多站点异步复制，实现数据镜像拷贝。

3、CEPH FILE SYSTEM文件存储，包含功能，特性如下：

POSIX-compliant semantics POSIX风格接口；
Separates metadata from data 元数据metadata和数据data分开存储；
Dynamic rebalancing 动态数据均衡；
Subdirectory snapshots 子目录快照；
Configurable striping 可配置切割大小；
Kernel driver support 内核驱动支持，即CephFS；
FUSE support 支持FUSE风格；
NFS/CIFS deployable 支持NFS/CIFS形式部署；
Use with Hadoop (replace HDFS) 可支持与Hadoop继承，替换HDFS存储。

通俗点讲：Ceph提供了三种存储接口：块存储RBD，对象存储RGW和文件存储CephFS，每种存储都有其相应的功能和特性

存储架构

Ceph 节点以普通硬件和智能守护进程作为支撑点， Ceph 存储集群组织起了大量节点，它们之间靠相互通讯来复制数据、并动态地重分布数据。

Ceph分布式集群是建立在RADOS算法之上的，RADOS是一个可扩展性，高可靠的存储服务算法，是Ceph的实现的基础。Ceph有两个重要的组件组成：Ceph Monitors（Ceph监视器）和Ceph OSDs（Ceph OSD 守护进程）。

其中Ceph Monitor作为集群中的控制中心，拥有整个集群的状态信息，各个组件如OSDs将自己的状态信息报告给Ceph Monitor这个总司令，
Ceph Monitor这个总司令肩负起整个集群协调工作；
同时Ceph Monitor还负责将集群的指挥工作，将集群的状态同步给客户端，客户端根据Ceph Monitor发送的集群状态信息可以获取到集群的状态，当集群状态有变化如OSD增加或故障时，Ceph Monitor会负责更新集群状态并下发给客户端。
Ceph Monitor的重要不言而喻，为了保障集群的可用性，需要部署高可用，一般需要部署2n+1个节点，如3个或5个Ceph Monitor节点。

Ceph Monitor监视器维护着集群运行图的主副本。一个监视器集群确保了当某个监视器失效时的高可用性。存储集群客户端向 Ceph Monitor 监视器索取集群运行图的最新副本。而Ceph OSD 守护进程检查自身状态、以及其它 OSD 的状态，并报告给监视器们。存储集群的客户端和各个 Ceph OSD 守护进程使用 CRUSH 算法高效地计算数据位置，而不是依赖于一个中心化的查询表。它的高级功能包括：基于 librados的原生存储接口、和多种基于 librados 的服务接口。

什么是集群的状态呢？

Ceph Monitor中保存的集群状态根据其功能角色的不同，分为以下几个map状态表：

Monitor Maps，集群Ceph Monitor集群的节点状态，通过ceph mon dump可以获取；
OSD Maps，集群数据存储节点的状态表，记录集群中OSD状态变化，通过ceph osd dump可以获取；
PGs Maps，PGs即placement group，表示在OSD中的分布式方式，通过ceph pg dump可以获取；
Crush Maps，Crush包含资源池pool在存储中的映射路径方式，即数据是如何分布的；
MDS Maps，CephFS依赖的MDS管理组件，可通过ceph mds dump获取，用于追踪MDS状态。

除了Ceph Monitor之外，还有一个重要的组件是OSD，集群中通常有多个OSD组成，OSD即Object Storage Daemon，负责Ceph集群中真正数据存储的功能，也就是我们的数据最终都会写入到OSD中。除了Monitor之外，根据Ceph提供的不同功能，还有其他组件，包括：

Ceph Monitors（ceph-mon）；
Ceph OSDs（ceph-osd）；
Ceph MDS（ceph-mds），用于提供CephFS文件存储，提供文件存储所需元数据管理；
Ceph RGW（ceph-rgw），用于提供Ceph对象存储网关，提供存储网关接入；
Ceph Manager（ceph-mgr），提供集群状态监控和性能监控。

数据的存储

Ceph中一切皆对象，不管是RBD块存储接口，RGW对象存储接口还是文件存储CephFS接口，其存储如到Ceph中的数据均可以看作是一个对象，一个文件需要切割为多个对象（object），然后将object存储到OSD中，

Ceph 存储集群从 Ceph 客户端接收数据——不管是来自 Ceph 块设备、 Ceph 对象存储、 Ceph 文件系统、还是基于 librados 的自定义实现——并存储为对象。每个对象是文件系统中的一个文件，它们存储在对象存储设备上。由 Ceph OSD 守护进程处理存储设备上的读/写操作。

Ceph的智能调度算法CRUSH，通过CRUSH算法将object调度到合适的OSD节点上，不管是客户端还是OSD，均使用CRUSH算法来计算object在集群中OSD的位置信息，同时保障object的副本能落到合适的OSD节点上

CRUSH算法的实现比较复杂，详情可以参考：CRUSH: Controlled, Scalable, Decentralized Placement of Replicated Data。

Ceph OSD 在扁平的命名空间内把所有数据存储为对象（也就是没有目录层次）。对象包含一个标识符、二进制数据、和由名字/值对组成的元数据，元数据语义完全取决于 Ceph 客户端。例如， CephFS 用元数据存储文件属性，如文件所有者、创建日期、最后修改日期等等。

object调度到OSD节点上，如果一个文件发生了变动或OSD出现了异常，以一个100G的文件为例，每个object默认为4M，将会切割为25600个object，如果Ceph集群需要正对每个object都进行调度的话，可想而知，在一个大规模集群中，crush的调度将会变得异常的繁重。因此，Ceph引入了另外一个概念PG，PG是Place Group即放置组，可以简单理解为一个装载object的容器，object将映射到PG中，PG最终会调度到某个具体的OSD上，因此CRUSH由object调度转为PG的调度，而PG的数量是相对固定的，因此集群分布时调度相对没有那么繁重，同时，当某个OSD异常时，CRUSH调度算法只需将其上的PG调度至其他OSD上（而不是将其上的object进行调度）

一个文件将会切割为多个object（如1G文件每个object为4M将切割为256个），每个object会由一个由innode(ino)和object编号(ono)组成oid，即object id，oid是真个集群唯一，唯一标识object对象；
针对object id做hash并做取模运算，从而获取到pgid，即place group id，通过hash+mask获取到PGs ID，PG是存储object的容器；
Ceph通过CRUSH算法，将pgid进行运算，找到当前集群最适合存储PG的OSD节点，如osd1和osd2（假设为2个副本）；
PG的数据最终写入到OSD节点，完成数据的写入过程，当然这里会涉及到多副本，一份数据写多副本。

参考地址：《Ceph分布式存储详述》

minIO ceph 存储方案简单介绍

存储发展史

minIO ceph都可以实现存储方案。存储的发展，根据不同的阶段诞生了不同的存储解决方案，每一种存储都有它当时的历史诞生的环境以及应用场景，解决的问题和优缺点。存储按照其功能，使用场景，一直在持续发展和迭代，大体上可以分为四个阶段：

DAS：Direct Attached Storage，即直连存储，第一代存储系统，通过SCSI总线扩展至一个外部的存储，磁带整列，作为服务器扩展的一部分；
NAS：Network Attached Storage，即网络附加存储，通过网络协议如NFS远程获取后端文件服务器共享的存储空间，将文件存储单独分离出来；
SAN：Storage Area Network，即存储区域网络，分为IP-SAN和FC-SAN，即通过TCP/IP协议和FC(Fiber Channel)光纤协议连接到存储服务器；
Object Storage：即对象存储，随着大数据的发展，越来越多的图片，视频，音频静态文件存储需求，动则PB以上的存储空间，需无限扩展。

存储的基本分类

存储的最终目的都是为了存放数据，而根据不同的分类方式存储也有多种分类，如

本地存储、外置存储
DAS：Direct Attached Storage,SAN：Storage Area Network,NAS：Network Attached Storage
快存储，文件存储，对象存储

存储的方案分成两种：一种是可以自定对象名称的，另一种是系统自动生成对象名称。

不能自定义名称的有领英的Ambry，MogileFS。
TFS 是淘宝开源的，但是目前已经很少有人维护它并且也不是很活跃。
ceph 是一个比较强大的分布式存储，但是它整个系统非常复杂需要大量的人力进行维护。
GlusterFS 为本身是一个非常成熟的对象存储的方案，2011被收购了，原班的人马又做了另外一个存储系统MINIO。

其中ceph跟minio是支持s3协议的。ceph跟minio大部分的s3 API都支持。

ceph支持s3 api的链接：https://docs.ceph.com/docs/master/radosgw/s3/#api
minio所支持的s3 API：https://docs.min.io/docs/java-client-api-reference

minio

minio是一个基于Apache License V2.0开源协议的对象存储服务，它兼容亚马逊S3云存储服务，非常适合于存储大容量非结构化的数据，如图片，视频，日志文件等。而一个对象文件可以任意大小，从几KB到最大的5T不等。它是一个非常轻量级的服务，可以很简单的和其它的应用结合，类似于NodeJS, Redis或者MySQL。
minio默认不计算MD5，除非传输给客户端的时候，所以很快，支持windows，有web页进行管理。

推荐一个比较好的实践案例：基于 Go 开源项目 MIMIO 的对象存储方案在探探的实践：https://mp.weixin.qq.com/s/YIKB_qAqqy6ydtFT_a_Ieg

ceph

ceph同时支持对象存储，块存储和文件系统服务。
高性能：摒弃了传统的集中式存储元数据寻址的方案采用CRUSH算法数据分布均衡并行度高;考虑了容灾域的隔离，能够实现各类负载的副本放置规则，例如跨机房、机架感知等;能够支持上千个存储节点的规模，支持TB到PB级的数据;
高可用性：副本数可以灵活控制;支持故障域分隔，数据强一致性;多种故障场景自动进行修复自愈;没有单点故障，自动管理;
高可扩展性：去中心化;扩展灵活;随着节点增加而线性增长;
特性丰富：支持三种存储接口：块存储、文件存储、对象存储;支持自定义接口，支持多种语言驱动.

minIOn VS ceph

	ceph	minIO
开发语言	C	go
数据冗余	副本、纠删码	纠删码(erasure code)
备份	ceph-backup备份软件	mc mirror
一致性	强一致性	强一致性
动态扩展	HASH	不支持动态加节点
中心节点	对象存储无中心，cephFS有元数据服务中心	无中心
存储方式	块、文件、对象	对象存储(分块)
活跃度	高，中文社区不算活跃	高，没有中文社区
成熟度	高	中
操作系统	linux-3 10.0+	linux windows
文件系统	EXT4 XFS	EXT4 XFS
断点续传	兼容S3，分段上传，断点下载	兼容S3，分段上传，断点下载
NAS	无	FreeNAS安装
学习成本	高	中
开源协议	LGPL version2.1	Apache v2.0
管理工具	ceph-admin ceph-mgr zabbix插件，web管理工具	命令行工具 mc
官网	https://ceph.io	https://min.io/
中文社区	http://ceph.org.cn/	无
优点	成熟，功能强大(支持数千节点，支持动态增加节点，自动平衡数据分布，可配置性强，可针对不同的场景进行调优)	学习成本低，安装运维简单，开箱即用
缺点	学习成本高，安装运维复杂	社区不够成熟，业界参考资料较少，不支持动态增加节点

指标体系管理系统闲扯下

指标体系在数仓物理实现层面主要是结合数仓模型分层架构进行指导建设，数仓建模的过程很大一部分其实就是在构建指标体系，可以说指标体系的好坏决定了模型了健壮性。构建指标体系需要从“管理、计算、使用”三个角度阐述一下什么样的指标管理方法是“合格的”

指标体系在数仓物理实现层面主要是结合数仓模型分层架构进行指导建设，数仓建模的过程很大一部分其实就是在构建指标体系，可以说指标体系的好坏决定了模型了健壮性。

一、存在的问题

实际工作中不管是做BI还是数仓项目，只要存在计算指标的功能就会存在以下问题：

命名不规范：好的指标命名是可以推断出其包含的业务过程的，但工作中总会碰到一些指标，很难判断这个指标是描述什么业务的。
计算口径不统一：有些指标的计算口径不同的人会有不同的理解方式，导致使用者对这一指标理解产生歧义。
数据来源、计算逻辑不清晰：之前工作中经常会碰到这类问题，当指标出现问题时需要去查代码才能找到指标使用了哪些表中的数据。而有些计算逻辑比较复杂的指标很难用语言描述清楚，即使能够描述清楚也会需要大段文字。指标开发人员很清楚其中的计算逻辑，使用者用起来是一头雾水。
指标重复/冲突/过度开发：由于没有统一的指标管理体系，导致很多指标重复开发，不同指标名称背后很可能是相同的计算逻辑和统计口径；指标名称相同，计算逻辑、统计口径、数据源等不一样，这种情况非常让人费解；工作中有时要开发一些由于“某些原因”必须开发的指标，而这些指标很多时候只使用一次
指标使用不明确：由于指标命名不规范、指标描述不清晰等问题，使用者不知道如何使用、分析这一指标。

二、指标管理的一些原则

指标体系化管理、全局统一管理
指标计算逻辑、计算口径、数据源表述清晰。
指标命名规范、描述清晰且含义明确
明确指标的使用方式、系统、使用人等权限明确

从 “管理、计算、使用”三个角度阐述一下什么样的指标管理方法是“合格的”：

三、基本概念

指标：业务单元细分之后量化的度量值
数据域：业务过程或者维度的抽象集合

其中，业务过程可以概括为一个个不拆分的行为事件，在业务过程之下，可以定义指标；维度，是度量的环境，如乘客呼单事件，呼单类型是维度。为了保障整个体系的生命力，数据域是需要抽象提炼，并且长期维护更新的，变动需执行变更流程。
业务过程：不可拆分的业务活动事件，如库房操作中的拣选、复核、打包等都是业务过程
时间周期：统计的时间范围或者时间点，非统计口径；最近30天、自然周、截止当日等
修饰词：业务场景限定词，如AGV仓、Shuttle仓、立体仓库等，个人理解可以和维度属性等同；修饰类型从属于某个业务域，如日志域的访问终端类型涵盖APP端、PC端等修饰词
修饰类型：修饰词的抽象划分，从属于某个业务域，如仓库类型下包含上述仓库类型在内的多种仓库

原子指标/度量：基于某一业务行为下的量化值，具有明确的业务含义，适合用“动作+度量”的方式命名；

原子指标和度量含义相同，基于某一业务事件行为下的度量，是业务定义中不可再拆分的指标，具有明确业务含义的名称，如支付金额。

指标分类主要分为原子指标、派生指标、衍生指标。

原子指标    基于某一业务事件行为下的度量，是业务定义中不可再拆分的指标，具有明确业务含义的名称，如呼单量、交易金额

派生指标    是1个原子指标+多个修饰词（可选）+时间周期，是原子指标业务统计范围的圈定。派生指标又分以下二种类型：

    事务型指标：是指对业务过程进行衡量的指标。例如，呼单量、订单支付金额，这类指标需要维护原子指标以及修饰词，在此基础上创建派生指标。
    存量型指标：是指对实体对象（如司机、乘客）某些状态的统计，例如注册司机总数、注册乘客总数，这类指标需要维护原子指标以及修饰词，在此基础上创建派生指标，对应的时间周期一般为“历史截止当前某个时间”。

衍生指标是在事务性指标和存量型指标的基础上复合成的。主要有比率型、比例型、统计型均值

维度：度量的环境，反映业务的一类属性，如库房维度、SKU品类维度、时间维度

维度是度量的环境，用来反映业务的一类属性，这类属性的集合构成一个维度，也可以称为实体对象。维度属于一个数据域，如地理维度（其中包括国家、地区、省市等）、时间维度（其中包括年、季、月、周、日等级别内容）。
维度属性：维度的属性，比如库房维度的属性：库房名称、库房位置、库房类型等
派生指标：时间周期+统计粒度+修饰词+原子指标，采用“修饰词__原子指标_时间周期”命名方式。一个简单的判断标准：如果修饰词有对应的维表，就可以作为派生指标，否则可以当作原子指标管理

四、指标管理方法

指标管理的几项目标是

技术目标   统一指标和维度管理，指标命名、计算口径、统计来源唯一， 维度定义规范、维度值一致
业务目标   统一数据出口、场景化覆盖
产品目标   指标体系管理工具产品化落地；指标体系内容产品化落地支持决策、分析、运营例如决策北极星、智能运营分析产品等

认识和管理复杂事物最好的方法之一就是分类

    A[业务线] -->B{主题域}
    B--> G(修饰类型)
    B --> D(纬度)
    B --> C(业务过程)
    D-->K(纬度属性)
    G-->H(修饰词)
    C -->E(原子指标)
    C-->J(度量)
    H-->F(派生指标)
    E -->F(派生指标)
    F-->M(汇总事实表)
    J-->N(明细纬度事实表)
    K-->N(明细纬度事实表)
    K-->L(纬度表)
    K-->M(汇总事实表)
    J-->M(汇总事实表)

一般会按照业务线、主题域、业务过程三级目录的方式管理指标，如果业务线条之间交叉较多，也可直接按照主题域划分。例如电商行业划分仓储、配送、零售、客服等主题域，都是为电商业务服务等，仓储主题域下面又划分为拣选、复核、打包等业务过程

规范的命名

原子指标：指标名称适合用“动作+度量”的命名方式，标识的命名用英文简称或者汉语拼音缩写比较好。
派生指标：指标名称应严格遵循“时间周期+统计粒度+业务限定+原子指标”的命名方式，标识命名要用“业务限定_原子指标_时间周期”的方式。

指标管理系统的基本功能

系统应当能按照指标管理体系进行多维度分类
能够清晰的描述指标名称（中英文）、业务口径、计算逻辑等；
能够较为便利的管理指标，进行添加、删除、修改等操作。
指标能够关联应用系统
指标应该和能数仓中的数据模型动态关联，即指标能够关联到表和字段上，以便使用者能够深入了解指标的计算过程，开发者能够较为便捷的定位数据源
系统应该和元数据管理系统关联，否则指标无法关联表和字段
应当能够同步数仓的主题域和业务过程，并按照命名规范创建指标
提供指标检索功能