Import von csv Dateien in duckdb und R

[bigben]

Die Frage ist, muss eine Tabelle erstellt werden?
Wie frage ich die Datenbank ab? [...] Bitte gebt mir einmal Starthilfe.

In https://cran.r-project.org/web/packages ... duckdb.pdf gibt es auf Seite 9 ein Beispiel

[Athomas]

Ich habe mal (ohne Ahnung zu haben ) etwas gefrickelt, damit was zum Anfassen da ist.
Der erste Teil brauch Dich nicht interessieren, der generiert nur Spielmaterial.

Danach ist dann - vermute ich zumindest stark - eine gefüllte duckdb-Datenbank vorhanden...
"Schnell" ist das aber auf keinen Fall, ich vermute, dass Du mit Deinem Terabyte Daten auf diese Weise nicht glücklich werden wirst!

Code: Alles auswählen

library(data.table)

#----------------- Simulation von Spielmaterial --------------------------------
Basisverzeichnis <- "P:/R Progis/duckdb"

Anfang <- strptime("01/01/2012 00:00:00.000", "%d/%m/%Y %H:%M:%OS")
Ende   <- strptime("01/01/2022 00:00:00.000", "%d/%m/%Y %H:%M:%OS")

test <- data.table(Timestamp = Anfang + runif(10*365*60*4)*(Ende - Anfang))
test[  , tdiff:=as.numeric(Timestamp - Anfang)]

test[  , ":="(Alpha=sin(2*pi*tdiff%%(  24*60)/(  24*60) + 0.27),
              Beta =cos(2*pi*tdiff%%(7*24*60)/(7*24*60) + 0.57))
]

test[  , tdiff:=NULL]
setorder(test, Timestamp)
#-------------------------------------------------------------------------------
test[  , Tag:=as.Date(Timestamp, tz="")]
List <- split(test, by="Tag", keep.by=FALSE)

sapply(names(List), function (x) fwrite(List[[x]], file=file.path(Basisverzeichnis, "Daten", paste0(x, ".csv"))))  # Verzeichnis Daten muss existieren
#--------------- Workspace wieder plattmachen ----------------------------------
rm(list = ls())
gc(); gc()
#---------------- Einlesen in duckdb--------------------------------------------

library(duckdb)

Basisverzeichnis <- "P:/R Progis/duckdb"

con <- dbConnect(duckdb(
  dbdir = file.path(Basisverzeichnis, "DBitself"),
  read_only = FALSE,
  bigint = "numeric",
  config = list()
))

Dateien <- list.files(path = file.path(Basisverzeichnis, "Daten"), pattern = "*.csv", full.names = TRUE) 

duckdb_read_csv(con, files=Dateien, tempfile(fileext = ".tmp"))

[bigben]

Der Claim von DuckDB, so habe ich das in Erinnerung, sind nicht schnelle Schreibzeiten sondern besonders schnelle Lesezugriffe für typische Datenanalyse-Schritte.

[bigben]

Hallo Athomas,

"Schnell" ist das aber auf keinen Fall, ich vermute, dass Du mit Deinem Terabyte Daten auf diese Weise nicht glücklich werden wirst!

Dann stelle ich mal die Frage, auf die Du anscheinend von Anfang an aus warst und die mich nicht praktisch, sondern nur aus Neugierde interessiert: Was ist denn aus Deiner Sicht der richtige Weg und das richtige Format, 1 Terabyte Messreihen zu verarbeiten? CSV wird es wohl nicht sein, oder?
Weil, wenn ich das Problem hätte, hätte ich auch eine SQL-Datenbank gedacht; und innerhalb der SQL-Datenbanken hätte ich wahrscheinlich auch DuckDB mit ganz oben auf der Liste gehabt.

Meine andere Frage lautet "Hä?" und zwar wegen dieses Code Snippets:

Code: Alles auswählen

gc(); gc()

Trivia: Bei der Suche bin ich auf StackOverflow auf ein spannendes Thema gestoßen, Dirk Eddelbüttel folgende Funktion vorschlägt:

Code: Alles auswählen

