初识大数据，一文掌握大数据必备知识文集(10)-Toy模板网

这篇具有很好参考价值的文章主要介绍了初识大数据，一文掌握大数据必备知识文集(10)。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

初识大数据，一文掌握大数据必备知识文集(10),大数据专栏,大数据,java,开发语言

🏆作者简介，普修罗双战士，一直追求不断学习和成长，在技术的道路上持续探索和实践。
🏆多年互联网行业从业经验，历任核心研发工程师，项目技术负责人。
🎉欢迎 👍点赞✍评论⭐收藏

🔎 大数据领域知识 🔎

链接	专栏
大数据专业知识学习一	大数据专栏
大数据专业知识学习二	大数据专栏
大数据专业知识学习三	大数据专栏
大数据专业知识学习四	大数据专栏
大数据专业知识学习五	大数据专栏
大数据专业知识学习六	大数据专栏
大数据专业知识学习七	大数据专栏
大数据专业知识学习八	大数据专栏
大数据专业知识学习九	大数据专栏
大数据专业知识学习十	大数据专栏
大数据专业知识学习十一	大数据专栏
大数据专业知识学习十二	大数据专栏
大数据专业知识学习十三	大数据专栏
大数据专业知识学习十四	大数据专栏
大数据专业知识学习十五	大数据专栏

🏆初识大数据应用知识

🔎一、初识大数据应用知识(10)

🍁 01、简答说一下hadoop的map-reduce编程模型？

Hadoop的MapReduce编程模型是一种用于并行处理大规模数据集的编程模型。它通过将计算过程分为两个阶段（Map和Reduce）来实现数据的分布式处理和计算。下面是对Hadoop的MapReduce编程模型的简要概述：

Map阶段：
- 输入：Map阶段的输入是一组键值对（key-value pairs）。
- 处理：用户需要自定义一个Map函数，该函数接收输入键值对并产生一组中间键值对（intermediate key-value pairs）作为输出。
- 部署：Map任务会自动分发到Hadoop集群的各个节点上执行，每个节点独立处理一部分输入数据。
Shuffle阶段：
- 排序：在Map阶段完成后，所有中间键值对首先会按照键（key）进行排序和分组，以便相同键的键值对被发送到同一个Reduce节点上。这个过程称为Shuffle。
- 分组：相同键的键值对通过网络发送到同一个Reduce节点。
Reduce阶段：
- 输入：Reduce阶段的输入是分组后的中间键值对，其中相同键的键值对被划分为一组。
- 处理：用户需要自定义一个Reduce函数，该函数接收分组后的键值对作为输入，并生成最终的输出结果。
- 部署：Reduce任务会自动分发到Hadoop集群的各个节点上执行。
输出：
- Reduce阶段输出的结果会被汇总，并存储在指定的位置。

Hadoop的MapReduce编程模型提供了一个框架，使用户能够以并行和分布式的方式处理大规模数据集。它将数据处理任务分解为独立的Map任务和Reduce任务，并自动处理数据的分区、排序和通信。这种分布式计算模型使得能够在大规模集群上实现高性能和可扩展的数据处理任务。

🍁 02、MR程序运行的时候会有什么比较常见的问题？

MR程序运行时可能会遇到以下常见问题：

输入输出路径不存在：MR程序需要指定输入和输出路径，但这些路径如果在HDFS上不存在，则会导致程序运行失败。这通常是由于路径拼写错误、权限不足或者输入数据文件被删除等原因导致的。
数据格式错误：MR程序需要解析输入数据，如果数据格式不正确，则会导致解析失败或运行错误。这通常是由于输入数据不符合预期的格式或结构、字段分隔符错误等输入格式问题导致的。
内存不足：MR程序在执行过程中需要加载和处理大量数据，如果内存不足，则会导致程序崩溃或者性能下降。这通常是由于数据量太大、程序逻辑有误或者数据处理方式不合理等原因导致的。
计算资源不足：MR程序需要占用一定的计算资源，包括CPU、内存和IO等方面，如果这些资源不足，则会导致程序运行缓慢或失败。这通常是由于资源分配不合理、其他用户占用了系统资源或者集群负载过大等原因导致的。
Hadoop版本兼容性问题：如果程序使用的Hadoop版本与集群上运行的版本不兼容，则会导致程序无法运行或者出现异常情况。这通常是由于程序使用过时的Hadoop API或者依赖，或者集群更新版本不及时等原因导致的。

