Bewährte Verfahren

Verwenden Sie die folgenden empfohlenen Richtlinien, wenn Sie Ihre serverunabhängigen Instanzen bereitstellen und verwalten und Spark-Anwendungen ausführen.

Best Practices für die Verwendung von Serverless-Instanzen, einschließlich detaillierter Beschreibungen und Referenzlinks
Bewährte Verfahren Beschreibung Referenzlink
Verwenden Sie separate Serviceinstanzen von IBM Analytics Engine für Ihre Entwicklungs-und Produktionsumgebungen. Dies ist ein allgemeines bewährtes Verfahren. Wenn Sie separate IBM Analytics Engine-Instanzen für verschiedene Umgebungen erstellen, können Sie alle Konfigurations-und Codeänderungen testen, bevor Sie sie auf die Produktionsinstanz anwenden. Nicht zutreffend
Upgrade auf die neueste Spark-Version Da Open-Source-Spark-Versionen freigegeben werden, werden sie nach einem Zeitintervall, das für interne Tests erforderlich ist, in IBM Analytics Engine verfügbar gemacht. Achten Sie auf die Ankündigung neuer Spark-Versionen im Abschnitt 'Releaseinformationen' und führen Sie ein Upgrade der Laufzeit Ihrer Instanz durch, um Ihre Anwendungen auf die neueste Spark-Laufzeit zu verschieben. Ältere Laufzeiten werden nicht mehr verwendet und schließlich entfernt, wenn neuere Versionen freigegeben werden. Testen Sie Ihre Anwendungen unbedingt in der neuen Laufzeit, bevor Sie Änderungen an den Produktionsinstanzen vornehmen.
Rollenbasierten Zugriff erteilen Sie sollten allen Benutzern in den IBM Analytics Engine-Instanzen rollenbasierten Zugriff auf Basis ihrer Anforderungen erteilen. Beispiel: Nur Ihr Automatisierungsteam sollte über Berechtigungen zum Übergeben von Anwendungen verfügen, da es Zugriff auf geheime Schlüssel hat und Ihr DevOps-Team nur die Liste aller Anwendungen und deren Status anzeigen kann.
Richtige IBM Cloud Object Storage-Konfiguration auswählen
  • Ausfallsicherheit bei der Notfallwiederherstellung (DR): Sie sollten die Option „Cross Region Resiliency“ IBM Cloud Object Storage verwenden, mit der Ihre Daten in mehreren verschiedenen Städten einer Region gesichert werden. Im Gegensatz dazu sichert die Option für regionale Ausfallsicherheit Daten in einem einzelnen Rechenzentrum.
  • Verschlüsselung: IBM Cloud Object Storage wird mit integrierter Standardverschlüsselung geliefert. Sie können Object Storage auch für die Verwendung des BYOK-Service Key Protect konfigurieren.
  • Serviceberechtigungsnachweise: IBM Cloud Object Storage verwendet standardmäßig Berechtigungsnachweise im IAM-Stil. Wenn Sie mit AWS-Berechtigungsnachweisen arbeiten möchten, müssen Sie die Option "HMAC-Berechtigungsnachweis einschließen" verwenden, wie unter Serviceberechtigungsnachweise beschrieben.
  • Direkte Endpunkte für IBM Cloud Object Storage: Verwenden Sie für die Konnektivität zur IBM Cloud Object Storage-Instanz immer direkte Endpunkte. Dies gilt für die IBM Cloud Object Storage-Ausgangsinstanz sowie für Endpunkte, die von Ihren Anwendungen verwendet werden (entweder Ihr Code oder das, was Sie als Parameter in den Konfigurationen auf Instanzebene oder Anwendungsebene übergeben). Direkte Endpunkte bieten eine bessere Leistung als öffentliche Endpunkte und es fallen keine Gebühren für ausgehende oder eingehende Bandbreite an.