cleanMem <- function(n=10) { for (i in 1:n) gc() }

und im gleichen Thema Hadley Wickham schreibt, dass man gc nicht aufrufen soll. Leider bieten beide befriedigende Begründung für eines von beidem.

LG,
Bernhard

[Athomas]

Was ist denn aus Deiner Sicht der richtige Weg und das richtige Format, 1 Terabyte Messreihen zu verarbeiten? CSV wird es wohl nicht sein, oder?

Dank "fread" würde ich nicht prinzipiell "Nein" zu CSV sagen - aber das ist sicherlich abhängig davon, was man machen möchte!

Um den Mittelwert einer Variable zu bilden oder die hundert größten Werte (aus einer moderaten Zahl großer Dateien) herauszusuchen ist wohl keine Datenbank nötig - und dass deren Verwendung diese einfache Berechnungen beschleunigt, kann ich auch nicht glauben.

Meine andere Frage lautet "Hä?" und zwar wegen dieses Code Snippets:

Das ist eine rituelle Formel, die ich seit meiner R-Frühzeit in Verbindung mit rm(list = ls()) verwende, wenn ich den Workspace in einen möglichst jungmenschlichen (korrekt gegendert?) Zustand versetzen will - ohne R komplett zu schließen und neu zu öffnen. Damals hatte ich irgendwo gelesen, dass doppelt besser hält...

[bigben]

Dank "fread" würde ich nicht prinzipiell "Nein" zu CSV sagen

Ich weiß, dass Du ein großer Fan von fread bist aber ich weiß nicht, wie fread sich verhält, wenn die Daten gar nicht mehr in den RAM passen. 1 TB in CSV wird sehr viel weniger als 1 TB in einem Zahlenformat sein aber die meisten von uns bemessen ihren RAM ja eher in GB.

Um den Mittelwert einer Variable zu bilden oder die hundert größten Werte (aus einer moderaten Zahl großer Dateien) herauszusuchen ist wohl keine Datenbank nötig - und dass deren Verwendung diese einfache Berechnungen beschleunigt, kann ich auch nicht glauben.

Ist bestimmt von vielen Faktoren abhängig. Ich habe in einem Interview mal gehört, dass DuckDB die Daten nicht zeilenweise sondern spaltenweise ablegt, weil man in der Datenanalyse eher spaltenweise Berechnungen ausführt (wie eben Mittelwert und die hundert größten Werte und Filtern nach Spalten). So etwas könnte natürlich schon viel Zeit beim Einlesen langer CSV kosten aber zugleich einen strategischen Vorteil bringen.
Ich würde vermuten, dass die SQL-Datenbank ihre Vorteile dann ausspielen kann, wenn es wirklich um die Verknüpfungen zwischen verschiedenen Tabellen geht bzw. dass sie darauf besonders optimiert sind.

wenn ich den Workspace in einen möglichst jungmenschlichen (korrekt gegendert?)

Mir persönlich wäre das jetzt entschieden zu speziesistisch, aber da kannst Du ja vielleicht nochmal in Dich gehen.

Viele Grüße,
Bernhard

[Athomas]

Ich weiß, dass Du ein großer Fan von fread bist aber ich weiß nicht, wie fread sich verhält, wenn die Daten gar nicht mehr in den RAM passen.

Dann geht gar nichts mehr, die Daten für data.table müssen schon (locker) in den RAM passen. Deshalb habe ich ja auch die portionsweise Verarbeitung angeregt, die auch nur bei speziellen Aufgaben einfach durchführbar ist - der Mittelwert gehört aber sicherlich dazu...

1 TB in CSV wird sehr viel weniger als 1 TB in einem Zahlenformat sein aber die meisten von uns bemessen ihren RAM ja eher in GB.

Das habe ich nicht verstanden!?

Ich glaube inzwischen, dass der Knackpunkt in Bezug auf die Performance des vorliegenden Problemchens (in jeder Herangehensweise) die Frage ist, ob der "Zeitstempel" wirklich in ein Datum konvertiert werden muss oder lediglich als Textlabel für bestimmte Messwerte mitgeschleppt werden kann.