为了避免这些问题，在编写MR程序之前，需要仔细检查输入输出路径、数据格式、计算资源、Hadoop版本等方面的问题，并进行合理的设置和优化。此外，在程序执行过程中及时查看日志和系统监控信息，可以帮助及时发现和解决潜在的问题。

🍁 03、Hive能像关系型数据库那样建多个库吗？

是的，Hive可以像关系型数据库一样建立多个库（database）。Hive使用数据库（Database）的概念来组织和管理数据表，每个数据库可以包含多个数据表。

在Hive中，可以使用以下语句来创建和管理数据库：

1. 创建数据库：

CREATE DATABASE database_name;

2. 切换到指定数据库：

USE database_name;

3. 查看当前所有数据库：

SHOW DATABASES;

4. 查看指定数据库的所有表：

SHOW TABLES;

5. 删除数据库：

DROP DATABASE database_name;

通过使用以上命令，可以在Hive中创建多个数据库，并在每个数据库中创建和管理不同的数据表。这样可以将不同类型或不同目的的数据进行逻辑上的分组和隔离，以方便数据管理和查询。类似于关系型数据库，Hive的数据库（Database）提供了一种逻辑上的命名空间，用于组织和分类数据表。

🍁 04、请列出你所知道的Hadoop调度器，并简要说明其工作方法？

下面是一些常见的Hadoop调度器及其工作方法的简要说明：

FIFO调度器（First-In, First-Out）：
- 工作方法：FIFO调度器按提交任务的顺序依次进行调度，每次只执行一个任务，直到任务完成。不考虑任务的优先级、资源需求或其他因素，简单粗暴地进行调度。
- 适用场景：适用于低负载、低优先级的任务场景，不适合复杂的并发或资源管理需求。
容量调度器（Capacity Scheduler）：
- 工作方法：容量调度器将资源划分为多个容量（capacity），每个容量分配给一个或多个队列。每个队列可以设置自己的资源配额和优先级。容量调度器根据队列的配置和资源配额来决定任务的调度。
- 适用场景：适用于多用户、多队列、带有多个资源需求的复杂任务调度场景，可以根据不同队列的需求来灵活分配资源。
公平调度器（Fair Scheduler）：
- 工作方法：公平调度器根据任务的优先级和资源需求进行调度，尽量保证各个任务的公平共享。任务被划分到多个调度池（scheduling pool），并根据每个调度池的资源配额和优先级来进行调度。
- 适用场景：适用于多用户、多队列、动态资源分配的任务调度场景，可以根据任务的优先级和资源需求在不同调度池中进行公平的调度。
其他调度器：
- 除了上述常见的调度器外，还有一些其他的Hadoop调度器，如CapacityScheduler和FairScheduler的结合调度器（CapacityFairScheduler）等。这些调度器可以根据实际需求进行配置和定制，满足更复杂的任务调度和资源管理需求。

这些调度器都是Hadoop集群上常见的调度策略，根据不同的需求和场景选择合适的调度器可以提高任务的执行效率、资源利用率和系统的整体性能。

🍁 05、请描述如何解决Hbase中region太小和region太大带来的结果？

HBase中，region太小和region太大都会带来一些问题，但解决方法不太一样。下面是如何解决这两个问题的一些建议：

解决region太小的问题：
- 合并小的region：使用HBase的merge_region命令合并大小相对较小的region，可以减少region的数量，提高读取效率。可以根据实际情况设置合适的合并策略和阈值。
- 调整split策略：通过设置HBase的split策略，可以控制region的大小。可以根据数据量、预期负载和硬件资源情况等，选择合适的split策略，使得region的大小在一个合理的范围内。
解决region太大的问题：
- 增加region数量：当region太大时，可以增加HBase表的region数量，将大的region分割为更小的region。可以通过调整HBase的region拆分策略和配置参数，使得新创建的region更小。
- 调整region预分区策略：通过预定义HBase表的region分配策略，可以控制region的分布和大小。可以根据数据分布的特点和负载情况，选择合适的预分区策略，使得region的大小均匀且适合负载均衡。

