Azure voor Beginners - Een Data Flow & Pipeline maken in Azure Data Factory

In onze Azure voor Beginners-serie hebben we tot nu toe een Azure Storage Account, een Azure SQL Database en een Azure Data Factory gemaakt, en hebben we laten zien hoe u data kunt kopiëren met behulp van alle drie. Hiermee hebben we bij lange na niet de volledige potentie van Azure Data Factory benut. Waar Azure Data Factory eigenlijk echt uitblinkt is in het maken van zogeheten data flows en pipelines.

• Met data flows kunnen we data transformeren via een visuele interface, zonder hiervoor code te hoeven schrijven. Het maakt gebruik van een drag-and-drop-systeem, waardoor we op eenvoudige wijze complexe datatransformatielogica kunnen ontwerpen en visualiseren. Als we bijvoorbeeld onze data willen samenvoegen, aggregeren of filteren, gebruiken we een data flow. Een data flow kan echter niet worden uitgevoerd zonder een pipeline.

• Data flows kunnen worden geïntegreerd in pipelines. Een pipeline is een logische groep activiteiten die samen een taak uitvoeren. Waar data flows draaien om het transformeren van data, zijn pipelines gericht op orkestratie. Ze stellen ons in staat activiteiten (zoals data flows) als een groep te beheren in plaats van elk afzonderlijk en onafhankelijk. Als u bijvoorbeeld afzonderlijke activiteiten heeft om gegevens in te laden, op te schonen en te analyseren, kunnen deze met elkaar 'verbonden' worden via een pipeline, welke ze achter elkaar laat uitvoeren. Omdat er veel soorten activiteiten bestaan in Azure Data Factory, betekent dit dat een pipeline kan worden uitgevoerd zonder een data flow, maar een data flow niet zonder pipeline.

In dit deel van onze serie Azure voor Beginners-serie gaan we een data flow creëren, waarin twee van onze CSV-bestanden uit ons Azure Storage Account worden samengevoegd tot één (met een join). Deze data filteren we en slaan het op in onze Azure SQL Database. Ten slotte creëren we een pipeline waarmee we deze data flow zullen uitvoeren.

Note: het uiterlijk van Azure verandert regelmatig. Uw scherm ziet er mogelijk net iets anders uit dan op de afbeeldingen in deze handleiding. Sommige functies zijn bijvoorbeeld mogelijk naar een ander tabblad verplaatst, maar de algemene stappen zullen hetzelfde zijn.

Note: deze beginnershandleiding is gemaakt op basis van de Engelstalige UI. Om deze reden zullen wij in dit artikel de Engelse benamingen hanteren.

Note: houd er rekening mee dat de services binnen Azure betaalde services zijn. De kosten zijn afhankelijk van uw gebruik en configuratie. (Meer informatie vindt u hier.) Het is verstandig om dit te doen onder toezicht van een databasebeheerder of een data-engineer.

Uiteraard begint u met het inloggen in uw Azure-account, waarna u vervolgens navigeert naar Azure Data Factory. U kunt dit doen door op het Data Factory-pictogram in de snelkoppeling bovenaan te klikken, of door helemaal rechts van de snelkoppeling op More services te klikken en naar beneden te scrollen naar de Analytics sectie, waaronder u onder meer Data factories zult zien staan. Nadat u de Azure Data Factory-omgeving heeft geladen klikt u op de specifieke Data Factory die u tijdens een vorige les heeft gemaakt.

Net als in de vorige les, start u Azure Data Factory Studio op door op de knop 'Launch studio' te klikken.

In plaats van op 'Ingest' te klikken, gebruiken we deze keer de 'Transform data' knop.

U zult een voor u nieuwe interface zien. Hierin kunt u onder andere data flows en pipelines creëren. Ons doel is om twee CSV-bestanden samen te voegen tot één dataset, deze te filteren en naar onze SQL database te verplaatsen. Het is waarschijnlijk geen verrassing, maar in Azure kunnen dingen op verschillende manieren worden gedaan. Bijvoorbeeld, we zullen eerst de dataset moeten selecteren die we willen samenvoegen. Dit kunnen we doen door ze rechtstreeks toe te voegen onder de kop Datasets. In deze handleiding zullen we dit echter doen door eerst een nieuwe data flow aan te maken en gedurende dit proces de datasets toe te voegen.

Om te beginnen geven we eerst onze nieuwe data flow een naam.

Aangezien we onze orders.csv dataset willen tranformeren in deze data flow, gebruiken we de naam 'OrdersTransformation'.

Vervolgens zullen we onze orders.csv dataset gaan toevoegen. We beginnen door op 'Add Source' te klikken.

Hiermee maken we een nieuwe bron aan, welke we zullen richten op onze orders.csv data set.

Wanneer we deze bron op het canvast hebben geselecteerd (waardoor deze een blauwe kleur krijgt), kunnen we deze bron aan de onderkant van het scherm configureren. Zoals gebruikelijk in Azure leidt dit ons door verschillende tabbladen, welke bovenaan te zien zijn.

Op het tabblad Source settings verzint u eerst een naam voor de bron. In ons voorbeeld hebben we voor de naam 'OrdersStream' gekozen. Voor Source type hebben we twee opties:

• Dataset - Door 'Dataset' te selecteren maken we een object dat de datastructuur vertegenwoordigt die we gaan gebruiken. (We laden niet de daadwerkelijke data, maar eigenlijk het Dataset-object dat de data vertegenwoordigt.) In ons geval is deze datastructuur een CSV-bestand in ons Azure Storage Account. Dit object is herbruikbaar, dus als we opnieuw naar hetzelfde CSV-bestand in ons opslagaccount willen verwijzen, kunnen we deze Dataset opnieuw gebruiken. Voor herbruikbare, complexe of vaak gebruikte data sources is Dataset de betere optie.

• Inline - Het brontype 'Inline' kan daarentegen slechts één keer worden gebruikt. Het creëert geen herbruikbaar object, maar definieert de details van de databron binnen de activiteit. Voor eenvoudige, eenmalige situaties kunnen inline source types een goede optie zijn.

Voor onze beginners handleiding selecteren we 'Dataset' als Source type en klikken we op '+ New' om de dataset te kunnen selecteren.

Aangezien onze dataset is opgeslagen in ons Azure Storage Account selecteren we 'Azure Blob Storage'.

Onze dataset (orders.csv) is opgeslagen als een CSV-bestand, dus kiezen we vervolgens 'DelimitedText'.

Geef de nieuwe data bron een naam en selecteer 'AzureBlobStorage' als Linked service. Daaronder zult u een Linked service moeten selecteren, waarvoor mogelijk een korte uitleg nodig is.

Met Azure Data Factory kunt u verbinding maken met verschillende databronnen door een object te maken dat een 'linked service' wordt genoemd. Een linked service is in wezen een reeks configuratie-instellingen die bepalen hoe u verbinding maakt met uw databron, zoals een bestand in uw Azure Storage Account, een tabel in uw Azure SQL Database, of vele andere opties. Door linked service te gebruiken om verbinding te maken met databronnen, kunnen we data opnemen en voorbereiden voor transformatie of analyse. Als u al een linked service voor uw Azure Storage Account heeft aangemaakt, selecteert u deze; zo niet dan maakt u een nieuwe aan.

Klik vervolgens op het folder icoontje om naar de specifieke dataset te navigeren.

In ons geval kiezen we het order.csv bestand, welke we gedurende het aanmaken van een Azure Storage Account hebben geüpload.

Indien u een CSV-bestand met een header als bron gebruikt, zorg er dan voor dat u 'First row as header' heeft ingeschakeld. Vervolgens selecteert u hoe u het schema (dat wil zeggen de structuur) voor de data wilt importeren. In ons geval gebeurt dit middels 'From connection/store', wat betekent dat Azure het schema rechtstreeks importeert vanuit de data bron die we hebben geselecteerd. Het is heel goed mogelijk dat u uw eigen voorbeeldbestand wilt gebruiken met daarin een schema, of dat u ervoor kiest helemaal geen schema te importeren omdat u dit later handmatig wil instellen. Klik op 'OK' als u klaar bent.

Klik bovenaan op het tabblad Source options. Dit tabblad toont ons verschillende mogelijkheden voor het laden van een data set. Deze opties zijn afhankelijk van het bestandstype van uw data bron, wat in ons geval een CSV-bestand is. Hoewel we voor onze beginners handleiding deze opties ongewijzigd laten, leest u hieronder een beschrijving van wat u met deze opties kunt doen.

• Wildcard paths worden gebruikt in gevallen waarin u meerdere bestanden van hetzelfde type wilt selecteren. Stel bijvoorbeeld dat u een folder heeft welke veel bestanden bevat met verschillende bestandnamen. Enkele van deze bestanden hebben bestandnamen welke een bepaald patroon volgens, zoals orders1.csv, orders2.csv, enz. Als we alleen bestanden willen selecteren met bestandnamen die beginnen met 'orders', kunnen we een wildcard path gebruiken, zoals orders?.csv. Hiermee selecteren we dan alleen bestanden die beginnen met 'order', gevolgd door een willekeurig ander teken, gevolgd door '.csv'. Als we veel van zulke bestanden zouden hebben, in de dubbele cijfers, dan zouden een extra '?' moeten gebruiken voor elk extra cijfer. Om bijvoorbeeld orders123.csv te kunnen matchen, zouden we de wildcard path orders???.csv moeten gebruiken. Mocht u geen bovengrens willen instellen, dan kunt u de wildcard path orders*.csv gebruiken.

• Partitions root path heeft te maken met partitiedetectie. Door een partitions root path op te geven, genereert u extra kolommen in uw data set op basis van uw bestandspad. Stel dat uw dataset in deze mappen is opgeslagen:

Vervolgens stelt u uw partitions root path in op deze map:

Azure Data Factory zal dan de volgende twee extra kolommen genereren in uw data set:

◦ De kolom 'month', met daarin de waarde '12'.

◦ De kolom 'day', met daarin de waarde '01'.

• Allow no files found ​​- Indien ingeschakeld, zult u geen foutmelding ontvangen als er geen bestanden worden gevonden. Dit is een goede optie als u een pipeline wilt maken waarin u niet verwacht dat uw upstream(s) u elke dag bestanden sturen, maar waarvoor u niet wilt dat uw pipelines falen.

