精华内容
下载资源
问答
  • 备库的概念
    千次阅读
    2022-03-29 14:58:46

    熟悉数据挖掘技术的小伙伴,对数据仓库这一概念应该都不会感到陌生。数据挖掘技术是基于已有的数据之上,以帮助企业或个人了解现有的数据或信息,并在此基础上对企业的未来发展状况做出预测。这个基础数据就储存于数据仓库中,基于数据仓库进行数据挖掘,还能够辅助管理层对未来行业发展前景做出更科学、更合理地数据分析与预测。

    数据仓库是单个数据存储,用于支持分析性报告、决策等为目的而建立的。其可以提供各种类型数据,支持企业进行各种级别决策的制定,还能为有业务智能需求的企业提供有关数据监看、业务流程改进等支持。由此可见数据仓库对整个数据挖掘过程的重要性,下面小编总结一下数据仓库的4大特征,以帮助大家更好地理解数据仓库的概念。

    在这里插入图片描述

    1、面向主题

    面向主题,即处于数据仓库中的数据是按照特定的主题组织而成的,这里的主题不是具体的而是一个抽象的概念,常指企业或个人在使用数据仓库着重关注的方面。它不像业务支撑系统按业务功能明确企业的业务范围并按业务对象的密切度进行分类,不同的行业数据仓库的主题划分也不尽相同。

    2、数据集成

    数据集成,指在数据仓库中的数据信息并不是在各业务系统中简单、随机抽取的,由于数据仓库间的独立性,因此需要消除源数据中的异值。即对原本分散于数据仓库中的数据进行抽取、清理的系统加工,以确保数据仓库中的数据保持一致性。

    3、稳定性

    业务系统中的数据总是处于不断变化的状态,即数据为最新的状态。相对于业务系统的不断变化,数据仓库具有稳定性,是指数据在进入数据仓库后,数据一般用于查询,很少会对数据进行修改,常见的操作也只是进行定期的加载和刷新。

    4、反映历史变化

    相对于业务系统数据常处于最新的状态,数据仓库的数据信息是可以反映历史变化的,即从过去的每一历史时刻至今各阶段的变化信息都有记录。由于数据仓库的数据具有能够反映历史变化的特点,因此可以利用其对行业的未来趋势和企业的发展方向做出更科学的预测,可以将其理解为环比、同比。

    现在你了解数据仓库的概念以及其4大特点了吗?经过上面的分析,相信大家也了解到了数据仓库于数据挖掘过程的重要性。在构建数据仓库方面,由于数据仓库的数据量是巨大的,因此一般要借助专业的BI工具来完成,如国内知名的BI品牌思迈特软件Smartbi就很不错。数据采集能力表现在,支持Excel数据批量导入功能。支持包括MySQL、MSSQL等丰富的数据连接。在跨库整合方面,Infobright、高速缓存库等数据源类型均可支持。

    更多相关内容
  • 9.maven的概念模型 Maven 包含了一个项目对象模型 (Project Object Model),一组标准集合,一个项目生命周期(Project Lifecycle),一个依赖管理系统(Dependency Management System),和用来运行定义在生命周期阶段 ...

    Maven系列1

    在这里插入图片描述

    1.什么是Maven?

    Maven是一个项目管理工具,它包含了一个对象模型。一组标准集合,一个依赖管理系统。和用来运行定义在生命周期阶段中插件目标和逻辑。
    核心功能
    Maven的核心功能是合理叙述项目间的依赖关系,通俗点 就是通过pom.xml文件的配置获取jar包不用手动的去添加jar包,,这个pom.xml包我后面会叙述,不过已经学习过maven的 人应该对这个很熟悉。其本质就是通过配置pom.xml来获取jar包,当然这是在该项目必须是maven项目的前提下。那么什么是maven项目
    maven项目是啥?
    我们这样来理解maven项目,就是在java项目和web项目上裹了一层maven,本质上java项目还是java项目,web项目还是web项目,但是包裹了maven之后,就可以使用maven提供的一些功能,即通过pom.xml添加jar包
    就像在蜜汁鸡外面裹了一层面粉油炸一下变成了炸鸡,但是他还是一只鸡

    在这里插入图片描述

    在这里插入图片描述

    2.Maven能够解决什么问题

    在想Maven可以解决什么问题之前我们先来想想我们开发过程中经常遇到什么问题
    1、我们需要引用各种 jar 包,尤其是比较大的工程,引用的 jar 包往往有几十个乃至上百个, 每用到一种 jar 包,都需要手动引入工程目录,而且经常遇到各种让人抓狂的 jar 包冲突,版本冲突。
    2、我们辛辛苦苦写好了 Java 文件,可是只懂 0 和 1 的白痴电脑却完全读不懂,需要将它编译成二进制字节码。好歹现在这项工作可以由各种集成开发工具帮我们完成,Eclipse、IDEA 等都可以将代码即时编译。当然,如果你嫌生命漫长,何不铺张,也可以用记事本来敲代码,然后用 javac 命令一个个地去编译,逗电脑玩。
    3、世界上没有不存在 bug 的代码,计算机喜欢 bug 就和人们总是喜欢美女帅哥一样。为了追求美为了减少 bug,因此写完了代码,我们还要写一些单元测试,然后一个个的运行来检验代码质量。
    4、再优雅的代码也是要出来卖的。我们后面还需要把代码与各种配置文件、资源整合到一起,定型打包,如果是 web 项目,还需要将之发布到服务器,供人蹂躏。
    maven所帮助我们解决的问题
    以上的这些问题maven都把我们解决了,没错maven可以帮我们
    1构建工程,
    2管理jar,
    3.编译代码,
    4.自动运行单元测试,
    5.打包
    6.生成报表,
    7.部署项目,生成web站点。

    有没有孙悟空得到金箍棒的感觉
    在这里插入图片描述

    3.接下来我就举个例子让大家先见识见识maven的功能

    在这里插入图片描述前面我们通过web阶段的项目,要能够将项目运行起来,就必须将该项目所依赖的一些jar包添加到工程中,否则项目就不可以运行了,如果相同架构的项目有十几个,那么我们就需要将这一份jar包复制到十个不同的工程中我们一起来看看CRM工程的大小
    使用传统的CRM项目

    在这里插入图片描述

    使用maven构建

    在这里插入图片描述

    4.Maven的依赖管理

    为什么使用maven之后文件夹就如此之小了呢?其实这我们在前面就提到过了即通过配置pom.xml的文件来配置依赖,而Maven的一个核心特征就是依赖管理,当我们涉及到多模块的项目(包含成百个模块或者子项目),管理依赖就变成了一个极为困难的任务Maven展示出了他对处理这种情形的高度控制
    传统的web项目中,我们必须将工程所依赖的jar包复制到工程中,导致工程变的很大,那么maven是如何通过操作使工程变少的呢

    在这里插入图片描述通过图解可以发现maven工程不直接将jar包导入到工程中,而是通过再pom.xml中添加所需的jar包的坐标,这样就避免了jar直接引入进来,在需要用到jar包的时候,只要查找pom.xml文件,再通过pom.xml中的坐标,到一个专门用于存放jar包的仓库中根据坐标从而找到这些jar包,再把这些jar包拿去运行
    看到这读者们可能会有疑问
    1.存放jar包的仓库长什么样?
    这个我们会在后面一一讲解,仓库也分为许多种类
    2.通过读取pom.xml坐标,来找jar的方式会不会导致速度很慢。从而导致这些方案不可行
    通过 pom.xml 文件配置要引入的 jar 包的坐标,再读取坐标并到仓库中加载 jar 包,这
    样我们就可以直接使用 jar 包了,为了解决这个过程中速度慢的问题,maven 中也有索引的概念,通过建立索引,可以大大提高加载 jar 包的速度,使得我们认为 jar 包基本跟放在本地的工程文件中再读取出来的速度是一样的。这个过程就好比我们查阅字典时,为了能够加快查找到内容,书前面的目录就好比是索引,有了这个目录我们就可以方便找到内容了,一样的在 maven 仓库中有了索引我们就可以认为可以快速找到 jar 包。

    5.仓库的概念

    仓库就是存放jar包的地方,即我们前面说的通过pom.xml中通过设置索引来到仓库中寻找jar包
    仓库分为:本地仓库,第三方仓库,中央仓库

    5.1本地仓库
    用来存储从远程仓库或者中央仓库下载的插件和jar包,项目使用一些插件或jar包
    优先从本地仓库查找
    默认本地仓库的位置在 u s e r . d i r / . m 2 / r e p o s i t o r y , {user.dir}/.m2/repository, user.dir/.m2/repository{user.dir}表示 windows 用户目录。
    在这里插入图片描述
    5.2第三方仓库
    d第三方仓库,又称为内部中心仓库,又称为私服
    私服:一般由公司自己设立,只为本公司内部共享使用,它既可以作为公司内部构建协作和存档,也可作为公用类库镜像缓存,减少在外部访问和下载的频率使用私服为了减少对中央仓库的访问私服可以使用的是局域网,中央仓库必须使用外网。也就是一般公司都会创建这种第三方仓库,保证项目开发时,项目所需用的jar都从该仓库中拿,每个人的版本就都一样。
    注意:连接私服,需要单独配置。如果没有配置私服,默认不使用

    5.3中央仓库
    在 maven 软件中内置一个远程仓库地址 http://repo1.maven.org/maven2 ,它是中央仓库,服务于整个互联网,它是由 Maven 团队自己维护,里面存储了非常全的 jar 包,它含了世界上大部分流行的开源项目构件。

    获取jar包的过程
    优先从本地仓库查找,如果本地仓库没有该jar包,如果配置了私服,就从私服中查找,私服中没有就从中央仓库中查找,然后下载到本地仓库,下次使用就可以直接从本地仓库中查找,没有配置私服则,直接从中央仓库中查找
    在这里插入图片描述

    6.Maven java项目结构

    Maven工程目录结构

    在这里插入图片描述图中有一个target目录,是因为将该java项目进行了编译,src/main/java下的源代码就会编译成.class文件放入target目录中,target就是输出目录。
    作为一个 maven 工程,它的 src 目录和 pom.xml 是必备的。
    进入 src 目录后,我们发现它里面的目录结构如下:
    在这里插入图片描述

    项目名称
    –pom.xml 核心配置,项目根下
    –src
    –main
    –java java源码目录
    –resources java配置文件目录
    –test
    –java 源码测试目录
    –resource 测试配置目录

    7.maven的常用命令

    7.1 compile
    compile是maven工程的编译命令,作用是将 src/main/java 下的文件编译为 class 文件输出到 target
    目录下。
    7.2 test
    test是maven工程的测试命令,会执行 src/test/java 下的单元测试类。
    cmd 执行 mvn test 执行 src/test/java 下单元测试类,下图为测试结果,运行 1 个测试用例,全部成功。
    7.3 clean
    clean是maven工程的清理命令,执行clean会删除target目录及其内容
    7.4 package
    package是maven工程的打包命令,对于java工程执行 package 打成 jar 包,对于 web 工程打成 war
    包。
    7.5 install
    install 是 maven 工程的安装命令,执行 install 将 maven 打成 jar 包或 war 包发布到本地仓库。
    从运行结果中,可以看出:当后面的命令执行时,前面的操作过程也都会自动执行

    8.maven的生命周期

    maven对项目构建过程分为三套相互独立的生命周期,这里说的三套而且是相互独立,
    这三套分别是:
    Clean Lifecycle :在进行真正的构建之前进行一些清理工作。
    Default Lifecycle :构建的核心部分,编译,测试,打包,部署等等。
    Site Lifecycle :生成项目报告,站点,发布站点。

    9.maven的概念模型

    Maven 包含了一个项目对象模型 (Project Object Model),一组标准集合,一个项目生命周期(Project
    Lifecycle),一个依赖管理系统(Dependency Management System),和用来运行定义在生命周期阶段
    (phase)中插件(plugin)目标(goal)的逻辑。

    在这里插入图片描述

    9.1项目对象模型
    一个maven工程都有一个pom.xml文件。通过pom.xml文件定义项目的坐标,项目的依赖,项目的信息
    插件目标等

    9.2依赖管理系统
    通过 maven 的依赖管理对项目所依赖的 jar 包进行统一管理。
    比如:项目依赖 junit4.9,通过在 pom.xml 中定义 junit4.9 的依赖即使用 junit4.9,如下所示是 junit4.9
    的依赖定义:

    <!-- 依赖关系 -->
    <dependencies>
    <!-- 此项目运行使用 junit,所以此项目依赖 junit -->
    <dependency>
    <!-- junit 的项目名称 -->
    <groupId>junit</groupId>
    <!-- junit 的模块名称 -->
    <artifactId>junit</artifactId>
    <!-- junit 版本 -->
    <version>4.9</version>
    <!-- 依赖范围:单元测试时使用 junit -->
    <scope>test</scope>
    </dependency>
    

    9.3 一个项目的生命周期
    使用maven完成项目的构建,项目构建包括:清理,编译,部署等过程,maven将这些过程规范为一个生命周期,如下所示是生命周期的各阶段

    在这里插入图片描述
    maven 通过执行一些简单命令即可实现上边生命周期的各各过程,比如执行 mvn compile 执行编译、
    执行 mvn clean 执行清理。

    9.4 一组标准集合
    maven将整个项目管理过程定义为一组标准集合,比如通过maven构建工程有标准的目录结构,有标准的生命周期阶段,依赖管理有标准的坐标定义

    9.5 插件目标

    maven管理项目生命周期都是基于插件完成的

    10.使用idea开发meven项目

    这个就是几个简单的参数配置一下没什么东西讲,我就放个流程图好了

    1.
    在这里插入图片描述2.

    在这里插入图片描述
    3.

    在这里插入图片描述

    在这里插入图片描述

    在这里插入图片描述
    6.
    在这里插入图片描述
    7.
    在这里插入图片描述
    8.
    在这里插入图片描述9.

    在这里插入图片描述10.

    在这里插入图片描述
    11.
    在这里插入图片描述

    11.获取jar包方式

    到中央仓库的官网上去下载
    网址:
    http://search.maven.org/
    http://mvnrepository.com/

    例图:
    在这里插入图片描述

    以上就是maven的一些基础知识,后续我会更新更高阶的maven知识
    ,即我们在项目中经常使用到的,喜欢的也可以关注我,创作不易,
    觉得有帮助的可以点赞收藏关注

    在这里插入图片描述

    展开全文
  • 1、数据倾斜表现 2、数据倾斜产生原因 3、解决数据倾斜思路 一、数据仓库的8个发展阶段 1、概念阶段(1978-1988) 数据仓库最早的概念可以追溯到20世纪70年代MIT的一项研究,该研究致力于开发一种优化的技术架构并...

    文末下载PDF

    文章很长,前言一定要看

    拥有本篇文章,意味着你拥有一本完善的书籍,本篇文章整理了数据仓库领域,几乎所有的知识点,文章内容主要来源于以下几个方面:

    1. 源于「数据仓库交流群」资深数据仓库工程师的交流讨论,如《sql行转列的千种写法》。
    2. 源于群友面试大厂遇到的面试真题,整理投稿给我,形成《面试题库》。
    3. 源于笔者在系统学习过程中整理的笔记和一点理解
    4. 源于技术网站的优质文章和高赞答案

    本篇文章尤其适合初级程序员准备面试,以及作为工作中的指导手册,对资深程序员来说也可夯实基础。

    当然,技术学习仅仅依靠一篇文章还是不够的,可加入公众号和技术交流群(联系方式见文末),群里有很多数据仓库领域资深大佬,大家经常在群里讨论技术热点问题、互相解决工作难题、安排内推、甚至有部门leader直接发出岗位邀请。「西红柿🍅」也会持续更新优质文章,也欢迎热爱学习总结的小伙伴有偿投稿,共同推动中国信息技术行业发展,让我们一起加油吧!

    目录

    一、数据仓库的8个发展阶段

    1、概念阶段(1978-1988)

    2、萌芽阶段

    3、集成阶段

    4、确立阶段(1991)

    5、数据集市(1994-1996)

    6、争吵与混乱(1996-1997)

    7、合并(1998-2001)

    8、未来

    二、四种常见数据模型

    1、为什么要进行数据仓库建模

    2、四种常见模型

    2.1 维度模型

    2.2 范式模型

    2.3 Data Vault模型

    2.4 Anchor模型

    3、数据模型的评价标准

    三、三种事实表

    1、三种事实表概述

    1.1 事务事实表

    1.2 周期快照事实表

    1.3 累积快照事实

    2、三种事实表对比

    3、事实表设计 8 大原则

    4、事实表设计方法

    第一步:选择业务过程及确定事实表类型

    第二步:声明粒度

    第三步:确定维度

    第四步:确定事实

    四、多维体系结构

    1、总线架构

    2、一致性维度 

    3、一致性事实

    五、数据仓库规范设计

    1、为什么要进行规范设计

    2、设计规范 - 指标

    3、命名规范 - 表命名

    3.1 常规表

    3.2 中间表

    3.3 临时表

    3.4 维度表

    4、开发规范

    5、流程规范

    六、元数据管理

    1、业务元数据

    2、技术元数据

    数据源元数据

    ETL 元数据

    数据仓库元数据

    BI 元数据

    3、管理元数据

    4、小编有话

    七、维度表

    1、什么是维度表

    2、维度表设计原则

    缓慢变化维

    3、维度表设计方法

    八、三范式与反范式

    1、第一范式

    2、第二范式

    3、第三范式

    4、反范式化

    5、范式化设计和反范式化设计的优缺点

    5.1 范式化 (时间换空间)

    5.2 反范式化(空间换时间)

    6、OLAP和OLTP中范式设计

    九、数据仓库架构-Lambda和Kappa

    1、Lambda架构原理

    2、Lambda架构的缺点

    3、Kappa架构原理

    4、Lambda架构和Kappa架构优缺点对比

    5、数据架构评价标准

    6、小编有话

    十、数据治理(目的、方法、流程)

    1、什么是数据治理

    2、数据治理的目的

    3、数据治理的方法

    4、数据质量8个衡量标准

    5、数据治理流程

    十一、ETL

    1、什么是ETL

    2、ETL & ELT

    3、常用的ETL工具

    3.1 sqoop

    3.2 DataX

    3.3 Kettle

    3.4 canal

    3.5 StreamSets

    4、ETL加载策略

    4.1 增量

    4.2 全量

    4.3 流式

    5、小编有话

    十二、数据应用-OLAP

    1、olap和oltp的区别

    2、OLAP分类

    3、OLAP基本操作

    4、OLAP选型

    4.1 druid

    4.2 kylin

    十三、数据倾斜

    1、数据倾斜表现

    2、数据倾斜产生原因

    3、解决数据倾斜思路


     

    一、数据仓库的8个发展阶段

    1、概念阶段(1978-1988)

    数据仓库最早的概念可以追溯到20世纪70年代MIT的一项研究,该研究致力于开发一种优化的技术架构并提出这些架构的指导性意见。

    第一次,MIT的研究员将业务系统和分析系统分开,将业务处理和分析处理分成不同的层次,并采用单独的数据存储和完全不同的设计准则。同时,MIT的研究成果与80年代提出的信息中心(InformationCenter)相吻合:即把那些新出现的、不可以预测的、但是大量存在的分析型的负载从业务处理系统中剥离出来。

    但是限于当时的信息处理和数据存储能力,该研究只是确立了一个论点:这两种信息处理的方式差别如此之大,以至于它们只能采用完全不同的架构和设计方法。

    2、萌芽阶段

    在80年代中后期,作为当时技术最先进的公司,DEC已经开始采用分布式网络架构来支持其业务应用,并且DEC公司首先将业务系统移植到其自身的RDBMS产品:RdB。并且,DEC公司从工程部、销售部、财务部以及信息技术部抽调了不同的人员组建了新的小组,不仅研究新的分析系统架构,并要求将其应用到其全球的财务系统中。该小组结合MIT的研究结论,建立了TA2(TechnicalArchitecture2)规范,该规范定义了分析系统的四个组成部分:

    • 数据获取
    • 数据访问
    • 目录
    • 用户服务

    其中的数据获取和数据访问目前大家都很清楚,而目录服务是用于帮助用户在网络中找到他们想要的信息,类似于业务元数据管理;用户服务用以支持对数据的直接交互,包含了其他服务的所有人机交互界面,这是系统架构的一个非常大的转变,第一次将交互界面作为单独的组件提出来。

    3、集成阶段

    全企业集成(EnterpriseIntergration,1988)同时,IBM也在处理信息管理不同方面的问题,其最烦人的问题是不断增加的信息孤岛,IBM的很多客户要面对很多分立系统的数据集成问题,而这些系统有不同的编码方式和数据格式。

    1988年,为解决全企业集成问题,IBM爱尔兰公司的BarryDevlin和PaulMurphy第一次提出了“信息仓库(InformationWarehouse)”的概念,将其定义为:“一个结构化的环境,能支持最终用户管理其全部的业务,并支持信息技术部门保证数据质量”,并在1991年在DECTA2的基础上把信息仓库的概念包含进去,并称之为VITAL规范,将PC、图形化界面、面向对象的组件以及局域网都包含在VITAL里,并定义了85种信息仓库的组件,包括数据抽取、转换、有效性验证、加载、Cube开发和图形化查询工具等。但是IBM只是将这种领先的概念用于市场宣传,而没有付诸实际的架构设计。这是IBM有一个领域上创新后停止不前导致丧失其领先地位。因此,在90年代初期,数据仓库的基本原理、框架架构,以及分析系统的主要原则都已经确定,主要的技术,包括关系型数据存取、网络、C/S架构和图形化界面均已具备,只欠东风了。

    同时,1988年-1991年,一些前沿的公司已经开始建立数据仓库

    4、确立阶段(1991)

    企业级数据仓库(EDW,1991)1991年,BillInmon出版了其有关数据仓库的第一本书,这本书不仅仅说明为什么要建数据仓库、数据仓库能给你带来什么,更重要的是,Inmon第一次提供了如何建设数据仓库的指导性意见,该书定义了数据仓库非常具体的原则,包括:数据仓库是面向主题的(Subject-Oriented)、集成的(Integrated)、包含历史的(Time-variant)、相对稳定的(Nonvolatile)、面向决策支持的(DecisionSupport)面向全企业的(EnterpriseScope)最明细的数据存(AtomicDetail)数据快照式的数据获取(SnapShotCapture)这些原则到现在仍然是指导数据仓库建设的最基本原则,虽然中间的一些原则引发一些争论,并导致一些分歧和数据仓库变体的产生。

    BillInmon凭借其这本书奠定了其在数据仓库建设的位置,被称之为数据仓库之父

    5、数据集市(1994-1996)

    数据仓库发展的第一明显分歧是数据集市概念的产生。由于企业级数据仓库的设计、实施很困难,使得最早吃数据仓库螃蟹的公司遭到大面积的失败,因此数据仓库的建设者和分析师开始考虑只建设企业级数据仓库的一部分,然后再逐步添加,但是这有背于BillInmon的原则:各个实施部分的数据抽取、清洗、转换和加载是独立,导致了数据的混乱与不一致性。而且部分实施的项目也有很多失败,除了常见的业务需求定义不清、项目执行不力之外,很重要的原因是因为其数据模型设计,在企业级数据仓库中,Inmon推荐采用3范式进行数据建模,但是不排除其他的方法,但是Inmon的追随者固守OLTP系统的3范式设计,从而无法支持DSS系统的性能和数据易访问性的要求。

    这时,Ralph Kimball出现了,他的第一本书“TheDataWarehouseToolkit”掀起了数据集市的狂潮,这本书提供了如何为分析进行数据模型优化详细指导意见,从DimensionalModeling大行其道,也为传统的关系型数据模型和多维OLAP之间建立了很好的桥梁。从此,数据集市在很多地方冒了出来,并获得很大成功,而企业级数据仓库已逐渐被人所淡忘。

    6、争吵与混乱(1996-1997)

    企业级数据仓库还是部门级数据集市?关系型还是多维?BillInmonRalphKimball一开始就争论不休,其各自的追随者也唇舌相向,形成相对立的两派:Inmon派和Kimball派(有点象少林和武当,呵呵)

    在初期,数据集市的快速实施和较高的成功率让Kimball派占了上风,但是很快,他们也发现自己陷入了某种困境:企业中存在6-7个不同的数据集市,分别有不同的ETL,相互之间的数据也不完全一致。同时,各个项目实施中也任意侵犯了Inmon开始定下的准则:把数据集市当成众多OLTP系统之后的有一个系统,而不是一个基础性的集成性的东西,为保证数据的准确性和实时性,有的甚至可以由OLTP系统直接修改数据集市里面的数据,为了保证系统的性能,有的数据集市删除了历史数据。等等,不一而足。

    当然,这导致了一些新的应用的出现,例如ODS,但是人们对DataWarehouse、DataMart、ODS的概念非常的模糊,经常混为一谈。有人说OLAP就是数据仓库,也有人说我要ODS和DataMart,不要Datawarehouse,也有人说,我DataMart建多了,自然就有DataWarehouse了。但是BillInmon一直很旗帜鲜明:“你可以打到几万吨的小鱼小虾,但是这些小鱼小虾加起来不是大鲸鱼”。

    7、合并(1998-2001)

    经过多翻争吵,证明one-size-fits-all是不可能的,你需要不同的BI架构来满足不同的业务需求。BillInmon也推出了新的BI架构CIF(Corporationinformationfactory),把Kimball的数据集市也包容进来了,第一次,Kimball承认了Inmon,但是仍然还有很多人在争论是自顶向下,还是自底向上。

    8、未来

    未来几个方向:时效性方向的实时数仓;数据质量方向的数据治理;数据中台、数据湖(欢迎留言讨论!

    推荐阅读:

    数据库、数据仓库、数据平台、数据中台、数据湖到底是什么?

    二、四种常见数据模型

    大数据时代,维度建模已成为各大厂的主流方式。

    维度建模从分析决策的需求出发构建模型,为分析需求服务。重点关注用户如何快速的完成数据分析,可以直观的反应业务模型中的业务问题,需要大量的数据预处理、数据冗余,有较好的大规模复杂查询的响应性能

    1、为什么要进行数据仓库建模

    • 性能:良好的模型能帮我们快速查询需要的数据,减少数据的IO吞吐
    • 成本:减少数据冗余、计算结果复用、从而降低存储和计算成本
    • 效率:改善用户使用数据的体验,提高使用数据的效率
    • 改善统计口径的不一致性,减少数据计算错误的可能性

    2、四种常见模型

    2.1 维度模型

    维度建模按数据组织类型划分可分为星型模型、雪花模型、星座模型。Kimball老爷爷维度建模四部曲:

    选择业务处理过程 > 定义粒度 > 选择维度 > 确定事实

    2.1.1 星型模型

    星型模型主要是维表和事实表,以事实表为中心,所有维度直接关联在事实表上,呈星型分布。

    https://mmbiz.qpic.cn/mmbiz_png/Jy3qP5tic4icSUZPphtibOGia8NhkDFBViaPQKswjhsQiafst5d5g50jc93wtRqzzCYicW2d13ys71Xl66acXr2yeZ44g/640?wx_fmt=png

    2.1.2 雪花模型

    雪花模型,在星型模型的基础上,维度表上又关联了其他维度表。这种模型维护成本高,性能方面也较差,所以一般不建议使用。尤其是基于hadoop体系构建数仓,减少join就是减少shuffle,性能差距会很大。

    星型模型可以理解为,一个事实表关联多个维度表,雪花模型可以理解为一个事实表关联多个维度表,维度表再关联维度表。

    https://mmbiz.qpic.cn/mmbiz_png/Jy3qP5tic4icSUZPphtibOGia8NhkDFBViaPQf8B5cIiboDpeaIKHBW7wlgnQ82v3g9A6of7CWRaEbsVVmvsib6iasmdlQ/640?wx_fmt=png

    2.1.3 星座模型

    星座模型,是对星型模型的扩展延伸,多张事实表共享维度表。

    星座模型是很多数据仓库的常态,因为很多数据仓库都是多个事实表的。所以星座模型只反映是否有多个事实表,他们之间是否共享一些维度表。

    https://mmbiz.qpic.cn/mmbiz_png/Jy3qP5tic4icSUZPphtibOGia8NhkDFBViaPQshEECGzZAgj2bRO4oYMkqbIeiazj65ccU0yJKw81J3SndpvR06iaBLSw/640?wx_fmt=png

    2.2 范式模型

    即实体关系(ER)模型,数据仓库之父Immon提出的,从全企业的高度设计一个3NF模型,用实体加关系描述的数据模型描述企业业务架构,在范式理论上符合3NF。此建模方法,对建模人员的能力要求非常高。

    特点:设计思路自上而下,适合上游基础数据存储,同一份数据只存储一份,没有数据冗余,方便解耦,易维护,缺点是开发周期一般比较长,维护成本高。

    详见后文:三范式与反范式

    2.3 Data Vault模型

    DataVault由Hub(关键核心业务实体)、Link(关系)、Satellite(实体属性) 三部分组成 ,是Dan Linstedt发起创建的一种模型方法论,它是在ER关系模型上的衍生,同时设计的出发点也是为了实现数据的整合,并非为数据决策分析直接使用。

    2.4 Anchor模型

    高度可扩展的模型,所有的扩展只是添加而不是修改,因此它将模型规范到6NF,基本变成了K-V结构模型。企业很少使用。

    信息技术智库关注领取技术资料、面试真题、简历模板和PPT模板;一起交流工作难题、面试套路、职场经验、内推直通车公众号

    3、数据模型的评价标准

    数据模型建设的怎么样,极度依赖规范设计,如果代码风格是“千人千面”,那么恐怕半年下来,业务系统就没法看了。没有什么比“数据系统”更看重“法制”了,规范体系不仅能保障数据建设的一致性,也能够应对业务交接的情况,更能够为自动化奠定基础。

    1. 业务过程清晰:ODS就是原始信息,不修改;DWD面向基础业务过程;DIM描述维度信息;DWS针对最小场景做指标计算;ADS也要分层,面向跨域的建设,和面向应用的建设;
    2. 指标可理解:按照一定业务事务过程进行业务划分,明细层粒度明确、历史数据可获取,汇总层维度和指标同名同义,能客观反映业务不同角度下的量化程度;
    3. 核心模型相对稳定:如果业务过程运行的比较久,过程相对固定,就要尽快下沉到公共层,形成可复用的核心模型;
    4. 高内聚低耦合:各主题内数据模型要业务高内聚,避免在一个模型耦合其他业务的指标,造成该模型主题不清晰和性价比低。

    小编有话

    • 在传统企业数仓中,业务相对稳定,以范式建模为主。如电信、金融行业等
    • 在互联网公司,业务变化快,需求来来回回的改,计算和存储也不是问题,我们更关心快速便捷的满足业务需求,所以以维度建模为主。


     

    三、三种事实表

    事实表作为数据仓库维度建模的核心,紧紧围绕着业务过程来设 计,通过获取描述业务过程的度量来表达业务过程,包含了引用的维度 和与业务过程有关的度量。

    1、三种事实表概述

    事实表有三种类型 : 事务事实表、周期快照事实表累积快照事实表

    • 1.1 事务事实表

    也称原子事实表,描述业务过程,跟踪控件或时间上某点的度量事件,保存的是最原子的数据;

    个人理解:类似于mysql binlog日志,每一次相关的 change 都记录下来,生成一行新的数据

    • 1.2 周期快照事实表

    以一个周期为时间间隔,来记录事实,一般周期可以是每天、每周、每月、每年等;

    个人理解:只看某个业务过程,比如订单收货,数据按订单收货时间来切分,周期可以为每天、每月等。

    • 1.3 累积快照事实

    用来描述过程开始和结束之间的关键步骤事件,覆盖过程的整个生命周期,通常具有多个日期字段来记录关键时间点;当过程随着生命周期不断变化时,记录也会随着过程的变化而被修改;

    个人理解:要看整个生命周期的多个业务过程,比如:创建订单 → 买家付款 → 卖家发货 → 买家确认收货。粒度是一个订单一行数据,创建订单时间,付款时间,发货时间,收货时间,分别作为一个字段,便于计算不同业务过程的时间间隔。

    2、三种事实表对比

    事务事实表 

    周期快照事实表 

    累积快照事实表 

    时期/时间 

    离散事务时间点 

    以有规律的、可预测的 

    用于时间跨度不确定的不断变化的工作流 

    日期维度 

    事务日期 

    快照日期 

    相关业务过程涉及的多个日期 

    粒度

    每行代表实体的一个事务 

    每行代表某时间周期的一个实体 

    每行代表一个实体的生命周期 

    事实 

    事务事实

    累积事实

    相关业务过程事实和时间间隔事实 

    事实表加载 

    插入 

    插入 

    插入与更新 

    事实表更新 

    不更新 

    不更新 

    业务过程变更时更新 

    3、事实表设计 8 大原则

    • 原则 1:尽可能包含所有与业务过程相关的事实
      • 分析哪些事实与业务过程相关,是设计过程中非常重要的关注点;
      • 在事实表中,尽量包含所有与业务过程相关的事实,即使存在冗余,由于事实通常是数字型,存储开销不会太大;

    • 原则 2:只选择与业务过程相关的事实
      • 如,订单的下单这个业务过程,事实表中不应该存在支付金额这个表示支付业务过程的事实;

    • 原则 3:分解不可加性事实为可加的组件
      • 如,订单的优惠率,应分解为订单原价金额与订单优惠金额两个事实存储在事实表中;

    • 原则 4:在选择维度和事实之前必须先声明粒度
      • 因为原子粒度提供了最大限度的灵活性,可以支持无法预期的各种细节层次的用户需求;
      • 粒度用于确定事实表中一行所表示业务的细节层次,决定了维度模型的扩展性;
      • 每个维度和事实必须与所定义的粒度保持一致;
      • 设计事实表时,粒度定义越细越好,一般从最低级别的原子粒度开始;

    • 原则 5:在同一个事实表中不能有多种不同粒度的事实
      • 粒度为票一级;(实际业务中,一个订单可以同时支付多张票)
      • 票支付金额和票折扣金额,两个事实的粒度为 “票级”,与定义的粒度一致;
      • 订单支付金额和订单票数,两个事实的粒度为 “订单级”,属于上一层订单级数据,与 “票级” 事实表的粒度不一致,且不能进行汇总;
      • 如果,以订单金额和订单票数这两个维度汇总总金额和总票数,会造成大量的重复计算;
      • 疑问:怎么判断不同事实的粒度是否相同?

    • 原则 6:事实的单位要保持一致
      • 如,订单金额、订单优惠金额、订单运费这 3 个事实,应该采用统一的计量单位,统一为元或者分,以方便使用;

    • 原则 7:对事实的 null 值要处理
      • 原因:在数据库中,null 值对常用数字型字段的 SQL 过滤条件都不生效;如,大于、小于、等于、大于或等于、小于或等于;
      • 处理:用 0 代替 null ;

    • 原则 8:使用退化维度提高事实表的易用性
      • 易用性:对事实表,更较少关联操作、过滤查询、控制聚合层次、排序数据、定义主从关系等;
      1. 事实表中存储各种类型的常用维度信息,较少下游用户使用时关联多个表的操作;
      2. 通过退化维度,可以实现对事实表的过滤查询、控制聚合层次、排序数据、定义主从关系等;
    • 在 Kimball 的维度建模中,通常按照星形模型的方式设计,通过事实表的外键关联专门的维表,这种方式来获取维度,谨慎使用退化维表;这与大数据领域的事实表设计不一样;
      • 思路:通过增加冗余存储,减少计算开销,提高使用效率;

    4、事实表设计方法

    Kimball 的维度模型设计 4 步法:选择业务过程、声明粒度、确定维度、确定事实;

    当前的互联网大数据环境,维度模型的设计,是基于 Kimball 的四步维度建模方法进行了更进一步的改进:

    • 第一步:选择业务过程及确定事实表类型

      • 如淘宝的一个交易订单,选择 “买家付款” 这个业务过程,则事实表类型应为只包含买家付款这一个业务过程的 “单事务事实表”;
      • 如选择了所有 4 个业务过程,并且需要分享各业务过程的时间间隔,则事实表类型应为包含了所有 4 个业务过程的 “累积快照事实表”;
      • 如是选择 “买家付款” 这个业务过程,还是选择 “创建订单” 和 “买家付款” 这两个业务过程,具体根据业务情况来定;
      • 思路:详细分析需求,对业务的整个生命周期进行分析,明确关键的业务步骤,从而选择与需求有关的业务过程;
      • 以实例说明:如何选择业务过程?如何确定事实表类型?
      1. 分析业务的生命周期,业务过程通常使用行为动词表示业务执行的活动
      2. 明确关键的业务步骤:该订单流转的业务过程有 4 个:创建订单 买家付款 卖家发货 买家确认收货;
      3. 根据业务需求,选择与维度建模有关的业务过程;
      4. 根据所选的业务过程确定事实表类型;

    • 第二步:声明粒度

      • 粒度的作用:
      • 粒度的选择:尽量选择最细级别的原子粒度,以确保事实表的应用具有最大的灵活性;
      1. 灵活性:支持无法预期的各种细节层次的用户需求;
      2. 对于订单级别,粒度可以定义为最细的订单级别;(如,父子订单,事实表的粒度可以定 “子订单级别” ;)
      3. 粒度的声明,意味着精确定义事实表的每一行所表示的业务含义
      4. 明确的粒度能够确保对实表中行的意思的理解不会产生混淆,保证所有的事实按照同样的细节层次记录;

    • 第三步:确定维度

      • 如,淘宝订单 “付款事务事实表” 中,粒度为 “子订单”,相关的维度有买家、卖家、商品、收货人信息、业务类型、订单时间等;
      • 完成了粒度声明,就意味着确定了主键,对应的维度组合以及相关的维度字段也可以确定了;
      • 选择维度的原则:应该选择能够描述清楚业务过程所处的环境的维度信息;

    • 第四步:确定事实

      • 确定原则:选择与业务过程有关的所有事实,且事实的粒度要与所声明的事实表的粒度一致
      • 思路:可以通过回答 “过程的度量是什么” 来确定;
      • 注意:将不可加性事实分解为可加的组件;(分解的原则:可以通过分解后的可加的属性值,计算得到不可加性事实)

    四、多维体系结构

    在Kimball的维度建模的数据仓库中,关于多维体系结构(MD)有三个关键性概念:总线架构(Bus Architecture),一致性维度(Conformed Dimension)和一致性事实(Conformed Fact)。 

    1、总线架构

    多维体系结构(总线架构) 数据仓库领域里,有一种构建数据仓库的架构,叫Multidimensional Architecture(MD),中文一般翻译为“多维体系结构”,也称为“总线架构”(Bus Architecture)。

    多维体系结构的创始人是数据仓库领域中最有实践经验的Kimball博士。多维体系结构主要包括后台(Back Room)和前台(Front Room)两部分。后台也称为数据准备区(Staging Area),是MD架构的最为核心的部件。在后台,是一致性维度的产生、保存和分发的场所。同时,代理键也在后台产生。前台是MD架构对外的接口,包括两种主要的数据集市,一种是原子数据集市,另一种是聚集数据集市。

    原子数据集市保存着最低粒度的细节数据,数据以星型结构来进行数据存储。聚集数据集市的粒度通常比原子数据集市要高,和原子数据集市一样,聚集数据集市也是以星型结构来进行数据存储。前台还包括像查询管理、活动监控等为了提供数据仓库的性能和质量的服务。在多维体系结构中,所有的这些基于星型机构来建立的数据集市可以在物理上存在于一个数据库实例中,也可以分散在不同的机器上,而所有这些数据集市的集合组成的分布式的数据仓库。

    https://mmbiz.qpic.cn/mmbiz_png/Jy3qP5tic4icSUZPphtibOGia8NhkDFBViaPQQk9flT8rs9Jhb2XAVBbHZPWMDsGYzA4swIJjlF2a4rqfGxMiciaM1xQw/640?wx_fmt=png

    2、一致性维度 

    在多维体系结构中,没有物理上的数据仓库,由物理上的数据集市组合成逻辑上的数据仓库。而且数据集市的建立是可以逐步完成的,最终组合在一起,成为一个数据仓库。如果分步建立数据集市的过程出现了问题,数据集市就会变成孤立的集市,不能组合成数据仓库,而一致性维度的提出正式为了解决这个问题。

    一致性维度的范围是总线架构中的维度,即可能会在多个数据集市中都存在的维度,这个范围的选取需要架构师来决定。一致性维度的内容和普通维度并没有本质上区别,都是经过数据清洗和整合后的结果。 一致性维度建立的地点是多维体系结构的后台(Back Room),即数据准备区。

    在多维体系结构的数据仓库项目组内需要有专门的维度设计师,他的职责就是建立维度和维护维度的一致性。在后台建立好的维度同步复制到各个数据集市。这样所有数据集市的这部分维度都是完全相同的。建立新的数据集市时,需要在后台进行一致性维度处理,根据情况来决定是否新增和修改一致性维度,然后同步复制到各个数据集市。这是不同数据集市维度保持一致的要点。

    在同一个集市内,一致性维度的意思是两个维度如果有关系,要么就是完全一样的,要么就是一个维度在数学意义上是另一个维度的子集。

    例如,如果建立月维度话,月维度的各种描述必须与日期维度中的完全一致,最常用的做法就是在日期维度上建立视图生成月维度。这样月维度就可以是日期维度的子集,在后续钻取等操作时可以保持一致。如果维度表中的数据量较大,出于效率的考虑,应该建立物化视图或者实际的物理表。这样,维度保持一致后,事实就可以保存在各个数据集市中。虽然在物理上是独立的,但在逻辑上由一致性维度使所有的数据集市是联系在一起,随时可以进行交叉探察等操作,也就组成了数据仓库。

    3、一致性事实

    在建立多个数据集市时,完成一致性维度的工作就已经完成了一致性的80%-90%的工作量。余下的工作就是建立一致性事实。一致性事实和一致性维度有些不同,一致性维度是由专人维护在后台(Back Room),发生修改时同步复制到每个数据集市,而事实表一般不会在多个数据集市间复制。需要查询多个数据集市中的事实时,一般通过交叉探查(drill across)来实现。

    为了能在多个数据集市间进行交叉探查,一致性事实主要需要保证两点:第一个是KPI的定义及计算方法要一致,第二个是事实的单位要一致性。如果业务要求或事实上就不能保持一致的话,建议不同单位的事实分开建立字段保存。


     

          这样,一致性维度将多个数据集市结合在一起,一致性事实保证不同数据集市间的事实数据可以交叉探查,一个分布式的数据仓库就建成了。

    小遍有话

    • 总线矩阵:业务过程和维度的交点;
    • 一致性维度:同一集市的维度表,内容相同或包含;
    • 一致性事实:不同集市的同一事实,需保证口径一致,单位统一。

    追求一致性必然会增加开发工作量,但长期来说,使用方便、运维简单;一致性和性能之间,需要平衡。
     

    五、数据仓库规范设计

    1、为什么要进行规范设计

    无规矩、不方圆。规范设计是在具体开发工作之前制定的,过程中不断进行完善。目的在于约束 N 个人对齐认知,按照一个标准或流程进行开发,以保证数据一致性,流程清晰且稳定。

    一个良好的规范设计,应当起到以下作用:提高开发效率,提升质量,降低沟通对齐成本,降低运维成本等。

    下面西红柿🍅将带领大家盘一盘数据仓库有哪些规范,从中挑选几个重点细说:

    • 设计规范

                逻辑架构、技术架构、分层设计、主题划分、方法论

    •  命名规范

                各层级命名、任务命名、表命名、字段命名、指标命名等 

    • 模型规范

                建模方法、建模工具、血缘关系、维度退化、一致性维度、元数据管理

    • 开发规范

                脚本注释、字段别名、编码规范、脚本格式、数据类型、缩写规范 

    • 流程规范

                需求流程、工程流程、上线流程、调度流、调度和表生命周期管理

    2、设计规范 - 指标

    • Step1:面向主题域管理

    为了提高指标管理的效率,你需要按照业务线、主题域和业务过程三级目录方式管理指标。
     

    • Step2:划分原子指标和派生指标

    原子指标 + 原子指标  = 派生指标
     

    • Step3:进行指标命名规范

    需要遵循两个原则:易懂与统一

    1. 易懂,就是看到指标的名称,就可以基本判断这个指标归属于哪个业务过程;
    2. 统一,就是要确保派生指标和它继承的原子指标命名是一致的。

    对于原子指标,标名称适合用“动作 + 度量”的命名方式(比如注册用户数、购买用户数)

    对于派生指标,应该严格遵循“时间周期 + 统计粒度 + 修饰词 + 原子指标”的命名方式。(比如30天内黑卡会员购买用户数)

    • Step4:分级管理

    指标确实是多,如果一视同仁去管理其实很难,所以可以按照下面的原则进行等级划分

    1. 一级指标:数据中台直接产出,核心指标(提供给公司高层看的)、原子指标以及跨部门的派生指标。
    2. 二级指标:基于中台提供的原子指标,业务部门创建的派生指标。

    3、命名规范 - 表命名

    3.1 常规表

    常规表是我们需要固化的表,是正式使用的表,是目前一段时间内需要去维护去完善的表。

    规范:分层前缀[dwd|dws|ads|bi]_业务域_主题域_XXX_更新频率|全量/增量。 

    业务域、主题域我们都可以用词根的方式枚举清楚,不断完善,粒度也是同样的,主要的是时间粒度、日、月、年、周等,使用词根定义好简称。

    建议格式: dwd_xxx_xxx_da

    • di :每日增量
    • da:每日全量
    • mi:每月增量
    • ma:每月全量

    3.2 中间表

    中间表一般出现在Job中,是Job中临时存储的中间数据的表,中间表的作用域只限于当前Job执行过程中,Job一旦执行完成,该中间表的使命就完成了,是可以删除的(按照自己公司的场景自由选择,以前公司会保留几天的中间表数据,用来排查问题)。

    建议格式:mid_table_name_[0~9]

    table_name是我们任务中目标表的名字,通常来说一个任务只有一个目标表。这里加上表名,是为了防止自由发挥的时候表名冲突,而末尾大家可以选择自由发挥,起一些有意义的名字,或者简单粗暴,使用数字代替,各有优劣吧,谨慎选择。

    3.3 临时表

    临时表是临时测试的表,是临时使用一次的表,就是暂时保存下数据看看,后续一般不再使用的表,是可以随时删除的表。

    建议格式:tmp_xxx

    只要加上tmp开头即可,其他名字随意,注意tmp开头的表不要用来实际使用,只是测试验证而已。

    3.4 维度表

    维度表是基于底层数据,抽象出来的描述类的表。维度表可以自动从底层表抽象出来,也可以手工来维护。

    建议格式:dim_xxx

    维度表,统一以dim开头,后面加上,对该指标的描述,可以自由发挥。

    4、开发规范

    1

    表和列的注释释是否有缺失,复杂计算逻辑是否有注释释

    2

    任务是否支持多次重跑而输出不变,不能有insert into语句

    3

    分区表是否使用分区键过滤并且有有效裁剪

    4

    外连接的过逑条件是否使用正确,例如在左连接的where语句存在右表的过滤条件

    5

    关联小表,是否使用/*+ map join * / hint

    6

    不允许引用别的计算任务临时表

    7

    原则上不允许存在一个任务更新多个目标表

    8

    是否存在笞、迪卡尔积

    9

    禁止在代码里面使用drop 111ble、creat它111ble、renaiue 111ble、chan零column等ddl语句

    10

    使用动态分区时,有没有检查分区键值为NULL的情况

    11

    DQC质量监控规则是否配置,严禁棵奔

    12

    代码中有没有进行适当的规避数据倾斜语句

    13

    Where条件中is null语句有没有进行空字符串处理

    5、流程规范

    根据阿里流程规范,本文将数据仓库研发流程抽象为如下几点:

    1. 需求阶段:数据产品经理应如何应对不断变化的业务需求。
    2. 设计阶段:数据产品经理、数据开发者应如何综合性能、成本、效率、质量等因素,更好地组织与存储数据。
    3. 开发阶段:数据研发者如何高效、规范地进行编码工作。
    4. 测试阶段:测试人员应如何准确地暴露代码问题与项目风险,提升产出质量。
    5. 发布阶段:如何将具备发布条件的程序平稳地发布到线上稳定产出。
    6. 运维阶段:运维人员应如何保障数据产出的时效性和稳定性。

    https://mmbiz.qpic.cn/mmbiz_png/Jy3qP5tic4icSUZPphtibOGia8NhkDFBViaPQ8x2HXSKH6OjYUG1XFtbeYz1DMRuMkSDDf3hZnHibqMiaOlickib5xPgLOQ/640?wx_fmt=png

    六、元数据管理

    1、业务元数据

    1. 描述 ”数据”背后的业务含义
    2. 主题定义:每段 ETL、表背后的归属业务主题。
    3. 业务描述:每段代码实现的具体业务逻辑。
    4. 标准指标:类似于 BI 中的语义层、数仓中的一致性事实;将分析中的指标进行规范化。
    5. 标准维度:同标准指标,对分析的各维度定义实现规范化、标准化。
    6. 不断的进行维护且与业务方进行沟通确认。

    2、技术元数据

    • 数据源元数据

      • 例如:数据源的 IP、端口、数据库类型;数据获取的方式;数据存储的结构;原数据各列的定义及 key 指对应的值。

    • ETL 元数据

      • 根据 ETL 目的的不同,可以分为两类:数据清洗元数据数据处理元数据
      • 数据清洗,主要目的是为了解决掉脏数据及规范数据格式;因此此处元数据主要为:各表各列的"正确"数据规则;默认数据类型的"正确"规则。
      • 数据处理,例如常见的表输入表输出;非结构化数据结构化;特殊字段的拆分等。源数据到数仓、数据集市层的各类规则。比如内容、清理、数据刷新规则。

    • 数据仓库元数据

      • 数据仓库结构的描述,包括仓库模式、视图、维、层次结构及数据集市的位置和内容;业务系统、数据仓库和数据集市的体系结构和模式等。

    • BI 元数据

      • 汇总用的算法、包括各类度量和维度定义算法。数据粒度、主题领域、聚集、汇总、预定义的查询与报告。

    3、管理元数据

    管理领域相关,包括管理流程、人员组织、角色职责等。

    4、小编有话

    在日常工作中,元数据的管理主要体现在元数据的采集、存储、查询、应用几个方面。原则上应从规范化,到脚本化,到工具化的方向进行建设。

    • 采集:元数据采集时尽可能详细,真实,可通过工具生成或者勾选,避免手动录入带来不规范等问题
    • 存储:存储元数据要做到不失真,元数据变更时及时同步
    • 查询:通过网页或库表等方式,方便快捷的看到元数据,辅助进行开发
    • 应用:数据血缘、优化调度依赖、数据治理等


     

    七、维度表

    1、什么是维度表

    ​维度是维度建模的基础和灵魂。在维度建模中,将度量称为“事实” , 将环境描述为“维度”。

    维度表包含了事实表中指定属性的相关详细信息,最常用的维度表有日期维度、城市维度等。

    日期维表:

    num

    字段名

    字段中文名

    描述

    数据类型

    1

    date

    日期

    日期 yyyMMdd格式

    bigint

    2

    week

    星期,数字型

    星期,数字型 0-6

    bigint

    3

    week_cn

    星期中文名

    星期中文名 星期一……

    string

    4

    year_weeks

    一年中的第几周

    一年中的第几周 1 2 3……

    bigint

    5

    mon_dt

    本周周一日期

    本周周一日期

    bigint

    6

    sun_dt

    本周周日日期

    本周周日日期

    bigint

    7

    month

    年月

    年月,yyyyMM格式

    bigint

    8

    month_short

    月份简写

    月份简写,MM格式1~12

    bigint

    9

    month_cn

    月份中文名

    月份中文名 一月……

    string

    10

    quarter

    季度

    季度,yyyyQ1\2\3\4

    string

    11

    quarter_short

    季度 数字型

    季度 数字型 1-4

    bigint

    12

    quarter_cn

    季度中文名

    季度中文名 第一季度……

    string

    13

    year

    年份

    年份,yyyy格式

    bigint

    2、维度表设计原则

    维度的作用一般是查询约束、分类汇总以及排序等,我们在进行维度表设计时,应当提前考虑:


     

    1)维度属性尽量丰富,为数据使用打下基础

    比如淘宝商品维度有近百个维度属性,为下游的数据统计、分析、探查提供了良好的基础。

    2)给出详实的、富有意义的文字描述

    属性不应该是编码,而应该是真正的文字。在间里巴巴维度建模中, 一般是编码和文字同时存在,比如商品维度中的商品 ID 和商品标题、 类目 ID 和 类目名称等。ID 一 般用于不同表之间的关联,而名称一般用 于报表标签

    3)区分数值型属性和事实

    数值型宇段是作为事实还是维度属性,可以参考字段的一般用途。如果通常用于查询约束条件或分组统计,则是作为维度属性;如果通常 用于参与度量的计算, 则是作为事实。比如商品价格,可以用于查询约 束条件或统计价格区间 的商品数量,此时是作为维度属性使用的;也可 以用于统计某类目 下商品的平均价格,此时是作为事实使用的。另外, 如果数值型字段是离散值,则作为维度属性存在的可能性较大;如果数 值型宇段是连续值 ,则作为度量存在的可能性较大,但并不绝对,需要 同时参考宇段的具体用途。

    4)沉淀出通用的维度属性,为建立一致性维度做好铺垫

    有些维度属性获取需要进行比较复杂的逻辑处理,有些需要通过多表关联得到,或者通过单表 的不同宇段混合处理得到,或者通过对单表 的某个字段进行解析得到。此时,需要将尽可能多的通用的维度属性进 行沉淀。一方 面,可以提高下游使用的方便性,减少复杂度;另一方面,可以避免下游使用解析时由于各自逻辑不同而导致口径不 一致。

    5)退化维度(Degenerate Dimension

    在维度类型中,有一种重要的维度称作为退化维度。这种维度指的是直接把一些简单的维度放在事实表中。退化维度是维度建模领域中的一个非常重要的概念,它对理解维度建模有着非常重要的作用,退化维度一般在分析中可以用来做分组使用。

    6)缓慢变化维(Slowly Changing Dimensions

    维度的属性并不是始终不变的,它会随着时间的流逝发生缓慢的变化,这种随时间发生变化的维度我们一般称之为缓慢变化维(SCD),缓慢变化维一般使用代理健作为维度表的主健。


     

    推荐阅读缓慢变化维度的10种处理方式
     

    缓慢变化维

     TYPE1 直接覆盖原值

    适用于:不看历史数据,简单粗暴

    https://mmbiz.qpic.cn/mmbiz_jpg/Jy3qP5tic4icSUZPphtibOGia8NhkDFBViaPQ1qA7qcY7ia3c1htggyt8sPkC9fjv3u3eptX0ibkwviaic9YoYHR3BHLkkg/640?wx_fmt=jpeg

     TYPE2 拉链表

    需要在维度行再增加三列:有效日期、截止日期、行标识(可选)。

    在旧的一行数据增加关链时间(end_date),新的一行数据增加开链时间关链时间,多条数据加起来是一个完整的时间周期。

    https://mmbiz.qpic.cn/mmbiz_png/Jy3qP5tic4icSUZPphtibOGia8NhkDFBViaPQjLpBffAmpWfWbuFKvKuibU9JCpoicSapJ4CYx12AB4ODR31ctynAoyjw/640?wx_fmt=png

     TYPE3 增加属性列

    https://mmbiz.qpic.cn/mmbiz_png/Jy3qP5tic4icSUZPphtibOGia8NhkDFBViaPQbFA9wmtmkE35LwT6dJX1COG9EvuuSfgHbGm4wson8u2r7x4AYdr2jg/640?wx_fmt=png

    3、维度表设计方法

    • 第一步:选择维度或新建维度。作为维度建模的核心,在企业级数 据仓库中必须保证维度的唯一性。以淘宝商品维度为例,有且只允许有 一个维度定义。

    • 第二步:确定主维表。此处的主维表一般是 ODS 表,直接与业务 系统同步。以淘宝商品维度为例, s_auction_auctions 是与前台商品中心 系统同步的商品表,此表即是主维表。

    • 第三步:确定相关维表。数据仓库是业务源系统的数据整合,不同业务系统或者同 一业务系统中的表之间存在 关联性。根据对业务的梳 理,确定哪些表和主维表存在关联关系,并选择其中的某些表用于生成维度属性。

    • 第四步 :确定维度属性 。本步骤主要 包括两个阶段,其中第 一 个阶 段是从主维表 中选择维度属性或生成新的维度属性;第 二个阶段是从相 关维表中选择维度属性或生成新 的维度属性。以淘宝商品维度为例,从 主维表 (s_auction_auctions)和类目、 SPU、卖家、店铺等相关维表中 选择维度属性或生成新 的维度属性。


     

    八、三范式与反范式

    范式是符合某一种级别的关系模式的集合。构造数据库必须遵循一定的规则。在关系数据库中,这种规则就是范式。

           关系数据库中的关系必须满足一定的要求,即满足不同的范式。大数据生态中,各类强大的查询引擎层出不穷,相对廉价的磁盘和分布式技术,也让数据冗余变得可接受甚至更加方便。

           在创建一个数据库的过程中,范化是将其转化为一些表的过程,这种方法可以使从数据库得到的结果更加明确。这样可能使数据库产生重复数据,从而导致创建多余的表。范化是在识别数据库中的数据元素、关系以及定义所需的表和各表中的项目等这些初始工作之后的一个细化的过程。

    1、第一范式

    1NF要求属性具有原子性,即列不可再分解;

    表:字段1、 字段2(字段2.1、字段2.2)、字段3 ......

    如学生(学号,姓名,性别,出生年月日)

    有些钢筋可能要问西红柿了,姓名可以拆成姓、名两列, “出生年月日” 也可以拆成年、月、日三个字段。所以就不满足第一范式了!!!这里再强调一下原子性,原子性是根据使用方便来自定义的最小单位。中国人一般姓名一起用,美国就习惯姓名分别存两字段。

    2、第二范式

    2NF要求记录有惟一标识,即不存在部分依赖;

    简单来说就是拆表,以人为粒度做一张明细表,以课程号为粒度做一张维度表,两表关联使用,消除了数据冗余

    表:学号、课程号、姓名、学分;

    这个表明显说明了两个事务:学生信息, 课程信息;由于非主键字段必须依赖主键,这里学分依赖课程号姓名依赖与学号,所以不符合二范式。

    可能会存在问题:

    • 数据冗余:每条记录都含有相同信息;
    • 删除异常:删除所有学生成绩,就把课程信息全删除了;
    • 插入异常:学生未选课,无法记录进数据库;
    • 更新异常:调整课程学分,所有行都调整。

    正确做法: 
    学生:Student(学号, 姓名); 
    课程:Course(课程号, 学分); 
    选课关系:StudentCourse(学号, 课程号, 成绩)。

    3、第三范式

    3NF是对字段的冗余性,要求任何字段不能由其他字段派生出来,它要求字段没有冗余,即不存在传递依赖;

    表: 学号, 姓名, 年龄, 学院名称, 学院电话

    因为存在依赖传递: (学号) → (学生)→(所在学院) → (学院电话) 。

    可能会存在问题:

    • 数据冗余:有重复值;
    • 更新异常:有重复的冗余信息,修改时需要同时修改多条记录,否则会出现数据不一致的情况 。

    正确做法:

    学生:(学号, 姓名, 年龄, 所在学院);

    学院:(学院, 电话)。

    4、反范式化

    一般说来,数据库只需满足第三范式(3NF)就行了。

        没有冗余的数据库设计可以做到。但是,没有冗余的数据库未必是最好的数据库,有时为了提高运行效率,就必须降低范式标准,适当保留冗余数据。具体做法是:在概念数据模型设计时遵守第三范式,降低范式标准的工作放到物理数据模型设计时考虑。降低范式就是增加字段,允许冗余,达到以空间换时间的目的

      〖例〗:有一张存放商品的基本表,如表1所示。“金额”这个字段的存在,表明该表的设计不满足第三范式,因为“金额”可以由“单价”乘以“数量”得到,说明“金额”是冗余字段。但是,增加“金额”这个冗余字段,可以提高查询统计的速度,这就是以空间换时间的作法。

        在Rose 2002中,规定列有两种类型:数据列计算列。“金额”这样的列被称为“计算列”,而“单价”和“数量”这样的列被称为“数据列”。

    5、范式化设计和反范式化设计的优缺点

    5.1 范式化 (时间换空间)

    优点:

    • 范式化的表减少了数据冗余,数据表更新操作快、占用存储空间少。

    缺点:

    • 查询时需要对多个表进行关联,查询性能降低。 
    • 更难进行索引优化

    5.2 反范式化(空间换时间)

    反范式的过程就是通过冗余数据来提高查询性能,但冗余数据会牺牲数据一致性

    优点:

    • 可以减少表关联
    • 可以更好进行索引优化

    缺点:

    • 存在大量冗余数据
    • 数据维护成本更高(删除异常,插入异常,更新异常)

    6、OLAP和OLTP中范式设计

    OLAP 一般冗余比较多,以查询分析为主,这种一般都是采用反范式设计,以提高查询效率。更新一般是定时大批量数据插入。
     

    OLTP 则是尽可能消除冗余,以提高变更的效率。因为这种应用无时无刻不在频繁变化。

     

    九、数据仓库架构-Lambda和Kappa

    随着数据量的暴增数据实时性要求越来越高,以及大数据技术的发展驱动企业不断升级迭代,数据仓库架构方面也在不断演进,分别经历了以下过程:早期经典数仓架构 > 离线大数据架构 > Lambda > Kappa > 混合架构。

    架构

    组成

    特点

    经典数仓架构

    关系型数据库(mysql、oracle)为主

    数据量小,实时性要求低

    离线大数据架构

    hive,spark为主

    数据量大,实时性要求低

    Lambda

    hive,spark负责存量,strom/Flink负责实时计算

    数据量大,实时性要求高

    Kappa

    kafka、strom、Flink

    多业务,多数据源,事件型数据源

    混合架构

    ps.西红柿的举例若有不当,欢迎指正

    https://mmbiz.qpic.cn/mmbiz_png/Jy3qP5tic4icSUZPphtibOGia8NhkDFBViaPQ4X2cMia5VZPHdFc2rEBWrmz4xS7IJkqt1tKyArdeba8kuS1f9TJulbA/640?wx_fmt=png

    1、Lambda架构原理

    Lambda架构的核心思想是把大数据系统拆分成三层:Batch LayerSpeed LayerServing Layer。其中,Batch Layer负责数据集存储以及全量数据集的预查询。


     

    Speed Layer主要负责对增量数据进行计算,生成Realtime Views。Serving Layer用于响应用户的查询请求,它将Batch Views和Realtime Views的结果进行合并,得到最后的结果,返回给用户,如下图:
     

    https://mmbiz.qpic.cn/mmbiz_png/Jy3qP5tic4icSUZPphtibOGia8NhkDFBViaPQZoAOTNNyDb86HhouCRWBr8ypDIe0lYb1L62WdvpibnceYqoxSoM7qIQ/640?wx_fmt=png

    2、Lambda架构的缺点

    Lambda架构解决了大数据量下实时计算的问题,但架构本身也存在一定缺点。

    • 实时与批量计算结果不一致引起的数据口径问题:因为批量和实时计算走的是两个计算框架和计算程序,算出的结果往往不同,经常看到一个数字当天看是一个数据,第二天看昨天的数据反而发生了变化。
    • 批量计算在计算窗口内无法完成:在IOT时代,数据量级越来越大,经常发现夜间只有4、5个小时的时间窗口,已经无法完成白天20多个小时累计的数据,保证早上上班前准时出数据已成为每个大数据团队头疼的问题。
    • 开发和维护的复杂性问题:Lambda 架构需要在两个不同的 API(application programming interface,应用程序编程接口)中对同样的业务逻辑进行两次编程:一次为批量计算的ETL系统,一次为流式计算的Streaming系统。针对同一个业务问题产生了两个代码库,各有不同的漏洞。这种系统实际上非常难维护
    • 服务器存储大:数据仓库的典型设计,会产生大量的中间结果表,造成数据急速膨胀,加大服务器存储压力。

    3、Kappa架构原理

    Kappa架构的核心思想包括以下三点:

    • 用Kafka或者类似的分布式队列系统保存数据,你需要几天的数据量就保存几天。
    • 当需要全量重新计算时,重新起一个流计算实例,从头开始读取数据进行处理,并输出到一个新的结果存储中。
    • 当新的实例做完后,停止老的流计算实例,并把老的一些结果删除。

    • https://mmbiz.qpic.cn/mmbiz_png/Jy3qP5tic4icSUZPphtibOGia8NhkDFBViaPQO33xBudXgbEVlhjv1nEu5SNtYy0plCDcwa3CGK63a01U7Wv1Mm0qXA/640?wx_fmt=png

    • 在Kappa架构下,只有在有必要的时候才会对历史数据进行重复计算,并且实时计算和批处理过程使用的是同一份代码。

    4、Lambda架构和Kappa架构优缺点对比

    项目

    Lambda

    Kappa

    数据处理能力

    可以处理超大规模的历史数据

    历史数据处理的能力有限

    机器开销

    批处理和实时计算需一直运行,机器开销大

    必要时进行全量计算,机器开销相对较小

    存储开销

    只需要保存一份查询结果,存储开销较小

    需要存储新老实例结果,存储开销相对较大

    开发、测试难度

    实现两套代码,开发、测试难度较大

    只需面对一个框架,开发、测试难度相对较小

    运维成本

    维护两套系统,运维成本大

    只需维护一个框架,运维成本小

    5、数据架构评价标准

    • 响应速度:数据架构的主要场景包括:业务开发、数据产品、运营分析三大类,不论是那种场景,数据架构均应该在尽可能短的时间内响应需求;

    • 可复用性:只有复用能力上来了,响应速度才能提上来,体现在下游依赖、调用次数、核心字段覆盖率等指标上;
    • 稳定性:除了日常任务不出问题以外,一旦发现了问题,能在多短的时间内定位和恢复问题,就非常重要;
    • 健壮性:除了电商等已经耕耘多年的领域外,绝大多数业务模型,都会快速的变化,如何适应这种变化,就非常考验架构功底。

    6、小编有话

    • Lambda 将全量历史数据和实时增量数据合并输出。
    • Kappa 两个流协作输出,queries每次使用最新一个流处理结果

    目前很多准实时增量批处理方案也能满足实时性需求,从稳定性和运维成本上也表现更佳。

    比如kudu(存储)+impala(计算)准实时方案,可以实现千万级数据的增量更新和olap查询,性能优异。
     

    十、数据治理(目的、方法、流程)

    1、什么是数据治理

    数据治理(Data Governance)是组织中涉及数据使用的一整套管理行为。由企业数据治理部门发起并推行,关于如何制定和实施针对整个企业内部数据的商业应用和技术管理的一系列政策和流程。

    数据的质量直接影响着数据的价值,并且直接影响着数据分析的结果以及我们以此做出的决策的质量。

    我们常说,用数据说话,用数据支撑决策管理,但低质量的数据、甚至存在错误的数据,必然会"说假话"!!!数据治理即提高数据的质量,发挥数据资产价值

    2、数据治理的目的

    • 降低风险
    • 建立数据使用内部规则
    • 实施合规要求
    • 改善内部和外部沟通
    • 增加数据价值
    • 方便数据管理
    • 降低成本
    • 通过风险管理和优化来帮助确保公司的持续生存

    3、数据治理的方法

    从技术实施角度看,数据治理包含”“”“”“”“这五个步骤,即业务和数据资源梳理、数据采集清洗、数据库设计和存储、数据管理、数据使用。 

    数据资源梳理:数据治理的第一个步骤是从业务的视角厘清组织的数据资源环境和数据资源清单,包含组织机构、业务事项、信息系统,以及以数据库、网页、文件和 API 接口形式存在的数据项资源,本步骤的输出物为分门别类的数据资源清单。

    数据采集清洗:通过可视化的 ETL 工具(例如阿里的 DataX,Pentaho Data Integration)将数据从来源端经过抽取 (extract)、转换 (transform)、加载 (load) 至目的端的过程,目的是将散落和零乱的数据集中存储起来。

    基础库主题库建设:一般情况下,可以将数据分为基础数据、业务主题数据和分析数据。基础数据一般指的是核心实体数据,或称主数据,例如智慧城市中的人口、法人、地理信息、信用、电子证照等数据。主题数据一般指的是某个业务主题数据,例如市场监督管理局的食品监管、质量监督检查、企业综合监管等数据。而分析数据指的是基于业务主题数据综合分析而得的分析结果数据,例如市场监督管理局的企业综合评价、产业区域分布、高危企业分布等。那么基础库和主题库的建设就是在对业务理解的基础上,基于易存储、易管理、易使用的原则抽像数据存储结构,说白了,就是基于一定的原则设计数据库表结构,然后再根据数据资源清单设计数据采集清洗流程,将整洁干净的数据存储到数据库或数据仓库中。

    元数据管理:元数据管理是对基础库和主题库中的数据项属性的管理,同时,将数据项的业务含义与数据项进行了关联,便于业务人员也能够理解数据库中的数据字段含义,并且,元数据是后面提到的自动化数据共享、数据交换和商业智能(BI)的基础。需要注意的是,元数据管理一般是对基础库和主题库中(即核心数据资产)的数据项属性的管理,而数据资源清单是对各类数据来源的数据项的管理。

    血缘追踪:数据被业务场景使用时,发现数据错误,数据治理团队需要快速定位数据来源,修复数据错误。那么数据治理团队需要知道业务团队的数据来自于哪个核心库,核心库的数据又来自于哪个数据源头。我们的实践是在元数据和数据资源清单之间建立关联关系,且业务团队使用的数据项由元数据组合配置而来,这样,就建立了数据使用场景与数据源头之间的血缘关系。数据资源目录:数据资源目录一般应用于数据共享的场景,例如政府部门之间的数据共享,数据资源目录是基于业务场景和行业规范而创建,同时依托于元数据和基础库主题而实现自动化的数据申请和使用。

    质量管理:数据价值的成功发掘必须依托于高质量的数据,唯有准确、完整、一致的数据才有使用价值。因此,需要从多维度来分析数据的质量,例如:偏移量、非空检查、值域检查、规范性检查、重复性检查、关联关系检查、离群值检查、波动检查等等。需要注意的是,优秀的数据质量模型的设计必须依赖于对业务的深刻理解,在技术上也推荐使用大数据相关技术来保障检测性能和降低对业务系统的性能影响,例如 Hadoop,MapReduce,HBase 等。

    商业智能(BI:数据治理的目的是使用,对于一个大型的数据仓库来说,数据使用的场景和需求是多变的,那么可以使用 BI 类的产品快速获取需要的数据,并分析形成报表,比较知名的产品有 Microsoft Power BI,QlikView,Tableau,帆软等。

    数据共享交换:数据共享包括组织内部和组织之间的数据共享,共享方式也分为库表、文件和 API 接口三种共享方式,库表共享比较直接粗暴,文件共享方式通过 ETL 工具做一个反向的数据交换也就可以实现。我们比较推荐的是 API 接口共享方式,在这种方式下,能够让中心数据仓库保留数据所有权,把数据使用权通过 API 接口的形式进行了转移。API 接口共享可以使用 API 网关实现,常见的功能是自动化的接口生成、申请审核、限流、限并发、多用户隔离、调用统计、调用审计、黑白名单、调用监控、质量监控等等。

    4、数据质量8个衡量标准

    • 数据的准确性

    数据采集值或者观测值和真实值之间的接近程度,也叫做误差值,误差越大,准确度越低。

    • 数据的精确性

    指对同一对象的观测数据在重复测量时所得到不同数据间的接近程度。

    • 数据的真实性
    • 数据的及时性

    数据能否在需要的时候得到保证,比如月初的财务对账,能不能在月初就完成

    • 数据的即时性

    指数据采集时间节点和数据传输的时间节点,一个数据在数据源头采集后立即存储,并立即加工呈现,就是即时数据,而经过一段时间之后再传输到信息系统中,则数据即时性就稍差。

    • 数据的完整性

    应采集和实际采集到数据之间的比例。

    • 数据的全面性

    完整性衡量的是应采集和实际采集的差异。而全面性指的是数据采集点的遗漏情况。

    • 数据的关联性

    指各个数据集之间的关联关系。比如员工工资数据和员工绩效考核数据是通过员工这个资源关联在一起来的。

    信息技术智库关注领取技术资料、面试真题、简历模板和PPT模板;一起交流工作难题、面试套路、职场经验、内推直通车公众号

    5、数据治理流程

    https://mmbiz.qpic.cn/mmbiz_png/Jy3qP5tic4icT2evG4mmN199tTlibT6WE0kVhEic4GWibqkIyxGpic0uCibZeqo393RvPWlXhQOMEqUcAg0quj01joQfA/640?wx_fmt=png

    基本流程:发现数据质量问题 > 定义数据质量规则 > 质量控制 > 质量评估 > 质量优化
     

    十一、ETL

    1、什么是ETL

    ETL,是英文Extract-Transform-Load的缩写,用来描述将数据从来源端经过抽取(extract)、转换(transform)、加载(load)至目的端的过程,是数据仓库的生命线。

           抽取(Extract主要是针对各个业务系统及不同服务器的分散数据,充分理解数据定义后,规划需要的数据源及数据定义,制定可操作的数据源,制定增量抽取和缓慢渐变的规则。

           转换(transform主要是针对数据仓库建立的模型,通过一系列的转换来实现将数据从业务模型到分析模型,通过ETL工具可视化拖拽操作可以直接使用标准的内置代码片段功能、自定义脚本、函数、存储过程以及其他的扩展方式,实现了各种复杂的转换,并且支持自动分析日志,清楚的监控数据转换的状态并优化分析模型。

    装载(Load主要是将经过转换的数据装载到数据仓库里面,可以通过直连数据库的方式来进行数据装载,可以充分体现高效性。在应用的时候可以随时调整数据抽取工作的运行方式,可以灵活的集成到其他管理系统中。

    2、ETL & ELT

    伴随着数据仓库的发展(传送门:数据仓库的八个发展阶段),数据量从小到大,数据实时性从T+1到准实时、实时,ETL也在不断演进。

     

    • 在传统数仓中,数据量小,计算逻辑相对简单,我们可以直接用ETL工具实现数据转换(T),转换之后再加载到目标库,即(Extract-Transform-Load)。

    • 但在大数据场景下,数据量越大越大,计算逻辑愈发复杂,数据清洗需放在运算能力更强的分布式计算引擎中完成,ETL也就变成了ELT(Extract-Load-Transform)。

    即:Extract-Transform-Load  >>  Extract-Load-Transform

    通常我们所说的ETL,已经泛指数据同步、数据清洗全过程,而不仅限于数据的抽取-转换-加载。

    3、常用的ETL工具

    下面小编将介绍几类ETL工具(sqoop,DataX,Kettle,canal,StreamSets)。

    3.1 sqoop

    • 是Apache开源的一款在Hadoop和关系数据库服务器之间传输数据的工具。
    • 可以将一个关系型数据库(MySQL ,Oracle等)中的数据导入到Hadoop的HDFS中,也可以将HDFS的数据导出到关系型数据库中。
    • sqoop命令的本质是转化为MapReduce程序。
    • sqoop分为导入(import)和导出(export),
    • 策略分为table和query
    • 模式分为增量和全量。

    https://mmbiz.qpic.cn/mmbiz_png/Jy3qP5tic4icSUZPphtibOGia8NhkDFBViaPQnA0yZMLxKRa7gXcbjXWfzoEMQMncdZZ7nT2d4ibgwcjsjJAIiavdcs3g/640?wx_fmt=png

    https://mmbiz.qpic.cn/mmbiz_jpg/Jy3qP5tic4icSUZPphtibOGia8NhkDFBViaPQjhaq786n4DAqRnpDLcFVLicUXGNIs2KtNUKOIj5rHQk5UhD4VtMZfFA/640?wx_fmt=jpeg

    3.2 DataX

    • DataX 是阿里巴巴集团内被广泛使用的离线数据同步工具/平台
    • 实现包括 MySQL、Oracle、SqlServer、Postgre、HDFS、Hive、ADS、HBase、TableStore(OTS)、MaxCompute(ODPS)、DRDS 等各种异构数据源之间高效的数据同步功能。

    https://mmbiz.qpic.cn/mmbiz_png/Jy3qP5tic4icSUZPphtibOGia8NhkDFBViaPQ2z5OF8icXcIibzBicDPlzFMBu6n7HmTGibu6c2TgiboXMB3TXWSmPGPGasw/640?wx_fmt=png

    3.3 Kettle

    • 一款国外免费开源的、可视化的、功能强大的ETL工具,纯java编写,可以在Windows、Linux、Unix上运行,数据抽取高效稳定。

    3.4 canal

    • canal是阿里巴巴旗下的一款开源项目,纯Java开发。基于数据库增量日志解析,提供增量数据实时订阅和消费,目前主要支持了MySQL,也支持mariaDB。

    https://mmbiz.qpic.cn/mmbiz_png/Jy3qP5tic4icSUZPphtibOGia8NhkDFBViaPQOEfD9nvZNfh23YscISVg2WfmZ7gNibIyAaugosmicT0zCfqS9slGkg6Q/640?wx_fmt=png

    3.5 StreamSets

    • 是大数据实时采集ETL工具,可以实现不写一行代码完成数据的采集和流转。通过拖拽式的可视化界面,实现数据管道(Pipelines)的设计和定时任务调度。
    • 创建一个Pipelines管道需要配置数据源(Origins)、操作(Processors)、目的地(Destinations)三部分。

    4、ETL加载策略

    4.1 增量

    • 有些表巨大,我们需要选择增量策略,新增delta数据需要和存量数据merge合并。

    只有新增(full join。能拿更新表就拿更新表)

    https://mmbiz.qpic.cn/mmbiz_png/Jy3qP5tic4icSUZPphtibOGia8NhkDFBViaPQicaxNmdEbWvh9aZpRgFiaicIp0jZ3Ot9dRHibIkfWHtkSUlTYXKcCn0lgA/640?wx_fmt=png

    • 新增+删除
      • history-table Left join delet-table where delect-table.value is null == 表a
      • 表a full join update-table (能拿update就拿update)

    https://mmbiz.qpic.cn/mmbiz_png/Jy3qP5tic4icSUZPphtibOGia8NhkDFBViaPQPD50eHPmrbjkt54ibibuOIYzgF6m4AkKFfBRys1XV9K7ZEU6MQZEfcjQ/640?wx_fmt=png

    4.2 全量

    每天一个全量表,也可一个hive天分区一个全量。

    4.3 流式

    使用kafka,消费mysql binlog日志到目标库,源表和目标库是1:1的镜像。

    5、小编有话

    无论是全量还是增量的方式,都会浪费多余的存储或通过计算去重,得到最新的全量数据。为解决这一问题,西红柿墙裂建议kafka的数据同步方案,源表变化一条,目标表消费一条,目标表数据始终是一份最新全量数据,且为实时同步的。 


     

    ps.极端情况下可能会丢数,需要写几个监控脚本(详见上文数据质量部分)和补数脚本即可~

     

    十二、数据应用-OLAP

    1、olap和oltp的区别

    OLTP

    OLAP

    对象

    业务开发人员

    分析决策人员

    功能

    日常事务处理

    面向分析决策

    模型

    关系模型

    多维模型

    数据量

    几条或几十条记录

    >百万于万条记录

    操作类型

    增、删、查、改(CRUD)

    查询为主

    总体概括

    联机事务处理

    在线分析处理

    2、OLAP分类

    • MOLAP基于多维数组的存储模型,也是OLAP最初的形态,特点是对数据进行预计算,以空间换效率,明细和聚合数据都保存在cube。但生成cube需要大量时间和空间。

    • ROLAP基于关系模型进行存储数据,不需要预计算,按需即时查询。明细和汇总数据都保存在关系型数据库事实表中。其特点是与事务实体对应,关系清晰;但一般需要较为复杂的数据准备。在响应前端需求时,一般较快,但取决于计算引擎能力。

    • HOLAP,混合模型,细节数据以ROLAP存放,聚合数据以MOLAP存放。这种方式相对灵活,且更加高效。可按企业业务场景和数据粒度进行取舍,没有最好,只有最适合。

    https://mmbiz.qpic.cn/mmbiz_jpg/Jy3qP5tic4icSUZPphtibOGia8NhkDFBViaPQePa7Lmibficd4hujUunO2E3aftVa5dFc2aKzR2f13NM3vfNfRyIOuIicA/640?wx_fmt=jpeg

    3、OLAP基本操作

    • 钻取:维的层次变化,从粗粒度到细粒度,汇总数据下钻到明细数据。如通过季度销售数据钻取每个月的销售数据。

    • 上卷:钻取的逆,向上钻取。从细粒度到粗粒度,细粒度数据到不同维层级的汇总。eg. 通过每个月的销售数据汇总季度、年销售数据。
    • 切片特定维数据(剩余维两个)。eg. 只选电子产品销售数据。

    • 切块维区间数据(剩余维三个)。eg. 第一季度到第二季度销售数据。

    • 旋转维位置互换(数据行列互换),通过旋转可以得到不同视角的数据。

    https://mmbiz.qpic.cn/mmbiz_png/Jy3qP5tic4icSUZPphtibOGia8NhkDFBViaPQNheDVKGZExDtl0sibo0N5HC6hCVzXBW0XVB3wHXCL4ssHCA6w53DkOA/640?wx_fmt=png

    4、OLAP选型

    4.1 druid

    • 实时查询和分析的高容错、高性能开源分布式系统,用于解决如何在大规模数据集下进行快速的、交互式的查询和分析。
    • 实时的数据消费,真正做到数据摄入实时、查询结果实时。
    • 扩展性强,支持 PB 级数据
    • 极高的高可用保障,支持滚动升级。
    • druid属于时间存储,删除操作比较繁琐,且不支持查询条件删除数据,只能根据时间范围删除数据。Druid能接受的数据的格式相对简单,比如不能处理嵌套结构的数据。

    4.2 kylin

    • 可扩展超快olap引擎,Hadoop/Spark上百亿数据规模
    • 提供 Hadoop ANSI SQL 接口
    • 交互式查询能力,用户可以与Hadoop数据进行亚秒级交互
    • 百亿以上数据集构建多维立方体(MOLAP CUBE)
    • 与BI工具无缝整合,如Tableau,PowerBI/Excel,MSTR,QlikSense,Hue和SuperSet


     

    十三、数据倾斜

    1、数据倾斜表现

    1.1 hadoop中的数据倾斜表现

    • 有一个多几个Reduce卡住,卡在99.99%,一直不能结束。
    • 各种container报错OOM
    • 异常的Reducer读写的数据量极大,至少远远超过其它正常的Reducer
    • 伴随着数据倾斜,会出现任务被kill等各种诡异的表现。


     

    1.2 hive中数据倾斜

    一般都发生在Sql中group by和join on上,而且和数据逻辑绑定比较深。
     

    1.3 Spark中的数据倾斜

    Spark中的数据倾斜,包括Spark Streaming和Spark Sql,表现主要有下面几种:

    • Executor lost,OOM,Shuffle过程出错;
    • Driver OOM;
    • 单个Executor执行时间特别久,整体任务卡在某个阶段不能结束;
    • 正常运行的任务突然失败;

    2、数据倾斜产生原因

    我们以Spark和Hive的使用场景为例。

    在做数据运算的时候会涉及到,count distinct、group by、join on等操作,这些都会触发Shuffle动作。一旦触发Shuffle,所有相同key的值就会被拉到一个或几个Reducer节点上,容易发生单点计算问题,导致数据倾斜。
     

    一般来说,数据倾斜原因有以下几方面:

    1)key分布不均匀;

    2)建表时考虑不周

    举一个例子,就说数据默认值的设计吧,假设我们有两张表:

        user(用户信息表):userid,register_ip

        ip(IP表):ip,register_user_cnt

    这可能是两个不同的人开发的数据表。如果我们的数据规范不太完善的话,会出现一种情况:

    user表中的register_ip字段,如果获取不到这个信息,我们默认为null;

    但是在ip表中,我们在统计这个值的时候,为了方便,我们把获取不到ip的用户,统一认为他们的ip为0。
     

    两边其实都没有错的,但是一旦我们做关联了,这个任务会在做关联的阶段,也就是sql的on的阶段卡死。
     

    3)业务数据激增

    比如订单场景,我们在某一天在北京和上海两个城市多了强力的推广,结果可能是这两个城市的订单量增长了10000%,其余城市的数据量不变。
     

    然后我们要统计不同城市的订单情况,这样,一做group操作,可能直接就数据倾斜了。
     

    3、解决数据倾斜思路

    很多数据倾斜的问题,都可以用和平台无关的方式解决,比如更好的数据预处理异常值的过滤等。因此,解决数据倾斜的重点在于对数据设计和业务的理解,这两个搞清楚了,数据倾斜就解决了大部分了。

    1)业务逻辑

    我们从业务逻辑的层面上来优化数据倾斜,比如上面的两个城市做推广活动导致那两个城市数据量激增的例子,我们可以单独对这两个城市来做count,单独做时可用两次MR,第一次打散计算,第二次再最终聚合计算。完成后和其它城市做整合。

    2)程序层面

    比如说在Hive中,经常遇到count(distinct)操作,这样会导致最终只有一个Reduce任务。

    我们可以先group by,再在外面包一层count,就可以了。比如计算按用户名去重后的总用户量:
     

    (1)优化前 

    只有一个reduce,先去重再count负担比较大:

    select name,count(distinct name)from user;

    (2)优化后

    // 设置该任务的每个job的reducer个数为3个。Hive默认-1,自动推断。

    set mapred.reduce.tasks=3;

    // 启动两个job,一个负责子查询(可以有多个reduce),另一个负责count(1):

    select count(1) from (select name from user group by name) tmp;
     

    3)调参方面

    Hadoop和Spark都自带了很多的参数和机制来调节数据倾斜,合理利用它们就能解决大部分问题。
     

    4)从业务和数据上解决数据倾斜

    很多数据倾斜都是在数据的使用上造成的。我们举几个场景,并分别给出它们的解决方案。
     

    一个原则:尽早过滤每个阶段的数据量。

    1. 数据有损的方法:找到异常数据,比如ip为0的数据,过滤掉。
    2. 数据无损的方法:对分布不均匀的数据,单独计算。
    3. hash:先对key做一层hash,先将数据随机打散让它的并行度变大,再汇聚。
    4. 数据预处理:就是先做一层数据质量处理,类似于数据仓库维度建模时,底层先处理数据质量。

    添加公众号「信息技术智库」:

    🍅 硬核资料:20G,8大类资料,关注即可领取(PPT模板、简历模板、技术资料)
    🍅 技术互助:技术群大佬指点迷津,你的问题可能不是问题,求资源在群里喊一声。
    🍅 面试题库:由各个技术群小伙伴们共同投稿,热乎的大厂面试真题,持续更新中。
    🍅 知识体系:含编程语言、算法、大数据生态圈组件(Mysql、Hive、Spark、Flink)、数据仓库、前端等。

    👇👇送书抽奖丨技术互助丨粉丝福利👇👇

    展开全文
  • 达梦数据库主搭建,又称达梦数据库数据守护搭建,适合新手练习,自己搭建主,与oracle的DG,和mysql的主是相同的作用,在达梦数据库中额外有一个监视器的概念
  • DM数据守护介绍 实时主集群同步机制 实时主集群切换机制

    DM数据守护介绍

    1. DM 数据守护(Data Watch)
    是一种集成化的高可用、高性能数据库解决方案,是数据库异地容灾的首选方案。通过部署 DM 数据守护,可以在硬件故障(如磁盘损坏)、自然灾害(地震、火灾)等极端情况下,避免数据损坏、丢失,保障数据安全,并且可以快速恢复数据库服务,满足用户不间断提供数据库服务的要求。与常规的数据库备份(Backup)、还原(Restore)技术相比,数据守护可以更快地恢复数据库服务。随着数据规模不断增长,通过还原手段恢复数据,往往需要数个小时、甚至更长时间,而数据守护基本不受数据规模的影响,只需数秒时间就可以将备库切换为主库对外提供数据库服务。
    3. 实时主备
    由一个主库以及一个或者多个配置了实时(Realtime)归档的备库组成,其主要目的是保障数据库可用性,提高数据安全性。实时主备系统中,主库提供完整的数据库功能,备库提供只读服务。主库修改数据产生的Redo日志,通过实时归档机制,在写入联机Redo日志文件之前发送到备库,实时备库通过重演Redo日志与主库保持数据同步。当主库出现故障时,备库在将所有Redo日志重演结束后,就可以切换为主库对外提供数据库服务。

    一、 实时主备集群同步机制

    1. 概念
      达梦数据库主备集群中主库与备库进行同步需要了解以下几点:
      (1)主库
      Primary 模式,提供完整数据库服务的实例,一般来说主库是用来直接支撑应用系统的生产库。

      (2)备库
      Standby 模式,提供只读数据库服务的实例。备库除了用于容灾,还可以提供备份、查询等只读功能,并且备库还支持临时表的 Insert/Delete/Update 操作。

      (3)MAL 系统
      MAL 系统是基于 TCP 协议实现的一种内部通信机制,具有可靠、灵活、高效的特性。
      DM 通过 MAL 系统实现 Redo 日志传输,以及其他一些实例间的消息通讯。

      (4)Redo 日志
      Redo 日志包含了所有物理数据页的修改内容,Insert/delete/update 等 DML 操作、Create Table 等 DDL 操作,最终都会转化为对物理数据页的修改,这些修改都会反映到 Redo 日志中。

      (5)Redo 日志包(RLOG_PKG)
      Redo 日志包(RLOG_PKG)是 DM 数据库批量保存物理事务产生的 Redo 日志的数据单元,以物理事务 PTX 为单位保存日志,一个日志包内可连续保存一个或多个 PTX。日志包具有自描述的特性,日志包大小不固定,采用固定包头和可变包头结合的方式,包头记录日志的控制信息,包括类型、长度、包序号、LSN 信息、产生日志的节点号、加密压缩信息、日志并行数等内容。

      日志包生成时按照序号连续递增,相邻日志包的 LSN 顺序是总体递增的,但是在多节点集群的 DSC 环境下不一定连续。如果未开启并行日志,RLOG_PKG 包内日志的 LSN 是递增的。如果开启并行日志,一个 RLOG_PKG 包内包含多路并行产生的日志,每一路并行日志的 LSN 是递增的,但是各路之间并不能保证 LSN 有序,因此并行日志包内 LSN 具有局部有序,整体无序的特点。

      物理事务提交时将 Redo 日志写入到日志包中,在数据库事务提交或日志包被写满时触发日志刷盘动作。日志刷盘线程负责将日志包中的 Redo 日志写入联机日志文件,如果配置了 Redo 日志归档,日志刷盘线程还将负责触发归档动作。DM 数据守护系统中,主库以RLOG_PKG 为最小单位发送 Redo 日志到备库。

      RLOG_PKG 具有自描述、自校验特征,数据的组织形式更加灵活、高效,支持 HUGE 表操作产生 Redo 日志,并且支持以 RLOG_PKG 为单位进行日志加密和压缩。

      (6)Redo 日志传输
      主备库之间的 Redo 日志传输,以日志包 RLOG_PKG 为单位,主库通过 MAL 系统发送Redo 日志到备库。各种不同数据守护类型的区别,就在于主库日志包 RLOG_PKG 的发送时机,以及备库收到 Redo 日志后的处理策略。

      (7)KEEP_PKG 介绍
      主库的RLOG_PKG日志通过实时归档机制发送到备库后,备库将最新收到的RLOG_PKG保存在内存中,不马上启动重演,这个 RLOG_PKG 我们称之为 KEEP_PKG

      (8)Redo 日志重演
      Redo 日志重演的过程,就是备库收到主库发送的 Redo 日志后,在物理数据页上,重新修改数据的过程。Redo 日志重演由专门的 Redo 日志重演服务完成,重演服务严格按照Redo 日志产生的先后顺序,解析 Redo 日志、修改相应的物理数据页,并且重演过程中备库会生成自身的 Redo 日志写入联机日志文件。

      (9)本地归档
      本地归档(Local),就是将 Redo 日志写入到本地归档日志文件的过程。本地归档在 REDO 日志写入联机日志文件后触发,由归档线程完成本地归档动作;与联机 Redo 日志文件可以被覆盖重用不同,本地归档日志文件不能被覆盖,写入其中的 Redo 日志信息会一直保留,直到用户主动删除;如果配置了归档日志空间上限,系统会自动删除最早生成的归档 Redo 日志文件,腾出空间。

      配置本地归档情况下,Normal/Primary 模式库在 Redo 日志写入联机 Redo 日志文件后,将对应的 RLOG_PKG 由专门的归档线程写入本地归档日志文件中。Standby 模式库收到主库产生的 Redo 日志后,直接进行本地归档,写入本地归档日志文件中,同时启动 Redo 日 志重演。

      Normal/Primary 模式库归档日志文件保存的是当前节点产生的 Redo 日志,归档日志文件内容与联机日志内容保持一致。Standby 模式库重演日志重新产生的 Redo 日志只写入联机日志文件,归档日志文件保存主库产生的 Redo 日志,因此备库联机日志文件内容和归档日志文件内容是不完全一致的。采用这种归档实现方式后,可以确保数据守护系统中所有节点的归档日志文件内容是完全一致的。

      (6)实时归档
      与本地归档写入保存在磁盘中的日志文件不同,实时归档(Realtime)将主库产生的Redo 日志通过 MAL 系统传递到备库,实时归档是实时主备和 MPP 主备的实现基础。实时 归档只在主库生效,一个主库可以配置 1~8 个实时备库。

    2. 主备集群同步机制归档流程如下所示
      在这里插入图片描述
      场景说明(实时主备,A主库,B备库):

      用户登录主库 A 执行:
      CREATE TABLE TX(C1 INT); 
      INSERT INTO TX VALUES(1);
      COMMIT;
      

      (1)DDL和DML提交事务操作使主库产生Redo 信息,Redo 信息会存放在RLOG_PKG(Redo 日志包)中,在此过程中RLOG_PKG存放在内存当中,暂时不会写入联机日志中;
      (2)MAL通讯系统将主库的RLOG_PKG包通过实时归档机制发送到备库B中,备库将最新收到的RLOG_PKG保存在内存中,然后进行校验是否合法,合法后标记为 KEEP_PKG,不会马上启动重演,但会将之前的KEEP_PKG通过APPLY线程队列加入日志重演任务系统,并马上响应主库,不需要等待之前的Redo日志重演结束后再响应主库;

      为了防止备库上重演日志堆积太多、占用大量内存、备库重演无响应导致主库挂住不能提供服务等情况的发生 ,可通过适当调整 BUFFER 、REDOS_PRE_LOAD 、REDOS_BUF_SIZE、REDOS_BUF_NUM、REDOS_MAX_DELAY 这几个参数达到加快备库重演速度、达到设置的堆积上限后延迟响应主机 、 备库自动宕机等目的 。 其中REDOS_BUF_SIZE 和 REDOS_BUF_NUM 同时起作用,只要达到一个条件即延迟响应。
      在这里插入图片描述
      (注意:备库确认收到主库发送的Redo 日志,并不保证备库已经完成重演这些 Redo 日志,因此主备库之间的数据同步存在一定的时间差。)

      备库 KEEP_PKG 日志重演的时机包括:
      1.备库收到新的 RLOG_PKG
      备库收到新的 RLOG_PKG 时,会将当前保存的 KEEP_PKG 日志重演,并将新收到的RLOG_PKG 再次放入
       KEEP_PKG 中。
      2. 收到主库的重演命令
      主库会定时将 FILE_LSN 等信息发送到备库,当主库 FILE_LSN 等于备库 SLSN 时,表明主库已经将
       KEEP_PKG 对应的 Redo 日志写入联机日志文件中,此时备库会启动KEEP_PKG 的日志重演。
      3. 备库切换为新主库
      在监视器执行 SWITCHOVER 或 TAKEOVER 命令,或者确认监视器通知备库自动接管时,备库会在切换为
       PRIMARY 模式之前,启动 KEEP_PKG 的日志重演。
      

      (3)主库收到备库的响应消息,确认备库已经收到 Redo 日志后,主库再将 Redo 日志写入联机日志文件中。

    二、 实时主备集群切换机制

    1. 概念
      达梦数据库主备集群中主库与备库进行切换需要了解以下几点:
      (1)主库
      Primary 模式,提供完整数据库服务的实例,一般来说主库是用来直接支撑应用系统的生产库。

      (2)备库
      Standby 模式,提供只读数据库服务的实例。备库除了用于容灾,还可以提供备份、查询等只读功能,并且备库还支持临时表的 Insert/Delete/Update 操作。
      备库支持临时表修改主要基于两个因素:1.临时表数据的修改不会产生 Redo 日志,主库对临时表的修改无法同步到备库;2.可以提供更大灵活性,适应更多应用场景。
      根据数据同步情况,备库又可以分为可切换备库和不可切换备库。可切换备库是指,主备库之间数据完全同步,主库发生故障、备库切换为主库后,不会造成任何数据丢失的备库。

      (3)守护进程
      守护进程(dmwatcher)是 DM 数据守护系统不可或缺的核心部件,是数据库实例和监视器之间信息流转的桥梁。数据库实例向本地守护进程发送信息,接收本地守护进程的消息和命令,守护进程负责解析、处理、转发命令。守护进程提供了数据库监控、故障检测、故障处理、故障恢复等各种功能。监视器(dmmonitor)接收守护进程的消息,并向守护进程发送命令;数据库实例与监视器之间没有直接的消息交互;守护进程解析并执行监视器发起的各种命令(Switchover/Takeover/Open database 等),并在必要时通知数据库实例执行相应的操作。

      守护进程负责监控数据库运行状态,必要时重启数据库服务。守护进程和实例链路建立成功后,数据库实例定时发送信息到守护进程,发送到守护进程的内容包括:实例进程 ID、实例名、数据库模式、数据库状态、FILE_SEQ、FILE_LSN、CUR_SEQ、CUR_LSN、MAL链路状态、归档状态、公钥、MPP 控制文件等信息。
      守护进程更新本地记录的实例信息后,同时记录该时间戳。当检测到实例进程 ID 已经不存在或者超过一段时间没有收到实例消息(INST_ERROR_TIME),则会认定实例故障。如果配置了自动重启,则会将实例重新拉起。

      守护进程将监控的数据库实例信息和守护进程自身的信息(包括守护类型、守护模式、守护状态、守护日志、监视器执行序列号、执行返回码等)捆绑在一起,定时发送给其他守护进程和所有监视器。

      (4)监视器
      监视器(dmmonitor)用来监控守护系统内守护进程、数据库实例信息,执行用户输入命令、监控实例故障、实现自动切换等。监视器一般配置在数据库实例和守护进程以外的机器上。

    2. DM 数据守护的主要特性包括:
      (1)完整功能的主库
      主库提供完整的数据库服务,与普通单节点数据库相比,主要的功能限制包括:不支持修改表空间文件名、不支持修改 arch_ini 参数。

      (2)活动的备库
      基于独特的字典缓存技术和日志重演技术,备库在 Open 状态下执行数据同步,是真正意义上的热备库;在实现异地容灾的同时,用户可以只读访问备库,执行报表生成、数据备份等功能,减轻主库的系统负载,提高资源利用率。

      (3)多重数据保护
      每个备库都是一个完整的数据库备份,可以同时配置多个备库,为数据安全提供全方位的保护。 高可用性主库出现故障时,可以快速将备库切换为主库,继续提供数据库服务,确保数据库服务不中断。切换过程一般在数秒钟之内完成。

      (4)多种守护模式
      提供自动切换和手动切换两种守护模式,满足用户不同需求。其中,配置自动切换的前提是已经部署确认监视器。在提供第三方机器部署确认监视器情况下,可以配置为故障自动切换模式,主库出现故障时,系统自动将备库切换为主库对外提供数据库服务。

      (5)故障自动重连
      配置、使用连接服务名访问数据库,在发生主备库切换后,接口会自动将连接迁移到新的主库上。

      (6)故障库自动重加入
      主库故障,发生主备库切换。故障主库重启后,可以自动切换为 Standby 模式,作为备库重新加入数据守护系统。

      (7)历史数据自动同步
      故障备库恢复后,可以自动同步历史数据,无需用户干预,并在同步完成以后,自动恢复为可切换备库。

      (8)丰富的守护命令
      监视器dmmonitor提供主备库切换、强制接管等功能,通过简单的命令就可以实现主备库角色互换、故障接管等功能。

    3. 数据库模式
      (1)Normal 模式
      提供正常的数据库服务,操作没有限制。正常生成本地归档,但不发送实时归档(Realtime)、即时归档(Timely)和异步归档(Async)。

      (2)Primary 模式
      提供正常的数据库服务,操作有极少限制。该模式下部分功能受限,包括:不支持修改表空间文件名、不支持修改 arch_ini 参数。正常生成本地归档,支持实时归档(Realtime)、即时归档(Timely)和异步归档(Async)。Primary 模式下,对临时表空间以外的所有的数据库对象的修改操作都强制生成 Redo 日志。

      (3)Standby 模式
      可以执行数据库备份、查询等只读数据库操作。正常生成本地归档,正常发送异步归档Redo 日志;但实时归档(Realtime)、即时归档(Timely)均强制失效。该模式下时间触发器、事件触发器等都失效。

    4. 数据库状态
      (1)Startup 状态
      系统刚启动时设置为 Startup 状态。

      (2)After Redo 状态
      系统启动过程中联机日志重做完成后,回滚活动事务前设置为 After Redo 状态。非Standby 模式的实例在执行 alter database open 操作前,也会将系统设置为 After Redo 状态。

      (3)Open 状态
      数据库处于正常提供服务的状态,但不能进行归档配置等操作。

      (4)Mount 状态
      数据库在 Mount 状态下,不能修改数据,不能访问表、视图等数据库对象,但可以执行修改归档配置、控制文件和修改数据库模式等操作,也可以执行一些不修改数据库内容的操作,比如查询动态视图或者一些只读的系统过程。由于 Mount 状态不生成 PWR 日志,因此数据页可以正常刷盘,也正常推进检查点。系统从 Open 状态切换为 Mount 状态时,会强制回滚所有活动事务,但不会强制清理(Purge)已提交事务,不会强制断开用户连接,也不会强制 Buffer 中的脏页刷盘。

      (5)Suspend 状态
      数据库在 Suspend 状态下,可以访问数据库对象,甚至可以修改数据,但限制 Redo日志刷盘,一旦执行 COMMIT 等触发 Redo 日志刷盘的操作时,当前操作将被挂起。相比 Open 到 Mount 的状态切换,Open 到 Suspend 的状态切换更加简单、高效,不会回滚任何活动事务,在状态切换完成后,所有事务可以继续执行。一般在修改归档状态之前将系统切换为 Suspend 状态,比如备库故障恢复后,在历史
      数据(归档日志)同步完成后,需要重新启用实时归档功能时:
      ①将系统切换为 Suspend 状态,限制 Redo 日志写入联机 Redo 日志文件;
      ②修改归档状态为 Valid;
      ③重新将数据库切换为 Open 状态,恢复 Redo 日志写入功能;
      ④备库与主库重新进入实时同步状态。 另外,实时归档失败时(比如网络故障导致),Primary 实例将试图切换成 Suspend状态,防止后续的日志写入。因为一旦写入,主备切换时有可能备库没有收到最后那次的RLOG_PKG,导致主库上多一段日志,很容易造成主备数据不一致。当实例成功切换为SUSPEND 状态时,可直接退出,强制丢弃多余的日志,避免主备数据不一致。

      (6)Shutdown 状态
      实例正常退出时设置为 Shutdown 状态。
      在这里插入图片描述

    5. 守护状态
      守护进程包括以下一些状态:
      ① Startup 守护进程启动状态,需要根据远程守护进程发送的状态信息,结合本地数据库的初始模式、状态和数据同步情况,确定本地数据库的启动模式和状态后,进入Open 状态。

      ② Open 守护进程正常工作,监控数据库,并定时发送数据库的状态信息,接收其他守护进程发送的信息,接收监视器发送的用户请求。

      ③Shutdown 守护进程停止监控数据库状态,也不提供主备库切换功能。

      ④ Switchover 主备库正常情况下,手动主备切换过程中设置为 Switchover 状态。

      ⑤Failover 远程备库故障后,本地主库执行故障处理时,守护进程设置为Failover 状态。

      ⑥ Recovery 故障恢复同步历史数据过程中设置为 Recovery 状态。

      ⑦ Confirm 通过监视器确认远程主(备)库是否活动的过程中,守护进程设置为Confirm 状态。

      ⑧Takeover 主库确认故障后,备库手工接管或监视器通知自动接管过程中,守护进程设置为 Takeover 状态。

      ⑨Open force 借助监视器命令强制 Open 主库或备库实例时,守护进程设置为Open force 状态。

      ⑩Error 超过一段时间(DW_ERROR_TIME)没有接收到远程守护进程消息,本地守护进程或监视器认定远程守护进程故障,修改远程守护进程为 Error 状态。

      ⑪Login check 监视器执行登录命令时,守护进程所处的状态。

      ⑫Mppctl update 修改主库 MPP 控制文件(dmmpp.ctl)时,守护进程所处的状态,只在 MPP 主备系统出现。

      ⑬Change arch 监视器执行 set arch invalid 命令时守护进程所处的状态。

      ⑭Standby check 主库守护进程监控到备库异常后,切换到此状态下通知主库修改此备库归档无效。

      ⑮Clear send info 清理主库上的归档发送信息时,守护进程所处的状态。

      ⑯Clear rapply stat 清理备库上的重演信息时,守护进程所处的状态。

      ⑰Unify ep 统一 DMDSC 集群各节点实例状态,或者各实例状态已经一致时,守护进程在 Startup 或 Open 状态下通知实例执行相关操作,都进入 Unify_ep 状态执行。

      ⑱Css process 监视器发起的对 DMDSC 集群的部分命令,比如启动、关闭、强杀 DMDSC 库,或者打开、关闭节点实例的自动拉起功能等命令,需要借助 dmcss 执行时,守护进程会切换到此状态下。
      守护进程所有状态变换和它监控的数据库的状态变换都会生成相应的 LOG 信息,写入到…/log 目录中以’dm_dmwatcher_实例名_当前年月.log’方式命名的日志文件中。用户可以通过查看日志文件,分析数据库和守护进程的运行状态、监控故障处理过程。
      守护进程的状态转换如下图所示:
      在这里插入图片描述

      另外,当远程守护故障,任何状态都可转到 Error 状态。

    6. 实时主备系统主要功能
      (1)实时数据同步
      主备库通过实时归档完成数据同步,实时归档要求主库将 RLOG_PKG 发送到备库后,再将RLOG_PKG 写入本地联机 Redo 日志文件。但要注意的是,备库确认收到主库发送的Redo 日志,并不保证备库已经完成重演这些 Redo 日志,因此主备库之间的数据同步存在一定的时间差。

      (2)主备库切换,主备库正常运行过程中,可以通过监视器的 Switchover 命令,一键完成主备库角色
      转换。主备库切换功能可以确保在软、硬件升级,或系统维护时,提供不间断的数据库服务。

      (3)自动故障处理
      备库故障,不影响主库正常提供数据库服务,守护进程自动通知主库修改实时归档为Invalid 状态,将实时备库失效。

      (4)自动数据同步
      备库故障恢复后,守护进程自动通知主库发送归档 Redo 日志,重新进行主备库数据同步。并在历史数据同步后,修改主库的实时归档状态为 Valid,恢复实时备库功能。备库接管后,原主库故障恢复,守护进程自动修改原主库的模式为 Standby,并重新作为备库加入主备系统。

      (5)备库接管
      主库发生故障后,可以通过监视器的 Takeover 命令,将备库切换为主库,继续对外提供服务。如果配置为自动切换模式,确认监视器可以自动检测主库故障,并通知备库接管,这个过程不需要人工干预。

      (6)备库强制接管
      如果执行 Takeover 命令不成功,但主库可能由于硬件损坏等原因无法马上恢复,为了及时恢复数据库服务,DM 提供了 Takeover Force 命令,强制将备库切换为主库。但需要由用户确认主库故障前,主库与接管备库的数据是一致的(主库到备库的归档是 Valid状态),避免引发守护进程组分裂。

      注意:执行Takeover Force有可能引发组分裂,而Takeover命令在确保不会产生组分裂情况下才允许执行。
      
    7. 集群故障处理
      (1)备库故障处理
      故障自动切换模式下,备库故障后,如果主备库之间的归档状态仍然有效,主库的守护进程会先切换为 Confirm 状态,等待确认监视器的确认消息,如果确认为符合故障处理条件,主库守护进程再切换至 Failover 状态,将故障备库的归档失效。

      故障手动切换模式下,备库故障后,如果主备库之间的归档状态仍然有效,会直接切换到 Failover 状态,并将故障备库的归档失效,不需要备库故障确认。备库故障后,备库的守护进程如果还处于活动状态且监控功能没有被关闭,则会切换到Startup 状态下。

      备库故障重启后,如果存在活动主库,主库守护进程根据备库实例的模式、状态、备库守护进程状态、守护进程控制文件状态、备库已经同步到的 Open 记录以及备库的恢复间隔等信息判断是否可以进行故障恢复,在满足故障恢复条件的情况下,主库守护进程启动Recovery 流程,重新恢复主备库到一致状态。如果一直没有观察到主库守护进程发起 Recovery 流程,可以借助监视器的 check recover 命令查找备库不满足条件的原因,并做对应的处理。

      (2)备库异常处理
      备库异常,指备库的数据库实例正常,但响应速度出现异常,这里的响应速度可能受主备库之间的网络影响,比如网络不稳定、网速大幅下降,也可能受备库自身的软硬件影响,比如操作系统原因或磁盘读写速度异常降低等异常情况导致响应主库的速度变慢,这种情况下会极大拖慢主库性能,影响主库正常处理对外的业务请求。

      守护进程提供 RLOG_SEND_THRESHOLD 参数用于监控主备之间的日志发送速度,此参数应配置为大于 0 的值,否则守护进程不会打开监控功能。主库守护进程在 Open 状态下对日志发送速度进行检测,一旦检测到异常,主库守护进程会切换到 Standby check 状态,并通知主库将异常备库的归档失效,暂停到此备库的数据同步,避免拖慢主库性能。

      完整的备库异常处理流程如下(Standby check 状态处理):
      ① 收集所有的异常备库。
      ②将主库守护进程上记录的这些异常备库的最近一次恢复时间修改为当前时间。恢复间隔仍然为 dmwatcher.ini 中配置的 INST_RECOVER_TIME 值。这一步骤的目的是为了防止修改备库归档为 Invalid 无效状态后,主库立马启动 recovery,但是还未取到备库最新的 LSN 信息,导致 recovery 无法正确执行的情况发生。
      ③通知主库修改这些异常备库的归档为 Invalid 无效状态。
      ④守护进程切回 Open 状态。

      (3)主库故障处理
      故障自动切换模式下,主库故障后,确认监视器会捕获到故障信息,自动选出可接管的备库,并通知备库进行接管。备库接管由确认监视器自动触发,无需用户干预。

      故障手动切换模式下,主库故障后,需要人工干预,通过监视器执行接管命令,将可接管备库切换为主库。

      故障自动切换模式下,可以实时处理故障,但对网络稳定性要求更高,需要确保主备库之间,主备库与守护进程、确认监视器之间的网络稳定可靠,否则可能会误判主库故障,备库自动接管后,出现多个 Open 状态的主库,引发脑裂。故障手动切换模式下,备库不会自动接管,出现节点故障或者网络故障时,由用户根据各种故障情况,进行人工干预。

      主库故障重启后,守护进程根据本地和远程库的 Open 记录、LSN 信息以及模式和状态信息来判定重启后的恢复策略,可能继续作为主库加入守护系统,也可能修改为 Standby模式,以备库身份重新加入守护系统,如果出现分裂,则需要用户干预。

      (4)故障恢复处理
      故障恢复状态(Recovery)由守护进程自行判断是否切换,和监视器无关。如果符合以下条件,主库的守护进程可自动进入 Recovery 状态,进行数据恢复:
      ①本地主库 [Primary,Open],守护进程 Open 状态;
      ②远程备库[Standby,Open],归档状态 Invalid,守护进程 Open 状态;
      ③远程备库[Standby,Open]的ASEQ/ALSN和SSEQ/SLSN相等,没有待重做日志;
      ④根据 Open 记录等信息判断备库可加入;
      ⑥远程备库[Standby,Open]达到了设置的启动恢复的时间间隔。
      对于前 4 点,只是概括说明,详细的条件比较多,这里不再逐一列出,如果某个备库一直没有被恢复,可以借助监视器的 check recover 命令来查找备库无法进行恢复的原因。
      对于第 5 点,可通过配置主库守护进程 dmwatcher.ini 的 INST_RECOVER_TIME来控制,取值(3s~ 86400 s),该值对所有备库有效,可通过监视器的 show arch send info 命令查看当前设置的到指定备库的恢复时间间隔。也可以使用监视器的 set recover time 命令来动态设置指定备库的恢复间隔,该命令只会修改命令中指定的备库的恢复间隔,并且只保存在主库的守护进程内存中,不会写入到 dmwatcher.ini 文件。

      在主备库运行正常,不需要执行备库故障恢复的情况下,主库守护进程内存中对备库的恢复间隔值和 dmwatcher.ini 中配置的 INST_RECOVER_TIME 值是一致的,在某些场景下会被设置为不同的值,下面分别进行说明:
      ①主库守护进程主动设置恢复间隔为 3s
      在以下场景中,主库的守护进程会重置内存中的 INST_RECOVER_TIME 为 3s,对满足前述前 4 个条件的备库在 3s 后会立即启动恢复流程:

      1 数据守护系统启动完成之后;
      2 守护系统运行过程中,主库手动重启或者守护进程自动启动 Open 之后;
      3 监视器执行Switchover 主备切换/Takeover 备库接管/强制 Open 主库的操作之后。

      ②使用监视器命令动态设置恢复间隔
      监视器提供有以下命令可动态修改 INST_RECOVER_TIME 值:

      1 set database [group_name.]db_name recover time time_value
      动态修改指定备库实例的恢复间隔 ,只修改对应主库守护进程内存中的INST_RECOVER_TIME 值。
      2 set group [group_name] recover time time_value
      动态修改指定组或所有组中所有备库的恢复间隔,只修改对应主库守护进程内存中的INST_RECOVER_TIME 值。
      3 set group [group_name] para_name para_value
      动态修改指定组或所有组中所有守护进程的配置参数值,para_name 允许指定为 INST_RECOVER_TIME , 同时修改dmwatcher.ini 文件和主库内存中的INST_RECOVER_TIME 值。

      以上 3 个命令都可以用来修改 INST_RECOVER_TIME 值,修改完成后,一旦主库对指定备库执行过恢复操作,不管恢复执行成功或失败,通过监视器动态修改的内存值都不再有效,主库守护进程在恢复完成后,会根据恢复结果重置内存中的恢复间隔值(对dmwatcher.ini 中的值没有影响)。

      ③主库守护进程根据恢复结果设置恢复间隔
      如果备库恢复成功,会重置此备库的恢复间隔为主库 dmwatcher.ini 中配置的值。如果备库恢复失败,会根据失败 code 区分设置为不同的值,比如 1800s,一般是在主备库日志校验不连续的情况下设置,其他还可能设置为 3s、30s、300s 或者dmwatcher.ini 中设置的值,这里不再详细说明,具体可通过服务器和守护进程的 log日志查看详细的设置信息,也可以通过监视器的 show arch send info 命令查看相关
      code 信息。
      完整的故障恢复流程如下:

      1 通知备库丢弃 KEEP_PKG;
      2 通知主库发送归档日志,同步历史数据;
      3 通知主库切换为 Suspend 状态;
      4 再次通知主库发送归档日志;
      5 通知主库设置备库归档为 Valid 状态;
      6 通知主库切换为 Open 状态。

      整个恢复过程中最耗时的是发送归档日志,当存在多个备库需要恢复时,为了提高恢复的效率,采用多备库并行发送归档的方式进行。守护进程每次搜集一个可恢复备库到恢复列表,按照上述故障恢复流程执行单个步骤,在等待发送归档日志的过程中,继续检测是否有备库可以恢复,如果有则加入恢复列表,也对其开始进行恢复流程处理;如果没有则检查恢复列表中是否有归档日志发送完成的备库,有则对其进行后续步骤处理,直至归档变成有效状态后从恢复列表中删除。对于恢复过程中出错的备库,也从恢复列表中删除。当恢复列表为空时,恢复流程执行结束,守护进程恢复为 OPEN 状态。
      恢复过程中,守护进程会继续检测是否有恢复列表之外的备库需要恢复,如果有则可以动态加入恢复列表,实现动态并行恢复。

      注意:以下情况会导致 Recovery 过程中断: ①Recovery 过程中收到监视器的命令。 ②存在多个备库时,Recovery
      过程中发现其他正常备库故障,且符合failover 条件,则守护进程主动中断 Recovery,先做 failover 处理。
      ③存在多个备库时,Recovery 过程中发现到其他正常备库归档发送异常,则守护进程主动中断 Recovery,先做异常处理。
      ④Recovery 过程中,当前正在被恢复的备库出现异常。 ⑤正在执行 Recovery 的主库或备库是 DMDSC
      集群,Recovery 过程中 DMDSC 集群启动故障处理或者故障重加入,也会中断当前的 Recovery动作。

      在守护进程打开备库异常监控的情况下,对于异常备库的恢复处理需要注意下面两点:

      ①如果主备库的 LSN 已经相等,但是根据统计出来的时间信息判断主库的归档发送时间或备库的日志重演时间仍然大于设置的阈值,则不会再进入Recovery状态,直到主库上有新的日志产生需要同步到备库,可以对统计的历史时间信息进行更新的情况下才会再进入 Recovery 状态尝试恢复。
      ②在进入 Recovery 状态后,通知主库 Suspend之前(主备库数据已经同步一致),会对主库的归档发送时间和备库的日志重演时间进行检查,在两者都小于或等于设置的阈值的情况下,才允许继续执行Suspend,并恢复备库归档为有效状态,否则不允许再往下执行,本次 Recovery 执行失败。

    8. 集群数据守护场景
      (1)正常运行状态
      守护系统正常运行时,同一个守护进程组中,只有一个主库,其他的都是备库。主库处于 Open 状态,主库守护进程也处于 Open 状态,本地没有守护进程控制文件,其内存值是 Valid 有效状态。
      所有备库也处于 Open 状态,所有备库守护进程处于 Open 状态,本地没有守护进程控制文件,其内存值是 Valid 有效状态。
      主库到所有备库的归档也都处于 Valid 有效状态。

      (2)数据守护的启动
      Normal 模式的库默认以 Open 状态启动,也可以通过增加启动参数 Mount 将数据库启动到 Mount 状态。而 Primary/Standby 模式的库启动后,自动进入 Mount 状态,因此,数据守护系统启动时,所有数据库实例处于 Mount 状态。所有守护进程处于 Startup状态。如果实例还未启动到 Mount 状态(比如还处于 After redo 状态),守护进程不会通知实例 Open。
      Local 守护类型的守护进程,直接 Open 数据库实例,并修改守护进程状态为 Open。
      Global 守护类型的守护进程,需要相互协调信息,自动将数据库实例切换到 Open 状态,并将守护进程状态也切换为 Open 状态。
      Global 守护类型的守护进程通知本地库 Open 的总体原则:
      ①对于备库,如果可加入远程任意一个库,则允许将其 Open;
      ②对于主库,如果远程所有库都可加入自己,则允许将其 Open。
      还有一些细节条件这里不再具体列出,如果通过监视器没有观察到主库或备库 Open,可以借助监视器的 Check Open 命令查找原因,根据命令返回的原因考虑是否进行人工干预,比如需要通过监视器命令强制 Open 主库或备库。

      注意:
      手动方式启动数据守护系统时,对于守护进程,数据库实例和监视器的启动顺序没有严格要求,也可以通过监视器命令启动守护系统(前提是所有守护进程已经启动)。
      启动流程中,守护进程在通知主库 Open 之前,会先收集出和主库数据一致的备库(备库的 ALSN 信息和主库的 FLSN 信息相等),守护进程会将这些备库的归档设置为 Valid 有效状态,其他数据不一致的备库则设置为Invalid 无效状态。Primary 模式数据库实例切换为 Open 状态时,需要回滚活动事务、Purge 已提交事务,并重构回滚段,会引发数据变化、LSN增长。对归档无效的备库,在数据守护启动完成后,主备库数据肯定是处于不一致状态。
      主库守护进程 Open 主库后,会修改 INST_RECOVER_TIME 内存值为 3 秒(默认 60 秒),确保归档状态无效的备库 Open 后,尽快启动故障恢复流程,同步主库数据完成后,重新将归档设置为 Valid 状态。
      如果在故障恢复流程完成之前,主库故障,并且不存在归档状态有效的备库,则无法执行备库接管;备库强制接管会引发守护进程组分裂。
      读写分离集群,在 Timely 或 Realtime 归档变为 Valid 之前,不会在备库上创建数据库连接,只读操作也无法分流到对应的备库。

      (3)强制 Open 数据库
      正常情况下,守护进程 dmwatcher 可以自动 Open 数据库实例,但某些情况下(比如备库硬件故障无法启动),数据守护系统不满足 6.2 介绍的启动条件,我们可以通过监视器执行 Open database 命令强制 Open 数据库实例。主备库都可以强制 Open,其执行流程如下:

      1 假设需要强制 Open 数据库 A,只需要启动一个监视器,登录后输入 Open database A 即可完成强制启动。 如果数据库 A 是 Standby 模式,强制 Open 的执行流程如下:
      ①通知 A 的守护进程切换为 Open Force 状态
      ②通知 A 执行 Open 操作
      ③通知守护进程切换 Open 状态

      2 如果数据库 A 是 Primary 模式,强制 Open 的执行流程如下:
      ①通知 A 的守护进程切换为 Open Force 状态
      ②修改 A 到所有归档目标的实时归档/即时归档状态为无效
      ③通知 A 执行 Open 操作
      ④通知守护进程切换 Open 状态

      3 Primary 模式数据库实例切换为 Open 状态时,需要回滚活动事务、Purge 已提交事 务,并重构回滚段,会引发数据变化、LSN 增长。因此,这个操作可能会引发守护进程组分 裂,比如下面的场景:
      ①主库 A 故障
      ②备库 B 接管,成为主库
      ③B 故障
      ④A 重启,并强制 Open
      ⑤A 和 B 数据不一致,并且无法恢复到一致状态。此时,B 重启,就会产生守护进程 组分裂。

      注意:
      强制 Open 主库前,会设置主库到所有归档目标的实时归档/即时归档为 Invalid 状态。
      强制 Open 主库命令,会修改主库守护进程 INST_RECOVER_TIME 内存值为3 秒(默认 60 秒),确保
      主库 Open 后,尽快启动故障恢复流程,同步主库数据完成后,重新将归档设置为 Valid 状态。
      如果在故障恢复流程完成之前,主库故障,将无法执行备库接管;备库强制接管会引发守护进程组分裂。
      

      (4)关闭数据守护系统
      关闭守护系统时,必须按照一定的顺序来关闭守护进程和数据库实例。特别是自动切换模式,如果退出守护进程或主备库的顺序不正确,可能会引起主备切换,甚至造成守护进程组分裂。通过监视器执行 Stop Group 命令关闭数据守护系统,是最简单、安全的方式。命令执行成功后,数据库实例正常关闭。但守护进程并没有真正退出,而是将状态切换为Shutdown 状态。
      Stop Group 命令内部流程如下:

      ①通知守护进程切换为 Shutdown 状态
      ②通知主库退出
      ③通知其他备库退出

      如果使用手动方式关闭数据守护系统,请严格按照以下顺序执行:

      ①如果启动了确认监视器,先关闭确认监视器(防止自动接管)
      ②关闭备库守护进程(防止重启实例)
      ③关闭主库守护进程(防止重启实例)
      ④Shutdown 主库
      ⑤Shutdown 备库

      如果是只关闭主库,并且不想引发备库自动接管,有以下两种方法:

      方法一:
      1 通过 Detach database 命令将所有备库分离
      2 通过 Stop database 命令退出主库
      方法二:严格按照以下顺序执行:
      1 通过 Stop dmwatcher 命令关闭所有守护进程监控
      2 手动正常退出主库

      如果是只关闭备库,并且不想引发主库发送日志失败进入 Suspend 状态,请严格按照
      以下顺序执行:

      1 通过 Detach database 命令将备库分离出数据守护系统
      2 正常退出备库(手动退出或者通过 Stop database命令退出)

      (5)主备库切换
      主库维护,滚动升级等场景,可以执行 Switchover 命令,实现主备库切换。如果存在多个备库,需要先执行 Choose Switchover 命令,选出守护进程组中可以切换的备库。
      Choose Switchover 命令选择可切换备库的条件如下:

      1 主库守护进程是 Open 状态
      2 备库守护进程是 Open 状态
      3 主、备库的 OPEN 记录项内容相同,并且守护进程控制文件是 Valid 有效状态(内存值)
      4 主库正常运行
      5 备库正常运行
      6 主库处于 Open 状态
      7 备库处于 Open 状态
      8 主库到备库的归档是 Valid 状态
      

      假定选出的可切换备库是 B,Switchover 切换流程如下:

      1 通知主备库守护进程,切换为 Switchover 状态
      2 通知主库(A) Mount
      3 实时或 MPP 主备环境下,通知备库(B) APPLY KEEP_RLOG_PKG
      4 通知备库(B) Mount
      5 通知(A) 切换为 Standby 模式
      6 MPP 主备环境下,通知(A)修改 MPP_INI 内存值为 0
      7 通知(B) 切换为 Primary 模式
      8 通知(B) 修改所有归档目标的归档状态为无效
      9 MPP 主备需要通知各组活动主库更新 dmmpp.ctl 文件,参考后文说明
      10 通知新的备库(A) Open
      11 通知新的主库(B) Open
      12 通知主备库守护进程切换为 Open 状态
      13 清理所有守护进程上记录的监视器命令执行信息
      

      注意: 主备库切换在实现逻辑上等同于主备库正常状态 下用户主动发起的Takeover 操作。Swithover完成后,主备库之间数据是不完全同步的,要由新主库 B 的守护进程通过 Recovery 流程,重新同步数据到新备库 A。Switchover 命令会修改切换后主库守护进程 INST_RECOVER_TIME 内存值为 3 秒(默认 60 秒),确保尽快启动故障恢复流程,同步主库数据完成后,重新将归档设置为 Valid 状态。
      在故障恢复流程完成之前,再次执行Switchover 命令会报错,如果主库故障,备库接管将会报错;备库强制接管会引发守护进程组分裂。

      (6)主库故障、备库接管
      当出现硬件故障(掉电、存储损坏等)原因导致主库无法启动,或者是主库内部网卡故障导致主库短期不能恢复正常的情况下,可使用备库接管功能,将备库切换为主库继续对外服务。
      故障自动切换模式下,确认监视器会自动选择符合条件的备库进行接管。
      故障手动切换模式下,可以先在监视器上执行 Choose Takeover 命令,选出守护进程组中可以接管的备库。
      为了避免备库接管后,造成守护进程组分裂,执行 Takeover 必须满足下列条件:

      1 主库是 Primary 模式、Open 状态时,发生故障
      2 主库守护进程故障,故障前是 Startup/Open/Recovery 状态;或者主库守护
      进程正常
      3 主库故障前到接管备库的归档状态为 Valid
      4 接管备库是 Standby 模式、Open 状态
      5 接管备库的守护进程控制文件状态为 Valid(内存值)
      6 故障主库和接管备库的 Open 记录项内容相同
      

      假设主库 A 故障时,在故障自动切换模式下确认监视器自动选出待接管备库 B 并通知备库 B 自动接管,或者在故障手动切换模式下,通过监视器上的 Choose Takeover 命令,选出待接管备库 B,在监视器上输入 Takeover 命令通知备库 B 执行接管,这两种方式的接管执行流程是一样的。
      以备库 B 为例,接管的执行流程包括:

      1 监视器通知守护进程(B)切换为 Takeover 状态
      2 实时主备或 MPP 主备环境下,通知备库(B) APPLY KEEP_PKG
      3 通知备库(B) Mount
      4 通知(B) 切换为 Primary 模式
      5 通知(B) 修改到所有归档目标的归档状态为 Invalid
      6 MPP 主备需要通知活动主库更新 dmmpp.ctl 文件(步骤参考 6.5 主备库切换)
      7 通知新的主库(B) Open
      8 通知守护进程(B)切换为 Open 状态
      

      (7)备库强制接管
      有些情况下,备库接管会失败,但主库不能启动或者及时恢复对外服务的情况下,可以使用 Takeover Force 命令,进行备库强制接管。强制接管具有一定的风险,可能导致备库和故障主库数据不一致,而造成部分数据的丢失,出现数据库分裂的情况,所以应该慎重使用。
      例如主库和守护进程故障时,监视器未启动,用户启动监视器后,由于监视器并未收到故障主库任何信息,因此不满足 Takeover 条件,执行 Takeover 会报错。如果用户可确认主库故障时主备数据是一致的(如故障时主库未执行操作,主备库归档有效的,并且两者的 LSN 一致)、或者丢失小部分数据的影响可忽略、或者丢失小部分数据的影响小于主库持续宕机造成的影响,则可以考虑执行 takeover force 强制接管。
      强制接管,先通过 Choose Takeover Force 选出符合强制接管条件的备库,再执行 Takeover Force 命令。
      备库强制接管时,如果接管备库是处于 Mount 状态/Standby模式的库,则会自动 Open 备库,其他执行流程与备库接管一致。强制接管的条件包括:

      1 不存在活动主库
      2 备库守护进程处于 Open 或 Startup 状态
      3 备库实例运行正常
      4 备库是 Standby 模式
      5 备库处于 Open 或 Mount 状态
      6 备库的 KLSN 必须是所有备库中最大的
      7 备库守护进程控制文件必须有效
      

      (8)主库故障重启(备库接管前重启)
      主库故障后立即重启,此时主库的守护进程变成 Startup 状态,重新进入守护进程的启动流程,将数据一致的备库归档设置为有效状态,其余备库归档设置成无效状态,并重新Open 主库。Open 成功后继续作为主库,当检测到归档状态无效的备库正常时会启动Recovery 处理流程,重新同步主备库数据。

      (9)备库故障处理
      备库产生故障(硬件故障或者内部网卡故障)时,主库的处理流程对手动切换、自动切换模式处理上有些差异。
      ①手动切换模式
      对于手动切换模式,检测到备库故障,满足 Failover 条件时,主库的守护进程立即切换到 Failover 状态,执行对应的故障处理,如果不满足切换 Failover 条件,则保持当前状态不变。
      手动切换模式下,主库守护进程切换 Failover 条件:

      1 备库实例故障,或者主备库之间出现网络故障,或者备库重演时校验 LSN 不匹配,这三种场景下引发主库
      同步日志到备库失败挂起,主库实例处于 Suspend 状态
      2 主库到此备库的归档状态是 Valid(读写分离集群没有此限制)
      3 主库的守护进程处于 Startup、Open 或 Recovery 状态
      4 当前没有监视器命令正在执行
      

      ②自动切换模式
      对于自动切换模式,主库的守护进程会自动判断切换到 Failover 状态或者 Confirm确认状态,如果两种状态切换条件都不满足,则保持当前状态不变。
      自动切换模式下,主库守护进程不进入 Confirm 确认状态,直接切换到 Failover 条件:

      1 前四项条件,和上面列出的手动切换条件相同
      2 备库实例故障,备库守护进程正常
      

      如果只满足条件 1,不满足条件 2,则主库守护进程会先进入 Confirm 确认状态,等待确认监视器的确认消息。主库的守护进程进入 Confirm 确认状态后,会有下面几种不同的处理:
      1 主库和确认监视器之间网络连接正常
      主库的守护进程收到了确认监视器返回的确认消息,如果确认监视器认定可以执行 Failover,则主库的守护进程会切换为 Failover 状态并执行对应的处理;如果确认监视器认定不满足执行 Failover 条件,则主库的守护进程会一直保持在 Confirm 状态。确认监视器认定主库可以执行 Failover 条件:

      1)主库守护进程处于 Confirm 状态
      2)主库实例正常,处于 Suspend 状态
      3)主库没有被接管,不存在其他主库
      4)没有 takeover/switchover 命令在执行
      5)当前所有归档有效的备库均可以加入主库
      

      2 主库和确认监视器之间网络连接异常,或者没有启动确认监视器。满足下面条件后
      主库允许切换至 Failover 状态执行故障处理:

      1)主库实例正常,处于 Suspend 状态
      2)备库守护进程正常
      3)主库没有被接管,不存在其他主库
      4)没有 takeover/switchover 命令正在执行
      5)备库故障前可以加入主库
      

      3 主库和确认监视器网络恢复正常后,主库已经被接管。老主库的守护进程切换为
      Startup 状态,重新判断是否可加入新主库。
      主库守护进程进入 Failover 状态后的执行流程(自动或手动切换模式下执行流程相
      同):

      1)对实时主备或 MPP 主备,通知主库修改发送归档失败的备库归档状态无效
      2)通知主库重新 Open。
      3)将主库的守护进程切换为 Open 状态
      

      ⑩确认监视器未启动
      故障自动切换模式下,确认监视器必须一直处于启动状态,并且要确保确认监视器的配置正确(否则无法和守护进程通信,相当于确认监视器没有启动)。若确认监视器未启动或者配置错误的,在主库或备库发生故障时,无法通过确认监视器执行正常的故障处理。确认监视器的具体作用请参考状态确认和自动接管小节。
      在没有确认监视器或确认监视器配置错误的情况下:

      1 如果主库故障,则备库无法自动接管为新主库。
      2 如果备库实例和备库的守护进程都出现故障,或者主备库之间出现网络故障,则主库的守护进程无法通过确认监视器来确认备库状态,主库守护进程会处于Confirm 确认状态,实例处于 Suspend 挂起状态。

      对于第 2 种情况,当备库实例和备库守护进程重新恢复正常,或者主备库之间的网络恢复正常后,即使没有确认监视器,主库的守护进程也会切换至 Failover 状态,将主库重新 Open,后续进行正常的备库恢复处理,而不会一直处于 Confirm 确认状态。
      可以通过监视器的 show monitor 命令查看连接到指定守护进程的所有监视器信息,以此可以检查守护系统中是否启动有确认监视器以及确认监视器和守护进程的通信是否正常,也可以尝试再启动一个新的确认监视器,如果守护系统中已经启动有确认监视器,则不允许再启动第二个。

      到此文章结束,请耐心阅读~
      
      更多达梦技术资讯,请访问达梦技术社区:
      达梦数据库 - 新一代大型通用关系型数据库 | 达梦云适配中心
      https://eco.dameng.com/
      
    展开全文
  • 最佳 React UI 组件,前端开发必备!

    千次阅读 2022-02-23 00:54:48
    上次推荐了12个 Vue UI组件,今天来推荐几个 GitHub 上流行的 React UI !1. Ant DesignGitHub 上超过 269 k 个项目使用了 Ant Des...
  • 面向多学科复杂产品虚拟...系统有案例及案例自组织模块,可适应多学科用户自建本学科适用案例及推理系统的需要.为满足复杂产品虚拟样机动态适应性技术进展的需要,提出该工具系统未来的改进方向,使系统具有自
  • 达梦主守护集群原理详解

    千次阅读 2022-04-26 09:36:28
    达梦主守护集群原理详解
  • 鲲鹏 BCManager 存储灾系统详解

    千次阅读 2021-10-24 14:01:24
    鲲鹏 BCManager 存储灾系统详解
  • 本文主要介绍使用ovirt必知的相关概念:Hypervisor、KVM、QEMU、libvirt、gluster、patternfly、ansible、VDSM、远程桌面协议、磁盘类型、存储结构、Cockpit、FQDN等等
  • python标准和第三方的区别

    千次阅读 2020-11-30 05:26:54
    1、python的标准是随着pyhon安装的时候默认自带的。2、python的第三方,需要下载后安装到python的安装目录下,不同的第三方安装及使用方法不同。3、它们调用方式是一样的,都需要用import语句调用。简单的说...
  • 什么逻辑、物理? 逻辑/逻辑文件:给用户看的(即Database和Table就是我们常说的逻辑的范畴) 物理/物理文件:存储在计算机中的(即机器和Port就是我们常说的物理的范畴。) 一个服务器有多个实例(port...
  • ORACLE DG概念及切换.pdf

    2021-09-13 16:03:03
    ORACLE DG概念及切换
  • 软件测试面试前必备题库(必备理论基础复习)

    万次阅读 多人点赞 2018-04-17 23:07:54
    ####软件测试的规范:这个概念很抽象,需要根据公司具体情况而定。 如果公司的时间和人力成本都比较充足的,那个测试规范就可以定义的比较高要求,测试文档的编写、测试用例的数量、测试数据的高效、手动和自动化...
  • python之sympy--数学符号计算与绘图必备

    万次阅读 多人点赞 2020-12-12 18:47:32
    #最后只有到需要的时候,再将符号表达式转为数值即可 二、代数表达式相关运算 2.1 代数表达式 2.1.1 一元表达式 #代数表达式只由一个符号或者该符号经过有限次初等运算组成,在复习初中数学知识,主要明晰相关概念 ...
  • MySQL实战45讲学习笔记----主切换

    千次阅读 2020-02-05 09:44:19
    正常情况下,只要主库执行更新生成的所有binlog,都可以传到备库并被正确地执行,备库就能达到跟主库一致的状态,这就是最终一致性。但是,MySQL要提供高可用能力,只有最终一致性是不够的。主要介绍主备延迟的原因...
  • 罗剑锋著,清华大学出版社,全书内容丰富、结构合理、概念清晰、讲解细致,是广大C++程序员和爱好者的必备之书。
  • 数据库主从和主部署介绍

    千次阅读 2021-01-20 21:51:49
    在系统架构中,数据库层主要由如下几种模式,分别是单点模式、主模式、主从模式。 单点模式 单点模式是最简单的模式,只有一台数据库服务器,部署最简单。但是存在单点风险,一旦这台服务器挂掉,整个系统也就...
  • 国内可外用免费语料下载资源汇总   (一) 国家语委1.国家语委现代汉语语料http://www.cncorpus.org/现代汉语通用平衡语料现在重新开放网络查询了。重开后的在线检索速度更快,功能更强,同时提供检索结果下载...
  • 1、python的标准是随着pyhon安装的时候默认自带的。2、python的第三方,需要下载后安装到python的安装目录下,不同的第三方安装及使用方法不同。3、它们调用方式是一样的,都需要用import语句调用。简单的说...
  • 基于2014年11月发布的Boost 1.57版,介绍了其中的所有129个。  国人原创精品  C++开发的好帮手  C++专家的优秀学习教材 ... 内容丰富、组织得当、概念清晰、讲解细致,是广大C++程序员和爱好者的必备好书。
  • 名称 简介 Chardet字符编码探测器,可以自动检测文本、网页、xml的编码。 colorama主要用来给文本添加各种颜色,并且非常简单易用。 Prettytable主要用于在终端或浏览器端构建格式化的输出。 difflib,[Python...
  • 26、总线架构 27、一致性维度 28、一致性事实 29、Kimball架构和Inmon架构的区别 30、概念模型、逻辑模型、物理模型 31、你认为数据仓库最重要的是什么 32、大宽表的优点与缺点 33、指标体系如何构建 1、什么是数据...
  • 最近天天熬夜,头发都掉完了,就为了把Python所有的完全整理一遍,希望对大家有所帮助! 一、数据处理 Chardet # 字符编码探测器,可以自动检测文本、网页、xml的编码; colorama # 主要用来给文本添加各种颜色...
  • sku与spu 概念

    千次阅读 多人点赞 2021-12-05 20:09:15
    SPU:标准化产品单元 ...SKU=stock keeping unit(库存量单位) ,SKU即库存进出计量的单位(买家购买、商家进货、供应商货、工厂生产都是依据SKU进行的)。 SKU是物理上不可分割的最小存货单元。也就是说一款商品,.
  • 必备 | AI & DS七大 Python

    千次阅读 2019-01-23 13:55:44
    本文作者Favio Vázquez从2018年开始发布《数据...一年结束,作者列出了2018年的7大最好的Python,这些确实地改进了研究人员的工作方式。 7. AdaNet ———快速灵活的AutoML框架 https://gith...
  • MySQL高可用和灾调研

    千次阅读 2022-05-04 14:14:51
    1.高可用和灾方案概览 高可用方案的评价以组件能正常对外提供服务为主,而灾方案的评价以数据稳定同步和恢复时间尽量短为主,其他的还要求方案实现起来较简单,后期运维服务压力较小等。 当下业界比较流行的 ...
  • 此时,再考虑数据库可用性,将扩展后的 4 个主库进行主操作,针对每个主库都建立对应的从,前者负责写操作,后者负责读操作。下次如果需要扩容也可以按照类似的操作进行。 从两个集群扩展成四个集群 双写...
  • Python各类常用整理

    千次阅读 多人点赞 2020-07-12 12:09:36
    一、20个必不可少的Python也是基本的第三方 Requests.Kenneth Reitz写的最富盛名的http。每个Python程序员都应该有它。 Scrapy.如果你从事爬虫相关的工作,那么这个也是必不可少的。用过它之后你就不会再...
  • 《操作系统》_考研复试_概念

    千次阅读 多人点赞 2020-04-25 17:55:12
    前言: 本文作为本人的考研复试收尾笔记,先梳理全面精炼的基本知识,文末会附加我自己整理加搜集的重点面试概念题,大家可以用来自测,看是否真正掌握,如果对大家有帮助,希望大家点赞哦~(^▽ ^)

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 71,997
精华内容 28,798
关键字:

备库的概念