无论是解决region太小还是太大的问题，在操作之前，建议先进行备份和测试，确保数据的安全和可靠性。此外，还应该根据实际情况进行性能监控和调优，以获得最佳的HBase性能和效率。

🍁 06、Spark任务执行流程？

Spark任务的执行流程如下：

创建SparkContext：Spark应用程序首先会创建一个SparkContext对象，它是Spark应用程序与Spark集群的连接器，用于管理与集群的通信，并执行相关的任务调度和资源分配。
提交任务：通过SparkContext提交需要执行的任务，任务可以是各种不同的操作，如数据加载、转换、计算等。
DAG生成：Spark会根据任务的依赖关系生成一个有向无环图（DAG，Directed Acyclic Graph），即执行计划。DAG描述了任务之间的依赖关系，可以通过转换操作或持久化操作对数据流进行优化。
任务调度：Spark将DAG划分为多个阶段（Stage），每个阶段包含一组可以并行执行的任务，这些任务不需要通过Shuffle（数据重分布）操作进行通信。Spark通过任务调度器将任务分配给集群中的执行器（Executor）进行并行执行。
任务划分与分配：对于需要进行Shuffle操作的阶段，Spark将数据划分为若干个分区，并将它们分别分配给不同的任务执行器进行处理。
任务执行：每个任务执行器根据指定的计算逻辑对分配到的数据分区进行处理。执行过程中，将根据需要对数据进行缓存、持久化、间隙填充等优化操作。
结果返回：执行器处理完任务后，会将结果返回给SparkContext。对于需要返回结果的操作，如collect或count等，SparkContext会将结果汇总到驱动程序上。
回收资源：任务执行完成后，SparkContext会自动回收使用的资源，并对结果进行整理。

需要注意的是，Spark的执行流程是根据任务的依赖关系动态生成的，Spark会根据任务的依赖和优化策略对任务进行调度和执行，以最大化并行计算的能力，提高任务的执行效率和性能。

🍁 07、怎么设置RDD cache？

在Spark中，可以使用cache()方法来设置RDD的缓存。cache()方法是RDD的一个转换操作，用于将RDD的数据缓存在内存中，以便在后续的操作中重复使用，提高计算性能。

以下是设置RDD缓存的示例代码：

# 创建一个RDD
rdd = sc.parallelize([1, 2, 3, 4, 5])

# 设置RDD缓存，将数据缓存在内存中
rdd.cache()

# 或者可以将cache()方法与其他转换操作链式调用
rdd = sc.parallelize([1, 2, 3, 4, 5]).cache()

需要注意的是，设置RDD缓存后，并非立即将数据缓存到内存中，而是在首次对RDD进行行动操作（如count()、collect()等）时才会触发真正的缓存操作。在首次行动操作之前，RDD的每个分区都是按需计算的（即在需要使用数据时才会计算），而非立即缓存。

如果希望在设置RDD缓存时立即将数据缓存到内存中，可以使用rdd.count()等行动操作来触发缓存。

此外，还可以使用unpersist()方法来清除RDD的缓存，释放内存资源。示例如下：

# 清除RDD缓存
rdd.unpersist()

当RDD的数据不再需要被重复使用时，及时清除缓存可以释放内存，避免占用过多的资源。

注：以上示例代码是基于PySpark编写的，使用其他Spark编程语言（如Scala）时，设置RDD缓存的方法和语法略有不同，但基本思路是一致的。

🍁 08、你们数据库如何导入hive的出现什么错误？

我们数据库如何导入Hive取决于具体的数据库和Hive版本，以及所用的工具和方法。一般来说，可以使用以下几种常见的方式来导入数据到Hive：

1. 使用Apache Hive的INSERT语句：在Hive中，可以使用INSERT语句从其他数据源（如数据库、文件系统等）导入数据。通过编写相应的INSERT语句，将数据导入到Hive表中。

2. 使用Hive的LOAD DATA命令：Hive提供了LOAD DATA命令，可以从本地文件系统或HDFS导入数据到Hive表中。语法如下：

LOAD DATA [LOCAL] INPATH 'filepath' [OVERWRITE] INTO TABLE tablename [PARTITION (partcol1=val1, partcol2=val2 ...)]

3. 使用Sqoop工具：Sqoop是一种用于将关系型数据库中的数据导入到Hadoop生态系统（包括Hive）的工具。可以使用Sqoop的命令行或者API接口，指定源数据库、目标Hive表和相关的映射配置，执行导入操作。

