Resume processing system and method for recruitment platform

Abstract

The invention discloses a resume processing system and method for a recruitment platform. The system comprises a Web management console used for providing a visual interface for managing a resume processing task; the trigger is used for initiating a resume processing request to the scheduler when a preset triggering condition is met; the scheduler is used for dividing the resume data set into a plurality of resume data fragments, generating a plurality of resume processing tasks containing the resume data fragments and resume processing logic, and marking a recommendation actuator type for each resume processing task; the message queue is used for storing a plurality of resume processing tasks; each actuator is used for calling a resume processing task of the target recommended actuator type from the message queue; the resume processing logic in the resume processing task is converted into a resume processing instruction locally operated by the actuator; and processing the resume data fragments in the resume processing task based on the resume processing instruction. According to the method, the resume data can be quickly updated, and the operation and maintenance complexity is reduced.

Description

Technical Field

[0001] This application relates to the field of recruitment technology, and in particular to a resume processing system and method for recruitment platforms. Background Technology

[0002] The core competitiveness of recruitment platforms lies in the quality and real-time nature of resume data. Currently, the industry standard for resume data management is to configure distributed scheduled tasks (such as Crontab) on a backend server cluster to periodically execute batch scripts to update resume status.

[0003] Specifically, traditional solutions typically employ fixed and infrequent batch processing cycles (e.g., once a day), making it difficult for the system to promptly detect and respond to the latest user activity, such as logging in or updating a resume. Core functions like recommendation engines and talent search can only rely on outdated data, resulting in a significant drop in accuracy and severely impacting the user experience.

[0004] Secondly, batch processing scripts in traditional solutions typically run during off-peak hours (such as early morning), which instantly consumes a large amount of database connections and computing resources, interfering with other concurrent background tasks (such as report generation). During peak hours, the system struggles to utilize idle resources for data processing. Furthermore, resume data processing scripts and scheduled tasks are often distributed across dozens or even hundreds of heterogeneous servers, making configuration, updates, and monitoring cumbersome. Moreover, the script logic is hard-coded, making it difficult to adaptively adjust to the characteristics of different resumes (such as the job seeker's industry and years of experience) or the performance differences of different servers. Summary of the Invention

[0005] In view of this, embodiments of this application provide a resume processing system and method for a recruitment platform to solve at least one of the above-mentioned technical problems.

[0006] In a first aspect, embodiments of this application provide a resume processing system for a recruitment platform, including a web management console, triggers, a scheduler, a message queue, and multiple executors: the web management console provides a visual interface for managing resume processing tasks; the trigger initiates a resume processing request to the scheduler when a preset trigger condition is detected, the resume processing request including the identifiers of each resume data in the resume data set to be processed; the scheduler obtains the resume data set according to the identifiers; divides the resume data set into multiple resume data slices and generates multiple resume processing tasks containing at least one resume data slice and resume processing logic; and labels each resume processing task with a recommended executor type according to the device information of the multiple executors; the message queue receives and stores the multiple resume processing tasks; each executor retrieves a resume processing task of the recommended executor type corresponding to its own device information from the message queue; converts the resume processing logic in the resume processing task into resume processing instructions that run locally on the executor; and processes the resume data slices in the resume processing task based on the resume processing instructions.

[0007] According to some embodiments of this application, optionally, the multiple actuators are heterogeneous actuators, with at least some of the actuators having different hardware configurations, operating system types, and / or software operating environments; wherein, the preset triggering conditions include at least one of the following: reaching a preset time period; detecting a business event related to the resume; detecting that the CPU idle rate and / or memory idle rate of at least one actuator exceeds a preset threshold.

[0008] According to some embodiments of this application, optionally, the scheduler is specifically used to divide the resume data set into multiple resume data shards based on the job seeker's activity level, resume submission time, job seeker's location, or industry category in the resume data; wherein, multiple resume data of the same activity level, the same submission time range, the same region, or the same industry category are divided into the same resume data shard.

[0009] According to some embodiments of this application, optionally, each executor is provided with an environment adapter and an execution engine; the environment adapter is used to select the corresponding target instruction mapping rule from a preset instruction mapping rule set according to the local operating system type, and map the resume processing logic described in a declarative language or general interface in the resume processing task into resume processing instructions to be executed in the local command line or script interpreter according to the target instruction mapping rule; the execution engine is used to perform at least one of the following processes on the resume data in the resume data shards based on the resume processing instructions: cleaning, standardizing and extracting information from the resume data; evaluating the activity of the resume data; scoring the quality of the resume data; calculating the matching degree between the resume data and the job; and updating the feature representation of the resume data in the recommendation system.

[0010] Optionally, according to some embodiments of this application, the activity assessment of resume data includes: obtaining behavioral data of the job seeker to whom the resume data belongs, the behavioral data including at least one of the job seeker's login frequency on the recruitment platform, historical activity level, number of job views, number of resume submissions, and number of communications with recruiting companies; calling a preset user activity analysis model to calculate the job seeker's activity score based on the job seeker's behavioral data; assigning activity status tags to the resume data according to the activity score, the activity status tags including at least one of high activity status, moderate activity status, low activity status, and pending cleanup status; and setting the display priority of the resume data in the platform's recommendation list or search results according to the activity status tags.

[0011] According to some embodiments of this application, optionally, the scheduler is specifically used to perform the following processes: analyze the resume data sharding and resume processing logic in the resume processing task, and determine the data processing feature category of the resume data sharding; obtain the device performance information of each executor by querying the executor registry; and, based on the matching relationship between the data processing feature category of the resume data sharding and the device performance information, label the resume processing task with recommended executor types.

[0012] According to some embodiments of this application, optionally, the resume data sharding and resume processing logic in the resume processing task are analyzed to determine the data processing feature category of the resume data sharding, including: obtaining the attribute information of the resume data sharding and the configuration information of the resume processing logic; estimating the computational complexity and data access score of the resume data sharding based on the attribute information and configuration information; if the computational complexity is greater than a preset complexity threshold, the data processing feature category is determined to be computationally intensive; if the data access score is greater than a preset access threshold, the data processing feature category is determined to be input-output intensive; if the computational complexity is less than or equal to a preset complexity threshold and the data access score is less than or equal to a preset access threshold, the data processing feature category is determined to be balanced or conventional.

[0013] According to some embodiments of this application, optionally, the device performance information includes a computational performance score and a storage input / output performance score; based on the matching relationship between the data processing feature categories of resume data fragments and the device performance tags, a recommended executor type is labeled for the resume processing task, including: if the data processing feature category is computationally intensive, then from the executor registry, executors with computational performance scores greater than a first performance threshold are selected, and the recommended executor type of the resume processing task is labeled with the type corresponding to the selected executor; if the data processing feature category is input / output intensive, then from the executor registry, executors with storage input / output performance scores greater than a second performance threshold are selected, and the recommended executor type of the resume processing task is labeled with the type corresponding to the selected executor; if the data processing feature category is balanced or normal, then executors with current load less than a load threshold are selected, and the recommended executor type of the resume processing task is labeled with the type corresponding to the selected executor.

[0014] According to some embodiments of this application, optionally, the visual interface of the Web management console includes: a task configuration and publishing component for receiving user input, including setting the trigger conditions for resume processing tasks, the range of resume data to be processed, and the resume processing logic to be executed; a heterogeneous resource monitoring view component for displaying at least one of the following in group or list form: device type, current load status, health, and task processing queue of multiple executors; a task end-to-end tracking component for displaying the processing progress of any resume processing task and supporting querying detailed execution logs of each stage in the resume processing process; and a result statistics and reporting component for aggregating and analyzing the results of completed resume processing tasks and displaying at least one of the following in chart form: resume distribution trend, task execution efficiency index, and system resource consumption report.

[0015] Secondly, embodiments of this application provide a resume processing method for a recruitment platform. This method is implemented based on a resume processing system for a recruitment platform as described in any embodiment of the first aspect. The method includes: providing a visual interface for managing resume processing tasks; initiating a resume processing request to a scheduler when a preset trigger condition is detected, the resume processing request including identifiers of various resume data in a set of resume data to be processed; and performing the following operations through the scheduler: obtaining the resume data set based on the identifiers; dividing the resume data set into multiple resume data fragments; generating multiple resume processing tasks, each resume processing task containing at least one resume data fragment and resume processing logic; marking a recommended executor type for each resume processing task based on the device information of multiple executors; sending the multiple resume processing tasks to a message queue; and performing the following operations through each executor: retrieving a resume processing task of the recommended executor type corresponding to its own device information from the message queue; converting the resume processing logic in the retrieved resume processing task into resume processing instructions that run locally on the executor; and processing the resume data fragments in the resume processing task based on the resume processing instructions.

[0016] The resume processing system and method for recruitment platforms, as described in this application, transforms the previously decentralized operation and maintenance (O&M) of distributing tasks across multiple servers and manually writing and configuring Crontab scripts into centralized management through a unified web management console. The visual interface provided by the web management console allows users to manage resume processing tasks uniformly, changing the cumbersome configuration, update, and monitoring issues caused by the traditional approach of distributing processing scripts and scheduled tasks across multiple servers. This reduces O&M complexity, enables rapid resume data updates, and ultimately improves the accuracy of talent recommendation and job matching. Furthermore, the decoupled design of the "scheduler-message queue-executor" achieves physical and logical separation between task scheduling and task execution. The scheduler divides the resume data set into multiple resume data shards, generating tasks that include the resume data shards and processing logic. Resume data shards facilitate parallel processing, reducing the processing pressure on individual executors. Combined with the operation of tagging and recommending executor types, tasks can be accurately allocated based on data characteristics and executor performance, fully leveraging the advantages of each executor and further improving processing efficiency. The executor retrieves resume processing tasks of the recommended executor type corresponding to its own device information on demand, which helps reduce resource waste and achieve system load balancing. Furthermore, if any executor fails, its unfinished resume processing tasks can be retained in the message queue and automatically taken over by other healthy executors of the same type. Faced with sudden surges in resume processing demands, simply adding executor nodes horizontally can linearly increase the overall system processing capacity without modifying the core scheduling logic, achieving rapid and elastic resource response. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings of the embodiments of this application will be briefly described below.

[0018] Figure 1 This is a structural block diagram of a resume processing system for a recruitment platform provided in an embodiment of this application.

[0019] Figure 2 This is a diagram illustrating several components in the visual interface of a web management console.

[0020] Figure 3 This is a schematic diagram of a process for evaluating the activity of resume data in an embodiment of this application.

[0021] Figure 4 This is a schematic diagram of a process in which the scheduler in this application identifies recommended executor types for resume processing tasks.

[0022] Figure 5 This is a schematic flowchart of a resume processing method for a recruitment platform provided in an embodiment of this application. Detailed Implementation

[0023] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0024] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes said element.

