shnapz commented on code in PR #37265:
URL: https://github.com/apache/beam/pull/37265#discussion_r3131587007
##########
sdks/java/core/src/main/java/org/apache/beam/sdk/io/FileBasedSource.java:
##########
@@ -318,35 +317,10 @@ public final List<? extends FileBasedSource<T>> split(
}
}
- /**
- * Report source Lineage. Due to the size limit of Beam metrics, report full
file name or only dir
- * depend on the number of files.
- *
- * <p>- Number of files<=100, report full file paths;
- *
- * <p>- Number of directory<=100, report directory names (one level up);
- *
- * <p>- Otherwise, report top level only.
- */
private static void reportSourceLineage(List<Metadata> expandedFiles) {
- if (expandedFiles.size() <= 100) {
- for (Metadata metadata : expandedFiles) {
- FileSystems.reportSourceLineage(metadata.resourceId());
- }
- } else {
- HashSet<ResourceId> uniqueDirs = new HashSet<>();
- for (Metadata metadata : expandedFiles) {
- ResourceId dir = metadata.resourceId().getCurrentDirectory();
- uniqueDirs.add(dir);
- if (uniqueDirs.size() > 100) {
- FileSystems.reportSourceLineage(dir, LineageLevel.TOP_LEVEL);
- return;
- }
- }
- for (ResourceId uniqueDir : uniqueDirs) {
- FileSystems.reportSourceLineage(uniqueDir);
- }
- }
+ List<ResourceId> resourceIds =
Review Comment:
Is the concern whether to commit to a new public API? I took a second look
and wanted to propose an alternative before reverting the move:
I've marked the method @Internal with a "for internal use only by
Beam-provided file-based connectors; not a stable public API" note in the
javadoc. FileSystems already uses this same pattern for
setDefaultPipelineOptions and registerFileSystemsOnce, so there's precedent for
@Internal public static helpers living here
The reason I prefer FileSystems over making it public on FileBasedSource:
HadoopFormatIO isn't a FileBasedSource (it's a generic InputFormat wrapper that
only sometimes produces file splits) so reaching into FileBasedSource as a
utility namespace feels off. FileSystems is already the shared home for lineage
reporting, it has three other reportSourceLineage overloads and this logic is
applicable to any file-producing connector, not just subclasses of
FileBasedSource.
Iam happy to revert to the FileBasedSource approach if you still prefer it.
Just wanted tofloat this as an option first
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