以上是常见的导入数据到Hive的方式，可能的错误情况及其解决方法有以下几种：

权限问题：确保执行导入操作的用户具有足够的权限，包括对源数据和Hive表的访问权限，以及导入数据所需的Hive操作权限。
数据格式不匹配：如果数据的格式与目标表定义的格式不匹配，可能出现解析或类型转换错误。请确保源数据和表定义的数据类型、分隔符等一致。
数据量过大：如果导入的数据量过大，可能导致内存不足或者过长的执行时间。可以根据具体情况增加集群资源或者进行分批导入。
数据源连接错误：如果无法连接到数据源，可能是由于网络、配置或凭证等问题导致。请检查配置文件、网络连接和凭证信息是否正确。

如果在具体操作中出现错误，建议查看错误的详细信息和日志，根据具体的错误信息来定位和解决问题。

🍁 09、hadoop 的 namenode 宕机怎么解决？

如果Hadoop的NameNode宕机，这会导致整个HDFS不可用。解决这个问题主要涉及到恢复NameNode以及恢复HDFS的元数据。下面是一些常见的解决方法：

启动备用NameNode：Hadoop提供了NameNode的高可用性解决方案，即通过配置一个备用的NameNode来实现冗余和故障转移。如果在集群中配置了备用NameNode，可以尝试启动备用NameNode来代替主NameNode，使整个HDFS能够继续提供服务。
使用元数据备份：在Hadoop中，可以定期进行HDFS元数据的备份，这些元数据包括文件和目录的信息、权限、块的分配等。如果有备份，可以使用备份的元数据来恢复NameNode。
核查fsimage和edits文件：NameNode在运行过程中会生成fsimage和edits文件，它们包含了HDFS的元数据。在NameNode宕机后，可以检查这些文件的状态，验证它们是否完整或损坏。如果文件完整，可以尝试将它们加载到新启动的NameNode中，从而恢复元数据。
使用Secondary NameNode：如果有Secondary NameNode配置，可以使用它来恢复NameNode。Secondary NameNode通常定期合并fsimage和edits文件，并生成新的fsimage文件。可以将这个新生成的fsimage文件复制到新的NameNode中，然后启动新的NameNode，从而恢复HDFS。
寻求专业支持：如果以上方法无法解决问题，可以寻求Hadoop专家或技术支持团队的帮助。他们可以根据具体情况提供进一步的诊断和解决方案。

需要注意的是，在处理NameNode宕机问题时，安全起见，务必确保对HDFS元数据进行备份，并在恢复过程中谨慎操作，以免进一步导致数据丢失或不一致。尽量在测试环境中进行恢复操作，确保恢复过程可行和可靠，以最大程度地保护数据的完整性。

🍁 10、在Shuffle阶段，你是怎么理解的？

在Spark中，Shuffle是指在RDD之间重新分配数据、重新组合和重组数据的过程。Shuffle是Spark中性能开销最大的操作之一，因为它涉及到网络I/O和磁盘操作。Shuffle通常发生在Spark的转换操作（如groupByKey、reduceByKey等）中，它通常包括以下几个步骤：

Map阶段：首先，在每个Executor上对输入的数据执行Map函数，将数据转换为Key-Value pairs，并按Key进行分组（相同Key的数据被分配到同一个Reducer任务上）。
Shuffle阶段：然后，将分组后的数据序列化为磁盘上的文件（称为Map输出文件），并根据Key的哈希值将它们分散到不同的节点上。
Sort阶段：在分发到不同的节点之后，Shuffle数据的Key被进行排序，以便它们能更有效地分配到Reducer上。排序后的文件被存放在Reducer节点的磁盘上。
Reduce阶段：最后，Reducer从磁盘上读取Shuffle输出文件，并将数据进行聚合、计算和转换。Reducer将其输出写入HDFS或Spark的其他数据源。

由于Shuffle操作需要进行磁盘和网络I/O，因此通常是Spark应用程序性能瓶颈的一个关键因素。为了优化Spark作业的性能，可以采取一些策略，例如：

1. 减少Shuffle数据量：通过适当的数据过滤、转换和合并操作，可以减少Shuffle操作的数据量。