• List of files - Indien u specifieke bestanden wilt selecteren (maar niet alle bestanden), kunt u deze functie gebruiken. Het verschil met Wildcard paths is dat List of files niet vereist dat de bestandsnamen een bepaald patroon delen. Waar Wildcard paths vereisen dat orders1.csv en orders2.csv een of meer delen van de bestandsnaam delen, in dit geval 'orders' en '.csv', heeft List of files deze vereiste niet. Dit betekent dat u de bestanden abcd.cvs en efghijk.json niet kunt selecteren met Wildcard paths, maar wel met List of files. Indien ingeschakeld, zult u het pad naar een lijst moeten opgeven waarin u alle bestanden opgeeft die u wilt selecteren. Dit kan eenvoudigweg een tekstbestand zijn waarbij elke bestandsnaam op een aparte regel staat.

• Multiline rows - Als uw bronbestand gebruikmaakt van rijen met meerdere regels, waarbij rijen zijn verspreid over meer dan één regel, dan selecteert u deze optie om ervoor te zorgen dat Azure Data Factory deze rijen interpreteert als enkele rijen in plaats van meerdere rijen. Waarden met meerdere regels moeten tussen aanhalingstekens staan.

• Maximum columns - Hier kunt u het maximale aantal kolommen instellen, dat standaard op 20480 staat. Indien uw bron bestand meer kolommen heeft dan het standaardaantal zult u dit hier op moeten geven.

• Change data capture - Indien u enkel wijzigingen in uw bron bestand wilt gebruiken, kunt u Change data capture (CDC) inschakelen. Met deze optie worden alleen de data gebruikt dat is gewijzigd sinds de laatste keer dat de pipeline werd uitgevoerd, in plaats van de volledige dataset bij elke uitvoering. In datatermen worden deze wijzigingen (zoals het toevoegen van nieuwe rijen, het bijwerken van bestaande rijen of het verwijderen van rijen) ook wel de 'delta' genoemd.

• Column to store file name - Met deze optie wordt er een nieuwe kolom in uw doel dataset aangemaakt met daarin de bronbestandsnaam en het pad.

• After completion - Hiermee krijgt u de mogelijkheid om te bepalen wat er met uw bron dataset wordt gedaan na de uitvoering van uw data flow. Hierbij heeft u de optie om niets te doen, de dataset te verwijderen, of de dataset te verplaatsen.

• Filter by last modified - Met deze optie kunt u uw bestanden filteren op basis van wanneer ze voor het laatst zijn gewijzigd. Dit is een goede optie om enkel bestanden te selecteren die gewijzigd zijn in een specifieke periode. U dient het begin en einde van deze periode op te geven.

Op het Projection tabblad kunnen we het schema voor onze doel dataset definiëren en beheren. Hier kunt u het datatype voor uw kolommen instellen, evenals de indeling van de kolom.

Op het Optimize tabblad kunt u kiezen of u uw data wel of niet opnieuw wilt partitioneren nadat u deze heeft getransformeerd. Hier heeft u de keuze tussen:

• Use current partitioning - Dit is de standaardoptie en zorgt ervoor dat Azure Data Factory de huidige output partitionering van de transformatie behoudt. Deze optie wordt in de meeste scenario's aanbevolen.

• Single partition - Hiermee wordt alle gedistribueerde data gecombineerd in één partitie. Omdat er één enkele, grote partitie zal zijn, zal er geen parallelle verwerking plaatsvinden. Dit kan een zeer langzaam proces worden, wat een negatieve impact zal hebben op alle downstream-activiteiten. Als u geen expliciete zakelijke reden heeft voor deze optie, kunt u dit het beste vermijden.

• Set partitioning - U heeft hier de keuze tussen de volgende partitionering types:

◦ Round robin, waarmee uw data gelijkmatig wordt verdeeld, op basis van het aantal fysieke partities dat u zult moeten opgeven. Dit is een goede optie als u geen goede partitiestrategie heeft.

◦ Hash, wat een hash van kolommen oplevert, zodat rijen met vergelijkbare waarden in dezelfde partitie vallen. U kunt het aantal fysieke partities instellen.

◦ Dynamic range, waarbij gebruik wordt gemaakt van dynamische bereiken op basis van de kolommen of expressies die u opgeeft. U kunt het aantal fysieke partities instellen.

◦ Fixed range, waarin u expressie maakt die een vast bereik biedt voor waarden binnen uw gepartitioneerde data kolommen. U kunt het aantal fysieke partities instellen.

◦ Key, waarmee partities worden gemaakt voor elke unieke waarde in een kolom naar keuze. Het aantal partities is gebaseerd op het aantal unieke waarden in deze kolom. Stel dat u bijvoorbeeld een data set over uw werknemers heeft, en dat u als Key een kolom heeft opgegeven met daarin de verschillende afdelingen waartoe uw werknemers behoren. Met deze optie wordt voor elke afdeling in deze kolom een ​​nieuwe map aangemaakt met de naam 'afdeling=....' (waarbij .... de afdelingsnaam is). Deze map bevat alleen de partitie met de medewerkersgegevens voor die specifieke afdeling.

Voor onze beginnershandleiding laten we het op 'Use current partitioning' staan ​​en gaan we verder naar het Inspect tabblad.

Op het Inspect tabblad zien we een alleen-lezen metagegevens weergave van de data die we transformeren. Het is een snel overzicht van kolommen, het aantal kolommen, de kolommen die we hebben gewijzigd of toegevoegd, data typen, kolom volgorde en kolom voorkeuren. Omdat we geen wijzigingen in de gegevens hebben aangebracht, zien we momenteel alleen het totaal aantal kolommen direct onder de tabbladen. Zodra u wijzigingen aanbrengt zult u ook u ook tellingen zoals New, Updated, and Unchanged zien staan.

