Viele Unter­neh­men pla­nen der­zeit, ihre Report­ing und Ana­ly­se­platt­form in die Cloud zu migrie­ren. Zu die­sem Zweck gibt es eine Viel­zahl von Ent­schei­dun­gen zu tref­fen. Die­ser Bei­trag stellt Micro­softs Lösung Syn­apse Ana­ly­tics vor. Diese bie­tet Daten­spei­cher in Dedi­ca­ted SQL Pools, die Daten­in­te­gra­ti­ons­mög­lich­kei­ten der Azure Data Fac­tory sowie Trans­for­ma­tio­nen im alt­be­währ­ten T‑SQL sowie in Spark.

Kom­po­nen­ten

Das Pro­dukt Syn­apse Ana­ly­tics von Micro­soft ent­stand als Erwei­te­rung des Azure SQL Data Ware­house und inte­griert zusätz­lich die Funk­tio­nen des Daten­in­te­gra­ti­ons­tool Azure Data Fac­tory. Für Syn­apse gibt es einer Ent­wick­lungs­um­ge­bung, das Syn­apse Stu­dio. In die­sem gibt es die Mög­lich­keit Pipe­lines zu ent­wi­ckeln, Daten zu erkun­den sowie Abfra­gen mit T‑SQL oder Apa­che Spark zu schreiben.

Auch das Moni­to­ring der Syn­apse ein­zel­nen Syn­apse Workloads kann im Syn­apse Stu­dio geschehen.

SQL Pool

Das klas­si­sche Data Ware­house kann mit Syn­apse mit einem dedi­zier­ten SQL Pool abge­bil­det wer­den. Die­ser  ver­wen­det die MPP (Mas­sive Par­al­lel Pro­ces­sing) Archi­tek­tur. Es  gibt einen Steu­er­kno­ten (Con­trol Node), auf wel­chem die SQL Befehle ankom­men und auf die Rechen­kno­ten (Com­pute Nodes) ver­teilt wer­den. Es gibt abhän­gig von der Ska­lie­rung des Pools bis zu 60 Ser­ver­kno­ten, auf die­sen dann die Queries aus­ge­führt wer­den. Die Abfra­ge­spra­che ist klas­si­sches T‑SQL, jedoch gilt es zu beach­ten, dass Syn­apse SQL bei wei­tem nicht alle Fea­tures von SQL Ser­ver beinhaltet.

Bei der Erstel­lung der Tabel­len muss direkt der Ver­tei­lung der Daten auf die einen ein­zel­nen Kno­ten bestimmt wer­den, dies pas­siert direkt im DDL.

Hier lie­fert Micro­soft drei Varianten:

• Round Robin
• Hash
• Repli­ca­ted

Bei der  Round Robin Ver­tei­lung wer­den die Daten zufäl­lig auf die ein­zel­nen Com­pute Nodes ver­teilt. Diese bie­tet sich für Sta­ging-Tabel­len an, bei denen man den Inhalt der Daten nicht kennt und für wel­che keine häu­fi­gen Abfra­gen geplant sind. Für diese ist die Round Robin Ver­tei­lung ent­spre­chend nicht optimiert.

Die Hash-Ver­tei­lung. Hier gibt es eine deter­mi­nis­ti­sche Funk­tion, die ein­zelne Daten­sätze (immer ganze Zei­len) ein­zel­nen Kno­ten zuord­net. Diese Art der Dis­tri­bu­tion bie­tet sich für große Fak­ten­ta­bel­len mit mehr als sie­ben Mil­lio­nen Ein­trä­gen an. Den Hash-Key kann man auf Spal­ten set­zen. Es bie­tet sich an, den Hash Key auf Spal­ten zu wäh­len, die viele ver­schie­dene Ein­träge haben, keine oder mög­lichst wenige NULL ‑Ein­träge, sowie keine nach denen gefil­tert wird.

CREATE TABLE [dbo].[Fact]
(
    [key_dim1] int,
    [date] datetimeoffset,
    [quantity] int
)
WITH (
    CLUSTERED COLUMNSTORE INDEX,
    DISTRIBUTION = HASH([key_dim1])
);
  