2. 调整分区数量：根据集群的资源情况和作业的特点，适当地调整Shuffle操作的分区数量，以平衡计算和I/O负载，并提高并行度。

3. 使用合适的硬件或存储策略：可以使用高效的网络、内存和存储系统，如SSD、快速网络等，以加快Shuffle的速度和吞吐量。

总之，Shuffle是Spark中的一个重要过程，也是性能优化的关键点之一。对于处理海量数据的Spark应用程序，如何高效地处理Shuffle操作是保障其性能和稳定性的重要因素。

🍁 11、数据导入Hive的方式？

在Hive中，可以使用以下几种方式将数据导入到表中：

1. Load Data： 使用LOAD DATA INPATH指令可以将本地文件或HDFS文件中的数据导入到Hive表中。例如：

LOAD DATA INPATH '/path/to/data' INTO TABLE table_name;

2. INSERT语句： 可以使用INSERT INTO语句将数据插入到表中。例如：

INSERT INTO TABLE table_name VALUES (value1, value2, …), (value1, value2, …), …;

3. External Table： Hive中的外部表不会在加载数据时将数据复制到Hive数据仓库中，而是在外部存储系统中存储实际数据。可以通过修改外部存储系统中的数据来插入、更新和删除数据。例如：

CREATE EXTERNAL TABLE table_name (col1 data_type, col2 data_type, …) LOCATION '/path/to/data';

4. Hadoop HDFS命令： 可以使用hadoop fs shell命令将数据复制到HDFS中，然后在Hive中创建表并指向HDFS中的数据。例如：

hadoop fs -put /path/to/data /user/hive/warehouse/table_name

使用以上任意一种方式导入数据到Hive表中都是可行的，具体选择哪种方式取决于数据来源、数据格式、数据量等因素。通常情况下，使用LOAD DATA和INSERT INTO语句在应用程序中较为常见和方便，而外部表和HDFS命令则更适用于某些特定情况下的数据管理和处理需求。

🍁 12、如何从SU转到Cloudera？

从SU（Supervisor）转移到Cloudera通常涉及以下几个步骤：

评估需求：首先，您需要评估您当前的环境和需求，以确定是否需要迁移到Cloudera。Cloudera提供了一套全面的数据管理和处理工具，包括Hadoop、Spark、Hive、Impala等，您需要确保Cloudera的功能和特性满足您的需求。
规划迁移策略：一旦确定迁移到Cloudera，您需要规划迁移策略。这可能涉及选择合适的Cloudera版本、确定集群规模和硬件要求，以及考虑数据迁移、兼容性等问题。
数据迁移：将数据从SU迁移到Cloudera可能涉及数据的复制、格式转换和加载等操作。您可以使用工具如Sqoop、Flume等将数据从SU导出，并使用相应的工具或脚本将数据导入Cloudera中的对应组件，如Hive、HBase等。
应用程序迁移：如果您有在SU上运行的应用程序，您需要迁移和调整它们以适应Cloudera环境。这可能包括修改配置文件、重新编译和调整应用程序逻辑等。
测试和验证：在完成迁移后，您需要进行测试和验证以确保数据和应用程序在Cloudera上正常运行。您可以通过运行一些测试作业、验证数据一致性等方式来确认迁移的成功。
培训和支持：对于使用新的Cloudera环境的团队成员，您可能需要提供培训，使他们熟悉Cloudera的工具和技术。此外，Cloudera提供有关产品使用和故障排除的技术支持。

请注意，从SU到Cloudera的迁移可能涉及复杂的任务和细节，具体的步骤和策略可能需要根据您的环境和需求进行调整。建议在进行迁移前，仔细计划和准备，并在迁移过程中密切关注数据的一致性和应用程序的稳定性。

🍁 13、数据库OLAP OLTP的介绍和比较？

OLAP（联机分析处理）和OLTP（联机事务处理）是两种常用的数据库处理模式，它们具有不同的特点和用途。

OLTP（Online Transaction Processing）是用于处理实时交易和查询的数据库处理模式。它主要用于支持业务应用程序的日常操作，如订单处理、账户管理等。OLTP数据库通常需要快速地执行读写操作并确保数据的一致性和事务完整性。OLTP系统通常具有以下特点：

