Uh oh!
There was an error while loading. Please reload this page.
[feat](thirdparty) Refactor HDFS dependency management: move HDFS client jars to FE and slim down BE thirdparty - #57202
Conversation
…ent jars to FE and slim down BE thirdparty ### Background Previously, BE depended on the HDFS official distribution through the thirdparty module. This approach directly compiled and packaged Hadoop’s full dependencies, including large and unnecessary modules such as YARN, MapReduce, etc. As a result: The build artifact contained many duplicate jars. The total size was unnecessarily large (hundreds of MB). BE only acted as an HDFS client, not a Hadoop runtime, so most of these dependencies were not needed. ### Changes in this PR Move all HDFS-related jars to FE for unified dependency management, since FE already uses HDFS extensively. Retain necessary native/C++ dependencies under thirdparty for BE. Do not build an uber-jar for HDFS (unlike other BE thirdparty libs). Exclude unused Hadoop modules (e.g., YARN, MR, tools). The resulting target structure now includes: ``` target/ ├── classes ├── lib/ │ └── (~57M total) ├── hadoop-deps.jar └── ... ``` Compared with the previous build, the total artifact size has been reduced by ~150 MB. ### Rationale Since BE only functions as a client to access HDFS, managing Java-side HDFS dependencies in FE is cleaner and more maintainable. If BE needs custom logic (e.g., optimized HDFS client), we can extend or override the relevant classes and control class loading order. Impact Build size reduced by ~150 MB Simpler dependency graph ### Notes Native/C++ HDFS dependencies remain managed under thirdparty. FE now provides necessary jars for BE at runtime. No need to modify existing C++ build logic.
hello-stephen
commented
Oct 21, 2025
Thank you for your contribution to Apache Doris. Please clearly describe your PR:
|
CalvinKirs
commented
Oct 21, 2025
run buildall |
doris-robot
commented
Oct 21, 2025
ClickBench: Total hot run time: 30.7 s |
CalvinKirs
commented
Oct 24, 2025
run compile |
3 similar comments
CalvinKirs
commented
Oct 24, 2025
run compile |
CalvinKirs
commented
Oct 24, 2025
run compile |
CalvinKirs
commented
Oct 24, 2025
run compile |
CalvinKirs
commented
Oct 24, 2025
run p0 |
[feat](thirdparty) Refactor HDFS dependency management: move HDFS client jars to FE and slim down BE thirdparty ### Background Previously, BE depended on the HDFS official distribution through the thirdparty module. This approach directly compiled and packaged Hadoop’s full dependencies, including large and unnecessary modules such as YARN, MapReduce, etc. As a result: The build artifact contained many duplicate jars. The total size was unnecessarily large (hundreds of MB). BE only acted as an HDFS client, not a Hadoop runtime, so most of these dependencies were not needed. ### Changes in this PR Move all HDFS-related jars to FE for unified dependency management, since FE already uses HDFS extensively. Retain necessary native/C++ dependencies under thirdparty for BE. Do not build an uber-jar for HDFS (unlike other BE thirdparty libs). Exclude unused Hadoop modules (e.g., YARN, MR, tools). The resulting target structure now includes: ``` target/ ├── classes ├── lib/ │ └── (~57M total) ├── hadoop-deps.jar └── ... ``` Compared with the previous build, the total artifact size has been reduced by ~150 MB. ### Rationale Since BE only functions as a client to access HDFS, managing Java-side HDFS dependencies in FE is cleaner and more maintainable. If BE needs custom logic (e.g., optimized HDFS client), we can extend or override the relevant classes and control class loading order. Impact Build size reduced by ~150 MB Simpler dependency graph ### Notes Native/C++ HDFS dependencies remain managed under thirdparty. FE now provides necessary jars for BE at runtime. No need to modify existing C++ build logic.
8244fb9 to
65c151fCompareCalvinKirs
commented
Oct 24, 2025
run buildall |
doris-robot
commented
Oct 24, 2025
ClickBench: Total hot run time: 29.86 s |
CalvinKirs
commented
Oct 27, 2025
run buildall |
doris-robot
commented
Oct 27, 2025
TPC-DS: Total hot run time: 189151 ms |
doris-robot
commented
Oct 27, 2025
ClickBench: Total hot run time: 28.25 s |
hello-stephen
commented
Oct 27, 2025
FE UT Coverage ReportIncrement line coverage `` 🎉 |
hello-stephen
commented
Oct 27, 2025
BE UT Coverage ReportIncrement line coverage Increment coverage report
|
hello-stephen
commented
Oct 27, 2025
BE Regression && UT Coverage ReportIncrement line coverage Increment coverage report
|
CalvinKirs
commented
Oct 28, 2025
run buildall |
hello-stephen
commented
Oct 28, 2025
Cloud UT Coverage ReportIncrement line coverage Increment coverage report
|
hello-stephen
commented
Oct 28, 2025
FE UT Coverage ReportIncrement line coverage `` 🎉 |
doris-robot
commented
Oct 28, 2025
TPC-DS: Total hot run time: 190878 ms |
4cd1e81 to
f23d78dCompareCalvinKirs
commented
Oct 29, 2025
run buildall |
doris-robot
commented
Oct 29, 2025
Cloud UT Coverage ReportIncrement line coverage Increment coverage report
|
PR approved by at least one committer and no changes requested. |
hello-stephen
commented
Oct 29, 2025
BE UT Coverage ReportIncrement line coverage Increment coverage report
|
hello-stephen
commented
Oct 29, 2025
BE Regression && UT Coverage ReportIncrement line coverage Increment coverage report
|
morningman
commented
Oct 30, 2025
run performance |
CalvinKirs
commented
Oct 30, 2025
run performance |
doris-robot
commented
Oct 30, 2025
ClickBench: Total hot run time: 28.32 s |
Uh oh!
There was an error while loading. Please reload this page.
…ent jars to FE and slim down BE thirdparty (#57202) ### Background Previously, BE depended on the HDFS official distribution through the thirdparty module. This approach directly compiled and packaged Hadoop’s full dependencies, including large and unnecessary modules such as YARN, MapReduce, etc. As a result: The build artifact contained many duplicate jars. The total size was unnecessarily large (hundreds of MB). BE only acted as an HDFS client, not a Hadoop runtime, so most of these dependencies were not needed. ### Changes in this PR Move all HDFS-related jars to FE for unified dependency management, since FE already uses HDFS extensively. Retain necessary native/C++ dependencies under thirdparty for BE. Do not build an uber-jar for HDFS (unlike other BE thirdparty libs). Exclude unused Hadoop modules (e.g., YARN, MR, tools). The resulting target structure now includes: ``` target/ ├── classes ├── lib/ │ └── (~57M total) ├── hadoop-deps.jar └── ... ``` Compared with the previous build, the total artifact size has been reduced by ~150 MB. ### Rationale Since BE only functions as a client to access HDFS, managing Java-side HDFS dependencies in FE is cleaner and more maintainable. If BE needs custom logic (e.g., optimized HDFS client), we can extend or override the relevant classes and control class loading order. Impact Build size reduced by ~150 MB Simpler dependency graph ### Notes Native/C++ HDFS dependencies remain managed under thirdparty. FE now provides necessary jars for BE at runtime. No need to modify existing C++ build logic.
…ve HDFS client jars to FE and slim down BE thirdparty (apache#57202) apache#57202 (cherry picked from commit 4ea473c)
…ent jars to FE and slim down BE thirdparty (apache#57202) ### Background Previously, BE depended on the HDFS official distribution through the thirdparty module. This approach directly compiled and packaged Hadoop’s full dependencies, including large and unnecessary modules such as YARN, MapReduce, etc. As a result: The build artifact contained many duplicate jars. The total size was unnecessarily large (hundreds of MB). BE only acted as an HDFS client, not a Hadoop runtime, so most of these dependencies were not needed. ### Changes in this PR Move all HDFS-related jars to FE for unified dependency management, since FE already uses HDFS extensively. Retain necessary native/C++ dependencies under thirdparty for BE. Do not build an uber-jar for HDFS (unlike other BE thirdparty libs). Exclude unused Hadoop modules (e.g., YARN, MR, tools). The resulting target structure now includes: ``` target/ ├── classes ├── lib/ │ └── (~57M total) ├── hadoop-deps.jar └── ... ``` Compared with the previous build, the total artifact size has been reduced by ~150 MB. ### Rationale Since BE only functions as a client to access HDFS, managing Java-side HDFS dependencies in FE is cleaner and more maintainable. If BE needs custom logic (e.g., optimized HDFS client), we can extend or override the relevant classes and control class loading order. Impact Build size reduced by ~150 MB Simpler dependency graph ### Notes Native/C++ HDFS dependencies remain managed under thirdparty. FE now provides necessary jars for BE at runtime. No need to modify existing C++ build logic.
…ent jars to FE and slim down BE thirdparty (#57202) ### Background Previously, BE depended on the HDFS official distribution through the thirdparty module. This approach directly compiled and packaged Hadoop’s full dependencies, including large and unnecessary modules such as YARN, MapReduce, etc. As a result: The build artifact contained many duplicate jars. The total size was unnecessarily large (hundreds of MB). BE only acted as an HDFS client, not a Hadoop runtime, so most of these dependencies were not needed. ### Changes in this PR Move all HDFS-related jars to FE for unified dependency management, since FE already uses HDFS extensively. Retain necessary native/C++ dependencies under thirdparty for BE. Do not build an uber-jar for HDFS (unlike other BE thirdparty libs). Exclude unused Hadoop modules (e.g., YARN, MR, tools). The resulting target structure now includes: ``` target/ ├── classes ├── lib/ │ └── (~57M total) ├── hadoop-deps.jar └── ... ``` Compared with the previous build, the total artifact size has been reduced by ~150 MB. ### Rationale Since BE only functions as a client to access HDFS, managing Java-side HDFS dependencies in FE is cleaner and more maintainable. If BE needs custom logic (e.g., optimized HDFS client), we can extend or override the relevant classes and control class loading order. Impact Build size reduced by ~150 MB Simpler dependency graph ### Notes Native/C++ HDFS dependencies remain managed under thirdparty. FE now provides necessary jars for BE at runtime. No need to modify existing C++ build logic. (cherry picked from commit 4ea473c)
Background
Previously, BE depended on the HDFS official distribution through the thirdparty module. This approach directly compiled and packaged Hadoop’s full dependencies, including large and unnecessary modules such as YARN, MapReduce, etc. As a result:
The build artifact contained many duplicate jars.
The total size was unnecessarily large (hundreds of MB).
BE only acted as an HDFS client, not a Hadoop runtime, so most of these dependencies were not needed.
Changes in this PR
Move all HDFS-related jars to FE for unified dependency management, since FE already uses HDFS extensively.
Retain necessary native/C++ dependencies under thirdparty for BE.
Do not build an uber-jar for HDFS (unlike other BE thirdparty libs).
Exclude unused Hadoop modules (e.g., YARN, MR, tools).
The resulting target structure now includes:
Compared with the previous build, the total artifact size has been reduced by ~150 MB.
Rationale
Since BE only functions as a client to access HDFS, managing Java-side HDFS dependencies in FE is cleaner and more maintainable. If BE needs custom logic (e.g., optimized HDFS client), we can extend or override the relevant classes and control class loading order.
Impact
Build size reduced by ~150 MB
Simpler dependency graph
Notes
Native/C++ HDFS dependencies remain managed under thirdparty.
FE now provides necessary jars for BE at runtime.
No need to modify existing C++ build logic.