This is an automated email from the ASF dual-hosted git repository.
gallardot pushed a commit to branch dev
in repository https://gitbox.apache.org/repos/asf/dolphinscheduler.git
The following commit(s) were added to refs/heads/dev by this push:
new 46698d6be4 [Chore][Doc] Fix typos and improve the expression in
`glossary.md`. (#17380)
46698d6be4 is described below
commit 46698d6be4dbe536ec6dcb804396cb2a5723a06a
Author: Sud0x67 <[email protected]>
AuthorDate: Tue Jul 29 13:57:32 2025 +0800
[Chore][Doc] Fix typos and improve the expression in `glossary.md`.
(#17380)
Co-authored-by: xiangzihao <[email protected]>
---
docs/docs/en/about/glossary.md | 54 ++++++++++++++++++++++--------------------
1 file changed, 28 insertions(+), 26 deletions(-)
diff --git a/docs/docs/en/about/glossary.md b/docs/docs/en/about/glossary.md
index db4e875354..f8f9c09386 100644
--- a/docs/docs/en/about/glossary.md
+++ b/docs/docs/en/about/glossary.md
@@ -5,47 +5,49 @@ scheduling system
### 1.Glossary
-**DAG：** The full name is Directed Acyclic Graph, referred to as DAG. Task
tasks in the workflow are assembled in the
-form of a directed acyclic graph, and topological traversal is performed from
nodes with zero degrees of entry until
-there are no subsequent nodes. Examples are as follows:
+**DAG：** The full name is Directed Acyclic Graph, referred to as DAG. Tasks in
the workflow are assembled in the
+form of a directed acyclic graph, and topological traversal is performed from
nodes with zero in-degree until
+there are no subsequent nodes. An example is shown below:
-**Process definition**: Visualization formed by dragging task nodes and
establishing task node associations**DAG**
+**Process definition**: Visualization of a **DAG** formed by dragging task
nodes and establishing associations between them.
-**Process instance**: The process instance is the instantiation of the process
definition, which can be generated by
-manual start or scheduled scheduling. Each time the process definition runs, a
process instance is generated
+**Process instance**: A process instance is the instantiation of a process
definition, which can be generated by
+manual start or scheduled triggering. Each time a process definition runs, a
process instance is generated
-**Task instance**: The task instance is the instantiation of the task node in
the process definition, which identifies
-the specific task
+**Task instance**: An instantiation of a task node within a process
definition, representing a specific execution
+of that task.
**Task type**: Currently supports SHELL, SQL, SUB_WORKFLOW, PROCEDURE, MR,
SPARK, PYTHON, DEPENDENT (
-depends), and plans to support dynamic plug-in expansion, note:
**SUB_WORKFLOW** need relation with another workflow definition which also a
separate process
-definition that can be started and executed separately
+depends), and plans to support dynamic plug-in expansion, note:
**SUB_WORKFLOW** need be associated with another
+workflow definition which is a separate process definition that can be started
and executed separately
-**Scheduling method**: The system supports scheduled scheduling and manual
scheduling based on cron expressions. Command
-type support: start workflow, start execution from current node, resume
fault-tolerant workflow, resume pause process,
-start execution from failed node, complement, timing, rerun, pause, stop,
resume waiting thread. Among them **Resume
-fault-tolerant workflow** and **Resume waiting thread** The two command types
are used by the internal control of
-scheduling, and cannot be called from the outside
+**Scheduling method**: The system supports scheduled triggering (based on cron
expressions) and manual triggering.
+Command types support: start workflow, start execution from current node,
resume fault-tolerant workflow,
+resume pause process, start execution from failed node, complement, timing,
rerun, pause, stop, resume waiting thread.
+Among them the command types **Resume fault-tolerant workflow** and **Resume
waiting thread** are used by the internal
+scheduling control and cannot be invoked externally.
-**Scheduled**: System adopts **quartz** distributed scheduler, and supports
the visual generation of cron expressions
+**Scheduled**: The system adopts **quartz** distributed scheduler, and
supports visual generation of cron expressions
-**Rely**: The system not only supports **DAG** simple dependencies between the
predecessor and successor nodes, but also
-provides **task dependent** nodes, supporting **between processes**
+**Dependencies**: The system not only supports simple **DAG** dependencies
between predecessor and successor nodes, but also
+provides **task dependent** nodes, supporting dependencies **between
processes**
-**Priority**: Support the priority of process instances and task instances, if
the priority of process instances and
-task instances is not set, the default is first-in-first-out
+**Priority**: Supports priority settings for both process instances and task
instances. If no priority is specified,
+the system defaults to a first-in, first-out (FIFO) execution order.
**Email alert**: Support **SQL task** Query result email sending, process
instance running result email alert and fault
tolerance alert notification
-**Failure strategy**: For tasks running in parallel, if a task fails, two
failure strategy processing methods are
-provided. **Continue** refers to regardless of the status of the task running
in parallel until the end of the process
-failure. **End** means that once a failed task is found, Kill will also run
the parallel task at the same time, and the
-process fails and ends
+**Failure strategy**: For workflows with parallel task execution, the system
provides two failure handling strategies.
+**Continue** If a task fails, the system continues executing other parallel
tasks to completion, regardless of the failure.
+The overall process is marked as failed only after all parallel tasks have
finished running.
+**End** means that upon a task failure, the system immediately marks the
process as failed and terminates any currently
+running parallel tasks
-**Complement**: Supplement historical data，supports **interval parallel** and
**serial** two complement methods, and two types of date selection which
include **date range** and **date enumeration**.
+**Complement**: backfilling historical data，supports **interval parallel** and
**serial** two complement modes,
+and two date selection methods including **date range** and **date
enumeration**.
### 2.Module introduction
@@ -71,5 +73,5 @@ process fails and ends
### Sum up
From the perspective of scheduling, this article preliminarily introduces the
architecture principles and implementation
-ideas of the big data distributed workflow scheduling system-DolphinScheduler.
To be continued
+ideas of the big data distributed workflow scheduling system —
DolphinScheduler. To be continued
