HashData 的湖仓一体思考：非结构化数据支持（Directory Table 等）讲解及演示

随着 LLM 基座的不断成熟和生态的不断完善，越来越多的企业开始在自身业务场景的应用探索，以实现降本增效。然而，在这一过程中，企业不得不面对两种 AI 应用形态的选择：

• 一种应用方式是基于大模型微调。这种方式需要将预先训练好的基座大模型，结合场景语料进行微调，从而获得具备行业知识的垂类模型应用。微调过程是精细而复杂的工作，不仅需要在保证语料质量的基础上进行梳理编排，而且还需要定期针对更新的语料重新进行模型微调训练。只有这样，微调后模型才会有更好的性能和泛化能力，从而提供更加准确和高效的推理结果。

• 另一种应用方式是通过 RAG（检索增强生成）方式，在大模型基础上建立行业知识库。这种方式可以弥补大模型在特定行业知识方面的不足。知识库的建设同样需要精心准备和规范化的管理，确保知识的正确性和规范性。只有这样，大模型进行检索时才能获得准确、相关的知识提示，从而引导大模型生成更符合需求的答案。

无论是基于微调还是 RAG 方式的 AI 应用，企业都需要建立完善的语料数据管理系统，为大模型微调训练提供高质量的语料输入，为 RAG 提供高质量知识库支持。由此，催生了企业对非结构化多模态语料数据管理的迫切诉求。

非结构化数据管理流程及技术挑战

然而，非结构化多模态语料数据不仅类型多样，而且体量巨大，给传统的数据处理方式带来了前所未有的挑战。

非结构化多模态语料数据管理流程大致可以分为以下 5 大流程：

• 数据收集：这是整个流程的起点，涉及从各种来源获取数据。这些数据可能来自网络、第三方电子书库、企业内部数据库、外部购买的知识库、同行业分享的文件等。这些数据格式各异，包括文本、图像、音频、视频等。

• 数据纳管：收集到的数据需要被统一管理，并建立一个清晰的资产目录，以确保数据的可访问性和可维护性。随着模型训练的不断迭代，语料数据会不断增加，因此需要一个统一的维度来管理这些数据，以确保其质量和精选性。

• 文档解析：对收集到的文档进行解析，提取出关键信息，这些信息将被整合成一个标准格式的文档，便于后续处理和分析。

• 数据清洗：清洗过程旨在去除原始语料中的噪声和无关信息，包括去重、处理空格、非法字符、URL 替换、语言类型检测以及敏感数据的过滤等，以确保数据的唯一性和准确性。

• 数据质量评估：在将清洗后的语料用于模型训练之前，需要对其进行质量评估。这可以从人工审查和量化评估指标两个维度进行。只有当数据在各个指标上表现良好时，才能被用于模型训练。

在整个管理流程中可以看出，非结构化多模态数据涵盖了各种格式和类型，如文本、图像、音频、视频等等，而且要处理的数据体量庞大，处理过程也十分复杂。企业已有的数据仓库或大数据平台在处理如此大规模的复杂数据时显得力不从心，独立建设又会带来不小的采购与维护成本。

HashData 湖仓一体思考

在这样的背景下，HashData 湖仓一体架构提出了新的思考。

如上图所示，HashData 湖仓一体架构主要由两大引擎组成：一是用于提供分析能力的 HashData SQL 数据库引擎，二是具备深度学习和机器学习能力 HashML/DL 算法引擎。这两大引擎共享一套数据湖对象存储 OSS 层，这个数据层可以实现结构化数据和非结构化数据的统一存储管理。

在这个架构基础上，HashData 引入了一种新的表类型——Directory Table。这是一种目录表，专门用于存储非结构化数据的信息。可以理解为，非结构化数据的实际内容存储在对象存储 OSS 层中，如文本、图片、视频等文件，而每个文件的元数据则存储在 Directory Table 中，这样我们就能够通过目录表的方式对非结构化数据进行统一纳管。

然而，仅仅将非结构化数据纳管进来并不够，我们还需要对其进行清洗、解析和加工，以生成高质量的训练语料。为了实现这一目标，HashData SQL 数据库引擎整合了多种外部引擎插件，包括向量引擎、机器/深度学习引擎 HashML 和文档引擎等等。

