InnoDB数据存储结构

索引的数据结构

存储引擎

逻辑架构

用户与权限管理

Windows 和 Linux 版安装详细步骤。

Hadoop

https://zh.wikipedia.org/zh-cn/Apache_Hadoop

https://hadoop.apache.org/

Apache Hadoop 是一个开源软件框架，它使用简单的编程模型提供高度可靠的大型数据集分布式处理。Hadoop 以其可扩展性而闻名，它构建在商用计算机集群上，为存储和处理大量结构化、半结构化和非结构化数据提供了经济高效的解决方案，且没有格式要求。

Apache Hadoop的核心模块分为存储和计算模块。Apache Hadoop框架由以下基本模块构成：

• Hadoop Common – 包含了其他 Hadoop 模块所需的库和实用程序；在0.20及以前的版本中，包含HDFS、MapReduce和其他项目公共内容，从0.21开始HDFS和MapReduce被分离为独立的子项目，其余内容为Hadoop Common

• Hadoop Distributed File System (HDFS，Hadoop分布式文件系统) – 一种将数据存储在集群中多个节点中的分布式文件系统，能够提供很高的带宽；

• Hadoop MapReduce – 用于大规模数据处理的MapReduce计算模型实现；

• Hadoop YARN – （于2012年引入） 一个负责管理集群中计算资源，并实现用户程序调度的平台；

• Hadoop Ozone – （于2020年引入） Hadoop的对象存储。

Apache Hadoop的MapReduce和HDFS模块的灵感来源于Google的 MapReduce 和 Google File System 论文。

大致工作流程：Hadoop框架先将文件分成数据块并分布式地存储在集群的计算节点中，接着将负责计算任务的代码传送给各节点，让其能够并行地处理数据。这种方法有效利用了数据局部性，令各节点分别处理其能够访问的数据。与传统的超级计算机架构相比，这使得数据集的处理速度更快、效率更高。

HDFS

https://www.ibm.com/cn-zh/topics/hdfs

