Database für Data Science & Analytics

Hey,

wir suchen für die Arbeit eine Lösung, wo wir zentral und komfortabel unsere Daten lagern können, um damit zu arbeiten.

Erst einmal paar Infos:
- Kein Production Server (worauf Kunden Zugriff hätten) oder ähnliches.
- Keine Cloud Lösung
- Soll für Data Science (aktuell 3 Leute) und Business Intelligence (3-5 Leute) genutzt werden
- Data Science arbeitet mit Python, Business Intelligence mit Tools wie Power BI
- Daten sind z.B. Nutzerprofile, Unternehmensdaten, gescrapte Daten, interne Trackingdaten aus unterschiedlichen Prozessen etc. (kein Video, Bild, Audio, Word, pdfs oder ähnliches)
- Datenmenge insg. ist aktuell < 1TB.
- Kein realtime analytics, alles batch processing
- Ein batch an Daten, mit dem gleichzeitig gearbeitet wird, beläuft sich aktuell im worst case auf ca. 10-15GB. Könnte jedoch in Zukunft etwas ansteigen. Aber Geschichten wie 100GB+ wird es in naher Zukunft auf jeden Fall nicht geben.
- Eine Art Frontend, wo einfache Sachen auch dort an- und nachgeschaut + visualisiert werden können (Graphen etc.), wäre nett.


Aktuell holen wir uns von unseren Production Servern immer einen json-Export zum Arbeiten, was aber nervig ist, weil es doch sehr unorganisiert ist. Diese dumps werden dann hin und her geschoben, was wir in Zukunft vermeiden wollen. Stattdessen wollen wir einen zentralen Datastorage haben, wo alle für uns relevanten Daten liegen.

Ich vermute, das hierfür ein vernünftiger Rechner (darf gerne auch z.B. ein Threadripper mit 64GB+ Ram sein, wenns nötig ist) im Netzwerk mit einer Datenbank ausreichend sein sollte. Bin für Inspirationen offen
Geschichten wie Spark, Hadoop, Yarn etc. sind sehr sicher overkill.
Konkret: Wie wärs z.B. mit MongoDB hierfür?

In der letzten Firma wurde dafür einfach eine Postgress verwendet. Jetzt sinds in einer Oracle DB da auch deren BI Produkt verwendet wird

Zitat aus einem Post von Crash Override

Wie liegen die Daten vor?

Afaik ausschließlich in Datenbanken. Elasticsearch, MongoDB, MySQL, Redis und Memcached. Wir bekommen daraus json-Exports, dh aktuell liegen die Daten in json vor. ABER es sollen nicht die (zum Teil auch schon nicht mehr up2date) dumps importiert werden.

Zitat aus einem Post von Crash Override

Wie kommen die Daten rein?

Steht noch nicht fest und wir sind da flexibel. Am einfachsten wäre wohl ein Import von unseren existierenden Datenbanken, wobei regelmäßig (vllt 1x die Woche?) neue Daten hinzukommen. Aber die Daten werden teilweise (abhängig von den Daten) sicherlich eine Transformation benötigen, da uns z.B. nicht alle Felder aus Datensätzen interessieren und wir die dementsprechend nicht in unserem Datastorage haben wollen.

Zitat aus einem Post von Crash Override

Was für eine Datenbank wird für Produktion genutzt?

Elasticsearch, MongoDB, MySQL, Redis und Memcached. Aber was für Datenbanken wir für Production verwenden soll nicht wirklich die Wahl für unser Datastorage beeinflussen, da auch die Anforderungen anders sind.

Zitat aus einem Post von Crash Override

Bei relationalen Daten sind auch relationale Datenbanken ganz weit vorne. Wenn du allerdings einen Haufen JSONs verwalten willst die Teilweise ähnlichen Inhalten ist MongoDB das Mittel der Wahl. wenn du beides benötigst kannst du dir mal MariaDB AX ansehen.

jsons verwalten wollen wir nicht, heißt eine relationale Datenbank wäre wohl angebracht. Die Daten, die wir haben, sind nicht sonderlich komplex und locker im Tabellenformat darstellbar.
MongoDB bietet z.B. MongoDB Charts an, was praktisch aussieht, gerade für unsere BI-Fraktion, die kein SQL/Python etc. können und ein UI benötigen. Es ist halt keine relationale Datenbank, was prinzipiell aber nicht schlimm ist, solange die Performance passt.

MariaDB AX sieht z.B. schon interessant aus, muss ich mir aber bei Gelegenheit genauer anschauen