[bigben]

Deshalb habe ich ja auch die portionsweise Verarbeitung angeregt, die auch nur bei speziellen Aufgaben einfach durchführbar ist - der Mittelwert gehört aber sicherlich dazu...

Ok, portionsweise Verarbeitung muss ja die Antwort sein, egal wie. Rechnen kann das DBMS ja auch nur im RAM und nicht auf der Platte. Einen Mittelwert aus Teilmengen zu berechnen wird leichter sein als beispielsweise einen Median. Man müsste halt alle gestellten Teilaufgaben durchgehen mit der Frage, ob der Algorithmus zum Berechnen aus Teilmengen banal ist und selbst gefunden werden kann oder ob darunter komplexe Fragen sind, die man lieber nicht selbst programmiert, sondern sich freut, wenn ein schlauer Mensch schon darüber nachgedacht und etwas optimiert hat.

Das habe ich nicht verstanden!?

Nun, beispielsweise ist die Timestamp im CSV als String mit 24 Zeichen hinterlegt. Also mindestens 24 Byte. Als Zahl passt so ein Timestamp aber bestimmt in eine 64 Bit Zahl. Die Zahl 0.83987 braucht in CSV sieben Bytes, kann im RAM aber als einfaches float repräsentiert werden. Die Kommas im CSV braucht ein data.table gar nicht und so weiter. Kleine Einsparung pro Zeile mal sehr, sehr viele Zeilen. Wenn ich also eine von fünf 200GB Dateien in den RAM lese und dabei das Datum konvertiere, dann wird das im RAM hoffentlich weniger als 200GB brauchen. Wenn ich wirklich den gesamten Datensatz in den RAM lesen wollte, bräuchte ich hoffentlich weniger als 1 TB freien RAM. Ich wollte also nur anerkennen, dass man weniger als 1 TB RAM bräuchte, aber der Einspareffekt wäre niemals so groß, dass man das in ein paar GB unterbringen kann. Das Problem löst sich also nicht deshalb auf, weil man für 200GB CSV weniger als 200GB im RAM braucht.

Ich glaube inzwischen, dass der Knackpunkt in Bezug auf die Performance des vorliegenden Problemchens (in jeder Herangehensweise) die Frage ist, ob der "Zeitstempel" wirklich in ein Datum konvertiert werden muss oder lediglich als Textlabel für bestimmte Messwerte mitgeschleppt werden kann.

Ich weiß nicht, ob diese Konvertierung wirklich so ein großer Performance-Fresser wäre, aber in jedem Fall hast Du soweit Recht, dass man über die 15 Einzelaufgaben im Detail nachdenken muss und das nicht beantworten kann, solange die nicht benannt sind.

So, jetzt gibt es Pizza. Schönen Abend,
Bernhard

[Athomas]

Ich habe mir den Thread (und verwandte ) nochmal komplett angeguckt und möchte klarstellen: wenn die Einrichtung und das Handling einer Datenbank sowie die Performance kein Problem darstellen, ist ihre Verwendung hier sicherlich der bessere Weg.

Meine Vorschläge sind als "Notlösung" bei Performance-Problemen gedacht!

[bigben]

Meine Vorschläge sind als "Notlösung" bei Performance-Problemen gedacht!

In diesem Zusammenhang fand ich diesen Vortrag auf Youtube interessant. Der Vortragende war früher für Google mit dem Google-Tool BigQuery für wirklich große Datenmengen beschäftigt und sagt: "The thing that I rapidly realized was that, you know, none of our customers are acutally running queries like this. [...] A lot of our BigQuery customers don't actually use big data."
Das ist ganz sicher kein Plädoyer gegen Datenbanken und sicher nicht gegen DuckDB. Der Titel "Big Data ist Dead" passt sicher nur für jemanden, der BigData als etwas betrachtet, dass auch für Google "Big" ist. Trotzdem ist es spannend zu hören, wie auch in seiner Kategorie sich der Hype nicht wirklich manifestiert hat.

Der Link: https://youtu.be/lisIQ9ohU8g?si=yYND9yXtbn3FDOod