Ein Dat­ums­at­tri­but bie­tet sich nicht als Key an, da viele Abfra­gen auf das Datum fil­tern und im End­ef­fekt nur auf einem Kno­ten ankom­men würden.

Als dritte Alter­na­tive kann man die Daten auch auf alle Ser­ver­kno­ten repli­zie­ren. Dies ist natür­lich die schnellste Lösung, jedoch auch die­je­nige, die am meis­ten Spei­cher­ka­pa­zi­tät erfor­dert. Diese bie­tet sich an für Dimen­si­ons­ta­bel­len, die häu­fig abge­fragt werden.

Als Default wird die Round Robin Dis­tri­bu­tion ver­wen­det. Ach­tung:  Bei der Kopie von Tabel­len mit­tels CREATE TABLE AS SELECT muss die Dis­tri­bu­tion expli­zit ange­ge­ben werden.

Ska­lier­bar­keit

Micro­soft rech­net den Preis des Dedi­ca­ted Pools anhand der Data-Ware­house Ein­hei­ten (DWU), die für die­sen Pool bestellt wer­den. Diese kön­nen ska­liert wer­den, dadurch ska­lie­ren dann die Geschwin­dig­keit der Abfra­gen, des Daten­la­dens aus dem Azure Blob Sto­rage sowie das Schrei­ben von Daten. Auch die Anzahl der phy­si­schen Com­pute Nodes wird ska­liert; wählt man eine Größe von weni­ger als 1000 DWU, so gibt es nur einen Com­pute Node, auf dem alle 60 Dis­tri­bu­tio­nen lie­gen; bei der maxi­ma­len Ska­lie­rung von 30000 DWU gibt es 60 Com­pute Nodes und nur eine Dis­tri­bu­tion pro Knoten.

Dane­ben gibt es Funk­tio­nen zum Workload-Manage­ment, mit dem  kann auch noch für jede Abfrage die Res­sour­cen­klasse gewählt wer­den, durch wel­che die maxi­male Memory Kapa­zi­tät pro Query bestimmt wird. Je grö­ßer die Res­sour­cen­klasse ist, desto grö­ßer ist die diese, jedoch ver­rin­gert sich dabei auch die mög­li­che Anzahl an par­al­lel lau­fen­den Abfragen.

Inte­gra­tion von semi­struk­tu­rel­len Daten

Zum Laden von Daten aus Quel­len im Data Lake Sto­rage gibt es eine Inte­gra­tion mit Poly­Base. Dies ist eine Tech­no­loge mit­hilfe derer Daten aus ver­schie­de­nen Quel­len inte­griert wer­den. Gerade für schnelle Loads aus dem Data Lake biete es sich an, Poly­base zu nutzen.

Für detail­lierte Infor­ma­tio­nen zu Poly­Base lesen Sie bitte auch unse­ren Blog­bei­trag.

Syn­apse Ana­ly­tics bie­tet auch die Mög­lich­keit eine Lake­house Archi­tek­tur zu modellieren.

Es ist häu­fig gewünscht, direkt auf semi­struk­tu­relle Daten im Data Lake zuzugreifen. 

Zu die­sem Behufe erstellt man externe Tabel­len im Dedi­ca­ted Pool. Für diese muss zuerst mit dem Befehl CREATE EXTERNAL DATA SOURCE auf eine Daten­quelle im Azure Data Lake oder einem Hadoop File­sys­tem in Azure ver­wei­sen. Dar­auf­hin muss mit dem Befehl CREATE EXTERNAL FILE FORMAT das For­mat der Dateien (im Dedi­ca­ted Pool CSV oder Par­quet) beschrie­ben wer­den. Der exter­nen Tabelle  muss schließ­lich sowohl DATA_SOURCE als auch FILE_FORMAT als Para­me­ter mit­ge­ge­ben werden.

CREATE EXTERNAL DATA SOURCE my_data_source
WITH (LOCATION = 'https://myazurestorage.blob.core.windows.net/myfolder/',
      TYPE = HADOOP);

