Hallo Aaron,
das verstehe ich wieder nicht. Wenn das alles auch in SQL funktioniert, ist es bestimmt am wenigsten Aufwand, es in SQL zu machen. Wie schon beschrieben, entweder passen die ganzen Daten in den RAM (A) oder man muss immer Teile davon in den RAM laden und dort verarbeiten (B). (A) scheint derzeit nicht erreichbar (man kann bestimmt bei AWS einen Server mit dem entsprechenden RAM mieten). Also (B). Du kannst beispielsweise duckdb sagen, dass Du nur die Daten vom 1. Januar bis 15 Januar in den RAM laden willst. Die passen dann vielleicht in den RAM wo Du sie in R verarbeiten kannst. Dann muss Du das halt immer wieder für mehrere Zeitabschnitte wiederholen. Warum Du Dir diese Mühe machen solltest, wenn es auch in SQL geht, weiß ich nicht. Schneller ist es wahrscheinlich, je weniger R Code darin vorkommt. Oder Du verwendest vorgefertigte Software, die Dir die Orchestrierung abnimmt, die Du dann aber erst erlernen musst. duckdb wäre solche vorgefertigte Software und von allen die, die sich für Dich besonders anbietet, weil Du damit jetzt schon soweit bist. Es gibt bestimmt auch andere Hilfsmittel, die man in R hinzuziehen kann, beispielsweise
arrow, wenn Du lieber dply- als SQL-Syntax benutzen möchtest. Die Annahme, dass dplyr leichter zu lernen wäre als SQL würde ich jetzt so nicht treffen. Dass Du jetzt gelerntes SQL auch in zwanzig Jahren noch brauchen kannst erscheint mir wahrscheinlich er als bei dplyr. YMMV.
LG,
Bernhard
), mit jeweils 10 Mio Sätzen (pro Datei ~560MB) in eine einzelne DuckDB-Datei eingelesen. 
!