Überblick Azure Data Factory

Microsoft hat innerhalb des letztens Jahres viele interessante Dienste auf Azure veröffentlicht. Einen dieser Dienste habe ich mit HDInsight das letzte Mal kurz vorgestellt. Ein weiterer Dienst, der sich sehr gut mit HDInsight ergänzt, ist die Azure Data Factory.

Dieser Artikel erklärt, was die Azure Data Factory ist und wofür sie genutzt werden kann. Zusätzlich werden die erste Schritte mit dem neuen Dienst erklärt.

Warum Azure Data Factory?

Typische ETL-Prozesse nutzen in der Regel nur eine Hand von Datenquellen, die in das Enterprise Data Warehouse (EDW) geladen werden.


src: Documentation

Mit dem Aufkommen vieler verschiender Datenquellen, bspw. Sensoren oder soziale Netzwerke, verschiedener Typen, bspw. semi-strukturierte oder unstrukturierte Daten, eine höhere Nachfrage entstand diese Prozesse sinnvoll zu integrieren.
Weiterhin wurden klassische EDWs dafür entwickelt bestimmte Fragen zu beantworten. Mit der Verbreitung des Big Data-Gedankens EDWs entwickeln sich immer mehr in die Richtung, dass auch Antworten gefunden werden sollen für die man die Frage noch nicht kennt, d.h. Daten bereits heute zu sammeln, da sie sich eines Tages bezahlt machen können.

Einer der populärsten Begriffe, die oben stehendes Problem am besten beschreibt, ist der sogenannte “Data Lake”. Hierunter wird die inhomogene Sammlung verschiedener Daten verstanden, sei es im traditionellen EDW oder im HDFS oder Blob Storage.


src: Documentation

Azure Data Factory versucht diese Probleme lösen, insbesondere durch das Ansteuern verschiedenartiger Datenquellen und die Verarbeitung hoher Datenaufkommen.

Was ist Azure Data Factory?

Einfach gesagt ist Azure Data Factory ein skalierbarer Dienst für das Zusammenführen von Verarbeiten verschiedener Datenquellen. Dieser Dienst ist entwickelt worden um unstrukturierten, semi-strukturierten und strukturierten Daten von on-premise und Cloud-Datenquellen leichter verarbeiten zu können. Dabei stehen folgende Stichworte im Vordergrund:

  • Linked Service: Ein Datenspeicher oder -verarbeiter (derzeit Azure Storage, Azure SQL Database, Azure HDInsight und on-premise SQL Server)
  • Data Hub: Ein Container für zusammenhängende Linked Services
  • Data Set: Eine Definition von Daten eines Linked Service
  • Pipeline: Ein Workflow für die Datenverarbeitung von Daten zwischen Quellen und Hubs


src: Documentation

Ungewöhnlich ist die Definition dieser verschiedenen Komponenten. Dies geschieht in einem bestimmten JSON-Schema. Zwei Data Sets und eine Pipeline werden examplarisch definiert. Hierbei sollen gesammelte Log-Dateien aus dem Azure Blob Storage in eine SQL Azure Database verschoben werden. Folgende Skripte setzen voraus, dass die entsprechenden Linked Services im Portal bereits erstellt wurden.

Die Definition des Blob Storage Data Set lautet wie folgt:

{
    "name": "WebsiteLogs",
    "properties":
    {
        "structure":  
         [ 
            { "name": "Site", "type": "String"},
            { "name": "Requester", "type": "String"}
        ],
        "location": 
        {
            "type": "AzureBlobLocation",
            "folderPath": "logs/",
            "format":
            {
                "type": "TextFormat",
                "columnDelimiter": ","
            },
            "linkedServiceName": "Blog Logs"
        },
        "availability": 
        {
            "frequency": "hour",
            "interval": 1,
            "waitonexternal": {}
        }
    }
}

Hierbei wird zuallererst ein Name vergeben. Danach definiert man in den Eigenschaften die Struktur der Daten (hier einfach die Seite, auf die zugegriffen wurde, und die IP des Aufrufers), wo diese Daten liegen und in welchen Intervallen diese abgerufen werden.

Die Definition des Data Sets für das SQL Azure Database-Ziel ist ähnlich definiert wie die des Blob Storages.

{
    "name": "WebsiteTable",
    "properties":
    {
        "structure":
        [
            { "name": "Site", "type": "String"},
            { "name": "Requester", "type": "String"}
        ],
        "location":
        {
            "type": "AzureSQLTableLocation",
            "tableName": "logs",
            "linkedServiceName": "Blog"
        },
        "availability": 
        {
            "frequency": "Hour",
            "interval": 1            
        }
    }
}

Der wichtigste Unterschied lässt sich im location-Bereich finden. Anstatt den Blob Storage und den Zugriff auf diesen zu definieren, wird ein entsprechender Typ und der Name der Tabelle, in die gespeichert werden soll, festgelegt. Für den Typen gibt es vier verschiedene Auswahlmöglichkeiten (äquivalent zu den unterstützten Datenquellen):

Data Set Typ
Azure SQL Database AzureSqlTableLocation
Azure Blob Storage AzureBlobLocation
Azure Table Storage AzureTableLocation
On-premise SQL Server OnPremisesSqlServerTableLocation

Um Daten zwischen Quelle und Ziel zu verschieben fehlt jetzt noch die entsprechende Pipeline. Diese nutzt die Copy Activity (eine weitere ist die sogenannte HDInsight Activity), die es ermöglicht Daten von einem Input in einen Output zu verschieben und auch bspw. Transformationen und Mappings zu definieren.

{
    "name": "LogPipeline",
    "properties":
    {   
        "description" : "Copy log data from a blob to Azure SQL table",
        "activities":   
        [
            {
                "name": "CopyFromBlobToSQL",
                "description": "Push website logs to Sql Azure",
                "type": "CopyActivity",
                "inputs": [ {"name": "WebsiteLogs"} ],
                "outputs": [ {"name": "WebsiteTable"} ],     
                "transformation":
                {
                    "source":
                    {                               
                        "type": "BlobSource"
                    },
                    "sink":
                    {
                        "type": "SqlSink"
                    }   
                },
                "Policy":
                {
                    "concurrency": 1,
                    "executionPriorityOrder": "NewestFirst",
                    "style": "StartOfInterval",
                    "retry": 0,
                    "timeout": "01:00:00"
                }       
            }
        ]
    }
} 

Die Einzelheiten des JSON-Skriptings sind in der Dokumentation nachzulesen.

Um nun diese Pipeline und die entsprechenden Data Sets zu veröffentlichen benötigt es den Einsatz der Azure PowerShell. Um die Data Factory Commandlets nutzen zu können ist es notwendigt, dass die neueste Azure PowerShell installiert ist. Dies kann leicht mithilfe des Web Platform Installers erledigt werden.

Das Bereitstellen des Blob-Data Sets erfolgt über folgenden Befehl

New-AzureDataFactoryTable -ResourceGroupName Blog -DataFactoryName blog -File .\LogBlobTable.json

Ähnliches Vorgehen besteht beim veröffentlichen des Azure SQL Database-Data Sets

New-AzureDataFactoryTable -ResourceGroupName Blog -DataFactoryName blog -File .\LogSQLTable.json

Um diese beiden nutzen zu können fehlt nur noch die Veröffentlichung der Pipeline für das Kopieren der Daten

New-AzureDataFactoryPipeline -ResourceGroupName Blog -DataFactoryName blog -File .\LogPipeline.json

Eines der netten Features von Data Factory ist das Definieren von Zeitperioden, wann eine Pipeline aktiv ist … und ob historische Daten nachgeladen werden können.

Set-AzureDataFactoryPipelineActivePeriod -ResourceGroupname Blog -DataFactoryName blog 
-StartDataTime 2014-12-12 -EndDateTime 2014-12-14 -Name LogPipeline

Es ist an dieser Stelle möglich das Startdatum auf einen beliebigen Wert in der Vergangenheit zu setzen und nicht nur aktuelle Daten zu verarbeiten, sondern auch historische.

Interessant für Entwickler

Obiges Beispiel zeigt nur einen kleinen Teil der Funktionalitäten von Azure Data Factory. Für Entwickler sind die sogenannten “Custom Activities” mit am interessantesten. Insbesondere in der Preview-Phase sind die vorhandenen Datenquellen und -ziele noch sehr beschränkt. Custom Activities ermöglicht es anhand von .NET-Code eigene Azure Data Factory Activities zu erstellen. Dies reicht von dem Verbinden mit neuen Datenquellen und -zielen bis hin zum Erstellen eigener Transformationen.

Zusammenfassung

Azure Data Factory ist einer der interessantesten Dienste, die im letzten Jahr zu Azure hinzugefügt worden. Derzeit sind die integrierten Funktionalitäten schon weit fortgeschritten, obwohl die Anzahl der ansprechbaren Datenquellen noch sehr limitiert sind. Dies liegt daran, dass Data Factory derzeit einen Fokus auf Azure und hybride Umgebunden hat. Dieser Fokus wird sich voraussichtlich innerhalb der nächsten Monate verschieben und immer mehr Erweiterungen für Data Factory zur Verfügung stellen. Anhand der Custom Activities sind eigene Erweiterungen aber schon heute möglich.

Sehr interessant ist der Ansatz Data Factories anhand von JSON zu erstellen bzw. zu konfigurieren.

Dieser Artikel konnte leider nur einen kleinen Einblick geben, was mit Azure Data Factory möglich ist. Um einen tieferen Einblick zu erhalten lohnt sich das Ansehen der TechEd Europe-Session von Mike Flasko sowie das Durcharbeiten der Dokumentation.

Lesenswertes

Jan (@Horizon_Net)

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s