[HDFS概述介绍及其优缺点](https://blog.csdn.net/mr123666/article/details/103310926) 

HDFS 是一种分布式文件系统，用于处理在商业硬件上运行的大型数据集。 它用于将单个 Apache Hadoop 集群扩展到数百 （甚至数千）个节点。 HDFS 不应与 Apache HBase 混淆或被 Apache HBase 取代，Apache HBase 是一个面向列的非关系数据库管理系统，它位于 HDFS 之上，可以通过其内存处理引擎更好地支持实时数据需求。

MapReduce

https://www.ibm.com/cn-zh/topics/mapreduce

MapReduce 是一种编程范式，它允许在 Hadoop 聚类中的数百或数千台服务器之间进行大规模扩展。 作为处理组件，MapReduce 是 Apache Hadoop 的核心。 术语“MapReduce”指的是 Hadoop 程序执行的两个不同的独立任务。 第一个是映射作业，它接受一组数据，并将其转换为另一组数据，其中各个元素分解为元组（键/值对）。

缩减作业以映射的输出作为输入，并将这些数据元组组合为更小的一组元组。 正如名称 MapReduce 的顺序所暗示的那样，缩减作业总是在映射作业之后执行。

MapReduce 编程提供了一些优势，有助于从您的大数据获得宝贵的洞察：

• 可扩展性。 企业可以处理 Hadoop Distributed File System (HDFS) 中存储的 PB 级数据。
• 灵活性。 利用 Hadoop，可以更轻松地访问多个数据源和多个类型的数据。
• 速度。 利用并行处理和最小数据迁移，Hadoop 提供了大量数据的快速处理。
• 简便易用。 开发者可以使用一系列语言（包括 Java、C++ 和 Python）编写代码。

HBase

https://zh.wikipedia.org/zh-cn/Apache_HBase

https://HBase.apache.org/

https://www.ibm.com/cn-zh/topics/HBase

Hadoop database 的简称。是一款基于 Hadoop HDFS 的数据库，是一种NoSQL数据库，主要适用于海量明细数据（十亿、百亿）的随机实时查询，如日志明细、交易清单、轨迹行为等。

HBase 是一个在 HDFS 上运行的列式存储非关系数据库管理系统。 HBase 提供了存储稀疏数据集的容错方式，这类数据集在许多大数据用例中十分常见。 它非常适合实时数据处理或者对大量数据的随机读取/写入访问。

与关系数据库系统不同，HBase 不支持 SQL 一类的结构化查询语言；事实上，HBase 根本不是关系数据存储库。 HBase 应用程序以 Java 编写，更像是一款典型的 Apache MapReduce 应用程序。 HBase 确实支持以 Apache Avro、REST 和 Thrift 编写应用程序。

HBase 系统设计为线性扩展。 它包括一系列由行和列组成的标准表，更像是传统数据库。 每个表必须有一个定义为主键的元素，且所有对 HBase 表的访问尝试都必须使用此主键。

Avro 作为组件，支持一系列丰富的原始数据类型（包括数字、二进制数据和字符串）以及多种复杂类型（包括数组、映射、枚举和记录）。 对于数据，也可以定义排序顺序。

HBase 依赖于 zookeeper 实现高性能协调。 zookeeper 内置到 HBase 中，但如果您正在运行生产集群，那么建议您配备一个与 HBase 集成的专用 ZooKeeper 集群。

HBase 非常适合与 Hive 结合使用，后者是用于大数据批处理的查询引擎，以支持容错性大数据应用程序。

维基百科

HBase是一个开源的<font color="red">非关系型分布式数据库（NoSQL）</font>，它参考了谷歌的BigTable建模，实现的编程语言为 Java。它是Apache软件基金会的Hadoop项目的一部分，运行于HDFS文件系统之上，为 Hadoop 提供类似于BigTable 规模的服务。因此，它可以对稀疏文件提供极高的容错率。

HBase在列上实现了BigTable论文提到的压缩算法、内存操作和布隆过滤器。HBase的表能够作为MapReduce任务的输入和输出，可以通过Java API来访问数据，也可以通过REST、Avro或者Thrift的API来访问。

虽然最近性能有了显著的提升，HBase 还不能直接取代SQL数据库。如今，它已经应用于多个数据驱动型网站，包括 Facebook的消息平台。

在 Eric Brewer的 [CAP理论](https://zh.wikipedia.org/zh-cn/CAP%E5%AE%9A%E7%90%86) 中，HBase属于CP类型的系统。

总结：

• HBase中的表是物理表，不是逻辑表，提供一个超大的内存hash表，搜索引擎通过它来存储索引，方便查询操作。
• HBase可以认为是 HDFS 的一个包装。它的本质是数据存储，是个NoSql数据库。它基于列的而不是基于行的模式处理数据，相比 HDFS 更适合海量数据的随机访问。
• HBase的表是疏松型，因此用户可以给行定义各种不同的列。
• HBase是近实时系统，支持实时查询。
• HBase支持row-level的更新。
• HBase不使用与有join、多级索引、表关系复杂的应用场景。

Hive

https://zh.wikipedia.org/zh-cn/Apache_Hive

https://hive.apache.org/

Hive 是基于Hadoop的一个<font color="red">数据仓库工具</font>，<font color="red">可以将结构化的数据文件映射为一张数据库表，并提供简单的SQL查询功能，并将SQL语句最终转换为 **MapReduce** 任务进行运行。</font>主要是让开发人员能够通过 SQL 来计算和处理 HDFS 上的结构化数据，**适用于离线的批量数据计算**。

Apache Hive 是一种分布式、容错的数据仓库系统，可实现大规模分析。<font color="red">Hive Metastore (HMS) 提供了一个元数据的中央存储库，</font>可以轻松分析该元数据以做出明智的、数据驱动的决策，因此它是许多数据湖架构的关键组件。Hive 构建在 Apache Hadoop 之上，通过 hdfs 支持 S3、adls、gs 等存储。Hive 允许用户使用 SQL 读取、写入和管理分布式存储中的 PB 级数据。

通过元数据来描述 HDFS 上的结构化文本数据，通俗点来说，就是定义一张表来描述HDFS上的结构化文本，包括各列数据名称，数据类型是什么等，方便我们处理数据，当前很多SQL ON Hadoop的计算引擎均用的是hive的元数据，如Spark SQL、Impala等；

总结：

• Hive中的表是纯逻辑表，就只是表的定义等，即表的元数据。Hive 本身不存储和计算数据，它完全依赖于HDFS存储文件和MapReduce计算框架。
• Hive可以认为是 MapReduce 的一个包装，它基于 MapReduce 处理数据，而 MapReduce 基于行的模式处理数据。Hive 的意义就是把好写的 HiveSQL 转换为复杂难写的 map-reduce 程序。
• Hive的表是稠密型，即定义多少列，每一行有存储固定列数的数据。
• Hive使用Hadoop来分析处理数据，而Hadoop系统是批处理系统，因此不能保证处理的低延迟问题。
• Hive不提供row-level的更新，它适用于大量append-only数据集（如日志）的批处理任务。
• Hive提供完成的SQL实现，通常被用来做一些基于历史数据的挖掘、分析。

			<font color="blue">**Hive Metastore (HMS)**</font> 是关系数据库中 Hive 表和分区 元数据的中央存储库，并为客户端**（包括 Hive、Impala 和 Spark）**提供使用 Metastore 服务 API 访问此信息的能力。它已成为利用各种开源软件（例如 Apache Spark 和 Presto）的数据湖的构建块。事实上，整个工具生态系统（开源工具和其他工具）都是围绕 Hive Metastore 构建的，此图展示了其中一些工具。

Hive和HBase的关系

HBase和Hive在大数据架构中处在不同位置，HBase主要解决实时数据查询问题，Hive主要解决数据处理和计算问题，一般是配合使用。

在大数据架构中，Hive和HBase是协作关系，数据流一般如下图：

1. 通过ETL工具将数据源抽取到HDFS存储；
2. 通过Hive清洗、处理和计算原始数据；
3. HIve清洗处理后的结果，如果是面向海量数据随机查询场景的可存入HBase
4. 数据应用从HBase查询数据；

Impala

Impala是用于处理存储在Hadoop集群中的大量数据的MPP（大规模并行处理）SQL查询引擎。 它是一个用C ++和Java编写的开源软件。与其他Hadoop的SQL引擎相比，它提供了高性能和低延迟。

优点

1. 支持JDBC/ODBC远程访问，支持SQL查询，快速查询大数据。
2. 无需转换为MR，直接读取HDFS数据。
3. 支持Data Local，可以对已有数据进行查询，减少数据的加载，转换。
4. 支持列式存储，多种存储格式可以选择（Parquet, Text, Avro, RCFile, SequeenceFile）。
5. 可以与Hive配合使用,兼容HiveSQL， 可对hive数据直接做数据分析。
6. 基于内存进行计算，能够对PB级数据进行交互式实时查询、分析。

缺点

1. 不支持用户定义函数UDF。
2. 不支持text域的全文搜索。
3. 不支持Transforms。
4. 不支持查询期的容错。（发生故障，则直接返回错误）
5. 对内存要求高。
6. 完全依赖于hive。
7. 实践过程中 分区超过1w 性能严重下降。
8. Impala不提供任何对序列化和反序列化的支持。
9. Impala只能读取文本文件，而不能读取自定义二进制文件。
10. 每当新的记录/文件被添加到HDFS中的数据目录时，该表需要被刷新。

Impala和关系数据库

Impala与hive

相同点

• 数据储存：使用相同的数据存储池，都可以将数据的储存在HDFS或HBase中。
• 元数据：两者使用相同的元数据
• SQL解释处理：比较相似的就是都是通过词法分析生成执行计划。
• 查询计划树

不同点

• 执行计划
  hive依赖于MapReduce执行框架，执行计划分成map->shuffle-reduce->…的模型。如果是一个Query则会有很多的写中间结果，由于MapReduce的执行特点，MapReudce任务的开启过程会增加过多的时间
  Impala将执行计划表现为一颗完整的执行计划树，Impala将所有的执行计划分发到Impala进行查询执行，避免了MR中sort和shuffle过程中的时间浪费。
• 数据流
  hive:采用push推的方式，将每次计算的结果都push达到下一个节点。
  Impala:采用pull拉取的方式，将本节点需要的结果从上一个节点执行完的结果中进行pull拉取。
• 内存使用
  Hive: 在执行过程中如果内存放不下所有数据，则会使用外存，以保证Query能顺序执行完。每一轮MapReduce结束，中间结果也会写入HDFS中，同样由于MapReduce执行架构的特性，shuffle过程也会有写本地磁盘的操作。
  Impala: 在遇到内存放不下数据时，当前版本0.1是直接返回错误，而不会利用外存，以后版本应该会进行改进。这使用得Impala目前处理Query会受到一定的限制，最好还是与Hive配合使用。Impala在多个阶段之间利用网络传输数据，在执行过程不会有写磁盘的操作（insert除外）
• 调度
  hive任务调度依赖于hadoop的调度策略
  Impala调度由自己完成，目前只有一种调度器，simple schedule，它会尽量满足数据的局部性，扫描数据的进程尽量靠近数据本身所在的节点服务器。调度器目前还比较简单，在Simple Scheduler::GetBackend中可以看到，现在还没有考虑负载，网络IO状况等因素进行调度。但目前Impala已经有对执行过程的性能统计分析，应该以后版本会利用这些统计信息进行调度吧。
• 容错
  Hive依赖于Hadoop的容错能力。
  Impalad:在查询过程中，没有容错逻辑，如果在执行过程中，发生故障，则直接返回错误（这与Impalad的设计有关，因为Impala定位于实时查询，一次查询失败，再查询一次就好，再查一次的成本很低）。但从整体来看，Impala是能很好的容错，所有的Impalad是对等的结构，用户可以向任何一个Impalad提交查询，如果一个Impalad失效，其上正在运行的所有Query都将失败，但用户可以重新提交查询由其它Impalad代替执行，不会影响服务。对于State Store目前只有一个，但当State Store失效，也不会影响服务，因为每个Impala都同步了State store的信息。只是不能再次更新集群的状态了。有可能会将执行计划分配给已经失效的Impalad执行。
• 适用场景
  Hive:复杂的批处理查询任务，数据转换任务。
  Impala:实时数据分析，因为不支持UDF,能处理的问题有一定的限制，与Hive配合使用，对Hive的结果数据集进行实时分析。

Hive，HBase和Impala

分布式执行

以⼀个SQL例⼦来展示查询计划

1
2
3
4
5
6
7
8
9
10
11

select
	t1.n1,
	t2.n2,
	count(1) as c
  from t1
  join t2 on t1.id = t2.id
  join t3 on t1.id = t3.id
 where t3.n3 between 'a' and 'f'
 group by t1.n1, t2.n2
 order by c desc
 limit 100;

单机执行计划

分析上⾯的单机执⾏计划，第⼀步先去扫描 t1 表中需要的数据，如果数据⽂件存储是列式存储我们可以便利的扫描到所需的列 id, n1; 接着需要与 t2 表进⾏ Join 操作，扫描 t2 表与 t1 表类似获取到所需数据列 id, n2。t1 与 t2 表进⾏关联执行 join 操作，关联之后再与 t3 表进⾏关联，这⾥会使⽤谓词下推扫描 t3 表只取 join 所需数据；关联三个表得到数据后，对 group by 进⾏相应的 aggregation 操作，最终是排序取出指定数量的数据返回。

这里由于是在一台机器上完成上述过程，所以逻辑上还是比较直观的。但是倘若所查询的 T1 和 T2 的数据都比较大，无法在一台机器上存储，或者单机执行效率太慢，这个时候就需要分布式并行执行计划来执行上述流程。

分布式并行执行计划

所谓的分布式并行化执行计划，就是在单机执行计划基础之上结合数据分布式存储的特点，按照任务的计要求把单机执行计划拆分为多段子任务，每个子任务都是可以并行执行的。上面的单机执行计划转为分布式并行执行计划如下图所示：

整体流程

一、Hash join分区

首先底层仍然先执行的是数据间的 join 操作。这里我们假设 T1 表和 T2 表是大表，分布在三个节点上（三台机器上）。而 T3 表是小表，只存储在第三个节点。此时为了做表之间数据的 Join 操作，可以想到需要将相同 id 字段的数据汇总到一起，这样才能进行拼接。 为了实现该过程，分布式执行计划会首先根据 T1 和 T2 两个大表中数据的 id 字段进行 hash join，采取的公式类似于：

这个是 MapReduce 中 HashPartitioner 类中的方法。可以看出上式的分区结果只与 key 值的 hashCode 有关。这里 id 字段是 int 类型，则 hashCode 就是其本身，所以通过上式，就可以实现将T1和T2表中相同id字段的数据划分到同一分区中。（这里要注意的是，不是id为1的字段进入一个分区，2、3、4、5…都各进入一个分区，通过上式可以看出是对分区大小取%的操作，图中分区大小是3，因此id为1,4,7…的数据进入同一分区。）

同时要注意的是，对于 T3 表与 T1、T2 表数据的关联采用的不是 hash join，而是利用 Broadcast 来进行 join。 因为 T3 表的数据量较小，如果仍然采用 hash join 的话，就需要在 T1 表和 T2 表通过 hash join 分区后，再利用 hash join 与 T3 表重复执行一遍上述分区流程。这样增加了不同节点间网络传输的开销，也降低了执行效率。因此，对于小表，分布式执行计划采用的方法是利用广播机制，将该 T3 表直接分发到三个节点上。这样每个节点在执行完 T1 表与 T2 表的关联后，就可以直接在本机上执行与 T3 表的关联。

通过上面的步骤，就可以保证对于 T1 表和 T2 表，id 字段相同的数据进入到同一分区中进行 join 操作，然后再与本机的 T3 表进行 join 操作。即完成了 sql 中的

1
2
3

from t1
join t2 on t1.id = t2.id
join t3 on t1.id = t3.id

二、分区内预聚合

这一步相当于执行 group by 的步骤。因为在分区时每条数据都带着各自的字段，也就包含着 n1, n2 的数据，所以此时在每个分区中，就可以对该分区内的数据按照 n1, n2 的值，执行 group by 操作进行一个局部的预聚合。

三、全局聚合

通过上述操作可以得到分区内的局部预聚合。但此时，条件相同的 n1, n2 可能分散在各个分区中（因为最初是按 id 字段分区的）。因此还需要一个全局的聚合，把所有 hash 结果相同的 <n1, n2> 进行汇总，这样才能得到最后的结果。因此，此时各个分区中预聚合(group by)后的数据会根据该组的 <n1, n2> 值再利用 hash join 进行分区，使得对 <n1, n2> 的 hash 值相同的数据组发送到同一分区中(此时数据量经过预聚合后已经变小了，所以就可以减少分区数，图上减少为 2 个)。这样在每个分区中每个组内的数据都是包含了所有 <n1, n2> Hash 值相等的结果，也即可以得到 SQL 查询语句中 group by 的最终结果(相当于原查询语句中，group by n1, n2 后所有应该进入同一分组中的数据)。

四、局部TopN

除了上述过程可以并行外，还有其它操作也可以并行吗？由于原SQL语句有 order by limit 操作，所以其实还可以在全局聚合后执行局部的 order by limit 操作。由于order by 操作是对得到的最终结果进行 order by，因此，这里就可以在每个分区进行全局聚合后，对得到的 count(1) as c 进行 order by limit 操作，得到局部的 Top100 的结果。这样同样减少了网络间传输的数据量，同时也体现了并行执行的特点。

五、全局TopN

最后，就是将所有的数据进行汇总，然后执行全局的order by limit 操作，就可以得到最终的结果。

整体的分布式并行执行计划流程图如下图所示：

各部分的具体操作就如上述流程介绍中所示。对上述流程的总结如下：

1. T1 和 T2 使⽤ Hash join，此时需要按照 id 的值分别将 T1 和 T2 分散到不同的进程，但是相同的 id 会散列到相同的进程，这样每⼀个 Join 之后是全部数据的⼀部分
2. T1 与 T2 Join之后的结果数据再与 T3 表进⾏ Join，此时 T3 表采⽤ Broadcast ⽅式把⾃⼰全部数据(id列)⼴播到需要的节点上
3. T1, T2, T3 Join之后再根据 Group by 执⾏本地的预聚合，每⼀个节点的预聚合结果只是最终结果的⼀部分（不同的节点可能存在相同的 group by 的值），需要再进⾏⼀次全局的聚合。
4. 全局的聚合同样需要并⾏，则根据聚合列进⾏Hash分散到不同的节点执⾏ Merge 运算（其实仍然是⼀次聚合运算），⼀般情况下为了较少数据的⽹络传输， 会选择之前本地聚合节点做全局聚合⼯作。
5. 通过全局聚合之后，相同的 key 只存在于⼀个节点，然后对于每⼀个节点进⾏排序和 TopN 计算，最终将每⼀个全局聚合节点的结果返回进⾏合并、排序、limit计算，返回结果给⽤户。

连接查询优化

一文读懂Impala统计信息相关知识 、 使用Impala hint加速SQL查询 、 Impala简明调优手册

方式一

优化连接最简单的方式就是使用 COMPUTE STATS 命令搜集所以参与关联表的统计信息，让 Impala 根据每个表的大小、列的非重复值个数等相关信息自动优化查询。为保证统计信息的准确性，我们需要在对表 INSERT、LOAD DATA 或者添加分区等操作之后及时执行 COMPUTE STATS 命令搜集统计信息。

Impala查询优化器根据表的绝对大小和相对大小为连接查询选择不同的关联技术，它提供了两种连接方式：

• 默认的连接方式是 Broadcast 连接，当右表比左表小时，它的内容会被发送到所有执行查询的节点上。
• 另一种连接方式是 partitioned 连接，它使用大小差不太多的大表关联。使用此种方式关联，为了保证关联操作可以并行执行，每个表的一部分数据都会被发送到不同节点上，最后各节点分别对传送过来的数据并行处理。

具体Impala优化器选择哪种连接方式，完全依赖于通过 COMPUTE STATS 搜集的表统计信息。为了确认表的连接策略，我们可以对一个特定的查询执行 EXPLAIN 语句。如果通过基准测试我们可以确认一种连接方式比另一种连接方式效率更高，也可以通过 Hint 的方式手动指定需要的连接方式。

方式二

当统计信息不可用时如何关联

如果参与关联的表的统计信息不可用，而且 Impala 自动选择的连接顺序效率很低，我们可以在 SELECT 关键字之后使用 STRAIGHT_JOIN 关键字手动指定连接的顺序。

如果参与关联的某些表的统计信息还是可用的，Impala会根据存在统计信息的表重新生成连接顺序。有统计信息的表会被放置在连接顺序的最左端，并根据表的基数和规模降序排列。而没有统计信息的表被作为空表对待，总是放在连接顺序的最右端。

方式三

使用 STRAIGHT_JOIN 覆盖连接顺序

如果关联查询由于统计信息不可用、或过期、或者数据分布等问题导致效率低下，我们可以通过指定STRAIGHT_JOIN关键字改变连接顺序。使用该关键字后，关联查询将不会使用 Impala 查询优化器自动生成的连接顺序，而是使用查询中表出现的先后顺序作为关联的顺序。对于手动指定连接顺序的查询，我们可能需要根据情况对连接顺序进行微调，比如有四张表分别为BIG、MEDIUM、SMALL、TINY，那连接顺序可以调整为：BIG、TINY、SMALL、MEDIUM。

如下示例中，表 BIG 经过过滤实际上产生了一个非常小的结果集，而 Impala 仍然把它作为最大的表对待放在连接顺序的最左侧。为了改变优化器错误的判断，我们使用 STRAIGHT_JOIN 改变连接的顺序，把 BIG 表放到了联机顺序的最右侧：

1
2
3
4
5

select straight_join x
  from medium
  join small
  join (select * from big where c1 < 10) as big
 where medium.id=small.id and small.id=big.id;

ImpalaSQL优化思路

• 大表和小表JOIN时，确保大表在左侧，小表在右侧（Impala 会广播小表到所有节点）;
• 有四张表分别为BIG、MEDIUM、SMALL、TINY，那连接顺序可以调整为：BIG、TINY、SMALL、MEDIUM。

优质文章推荐

SQL优化器-RBO与CBO分别是什么

sql 算法 : Nested Loop，Hash Join，Merge Join介绍

看懂Oracle执行计划

MySQL优化

执行计划中包含的信息 - 阿里云

MySQL Explain详解

MySQL高级 之 explain执行计划详解

MySQL数据库：explain执行计划详解

不允许你不知道的 MySQL 优化实战（一）

不允许你不知道的 MySQL 优化实战（二）

不允许你不知道的 MySQL 优化实战（三）

推荐链接：

分类:字符编码 - 维基百科

分类:字符集 - 维基百科

字符编码 - 维基百科

字符集和字符编码 - 菜鸟

字符编码笔记：ASCII，Unicode 和 UTF-8 - 阮一峰

参考链接： https://blog.51cto.com/1inux/1638154

什么是CA

数字证书认证机构（英语：Certificate Authority，缩写为CA），是指发放、管理、废除数字证书的机构。CA的作用是检查证书持有者身份的合法性，并签发证书（在证书上签字），以防证书被伪造或篡改，以及对证书和密钥进行管理。

为什么使用CA

CA 是PKI（Public Key Infrastructure）体系的核心。它为客户的公开密钥签发公钥证书、发放证书和管理证书，并提供一系列密钥生命周期内的管理服务。它将客户的公 钥与客户的名称及其他属性关联起来，为客户之间电子身份进行认证。证书中心是一个具有权威性、可信赖性和公证性的第三方机构。它是电子商务存在和发展的基础。

简单的说，使用CA不仅能保证数据的安全传输，还能保证目标的可信赖性。