如何对数据库进行管理

数据库管理其实不难，前提是有一个公司的标准管理规范。对数据库的 *** 作有可遵循的流程。

首先是数据库的规范。数据库命名，字符集，必须都要严格统一。命名一定要有规范，包含层次，业务系统等，望文生义。

其次表名要规范，事实表，维度表要分清，按业务类型分好表。表的字段命名要规范尽量不要用拼音，过长的单词可以用缩写。相同的含义的字段在不同表中命名要保持一致，字段类型要统一，长度统一，字段有注释说明，并且每建一个表都要做好数据字典归档，所有的表都能找到字段的含义。

存储过程，触发器也一样，命名要能够区分是什么业务系统的什么类型的功能。

数据库用户管理采取最小权限管理。所有当前权限之外的 *** 作必须申请权限才能放开。所有对现有表做修改 *** 作应该提交申请，做好改动表设计对数据上下游影响的评估。

数据的治理，可以对表做好数据分层，数据经过etl的流转最终统一存储到数据集市，数据仓库中。应用层再从中取数。

好的数据库系统一定是可用的，安全的。需要设计好容灾处理，定期检查备份，做好数据库高可用。设置安全级别更高的数据库访问方式，启用SSL等

一，HDFS的基本特征与构架

1基本特征

（1）大规模数据分布存储能力：以分布式存储能力和良好的可扩展性。（基于大量分布节点上的本地文件系统，构建一个逻辑上具有巨大容量的分布式文件系统，并且整个文件系统的容量可随集群中节点的增加而线性扩展）

（2）高并发访问能力：提供很高的数据访问宽带（高数据吞吐率），并且可以把带宽的大小等比例扩展到集群中的全部节点上

（3）强大的容错能力：（设计理念中硬件故障被视作常态）保证在经常有节点发生硬件故障的情况下正确检测硬件故障，并且能自动从故障中快速恢复，确保数据不丢失（采用多副本数据块形式存储）

（4）顺序式文件访问：（大数据批处理都是大量简单数据记录的顺序处理）对顺序读进行了优化，支持大量数据的快速顺序读出，代价是对于随机的访问负载较高

（5）简单的一致性模型（一次写多次读）：支持大量数据的一次写入，多次读取；不支持已写入数据的更新 *** 作，但允许在文件尾部添加新的数据

（6）数据块存储模式：默认的块大小是64MB。好处：减少元数据的数量，允许这些数据块通过随机方式选择节点，分布存储在不同地方

2基本框架与工作过程

（1）基本组成结构与文件访问过程

[1]HDFS；一个建立在一组分布式服务器节点的本地文件系统之上的分布式文件系统（采用经典主-从结构）

[2]主控节点NameNode:

1）是一个主服务器，用来管理整个文件系统的命名空间和元数据,以及处理来自外界的文件访问请求

2）保存了文件系统的三中元数据

命名空间：整个分布式文件系统的目录结构

数据块与文件名的映射表

每个数据块副本的位置信息，每一个数据块默认有3个副本

[3]从节点DataNode：

1）用来实际存储和管理文件的数据块

2）为了防止数据丢失，每个数据块默认有3个副本，且3个副本会分别复制在不同节点上，以避免一个节点失效造成一个数据块的彻底丢失

[4]程序访问文件时，实际文件数据流并不会通过NameNode传送，而是从NameNode获得所需访问数据块的存储位置信息后，直接去访问对应的DataNode获取数据

[5]设计好处：

1）可以允许一个文件的数据能同时在不同DataNode上并发访问，提高数据访问的速度

2）减少NameNode的负担，避免使NameNode成为数据访问瓶颈

[6]基本访问过程：

1）首先，用户的应用程序通过HDFS的客户端程序将文件名发送至NameNode

2）NameNode接收到文件名之后，在HDFS目录中检索文件名对应的数据块，再根据数据块信息找到保存数据块的DataNode地址，讲这些地址回送到客户端

3）客户端接收到这些DataNode地址之后，与这些DataNode并行的进行数据传输 *** 作，同时将 *** 作结果的相关日志提交到NameNode