Private Endpunkte für den externen Hive-Metaspeicher verwenden Wenn Sie Spark SQL verwenden und einen externen Metaspeicher wie IBM Cloud Databases for PostgreSQL als Hive-Metaspeicher verwenden möchten, müssen Sie den privaten Endpunkt für die Datenbankverbindung verwenden, um eine bessere Leistung und Kosteneinsparungen zu erzielen.
Anwendungen mit Ressourcenüberbelegung ausführen Jeder serverunabhängigen Analytics Engine-Instanz ist ein Kontingent zugeordnet. Wenn Anwendungen an eine Instanz übergeben werden, werden ihnen Ressourcen aus dem Instanzkontingent zugeordnet. Wenn eine Anwendung Ressourcen über das verfügbare Kontingent hinaus anfordert, wird die Anwendung entweder nicht gestartet oder mit weniger als den angeforderten Ressourcen ausgeführt. Dies kann dazu führen, dass die Anwendung langsamer als erwartet ausgeführt wird oder in einigen Fällen die Anwendung fehlschlägt. Sie sollten immer die aktuelle Ressourcennutzung in einer Instanz überwachen, um sicherzustellen, dass Ihre Anwendungen innerhalb der angegebenen Grenzwerte ausgeführt werden. Sie können die Grenzwerte bei Bedarf über ein Support-Ticket anpassen.
Statische Zuordnung von Ressourcen im Vergleich zur automatischen Skalierung Wenn Sie Anwendungen übergeben, können Sie die Anzahl der Steuerprogramme vorab angeben (statische Zuordnung) oder die Option für automatische Skalierung (dynamische Zuordnung) verwenden. Bevor Sie entscheiden, ob Sie die statische Zuordnung oder die automatische Skalierung verwenden möchten, können Sie einige Benchmarking-Tests ausführen, indem Sie unterschiedliche Datasets mit statischer und automatischer Skalierung verwenden, um die richtige Konfiguration zu finden. Allgemeine Hinweise:
-Wenn Sie die Anzahl der Ressourcen (Kerne und Speicher) kennen, die für Ihre Anwendung erforderlich sind, und sie nicht in verschiedenen Phasen der Anwendungsausführung variieren, wird empfohlen, statische Ressourcen zuzuordnen, um die Leistung zu verbessern.
-Wenn Sie eine optimierte Ressourcenauslastung verwenden möchten, können Sie sich für die automatische Skalierung von Executors entscheiden, bei denen die Executors basierend auf dem tatsächlichen Bedarf der Anwendung zugeordnet werden. Beachten Sie, dass es bei der Verwendung der automatischen Skalierung in Anwendungen zu einer leichten Verzögerung kommen kann.
Weiterleitungsprotokollierung aktivieren und optimieren -Aktivieren Sie die Weiterleitungsprotokollierung für Ihre Serviceinstanz, um Fehler zu beheben, den Fortschritt anzuzeigen und Ausgaben Ihrer Anwendungen zu drucken oder anzuzeigen. Beachten Sie, dass die Protokollweiterleitung Kosten verursacht, die auf der Menge der Protokolle basieren, die in der IBM Log Analysis-Instanz weitergeleitet oder aufbewahrt werden. Je nach Anwendungsfall und Bedarf müssen Sie die optimalen Einstellungen festlegen.
-Wenn Sie die Protokollweiterleitung über die Standard-API aktivieren, sind nur die Treiberprotokolle aktiviert. If you need executor logs as well, for example, if there are errors that you would see only on executors, you need to customize logging to enable executor logging as well. Executor-Protokolle können sehr groß werden. Daher sollten Sie die Optionen zur Optimierung der Anzahl der Protokolle, die an Ihre Protokollierungsinstanz weitergeleitet werden, im Vergleich zu den Informationen, die Sie in den Protokollen für Fehlerbehebungszwecke erhalten, abwägen.
-Befolgen Sie die bewährten Verfahren von IBM Log Analysis, wenn Sie die richtigen Konfigurations-und Suchverfahren auswählen. Sie können beispielsweise den Instanzplan IBM Log Analysis für eine 7-tägige Suche mit der Archivierung von Protokollen in IBM Cloud Object Storage konfigurieren, um Kosten zu sparen. In der Dokumentation zu IBM Log Analysis finden Sie außerdem Informationen zu Verfahren für die Suche nach Protokollen, die Sie interessieren, basierend auf Schlüsselwörtern, Zeitpunkten usw.
Serviceinstanz anpassen -Möglicherweise müssen Sie Ihre Serviceinstanz anpassen, um Python-oder Conda-Pakete zu integrieren, die nicht vorinstalliert sind, oder einige Dateien (Zertifikate oder Konfigurationsdateien), die für Spark-Anwendungen verfügbar gemacht werden sollen. Passen Sie Ihre Instanz entsprechend Ihren Anforderungen mithilfe von Bibliotheksgruppen an und verwenden Sie diese Bibliotheksgruppen, wenn Sie Anwendungen übergeben.
-Die Größe Ihrer Bibliotheksgruppe hat einen Einfluss auf die Anwendungsstartzeit und die Startzeit des Steuerprogramms (wenn Sie Anwendungen automatisch skalieren). Beachten Sie auch, dass es eine Obergrenze für die Größe einer Bibliotheksgruppe gibt, nämlich 2 GB. Wenn also unterschiedliche Anwendungen unterschiedliche Bibliotheksgruppen benötigen, ist es für Sie besser, separate Bibliotheksgruppen zu verwenden, damit sie bei der Übergabe der Anwendung einzeln angegeben werden können.
-Verwenden Sie die Anpassung nur, um Dateien zu integrieren, die nicht durch die Parameter für Anwendungsdetails eingebracht werden können. Siehe Parameter für die Übergabe von Spark-Anwendungen. Sie müssen die funktional entsprechenden Standardparameteroptionen für 'spark-submit' wie die Optionen files, jars, packages und pyFiles verwenden, wenn dies zu Ihrem Anwendungsfall passt. Nur wenn Sie Dateien benötigen, die nicht in eine dieser Kategorien passen, z. B. ein selbst signiertes Zertifikat, eine JAAS-Konfigurationsdatei oder eine .so-Datei, sollten Sie die Option "Anpassung für Dateidownload" verwenden.
Filter beim Abrufen der Anwendungsliste anwenden Wenn Sie eine Liste von Anwendungen in der Benutzerschnittstelle oder über die API oder CLI abrufen müssen, ist es besser, die entsprechenden Filter anzuwenden und die gewünschte Gruppe abzurufen.
Andere Services oder Tools zur Unterstützung von Funktionen verwenden Neben der Verwendung einer IBM Log Analysis-und IBM Cloud Object Storage-Instanz können Sie je nach Anwendungsfall andere unterstützende Tools und Services verwenden. Sie können beispielsweise Apache Airflow (von Ihnen verwaltet) verwenden, um Ihre Anwendungen zu koordinieren, zu planen und zu automatisieren. Sie können auch IBM Secrets Manager verwenden, um die geheimen Schlüssel zu speichern, die für Ihre Anwendungen erforderlich sind, und Ihre Automatisierungsscripts verwenden, um die geheimen Schlüssel aus Secrets Manager zu lesen, bevor Sie Ihre Anwendungen übergeben. Sie können auch mit Ihren Anwendungsargumenten kreativ werden und ein Token übergeben, das erforderlich ist, um die erforderlichen geheimen Schlüssel aus dem Secrets Manager direkt aus Ihrer Anwendung zu lesen.
Instanzen in alternativen Regionen für Sicherung und Disaster-Recovery verwenden Derzeit können IBM Analytics Engine Serverless-Instanzen in zwei Regionen erstellt werden: Dallas (us-south) und Frankfurt (eu-de). Obwohl es empfehlenswert ist, Ihre Instanzen in derselben Region zu erstellen, in der sich Ihre Daten befinden, ist es immer sinnvoll, eine Sicherungsinstanz in einer alternativen Region mit derselben Gruppe von Konfigurationen wie Ihre primäre Instanz zu erstellen, falls die primäre Instanz nicht mehr verfügbar oder nicht verwendbar ist. Ihre Automatisierungen sollten bei Bedarf das Wechseln von Anwendungsübergaben zwischen den beiden Regionen ermöglichen. Nicht zutreffend
Separate Buckets und Serviceberechtigungsnachweise für Anwendungsdateien, Datendateien und Ausgangsinstanz verwenden Verwenden Sie das Prinzip der "Trennung von Problemstellungen", um den Zugriff zwischen verschiedenen Ressourcen zu unterscheiden.
-Speichern Sie keine Daten-oder Anwendungsdateien im Bucket der Ausgangsinstanz.
-Verwenden Sie separate Buckets für Daten und Anwendungsdateien.
-Verwenden Sie separate Zugriffsberechtigungsnachweise (IAM-Schlüsselbasiert) mit eingeschränktem Zugriff auf das Bucket für Anwendungsdateien und das Bucket, das Ihre Daten enthält.
Anwendungen müssen innerhalb von 72 Stunden ausgeführt werden Die Anzahl der Stunden, die eine Anwendung oder ein Kernel ausführen kann, ist begrenzt. Für Sicherheits-und Konformitätspatches werden alle Laufzeiten gestoppt, die länger als 72 Stunden ausgeführt werden. Wenn Sie eine große Anwendung haben, teilen Sie Ihre Anwendung in kleinere Blöcke auf, die innerhalb von 72 Stunden ausgeführt werden. Wenn Sie Spark-Streaming-Anwendungen ausführen, stellen Sie sicher, dass Sie Prüfpunkte konfigurieren und über eine Überwachung verfügen, um Ihre Anwendungen erneut zu starten, wenn sie gestoppt wurden
Spark-Protokoll nur bei Bedarf starten und stoppen Stoppen Sie den Spark-Protokollserver immer, wenn Sie ihn nicht mehr benötigen. Beachten Sie, dass der Spark-Protokollserver kontinuierlich CPU-und Speicherressourcen verbraucht, während sein Status gestartet wird.