在过去很长的一段时间中，关系型数据库（Relational DatabaseManagement System）一直是最主流的数据库解决方案，它运用真实世界中的事务与关系来解释数据库中抽象的数据结构。而熟悉关系型数据库的朋友，相信对于数据字典这个词应该也不会陌生，它曾经是关系型数据库的重要组成部分，用户可以通过访问数据字典的方式，查看数据库的元数据信息和数据库的运行状态。

随着大数据时代的到来，传统的关系型数据库在处理海量数据时已显得力不从心，很多大数据解决方案应运而生。而在大数据解决方案中，数据字典的作用依然重要，本文就从关系型数据库到大数据的变迁中，谈谈数据字典的故事。

数据字典（Data Dictionary）是一种用户可以访问的记录数据库和应用程序元数据（Metadata）的目录。而元数据是指对数据对象（如表、视图、存储过程等）的描述，包括数据容器的名称、创建时间、创建者或属者、物理存放位置等基础元信息，还包括外部实体、参照完整性等与其他对象的关联信息。

数据字典最重要的作用是作为分析阶段的工具，具体如下：

管理系统数据资源——数据字典提供了管理和收集数据的方法；

实现数据标准化——在数据库中，数据的名称、格式和涵义等在不同的场合下容易混淆，数据字典提供使之标准化的工具，它可以给这些内容予以统一的名称、格式和涵义；

使系统的描述文体化——所有和系统有关的描述，都可以对数据字典中的信息进行查询、插入、删除和修改；

作为设计的工具——由于数据字典中存放着与数据库有关的各种信息和原始资料，就为数据库设计提供了有力的工具；

为数据库提供存取控制和管理——数据库在接受每一个对数据库的存取请求时，都要检查用户标识、口令、子模式、模式和物理模式等。所以从某种意义上讲，数据字典控制了数据库的运行；

供数据库管理员(DBA)进行各种查询——以便了解系统性能、空间使用状况和各种统计信息，及时掌握数据库的动态。所以数据字典是 DBA 观察数据库的眼晴和窗口。

数据字典（Data Dictionary）是关系型数据库的核心组件之一，在不同的关系型数据库中，数据字典的结构和存储方式有所不同，这里我们仅以Oracle数据库为例，详细讲解一下Oracle数据库数据字典的结构和使用。

Oracle 数据字典的结构

我们先来看看Oracle数据字典的结构（图1）：

图1 Oracle数据库数据字典的结构

如上图所示，Oracle数据字典包括四个层次：X$内部表，动态性能视图，基础数据字典表，静态数据字典视图。

其中，X$内部表属于Oracle数据库的核心部分，这些表用于跟踪数据库内部信息，不允许SYSDBA之外用户直接访问。在数据库启动时，Oracle应用程序会动态创建X$表，比如我们熟知的X$BH、X$K*SP等。

基础数据字典表才是真正用于存储表、列、索引、约束以及其它数据库结构信息的表，也不能直接被普通用户访问。在创建数据库时，会自动运行$ORACLE_HOME/rdbms/ admin/sql.bsq脚本创建这些基础数据字典表，而当用户创建新表时，会自动向这些基础数据字典表中插入数据。

正如前面所说，X$内部表和基础数据字典表都不能被普通用户直接访问，那么用户想要查看这些表中的信息该怎么办呢？所以，Oracle数据库还为用户提供了动态性能视图和静态数据字典视图这两个部分，它们分别是基于X$内部表和基础数据字典表创建的，其中静态数据字典视图包括user_xxx、all_xxx、dba_xxx三类，在创建数据库时由$ORACLE_HOME/rdbms/admin/catagory.sql脚本创建。user_xxx存储了关于当前用户所拥有的对象的信息，即所有在该用户模式下的对象；all_xxx存储了当前用户能够访问的对象的信息，与user_xxx相比，all_xxx并不需要拥有该对象，只需要具有访问该对象的权限即可；dba_xxx存储了数据库中所有对象的信息，前提是当前用户具有访问这些数据库的权限，一般来说必须具有管理员权限。下面举几个例子：

例1-1：查询该用户拥有哪些表，并查看这些表的表名，表空间名，簇名等信息

例1-2：查询该用户拥有哪些索引

例1-3：查询当前库的所有数据表

动态性能视图包括GV$和V$视图，这里需要说明的一点是，Oracle数据库对GV$和V$视图的访问做了限制，它也不允许普通用户直接访问，而是基于GV$和V$分别引入了GV_$和V_$视图，随后为GV_$和V_$视图建立了与GV$和V$视图同名的共用同义词，所以大部分用户访问的其实是GV_$和V_$视图的同义词，举例如下：