向量引擎：在大模型的应用方式中，RAG 知识增强方式便充分利用了向量库。因此，在清洗完目录表中的非结构化文档数据后，我们可以直接将其导入向量引擎，为 AI 应用提供丰富的知识库支持。

• HashML 机器/深度学习引擎：具备多种强大的算法模型，能够迅速解析非结构化文档，并执行语料的清洗工作。

• 文档引擎：针对文档内容关键词检索的需求，我们集成了 ZomboDB 引擎，将索引数据存储在其中。同时，具体的文档数据则存储在 elasticsearch 平台上。这样，用户只需采用简单的 SQL 语言就能使用文档引擎基于关键词轻松检索文档内容。检索结果可进一步用于机器学习算法处理，从而丰富非结构化数据处理能力。

Directory Table 定位

在深入探讨 Directory Table 的定位之前，我们首先需要理解它在整个 HashData SQL 数据库引擎架构中的角色和与其他组件的关系。

在 HashData SQL 数据库引擎中，原本包含 Table 普通表，属于记录表。这种记录表的实际数据是以行/列或者行列混合的方式作为数据文件存储在对象存储 OSS 层中。数据文件与 Table 普通表之间是 cache 关系，也就是一对一的关系。这种存储方式确保了数据的一致性和高效访问。然而，随着非结构化数据的快速增长，我们需要一种新的方法来有效管理和分析这些数据。这就是 Directory Table 的用武之地。

与普通表不同，Directory Table 被设计为存储和管理非结构化数据对象的元数据。这些元数据以结构化的形式存在，与非结构化数据文件本身形成关联关系，而非一一对应的 cache 关系。这种设计使得我们能够用结构化的方式来描述和查询非结构化数据，从而提高了数据管理的灵活性和效率。

在实现上，HashData SQL 数据库引擎在 SQL 层面进行了统一，让用户可以使用熟悉的 SQL 语句来操作 Directory Table 和 Table 普通表。无论是创建表、导入数据、导出数据还是执行查询，都可以通过 SQL 语句来完成。这种统一的操作方式降低了用户的学习成本，同时提高了系统的易用性。

Directory Table 的定位是存储、管理和分析非结构化数据对象。Table 普通表则是针对结构化的数据。Directory Table 与 Table 普通表共同构成了多模态数据管理能力，使得我们能够更加高效地处理各种类型的数据。

Directory Table 最佳实践

如何使用这个 Directory Table 表呢？我们以视频的方给大家介绍下 Directory Table 的最佳实践方式。

其中，需要重点介绍 Directory Table 的表定义、表数据导入和表数据查询三个部分：

🚩Directory Table 使用：表定义

Directory Table 定义了一个表结构，用于存储非结构化数据文件的元数据信息，包含以下字段：

• RELATIVE_PATH：路径字段，具有唯一性。在数据导入时生成，可以作为数据的唯一标识符使用。通过这个字段，我们可以大致了解语料的来源；

• SIZE：表示语料数据的大小；

• LAST_MODIFIED：记录语料数据的最后修改时间；

• MD5：生成一个唯一的 MD5 码，用于校验。当语料数据重复加载时，通过 MD5 码进行校验，确保数据的准确性；

• TAGS：标签字段，当面对海量语料数据时，通常通过标签来管理和检索数据。标签支持 KV（键值对）方式存储，上传时可以自定义；

• SCOPED_FILE_URL：隐藏字段，用于内部处理。

针对这个表结构定义，我们在 HashData SQL 数据库引擎中构建对应的存储空间。由于语料数据存储在对象存储 OSS 上，我们在创建存储空间（表空间）时，会将其关联到对象存储上。有了这个表空间之后，我们就可以创建目录表，并将存储的对象数据默认放置在对象存储的表空间上。

创建目录表的方式与使用普通表的方式相似，我们依然可以使用 SQL 语句来创建。以下是创建目录表的方法：首先创建一个自定义表空间，并指定其位置和服务器：