Vervolgens gaan we door naar het Data preview tabblad.

Het is altijd verstandig om het Data preview tabblad te controleren, ook al is het alleen maar om te controleren of de data correct is geladen. Als u het bericht "Please turn on debug mode and wait until the cluster is ready to preview data" ziet, zult u eerst de debug mode moeten inschakelen. Dit kunt u doen door de Data flow debug schakelaar om te zetten.

Selecteer de juiste integration runtime (daarover later meer) en hoe lang u de Debug-tijd geactiveerd wilt hebben. Voor onze beginnershandleiding laten we de instellingen ongewijzigd en klikken op 'OK'.

De Debug modus activeren kan even duren.

Nadat de Debug modus is geactiveerd klikt u linksboven op het Data preview tabblad op Refresh. Hierna zult u een voorbeeld van uw data set te zien krijgen.

Aangezien ons doel is om twee data bronnen samen te voegen via een zogeheten join, voegen we nu nog een data bron toe.

Het toevoegen van de tweede data bron gebeurt op dezelfde manier als het toevoegen van de eeerste data bron. We hebben nog een CSV-bestand toegevoegd, deze keer met de naam 'Customers', daarom hebben we de stream 'CustomersStream' genoemd. Op de overige tabbladen zijn geen aanpassingen aangebracht.

We zullen nu de twee datasets die we hebben toegevoegd samenvoegen tot één dataset, wat in datatermen ook wel een 'join' wordt genoemd. Als u bekend bent met het maken van joins in SQL, Python of visualisatieprogramma's zoals Tableau, Power BI of Looker Studio, is het maken van een join niets nieuws onder de zon. Zo niet, dan is de uitleg ervan erg eenvoudig: u neemt twee tabellen en combineert ze tot één (bredere en eventueel langere) tabel. Met een join kunt u dus data uit meerdere datasets combineren.

Tot nu toe hebben we onze dataset orders.csv (OrdersStream) toegevoegd, wat in feite een tabel is met de bestellingen die door klanten zijn geplaatst, én we hebben onze dataset customers.csv (CustomersStream) toegevoegd, wat een tabel is met klantinformatie over onze klanten. Wij willen deze twee datasets samenvoegen tot één, zodat we een dataset hebben met de geplaatste bestellingen én de klantgegevens van de klanten die deze bestellingen hebben geplaatst. In veel gevallen (maar niet altijd) wordt een join uitgevoerd via een kolom die beide tabellen gemeen hebben, wat in ons geval de kolom 'customerid' is. In onze customers dataset identificeert de customerid kolom elke klant op unieke wijze. (Geen enkele klant heeft dezelfde customerid.) Deze kolom wordt ook wel de primary key genoemd. In de orders dataset is deze kolom echter niet uniek, want een klant kan immers meerdere bestellingen plaatsen waardoor dezelfde customerid meerdere malen voor zal komen in dezelfde dataset. In de orders dataset verwijst de kolom customerid eigenlijk naar de naar de primary key in de customers dataset. Deze kolom wordt ook wel de foreign key genoemd. In veel gevallen (maar niet altijd) zal een join gebaseerd zijn op een primary key en een foreign key.

Om een join te maken, klik op het + teken naast een van uw data streams.

U zult een lange lijst te zien krijgen met daarin allerlei data transformaties. Hier selecteert u de optie 'Join'.

Net als bij het toevoegen van een data bron, zullen we onze join moeten configureren. Eerst dient u de join een naam te geven. Daaronder heeft u ook de mogelijkheid om een ​​beschrijving toe te voegen, maar dit is niet verplicht. Vervolgens u streams moeten selecteren die u wilt samenvoegen. We hebben 'OrdersStream' geselecteerd als onze Left stream en 'CustomersStream' als onze Right stream.

Vervolgens zult u een Join type moeten kiezen:

• Full outer - Retourneert alle rijen als er een overeenkomst is in de linker- of rechtertabel. Als er geen overeenkomst is, wordt NULL ingevuld voor de ontbrekende zijde.

• Inner - Retourneert alleen de rijen met overeenkomende waarden in beide tabellen.

• Left outer - Retourneert alle rijen uit de linkertabel en de overeenkomende rijen uit de rechtertabel. Als er geen overeenkomst is, is het resultaat NULL voor de rechter tabelkolommen.

• Right outer - Het tegenovergestelde van een Left outer join. Het retourneert alle rijen uit de rechtertabel en de overeenkomende rijen uit de linkertabel.

• Custom (cross) - Retourneert het Cartesiaanse product van beide tabellen (d.w.z. elke rij uit de eerste tabel gecombineerd met elke rij uit de tweede tabel).

Omdat we in ons geval niet zeker weten of alle klanten in onze customers.csv aanwezig zullen zijn in onze orders.csv (het kunnen alleen de bestellingen van een bepaalde periode zijn), kiezen we een left outside join als join type.

Omdat we de bestellingen in onze orders.csv dataset willen samenvoegen met de klanten in onze customers.csv dataset die deze bestellingen hebben geplaatst, zullen we de juiste klanten aan de juiste bestellingen moeten koppelen. Dit gebeurt via de join condition; een kolom die beide datasets gemeen hebben. Zoals we eerder hebben vermeld, is dit in ons geval de kolom 'customerid'. Selecteer 'customerid' onder Left: OrdersStream's column. Selecteer vervolgens '==' als equality operator, wat betekent dat waarden in de linker- en rechterkolom overeen moeten komen. Selecteer vervolgens ook 'customerid' onder Right: CustomersStream's column.

U zult de verbinding ook gevisualiseerd zien op het canvas erboven, met in totaal 23 kolommen. (13 kolommen uit de OrdersStream en 10 kolommen uit de CustomersStream.)

Op het Optimaliseren tabblad zult u een optie zien die u niet op gelijknamige tabblad heeft gezien toen toen we de datasets hebben toegevoegd: Broadcast. Om te weten wat deze optie doet zult u eerst wat meer over Azure moeten weten. Azure Data Factory is gebaseerd op Apache Spark, een open-sourcetool (gedistribueerd computersysteem) wat is ontworpen voor snelle verwerking van grootschalige data. Het wordt veel gebruikt voor big data-analyse omdat het relatief snel enorme datasets kan verwerken. Dit gebeurt door de gegevens in kleinere stukjes op te delen en ze allemaal tegelijk te verwerken met behulp van meerdere computers. Zo'n groep computers wordt een cluster wordt genoemd, waarbij afzonderlijke computer daarin een node wordt genoemd. Nodes kunnen een master node of een worker node zijn. Master nodes zijn als managers: ze instrueren de worker nodes wat ze moeten doen, terwijl de worker nodes zich bezighouden met het daadwerkelijke werk.

Stel dat u een kleine dataset wilt samenvoegen met een grote dataset. Wanneer u een join maakt, wordt uw data door elkaar geschoven om de join te maken, wat tijd kost. Om dit schuiven van data te voorkomen, kunt u, als de kleine dataset klein genoeg is om in het geheugen van elk worker node te passen, een kopie van de dataset naar elk worker node in het cluster versturen. Omdat elk worker node nu een kopie van de kleine dataset direct beschikbaar heeft, kan het deze snel matchen met zijn deel van de grote dataset zonder alle gegevens door elkaar te hoeven schuiven.

Indien u hier 'auto' aan laat staan, zult u Azure Data Factory laten beslissen of uw datasets voldoen aan de vereisten voor Broadcast. Bij de instelling 'Fixed', daarentegen, zult u moeten beslissen of de kleinere dataset klein genoeg is om te worden uitgezonden. Als het te groot blijkt te zijn, kunt u tegen een foutmelding over onvoldoende geheugen aanlopen. Ten slotte heeft u ook de mogelijkheid om Broadcast uit te schakelen.

Vlak daaronder heeft u wederom een keuze voor Partition option. Aangezien we daar eerder aandacht aan hebben besteed, gaan we er niet verder op in. Voor onze beginnershandleiding houden we de standaardinstellingen aan.

Net als op het Inspect tabblad welke we hebben besproken tijdens het toevoegen van onze datasets, toont het Inspect tabblad hier ons een alleen-lezen weergave van de metagegevens. Hier zien we welke kolommen uit welke datastroom komen, evenals het totale aantal kolommen.

Op het Data preview tabblad ziet u dat de datasets correct zijn samengevoegd. Als de data preview niet werkt voor u, zorg er dan voor dat u de Data flow debug heeft ingeschakeld, zoals we u eerder hebben laten zien. Klik vervolgens op 'Refresh' in de linkerbovenhoek van het Data preview tabblad.

We zullen nu een filter toevoegen. Indien mogelijk is het altijd verstandig om uw data in een zo vroeg mogelijk stadium te filteren. In ons geval zou dit pre-join zijn geweest, omdat er op die manier minder data zal worden verwerkt tijdens de join. Voor demonstratieve doeleinden is het echter goed om te laten zien hoe u een filter kunt toepassen. Klik op het + teken naast de join die we zojuist hebben gemaakt.

Selecteer 'Filter' uit de lijst.

Op het Filter settings tabblad verzint u eerst een naam voor uw filter en selecteert u een inkomende data stroom (de join die we net hebben gemaakt). Klik vervolgens op het veld 'Filter on'. Onder het veld verschijnt een link naar de expressiebouwer. Klik op deze link.

In de expressiebouwer kunt u expressies en functies gebruiken om een ​​filter te maken. In ons geval willen we een filter maken dat alleen de rijen bewaart waarin de country kolom de waarde 'Germany' bevat. We kunnen hiervoor de equals functie gebruiken. Deze functie controleert of beide waarden binnen de functie gelijk zijn, in dit geval of de waarden in de country kolom gelijk zijn aan de waarde 'Germany'. Wanneer u klaar bent met het maken van uw expressie, klikt u op de knop 'Save and finish'.

U zult uw expressie vervolgens zien verschijnen in het Filter on veld.

Als we vervolgens op het Data preview tabblad naar de country kolom kijken, dan zien we alleen maar de waarde 'Germany' staan. Dit betekent dat onze expressie heeft gewerkt.

Vervolgens gaan we een sink transformatie toevoegen, ook wel een sink genoemd. Nadat we onze data hebben getransformeerd door middel van onze join en filter, willen we onze data ergens opslaan. Dit gebeurt via een sink. Voor elke data flow is minimaal één sink nodig, maar u kunt zoveel sinks toevoegen als u nodig acht. Elke sink is gekoppeld aan precies één dataset object of gekoppelde service, dus als u data wilt opslaan in uw Azure SQL Database én in uw Azure Storage Account, dan heeft u daarvoor twee sinks nodig; één voor elke bestemming waar uw data naartoe wilt schrijven.

Om een sink toe te voegen klikt u op het + teken naast uw filter.

Vervolgens selecteert u 'Sink' uit de lijst.

In de configuratie van uw sink verzint u eerst een naam voor uw sink. Vervolgens selecteert u de data stroom waar uw data vandaan zal komen (in ons geval het filter). Daarna zullen we de bestemming moeten selecteren waar we de getransformeerde data naartoe willen schrijven, waarbij we eerst een sink type moeten kiezen:

• Dataset - Dit sink type slaat instructies op over waar uw data wordt opgeslagen, hoe u er verbinding mee kunt maken en wat de structuur van die gegevens is (zoals tabelkolommen of bestandsindeling). Dit is een goede keuze als u de sink wilt hergebruiken in andere activiteiten en pijplines.

• Inline - Het Inline data sink type definieert de details van uw data binnen de sink zelf. Dit is een goede optie voor eenvoudige, eenmalige gebruikssituaties. Het is verstandig om dit type alleen te gebruiken voor kleine datasets, omdat inline data rechtstreeks in de pipeline wordt opgenomen in plaats van in een aparte opslag.

• Cache - Een Cache sink type slaat de data tijdelijk op voor snelle toegang tijdens de verwerking, wat de prestaties ten goede komt omdat het niet herhaaldelijk data uit een langzame bron hoeft op te halen. Dit is ideaal voor grote datasets die meerdere keren in dezelfde data flow worden gebruikt.

Aangezien onze dataset erg klein is zal een inline sink volstaan. Uiteraard dienen we hierna de uiteindelijke bestemming voor onze getransformeerde data te selecteren, wat onze database in onze Azure SQL Database is. Als u hetzelfde doet, zorg er dan voor dat u verbonden bent met uw Azure SQL Database! Dit kan via een applicatie als Azure Data Studio. (Scroll omlaag naar het kopje Azure Data Studio en volg de verbindingsinstructies.) Klik op de knop 'Test connection' en test of de verbinding tot stand is gebracht.

Op het Settings tabblad zult u de volgende opties krijgen:

• Schema name - Uw tabel zal in dit schema worden geschreven. Klik op de knop 'Refresh' om er zeker van te zijn dat al uw bestaande schemanamen zijn geladen. Selecteer vervolgens de juiste schemanaam. Als u dit niet zeker weet (of als u geen flauw idee heeft wat een schema is), lees dan het gedeelte over schema's in deze beginnershandleiding nog eens door.

• Table name - Hier kunt u de naam verzinnen die uw tabel zal krijgen in uw Azure SQL Database. Wij kiezen voor de naam 'orders_customers'.

• Table action - Dit is wat er met de tabel zal gebeuren voordat er naar uw tabel wordt geschreven. Dit is uiteraard vooral belangrijk als u de data flow regelmatig uitvoert.

◦ None - Niets.

◦ Recreate table - De tabel wordt verwijderd en opnieuw gemaakt. Vereist als er dynamisch een nieuwe tabel wordt gemaakt. 

◦ Truncate table - Hierdoor blijft de bestaande tabelstructuur behouden, maar worden eerst alle rijen leeggemaakt en vervolgens de nieuwe rijen ingevoegd.

• Update method - U zult moeten opgeven welke bewerkingen zijn toegestaan ​​op de doeltabel in uw Azure SQL Database. De standaardinstelling is om alleen invoegingen toe te staan.

• Use TempDB - Wanneer we data naar onze Azure SQL Database schrijven, zal de data doorgaans niet rechtstreeks naar de doeltabel gaan, wat vooral het geval is bij grote datasets. De data zal eerst in een tijdelijke opslag worden geladen. Door Use TempDB in te schakelen (de standaardinstelling), gebruikt Azure een tijdelijke tabel in de TempDB database in SQL Server, welke wordt gebruikt voor tijdelijke opslagdoeleinden. Zodra uw data volledig in deze tijdelijke opslag is geladen, zal de data worden verplaatst naar onze Azure SQL Database. Als we echter het gebruik van TempDB uitschakelen, wordt de tijdelijke opslag rechtstreeks in onze Azure SQL Database aangemaakt. Dat klinkt misschien een beetje overbodig, maar dergelijke staging-data fungeert als buffer om het laadproces soepeler, veiliger en efficiënter te maken.

• Pre SQL scripts & Post SQL scripts - U kunt hier SQL-scripts invoeren die worden uitgevoerd vóór (pre-processing) en ná (post-processing) de data naar onze Azure SQL Database wordt geschreven. U kunt dit gebruiken om de vooraf of achteraf geladen data schoon te maken.

Het Errors tabblad Fouten geeft ons opties om te beheren wat er gebeurt als het schrijven naar onze Azure SQL Database, om welke reden dan ook, in de problemen komt. Voor onze beginnershandleiding laten we dit tabblad op de standaardinstellingen staan. Ter informatie geven wij een korte beschrijving van de beschikbare opties:

• Linked service - Hier selecteert u waar u uw getransformeerde data naartoe wilt schrijven. In ons geval zou dit Azure SQL Database zijn. Wanneer u uw gekoppelde dienst heeft geselecteerd, kunt u de verbinding testen.

• SQL error rows - Door middel van deze optie kunt u kiezen wat er gebeurt als er bij het schrijven naar uw database een fout optreedt door beperkingen van de bestemming (Azure SQL Database).

◦ Error row handling - Standaard zal de data flow mislukken bij de eerste fout die wordt aangetroffen. Als alternatief kunt u kiezen voor 'Continue on error', waardoor uw data flow toch zal worden uitgevoerd, ondanks dat individuele rijen fouten bevatten.

◦ Transaction Commit - Met deze optie kunt u kiezen of uw data in batches of in één transactie wordt geschreven. Het laatstgenoemde zal langzamer presteren en er zal geen data zichtbaar zijn totdat de volledige transactie is voltooid.

◦ Output success on error - Als u wilt dat uw data flow als succesvol wordt gemarkeerd ondanks dat er fouten zijn opgetreden, schakelt u deze optie in.

◦ Output to separate file - Hierdoor worden de rijen waarin een fout is opgetreden opgeslagen in een afzonderlijk CSV-bestand in uw Azure Blob Storage- of Azure Data Lake Storage Gen2-account (waarvoor u een bestemming zult moeten opgeven). Aan de rijen die een fout bevatten, worden drie kolommen toegevoegd: de SQL-bewerking (bijvoorbeeld INSERT of UPDATE), de foutcode van de data flow en de foutmelding op de rij.

• Assert failure rows - Als u assertions heeft ingesteld, kunt u hier beheren wat er gebeurt als u fouten tegenkomt met Assert failure rows. In Azure Data Factory is een assertion een regel die u op uw data kunt toepassen om bepaalde voorwaarden te valideren. Het is een soort kwaliteitscontrole. U kunt bijvoorbeeld opgeven dat er in een bepaalde kolom null-waarde voor mag komen. Wanneer deze kolom wel een null-waarde bevat, zult u een foutmelding krijgen. Met de optie Uitvoer naar sink worden deze rijen nog steeds opgenomen in onze Azure SQL Database. Output to separate file zal de rijen met fouten in een afzonderlijk bestand opslaan.

Net als voorheen kunt u op het Optimize tabblad kiezen of u uw data wel of niet opnieuw wilt verdelen nadat u deze heeft getransformeerd. Omdat we al eerder door de beschikbare opties hebben gelopen, slaan we de uitleg hiervan deze deze keer over..

Deze keer laat de alleen-lezen weergave van de metagegevens op het Inspect tabblad de wijziging zien die we zojuist hebben aangebracht in de customerid-kolom, afkomstig van CustomersStream. Controleer daarna op het Data preview tabblad of al uw data aanwezig is. 

Nu we onze data flow hebben afgerond, zullen we de aangebrachte wijzigingen moeten valideren en publiceren.

Door op 'Validate all' te klikken, kunnen we controleren of Azure eventuele fouten tegenkomt in wat we zojuist allemaal hebben ingesteld. Dit is een belangrijke stap voordat we alles proberen te publiceren.

Als alles goed is gegaan, zult u de onderstaande melding moeten zien.

Vervolgens zullen we onze data flow moeten 'publiceren'. Dit betekent dat alle wijzigingen die we tot nu toe hebben aangebracht, worden vastgelegd en opgeslagen. Alles wat we hebben opgezet, gaat 'live'.

Hierna zult de onderstaande melding moeten zien.

Zoals we eerder hebben vermeld, kan een data flow niet worden uitgevoerd zonder pipeline, en dat is wat we nu gaan opzetten. Pipelines kunnen heel uitgebreid zijn, maar in ons geval hebben we slechts een eenvoudige pipeline nodig om onze data flow uit te voeren. We kunnen er een maken door op de + knop onder de kop Factory Resources te klikken, en vervolgens naar Pipeline > Pipeline te gaan.

Vervolgens sleept u eenvoudig de data flow die we zojuist hebben gemaakt naar het canvas.

Geef uw pipeline een naam. Wij hebben gekozen voor de naam 'OrdersTransformationPipeline'.

Bij het werken met pipelines (en data flows) is het belangrijk om in gedachten te houden dat er verschillende niveaus bestaan. Wanneer u een activiteit heeft geselecteerd, zoals de data flow die u zojuist naar het canvas heeft gesleept, zijn de opties die we onder het canvas zien op activiteitenniveau. De instellingen die u daar aanpast, worden toegepast op die specifieke activiteit, niet op de hele pipeline. Als we geen activiteit hebben geselecteerd, bevinden de opties die we onder het canvas zien zich op pipelineniveau. De instellingen die we daar aanpassen zullen op de hele pipeline worden toegepast.

Omdat we onze data flow nog geselecteerd hebben, zullen we kort de configuratieopties op activiteitenniveau doornemen.

• Activity state - Met deze optie kunt u uw pipeline deactiveren zonder dat u deze hoeft te verwijderen.

• Timeout - De time-out van uw pipeline is de tijdsduur die uw pipeline wacht totdat alle activiteiten daarin zijn voltooid. Zodra de duur is bereikt zonder te eindigen, zal er een time-out fout optreden.

• Retry - Hier kunt u het aantal keren instellen dat een mislukte activiteit zichzelf opnieuw kan opstarten zonder handmatige tussenkomst (waarbij iemand de pipeline moet activeren). Als de activiteit bijvoorbeeld mislukt vanwege verbindingsproblemen, kan de activiteit zichzelf opnieuw opstarten.