2数据块

（1）为了提高硬盘的效率，文件系统中最小的数据读写单元是数据块

（2）HDFS数据块的默认大小是64MB，实际部署中，可能会更多

（3）将数据块设置大的原因是减少寻址开销的时间

（4）当应用发起数据传输请求：

[1]NameNode首先检索文件对应的数据块信息，找到数据块对应的DataNode

[2]DataNode根据数据块信息在自身的存储中寻找相应的文件，进而与应用程序之间交换数据

[3]因为检索过程是但进行，所以要增加数据块大小，这样就可以减少寻址的频度和时间开销

3命名空间

（1）文件命名遵循“目录/子目录/文件”格式

（2）通过命令行或者是API可以创建目录，并且将文件保存在目录中。可以对文件进行创建，删除，重命名 *** 作

（3）命令空间由NameNode管理。所有对命名空间的改动都会被记录

（4）允许用户配置文件在HDFS上保存的副本数量，保存的副本数称作“副本因子”

4通信协议

（1）采用TCP协议作为底层的支撑协议

（2）应用协议

[1]应用可以向NameNode主动发起TCP连接

[2]应用和NameNode交互协议称为Client协议

[3]NameNode和DataNode交互的协议称为DataNode协议

（3）用户和DataNode的交互是通过发起远程调用（RPC），并由NameNode响应来完成的。另外，NameNode不会主动发起远程过程调用请求

5客户端：是用户和HDFS通信最常见的渠道，部署的HDFS都会提供客户端

二，HDFS可靠性设计

1HDFS数据块多副本存储设计

（1）采用了在系统中保存多个副本的方式保存数据，且同一个数据块的多个副本会存放在不同节点上

（2）优点：

[1]采用多副本，可以让客户从不同数据块中读取数据，加快传输速度

[2]HDFS的DataNode之间通过网络传输数据，如果采用多个副本可以判断数据传输是否出错

[3]多副本可以保证某个DataNode失效的情况下，不会丢失数据

2可靠性的设计实现

（1）安全模式：

[1]HDFS启动时，NameNode进入安全模式

[2]处于安全模式的NameNode不能做任何文本 *** 作，甚至内部的副本创建不允许

[3]NameNode需要和各个DataNode通信，获得其中保存的数据块信息，并对数据块信息进行检查

[4]只有通过了NameNode检查，一个数据块被认为安全。当被认为安全的数据块所占比例达到某个阈值，NameNode退出

（2）SecondaryNmaeNode

[1]使用它来备份NameNode元数据，以便在其失效时能从中恢复出其上的元数据

[2]它充当NameNode的一个副本，本身并不处理任何请求。

[3]作用：周期性保存NameNode的元数据

（3）心跳包和副本重新创建

[1]心跳包：位于HDFS核心的NameNode，通过周期性的活动检查DataNode的活动

[2]检测到DataNode失效，保存在其上的数据不可用。则其上保存的副本需要重新创建这个副本，放到另外可用的地方

（4）数据一致性

[1]采用了数据校验和机制

[2]创建文件时，HDFS会为这个文件生成一个校验和，校验和文件和文件本身保存在同一空间上，

[3]传输数据时会将数据与校验和一起传输，应用收到数据后可以进行校验

（5）租约

[1]防止同一个文件被多个人写入数据

[2]NameNode保证同一个文件只会发放一个允许的租约，可以有效防止出现多人写入的情况

（6）回滚

三，HDFS文件存储组织与读写

1文件数据的存储组织

（1）NameNode目录结构

[1]借助本地文件系统来保存数据，保存文件夹位置由配置选项（{dfsnamedir}/{/tmp/dfs/name}）决定

[2]在NameNode的${dfsnamedir}之下有3个文件夹和1个文件：

1）current目录：

文件VERSION:保存了当前运行的HDFS版本信息

FsImages:是整个系统的空间镜像文件

Edit：EditLog编辑文件

Fstime：上一次检查点时间

2）previouscheckpoint目录：和上一个一致，但是保存的是上一次检查点的内容

