Database für Data Science & Analytics
URL: https://www.overclockers.at/storage-memory/database-fuer-data-science-analytics_253012/page_1 - zur Vollversion wechseln!
Denne schrieb am 26.01.2019 um 13:01
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?
pinkey schrieb am 26.01.2019 um 13:34
Bin mal sehr auf die Empfehlungen gespannt, bei uns ist relativ ähnlich von den Anforderungen und Softwarestack nur das derzeit weniger Leute damit arbeiten, was sich in nächster Zeit aber recht sicher ändern wird.
Viper780 schrieb am 26.01.2019 um 14:06
In der letzten Firma wurde dafür einfach eine Postgress verwendet. Jetzt sinds in einer Oracle DB da auch deren BI Produkt verwendet wird
Crash Override schrieb am 26.01.2019 um 14:58
Wie liegen die Daten vor?
Wie kommen die Daten rein?
Was für eine Datenbank wird für Produktion genutzt?
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.
Denne schrieb am 26.01.2019 um 15:29
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.
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.
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.
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.
Crash Override schrieb am 26.01.2019 um 15:52
Relationale Daten willst du nicht mit MongoDB verarbeiten. Das passt nicht zusammen.
MariaDB/MySQL könntest du als Slave an die Produktionsserver mit MySQL hängen und mit Replikationsfiltern und Triggern (Ab MariaDB 10.1 funktionieren Trigger in der Replikation) die Daten aufbereiten.
Denne schrieb am 26.01.2019 um 15:59
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.
Snoop schrieb am 26.01.2019 um 16:11
Palo von jedox könnte hier hilfreich sein. Hab damit mal vor (hmm ich glaub inzwischen) 7 jahren auf der FH gearbeitet. Die hatten damals schon ziemlich coole connectoren auch zu Excel womit jeder sich seine daten rausziehen konnte
Aber kA, ob die Lösung heute noch immer so genial ist. Auf der Homepage steht zumindest, dass es mal mit MongoDB Mysql etc connecten kann und sich die Daten ziehen kann. Von daher dürfte der Sprung zu Redis Elastics und memcached ned wirklich weit entfernt sein, bzw. vermutlich eh auch vorhanden sein
stream schrieb am 26.01.2019 um 16:27
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
COLOSSUS schrieb am 26.01.2019 um 18:20
Der Thread ist imo recht sinnlos. Ihr arbeitet momentan mit ad-hoc in JSON serialisierten Dateien - das bedeutet: Eine ertragbare Loesung fuer dein Problem wird man in jeder der hier erwaehnten (bzw. wild herumgeworfenen) Technologien hinkriegen.
Die richtige Technologie fuer euch ist die, mit der genuegend Leute in eurem Team Erfahrung haben, um ausreichend Flexibilitaet/"Agilitaet" bei der Umsetzung und die ueblicherweise gewuenschten Charaktertistika im Betrieb (z. B. Verfuegbarkeit) zu gewaehrleisten. Wenn ihr mit keiner tauglichen Technologie Erfahrung habt, solltet ihr vermutlich einen Consultant ins Boot holen - und in diesem "Vakuum" wuerde ich Postgres (schreibt sich mit nur einem "s") nehmen. Bei https://www.cybertec-postgresql.com/de/ kann man euch da z. B. helfen.
Denne schrieb am 27.01.2019 um 11:36
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!
Obermotz schrieb am 27.01.2019 um 11:47
Ich hätte jetzt eigentlich auch erwartet, dass die Data Science & BI Guys ihre Wunschlösung eigentlich selbst kennen sollten. Oft bevorzugt man die Tools, mit denen man lernt, da sollte man auf einen Konsens kommen können.
Denne schrieb am 27.01.2019 um 13:33
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.
Gex schrieb am 27.01.2019 um 13:37
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?
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...
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.
Denne schrieb am 27.01.2019 um 14:33
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 
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.
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.
overclockers.at v4.thecommunity
© all rights reserved by overclockers.at 2000-2025