• Retry interval (sec) - Als er een nieuwe poging benodigd is, zult u het interval voor nieuwe pogingen moeten opgeven. Dit is het aantal seconden dat moet worden gewacht nadat het is mislukt voordat de poging opnieuw wordt uitgevoerd.

• Secure input + Secure output - Afhankelijk van de data waarmee u werkt, heeft u wellicht baat bij het beveiligen van de in- en uitvoer. Dit betekent dat uw activiteiten niet worden vastgelegd in de monitoringsectie van Azure Data Factory.

Voor onze beginnershandleiding laten we alles behalve Name op de standaardinstellingen staan.

Het Settings tabblad bevat de volgende opties:

• Data flow - Als dit nog niet automatisch voor u is geselecteerd, selecteert u hier de juiste data flow.

• Run on (Azure IR) - Selecteer vervolgens de juiste Integration Runtime (IR), wat standaard 'AutoResolveIntegrationRuntime' zal zijn.

• Compute size - Selecteer de juiste Compute size voor uw IR. Data flows worden uitgevoerd op Spark-clusters. De configuratie voor deze clusters wordt gedefinieerd in de IR van de activiteit. Data flows verdelen de gegevensverwerking over verschillende kernen in een Spark-cluster om bewerkingen parallel uit te voeren. Hoe groter het Spark-cluster, hoe meer kernen het bevat; hoe meer kernen het heeft, hoe meer rekenkracht er beschikbaar is. De standaardclustergrootte is 'Small', wat zich vertaalt in vier 'driver' kernen en vier 'worker' kernen. 'Medium' en 'Large' clusters hebben respectievelijk acht en acht, en zestien en zestien driver- en worker-kernen. Wanneer u veel data moet verwerken is het verstandig de clustergrootte te vergroten. Voor onze beginnershandleiding gebruiken we een zeer kleine hoeveelheid data, waarvoor een kleine compute size voldoende is.

• Logging level - Vervolgens zullen we een Logging level moeten kiezen. Dit gaat over de hoeveelheid informatie die wordt vastgelegd over wat er gebeurt als uw data flow wordt uitgevoerd.

◦ Verbose - Verbose is het meest gedetailleerde niveau en registreert elke afzonderlijke stap en partitie in uw data flow volledig. Dit is een goede optie als u de oorzaak van problemen probeert te achterhalen. Het kan echter wel veel data genereren, wat mogelijk meer kosten met zich meebrengt. Verbose is de standaardinstelling.

◦ Basic - Dit logniveau registreert alleen de duur van de dataflow transformaties (hoe lang elke transformatie duurt). Dit kan voldoende zijn om de prestaties te monitoren.

◦ None - Er wordt alleen een samenvatting van de duur gegeven.

Voor onze beginnershandleiding selecteren we alleen onze data flow en IR, en laten we de rest van de instellingen op hun standaardwaarden staan.

Op het Parameters tabblad kunt u dynamische waarden doorgeven aan uw data flow wanneer u deze uitvoert. Dit maakt pipelines en data flows erg flexibel en herbruikbaar. Kunt u zich herinneren dat we een filter aan onze data flow hebben toegevoegd waardoor we alleen de rijen overhielden waar de country kolom de waarde 'Germany' bevatte? Als we dit later zouden willen wijzigen naar een ander land, zouden we daarvoor een nieuwe data flow moeten creëren, omdat de waarde 'Duitsland' hardgecodeerd in ons filter is. Parameters zijn een manier om dat te omzeilen. Ze stellen ons in staat om dynamisch 'Germany' in te voeren, maar het ook naar een ander land te wijzigen wanneer dat nodig is.

Op het User properties tabblad kunt u dynamische informatie (sleutel-waardeparen, maximaal 5 per activiteit) over de activiteit toevoegen, wat u kan helpen bij het monitoren van de prestaties. 

Nu is het tijd om onze pipeline te valideren en te publiceren. Zoals we eerder hebben gedaan, valideert u eerst en klikt u vervolgens op 'Publish all' om alle wijzigingen die we hebben aangebracht te publiceren.

Als alles goed is gegaan, zult u de onderstaande melding te zien krijgen.

Pipelines moeten worden 'getriggered', wat u kunt doen door op 'Trigger now' te klikken, waardoor de pipeline direct wordt uitgevoerd.

Omdat dit onze eerste pipeline run is, kunnen er geen gegevens van een eerdere pipeline runs worden gevonden. Klik nogmaals op 'OK'.

Wanneer uw pijplijn actief is, zult u de onderstaande melding te zien krijgen.

We zullen nu in onze Azure SQL Database controleren of onze getransformeerde data daar met succes is ontvangen. Als u dit nog niet heeft gedaan, start Azure Data Studio op (het losstaande programma wat niet in uw browser wordt uitgevoerd) en maak verbinding met uw database, zoals we al meerdere keren eerder hebben gedaan. Klik op de knop 'Refresh' naast Tables.

Hier zien we nu de tabel die in onze data flow is aangemaakt.

Om er zeker van te zijn dat onze nieuwe tabel de juiste data bevat, kunnen we een query uitvoeren om dit te controleren.

Zoals we kunnen zien bevat onze tabel de juiste gegevens. We zien hier alleen rijen waarin de country kolom de waarde 'Germany' bevat.

Hiermee zijn we bij het einde gekomen in dit deel van onze Azure voor Beginners handleiding. Goed gedaan!