Skip to content

[Compiler Refactor 7] Migrate simple operators to use the new OpExecConfig class#1794

Merged
zuozhiw merged 14 commits into
zuozhi-refactor-workflowfrom
zuozhi-migrate-opexec
Jan 31, 2023
Merged

[Compiler Refactor 7] Migrate simple operators to use the new OpExecConfig class#1794
zuozhiw merged 14 commits into
zuozhi-refactor-workflowfrom
zuozhi-migrate-opexec

Conversation

@zuozhiw

@zuozhiw zuozhiw commented Jan 17, 2023

Copy link
Copy Markdown
Contributor

This PR is a follow up of #1791 . In #1791 a new OpExecConfig class is introduced. This PR updates the simple operators that are mostly one-to-one to use the new class. Most changes are one-line changes that directly map from the old API to the new API. Changes to more complicated operators (join, aggregate, etc..) will be completed in subsequent PRs.

@zuozhiw zuozhiw changed the base branch from master to zuozhi-op-interface January 17, 2023 21:07
Base automatically changed from zuozhi-op-interface to master January 17, 2023 22:01
@zuozhiw zuozhiw requested a review from shengquan-ni January 17, 2023 22:05
@zuozhiw zuozhiw changed the title Migrate one-to-one operators to use the new OpExecConfig class Migrate simple operators to use the new OpExecConfig class Jan 19, 2023
@zuozhiw zuozhiw changed the title Migrate simple operators to use the new OpExecConfig class Migrate one-to-one operators to use the new OpExecConfig class Jan 19, 2023
@zuozhiw zuozhiw changed the title Migrate one-to-one operators to use the new OpExecConfig class Migrate simple operators to use the new OpExecConfig class Jan 19, 2023
@zuozhiw zuozhiw added engine refactor Refactor the code java labels Jan 19, 2023
@zuozhiw zuozhiw changed the title Migrate simple operators to use the new OpExecConfig class [Compiler Refactor 6] Migrate simple operators to use the new OpExecConfig class Jan 19, 2023
@zuozhiw zuozhiw changed the base branch from master to zuozhi-refactor-workflow January 25, 2023 19:46
@zuozhiw zuozhiw changed the title [Compiler Refactor 6] Migrate simple operators to use the new OpExecConfig class [Compiler Refactor 7] Migrate simple operators to use the new OpExecConfig class Jan 30, 2023

@shengquan-ni shengquan-ni left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

…ig class (#1817)

This PR is a continuation of #1794 . In this PR, all the operators are
migrated to use the new `OpExecConfig` class. This PR involves changes
to more complicated operators such as sources, aggregations, and joins.
@zuozhiw zuozhiw merged commit 3f32fb5 into zuozhi-refactor-workflow Jan 31, 2023
@zuozhiw zuozhiw deleted the zuozhi-migrate-opexec branch January 31, 2023 10:12
zuozhiw added a commit that referenced this pull request Feb 2, 2023
…Plan implementation (#1807)

This PR does the following changes:
1. Refactors the `Workflow` class to use the new `PhysicalPlan` class.
After this change, all helper functions related to traversing the
physical plan DAG is inside `PhysicalPlan`.
2. In all classes dealing with the actual physical plan, use `LayerID`
(physical operator ID) instead of `OperatorID`(logical operator ID) to
identify an operator. Specifically, `OperatorID` consists of
`(workflowID, operatorID)` (logical operator). `LayerID` consists of
`(workflowID, operatorID, layerID)`, one logical operator can
corresponds to multiple physical operators (such as aggregate and
visualization).
3. Changes from #1794 and #1817 are also merged into master in this
branch. Previously, these two PRs are merged into this base branch. In
the previous two PRs, all operators are updated to adopt the new
`OpExecConfig` API.
4. After all operators adopt the new `OpExecConfig` API, the old code
are all cleaned up. Specifically, many old `XxxOpExecConfig` classes are
no longer needed and they are all unified into the new OpExecConfig`
API.
5. Refactors the `WorkflowPipelinedBuilder` class to use the new
`PhysicalPlan` API. Separate the logic of deiciding a region and adding
a materialization operator with a new `MaterializationRewriter` class.
6. Refactors the compilation phase into a logical plan building and a
physical plan building phase. In the physical plan building phase, adds
a new `PartitionEnforcer` to decide the shuffle policies of each link.
The old ad-hoc way to decide shuffle policies (`DeploymentFilter`) is
removed.
yangzhang75 pushed a commit to yangzhang75/texera that referenced this pull request Jun 22, 2026
…Plan implementation (apache#1807)

This PR does the following changes:
1. Refactors the `Workflow` class to use the new `PhysicalPlan` class.
After this change, all helper functions related to traversing the
physical plan DAG is inside `PhysicalPlan`.
2. In all classes dealing with the actual physical plan, use `LayerID`
(physical operator ID) instead of `OperatorID`(logical operator ID) to
identify an operator. Specifically, `OperatorID` consists of
`(workflowID, operatorID)` (logical operator). `LayerID` consists of
`(workflowID, operatorID, layerID)`, one logical operator can
corresponds to multiple physical operators (such as aggregate and
visualization).
3. Changes from apache#1794 and apache#1817 are also merged into master in this
branch. Previously, these two PRs are merged into this base branch. In
the previous two PRs, all operators are updated to adopt the new
`OpExecConfig` API.
4. After all operators adopt the new `OpExecConfig` API, the old code
are all cleaned up. Specifically, many old `XxxOpExecConfig` classes are
no longer needed and they are all unified into the new OpExecConfig`
API.
5. Refactors the `WorkflowPipelinedBuilder` class to use the new
`PhysicalPlan` API. Separate the logic of deiciding a region and adding
a materialization operator with a new `MaterializationRewriter` class.
6. Refactors the compilation phase into a logical plan building and a
physical plan building phase. In the physical plan building phase, adds
a new `PartitionEnforcer` to decide the shuffle policies of each link.
The old ad-hoc way to decide shuffle policies (`DeploymentFilter`) is
removed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

engine refactor Refactor the code

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants