Azure Data Factory – Concurrency
Heute geht es um das Thema „Concurrency“ in der Azure Data Factory. Und das passt wunderbar zu unserem letzten Beitrag, der von der automatischen Verarbeitung neu angelieferter Files im Azure Blob Storage handelte.
Heute geht es um das Thema „Concurrency“ in der Azure Data Factory. Und das passt wunderbar zu unserem letzten Beitrag, der von der automatischen Verarbeitung neu angelieferter Files im Azure Blob Storage handelte.
Der ganze Prozess findet ausschließlich in der Cloud statt – nichts mehr mit der guten alten on-premise Technologie! Und all das kann sogar noch skaliert werden. In der obigen Abbildung haben wir die Concurrency der Pipeline auf 10 gestellt, d.h. bis zu 10 Instanzen der Pipeline können parallel laufen, wenn in kurzer Zeit eine größere Anzahl Files eintrifft. In der alten Welt hätten wir in klassischen SSIS-Paketen mit for-each-loop Containern die Files irgendwie gelesen und weiterverarbeitet.
Wir sind große Fans der Möglichkeit, den SQL Server in Azure “serverless” zu betreiben! Diese Variante hat gegenüber den traditionellen Versionen Basic, Standard, oder Premium, die über eine konstante Menge von DTUs abgerechnet werden, den Vorteil, dass sie dynamisch hoch- und herunterskaliert, je nachdem, wie intensiv sie benutzt werden, und dass dann auch nur über sogenannte “vCores” genau das an Rechenzeit abgerechnet wird, was man auch genutzt hat. Super!
Wie in Teil 1 bereits beschrieben, bietet die von Azure integrierte Lösung für SQL-Datenbanken bereits eine Verfügbarkeit von 99,99 %. Was aber, wenn das nicht ausreicht? Teil II
Für viele Unternehmen hat die Verfügbarkeit ihrer Datenbanken oberste Priorität. Was passiert, wenn eine Datenbank plötzlich nicht mehr verbunden ist? Sind die Daten verloren?
Diesbezüglich müssen Sie sich bei Azure SQL-Datenbanken keine Sorgen machen.
In diesem Beitrag soll es um Visualisierung von Zahlen gehen (z.B. nach ibcs-Standard), um geeignete und weniger geeignete Methoden zur Darstellung und um die Schlüsse, die daraus gezogen werden – richtige und falsche gleichermaßen.
In diesem Beitrag geht es darum, dass Excel und ähnliche Tabellenkalkulationen allgemein nicht die besten BI-Tools sind – und Self Service BI mit dem Fischen im Data Lake auch nicht immer der Stein der Weisen zu sein scheint.
Wir empfehlen Guided bzw. Managed Analytics. Warum?
BI-Projekte sind dynamisch. Wenn man jetzt schon wüsste, welche Anforderungen in zwei Jahren kommen, würde man höchstwahrscheinlich anders modellieren als mit dem aktuellen Wissensstand. Wir sind aber alle keine Hellseher und deswegen ist es müßig, im Nachhinein immer sich zu sagen: „Hätte ich damals gewusst…“.
Tableau ist ein sehr starkes Tool, die viele Möglichkeiten zur Visualisierung bietet. Bei einem richtigen Einsatz der Software kann man viel Zeit und Geld sparen. Und umgekehrt, ein falscher Einsatz kann es zur Zeit- und Geldverluste führen.