FAQ‐zh

1. Data-Juicer是用来干嘛的？

Data-Juicer是一套针对LLM的开源的、一站式的、灵活可扩展的数据处理系统，旨在为LLM提供更高质量的数据，从data的视角提高LLM的最终性能。它最基本的功能为编辑、清洗过滤数据以及数据去重，并为此提供了丰富的数据处理算子。在此基础上，Data-Juicer还提供了大量的数据处理和优化的菜谱，方便大家直接复用。

2. 如何安装Data-Juicer？

可参考安装文档进行安装。

3. 如何快速使用Data-Juicer？

可参考快速开始文档进行初步使用。

4. 我在哪里可以找到Data-Juicer提供的数据处理菜谱？

数据处理菜谱即数据处理配置文件，可以在configs目录下找到Data-Juicer复现和优化的各种数据处理菜谱。

5. 配置文件看起来参数很多，怎么去整体、系统、详细地了解其中的参数含义？

一方面，您可以在configs/config_all.yaml文件中找到所有配置参数的列表以及其对应的含义。另一方面，对于某个算子（Operator, OP）来说，您可以在API Reference文档中或者对应OP的源码中找到详细的注释文档。

处理配置相关

1. 如何使用多进程并行处理？

Data-Juicer支持多进程并行处理，进程数目可以由参数np控制。

2. 处理结束后，结果数据集会存放在什么地方？

结果数据集的导出位置由参数export_path控制。同时，该文件路径所在的目录会被当做数据处理过程中的工作目录。

3. 导出处理后的数据集时，支持哪些格式？

目前支持三种格式：[jsonl, json, parquet]。前两者虽然后缀名会不同，但实际上都是jsonl格式。导出格式可以通过在配置文件中修改export_path的后缀名修改。

4. 如何将处理后的数据导出为若干个子文件？

可以通过指定export_shard_size参数来实现，该参数表示导出为若干个子文件时，每个子文件的最大大小限制，以字节byte为单位。该参数默认为0，表示只导出为单个文件。如果将其设置大于0的数值，则会导出 $N$ 个子文件，每个子文件大小不超过export_shard_size个字节。 $N$ 由以下方式计算得到：

$N=\lfloor S/export_shard_size\rfloor + 1$

其中， $S$ 为结果数据集的字节数目。

此外，如果将参数export_in_parallel设置为true可在导出为多个子文件的时候开启并行导出，该参数默认为false。

5. cache是什么？什么场景下需要使用cache？

Data-Juicer的cache系统基于datasets库的cache系统建立，并优化了cache指纹的计算。当cache开启后，读取数据集、改变数据集内容、过滤数据集中的样本等步骤发生后，中间数据集都会在硬盘空间中存放一份cache。当我们仅改变某个算子的参数，需要重复处理某个数据集时，不会有变化的操作步骤就不会再进行处理，而是会直接载入之前存放好的cache，从而达到避免重复计算的速度优化效果。

默认情况下，Data-Juicer的cache系统是开启的。用户也可以通过use_cache参数来控制cache的开启与关闭。由于cache系统会向硬盘写入大量cache文件，所以当该参数为true、待处理的数据集非常大且要处理的OP数目特别多时，可能会快速消耗硬盘空间。因此这里用户需要做一个可用硬盘空间与重复处理数据集花费时间之间的一个平衡与抉择，以此选择是否开启cache系统。

6. 如何修改处理过程中数据集cache文件的存放地址？

可以修改ds_cache_dir参数来指定数据集cache文件的存放地址，这个参数默认为None，此时会使用datasets库的默认cache地址~/.cache/huggingface/datasets�。

您也可以通过环境变量HF_DATASETS_CACHE来修改cache存放地址，但是在Data-Juicer中，ds_cache_dir参数的优先级要高于这个环境变量，因此如果您手动指定了该参数，则会优先使用该参数的目录来存放cache文件，否则使用环境变量的目录来存放。

7. checkpoint是什么？什么场景下需要使用checkpoint？

