Überlegungen und Einschränkungen - AWS Glue

Überlegungen und Einschränkungen

Berücksichtigen Sie folgende Überlegungen und Einschränkungen, wenn Sie Lake Formation mit AWS Glue verwenden.

AWS Glue mit Lake Formation ist in allen unterstützten Regionen außer AWS GovCloud (USA-Ost) und AWS GovCloud (USA-West) verfügbar.

  • AWS Glue unterstützt eine differenzierte Zugriffskontrolle über Lake Formation nur für Apache-Hive- und Apache-Iceberg-Tabellen. Zu den Apache-Hive-Formaten gehören Parquet, ORC und CSV.

  • Sie können Lake Formation nur mit Spark-Aufträgen verwenden.

  • AWS Glue mit Lake Formation unterstützt nur eine einzige Spark-Sitzung während eines Auftrags.

  • Wenn Lake Formation aktiviert ist, benötigt AWS Glue eine größere Anzahl von Workern, da die Anwendung einen Systemtreiber, System-Executors, einen Benutzertreiber und optional Benutzer-Executors benötigt (erforderlich, wenn Ihr Auftrag UDFs oder spark.createDataFrame hat).

  • AWS Glue with Lake Formation unterstützt nur kontenübergreifende Tabellenabfragen, die über Ressourcenlinks freigegegeben werden. Der Name des Ressourcenlinks muss identisch sein mit dem Namen der Ressource des Quellkontos.

  • Übergeben Sie den --enable-lakeformation-fine-grained-access-Aufgaben-Parameter, um die differenzierte Zugriffskontrolle für AWS-Glue-Aufgaben zu aktivieren.

  • Sie können Ihre AWS-Glue-Aufträge so konfigurieren, dass sie mit der AWS-Glue-Hierarchie mit mehreren Katalogen funktionieren. Informationen zu den Konfigurationsparametern, die mit der AWS-GlueStartJobRun-API verwendet werden können, finden Sie unter Arbeiten mit der AWS-Glue-Hierarchie mit mehreren Katalogen in EMR Serverless.

  • Folgendes wird nicht unterstützt:

    • Resilient Distributed Datasets (RDD)

    • Spark-Streaming

    • Schreiben mit von Lake Formation erteilten Berechtigungen

    • Zugriffskontrolle für verschachtelte Spalten

  • AWS Glue blockiert Funktionen, die die vollständige Isolierung des Systemtreibers untergraben könnten, darunter die folgenden:

    • UDTs, HiveUDFs und alle benutzerdefinierten Funktionen, die benutzerdefinierte Klassen beinhalten

    • Benutzerdefinierte Datenquellen

    • Bereitstellung zusätzlicher JARs für Spark-Erweiterungen, Connectors oder Metastore

    • ANALYZE TABLE command

  • Um Zugriffskontrollen, EXPLAIN PLAN und DDL-Vorgänge durchzusetzen, z. B. DESCRIBE TABLE, sollten eingeschränkte Informationen nicht offengelegt werden.

  • AWS Glue schränkt den Zugriff auf Systemtreiber-Spark-Protokolle für Lake-Formation-fähige Anwendungen ein. Weil der Systemtreiber mit mehr Zugriffsrechten ausgeführt wird, können Ereignisse und Protokolle, die der Systemtreiber generiert, vertrauliche Informationen enthalten. Um zu verhindern, dass ein unbefugter Benutzer oder Code auf diese sensiblen Daten zugreift, hat AWS Glue den Zugriff auf Systemtreiberprotokolle deaktiviert. Wenden Sie sich zur Fehlerbehebung an den AWS-Support.

  • Wenn Sie einen Tabellenspeicherort bei Lake Formation registriert haben, durchläuft der Datenzugriffspfad unabhängig von der IAM-Berechtigung für die AWS-Glue-Auftrag-Laufzeitrolle die gespeicherten Anmeldeinformationen von Lake Formation. Wenn Sie die mit dem Tabellenspeicherort registrierte Rolle falsch konfigurieren, schlagen gesendete Aufträge fehl, die die Rolle mit der S3-IAM-Berechtigung für den Tabellenspeicherort verwenden.

  • Beim Schreiben in eine Lake-Formation-Tabelle werden IAM-Berechtigungen und nicht die von Lake Formation erteilten Berechtigungen verwendet. Wenn Ihre Auftrag-Laufzeitrolle über die erforderlichen S3-Berechtigungen verfügt, können Sie sie zum Ausführen von Schreibvorgängen verwenden.

Im Folgenden werden Einschränkungen und Überlegungen bei der Verwendung von Apache Iceberg aufgeführt:

  • Sie können Apache Iceberg nur mit Sitzungskatalogen und nicht mit beliebig benannten Katalogen verwenden.

  • Iceberg-Tabellen, die in Lake Formation registriert sind, unterstützen nur die Metadatentabellen history, metadata_log_entries, snapshots, files, manifests und refs. AWS Glue blendet die Spalten aus, die möglicherweise sensible Daten enthalten, beispielsweise partitions, path und summaries. Diese Einschränkung gilt nicht für Iceberg-Tabellen, die nicht in Lake Formation registriert sind.

  • Tabellen, die Sie nicht in Lake Formation registrieren, unterstützen alle gespeicherten Iceberg-Prozeduren. Die Prozeduren register_table und migrate werden für keine Tabellen unterstützt.

  • Wir empfehlen Ihnen, Iceberg DataFrameWriterV2 anstelle von V1 zu verwenden.

Beispiel für Worker-Zuordnung

Für einen Auftrag, der mit folgenden Parametern konfiguriert wurde:

--enable-lakeformation-fine-grained-access=true --number-of-workers=20

Die Worker-Zuordnung würde so lauten:

  • Ein Worker für den Benutzertreiber.

  • Ein Worker für den Systemtreiber.

  • 10 % der verbleibenden 18 Worker (d. h. 2 Worker) sind für die Ausführung durch Benutzer-Executors reserviert.

  • Bis zu 16 Worker sind für System-Executors vorgesehen.

Wenn Auto Scaling aktiviert ist, können die Benutzer-Executors bei Bedarf jede der nicht zugewiesenen Kapazitäten der System-Executors nutzen.

Steuern der Benutzer-Executor-Zuordnung

Sie können den Reservierungsprozentsatz für Benutzer-Executors mit der folgenden Konfiguration anpassen:

--conf spark.dynamicAllocation.maxExecutorsRatio=<value between 0 and 1>

Mit dieser Konfiguration kann genau gesteuert werden, wie viele Benutzer-Executors im Verhältnis zur verfügbaren Gesamtkapazität reserviert werden.