CREATE TableSPACE <Tablespace_name>         LOCATION '<对象存储OSS Tablespace_path>'         WITH ( [SERVER = <server_name>] );

然后在自定义表空间中创建目录表：

CREATE DIRECTORY Table <Table_name>         TableSPACE <Tablespace_name>;

这样，我们就成功创建了一个用于存储非结构化数据文件的元数据信息的目录表，并将其数据对象文件存储在 HashData 对象存储 OSS 中。

🚩Directory Table 使用：表数据导入

Directory Table 支持从本地导入数据，用户可以将文件从本地路径导入至表中。此外，系统支持使用 Wildcard 进行批量上传，大大提高了导入效率。为保持数据文件的组织结构一致，我们推荐使用子目录功能，确保上传后的目录路径与本地一致，便于后续管理。

导入数据的 SQL 语句如下：

\COPY <directory_Table_name>[/<path>] FROM <local_path_to_file>/<file_name>;-- filename: Wildcard characters (*, ?) are supported to enable uploading multiple files in a directory

除了本地导入，我们还提供了专门的导入工具 dataX，它支持通过 JDBC、ODBC 接口将表数据导入至 Directory Table，为用户提供了更多的选择和灵活性。

🚩Directory Table 使用：表数据查询（支持关键词检索）

数据导入后，用户可以使用 SQL 语句对 Directory Table 进行查询和检索。通过查询，用户可以获取文件的相对路径、大小、最后修改时间、MD5 码标签等信息。

在查询之前，需要使用我们数据库提供的目录表函数。此函数接收目录表的表名作为参数，并自动读取表中的数据，解析为各个字段，并以字段的形式展示给用户。因此，用户可以使用 SQL 语句来查询这张表。

以下是查询 Directory Table 表内语料数据对象元数据的 SQL 示例：

-- 使用 Table function directory_Table() 读取文件元数据及内容  SELECT relative_path,         size,         last_modified,         md5,         tags  FROM directory_Table('<dir_Table_name>');

通过执行上述 SQL 语句，用户可以检索出所需的语料数据对象元数据，为后续的算法训练和使用提供数据支持。

语料管理方案介绍及 demo 演示

接下来，我们来给大家简单讲解下基于 Directory Table 特性的语料管理技术方案及 demo 演示。该技术方案旨在为客户提供一个高效、灵活的语料处理平台，核心在于利用 Directory Table 的特性，实现对各种格式的文档、图片等原始语料的统一存储、处理与管理。

以上图为例，首先，原始语料数据（如文档、pdf/docx/html 等文件，图片如 jpeg/png 等格式，以及视频和音频文件如 rav4/mp4 等）通过 Copy 工具或 dataX 工具，被导入到 HashData 数据库的 Directory Table 中。Directory Table 能够自动为这些语料数据建立元数据，使得用户可以方便地查看和管理表中存储的数据。随后，在 HashML 引擎中，采用 Python 脚本进行文档解析、清洗和特征化 embedding 等处理。处理完成后，结果数据会被回写到 HashData SQL 数据库引擎中。标准化的结构文档数据会被写入到特定的 Table 表中，该表包含从文档中提取的关键字段以及文档内容大字段。同时，一部分数据还会被写入到向量库或文档库中，以便后续使用。当大模型需要进行训练或推理时，它可以从这些结果表中筛选所需的数据，并将其导出生成文件，供大模型使用。整个过程中，我们建议使用 SQL 程序进行开发，因为 SQL 语言简单易懂，降低了入门门槛。此外，算法引擎中的 Python 脚本程序可以通过函数形式直接集成到 SQL 程序中，实现两者的无缝对接。

结语

面对 AI 应用带来的非结构化数据管理挑战，HashData 湖仓一体架构通过引入 Directory Table 这一新技术特性，为结构化和非结构化数据提供了统一的管理平台。结合 HashML 的并行处理能力，能够有效降低用户使用门槛，让更多的开发者能够轻松地处理和加工非结构化数据，让用户更加便捷地探索 AI 应用场景与价值。相关方案已经在大型央企集团开展共创落地，欢迎感兴趣的朋友们与我们联络交流。