Warum Baumstruktur

Für Dateiverzeichnisse (Filesysteme) hat sich eine Baumstruktur etabliert. Wir haben uns daran gewöhnt und für die meisten Zwecke ist das auch eine sinnvolle Strukturierung.

Relativ oft wird man aber mit dem Problem konfrontiert, daß es zwei oder mehr Aspekte gibt, nach denen man seine Dateien oder Unterverzeichnisse gruppieren will. Machen wir es mal abstrakt mit Farbe, Form und Größe.

Dann kann man etwa so etwas haben wie

$MAINDIR/rot
$MAINDIR/blau
$MAINDIR/gruen
$MAINDIR/gelb

und in der nächsten Ebene dann jeweils so etwas wie

$MAINDIR/rot/quadrat
$MAINDIR/rot/kreis
$MAINDIR/rot/dreieck
$MAINDIR/rot/sechseck
$MAINDIR/blau/quadrat
$MAINDIR/blau/kreis
...
$MAINDIR/gelb/dreieck
$MAINDIR/gelb/sechseck

und darunter jeweils

.../klein
.../mittel
.../gross

Aber manchmal möchte man es genau anders haben haben, also zuerst nach Form differenzieren, dann nach Größe und zuletzt nach Farbe.
Und es kann oft sehr unpraktisch sein, wenn Dinge, die eigentlich zusammengehören und die man zusammen bearbeiten will, verstreut über das Verzeichnissystem herumliegen.

Es hilft sicher, daß man sich vorher gut überlegt, wie man seine Verzeichnisstruktur aufbaut, so daß es zumindest in möglichst vielen Situationen einigermaßen paßt. Es gibt sicher Möglichkeiten, damit umzugehen. Man könnte zum Beispiel alle sechs Verzeichnisbäume anlegen und via Hardlinks oder Softlinks die Dateien, die man im ersten Verzeichnisbaum richtig eingetragen hat, von den anderen Verzeichnisbäumen jeweils passend verlinken (Softlink) oder dort auch eintragen (Hardlink). Das geht unter Linux und Unix mit deren eigenen Dateisystemen gut, es kann aber eine Herausforderung sein, das konsistent zu halten.

Man kann auch die Daten auf Dateisystemebene irgendwie ablegen, vielleicht sogar in einer der möglichen Strukturierungen, aber den Zugriff über eine Applikation anbieten, die es ermöglicht, so darauf zuzugreifen, als wären sie in einer der anderen fünf Arten strukturiert. Ein typisches Beispiel sind Musikprogramme (Player), die es ermöglichen, die Musikstücke nach Genre, Sänger, und vielen anderen Kriterien zu strukturieren und dann mit diesen Daten darauf zuzugreifen. Es gibt dann typischerweise irgendwo Metadaten, die diese Zusatzinformationen enthalten. Hier hat man noch den Zugriff über das Dateisystem, was sehr praktisch ist, gerade bei Musik, aber die Applikation muß Änderungen erkennen und gegebenenfalls die Metadaten anpassen oder sogar interaktiv abfragen und ergänzen.

Noch weiter geht es, wenn die Datenspeicherung völlig intransparent ist, im Extremfall sogar unter Benutzung sogenannter „Raw-Devices“, und wenn man dann nur noch über so eine Applikation an die Daten herankommt. Im Grunde genommen sind alle Datenbanken in dieser Rubrik angesiedelt, aber auch die Repositories vieler Versionsverwaltungssysteme oder auch Content-Management-Systeme, die natürlich wiederum eine Datenbank verwenden können. Eine Folge davon ist, daß man an diese Daten nur noch mit der Applikation oder deren Hilfsprogrammen herankommt und nicht mehr wirklich auf Dateisystemebene damit arbeiten kann. Eine kleine Anzahl von Datenbankprodukten und das zugehörige Knowhow leistet man sich gerne, denn das braucht man und es lohnt sich. Aber wenn jetzt Software unnötigerweise ihr eigenes Repository-Format statt einer einfachen Dateispeicherung verwendet, kann es schon schwieriger werden, die ganzen Daten im Griff zu behalten.