CREATE EXTERNAL FILE FORMAT my_file_format
WITH (
    FORMAT_TYPE = PARQUET,
    DATA_COMPRESSION = 'org.apache.io.compress.SnappyCodec');

CREATE EXTERNAL TABLE my_table
(
    col1 int,
    col2 varchar(100)
)
WITH ( LOCATION = '/parquet/',
       DATA_SOURCE = my_data_source,
       FILE_FORMAT = my_file_format);
 

Secu­rity und Access Management

Als Azure-Res­source ist Azure Syn­apse Ana­ly­tics direkt mit dem Azure Active Direc­tory inte­griert. Die sichere Iden­ti­täts- und Zugriffs­ver­wal­tung kann dadurch sicher­ge­stellt werden.

Ser­ver­less SQL Pool

In Azure Syn­apse Ana­ly­tics gibt es nicht nur die Mög­lich­keit, dedi­zierte SQL Pools zu ver­wen­den, son­dern auch on-demand ser­ver­lose Infr­struk­tur. Mit ande­ren Wor­ten Ser­ver­less SQL Pools, von denen einer bei jeder Deploy­ment eines Syn­apse Ana­ly­tics Workspace in Azure bereit­ge­stellt wird. Die­ser bie­tet die klas­si­schen Vor­teile einer ser­ver­lo­sen Archi­tek­tur, also auto­ma­ti­sche Ska­lie­rung der Rechen­res­sour­cen sowie eine Abrech­nung basie­rend auf der tat­säch­lich genutz­ten Menge an Daten und Com­pute Ressourcen.

Daten­in­te­gra­tion und ‑trans­for­ma­tion

Azure Syn­apse Ana­ly­tics bie­tet zusätz­lich noch die Azure Pipe­lines. Diese erin­nern sehr Stark an die Data Fac­tory und bie­ten Daten­in­te­gra­tion mit zahl­rei­chen Kon­nek­to­ren zu Quell­sys­te­men. Als Bei­spiele seien hier Ora­cle, SQL Ser­ver, Sales­force, SAP, S3 sowie die Azure Sto­rage Ange­bote genannt.

Diese Daten­in­te­gra­tion sowie Daten­trans­for­ma­tion mit Spark oder T‑SQL Stored Pro­ce­du­res kann in Syn­apse Pipe­lines orches­triert und geplant wer­den. Es besteht sowohl die Mög­lich­keit die Pipe­lines zu bestimm­ten Zeit lau­fen zu las­sen, als auch Event Trig­ger zu verwenden.

In die­sen Pipe­lines gibt es auch ver­schie­dene Mög­lich­kei­ten zur Trans­for­ma­tion der Daten: Spark-Note­books, T‑SQL Stored Pro­ce­du­res sowie Map­ping Data Flows.

Die bie­ten Trans­for­ma­tio­nen in einer visu­el­len Ober­flä­che, die auf Apa­che Spark basie­ren . Es gilt jedoch zu beach­ten, dass für zum Debug eines Dataf­lows ein Clus­ter hoch­ge­fah­ren wird, wel­ches zusätz­li­che Kos­ten verursacht.

Fazit

Azure Syn­apse Ana­ly­tics bie­tet sich an, wenn man haupt­säch­lich oder aus­schließ­lich im Azure Kos­mos unter­wegs ist. Es gibt eine gute Anbin­dung an Power BI sowie die Mög­lich­keit alte SSIS-Pakete per Lift and Shift zu migrieren.

Die Abhän­gig­keit an Micro­soft kann jedoch auch als Nach­teil auf­ges­fasst wer­den, da mit einem even­tu­el­len Wech­sel des Clou­dan­bie­ters auch große Migra­ti­ons­auf­wände in der Data Ana­ly­tics Platt­form einhergehen.

Wir bei saracus haben Erfah­run­gen mit Syn­apse Ana­ly­tics sowie mit ande­ren Cloud Data Platt­for­men, bei Inter­esse an Bera­tung kom­men Sie auf uns zu.

Quelle

Bild 1

Bild 2

Erfah­ren Sie mehr über Lösun­gen im Bereich DWH oder besu­chen Sie eines unse­rer kos­ten­lo­sen Web­i­nare.