3）image目录：旧版本的FsImage存储位置

4）in_uselook:NameNode锁，只在NameNode有效（启动并且能和DataNode正常交互）时存在。

（2）DataNode目录结构

[1]借助本地文件系统来保存数据。保存文件夹位置由配置选项{dfsdatadir}决定

[2]在其之下有4个子目录和2个文件

1）current目录：已经成功写入的数据块，以及一些系统需要的文件

a)文件VERSION：保存了当前运行的HDFS版本信息

b)subdirXX:当同一目录下文件超过一定限制，新建一个目录，保存多出来的数据块和元数据

2）tmp目录和blockBeingWritten目录：正在写入的数据块，是HDFS系统内部副本创建时引发的写入 *** 作对应的数据块

3）detach目录：用于DataNode升级

4）Storage目录：防止版本不同带来风险

5）in_userlock文件：DataNode锁。只有在DataNode有效时存在。

（3）CheckPointNode目录结构：和上一个基本一致

2数据的读写过程

（1）数据读取过程

[1]首先，客户端调用FileSystem实例的open方法，获得这个文件对应的输入流，在HDFS中就是DFSInputStream

[2]构造第一步的输入流时，通过RPC远程调用NameNode可以获得NameNode中此文件对应的数据块保存位置，包括这个文件副本的保存位置（注：在输入流中会按照网络拓扑结构，根据与客户端距离对DataNode进行简单排序）

[3]-[4]获得此输入流后，客户端调用READ方法读取数据。输入流选择最近的DFSInputStream会根据前面的排序结果，选择最近的DataNode建立连接并读取数据。

[5]如果已达到数据块末端，关闭这个DataNode的连接，然后重新查找下一个数据块

[6]客户端调用close，关闭输入流DFSInputStream

（2）数据输入过程

[1]-[2]:客户端调用FileSystem实例的create方法，创建文件。检查后，在NameNode添加文件信息，创建结束之后，HDFS会返回一个输出流DFSDataOutputStream给客户端

[3]调用输出流的write方法向HDFS中对应的文件写入数据。

数据首先会被分包，这些分包会写入一个输出流的内部队列Data队列中，接收完整数据分包，输出流回想NameNode申请保存文件和副本数据块的若干个DataNode

[4]DFSDataOutputStream会（根据网络拓扑结构排序）将数据传输给距离上最短的DataNode，这个节点接收到数据包后传给下一个。数据在各节点之间通过管道流通，减少传输开销

[5]数据节点位于不同机器上，数据需要通过网络发送。（为保证数据节点数据正确，接收到数据的节点要向发送者发送确认包）

[6]执行3-5知道数据全部写完，DFSDataInputStream继续等待知道所有数据写入完毕并确认，调用complete方法通知NameNode文件写入完成

[7]NameNode接收到complete消息之后，等待相应数量的副本写入完毕后，告知客户端

传输过程，当某个DataNode失效，HDFS执行：

1）关闭数据传输的管道

2）将等待ACK队列的数据放到Data队列头部

3）更新正常DataNode中所有数据块版本。当失效的DataNode重启，之前的数据块会因为版本不对被清除

4）在传输管道中删除失效的DataNode,重新建立管道并发送数据包

4HDFS文件系统 *** 作命令

（1）HDFS启动与关闭

[1]启动过程：

1）进入到NameNode对应节点的Hadoop安装目录

2）执行启动脚本:bin/start-dfssh

[2]关闭过程:bin/stop-dfssh

（2）文件 *** 作命令格式与注意事项

[1]基本命令格式：

1）bin/hadoop dfs-cmd <args> args-> scheme://authority/path

2）args参数基本格式前面是scheme，authority是机器地址和对应端口

a)本地文件，scheme是file

b)HDFS上文件，scheme是hdfs

（3）文件 *** 作基本格式

[1]hadoop dfs-cat URL [URL ]

