POC-Playbook in Synapse: Data Warehousing mit dediziertem SQL-Pool in Azure Synapse Analytics
Dieser Artikel stellt eine allgemeine Methodik zum Vorbereiten und Ausführen eines effektiven Azure Synapse Analytics-Proof of Concept-Projekts (POC) für einen dedizierten SQL-Pool vor.
Hinweis
Dieser Artikel ist Teil der Artikelreihe Azure Synapse Proof of Concept Playbook. Eine Übersicht über die Reihe finden Sie unter Azure Synapse Proof of Concept Playbook.
Tipp
Wenn Sie mit dedizierten SQL-Pools noch nicht vertraut sind, empfehlen wir Ihnen, den Lernpfad Arbeiten mit Data Warehouses mithilfe von Azure Synapse Analytics durchzuarbeiten.
Vorbereiten für POC
Bevor Sie sich für Ihre POC-Ziele in Azure Synapse entscheiden, empfehlen wir Ihnen, zunächst den Artikel Azure Synapse SQL-Architektur zu lesen, um sich mit der Art und Weise vertraut zu machen, wie ein dedizierter SQL-Pool Compute und Speicher trennt, um branchenführende Leistungen zu erzielen.
Identifizieren von Sponsoren und potenziellen Hindernissen
Sobald Sie sich mit Azure Synapse vertraut gemacht haben, müssen Sie sicherstellen, dass Ihr POC über die notwendige Unterstützung verfügt und nicht auf Hindernisse stößt. Gehen Sie wie folgt vor:
- Ermitteln Sie alle Einschränkungen oder Richtlinien, die Ihr Unternehmen in Bezug auf das Verschieben von Daten in die Cloud und das Speichern von Daten dort hat.
- Identifizieren Sie die Unterstützung der Geschäftsleitung und des Unternehmens für ein cloudbasiertes Data Warehouse-Projekt.
- Überprüfen Sie, ob Ihre Workload für Azure Synapse geeignet ist. Weitere Informationen finden Sie unter Dedizierte SQL-Poolarchitektur in Azure Synapse Analytics.
Festlegen der Zeitachse
Ein POC ist eine bereichsbezogene, zeitlich begrenzte Übung mit spezifischen, messbaren Zielen und Metriken, die den Erfolg definieren. Idealerweise sollte es eine gewisse Grundlage in der geschäftlichen Realität haben, sodass die Ergebnisse aussagekräftig sind.
POCs haben das beste Ergebnis, wenn ein Zeitrahmen festgelegt ist (Timebox). Beim Timeboxing wird einer Tätigkeit eine feste und maximale Zeiteinheit zugeordnet. Unserer Erfahrung nach bieten zwei Wochen genug Zeit, um die Arbeit abzuschließen, ohne dass zu viele Anwendungsfälle oder komplexe Testmatrizen erforderlich sind. Wenn Sie innerhalb dieses festen Zeitraums arbeiten, empfehlen wir Ihnen, sich an diesen Zeitplan zu halten:
- Daten laden: Drei Tage oder weniger
- Abfragen: Fünf Tage oder weniger
- Mehrwerttests: Zwei Tage oder weniger
Hier einige Tipps:
- Schätzen Sie realistisch ein, wie viel Zeit Sie für die Erfüllung der Aufgaben in Ihrem Plan benötigen werden.
- Sie sollten sich darüber im Klaren sein, dass die Zeit für die Fertigstellung Ihres POC von der Größe Ihres Datasets, der Anzahl der Datenbankobjekte (Tabellen, Sichten und gespeicherte Prozeduren), der Komplexität der Datenbankobjekte und der Anzahl der zu testenden Schnittstellen abhängt.
- Wenn Sie davon ausgehen, dass Ihr POC länger als vier Wochen ausgeführt wird, sollten Sie den Umfang reduzieren und sich nur auf die wichtigsten Ziele konzentrieren.
- Holen Sie sich die Unterstützung aller führenden Ressourcen und Projektsponsoren für den Zeitplan, bevor Sie mit dem POC beginnen.
Sobald Sie festgestellt haben, dass es keine unmittelbaren Hindernisse gibt und Sie den Zeitplan festgelegt haben, können Sie eine allgemeine Architektur festlegen.
Erstellen einer allgemeinen eingrenzenden Architektur
Eine allgemeine zukünftige Architektur enthält wahrscheinlich viele Datenquellen und Datenconsumer, Big Data-Komponenten und möglicherweise Machine Learning- und KI-Datenconsumer. Damit Ihre POC-Ziele erreichbar (und innerhalb des festgelegten Zeitrahmens) bleiben, entscheiden Sie, welche dieser Komponenten Teil des POC sein werden.
Wenn Sie Azure bereits verwenden, sollten Sie außerdem Folgendes beachten:
- Alle vorhandenen Azure-Ressourcen, die Sie während des POC verwenden können. Beispielsweise können Ressourcen Microsoft Entra ID oder Azure ExpressRoute enthalten.
- Welche Azure-Region(en) Ihr Unternehmen bevorzugt.
- Ein Abonnement, das Sie für POC-Arbeiten außerhalb der Produktionsumgebung verwenden können.
- Der Durchsatz Ihrer Netzwerkverbindung mit Azure.
Wichtig
Stellen Sie sicher, dass Ihr POC einen Teil dieses Durchsatzes verbrauchen kann, ohne die Produktionslösungen zu beeinträchtigen.
Anwenden von Migrationsoptionen
Wenn Sie von einem Data Warehouse-Legacysystem zu Azure Synapse migrieren, sollten Sie einige Fragen beachten:
- Sie migrieren und möchten so wenig wie möglich an den bestehenden Extraktions-, Transformations- und Ladeprozessen (ETL) und der Nutzung des Data Warehouse ändern?
- Migrieren Sie, möchten aber einige umfangreiche Verbesserungen durchführen?
- Erstellen Sie eine völlig neue Datenanalyseumgebung (manchmal auch als Greenfield-Projekt bezeichnet)?
Als nächstes müssen Sie sich Gedanken über Ihre Probleme machen.
Identifizieren aktueller Probleme
Ihr POC sollte Anwendungsfälle enthalten, um potenzielle Lösungen für Ihre aktuellen Probleme zu testen. Dabei stellen sich unter anderem folgende Fragen:
- Welche Lücken in Ihrer derzeitigen Implementierung soll Azure Synapse schließen?
- Welche neuen Geschäftsanforderungen müssen Sie unterstützen?
- Welche Vereinbarungen zum Servicelevel (SLAs) müssen Sie erfüllen?
- Was werden die Workloads sein (z. B. ETL, Batchabfragen, Analysen, Berichtsabfragen oder interaktive Abfragen)?
Als nächstes müssen Sie Ihre POC-Erfolgskriterien festlegen.
Festlegen von POC-Erfolgskriterien
Legen Sie fest, warum Sie einen POC durchführen und definieren Sie klare Ziele. Es ist auch wichtig, dass Sie wissen, welche Ergebnisse Sie von Ihrem POC erwarten und was Sie mit ihnen vorhaben.
Denken Sie daran, dass ein POC ein kurzer und konzentrierter Vorgang sein sollte, um schnell eine begrenzte Anzahl von Konzepten zu testen. Wenn Sie über eine lange Liste von nachzuweisenden Elementen verfügen, möchten Sie diese vielleicht in mehreren POCs unterbringen. POCs können Tore zwischen sich aufweisen, damit Sie bestimmen können, ob sie mit dem nächsten POC fortfahren möchten.
Hier sind einige Beispiele für POC-Ziele:
- Wir müssen wissen, dass die Abfrageleistung für unsere großen, komplexen Berichtsabfragen unseren neuen SLAs entspricht.
- Wir müssen die Abfrageleistung für unsere interaktiven Benutzer kennen.
- Wir müssen wissen, ob unsere bestehenden ETL-Prozesse gut geeignet sind und wo wir sie verbessern müssen.
- Wir müssen wissen, ob wir unsere ETL-Runtimes verkürzen können und um wie viel.
- Wir müssen wissen, dass Synapse Analytics über ausreichende Sicherheitsfunktionen verfügt, um unsere Daten angemessen zu schützen.
Als nächstes müssen Sie einen Testplan erstellen.
Erstellen eines Testplans
Verwenden Sie Ihre Ziele und identifizieren Sie spezifische Tests, die Sie ausführen müssen, um diese Ziele zu unterstützen und Ihre identifizierten Ergebnisse zu liefern. Es ist wichtig, dass Sie mindestens einen Test für jedes Ziel und die erwartete Ausgabe haben. Identifizieren Sie spezifische Abfragen, Berichte, ETL und andere Prozesse, die Sie ausführen werden, um quantifizierbare Ergebnisse zu erzielen.
Optimieren Sie Ihre Tests, indem Sie mehrere Testszenarien hinzufügen, um alle Fragen zur Tabellenstruktur zu klären, die sich ergeben.
Eine gute Planung definiert in der Regel eine effektive POC-Ausführung. Stellen Sie sicher, dass alle Beteiligten einem schriftlichen Testplan zustimmen, der jedes POC-Ziel mit einer Reihe von klar definierten Testfällen und Erfolgsmessungen festlegt.
Die meisten Testpläne drehen sich um die Leistung und das erwartete Erlebnis für den Benutzer. Im Folgenden finden Sie ein Beispiel für einen Testplan. Es ist wichtig, dass Sie Ihren Testplan an die geschäftlichen Anforderungen anpassen. Eine klare Definition dessen, was Sie testen, wird sich später in diesem Prozess auszahlen.
| Zielsetzung | Test | Erwartete Ergebnisse |
|---|---|---|
| Wir müssen wissen, dass die Abfrageleistung für unsere großen, komplexen Berichtsabfragen unseren neuen SLAs entspricht. | - Sequenzieller Test komplexer Abfragen - Parallelitätstest komplexer Abfragen für angegebene SLAs |
- Die Abfragen A, B und C wurden in 10, 13 und 21 Sekunden abgeschlossen. - Bei 10 gleichzeitigen Benutzern wurden die Abfragen A, B und C im Durchschnitt in 11, 15 und 23 Sekunden abgeschlossen. |
| Wir müssen die Abfrageleistung für unsere interaktiven Benutzer kennen. | - Parallelitätstest ausgewählter Abfragen bei einem erwarteten Parallelitätsgrad von 50 Benutzern. - Ausführen der vorherigen Abfrage mit Zwischenspeicherung des Resultsets |
- Bei 50 gleichzeitigen Benutzern dürfte die durchschnittliche Ausführungszeit unter 10 Sekunden liegen, und zwar ohne Zwischenspeicherung des Resultsets - Bei 50 gleichzeitigen Benutzern dürfte die durchschnittliche Ausführungszeit mit Zwischenspeicherung des Resultsets unter fünf Sekunden liegen |
| Wir müssen wissen, ob unsere bestehenden ETL-Prozesse innerhalb der SLA ausgeführt werden können. | - Ausführen von einem oder zwei ETL-Prozessen, um die Produktionslasten zu simulieren | - Das inkrementelle Laden in eine zentrale Faktentabelle muss in weniger als 20 Minuten abgeschlossen sein (einschließlich Staging und Datenbereinigung) - Die Verarbeitung der Dimensionen muss weniger als fünf Minuten dauern |
| Wir müssen wissen, dass das Data Warehouse über ausreichende Sicherheitsfunktionen verfügt, um unsere Daten zu schützen. | - Überprüfen und aktivieren der Netzwerksicherheit (VNet und private Endpunkte), Zugriffssteuerung (Sicherheit auf Zeilenebene, dynamische Datenmaskierung) | - Beweisen, dass die Daten unseren Mandanten nie verlassen - Sicherstellen, dass Kundeninhalte leicht zu sichern sind |
Als nächstes müssen Sie das POC-Dataset identifizieren und überprüfen.
Identifizieren und Überprüfen des POC-Datasets
Mithilfe der bereichsbezogenen Tests können Sie jetzt das Dataset identifizieren, das für die Ausführung dieser Tests in Azure Synapse erforderlich ist. Überprüfen Sie Ihr Dataset unter Berücksichtigung der folgenden Punkte:
- Vergewissern Sie sich, dass das Dataset Ihrem Produktionsdataset in Bezug auf Inhalt, Komplexität und Skalierung angemessen repräsentiert.
- Verwenden Sie kein zu kleines Dataset (weniger als 1 TB), da Sie sonst möglicherweise keine repräsentative Leistung erzielen.
- Verwenden Sie kein zu großes Dataset, da der POC nicht für eine vollständige Datenmigration gedacht ist.
- Identifizieren Sie das Verteilungsmuster, die Indizierungsoption und die Partitionierung für jede Tabelle. Wenn es Fragen zur Verteilung, Indizierung oder Partitionierung gibt, fügen Sie Ihrem POC Tests hinzu, um sie zu beantworten. Denken Sie daran, dass Sie vielleicht mehr als eine Verteilung- oder Indizierungsoption für einige Tabellen testen möchten.
- Erkundigen Sie sich bei den unternehmensbesitzenden Personen, ob es Hindernisse für die Übertragung des POC-Datasets in die Cloud gibt.
- Identifizieren Sie alle Bedenken hinsichtlich Sicherheit und Datenschutz.
Wichtig
Stellen Sie sicher, dass Sie die Geschäftsbesitzer auf Blocker überprüfen, bevor Sie Daten in die Cloud verschieben. Identifizieren Sie Sicherheits- oder Datenschutzbedenken oder etwaige Datenobfuskationsanforderungen, die erfüllt werden müssen, bevor Sie Daten in die Cloud verschieben.
Als nächstes müssen Sie das Expertenteam zusammenstellen.
Zusammenstellen des Teams
Bestimmen Sie die Teammitglieder und deren Verpflichtung zur Unterstützung Ihres POC. Zu den Teammitgliedern sollten gehören:
- Ein Projektmanager, der das POC-Projekt leitet.
- Einen Geschäftsvertreter, der Anforderungen und Ergebnisse überwacht.
- Ein Experte für Anwendungsdaten, um die Daten für das POC-Dataset zu beschaffen.
- Ein Azure Synapse-Spezialist.
- Einen beratenden Experten, der die POC-Tests optimiert.
- Alle Personen, die für bestimmte Aufgaben des POC-Projekts benötigt werden, aber nicht für die gesamte Dauer des Projekts erforderlich sind. Zu diesen unterstützenden Ressourcen können Netzwerkadministrator*innen, Azure-Administrator*innen oder Microsoft Entra-Administrator*innen gehören.
Tipp
Wir empfehlen, einen Experten zu engagieren, der Sie beim POC unterstützt. Die Partnercommunity von Microsoft bietet eine weltweite Verfügbarkeit von Experten, die Ihnen helfen können, Azure Synapse zu bewerten, zu beurteilen oder zu implementieren.
Nachdem Sie jetzt vollständig vorbereitet sind, ist es an der Zeit, Ihren POC in die Praxis umzusetzen.
Umsetzen des POC in die Praxis
Es ist wichtig, Folgendes zu beachten:
- Implementieren Sie Ihr POC-Projekt mit der Disziplin und Strenge eines beliebigen Produktionsprojekts.
- Führen Sie den POC wie geplant aus.
- Sorgen Sie dafür, dass Ihr POC-Anwendungsbereich nicht erweitert oder verändert wird, indem Sie einen Change Request einrichten.
Bevor die Tests beginnen können, müssen Sie die Testumgebung einrichten. Dies umfasst vier Phasen:
- Einrichten
- Laden von Daten
- Abfragen
- Tests mit Mehrwert
Setup
Sie können einen POC für Azure Synapse einrichten, indem Sie die folgenden Schritte ausführen:
- Verwenden Sie diesen Schnellstart, um einen Synapse-Arbeitsbereich einzurichten und Speicher und Berechtigungen gemäß dem POC-Testplan festzulegen.
- Verwenden Sie diesen Schnellstart, um dem Synapse-Arbeitsbereich einen eigenen SQL-Pool hinzuzufügen.
- Richten Sie Netzwerk und Sicherheit nach Ihren Anforderungen ein.
- Gewähren Sie den Mitgliedern des POC-Teams angemessenen Zugriff. In diesem Artikel finden Sie Informationen zur Authentifizierung und Autorisierung für den Zugriff auf dedizierte SQL-Pools.
Tipp
Wir empfehlen Ihnen, die Entwicklung von Code- und Komponententests mithilfe des DW500c-Servicelevels (oder darunter) vorzunehmen. Wir empfehlen Ihnen, Last- und Leistungstests mithilfe des DW1000c-Servicelevels (oder höher) auszuführen. Sie können das Compute des dedizierten SQL-Pools jederzeit unterbrechen, um die Computeabrechnung zu beenden und so Kosten zu sparen.
Laden von Daten
Sobald Sie den dedizierten SQL-Pool festgelegt haben, können Sie die folgenden Schritte ausführen, um Daten zu laden:
- Laden Sie die Daten in Azure Blob Storage. Für einen POC empfehlen wir Ihnen, ein universelles V2-Speicherkonto mit lokal redundantem Speicher (LRS) zu verwenden. Es gibt zwar mehrere Tools für die Migration von Daten in Azure Blob Storage, aber am einfachsten ist es, den Azure Storage-Explorer zu verwenden, der Dateien in einen Speichercontainer kopieren kann.
- Laden Sie die Daten in den dedizierten SQL-Pool. Azure Synapse unterstützt zwei T-SQL-Lademethoden: PolyBase und die COPY-Anweisung. Sie können SSMS verwenden, um eine Verbindung mit dem dedizierten SQL-Pool herzustellen, damit Sie eine der beiden Methoden verwenden können.
Wenn Sie zum ersten Mal Daten in den dedizierten SQL-Pool laden, müssen Sie überlegen, welches Verteilungsmuster und welche Indexoption Sie verwenden. Obwohl ein dedizierter SQL-Pool eine Vielzahl von beiden unterstützt, ist es eine bewährte Methode, sich auf die Standardeinstellungen zu verlassen. Die Standardeinstellungen verwenden eine Roundrobin-Verteilung und einen gruppierten Columnstore-Index. Falls erforderlich, können Sie diese Einstellungen später anpassen, was weiter unten in diesem Artikel beschrieben wird.
Das folgende Beispiel zeigt die COPY-Lademethode:
--Note when specifying the column list, input field numbers start from 1
COPY INTO
test_1 (Col_1 default 'myStringDefault' 1, Col_2 default 1 3)
FROM
'https://myaccount.blob.core.windows.net/myblobcontainer/folder1/'
WITH (
FILE_TYPE = 'CSV',
CREDENTIAL = (IDENTITY = 'Storage Account Key' SECRET = '<Your_Account_Key>'),
FIELDQUOTE = '"',
FIELDTERMINATOR = ',',
ROWTERMINATOR = '0x0A',
ENCODING = 'UTF8',
FIRSTROW = 2
);
Abfragen
Der Hauptzweck eines Data Warehouses ist die Durchführung von Analysen, was eine Abfrage des Data Warehouses erfordert. Die meisten POCs beginnen damit, eine kleine Anzahl repräsentativer Abfragen für das Data Warehouse auszuführen, zunächst sequentiell und dann gleichzeitig. Sie sollten beide Ansätze in Ihrem Testplan definieren.
Sequenzielle Abfragetests
Es ist ganz einfach, sequenzielle Abfragetests in SSMS auszuführen. Es ist wichtig, dass Sie diese Tests mithilfe eines Benutzers mit einer ausreichend großen Ressourcenklasse ausführen. Eine Ressourcenklasse ist ein vorher festgelegtes Ressourcenlimit in einem dedizierten SQL-Pool, das die Computeressourcen und die Parallelität bei der Ausführung von Abfragen regelt. Für einfache Abfragen empfehlen wir, die vordefinierte Ressourcenklasse staticrc20 zu verwenden. Für komplexere Abfragen empfehlen wir, die vordefinierte Ressourcenklasse staticrc40 zu verwenden.
Beachten Sie, dass die folgende erste Abfrage eine Abfragebezeichnung verwendet, um einen Mechanismus zur Nachverfolgung der Abfrage bereitzustellen. Die zweite Abfrage verwendet die dynamische Verwaltungssicht sys.dm_pdw_exec_requests für die Suche nach der Bezeichnung.
/* Use the OPTION(LABEL = '') Syntax to add a query label to track the query in DMVs */
SELECT TOP (1000)
*
FROM
[dbo].[Date]
OPTION (LABEL = 'Test1');
/* Use sys.dm_pdw_exec_requests to determine query execution duration (ms) */
SELECT
Total_elapsed_time AS [Elapsed_Time_ms],
[label]
FROM
sys.dm_pdw_exec_requests
WHERE
[label] = 'Test1';
Gleichzeitige Abfragetests
Nachdem Sie die Leistung sequenzieller Abfragen aufgezeichnet haben, können Sie anschließend mehrere Abfragen gleichzeitig ausführen. Auf diese Weise können Sie eine Business Intelligence-Workload simulieren, die für den dedizierten SQL-Pool ausgeführt wird. Am einfachsten können Sie diesen Test ausführen, indem Sie ein Belastungstesttool herunterladen. Das beliebteste Tool ist Apache JMeter, ein Open Source-Tool eines Drittanbieters.
Das Tool berichtet über die minimale, maximale und mittlere Dauer von Abfragen für einen bestimmten Parallelitätsgrad. Nehmen wir z. B. an, Sie möchten eine Business Intelligence-Workload simulieren, die 100 gleichzeitige Abfragen generiert. Sie können JMeter so einrichten, dass es diese 100 gleichzeitigen Abfragen in einer Schleife ausführt und dann die stabile Ausführung überprüft. Es kann mit aktiviertem oder deaktiviertem Zwischenspeichern des Resultsets erfolgen, um die Eignung dieses Features auszuwerten.
Achten Sie darauf, Ihre Ergebnisse zu dokumentieren. Hier ist ein Beispiel für einige Ergebnisse:
| Parallelität | Anzahl ausgeführter Abfragen | DWU | Min. Dauer (s) | Max. Dauer (s) | Mittlere Dauer (s) |
|---|---|---|---|---|---|
| 100 | 1\.000 | 5\.000 | 3 | 10 | 5 |
| 50 | 5\.000 | 5\.000 | 3 | 6 | 4 |
Gemischte Workloadtests
Das Testen gemischter Workloads ist eine Erweiterung der Tests für gleichzeitige Abfragen. Durch das Hinzufügen eines Datenladevorgangs zur Workloadkombination wird die Workload eine echte Produktionsworkload besser simulieren.
Optimieren der Daten
Je nach der in Azure Synapse ausgeführten Abfrageworkload müssen Sie möglicherweise die Data Warehouse-Verteilungen und -Indizes optimieren und die Tests erneut durchführen. Weitere Informationen finden Sie unter Best Practices für dedizierte SQL-Pools in Azure Synapse Analytics.
Die häufigsten Fehler, die bei der Einrichtung auftreten, sind:
- Große Abfragen werden mit einer zu niedrigen Ressourcenklasse ausgeführt.
- Die Servicelevel-DWUs des dedizierten SQL-Pools sind für die Workload zu niedrig.
- Große Tabellen erfordern eine Hashverteilung.
Zum Verbessern der Abfrageleistung können Sie wie folgt vorgehen:
- Erstellen Sie materialisierte Sichten, die Abfragen mit gemeinsamen Aggregationen beschleunigen können.
- Replizieren Sie Tabellen, insbesondere bei kleinen Dimensionstabellen.
- Nehmen Sie eine Hashverteilung für große Faktentabellen vor, die verknüpft oder aggregiert werden.
Tests mit Mehrwert
Sobald Sie die Abfrageleistung getestet haben, ist es an der Zeit, bestimmte Features zu testen, um zu überprüfen, ob sie die von Ihnen beabsichtigten Anwendungsfälle erfüllen. Zu diesen Features zählen:
- Sicherheit auf Zeilenebene
- Sicherheit auf Spaltenebene
- Dynamische Datenmaskierung
- Clusterinterne Skalierung über Workloadisolation
Schließlich müssen Sie Ihre POC-Ergebnisse interpretieren.
Interpretieren der POC-Ergebnisse
Sobald Testergebnisse für Ihr Data Warehouse vorliegen, ist es wichtig, diese Daten zu interpretieren. Ein gängiger Ansatz ist der Vergleich der Ausführungen in Bezug auf Preis/Leistung. Einfach ausgedrückt: Preis/Leistung entfernt die Unterschiede im Preis pro DWU oder Diensthardware und liefert einen einzelnen vergleichbaren Wert für jeden Leistungstest.
Hier sehen Sie ein Beispiel:
| Test | Testdauer | DWU | USD/Std für DWU | Testkosten |
|---|---|---|---|---|
| Test 1 | 10 Min. | 1000 | 12 USD/Std | 2 USD |
| Test 2 | 30 Min. | 500 | 6 USD/Std | $3 |
An diesem Beispiel lässt sich leicht erkennen, dass Test 1 bei DWU1000 mit 2 USD pro Testlauf kostengünstiger ist als mit 3 USD pro Testlauf.
Hinweis
Sie können diese Methode auch verwenden, um Ergebnisse anbieterübergreifend in einem POC zu vergleichen.
Zusammenfassend lässt sich sagen, dass Sie, sobald Sie alle POC-Tests abgeschlossen haben, die Ergebnisse auswerten können. Beginnen Sie mit der Auswertung, ob die POC-Ziele erreicht und die gewünschten Ergebnisse gesammelt wurden. Notieren Sie sich, wo zusätzliche Tests gerechtfertigt sind und welche zusätzlichen Fragen aufgeworfen wurden.