Das Problem ist also in der Praxis dort, wo es eine große Rolle spielt, häufig irgendwie gelöst. Trotzdem wäre es manchmal schön, wenn die Verzeichnisstruktur nicht wie ein Verzeichnisbaum aufgebaut wäre, sondern zumindst in manchen Teilbäumen wie ein dünn besetzter Hyperquader, wo man nach einer Reihe von Kriterien die passenden Dateien suchen und in einem temporären virtuellen Verzeichnisbaum zugänglich machen könnte. Diese Mehrfachindizierung war übrigens auch in Datenbanken vor etwa 30 Jahren eine Herausforderung, wenn die einzelnen Indizes für sich genommen nicht selektiv genug sind. Man hat wohl das Konzept des Z-Index (oder der Z-Kurve) entwickelt, womit eine Verflechtung von verschiedenen Indizes möglich ist, die für sich genommen nicht selektiv genug sind, um für einen bestimmten Indexwert nur noch eine so kleine Menge von Daten zurückzuliefern, daß eine erschöpfende Suche in diesen Daten unproblematisch wäre.

In der Systemadministration stellt sich diese Frage häufig. In der Linux- und Unix-Welt ist es üblich, größere Applikationen so zu installieren, daß etwa 4-6 Orte im Verzeichnissystem verwendet werden:

  • ausführbare Programme in /usr/bin oder /usr/local/bin oder /bin o.ä.
  • Bibliotheken und statische Hilfsdaten dazu in /usr/lib oder /usr/local/lib oder /opt. Zum Teil architekturunabhängige statische Hilfsdaten und Bibliothken auch in /usr/share. Oft ist die ganze Applikation unter /opt installiert und es gibt softlinks nach /usr/local/bin
  • Man-Seiten unter /usr/man, /usr/local/man, /opt/man o.ä.
  • Konfiguration unter /etc
  • Variable Daten (z.B. Tablespaces für Datenbanken) unter /var/lib, /var/opt o.ä.
  • logs unter /var/log

Das ist das, was sich eigentlich etabliert hat und wie die Software, die mit Linux-Distributionen mitkommt, üblicherweise installiert wird. Man hat so nicht die ganze Applikation zusammen in einem Verzeichnis, aber dafür hat man eine Trennung in statische und dynamische Daten und kann auf Servern viel gezielter Entscheidungen darüber treffen, welche Daten in welches Backup kommen, welche Raid-Konfiguration man verwendet, ob man die Daten lokal oder remote hält, ob man sie mit anderen Servern teilen kann und ob man SSDs einsetzt oder auch wer Schreib- und Leseberechtigungen hat. Diese Fragen wird man eher für alle Daten in /var/lib gleich beantworten als für alle Daten unter /tomcat.
So wird die zweitbeste Vorgehensweise, eben alles, was zu einer Applikation gehört, komplett in einem Unterverzeichnis zu halten, trotz ihrer offensichtlichen Reize, eher selten gewählt. Hier wäre so eine Matrixstruktur für das Dateisystem schön, man könnte also Zeilen für die Applikationen haben und Spalten für die Art der Daten (lib, bin, share, var, log, conf, man,…).

Share Button

Festplatten zur Erdbebenmessung

Auch wenn SSDs immer mehr Verwendung finden, sind magnetische (mechanische) Festplatten weiterhin verbreitet und werden es wohl auch noch lange bleiben.