[0025] It should be understood that the term "and / or" used in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0026] Various modifications and variations can be made to this application without departing from its spirit or scope, which will be apparent to those skilled in the art. Therefore, this application is intended to cover modifications and variations falling within the scope of the corresponding claims (the claimed technical solutions) and their equivalents. It should be noted that the implementation methods provided in the embodiments of this application can be combined with each other without contradiction.

[0027] Before describing the technical solutions provided in the embodiments of this application, in order to facilitate understanding of the embodiments of this application, this application first specifically explains the problems existing in the related technologies: The core competitiveness of recruitment platforms lies in the quality and real-time nature of resume data. Currently, the industry standard for resume data management is to configure distributed scheduled tasks (such as Crontab) on a backend server cluster to periodically execute batch scripts to update resume status.

[0028] Specifically, traditional solutions typically employ fixed and infrequent batch processing cycles (e.g., once a day), making it difficult for the system to promptly detect and respond to the latest user activity, such as logging in or updating a resume. Core functions like recommendation engines and talent search can only rely on outdated data, resulting in a significant drop in accuracy and severely impacting the user experience.

[0029] Secondly, batch processing scripts in traditional solutions typically run during off-peak hours (such as early morning), which instantly consumes a large amount of database connections and computing resources, interfering with other concurrent background tasks (such as report generation). During peak hours, the system struggles to utilize idle resources for data processing. Furthermore, resume data processing scripts and scheduled tasks are often distributed across dozens or even hundreds of heterogeneous servers, making configuration, updates, and monitoring cumbersome. Moreover, the script logic is hard-coded, making it difficult to adaptively adjust to the characteristics of different resumes (such as the job seeker's industry and years of experience) or the performance differences of different servers.

[0030] To address at least one of the aforementioned technical problems, this application provides a resume processing system and method for recruitment platforms. Centralized management via a web management console reduces operational complexity. A decoupled design of scheduler-message queue-executor enables reasonable allocation and parallel processing of resume processing tasks, improving resume processing efficiency and resource utilization. Furthermore, it possesses fault tolerance and elastic scaling capabilities, enhancing overall system performance.

[0031] The resume processing system for recruitment platforms provided in this application embodiment will be introduced below.

[0032] Figure 1 This is a structural block diagram of a resume processing system for a recruitment platform provided in an embodiment of this application. Figure 1 As shown in the embodiments of this application, the resume processing system 10 for a recruitment platform may include a web management console 101, a trigger 102, a scheduler 103, a message queue 104, and multiple executors 105.

[0033] The Web Management Console 101 provides a visual interface for managing resume processing tasks. In traditional recruitment platforms, processing scripts and scheduled tasks are scattered across multiple servers, making configuration, updates, and monitoring cumbersome. However, the Web Management Console 101 offers a unified visual interface for managing resume processing tasks, allowing users (such as administrators) to easily manage these tasks, such as setting task parameters and viewing task status, thus reducing operational complexity.

[0034] Trigger 102 can be used to initiate a resume processing request to the scheduler when a preset trigger condition is detected. For example, trigger 102 can be a rule-based event monitoring module that can monitor at least one preset trigger condition in the recruitment platform in real time. For instance, when a new resume is uploaded, a job seeker updates their resume information, or a recruiting company posts a new job opening, trigger 102 can identify these events as meeting the preset trigger condition. Once the condition is detected, trigger 102 can initiate a resume processing request to scheduler 103. This request may include identifiers for each resume in the set of resumes to be processed. For example, the identifiers for the resumes may include a unique resume number, a job seeker ID, etc.

[0035] The scheduler (Beat) 103 can be used to obtain a set of resume data based on the identifier of the resume data sent by the trigger 102; divide the set of resume data into multiple resume data fragments and generate multiple resume processing tasks containing at least one resume data fragment and resume processing logic; and mark a recommended executor type for each resume processing task based on the device information of multiple executors.

[0036] Specifically, the scheduler 103 can be decoupled from the executor 105. The scheduler 103 is only responsible for obtaining the resume data set according to the resume data identifier provided by the trigger 102, reasonably dividing it into multiple resume data fragments, generating a task containing resume data fragments and processing logic, and recommending executor types for the task based on the device information of the executor 105. It does not care which executor 105 will ultimately execute the specific resume processing task, nor does it participate in the actual processing of the resume data fragments by the executor 105.

[0037] After receiving the identifier of the resume data sent by the trigger 102, the scheduler 103 can retrieve the corresponding resume data set from the recruitment platform's database based on the identifier. Then, the scheduler 103 can divide the resume data set into multiple resume data slices based on a preset data slice algorithm. For example, in some examples, slices can be made according to dimensions such as resume submission time, job seeker's location, or job type. Next, the scheduler 103 can generate a resume processing task containing at least one resume data slice and corresponding resume processing logic. Simultaneously, the scheduler 103 can assign a recommended executor type to each resume processing task based on the device information of multiple executors 105, such as CPU performance, memory size, and network bandwidth, so that subsequent executors can accurately obtain tasks suitable for their processing.

[0038] The message queue 104 can be used to receive multiple resume processing tasks generated by the scheduler 103, and store and sort the multiple resume processing tasks according to preset rules to prevent task loss or duplicate processing.

[0039] Multiple executors (Workers) 105 can be computing nodes distributed across different servers. Each executor 105 has its own device information, such as CPU model, number of cores, memory capacity, network bandwidth, and / or disk I / O speed. Executors 105 are only responsible for retrieving suitable tasks from the message queue and processing the resumed data according to the processing logic in the task, without needing to concern themselves with the task scheduling process or the operation of other executors.

[0040] Specifically, each executor 105 can retrieve a resume processing task of the recommended executor type corresponding to its own device information from the message queue 104. After obtaining the resume processing task, the executor 105 can convert the resume processing logic in the resume processing task into resume processing instructions that run locally on the executor, such as compiling the processing logic into executable code. Next, the executor 105 can process the resume data slices in the resume processing task based on the resume processing instructions, such as performing operations such as filtering, matching, and / or sorting resumes.

[0041] The resume processing system for recruitment platforms provided in this application, on the one hand, transforms the previously decentralized operation and maintenance (O&M) of distributing tasks across various servers and manually writing and configuring Crontab scripts into centralized management through a unified web management console. The visual interface provided by the web management console allows users to manage resume processing tasks uniformly, changing the cumbersome configuration, update, and monitoring issues caused by the traditional approach of distributing processing scripts and scheduled tasks across multiple servers. This reduces O&M complexity, enables rapid resume data updates, and thus helps improve the accuracy of talent recommendation and job matching. On the other hand, through a decoupled design of "scheduler-message queue-executor," the physical separation and logical decoupling of task scheduling and task execution are achieved. The scheduler divides the resume data set into multiple resume data shards, generating tasks containing resume data shards and processing logic. Resume data shards facilitate parallel processing, reducing the processing pressure on individual executors. Combined with the operation of tagging and recommending executor types, tasks can be accurately allocated based on data characteristics and executor performance, fully leveraging the advantages of each executor and further improving processing efficiency. The actuator retrieves resume processing tasks of the recommended actuator type corresponding to its own equipment information on demand, which helps to reduce resource waste and achieve system load balancing.

[0042] Furthermore, through the decoupled design of "scheduler-message queue-executor," if any executor fails, its unfinished resume processing tasks can be retained in the message queue and automatically taken over by other healthy executors of the same type. Faced with sudden surges in resume processing demands, simply adding executor nodes horizontally can linearly increase the overall system processing capacity without modifying the core scheduling logic, achieving rapid and elastic resource response.

[0043] The following describes the resume processing system for recruitment platforms provided in this application, using specific embodiments as examples.

[0044] Figure 2 This is a diagram illustrating several components within the visual interface of a web management console. For example... Figure 2 As shown, according to some embodiments of this application, optionally, the visual interface of the Web management console may include a task configuration and publishing component 201, a heterogeneous resource monitoring view component 202, a task end-to-end tracing component 203, and a result statistics and reporting component 204.

[0045] The task configuration and publishing component 201 can be used to receive user input, which may include setting the trigger conditions for the resume processing task, the range of resume data to be processed, and the resume processing logic to be executed.

[0046] In some embodiments, the task configuration and publishing component 201 allows users to set various parameters of the resume processing task according to their actual needs. For example, users can input and set trigger conditions for the resume processing task, such as setting the time for resume processing, or setting the task to be triggered when the number of resumes reaches a preset threshold. The preset threshold can be input by the user or set by default. In some examples, the task configuration and publishing component 201 can also allow users to specify the range of resume data to be processed, such as selecting resumes within a target time period, resumes for a target position, or resumes from a target region. In some examples, the task configuration and publishing component 201 can also allow users to set the resume processing logic to be executed, such as filtering resumes that meet the target education and work experience requirements, or performing keyword matching on the resumes. Through the task configuration and publishing component 201, users can flexibly customize resume processing tasks to meet different recruitment needs.

[0047] The heterogeneous resource monitoring view component 202 can be used to display at least one of the following in group or list form: device type, current load status, health, and task processing queue of multiple actuators.

[0048] In some embodiments, the heterogeneous resource monitoring view component 202 can display at least one of the following information for multiple actuators in a grouped or list format: device type, current load status, health status, and task processing queue. The heterogeneous resource monitoring view component 202 allows users to easily understand the current load of each actuator, determine whether an actuator is operating under high load, and adjust task allocation in a timely manner. Simultaneously, health information helps users detect actuator malfunctions or anomalies, and task processing queue information allows users to understand task backlog, thereby better managing system resources.

[0049] The task end-to-end tracking component 203 can be used to display the processing progress of any resume processing task and supports querying detailed execution logs for each stage of the resume processing process.

[0050] In some embodiments, the task end-to-end tracing component 203 can display the processing progress of any resume processing task, allowing users to easily see which stage the resume processing task is at—whether it is being processed, completed, or has encountered an error. In some specific examples, the task end-to-end tracing component 203 can also support users in querying detailed execution logs for each stage of the resume processing process. For example, when a resume processing task encounters an anomaly, users can query the execution logs to understand which processing step went wrong—whether it was a data reading error, a processing logic error, or some other problem—thereby facilitating quick location and resolution of the issue.

[0051] The results statistics and reporting component 204 can be used to aggregate and analyze the results of completed resume processing tasks, and display at least one of the following in the form of charts: resume distribution trend, task execution efficiency indicators, and system resource consumption reports.

[0052] In some embodiments, the results statistics and reporting component 204 can be used to aggregate and analyze the results of completed resume processing tasks and display the results in chart form. For example, in some examples, the results statistics and reporting component 204 can display trends in resume distribution, such as changes in the number of resumes submitted for different positions within different time periods, and the distribution of resumes in different regions, thereby helping users understand the dynamics of the recruitment market. In some examples, the results statistics and reporting component 204 can display task execution efficiency indicators, such as the average processing time of the task and the processing efficiency of each executor, helping users understand the performance of the system and executors in a timely manner. In some examples, the results statistics and reporting component 204 can display system resource consumption reports, such as information on executor CPU usage, memory usage, and network bandwidth consumption.

[0053] According to some embodiments of this application, optionally, the multiple actuators can be heterogeneous actuators. That is, at least some of the actuators have different hardware configurations, operating system types, and / or software operating environments.

[0054] Specifically, different executors can be configured according to specific task requirements and resource availability. For example, some executors can utilize high-performance multi-core CPU servers equipped with large-capacity memory and high-speed storage devices, running a Linux operating system, and can install dedicated software environments for data processing and analysis. This makes them suitable for handling large-scale, complex resume data, enabling rapid data filtering, matching, and sorting operations. Other executors can be ordinary servers with relatively lower hardware configurations, running a Windows operating system, and can install lightweight data processing tools for handling simple resume data tasks, such as preliminary data organization and format conversion. Optionally, some executors can be cloud-based virtual servers with flexible resource allocation and elastic scaling capabilities, running cloud operating systems and software environments. These can dynamically adjust resources according to real-time business needs, handling peak and off-peak periods in resume processing tasks.

[0055] The Web Management Console 101 provides unified management of these heterogeneous executors. For example, it allows users to view detailed configuration information, current load status, health, and task processing queues for each executor on a visual interface. Remote maintenance operations can also be performed on the executors within the Web Management Console 101, such as restarting executors, cleaning disk space, and updating software, ensuring stable operation. Furthermore, the Web Management Console 101 can dynamically adjust the resources of each executor based on real-time business needs. For instance, when the workload of resume processing tasks increases, the Web Management Console 101 can request more computing resources, memory, and storage capacity from the cloud platform; when the workload decreases, it releases excess resources to reduce costs. Simultaneously, the Web Management Console 101 can coordinate resources between different types of executors to achieve optimal resource allocation.

[0056] According to some embodiments of this application, optionally, the preset triggering conditions may include at least one of the following: reaching a preset time period; detecting a business event related to the resume; detecting that the CPU idle rate and / or memory idle rate of at least one actuator exceeds a preset threshold.

[0057] In some specific examples, a fixed time period can be set to trigger resume processing tasks, such as every 10 minutes, 30 minutes, or 1 hour. For instance, every 30 minutes, the trigger sends a resume processing request to the scheduler to process resume data from the most recent 30 minutes. The size of the preset time period can be flexibly adjusted according to actual needs, and this application does not limit it in this regard.

[0058] In some specific examples, triggers can be used to monitor resume-related business events. When a target business event related to resumes is detected, a resume processing request is automatically sent to the scheduler, triggering a resume processing task. For example, when a sudden 20% increase in the platform's overall user login rate within 10 minutes or a large number of newly posted jobs are detected, a resume processing task is immediately triggered, improving the response speed of recruitment.

[0059] In some specific examples, triggers can be used to monitor the CPU idle rate and / or memory idle rate of individual executors. When the CPU idle rate and / or memory idle rate of at least one executor exceeds a preset threshold, it indicates that some executors have sufficient resources available. At this point, triggering a task to complete the task fully utilizes idle resources and improves the overall performance of the system.

[0060] According to some embodiments of this application, optionally, the scheduler 103 can be used to divide the resume data set into multiple resume data shards based on the job seeker's activity level, resume submission time, job seeker's location, or industry category in the resume data. Specifically, multiple resumes with the same activity level, the same submission time range, the same region, or the same industry category are grouped into the same resume data shard.

[0061] For example, in some examples, scheduler 103 can group the resume data of job seekers with the same activity level into the same resume data shard based on their activity level. For instance, highly active job seekers frequently update their resumes and actively apply for jobs; processing the resumes of highly active job seekers in a centralized manner helps recruiting companies quickly screen out potential high-quality candidates.

[0062] For example, in other examples, scheduler 103 may also divide the resume data set into multiple resume data shards according to the resume submission time, the job seeker's location, or the industry category in the resume data. This application does not limit the division of multiple resume data within the same submission time range, the same region, or the same industry category into the same resume data shard.

[0063] In this way, by grouping resume data with similar characteristics into the same data shard, the executor can utilize system resources more efficiently when processing resumes. For example, for resumes with the same activity level, the executor can use the same screening strategy and processing logic, reducing the overhead of frequently switching processing methods and thus improving the overall processing speed.

[0064] According to some embodiments of this application, optionally, each actuator 104 is provided with an environment adapter and an execution engine.

[0065] An environment adapter can be used to select the corresponding target instruction mapping rule from a preset instruction mapping rule set based on the local operating system type; and based on the target instruction mapping rule, map the resume processing logic described in a declarative language or a general interface in the resume processing task into resume processing instructions that are executed in the local command line or script interpreter.

[0066] Specifically, different operating systems (such as Windows, Linux, and macOS) differ in how they use command lines and script interpreters. For example, Windows typically uses batch scripts and PowerShell for system operations, while Linux primarily uses shell scripts, and although macOS is based on a Unix kernel, it also has its own unique command-line operation habits.

[0067] When executor 104 receives a resume processing task, the environment adapter can identify the type of the local operating system. Once the operating system type is determined, the environment adapter can search for a target instruction mapping rule that matches the operating system type in a pre-defined instruction mapping rule set. This instruction mapping rule set can include the correspondence between logic described in various declarative languages ​​or generic interfaces under different operating systems and local command-line or script interpreter instructions. Next, based on the target instruction mapping rule, the environment adapter can convert the resume processing logic described in declarative languages ​​(such as filtering logic described in SQL statements) or generic interfaces in the resume processing task into resume processing instructions that can be executed in the local command-line or script interpreter. For example, taking the resume processing logic as calling the v2.3 version of the user activity analysis model as an example, on a Linux operating system, it can be converted to "execute / usr / local / models / v2.3 / predict.py", and on a Windows operating system, it can be converted to "call PowerShell script Analyze-Resume.ps1-Version2.3".

[0068] The execution engine can be used to perform at least one of the following processes on resume data in resume data shards based on resume processing instructions: cleaning, standardizing and extracting information from resume data; evaluating the activity of resume data; scoring the quality of resume data; calculating the matching degree between resume data and job postings; and updating the feature representation of resume data in the recommendation system.

[0069] Specifically, the main function of the execution engine is to execute the resume processing instructions translated by the environment adapter. The execution engine can call the local command line or script interpreter to perform the actual processing operations on the resume data according to the requirements of the resume processing instructions. For example, if the environment adapter generates a shell script, the execution engine can start a shell interpreter to execute the script; if it is an Excel operation step, the execution engine can call Excel to complete the corresponding operation.

[0070] For example, in some cases, the execution engine can be used to clean resume data, removing noise, duplicate information, and erroneous data. The execution engine can also standardize resume data in different formats, giving it a uniform structure and format. Furthermore, the execution engine can extract key information from resumes, such as name, contact information, work experience, and educational background, providing a foundation for subsequent processing and analysis.

[0071] For example, in some examples, the execution engine can be used to perform activity assessments on resume data, evaluating the activity level of job seekers to better understand their job-seeking intentions and behavioral patterns. For example, in some examples, the execution engine can be used to perform quality scoring on resume data. This includes scoring resumes based on factors such as completeness of content, accuracy of information, and relevance to the job, helping recruiters filter out high-quality resumes. For example, in some examples, the execution engine can also be used to calculate the match between resume data and job postings and / or update the feature representation of resume data in a recommendation system.

[0072] This allows multiple executors to run on different operating systems and software environments, improving system compatibility and adaptability. Regardless of the operating system used, resume processing tasks can be executed smoothly, reducing development and maintenance costs caused by environmental differences. Furthermore, by mapping processing logic described in declarative languages ​​or generic interfaces to native executable instructions, the processing logic is standardized while retaining flexibility across different environments. Thus, developers can use a common approach to describe resume processing logic, and the executor can automatically adapt to the local environment, ensuring correct task execution.

[0073] Figure 3 This is a schematic diagram illustrating a process for evaluating the activity of resume data in an embodiment of this application. Figure 3 As shown, according to some embodiments of this application, optionally, the activity evaluation of resume data may include the following steps S301 to S304.

[0074] S301: Obtain behavioral data of the job seeker to whom the resume data belongs.

[0075] In S301, behavioral data of job seekers to whom resume data belongs can be queried from the database of the recruitment platform. This behavioral data may include at least one of the following: the job seeker's login frequency on the recruitment platform, historical activity level, number of job views, number of resume submissions, and number of communications with recruiting companies.

[0076] S302: Call the preset user activity analysis model to calculate the activity score of job seekers based on their behavioral data.

[0077] The user activity analysis model can be pre-trained or an existing model on the recruitment platform. For example, it can be trained using historical behavioral data and corresponding activity scores from multiple job seekers on the platform. Exemplarily, the model may include decision tree models (such as XGBoost or LightGBM) or deep neural network models. This model can be used to calculate a job seeker's activity score based on their behavioral data.

[0078] In S302, the behavioral data of job seekers can be input into the user activity analysis model, and the user activity score can be calculated and output through the user activity analysis model.

[0079] The user activity analysis model can assign different weights to each behavioral data item based on its importance. For example, the weight of login frequency can be 0.2, the weight of job viewing frequency can be 0.25, the weight of resume submission frequency can be 0.3, and the weight of communication with recruiting companies can be 0.25. By multiplying each behavioral data item by its corresponding weight and summing the results, the user activity analysis model can calculate and output the activity score of job seekers.

[0080] S303: Assign an activity status label to the resume data based on the activity score. The activity status label includes at least one of the following: high activity status, moderate activity status, low activity status, and pending cleanup status.

[0081] Based on the job seeker's activity score, corresponding activity status tags can be assigned to resume data. These activity status tags include at least one of the following: highly active, moderately active, inactive, and pending cleanup.

[0082] Specific allocation rules can be set according to actual circumstances. For example, when the activity score is higher than a preset threshold, such as a score greater than 8, the resume data is assigned to a highly active status. When the activity score is within a certain range, such as between 5 and 8, the resume data is assigned to a moderately active status. When the activity score is low, such as between 2 and 5, the resume data is assigned to a low-activity status. For resume data that has been inactive for a long time and has an extremely low activity score, such as less than 2, it can be assigned to a pending cleanup status.

[0083] S304: Set the display priority of resume data in the platform's recommendation list or search results based on the activity status tag.

[0084] Based on the assigned activity status tags, you can set the display priority of resume data in the platform's recommendation list or search results. For example, resume data with a high activity status can be displayed first to increase its exposure and the chances of being discovered by recruiters. Resume data with a moderate activity status has a lower display priority. Resume data with a low activity status has a lower display priority. Resume data in a pending cleanup status can have its display reduced or be cleaned up.

[0085] In this way, by collecting and analyzing job seeker behavior data, it is possible to more accurately understand users' job-seeking intentions and activity levels. Assigning activity status tags to resume data based on activity scores and setting display priorities helps recruiting companies find active and promising candidates more quickly in recommendation lists and search results, improving recruitment efficiency and reducing the time and workload for recruiting companies in screening resumes. In addition, setting "pending cleanup" status tags helps recruitment platforms promptly clean up long-term inactive resume data, reducing the burden on the database and improving system operating efficiency.

[0086] Figure 4 This is a schematic diagram illustrating a process in which the scheduler in this embodiment of the application tags recommended executor types for resume processing tasks. Figure 4 As shown, according to some embodiments of this application, optionally, the scheduler 103 is specifically used to perform the following steps S401 to S403.

[0087] S401: Analyze the resume data sharding and resume processing logic in the resume processing task, and determine the data processing feature categories of resume data sharding.

[0088] Because resume data in resume processing tasks comes from a wide range of sources and has diverse structures, and processing needs and goals may vary, different resume data segments may exhibit different characteristics and requirements during processing. For example, some resume data may come from large recruitment websites with standardized formats, while others may be documents manually uploaded by job seekers with inconsistent formats. Furthermore, processing needs may also differ; some may be for quality scoring of resume data, while others involve cleaning, standardizing, and extracting information from the resume data.

[0089] Therefore, the resume data sharding and resume processing logic in resume processing tasks can be analyzed to determine the data processing characteristic categories of resume data sharding. For example, data processing characteristic categories can include computationally intensive, input-output intensive, balanced, and conventional.

[0090] S402: Obtain device performance information for each actuator by querying the actuator registry.

[0091] Scheduler 103 can access the executor registry, which records device performance information for all executors in the system. From the executor registry, scheduler 103 can obtain device performance information for each executor, such as the number of CPU cores, CPU frequency, memory capacity, hard disk read / write speed, network bandwidth, computing performance score, and storage I / O performance score. This device performance information reflects the executor's computing power, data storage, and transmission capabilities.

[0092] The computational performance score is a quantitative assessment of the executor's computational capabilities. The more CPU cores, the more computational tasks the executor can process in parallel. A higher CPU clock speed results in faster processing speeds for individual cores. Furthermore, factors such as cache size can be considered; a larger cache can reduce data read time and improve computational efficiency. For example, in some examples, the computational performance score is calculated as: CPU core count weight × CPU core count + CPU clock speed weight × CPU clock speed + Cache size weight × Cache size. The weights for each item can be flexibly adjusted based on the actual application, and this application does not impose any limitations on this.

[0093] Storage I / O performance ratings can be used to evaluate an actuator's capabilities in data storage and transmission. Faster hard drive read / write speeds mean shorter times for the actuator to read data from and write data to the hard drive. Higher network bandwidth results in more efficient data transfer between the actuator and other devices. For example, in some cases, the storage I / O performance rating is calculated as: Hard Drive Read / Write Speed ​​Weight × Hard Drive Read / Write Speed ​​+ Network Bandwidth Weight × Network Bandwidth. The weights for each item can be adjusted flexibly based on the specific application, and this application does not impose any limitations on this.

[0094] S403: Based on the matching relationship between data processing feature categories of resume data fragmentation and device performance information, recommend executor types for resume processing tasks.

[0095] Scheduler 103 can recommend executor types for resume processing tasks based on the matching relationship between the data processing feature categories of resume data fragments and the device performance information of the executors. For example, for computationally intensive resume data fragments, the scheduler can prioritize executors with powerful CPU performance and high computing power, such as servers equipped with multi-core high-performance CPUs. For input / output intensive resume data fragments, the scheduler can select executors with high-speed hard drive read / write capabilities and high network bandwidth to meet the needs of large amounts of data input / output. For balanced or regular resume data fragments, the scheduler can select executors with relatively balanced performance. The scheduler recommends executor types for resume processing tasks to facilitate subsequent task assignment to appropriate executors.

[0096] In this way, based on the matching relationship between the data processing feature categories of resume data fragmentation and device performance information, the scheduler can achieve precise matching of tasks and executors, improving the utilization rate of system resources. This allows each executor to play its maximum role in its area of ​​expertise, thereby improving the processing efficiency and performance of the entire resume processing system. At the same time, it also reduces task processing time and costs, providing more efficient services for recruiting companies and job seekers.

[0097] According to some embodiments of this application, optionally, S401: Analyzing resume data fragmentation and resume processing logic in the resume processing task, and determining the data processing feature category of the resume data fragmentation, may include the following steps one to five.

[0098] Step 1: Obtain the attribute information of the resume data segments and the configuration information of the resume processing logic.

[0099] For example, the attribute information of a resume data segment may include the size of the data segment and the data format. The size of the data segment is the amount of storage space occupied by the resume data segment. The data format may include text format (such as JSON, XML), binary format, or other formats. Different data formats require different parsing methods and tools during processing, and obtaining the data format helps in selecting subsequent processing logic.

[0100] For example, the configuration information for resume processing logic may include the algorithms, operation steps, and data dependencies involved in the processing logic. The algorithms involved in the processing logic are those used when processing resume data, such as string matching algorithms and / or sorting algorithms (e.g., quicksort, mergesort). The operation steps are the specific operational processes for processing resume data, such as data cleaning, feature extraction, and / or classification. Data dependencies are the data dependencies between the various steps in the processing logic, i.e., which steps depend on the output results of other steps. Obtaining data dependencies helps determine the order and frequency of data access, thereby accurately predicting the data access volume score.

[0101] Step 2: Based on attribute and configuration information, estimate the computational complexity and data access volume score of resume data sharding.

[0102] In some embodiments, scores can be assigned to the size of the data slice, the algorithms involved in the processing logic, and the operation steps. For example, data slice sizes can be divided into three levels: small (e.g., less than 1MB), medium (e.g., 1MB-10MB), and large (e.g., greater than 10MB), assigned 1, 3, and 5 points respectively. For example, common algorithms such as simple search algorithms can be assigned 1-2 points, medium-complexity sorting algorithms 3-4 points, and complex machine learning algorithms (e.g., deep learning algorithms) 5 points. For example, processing logic with fewer and simpler steps can be assigned 1-2 points, those with a medium number of steps and complexity 3-4 points, and those with many and complex steps 5 points. Then, the computational complexity of the data slice is calculated by weighting the scores based on the data slice size, the algorithms involved in the processing logic, and the operation steps.

[0103] In some embodiments, data dependencies can be categorized and scored based on their complexity. For example, simple data dependencies with few inter-step relationships are assigned 1-2 points. Data dependencies with some degree of dependence, where some steps require the results of other steps, are assigned 3-4 points. Data dependencies with complex relationships, where multiple steps depend on each other and there are circular dependencies, are assigned 5 points. Then, the data dependency score is multiplied by a preset weight to obtain the data access volume score.

[0104] Step 3: If the computational complexity is greater than the preset complexity threshold, then the data processing feature category is determined to be computationally intensive.

[0105] Scheduler 103 can compare the estimated computational complexity with a preset complexity threshold. If the computational complexity is greater than the preset complexity threshold, it means that the processing of the resume data shards requires a large amount of computing resources, and therefore the data processing feature category can be determined as computationally intensive.

[0106] Step 4: If the data access score is greater than the preset access threshold, then the data processing feature category is determined to be input-output intensive.

[0107] Scheduler 103 can compare the estimated data access score with a preset access threshold. If the data access score is greater than the preset access threshold, it indicates that the main bottleneck in processing the resume data shard is the data input and output operations, and therefore the data processing feature category can be determined as input and output intensive.

[0108] Step 5: If the computational complexity is less than or equal to the preset complexity threshold, and the data access volume score is less than or equal to the preset access volume threshold, then the data processing feature category is determined to be either balanced or conventional.

[0109] When the computational complexity and data access volume scores do not exceed their respective thresholds, it indicates that the processing of the resume data shards has a relatively balanced demand for computational resources and data input / output resources. Therefore, the data processing characteristic category can be determined as balanced or conventional.

[0110] In this way, by accurately determining the data processing characteristic categories, the scheduler can gain a deep understanding of the resource requirements of resume processing tasks, providing a key basis for selecting appropriate executors. For example, it helps to avoid assigning computationally intensive tasks to executors that do not have strong computing power, or to avoid assigning input-output intensive tasks to executors with weak data read-write capabilities, thereby improving the efficiency and quality of task processing.

[0111] According to some embodiments of this application, optionally, the device performance information may include a computing performance score and a storage input / output performance score. The computing performance score and storage input / output performance score have been described above and will not be repeated here.

[0112] Accordingly, S403: Based on the matching relationship between the data processing feature categories of resume data fragments and the device performance tags, the recommended executor type is marked for the resume processing task, which may include the following steps six to eight.

[0113] Step 6: If the data processing feature category is computationally intensive, then filter out executors with computational performance scores greater than the first performance threshold from the executor registry, and mark the recommended executor type for the resume processing task as the type corresponding to the filtered executor.

[0114] In step six, when the data processing characteristic category of the resume data fragment is determined to be computationally intensive, the scheduler 103 can filter executors with computational performance scores greater than a first performance threshold from the executor registry. These executors have strong computational capabilities and can better handle computationally intensive resume processing tasks. Then, the scheduler 103 can mark the recommended executor type for the resume processing task as the type corresponding to the filtered executors.

[0115] This allows computationally intensive resume processing tasks to be assigned to powerful executors. High-performance executors can complete complex computational tasks more quickly and efficiently, such as performing complex algorithmic analysis on large amounts of resume data, thereby improving the speed and quality of task processing and reducing the execution time of resume processing tasks.

[0116] Step 7: If the data processing feature category is input-output intensive, then filter out the executors from the executor registry whose stored input-output performance scores are greater than the second performance threshold, and mark the recommended executor type for the resume processing task as the type corresponding to the filtered executor.

[0117] In step seven, if the data processing characteristic category is input / output intensive, the scheduler 103 can filter executors from the executor registry whose stored input / output performance scores are greater than a second performance threshold. These executors have advantages in data reading, writing, and transmission, and are suitable for handling resume processing tasks that require a large amount of data input and output. Then, the scheduler 103 can mark the recommended executor type for the resume processing task as the type corresponding to the filtered executors.

[0118] In this way, input-output intensive resume processing tasks can be assigned to executors with good storage input-output performance. The executors can quickly read and write large amounts of resume data, such as batch reading resume information from the database and quickly storing the processed results in storage devices, avoiding task processing delays caused by data input-output bottlenecks and improving the overall efficiency of the system.

[0119] Step 8: If the data processing feature category is balanced or regular, then filter out the executors whose current load is less than the load threshold, and mark the recommended executor type for the resume processing task as the type corresponding to the filtered executor.

[0120] In step eight, for resume processing tasks with data processing characteristics classified as balanced or regular, scheduler 103 can filter out executors whose current load is less than a load threshold. These executors are in a relatively idle state and have sufficient resources to process resume processing tasks. Then, scheduler 103 can mark the recommended executor type for the resume processing task as the type corresponding to the filtered executors.

[0121] This allows balanced or routine resume processing tasks to be rationally distributed to less loaded executors. It avoids assigning tasks to already heavily loaded executors, which could lead to inefficient processing or system crashes, thus ensuring system stability and reliability.

[0122] Based on the resume processing system for recruitment platforms provided in the above embodiments, this application also provides a resume processing method for recruitment platforms. This method can be implemented based on the resume processing system for recruitment platforms provided in any of the above embodiments.

[0123] Figure 5 This is a schematic flowchart illustrating a resume processing method for a recruitment platform provided in an embodiment of this application. Figure 5 As shown, the resume processing method used by recruitment platforms may include the following steps: S501: Provides a visual interface for managing resume processing tasks; S502: When a preset triggering condition is detected, a resume processing request is sent to the scheduler. The resume processing request includes the identifier of each resume data in the resume data set to be processed. S503: Perform the following operations through the scheduler: obtain a set of resume data based on the identifier; divide the set of resume data into multiple resume data slices; generate multiple resume processing tasks, each of which contains at least one resume data slice and resume processing logic; label each resume processing task with a recommended executor type based on the device information of multiple executors; and send the multiple resume processing tasks to a message queue. S504: Perform the following operations on each executor: retrieve a resume processing task of the recommended executor type corresponding to its own device information from the message queue; convert the resume processing logic in the retrieved resume processing task into resume processing instructions that run locally on the executor; and process the resume data fragments in the resume processing task based on the resume processing instructions.

[0124] The specific process of the above steps has been described in detail above and will not be repeated here.

[0125] The resume processing method for recruitment platforms provided in this application transforms the previously decentralized operation and maintenance (O&M) of distributing tasks across multiple servers and manually writing and configuring Crontab scripts into centralized management through a unified web management console. The visual interface provided by the web management console allows users to manage resume processing tasks uniformly, changing the cumbersome configuration, update, and monitoring issues caused by the traditional approach of distributing processing scripts and scheduled tasks across multiple servers. This reduces O&M complexity, enables rapid resume data updates, and ultimately improves the accuracy of talent recommendation and job matching. Furthermore, through a decoupled design of "scheduler-message queue-executor," the physical and logical separation of task scheduling and task execution is achieved. The scheduler divides the resume data set into multiple resume data shards, generating tasks containing the resume data shards and processing logic. Resume data shards facilitate parallel processing, reducing the processing pressure on individual executors. Combined with the operation of tagging and recommending executor types, tasks can be accurately allocated based on data characteristics and executor performance, fully leveraging the advantages of each executor and further improving processing efficiency. The actuator retrieves resume processing tasks of the recommended actuator type corresponding to its own equipment information on demand, which helps to reduce resource waste and achieve system load balancing.

[0126] Furthermore, through the decoupled design of "scheduler-message queue-executor," if any executor fails, its unfinished resume processing tasks can be retained in the message queue and automatically taken over by other healthy executors of the same type. Faced with sudden surges in resume processing demands, simply adding executor nodes horizontally can linearly increase the overall system processing capacity without modifying the core scheduling logic, achieving rapid and elastic resource response.

[0127] It should be noted that the resume processing method for recruitment platforms can have the same or corresponding technical features as the resume processing system for recruitment platforms provided in any of the above embodiments, and produce the same technical effects. For the sake of brevity, further details will not be elaborated here.

[0128] The flowcharts and / or block diagrams of the methods and systems according to embodiments of this application have been described above by way of example, and related aspects have been described. It should be understood that each block or combination thereof in the flowcharts and / or block diagrams may be implemented by computer program instructions, by dedicated hardware performing the specified function or action, or by a combination of dedicated hardware and computer instructions. For example, these computer program instructions may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to form a machine such that these instructions, which execute via such processor, enable the implementation of the function / action specified in each block or combination thereof in the flowcharts and / or block diagrams. Such a processor may be a general-purpose processor, a dedicated processor, a special-purpose application processor, or a field-programmable logic circuit.

[0129] The functional blocks shown in the structural block diagrams of this application can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc.; when implemented in software, they are programs or code segments used to perform the required tasks. Programs or code segments can be stored in memory or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. Code segments can be downloaded via computer networks such as the Internet or intranets.

[0130] It should be noted that this application is not limited to the specific configurations and processes described above or shown in the figures. The above descriptions are merely specific embodiments of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the described systems, devices, modules, or units can be referred to the corresponding processes in the method embodiments, and need not be repeated here. It should be understood that the scope of protection of this application is not limited thereto. Any person skilled in the art can conceive of various equivalent modifications or substitutions within the scope of the technology disclosed in this application, and these modifications or substitutions should all be covered within the scope of protection of this application.

Claims

1. A resume processing system for a recruitment platform, characterized in that, Includes a web management console, triggers, schedulers, message queues, and multiple executors: The web management console provides a visual interface for managing resume processing tasks; The trigger is used to send a resume processing request to the scheduler when a preset trigger condition is detected. The resume processing request includes the identifier of each resume data in the resume data set to be processed. The scheduler is used to obtain a set of resume data according to the identifier; divide the set of resume data into multiple resume data segments; and generate multiple resume processing tasks containing at least one resume data segment and resume processing logic. And based on the device information of multiple actuators, recommend the actuator type for each resume processing task; The message queue is used to receive and store multiple resume processing tasks; Each executor is used to retrieve a resume processing task of the recommended executor type corresponding to its own device information from the message queue; The resume processing logic in the resume processing task is converted into resume processing instructions that run locally on this executor. And based on resume processing instructions, it processes resume data segments in resume processing tasks.

2. The system according to claim 1, characterized in that, The plurality of actuators are heterogeneous actuators, with at least some of the actuators having different hardware configurations, operating system types and / or software operating environments; The preset triggering conditions include at least one of the following: reaching a preset time period; detecting a business event related to the resume; detecting that the CPU idle rate and / or memory idle rate of at least one actuator exceeds a preset threshold.

3. The system according to claim 1, characterized in that, The scheduler is specifically used to divide the resume data set into multiple resume data shards based on the job seeker's activity level, resume submission time, job seeker's location, or industry category in the resume data; among them, multiple resumes with the same activity level, the same submission time range, the same region, or the same industry category are assigned to the same resume data shard.

4. The system according to claim 3, characterized in that, Each actuator contains an environment adapter and an execution engine; The environment adapter is used to select the corresponding target instruction mapping rule from a preset instruction mapping rule set according to the local operating system type, and to map the resume processing logic described in a declarative language or general interface in the resume processing task into resume processing instructions that are executed in the local command line or script interpreter according to the target instruction mapping rule. The execution engine is used to perform at least one of the following processes on the resume data in the resume data shards based on resume processing instructions: cleaning, standardizing and extracting information from the resume data; evaluating the activity of the resume data; scoring the quality of the resume data; calculating the matching degree between the resume data and the job; and updating the feature representation of the resume data in the recommendation system.

5. The system according to claim 4, characterized in that, Active evaluation of resume data, including: Obtain behavioral data of the job seeker to whom the resume data belongs. The behavioral data includes at least one of the following: the job seeker's login frequency on the recruitment platform, historical activity level, number of times job views are made, number of times resumes are submitted, and number of times communication with recruiting companies. The system invokes a pre-defined user activity analysis model to calculate the activity score of job seekers based on their behavioral data. The resume data is assigned an activity status label based on the activity score. The activity status label includes at least one of the following: high activity status, normal activity status, low activity status, and pending cleanup status. Based on the activity status tag, set the display priority of the resume data in the platform's recommendation list or search results.

6. The system according to claim 1, characterized in that, The scheduler is specifically used to perform the following processes: Analyze resume data segmentation and resume processing logic in resume processing tasks to determine the data processing characteristic categories of resume data segmentation. By querying the actuator registry, the device performance information of each actuator can be obtained; Based on the matching relationship between the data processing feature categories of the resume data segments and the device performance information, a recommended executor type is assigned to the resume processing task.

7. The system according to claim 6, characterized in that, Analyze resume data segmentation and resume processing logic in resume processing tasks to determine the data processing characteristic categories of resume data segmentation, including: Obtain the attribute information of the resume data segments and the configuration information of the resume processing logic; Based on the attribute information and the configuration information, the computational complexity and data access volume score of resume data sharding are estimated. If the computational complexity exceeds a preset complexity threshold, the data processing feature category is determined to be computationally intensive. If the data access score is greater than the preset access threshold, the data processing feature category is determined to be input-output intensive. If the computational complexity is less than or equal to the preset complexity threshold, and the data access volume score is less than or equal to the preset access volume threshold, then the data processing feature category is determined to be either balanced or conventional.

8. The system according to claim 7, characterized in that, The device performance information includes computational performance scores and storage input / output performance scores; Based on the matching relationship between the data processing feature categories of the resume data segments and the device performance tags, a recommended executor type is assigned to the resume processing task, including: If the data processing feature category is computationally intensive, then from the executor registry, executors with computational performance scores greater than the first performance threshold are selected, and the recommended executor type for the resume processing task is marked as the type corresponding to the selected executor. If the data processing feature category is input-output intensive, then from the executor registry, executors with input-output performance scores greater than the second performance threshold are selected, and the recommended executor type for the resume processing task is marked as the type corresponding to the selected executor. If the data processing feature category is balanced or normal, then the executors whose current load is less than the load threshold are selected, and the recommended executor type for the resume processing task is marked as the type corresponding to the selected executor.

9. The system according to claim 1, characterized in that, The visual interface of the web management console includes: The task configuration and publishing component is used to receive user input, which includes setting the trigger conditions for the resume processing task, the range of resume data to be processed, and the resume processing logic to be executed. A heterogeneous resource monitoring view component is used to display at least one of the following in the form of grouping or list: device type, current load status, health, and task processing queue of the multiple actuators; The task end-to-end tracking component is used to display the processing progress of any resume processing task and supports querying detailed execution logs for each stage of the resume processing process; The results statistics and reporting component is used to aggregate and analyze the results of resume processing tasks and display at least one of the following in the form of charts: resume distribution trend, task execution efficiency indicators, and system resource consumption reports.

10. A resume processing method for a recruitment platform, characterized in that, The method is implemented based on a resume processing system for a recruitment platform as described in any one of claims 1-9, and the method includes: Provides a visual interface for managing resume processing tasks; When a preset trigger condition is detected, a resume processing request is sent to the scheduler. The resume processing request includes the identifier of each resume data in the resume data set to be processed. The scheduler performs the following operations: obtains the resume data set based on the identifier; divides the resume data set into multiple resume data fragments; generates multiple resume processing tasks, each resume processing task containing at least one resume data fragment and resume processing logic; labels each resume processing task with a recommended executor type based on the device information of multiple executors; and sends the multiple resume processing tasks to a message queue. Each executor performs the following operations: retrieves a resume processing task of the recommended executor type corresponding to its own device information from the message queue; converts the resume processing logic in the retrieved resume processing task into resume processing instructions that run locally on the executor; and processes the resume data fragments in the resume processing task based on the resume processing instructions.

Images