Succesmethodologie voor Synapse-implementatie: Serverloze SQL-poolontwerp evalueren

Notitie

Dit artikel maakt deel uit van het succes van de Azure Synapse-implementatie door ontwerpreeksen . Zie Azure Synapse-implementatie geslaagd voor een overzicht van de reeks.

U moet het ontwerp van uw serverloze SQL-pool evalueren om problemen te identificeren en te valideren dat deze voldoet aan richtlijnen en vereisten. Door het ontwerp te evalueren voordat de ontwikkeling van oplossingen begint, kunt u obstakels en onverwachte ontwerpwijzigingen voorkomen. Op die manier beveiligt u de tijdlijn en het budget van het project.

De architectuurscheiding van opslag en berekening voor moderne gegevens, analytische platforms en services is een trend en veelgebruikt patroon. Het biedt kostenbesparingen en meer flexibiliteit, waardoor uw opslag en rekenkracht onafhankelijk op aanvraag kunnen worden geschaald. Synapse SQL breidt dit patroon uit door de mogelijkheid toe te voegen om rechtstreeks query's uit te voeren op uw data lake-gegevens. U hoeft zich geen zorgen te maken over rekenbeheer bij het gebruik van selfservicetypen van workloads.

Analyse van hiaat passend maken

Wanneer u van plan bent om serverloze SQL-pools in Azure Synapse te implementeren, moet u eerst controleren of serverloze pools geschikt zijn voor uw workloads. Houd rekening met operationele uitmuntendheid, prestatie-efficiëntie, betrouwbaarheid en beveiliging.

Operationele uitmuntendheid

Evalueer de volgende punten voor operationele uitmuntendheid.

• Ontwikkelomgeving voor oplossingen: binnen deze methodologie is er een evaluatie van de ontwikkelomgeving voor oplossingen. Bepaal hoe de omgevingen (ontwikkeling, test en productie) zijn ontworpen ter ondersteuning van de ontwikkeling van oplossingen. Meestal vindt u een productie- en niet-productieomgeving (voor ontwikkeling en test). U moet Synapse-werkruimten vinden in alle omgevingen. In de meeste gevallen bent u verplicht om uw productie- en ontwikkelings- en testgebruikers en workloads te scheiden.
• Ontwerp van Synapse-werkruimte: Binnen deze methodologie is er een evaluatie van het Synapse-werkruimteontwerp. Bepaal hoe de werkruimten zijn ontworpen voor uw oplossing. Raak vertrouwd met het ontwerp en weet of de oplossing één werkruimte gebruikt of dat meerdere werkruimten deel uitmaken van de oplossing. Weet waarom een of meer werkruimteontwerpen zijn gekozen. Een ontwerp met meerdere werkruimten wordt vaak gekozen om strikte beveiligingsgrenzen af te dwingen.
• Implementatie: serverloze SQL is on-demand beschikbaar voor elke Synapse-werkruimte, dus er zijn geen speciale implementatieacties vereist. Controleer de regionale nabijheid van de service en dat van het Azure Data Lake Storage Gen2-account (ADLS Gen2) waarmee deze is verbonden.
• Bewaking: Controleer of ingebouwde bewaking voldoende is en of er externe services moeten worden geplaatst om historische logboekgegevens op te slaan. Met logboekgegevens kunt u wijzigingen in prestaties analyseren en kunt u waarschuwingen of geactiveerde acties definiëren voor specifieke omstandigheden.

Prestatie-efficiëntie

In tegenstelling tot traditionele database-engines is serverloze SQL niet afhankelijk van een eigen geoptimaliseerde opslaglaag. Daarom zijn de prestaties sterk afhankelijk van de manier waarop gegevens worden georganiseerd in ADLS Gen2. Evalueer de volgende punten voor prestatie-efficiëntie.

• Gegevensopname: Controleer hoe gegevens worden opgeslagen in de data lake. Bestandsgrootten, het aantal bestanden en de mapstructuur hebben allemaal invloed op de prestaties. Houd er rekening mee dat hoewel sommige bestandsgrootten voor SQL serverloos kunnen werken, ze problemen kunnen opleggen voor efficiënte verwerking of verbruik door andere engines of toepassingen. U moet het ontwerp voor gegevensopslag evalueren en valideren op alle gegevensgebruikers, inclusief serverloze SQL-hulpprogramma's en andere gegevenshulpprogramma's die deel uitmaken van uw oplossing.
• Plaatsing van gegevens: evalueer of uw ontwerp uniforme en gedefinieerde algemene patronen voor gegevensplaatsing heeft. Zorg ervoor dat adreslijstvertakking uw beveiligingsvereisten kan ondersteunen. Er zijn enkele veelvoorkomende patronen waarmee u uw tijdreeksgegevens georganiseerd kunt houden. Wat u ook kiest, zorg ervoor dat het ook werkt met andere engines en workloads. Controleer ook of het automatisch detecteren van Spark-toepassingen en externe tabellen kan helpen partitioneren.
• Gegevensindelingen: in de meeste gevallen biedt serverloze SQL de beste prestaties en betere compatibiliteitsfuncties met behulp van een Parquet-indeling. Controleer uw prestatie- en compatibiliteitsvereisten, omdat Parquet de prestaties verbetert , dankzij betere compressie en vermindering van IO (door alleen vereiste kolommen te lezen die nodig zijn voor analyse) - er meer rekenresources nodig zijn. Omdat sommige bronsystemen Parquet niet standaard ondersteunen als exportindeling, kan dit leiden tot meer transformatiestappen in uw pijplijnen en/of afhankelijkheden in uw algehele architectuur.
• Verkenning: Elke branche is anders. In veel gevallen zijn er echter algemene patronen voor gegevenstoegang gevonden in de meest frequent uitgevoerde query's. Patronen omvatten doorgaans filteren en aggregaties op datums, categorieën of geografische regio's. Identificeer uw meest voorkomende filtercriteria en koppel deze aan hoeveel gegevens worden gelezen/verwijderd door de meest frequent uitgevoerde query's. Controleer of de informatie over de data lake is georganiseerd om uw verkenningsvereisten en verwachtingen te bevorderen. Voor de query's die zijn geïdentificeerd in uw ontwerp en in uw evaluatie, controleert u of u overbodige partities in uw OPENROWSET-padparameter kunt elimineren of , als er externe tabellen zijn, of het maken van meer indexen kan helpen.