Data-Juicer的checkpoint系统为本框架特有系统，目的为一定程度上补足cache系统硬盘空间消耗过快的缺点。数据集的checkpoint本质上也是处理过程中某个时刻数据集的cache文件，但与cache不同，当开启checkpoint系统时，只有在处理过程中某个OP失败时才会主动将上一个OP产出的数据集的checkpoint文件写到硬盘。而在需要重复处理同一个数据集时，如果checkpoint前的OP配置都未发生改变，就会直接载入checkpoint，并从失败位置处的OP继续进行处理；如果之前的OP配置发生了改变，则会尝试从头重新进行处理。

默认情况下，Data-Juicer的checkpoint系统是关闭的。用户可以通过use_checkpoint参数来控制checkpoint系统的开启与关闭。当checkpoint开启后，每个OP计算时的临时cache文件将会写到一个temp目录下，默认写到tempfile.tempdir下，可通过temp_dir参数进行修改。checkpoint文件默认会存放到工作目录下。

如果您的硬盘空间预估后已不足以存放所有的cache文件，可以考虑开启checkpoint系统。此外需要注意的是，checkpoint系统与cache系统是互斥的，如果checkpoint系统开启，则会强制关闭cache系统。

8. cache压缩是什么？什么场景下需要使用cache压缩？

Data-Juicer的cache压缩系统为本框架特有系统，目的为一定程度上补足cache系统硬盘空间消耗过快的缺点。它可以利用目前在速度和压缩率上都比较优秀的几种压缩算法及时对产生的cache进行压缩，以此达到节省硬盘空间占用的目的。而在重复处理需要再次使用到某一份cache的时候，又会及时地进行解压。

默认情况下，Data-Juicer的cache压缩系统是关闭的。用户可以通过cache_compress参数来控制cache压缩系统的需要使用的压缩算法，目前支持[gzip, zstd, lz4]三种算法，默认为null表示系统关闭。当cache压缩系统开启后，每个OP后会将后续无用的cache压缩，并删除掉原cache文件。需要再次使用时，再进行解压。由于解压缩过程需要消耗额外的时间，所以用户需要根据硬盘空间使用和处理时间这两个方面的情况进行权衡与抉择。

9. tracer是什么？什么场景下需要使用tracer？

Data-Juicer的tracer系统为本框架特有系统，其主要功能为追踪每个OP对数据集做出的改变。对于Mapper算子，它可以追踪Mapper对其做出编辑的样本示例；对于Filter算子，它可以追踪到那些被过滤掉的样本示例；对于Deduplicator算子，它可以追踪到那些被认为是重复的样本对示例。

默认情况下，Data-Juicer的tracer系统是关闭的。用户可以通过open_tracer参数来控制tracer系统的开启与关闭。当tracer系统开启时，tracer记录会被存放在工作目录下的trace目录中。tracer系统追踪的过程可能会消耗额外的处理时间，因此用户可以通过两个参数来适当调节其耗时多少：一方面，用户可以使用op_list_to_trace参数来控制tracer只对特定的几个OP追踪，该参数默认为空列表，表示对所有处理OP进行追踪；另一方面，用户可以使用trace_num参数控制对于单个OP，tracer最多追踪的样本示例数目，当已经收集到足够的样本时，tracer系统可以提前停止该OP的追踪过程。

10. OP融合是什么？什么场景下需要使用OP融合？

Data-Juicer的OP融合系统为本框架特有系统，其主要功能为将若干计算过程中有相同中间变量的OP合并为一个OP，这些中间变量只需要计算一次即可，可以一定程度上加快处理速度并节省内存占用。具体的OP融合过程可参考我们的论文。

默认情况下，Data-Juicer的OP融合系统是关闭的。用户可以通过op_fusion参数来控制OP融合系统的开启与关闭。需要注意的是，OP融合系统目前尚处于实验性阶段，其暂时无法与checkpoint系统同时工作。

11. Data-Juicer支持哪些处理方式？可以支持分布式处理吗？

Data-Juicer目前支持单机处理和分布式处理，可以由executor_type参数控制，设置为“default”时为单机处理模式，设置为“ray”则可以支持基于Ray的分布式处理。

由于目前Data-Juicer的分布式处理能力尚处于实验阶段，因此它暂时只能支持Mapper和Filter类算子。