Können Sie einen unsymmetrischen Spliterator unbekannter Größe neu ausbalancieren?

Ich möchte a verwenden, Streamum die Verarbeitung eines heterogenen Satzes von remote gespeicherten JSON-Dateien mit unbekannter Anzahl zu parallelisieren (die Anzahl der Dateien ist im Voraus nicht bekannt). Die Dateien können sehr unterschiedlich groß sein, von 1 JSON-Datensatz pro Datei bis zu 100.000 Datensätzen in einigen anderen Dateien. Ein JSON-Datensatz in diesem Fall ein in sich geschlossenes JSON-Objekt, das als eine Zeile in der Datei dargestellt wird.

Ich möchte wirklich Streams dafür verwenden und habe dies implementiert Spliterator:

public abstract class JsonStreamSpliterator<METADATA, RECORD> extends AbstractSpliterator<RECORD> {

    abstract protected JsonStreamSupport<METADATA> openInputStream(String path);

    abstract protected RECORD parse(METADATA metadata, Map<String, Object> json);

    private static final int ADDITIONAL_CHARACTERISTICS = Spliterator.IMMUTABLE | Spliterator.DISTINCT | Spliterator.NONNULL;
    private static final int MAX_BUFFER = 100;
    private final Iterator<String> paths;
    private JsonStreamSupport<METADATA> reader = null;

    public JsonStreamSpliterator(Iterator<String> paths) {
        this(Long.MAX_VALUE, ADDITIONAL_CHARACTERISTICS, paths);
    }

    private JsonStreamSpliterator(long est, int additionalCharacteristics, Iterator<String> paths) {
        super(est, additionalCharacteristics);
        this.paths = paths;
    }

    private JsonStreamSpliterator(long est, int additionalCharacteristics, Iterator<String> paths, String nextPath) {
        this(est, additionalCharacteristics, paths);
        open(nextPath);
    }

    @Override
    public boolean tryAdvance(Consumer<? super RECORD> action) {
        if(reader == null) {
            String path = takeNextPath();
            if(path != null) {
                open(path);
            }
            else {
                return false;
            }
        }
        Map<String, Object> json = reader.readJsonLine();
        if(json != null) {
            RECORD item = parse(reader.getMetadata(), json);
            action.accept(item);
            return true;
        }
        else {
            reader.close();
            reader = null;
            return tryAdvance(action);
        }
    }

    private void open(String path) {
        reader = openInputStream(path);
    }

    private String takeNextPath() {
        synchronized(paths) {
            if(paths.hasNext()) {
                return paths.next();
            }
        }
        return null;
    }

    @Override
    public Spliterator<RECORD> trySplit() {
        String nextPath = takeNextPath();
        if(nextPath != null) {
            return new JsonStreamSpliterator<METADATA,RECORD>(Long.MAX_VALUE, ADDITIONAL_CHARACTERISTICS, paths, nextPath) {
                @Override
                protected JsonStreamSupport<METADATA> openInputStream(String path) {
                    return JsonStreamSpliterator.this.openInputStream(path);
                }
                @Override
                protected RECORD parse(METADATA metaData, Map<String,Object> json) {
                    return JsonStreamSpliterator.this.parse(metaData, json);
                }
            };              
        }
        else {
            List<RECORD> records = new ArrayList<RECORD>();
            while(tryAdvance(records::add) && records.size() < MAX_BUFFER) {
                // loop
            }
            if(records.size() != 0) {
                return records.spliterator();
            }
            else {
                return null;
            }
        }
    }
}

Das Problem, das ich habe, ist, dass, während der Stream zunächst wunderbar parallelisiert, die größte Datei schließlich in einem einzigen Thread verarbeitet wird. Ich glaube, die proximale Ursache ist gut dokumentiert: Der Spliterator ist "unausgeglichen".

Genauer gesagt scheint die trySplitMethode nach einem bestimmten Punkt im Stream.forEachLebenszyklus des Systems nicht mehr aufgerufen zu werden , daher die zusätzliche Logik, kleine Stapel am Ende von zu verteilentrySplit selten ausgeführt wird.

Beachten Sie, dass alle von trySplit zurückgegebenen Spliteratoren denselben pathsIterator verwenden. Ich dachte, dies sei eine wirklich clevere Methode, um die Arbeit über alle Spliteratoren hinweg auszugleichen, aber es hat nicht ausgereicht, um eine vollständige Parallelität zu erreichen.

Ich möchte, dass die parallele Verarbeitung zuerst über Dateien hinweg erfolgt. Wenn dann nur noch wenige große Dateien splittert, möchte ich über Teile der verbleibenden Dateien parallelisieren. Das war die Absicht des elseBlocks am Ende vontrySplit .

Gibt es einen einfachen / einfachen / kanonischen Weg, um dieses Problem zu umgehen?

Sie trySplitsollten Splits gleicher Größe ausgeben, unabhängig von der Größe der zugrunde liegenden Dateien. Sie sollten alle Dateien als eine Einheit behandeln und den ArrayListSpliterator mit Unterstützung jedes Mal mit der gleichen Anzahl von JSON-Objekten füllen . Die Anzahl der Objekte sollte so sein, dass die Verarbeitung eines Splits zwischen 1 und 10 Millisekunden dauert: Unter 1 ms nähern Sie sich den Kosten für die Übergabe des Stapels an einen Arbeitsthread, die höher sind, und Sie riskieren aufgrund von eine ungleichmäßige CPU-Auslastung Aufgaben, die zu grobkörnig sind.