edit: Datenbanken aktualisiert.

Habe mal noch einmal mit meinem Kollegen gesprochen, der sich um die Production Server kümmert: Die Rohdaten sind wohl viel zu inhomogen, weshalb eine relationale Datenbank wohl nicht optimal ist
D.h. Datenbank muss gut mit JSONs umgehen. MongoDB mit besserer Suchperformance (besonders für die Kollegen mit BI-Tools) wäre ideal. Paar Minuten warten, bis der Query ausgeführt ist, soll nicht vorkommen.

MariaDB AX hat ihm als Vorschlag auch ganz gut gefallen, wobei wir schauen müssten, wie gut das mit JSONs klappt.

Postgresql eignet sich auch für json daten.
Der Guardian ist von mongodb auf postgresql gewechselt: https://www.theguardian.com/info/20...-hello-postgres

Das jsonb column type unterstützt indexing, queries und joins.

https://www.postgresql.org/docs/9.5/functions-json.html

Der Thread soll einfach zur Inspiration dienen und dafür ist so ein Thread imho auch okay. Ich selbst kenne mich viel zu wenig aus und werde es auch nicht umsetzen, das machen die Leute aus unserem Production Team, die sich auch um all unsere Datenbanken kümmern.

Im Endeffekt wurde hier auch nicht so vieles erwähnt, was uns nicht bekannt wäre, wobei wir bisher nicht an MariaDB AX gedacht haben - danke hierfür!

Im Idealfall wäre das so ja. Die Realität sieht wie so oft leider anders aus
Ganz ehrlich: Für Data Science ist relativ egal, was für eine Datenbank wir anzapfen. Solange die Performance passt juckt uns das ehrlich gesagt kaum. Aber klar, es gibt sicher Lösungen, wo es komfortabler ist als bei anderen. BI ist z.B. nicht so flexibel, da sollten ihre Tools mitspielen, was aber in der Regel gegeben ist, wenn man die üblichen Verdächtigen als Lösungen verwendet. Von daher wird COLOSSUS mit seiner Aussage, das unser Vorhaben mit wohl allen Vorschlägen umsetzbar ist, Recht haben.

Es wird sich intern eh noch zusammengesetzt und alle Optionen besprochen, so ists nicht. Aktuell sind wir so in der Recherche- und Brainstorm-Phase.

Zitat aus einem Post von Gex

Beim BI-Anwendungsfall schreibst du oben:
"- Kein realtime analytics, alles batch processing"
und weiter unten:
"Paar Minuten warten, bis der Query ausgeführt ist, soll nicht vorkommen."

Also doch Ad-hoc Analysen?

Also einfach mal in der Datenbank nach etwas schauen (z.B. alle Einträge wo x > 5) sollte performant möglich sein. Wenn man sich dann z.B. noch die Frequency oder Ähnliches grafisch darstellen lassen kann, wärs perfekt. Mehr aber auch nicht. Alle anderen Analysen sind zu komplex und passieren nicht in realtime. Ich weiß, dass meine Aussage da etwas widersprüchlich ist, sorry

Zitat aus einem Post von Gex

Für klassisches BI wäre ja eine relationale Datenbank mit Column-Store-Engine immer noch vernünftig. Dort z.B. mal Pivotal Greenplum (Postgres-Basis) oder auch Vertica (auch Postgres-Basis, aber nur bis 1TB/3 Nodes kostenlos) angeschaut?
Ob solche Produkte dann für eure Data Scientists wirklich die richtige Plattform sind, kA...

Ich schau es mir mal an, vielen Dank auf jeden Fall für die Vorschläge. Kannte sie persönlich bisher nicht.

Zitat aus einem Post von Gex

Habt ihr schon mal in Richtung Hadoop/Hive/Spark überlegt? Ist halt ein riesiger Stack, der erst mal beherrscht werden will. Und bei der Performance eher nichts für Ad-Hoc Analytics. Dafür ziemlich universell einsetzbar.

Ich kenne das alles oberflächlich, könnte es aber unmöglich verwalten. Dafür würde uns auch sehr sicher das know-how fehlen. Ich habe es bisher immer verworfen, weil es (zumindest meine Überzeugung) einfach Overkill ist. Ich bin bisher immer davon ausgegangen, dass sich das ganze nur lohnt, wenn du wirklich schon an das Limit einer Maschine kommst was die Datenmengen und deren Verarbeitung angeht (sei es RAM/CPU oder HDD). Davon sind wir noch sehr weit entfernt.