Я вижу масштабирование луча apache с # из файлов CSV легко, но как насчет # строк в одном CSV?

Question

В настоящее время я читаю эту статью и документы apache beam https://medium.com/@mohamed.t.esmat/apache-beam-bites-10b8ded90d4c

Все, что я читал, касается N файлов. В нашем случае мы каждый раз получаем событие pubsub для ОДНОГО нового файла, чтобы начать работу. Мне не нужно масштабировать файл, так как я мог бы использовать для этого cloudrun. Мне нужно масштабировать с количеством строк в файлах. т.е. файл из 100 строк и файл из 100000000 строк, я хотел бы, чтобы они обрабатывались примерно за одно и то же время.

Если я последую приведенной выше статье и дам ему ОДИН файл вместо многих, за кулисами, как будет масштабироваться луч Apache. Как он узнает, что использовать 1 узел для 100 строк по сравнению с, возможно, 1000 узлов для файла 1000000 строк. В конце концов, он не знает, сколько строк в файле с самого начала.

Поток данных НЕ масштабируется с количеством строк в файле? Я думал, что, возможно, узел 1 будет читать строки 0-99, а узел 2 будет читать / отбрасывать 0-99, а затем читать 100-199.

Кто-нибудь знает, что происходит под капотом, чтобы я не тратил часы времени на тестирование, пытаясь выяснить, масштабируется ли оно по отношению к количеству строк в файле?

РЕДАКТИРОВАТЬ: Связанный вопрос, но не тот же вопрос - Как читать большой CSV с помощью Beam?

Я думаю, что поток данных может быть узким местом из-за чтения одного узла во всем файле, что я мог бы сделать только на обычном компьютере, НО мне действительно интересно, может ли это быть лучше, чем это.

Другой способ сказать это за кулисами, что на самом деле делает эта строка

      PCollection<String> leftInput = TextIO.read().from(“left.csv”)

Это может быть чтение 1 узла с последующей отправкой на группу других узлов, но есть явное узкое место, если есть только 1 считыватель csv, когда csv имеет размер bigdata.

Больше контекста о моих мыслях. Я действительно вижу коннектор «HadoopFileSystem» (хотя мы говорим с GCP Storage). Я предполагаю, что HadoopFileSystem работает на том факте, что HDFS имеет «файлы разделов», которые представляют файл, так что это уже N файлов. Мы используем облачное хранилище Google, поэтому это просто один файл csv, а не N файлов. В то время как соединитель HDFS может увеличивать количество узлов, равных разделам, TextIO видит только один файл csv, и все.

Answer 1

К счастью, мой коллега нашел это, в котором читается только одна строка

http://moi.vonos.net/cloud/beam-read-header/

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

Если у кого-то есть хороший пример разделения csv, это будет здорово, но мы можем попробовать создать свой собственный. в настоящее время кто-то читает весь файл.