Diese mechanischen Festplatten enthalten Sensoren, mit denen man Erschütterungen erkennen kann, zum Beispiel um den Kopf in eine ungefährliche Position zu bringen, um Schäden zu verhindern. Diese Sensoren sind sicher nicht so genau wie die Seismographen, die man zur Vorhersage von Erdbeben, Tsunamis und Vulkanausbrüchen und für die geophysikalische Forschung verwendet. Aber sie sind überall vorhanden und könnten so wertvolle zusätzliche Daten liefern. Das könnte vielleicht so funktionieren, daß die Betreiber von Rechnern mit Festplatten der Erfassung und Übermittlung von seismographischen Daten an ein geophysikalisches Rechenzentrum zustimmen. Weil die genaue Standortinformation ziemlich essentiell ist, sind sicher stationäre Rechner besser geeignet als Laptops, außer es werden noch GPS-Daten zusätzlich erfaßt und übermittelt, was aber ein größeres Mißbrauchsrisiko der Daten impliziert. Wenn Millionen von Nutzern mitmachen würden, hätte man genug Daten, um die Ungenauigkeiten der Messung teilweise zu eliminieren, weil nach dem Gesetz der großen Zahl angenommen werden kann, daß sich zufällige Fehler relativ gesehen verringern, wenn man etwa Mittelwerte vieler Meßwerte bildet. Systematische Meßfehler eines Sensors kann man auch erkennen und korrigieren oder sogar die Ausreißer weglassen. Noch besser wäre vielleicht eine Gewichtung der Meßwerte nach Qualität.

Eigentliche Mittelwerte sind nur sinnvoll, wenn man mehrere Festplatten am selben Standort hat, ansonsten wäre wohl eine mehrdimensionale Funktion, die von Ort und Zeit abhängt, zu approximieren. Die Geophysiker wissen etwa, wie diese Funktionen aussehen könnten und man kann die Meßwerte, von denen man Ort und Zeit kennt, verwenden, um ein paar Parameter dieser Funktion abzuschätzen. Diese Daten könnte man mit den genaueren Messungen der professionellen Geräte kombinieren. Der Vorteil der Festplattensensoren wäre vor allem, daß man ein viel flächendeckenderes Sensorennetz erhielte als man je durch Aufstellen von Seismographen bezahlen könnte. Das wäre eine echte Big-Data-Anwendung.

Share Button

Datenqualität

English

Sehr häufig erlebt man, daß Software nicht richtig funktioniert.  Oft ist es ein Fehler der Software selbst,das wissen wir nur zu gut.

Die Erfahrung zeigt aber, daß noch häufiger das Problem bei den Daten liegt, mit denen die Software arbeitet.  Kurz gesagt ergeben sich aus falschen Daten falsche Ergebnisse.

Es lohnt sich also, in Organisationen, die mit Software arbeiten, auf die Qualität der zugrundeliegenden Daten zu achten.  Für Software sind wir es gewohnt, daß es Prozesse gibt, die Qualität zu testen und gegebenenfalls Fehler zu finden und zu korrigieren.  Auch wenn diese Prozesse oft Mängel aufweisen, sind sie doch vorhanden und funktionieren meistens auch irgendwie. Natürlich ist es andererseits auch oft einfacher, fehlerhafte Daten als fehlerhafte Software zu korrigieren.

Wer kümmert sich aber um die Qualität der Daten?  Ist die Software einmal abgenommen, ist oft eine „Fachseite“ dafür zuständig, die Daten zu pflegen.  Oder die Daten kommen von anderen Systemen.  Ein paar Fragen dazu:

  • Kennt man den Weg der Daten durch die verschiedenen Systeme?
  • Gibt es Verantwortliche für die Datenqualität?
  • Werden die Daten überprüft?

Die entsprechenden Fragen sind oft weniger klar beantwortet als im Fall der Software, wo man doch den Entwicklungsprozeß zumindest ansatzweise kennt, Verantwortlichkeiten definiert sind und eine zumindest rudimentäre Überprüfung der Qualität üblich geworden ist.

Ein paar Beispiele, natürlich soweit abstrahiert, daß man sie nicht mehr einer bestimmten Organisation zuordnen kann:

Daten sollten eine Realität abbilden, sagen wir mal den Bestand an Möbelstücken in einem Büro.  Wenn nun gelegentlich Möbelstücke ausgetauscht, entfernt oder dazugekauft werden und die Daten mit der Realität nicht Schritt halten, hat man irgendwann den Bezug zur Realität eingebüßt.

Daten sollten genau sein.  Zum Beispiel hat man irgendwo meinen Namen falsch geschrieben und die Mailadresse mit dem falschen Namen definiert.  Das kann egal sein, ist es aber nicht wirklich.  Der Name wird an so vielen Stellen verwendet, wo es auf die buchstabengenaue Schreibweise ankommt, deshalb ist eine Ungenauigkeit heute nicht mehr so leicht zu verschmerzen wie zu den Zeiten der Papierpost und der Briefträger, die noch Zeit hatten, einen Brief mit einer ungeauen Adresse dem richtigen Empfänger zu bringen.  Im Fall des falsch geschriebenen Namens konnte ich damals recht schnell eine Stelle finden, die den Fehler korrigiert hat.  Aber nach einer Woche war er wieder da und niemand wußte, wie man das wirklich löst, bis ich nach ein paar Monaten zufällig die Person gefunden hatte, die das „Master“-System betreute, von dem die Daten immer wieder repliziert wurden.

Eine häufige Folge von Ungenauigkeiten sind Duplikate, die unter anderem durch so eine Ungenauigkeit beim Schreiben von Namen oder anderen Datenfeldern entstehen können. Oder durch verschiedene miteinander kommunzierende Systeme, die sich ihre Daten gegenseitig weiterreichen und irgendwann „vergessen“ auf schon bekannte Daten zu prüfen.

Interessant sind auch Fälle, wo sich eine Attribut ändert, zum Beispiel der Name einer Person.  Nun ist diese Person aber schon vor der Namensänderung im System gewesen und die Daten sind auch entsprechend verknüpft.  Bleiben diese Verknüpfungen bei einer Namensänderung erhalten?

Viele dieser Probleme lassen sich zumindest teilweise behandeln, indem man bei der Erstellung einer IT-Landschaft darauf achtet, daß diese möglichst wenig fehleranfällig ist:

  • Wie kommunzieren die Systeme miteinander?  Welches System ist „Master“ für die Daten?  Oder gibt es eine wirklich funktionierende „Multimaster“-Architektur?
  • Können offensichtlich falsche Daten erkannt und abgelehnt werden?
  • Wie werden Daten miteinander verknüpft und wie resistent sind diese gegenüber Veränderungen?
  • Gibt es Workflows, die es erleichtern, Daten konsistent und aktuell zu halten?
  • Wie stabil sind Schnittstellen zu anderen Systemen?
  • Gibt es Plausibiltitätsprüfungen bei den Daten, insbesondere auch auf Ähnlichkeit (Duplikate)?
  • Wird ein Abgleich mit zuverlässigen Datenquellen durchgeführt?
  • Wie werden Änderungen in der durch die Daten abgebildeten Realität erkannt und in den Datenbestand eingeführt?

Man kann heute recht viel machen und es ist sinnvoll, auch viele Tests der Datenqualität im laufenden Betrieb automatisiert durchzuführen.  Aber es ist auch wichtig, daß die Personen, die die Daten liefern, genau arbeiten und daß die Prozesse so gelebt werden, daß alle Beteiligten daran arbeiten, eine gute Datenqualität sicherzustellen.  Um bei dem Beispiel der Möbel zu bleiben:  Diejenigen, die die Möbel in dem System erfassen müssen, dürfen nicht mit anderen Tätigkeiten so überlastet sein, daß die Erfassung der Möbel keine Priorität mehr hat und nur halbherzig oder zu spät oder gar nicht gemacht wird.  Sonst kann man sich die teure IT-Applikation sparen, die mit dem entsprechenden Datenbestand arbeitet.

 

Share Button