[2]作用：将参数所指示文件内容输出到stdout

    本篇文章翻译了Hadoop系列下的 HDFS Architecture ，原文最初经过笔者翻译后大概有6000字，之后笔者对内容进行了精简化压缩，从而使笔者自己和其他读者们阅读本文时能够更加高效快速的完成对Hadoop的学习或复习。本文主要介绍了Hadoop的整体架构，包括但不限于节点概念、命名空间、数据容错机制、数据管理方式、简单的脚本命令和垃圾回收概念。

    PS：笔者新手一枚，如果看出哪里存在问题，欢迎下方留言！

    Hadoop Distributed File System（HDFS）是高容错、高吞吐量、用于处理海量数据的分布式文件系统。

    HDFS一般由成百上千的机器组成，每个机器存储整个数据集的一部分数据，机器故障的快速发现与恢复是HDFS的核心目标。

    HDFS对接口的核心目标是高吞吐量而非低延迟。

    HDFS支持海量数据集合，一个集群一般能够支持千万以上数量级的文件。

    HDFS应用需要对文件写一次读多次的接口模型，文件变更只支持尾部添加和截断。

    HDFS的海量数据与一致性接口特点，使得迁移计算以适应文件内容要比迁移数据从而支持计算更加高效。

    HDFS支持跨平台使用。

    HDFS使用主从架构。一个HDFS集群由一个NameNode、一个主服务器（用于管理系统命名空间和控制客户端文件接口）、大量的DataNode（一般一个节点一个，用于管理该节点数据存储）。HDFS对外暴露了文件系统命名空间并允许在文件中存储用户数据。一个文件被分成一个或多个块，这些块存储在一组DataNode中。NameNode执行文件系统命名空间的打开关闭重命名等命令并记录着块和DataNode之间的映射。DataNode用于处理客户端的读写请求和块的相关 *** 作。NameNode和DataNode一般运行在GNU/Linux *** 作系统上，HDFS使用Java语言开发的，因此NameNode和DataNode可以运行在任何支持Java的机器上，再加上Java语言的高度可移植性，使得HDFS可以发布在各种各样的机器上。一个HDFS集群中运行一个NameNode，其他机器每个运行一个（也可以多个，非常少见）DataNode。NameNode简化了系统的架构，只用于存储所有HDFS元数据，用户数据不会进入该节点。下图为HDFS架构图：

    HDFS支持传统的分层文件管理，用户或者应用能够在目录下创建目录或者文件。文件系统命名空间和其他文件系统是相似的，支持创建、删除、移动和重命名文件。HDFS支持用户数量限制和访问权限控制，不支持软硬链接，用户可以自己实现软硬链接。NameNode控制该命名空间，命名空间任何变动几乎都要记录到NameNode中。应用可以在HDFS中对文件声明复制次数，这个次数叫做复制系数，会被记录到NameNode中。

    HDFS将每个文件存储为一个或多个块，并为文件设置了块的大小和复制系数从而支持文件容错。一个文件所有的块（除了最后一个块）大小相同，后来支持了可变长度的块。复制系数在创建文件时赋值，后续可以更改。文件在任何时候只能有一个writer。NameNode负责块复制，它周期性收到每个数据节点的心跳和块报告，心跳表示数据节点的正常运作，块报告包含了这个DataNode的所有块。

    副本存储方案对于HDFS的稳定性和性能至关重要。为了提升数据可靠性、灵活性和充分利用网络带宽，HDFS引入了机架感知的副本存储策略，该策略只是副本存储策略的第一步，为后续优化打下基础。大型HDFS集群一般运行于横跨许多支架的计算机集群中，一般情况下同一支架中两个节点数据传输快于不同支架。一种简单的方法是将副本存放在单独的机架上，从而防止丢失数据并提高带宽，但是增加了数据写入的负担。一般情况下，复制系数是3，HDFS存储策略是将第一份副本存储到本地机器或者同一机架下一个随机DataNode，另外两份副本存储到同一个远程机架的不同DataNode。NameNode不允许同一DataNode存储相同副本多次。在机架感知的策略基础上，后续支持了 存储类型和机架感知相结合的策略 ，简单来说就是在机架感知基础上判断DataNode是否支持该类型的文件，不支持则寻找下一个。

    HDFS读取数据使用就近原则，首先寻找相同机架上是否存在副本，其次本地数据中心，最后远程数据中心。

    启动时，NameNode进入安全模式，该模式下不会发生数据块复制，NameNode接收来自DataNode的心跳和块报告，每个块都有一个最小副本数量n，数据块在NameNode接受到该块n次后，认为这个数据块完成安全复制。当完成安全复制的数据块比例达到一个可配的百分比值并再过30s后，NameNode退出安全模式，最后判断是否仍然存在未达到最小复制次数的数据块，并对这些块进行复制 *** 作。

    NameNode使用名为EditLog的事务日志持续记录文件系统元数据的每一次改动（如创建文件、改变复制系数），使用名为FsImage的文件存储全部的文件系统命名空间（包括块到文件的映射关系和文件系统的相关属性），EditLog和FsImage都存储在NameNode本地文件系统中。NameNode在内存中保存着元数据和块映射的快照，当NameNode启动后或者某个配置项达到阈值时，会从磁盘中读取EditLog和FsImage，通过EditLog新的记录更新内存中的FsImage，再讲新版本的FsImage刷新到磁盘中，然后截断EditLog中已经处理的记录，这个过程就是一个检查点。检查点的目的是确保文件系统通过在内存中使用元数据的快照从而持续的观察元数据的变更并将快照信息存储到磁盘FsImage中。检查点通过下面两个配置参数出发，时间周期（dfsnamenodecheckpointperiod）和文件系统事务数量（dfsnamenodecheckpointtxns），二者同时配置时，满足任意一个条件就会触发检查点。

    所有的HDFS网络协议都是基于TCP/IP的，客户端建立一个到NameNode机器的可配置的TCP端口，用于二者之间的交互。DataNode使用DataNode协议和NameNode交互，RPC包装了客户端协议和DataNode协议，通过设计，NameNode不会发起RPC，只负责响应来自客户端或者DataNode的RPC请求。

    HDFS的核心目标是即使在失败或者错误情况下依然能够保证数据可靠性，三种常见失败情况包括NameNode故障、DataNode故障和network partitions。

    网络分区可能会导致部分DataNode市区和NameNode的连接，NameNode通过心跳包判断并将失去连接的DataNode标记为挂掉状态，于是所有注册到挂掉DataNode的数据都不可用了，可能会导致部分数据块的复制数量低于了原本配置的复制系数。NameNode不断地追踪哪些需要复制的块并在必要时候进行复制，触发条件包含多种情况：DataNode不可用、复制乱码、硬件磁盘故障或者认为增大负值系数。为了避免DataNode的状态不稳定导致的复制风暴，标记DataNode挂掉的超时时间设置比较长（默认10min），用户可以设置更短的时间间隔来标记DataNode为陈旧状态从而避免在对读写性能要求高的请求上使用这些陈旧节点。

    HDFS架构兼容数据各种重新平衡方案，一种方案可以在某个DataNode的空闲空间小于某个阈值时将数据移动到另一个DataNode上；在某个特殊文件突然有高的读取需求时，一种方式是积极创建额外副本并且平衡集群中的其他数据。这些类型的平衡方案暂时还未实现（不太清楚现有方案是什么）。

    存储设备、网络或者软件的问题都可能导致从DataNode获取的数据发生乱码，HDFS客户端实现了对文件内容的校验，客户端在创建文件时，会计算文件中每个块的校验值并存储到命名空间，当客户端取回数据后会使用校验值对每个块进行校验，如果存在问题，客户端就会去另一个DataNode获取这个块的副本。

    FsImage和EditLog是HDFS的核心数据结构，他们的错误会导致整个HDFS挂掉，因此，NameNode应该支持时刻维持FsImage和EditLog的多分复制文件，它们的任何改变所有文件应该同步更新。另一个选择是使用 shared storage on NFS 或者 distributed edit log 支持多个NameNode，官方推荐 distributed edit log 。

    快照能够存储某一特殊时刻的数据副本，从而支持HDFS在发生错误时会滚到上一个稳定版本。

    HDFS的应用场景是大的数据集下，且数据只需要写一次但是要读取一到多次并且支持流速读取数据。一般情况下一个块大小为128MB，因此一个文件被切割成128MB的大块，且每个快可能分布在不同的DataNode。

    当客户端在复制系数是3的条件下写数据时，NameNode通过目标选择算法收到副本要写入的DataNode的集合，第1个DataNode开始一部分一部分的获取数据，把每个部分存储到本地并转发给第2个DataNode，第2个DataNode同样的把每个部分存储到本地并转发给第3个DataNode，第3个DataNode将数据存储到本地，这就是管道复制。

    HDFS提供了多种访问方式，比如 FileSystem Java API 、 C language wrapper for this Java API 和 REST API ，而且还支持浏览器直接浏览。通过使用 NFS gateway ，客户端可以在本地文件系统上安装HDFS。

    HDFS使用目录和文件的方式管理数据，并提供了叫做 FS shell 的命令行接口，下面有一些简单的命令：

    DFSAdmin命令集合用于管理HDFS集群，这些命令只有集群管理员可以使用，下面有一些简单的命令：