例2-1：查询最频繁执行的sql

例2-2：查看回滚段的争用情况

Oracle RDBMS架构

我们再来看一看Oracle RDBMS的架构图（如图2），进一步讨论一下数据字典在Oracle数据库的架构中所处的位置和所起的作用。

图2 Oracle RDBMS架构图

如上图所示，Oracle RDBMS架构主要包括User Process、Server Process等的Client端，Instance实例，Databases以及一些参数文件，密码文件和归档日志文件。

在Oracle数据库中，其实用户并不能直接访问到数据库文件，而是需要先创建一个数据库实例。数据库实例指的就是操作系统中一系列的进程以及为这些进程所分配的内存块，用更通俗的方式解释，Oracle数据库实例就是我们访问Oracle数据库文件的通道，有关Oracle数据库和Oracle数据库实例的区别，建议感兴趣的朋友们再自行了解。

如图2所示，一个数据库实例包括Shared Pool（共享池），Data Buffer Cache（数据库缓冲区缓存），Redo Log Buffer（重做日志缓冲区）等部分，其中Shared Pool（共享池）又包括Library Cache（库缓存），Data Dictionary Cache（数据字典缓存）。当用户访问数据库文件时，需要先启动一个数据库实例，然后将数据库文件加载到Data Buffer Cache，将数据字典加载到Data DictionaryCache，之后Server Process会首先访问Data Dictionary Cache，获取到有关数据库表的字段，关键字等元数据信息，然后再访问Data Buffer Cache，读取相关数据。

从上述过程中，可以看到在Oracle数据库中，数据字典不仅是管理和查询元数据的工具，还是用户访问数据库文件的基础。

大数据这个概念近几年被炒得很热，大数据技术涉及面很广，包括数据采集、数据存储、基础架构、数据处理、统计分析、数据挖掘、模型预测和结果呈现等。

回到数据字典的主题，大数据平台是如何做元数据的管理的呢？以Hadoop Hive为例，Hive里有一个Metastore概念，即元数据存储。基于Hive发展起来的大数据平台比如Cloudera、MapR、Hortonworks等，也都沿用了Hive的Metastore来做元数据的管理和存储。但是Metastore中的元数据组织凌乱，格式也不统一，如果权限设置很高，一般用户也很难访问，这对于开发人员来说，使用起来可谓痛苦不堪。因此，对各个大数据平台来说，增加一个类似于关系型数据库中的数据字典的组件是很有必要的。就目前而言，星环科技的TDH（Transwarp Data Hub）在4.6版本已经增加了数据字典组件，这里我们就来看看它是怎么做的。

我们先来看一下TDH 4.6中Inceptor的架构图（如图3）：

图3 Transwarp Inceptor的架构图

上图所示，Inceptor 4.6的架构包括了Connector，Batch & Interactive SQL Engine，Guardian，Distributed Execution Engine，StarGate，HDFS，Holodesk等组件。DataDictionary是构建在SQL接口层中的一个组件，是用于管理和查询元数据信息的工具。和关系数据库不同的是，它不再是用户访问数据文件的基础组件。

目前，在Inceptor 4.6的数据字典中，包括databases_v、columns_v、database_privileges _v 等提供不同种元信息的字典表，这些字典表实则是一系列根据元数据构建的视图，全部以“_v”结尾命名。和关系型数据库数据字典一样，用户也可以使用SQL语句对其进行查询。通过查询字典表，用户能够获取到数据库表、列、视图、权限，存储过程，包，当前TDH版本号等元数据信息，下面举几个例子以示其用法：

例3-1：利用DESC查看databases_v的结构

例3-2：查看databases_v中的全部内容

想要进一步了解TDH数据字典使用方法的读者，可以查看星环科技的数据字典使用手册，该手册提供于星环科技的官方论坛(http://support.transwarp.cn/)。

这里还需要说明的一点是，Inceptor 4.6将数据字典设计成了一个可插拔的组件，也就是说，用户可以根据自己的需要安装、升级、卸载数据字典，这一设计出于人性化使用考虑。而且虽然它是在TDH 4.6版本中推出的，但是对4.3和4.5版本也支持，具体请参阅Transwarp Inceptor数据字典手册。

总的来说，无论是传统的关系型数据库，还是各种大数据平台，对用户而言，对元数据信息进行管理和查询，是一件非常有必要的事。虽然目前并不是所有的大数据平台都配备了数据字典功能，即使是TDH在字典内容的丰富性上也有待提高，但是相信在不久的将来，数据字典会陆陆续续成为各个大数据平台的标配，毕竟如何方便用户使用产品，才是最重要的。