Betrouwbaarheid

Evalueer voor betrouwbaarheid de volgende punten.

• Beschikbaarheid: Valideer eventuele beschikbaarheidsvereisten die zijn geïdentificeerd tijdens de evaluatiefase. Hoewel er geen specifieke SLA's zijn voor serverloze SQL-servers, is er een time-out van 30 minuten voor het uitvoeren van query's. Identificeer de langst lopende query's uit uw evaluatie en valideer deze op basis van uw serverloze SQL-ontwerp. Een time-out van 30 minuten kan de verwachtingen voor uw workload verbreken en worden weergegeven als een serviceprobleem.
• Consistentie: serverloze SQL is voornamelijk ontworpen voor leesworkloads. Valideer dus of alle consistentiecontroles zijn uitgevoerd tijdens het data lake-inrichtings- en vormingsproces. Zorg ervoor dat nieuwe mogelijkheden, zoals de opensource-opslaglaag van Delta Lake , die ondersteuning biedt voor ACID-garanties (atomiciteit, consistentie, isolatie en duurzaamheid) voor transacties. Met deze mogelijkheid kunt u effectieve lambda- of Kappa-architecturen implementeren ter ondersteuning van zowel streaming- als batchgebruiksscenario's. Zorg ervoor dat u uw ontwerp evalueert op mogelijkheden om nieuwe mogelijkheden toe te passen, maar niet ten koste van de tijdlijn of kosten van uw project.
• Back-up: Controleer eventuele vereisten voor herstel na noodgevallen die zijn geïdentificeerd tijdens de evaluatie. Valideer deze op basis van uw serverloze SQL-ontwerp voor herstel. Sql serverloos zelf heeft geen eigen opslaglaag en waarvoor momentopnamen en back-upkopieën van uw gegevens moeten worden verwerkt. Het gegevensarchief dat wordt geopend door serverloze SQL, is extern (ADLS Gen2). Bekijk het herstelontwerp in uw project voor deze gegevenssets.

Beveiliging

De organisatie van uw gegevens is belangrijk voor het bouwen van flexibele beveiligingsfundamenten. In de meeste gevallen hebben verschillende processen en gebruikers verschillende machtigingen en toegang nodig tot specifieke subgebieden van uw Data Lake of logisch datawarehouse.

Evalueer voor beveiliging de volgende punten.

• Gegevensopslag: Met behulp van de gegevens die tijdens de evaluatiefase zijn verzameld, kunt u bepalen of typische gebieden voor onbewerkte gegevens, fasen en gecureerde data lake-gebieden moeten worden geplaatst in hetzelfde opslagaccount in plaats van onafhankelijke opslagaccounts. Dit laatste kan leiden tot meer flexibiliteit in termen van rollen en machtigingen. Er kan ook meer IOPS-capaciteit (input/output operations per seconde) worden toegevoegd die mogelijk nodig zijn als uw architectuur zware en gelijktijdige lees-/schrijfworkloads moet ondersteunen (zoals realtime- of IoT-scenario's). Controleer of u verder moet scheiden door uw sandbox- en hoofdgegevensgebieden in afzonderlijke opslagaccounts te bewaren. De meeste gebruikers hoeven geen gegevens bij te werken of te verwijderen, dus ze hebben geen schrijfmachtigingen nodig voor de data lake, met uitzondering van sandbox- en privégebieden.
• Bepaal op basis van uw evaluatiegegevens of vereisten afhankelijk zijn van beveiligingsfuncties zoals Always Encrypted, dynamische gegevensmaskering of beveiliging op rijniveau. Valideer de beschikbaarheid van deze functies in specifieke scenario's, zoals bij gebruik met de functie OPENROWSET. Verwacht mogelijke tijdelijke oplossingen die mogelijk vereist zijn.
• Bepaal op basis van uw evaluatiegegevens wat de beste verificatiemethoden zijn. Overweeg service-principals van Microsoft Entra, Shared Access Signature (SAS) en wanneer en hoe passthrough voor verificatie kan worden gebruikt en geïntegreerd in het verkenningsprogramma van de klant. Evalueer het ontwerp en valideer of de beste verificatiemethode deel uitmaakt van het ontwerp.

Overige overwegingen

Controleer uw ontwerp en controleer of u best practices en aanbevelingen hebt ingevoerd. Besteed speciale aandacht aan filteroptimalisatie en sortering om ervoor te zorgen dat predicaatpush naar behoren werkt.

Volgende stappen

In het volgende artikel in de azure Synapse-serie voor succes per ontwerp leert u hoe u het ontwerp van uw Spark-pool evalueert om problemen te identificeren en te valideren dat deze voldoet aan richtlijnen en vereisten.