正常的HDFS安装都会配置一个web服务，通过可配的TCP端口对外暴露命名空间，从而使得用户可以通过web浏览器查看文件内容。

如果垃圾回收配置打开，通过FS shell移除的文件不会立刻删除，而是会移动到一个垃圾文件专用的目录（/user/<username>/Trash），类似回收站，只要文件还存在于那个目录下，则随时可以被回复。绝大多数最近删除的文件都被移动到了垃圾目录（/user/<username>/Trash/Current），并且HDFS每个一段时间在这个目录下创建一个检查点用于删除已经过期的旧的检查点，详情见 expunge command of FS shell 。在垃圾目录中的文件过期后，NameNode会删除这个文件，文件删除会引起这个文件的所有块的空间空闲，需要注意的是在文件被删除之后和HDFS的可用空间变多之间会有一些时间延迟（个人认为是垃圾回收机制占用的时间）。下面是一些简单的理解删除文件的例子：

    当文件复制系数减小时，NameNode会选择多余的需要删除的副本，在收到心跳包时将删除信息发送给DataNode。和上面一样，这个删除 *** 作也是需要一些时间后，才能在集群上展现空闲空间的增加。

HDFS Architecture

基于文件的影像数据库管理方式是将影像文件以文件夹的形式存储在计算机的硬盘或网络存储设备中，并使用文件目录结构来组织和管理文件。其优缺点如下：