高并发性：OLTP系统需要支持大量同时操作的用户，并提供快速的响应时间。
低延迟： OLTP系统需要快速地执行交易和查询操作，通常需要进行索引优化、事务管理等。
小事务：每个事务通常只操作少量的数据，保证了数据的完整性和一致性。

OLAP（Online Analytical Processing）是用于分析和报表查询的数据库处理模式。它主要用于支持商业智能、数据挖掘和决策支持等应用。OLAP数据库通常存储大量历史数据，并支持复杂的多维分析查询。OLAP系统通常具有以下特点：

复杂查询：OLAP系统支持复杂的多维查询，如汇总、切片、钻取等，以支持决策分析和报表生成。
高性能读取：OLAP数据库通常针对查询进行优化，并支持高性能的读取操作。
大数据量：OLAP系统通常存储大量历史数据，并具有合理的数据模型和结构，以支持高效的数据分析。

OLTP和OLAP之间的比较主要体现在以下方面：

数据模型：OLTP通常使用关系型数据库，采用规范化的数据模型；而OLAP系统则常常使用多维数据模型，如星型模型或雪花模型。
事务特性：OLTP系统需要支持强一致性和事务管理，而OLAP系统则更关注数据的可靠性和查询性能，不侧重于事务处理。
数据操作：OLTP系统执行频繁的读写操作，而OLAP系统更注重数据查询和分析操作。
数据量：OLTP系统通常处理实时的交易数据，数据量相对较小；而OLAP系统通常处理大规模的历史数据，数据量较大。

综上所述，OLTP用于处理实时交易和查询，强调数据的一致性和事务处理；而OLAP则用于分析和报表查询，强调多维分析和查询性能。两者在数据模型、事务特性、数据操作和数据量等方面存在差异，根据具体的业务需求选择合适的数据库处理模式。

🍁 14、Flink的四大基石都有哪些？

Flink的四大基石是：

1. 事件时间（Event Time）：Flink支持基于事件时间的处理，即根据事件生成的时间戳进行处理。事件时间是基于事件发生的实际时间，而不是基于处理事件的时间。通过事件时间，Flink能够在处理有序和无序事件的场景下，有效处理延迟、乱序和窗口计算等问题。

2. 状态后端（State Backends）：Flink的状态后端负责存储应用程序的状态信息。这些状态可以是中间结果、窗口计算状态、用户定义的状态等。Flink提供了多种状态后端的选择，如内存状态后端、文件系统状态后端和分布式键值存储状态后端，可以根据应用程序的需求选择合适的状态后端。

3. exactly-once语义（Exactly-once Processing Semantics）：Flink提供了精确一次处理语义，确保在发生故障或重启情况下，数据被准确处理一次，避免数据丢失或重复处理。通过检查点机制和事务日志，Flink能够实现精确一次处理语义，保证数据的可靠性。

4. 分布式数据流处理（Distributed Dataflow Processing）：Flink采用了分布式数据流处理模型，将应用程序表示为数据流的形式，并提供了丰富的操作符和窗口函数来处理数据流。Flink利用流处理的优势，如低延迟、高吞吐量、动态扩缩容等，适用于处理连续流数据和无限数据集。

这四个基石使得Flink成为一个强大而灵活的流式数据处理引擎，可以应对各种复杂的数据处理场景，并提供高效、稳定和准确的处理结果。

🍁 15、搜索引擎会通过日志文件把用户每次检索使用的所有检索串都记录下来，每个查询串的长度为1-255字节？

以下是用Java和Python语言实现搜索引擎日志文件处理的逻辑示例：

Java实现逻辑：

import java.io.BufferedWriter;
import java.io.FileWriter;
import java.io.IOException;

public class SearchEngineLogger {
    public static void logQuery(String query) {
        try {
            // 打开日志文件
            BufferedWriter writer = new BufferedWriter(new FileWriter("search_engine.log", true));
            
            // 写入查询串到日志文件
            writer.write(query);
            writer.newLine();
            
            // 关闭日志文件
            writer.close();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
    
    public static void main(String[] args) {
        String queryString = "example query";
        logQuery(queryString);
    }
}

Python实现逻辑：

def log_query(query):
    try:
        # 打开日志文件
        with open("search_engine.log", "a") as file:
            # 写入查询串到日志文件
            file.write(query + "\n")
    except IOError:
        print("Error writing to log file")

# 示例用法
query_string = "example query"
log_query(query_string)