Der Spliterator ist nicht verpflichtet, eine Größenschätzung zu melden, und Sie tun dies bereits korrekt: Ihre Schätzung Long.MAX_VALUEist ein spezieller Wert, der "unbegrenzt" bedeutet. Wenn Sie jedoch viele Dateien mit einem einzelnen JSON-Objekt haben, was zu Stapeln der Größe 1 führt, kann dies Ihre Leistung auf zwei Arten beeinträchtigen: Der Aufwand für das Öffnen, Lesen und Schließen der Datei kann zu einem Engpass werden, und wenn Sie es schaffen, zu entkommen dass die Kosten für die Thread-Übergabe im Vergleich zu den Kosten für die Verarbeitung eines Elements erheblich sein können, was wiederum einen Engpass verursacht.

Vor fünf Jahren habe ich ein ähnliches Problem gelöst. Sie können sich meine Lösung ansehen .

Nach vielen Experimenten konnte ich immer noch keine zusätzliche Parallelität erzielen, indem ich mit den Größenschätzungen spielte. Grundsätzlich jeder andere Wert alsLong.MAX_VALUE dazu, dass der Spliterator zu früh (und ohne Aufteilung) beendet wird, während andererseits eine Long.MAX_VALUESchätzung dazu führt trySplit, dass sie unerbittlich aufgerufen wird, bis sie zurückkehrt null.

Die Lösung, die ich gefunden habe, besteht darin, die Ressourcen intern unter den Spliteratoren zu teilen und sie untereinander neu ausbalancieren zu lassen.

Arbeitscode:

public class AwsS3LineSpliterator<LINE> extends AbstractSpliterator<AwsS3LineInput<LINE>> {

    public final static class AwsS3LineInput<LINE> {
        final public S3ObjectSummary s3ObjectSummary;
        final public LINE lineItem;
        public AwsS3LineInput(S3ObjectSummary s3ObjectSummary, LINE lineItem) {
            this.s3ObjectSummary = s3ObjectSummary;
            this.lineItem = lineItem;
        }
    }

    private final class InputStreamHandler {
        final S3ObjectSummary file;
        final InputStream inputStream;
        InputStreamHandler(S3ObjectSummary file, InputStream is) {
            this.file = file;
            this.inputStream = is;
        }
    }

    private final Iterator<S3ObjectSummary> incomingFiles;

    private final Function<S3ObjectSummary, InputStream> fileOpener;

    private final Function<InputStream, LINE> lineReader;

    private final Deque<S3ObjectSummary> unopenedFiles;

    private final Deque<InputStreamHandler> openedFiles;

    private final Deque<AwsS3LineInput<LINE>> sharedBuffer;

    private final int maxBuffer;

    private AwsS3LineSpliterator(Iterator<S3ObjectSummary> incomingFiles, Function<S3ObjectSummary, InputStream> fileOpener,
            Function<InputStream, LINE> lineReader,
            Deque<S3ObjectSummary> unopenedFiles, Deque<InputStreamHandler> openedFiles, Deque<AwsS3LineInput<LINE>> sharedBuffer,
            int maxBuffer) {
        super(Long.MAX_VALUE, 0);
        this.incomingFiles = incomingFiles;
        this.fileOpener = fileOpener;
        this.lineReader = lineReader;
        this.unopenedFiles = unopenedFiles;
        this.openedFiles = openedFiles;
        this.sharedBuffer = sharedBuffer;
        this.maxBuffer = maxBuffer;
    }

    public AwsS3LineSpliterator(Iterator<S3ObjectSummary> incomingFiles, Function<S3ObjectSummary, InputStream> fileOpener, Function<InputStream, LINE> lineReader, int maxBuffer) {
        this(incomingFiles, fileOpener, lineReader, new ConcurrentLinkedDeque<>(), new ConcurrentLinkedDeque<>(), new ArrayDeque<>(maxBuffer), maxBuffer);
    }

    @Override
    public boolean tryAdvance(Consumer<? super AwsS3LineInput<LINE>> action) {
        AwsS3LineInput<LINE> lineInput;
        synchronized(sharedBuffer) {
            lineInput=sharedBuffer.poll();
        }
        if(lineInput != null) {
            action.accept(lineInput);
            return true;
        }
        InputStreamHandler handle = openedFiles.poll();
        if(handle == null) {
            S3ObjectSummary unopenedFile = unopenedFiles.poll();
            if(unopenedFile == null) {
                return false;
            }
            handle = new InputStreamHandler(unopenedFile, fileOpener.apply(unopenedFile));
        }
        for(int i=0; i < maxBuffer; ++i) {
            LINE line = lineReader.apply(handle.inputStream);
            if(line != null) {
                synchronized(sharedBuffer) {
                    sharedBuffer.add(new AwsS3LineInput<LINE>(handle.file, line));
                }
            }
            else {
                return tryAdvance(action);
            }
        }
        openedFiles.addFirst(handle);
        return tryAdvance(action);
    }

    @Override
    public Spliterator<AwsS3LineInput<LINE>> trySplit() {
        synchronized(incomingFiles) {
            if (incomingFiles.hasNext()) {
                unopenedFiles.add(incomingFiles.next());
                return new AwsS3LineSpliterator<LINE>(incomingFiles, fileOpener, lineReader, unopenedFiles, openedFiles, sharedBuffer, maxBuffer);
            } else {
                return null;
            }
        }
    }
}