优点：

1 管理简单易懂：基于文件的影像数据库管理方式，可以方便地使用 *** 作系统自带的文件管理工具进行管理，不需要额外的数据库管理软件或技术支持，易于理解与 *** 作。

2 通用性强：不像基于数据库的方案那样需要事先定义好数据结构，可以存储不同格式和大小的影像文件，兼容性好，适用于多种应用场景。

3 灵活性强：由于影像文件以文件夹的形式存储，可以方便地自定义目录结构，根据实际需求进行管理。

4 性能高：由于没有中间软件，对计算机资源的消耗较小，速度相对较快。

缺点：

1 安全性差：基于文件的影像数据库管理方式缺乏对数据的有效保护措施，易受到病毒、黑客、误删等风险。

2 数据冗余：文件文件管理方式的文件系统中，有可能存在重复保存的文件，导致数据库中包含有大量冗余数据，占用空间较大。

3 维护成本高：若文件目录结构建立不规范，需要更改目录结构时，会带来很高的维护成本。

4 受硬件限制：由于其数据存储在磁盘中，磁盘的容量、读写速度等硬件因素限制了基于文件的影像数据库管理方式的Storage容量和检索效率。

总之，基于文件的影像数据库管理方式具有通用性较强、管理简单、灵活性高、性能较优等优点，适用于小规模、简单的数据管理需求，但数据的安全性与维护成本仍是它的弱点。

以上就是关于如何对数据库进行管理全部的内容，包括:如何对数据库进行管理、第三章 大数据存储、Hadoop系列之HDFS架构等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！