Clojure/Java: наиболее эффективный метод минимизации потребления полосы пропускания при выполнении сложных операций над потоком данных Amazon S3

Question

Я выполняю потоковое считывание объекта с использованием BufferedReader.

мне нужно сделать две вещи с этим объектом:

1. передать его читателю SuperCSV Csv
2. Получить исходные линии и держать их в (Clojure) ленивым последовательность

В настоящее время мне приходится использовать два разных BufferedReaders: один в качестве аргумента для класса чтения SuperCSV CSV и один для инициализации ленивой последовательности исходных строк. Я эффективно загружаю объект S3 дважды, что дорого ($) и медленный.

Один из моих коллег указал, что что-то похожее на команду «tee» Unix - это то, что я ищу. BufferedReader, который можно каким-то образом «разбить», загрузить фрагмент данных и передать копию как для ленивой последовательности, так и для функции чтения csv.

Я также изучаю, можно ли обернуть ленивую последовательность в BufferedReader и передать , что в супер csv. У меня было несколько проблем с кучей Java, когда передавали очень большие ленивые последовательности нескольким потребителям, поэтому я немного обеспокоен использованием этого решения.

Другое решение просто загружает файл локально, а затем открывает два потока в этом файле. Это устраняет оригинальную мотивацию потоковой передачи: позволяет начать работу с файлом, как только начнутся данные.

Окончательное решение, которое я бы рассматривал только в том случае, если ничего не работает, реализует мой собственный CSV-ридер, который возвращает как проанализированный CSV, так и оригинальную непараметрированную строку. Если вы использовали очень прочный CSV-ридер, который может возвращать как Java-Hash проанализированных CSV-данных, так и оригинальную строку без ссылок, пожалуйста, дайте мне знать!

Спасибо!

Answer 1

Решение было использовать один BufferedReader для всех заходов, а затем сбросить() Ing это каждый раз, когда он передается в функциональности, которая должна читать с самого начала.

Answer 2

Я был бы склонен идти с созданием seq линий из сети, а затем передать это, несмотря на то, что многие процессы должны работать над этим seq; Таким образом, устойчивые структуры данных выглядят здорово. В случае необходимости превратить SEQ строк в считыватель, который можно передать от АНИ SuperCSV, это похоже на работу:

 
(import '[java.io Reader StringReader]) 

(defn concat-reader 
    "Returns a Reader that reads from a sequence of strings." 
    [lines] 
    (let [srs (atom (map #(StringReader. %) lines))] 
    (proxy [Reader] [] 
     (read 
     ([] 
      (let [c (.read (first @srs))] 
      (if (and (neg? c) (swap! srs next)) 
       (.read this) 
       c))) 
     ([cbuf] 
      (.read this cbuf 0 (count cbuf))) 
     ([cbuf off len] 
      (let [actual (.read (first @srs) cbuf off len)] 
      (if (and (neg? actual) (swap! srs next)) 
       (.read this cbuf off len) 
       actual)))) 
     (close [])))) 

Э.Г.

 
user=> (def r (concat-reader ["foo" "bar"])) 
#'user/r 
user=> (def cbuf (char-array 2)) 
#'user/cbuf 
user=> (.read r cbuf) 
2 
user=> (seq cbuf) 
(\f \o) 
user=> (char (.read r)) 
\o 
user=> (char (.read r)) 
\b