Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Daten optimieren
Die Leistung hängt nicht nur von Abfragen ab, sondern vor allem auch davon, wie Ihr Datensatz organisiert ist und welches Dateiformat und welche Komprimierung er verwendet.
Ihre Daten partitionieren
Durch die Partitionierung wird Ihre Tabelle in Teile aufgeteilt und die zugehörigen Daten werden auf der Grundlage von Eigenschaften wie Datum, Land oder Region zusammengefasst. Partitionsschlüssel fungieren als virtuelle Spalten. Sie definieren Partitionsschlüssel bei der Tabellenerstellung und verwenden sie zum Filtern Ihrer Abfragen. Wenn Sie nach Partitionsschlüsselspalten filtern, werden nur Daten aus übereinstimmenden Partitionen gelesen. Wenn Ihr Datensatz beispielsweise nach Datum partitioniert ist und Ihre Abfrage über einen Filter verfügt, der nur auf die letzte Woche zutrifft, werden nur die Daten der letzten Woche gelesen. Weitere Informationen zur Partitionierung finden Sie unter Ihre Daten partitionieren.
Wählen Sie Partitionsschlüssel aus, die Ihre Abfragen unterstützen
Da die Partitionierung erhebliche Auswirkungen auf die Abfrageleistung hat, sollten Sie beim Entwerfen Ihres Datensatzes und Ihrer Tabellen darauf achten, wie Sie partitionieren. Zu viele Partitionsschlüssel können zu fragmentierten Datensätzen mit zu vielen und zu kleinen Dateien führen. Umgekehrt führen zu wenige Partitionsschlüssel oder gar keine Partitionierung zu Abfragen, bei denen mehr Daten gescannt werden als nötig.
Vermeiden Sie die Optimierung für seltene Abfragen
Eine gute Strategie besteht darin, für die häufigsten Abfragen zu optimieren und die Optimierung für seltene Abfragen zu vermeiden. Wenn sich Ihre Abfragen beispielsweise auf Zeiträume von Tagen beziehen, sollten Sie sie nicht nach Stunden partitionieren, auch wenn einige Abfragen auf diese Ebene filtern. Wenn Ihre Daten über eine detaillierte Zeitstempelspalte verfügen, können die seltenen Abfragen, die nach Stunden filtern, die Zeitstempelspalte verwenden. Auch wenn in seltenen Fällen etwas mehr Daten als nötig gescannt werden, ist eine Reduzierung der Gesamtleistung in seltenen Fällen in der Regel kein guter Kompromiss.
Um die Datenmenge, die Abfragen scannen müssen, zu reduzieren und dadurch die Leistung zu verbessern, sollten Sie ein spaltenförmiges Dateiformat verwenden und die Datensätze sortiert halten. Anstatt nach Stunden zu partitionieren, sollten Sie die Datensätze nach Zeitstempel sortieren. Bei Abfragen mit kürzeren Zeitfenstern ist die Sortierung nach Zeitstempel fast so effizient wie die Partitionierung nach Stunden. Darüber hinaus beeinträchtigt die Sortierung nach Zeitstempeln in der Regel nicht die Leistung von Abfragen in Zeitfenstern, die in Tagen gezählt werden. Weitere Informationen finden Sie unter Spaltenorientierte Dateiformate verwenden.
Beachten Sie, dass Abfragen in Tabellen mit Zehntausenden von Partitionen besser abschneiden, wenn alle Partitionsschlüssel Prädikate enthalten. Dies ist ein weiterer Grund, Ihr Partitionierungsschema für die häufigsten Abfragen zu entwerfen. Weitere Informationen finden Sie unter Partitionen nach Gleichheit abfragen.
Partitionsprojektion verwenden
Die Partitionsprojektion ist eine Athena-Funktion, die Partitionsinformationen nicht in der AWS Glue Data Catalog, sondern als Regeln in den Eigenschaften der Tabelle in AWS Glue speichert. Wenn Athena eine Abfrage für eine mit Partitionsprojektion konfigurierte Tabelle plant, liest es die Partitionsprojektionsregeln der Tabelle. Athena berechnet die Partitionen, die im Speicher gelesen werden sollen, basierend auf der Abfrage und den Regeln, anstatt nach Partitionen in der AWS Glue Data Catalog zu suchen.
Die Partitionsprojektion vereinfacht nicht nur die Partitionsverwaltung, sondern kann auch die Leistung von Datensätzen mit einer großen Anzahl von Partitionen verbessern. Wenn eine Abfrage Bereiche anstelle bestimmter Werte für Partitionsschlüssel enthält, dauert die Suche nach passenden Partitionen im Katalog umso länger, je mehr Partitionen vorhanden sind. Mit der Partitionsprojektion kann der Filter im Speicher berechnet werden, ohne den Katalog aufrufen zu müssen, und das kann viel schneller sein.
Unter bestimmten Umständen kann die Partitionsprojektion zu einer schlechteren Leistung führen. Ein Beispiel ist, wenn eine Tabelle „spärlich“ ist. Eine spärliche Tabelle enthält nicht Daten für jede Permutation der Partitionsschlüsselwerte, die in der Konfiguration der Partitionsprojektion beschrieben werden. Bei einer spärlichen Tabelle werden die anhand der Abfrage berechneten Partitionen und die Konfiguration der Partitionsprojektion alle in Amazon S3 aufgeführt, auch wenn sie keine Daten enthalten.
Wenn Sie die Partitionsprojektion verwenden, stellen Sie sicher, dass alle Partitionsschlüssel Prädikate enthalten. Grenzen Sie den Umfang der möglichen Werte ein, um unnötige Amazon-S3-Auflistungen zu vermeiden. Stellen Sie sich einen Partitionsschlüssel mit einem Bereich von einer Million Werten und eine Abfrage ohne Filter für diesen Partitionsschlüssel vor. Um die Abfrage auszuführen, muss Athena mindestens eine Million Amazon-S3-Listenoperationen ausführen. Abfragen sind am schnellsten, wenn Sie bestimmte Werte abfragen, unabhängig davon, ob Sie Partitionsprojektion verwenden oder Partitionsinformationen im Katalog speichern. Weitere Informationen finden Sie unter Partitionen nach Gleichheit abfragen.
Wenn Sie eine Tabelle für die Partitionsprojektion konfigurieren, stellen Sie sicher, dass die von Ihnen angegebenen Bereiche angemessen sind. Wenn eine Abfrage kein Prädikat für einen Partitionsschlüssel enthält, werden alle Werte im Bereich für diesen Schlüssel verwendet. Wenn Ihr Datensatz an einem bestimmten Datum erstellt wurde, verwenden Sie dieses Datum als Ausgangspunkt für alle Datumsbereiche. Verwenden Sie NOW als das Ende von Datumsbereichen. Vermeiden Sie numerische Bereiche mit einer großen Anzahl von Werten und ziehen Sie in Betracht, stattdessen den injizierten Typ zu verwenden.
Weitere Informationen zur Partitionsprojektion finden Sie unter Verwenden Sie die Partitionsprojektion mit Amazon Athena.
Verwenden Sie Partitionsindizes
Partitionsindizes sind eine Funktion in der AWS Glue Data Catalog , die die Leistung der Partitionssuche für Tabellen mit einer großen Anzahl von Partitionen verbessert.
Die Liste der Partitionen im Katalog ist wie eine Tabelle in einer relationalen Datenbank. Die Tabelle enthält Spalten für die Partitionsschlüssel und eine zusätzliche Spalte für den Speicherort der Partition. Wenn Sie eine partitionierte Tabelle abfragen, werden die Partitionsspeicherorte durch Scannen dieser Tabelle gesucht.
Wie bei relationalen Datenbanken können Sie die Leistung von Abfragen erhöhen, indem Sie Indizes hinzufügen. Sie können mehrere Indizes hinzufügen, um unterschiedliche Abfragemuster zu unterstützen. Der AWS Glue Data Catalog Partitionsindex unterstützt sowohl Gleichheits- als auch Vergleichsoperatoren wie >>=,, in < Kombination mit dem AND Operator. Weitere Informationen finden Sie unter Arbeiten mit Partitionsindizes AWS Glue im AWS Glue Entwicklerhandbuch und Verbessern der Abfrageleistung von Amazon Athena mithilfe von AWS Glue Data Catalog Partitionsindizes
Immer STRING als Typ für Partitionsschlüssel verwenden
Wenn Sie Partitionsschlüssel abfragen, denken Sie daran, dass Athena verlangt, dass die Partitionsschlüssel vom Typ STRING sind, um die Partitionsfilterung nach unten in AWS Glue zu schieben. Wenn die Anzahl der Partitionen nicht gering ist, kann die Verwendung anderer Typen zu einer schlechteren Leistung führen. Wenn Ihre Partitionsschlüsselwerte einem Datum oder einer Zahl ähneln, wandeln Sie sie in Ihrer Abfrage in den entsprechenden Typ um.
Alte und leere Partitionen entfernen
Wenn Sie Daten aus einer Partition auf Amazon S3 entfernen (z. B. mithilfe des Amazon-S3-Lebenszyklus), sollten Sie auch den Partitionseintrag aus dem AWS Glue Data Catalog entfernen. Während der Abfrageplanung wird jede Partition, der die Abfrage entspricht, in Amazon S3 aufgeführt. Wenn Sie viele leere Partitionen haben, kann sich der Mehraufwand beim Auflisten dieser Partitionen nachteilig auswirken.
Wenn Sie viele tausend Partitionen haben, sollten Sie außerdem in Erwägung ziehen, Partitionsmetadaten für alte Daten zu entfernen, die nicht mehr relevant sind. Wenn Abfragen beispielsweise nie Daten berücksichtigen, die älter als ein Jahr sind, können Sie in regelmäßigen Abständen Partitionsmetadaten für die älteren Partitionen entfernen. Wenn die Anzahl der Partitionen auf Zehntausende ansteigt, kann das Entfernen ungenutzter Partitionen Abfragen beschleunigen, die nicht für alle Partitionsschlüssel Prädikate enthalten. Hinweise zum Einbeziehen von Prädikaten für alle Partitionsschlüssel in Ihre Abfragen finden Sie unter Partitionen nach Gleichheit abfragen.
Partitionen nach Gleichheit abfragen
Abfragen, die Gleichheitsprädikate für alle Partitionsschlüssel enthalten, werden schneller ausgeführt, da die Partitionsmetadaten direkt geladen werden können. Vermeiden Sie Abfragen, bei denen einer oder mehrere Partitionsschlüssel kein Prädikat haben oder bei denen das Prädikat einen Wertebereich auswählt. Für solche Abfragen muss die Liste aller Partitionen gefiltert werden, um passende Werte zu finden. Bei den meisten Tabellen ist der Overhead minimal, bei Tabellen mit Zehntausenden oder mehr Partitionen kann der Overhead jedoch erheblich werden.
Wenn es nicht möglich ist, Ihre Abfragen so umzuschreiben, dass Partitionen nach Gleichheit gefiltert werden, können Sie es mit Partitionsprojektion versuchen. Weitere Informationen finden Sie unter Partitionsprojektion verwenden.
Vermeiden Sie die Verwendung MSCK REPAIR TABLE für die Partitionsverwaltung
Da die Ausführung von MSCK REPAIR TABLE sehr lange dauern kann, nur neue Partitionen hinzugefügt und alte Partitionen nicht entfernt werden, ist dies keine effiziente Methode zur Verwaltung von Partitionen (siehe Überlegungen und Einschränkungen).
Partitionen lassen sich besser manuell mit den AWS Glue Crawlern AWS Glue Data Catalog APIsALTER TABLE ADD PARTITION, oder verwalten. Als Alternative können Sie die Partitionsprojektion verwenden, sodass Sie keine Partitionen mehr verwalten müssen. Weitere Informationen finden Sie unter Verwenden Sie die Partitionsprojektion mit Amazon Athena.
Stellen Sie sicher, dass Ihre Abfragen mit dem Partitionierungsschema kompatibel sind
Mithilfe der Anweisung EXPLAIN können Sie im Voraus überprüfen, welche Partitionen eine Abfrage scannt. Stellen Sie Ihrer Abfrage das EXPLAIN-Schlüsselwort voran und suchen Sie dann am Ende der EXPLAIN-Ausgabe nach dem Quellfragment (z. B. Fragment 2 [SOURCE]) für jede Tabelle. Suchen Sie nach Zuweisungen, bei denen die rechte Seite als Partitionsschlüssel definiert ist. Die Zeile darunter enthält eine Liste aller Werte für diesen Partitionsschlüssel, die bei der Ausführung der Abfrage gescannt werden.
Angenommen, Sie haben eine Abfrage für eine Tabelle mit einem dt-Partitionsschlüssel und dem Präfix EXPLAIN. Wenn es sich bei den Werten in der Abfrage um Datumswerte handelt und ein Filter einen Bereich von drei Tagen auswählt, könnte die EXPLAIN Ausgabe etwa so aussehen:
dt := dt:string:PARTITION_KEY :: [[2023-06-11], [2023-06-12], [2023-06-13]]
Die EXPLAIN-Ausgabe zeigt, dass der Planer drei Werte für diesen Partitionsschlüssel gefunden hat, die der Abfrage entsprachen. Sie zeigt Ihnen auch, was diese Werte sind. Weitere Informationen zur Verwendung von EXPLAIN und Verwenden von EXPLAIN und EXPLAIN ANALYZE in Athena finden Sie unter Verstehen Sie die Ergebnisse der EXPLAIN Athena-Erklärung.
Spaltenorientierte Dateiformate verwenden
Spaltenförmige Dateiformate wie Parquet und ORC sind für verteilte Analyse-Workloads konzipiert. Sie organisieren Daten nach Spalten statt nach Zeilen. Das Organisieren von Daten im Spaltenformat bietet die folgenden Vorteile:
-
Nur die für die Abfrage benötigten Spalten werden geladen
-
Die Gesamtmenge der Daten, die geladen werden müssen, wird reduziert
-
Spaltenwerte werden zusammen gespeichert, sodass Daten effizient komprimiert werden können
-
Dateien können Metadaten enthalten, die es der Engine ermöglichen, das Laden nicht benötigter Daten zu überspringen
Als Beispiel dafür, wie Dateimetadaten verwendet werden können, können Dateimetadaten Informationen über die Mindest- und Höchstwerte auf einer Datenseite enthalten. Wenn die abgefragten Werte nicht in dem in den Metadaten angegebenen Bereich liegen, kann die Seite übersprungen werden.
Eine Möglichkeit, diese Metadaten zur Verbesserung der Leistung zu verwenden, besteht darin, sicherzustellen, dass die Daten in den Dateien sortiert sind. Angenommen, Sie haben Abfragen, die nach Datensätzen suchen, bei denen sich der created_at-Eintrag innerhalb einer kurzen Zeitspanne befindet. Wenn Ihre Daten nach der created_at-Spalte sortiert sind, kann Athena die Minimal- und Maximalwerte in den Dateimetadaten verwenden, um die nicht benötigten Teile der Datendateien zu überspringen.
Achten Sie bei der Verwendung von spaltenorientierten Dateiformaten darauf, dass Ihre Dateien nicht zu klein sind. Wie in Zu viele Dateien vermeiden erwähnt, verursachen Datensätze mit vielen kleinen Dateien Leistungsprobleme. Dies gilt insbesondere für spaltenförmige Dateiformate. Bei kleinen Dateien überwiegt der Aufwand des spaltenförmigen Dateiformats die Vorteile.
Beachten Sie, dass Parquet und ORC D intern nach Zeilengruppen (Parquet) und Streifen (ORC) organisiert sind. Die Standardgröße für Zeilengruppen beträgt 128 MB und für Streifen 64 MB. Wenn Sie viele Spalten haben, können Sie die Zeilengruppe und die Streifen-Größe erhöhen, um die Leistung zu verbessern. Es wird nicht empfohlen, die Zeilengruppen- oder Streifen-Größe auf weniger als die Standardwerte zu reduzieren.
Um andere Datenformate in Parquet oder zu konvertierenORC, können Sie AWS Glue ETL oder Athena verwenden. Weitere Informationen finden Sie unter In spaltenorientierte Formate konvertieren.
Daten komprimieren
Athena unterstützt eine Vielzahl von Komprimierungsformaten. Das Abfragen komprimierter Daten ist schneller und auch günstiger, da Sie für die Anzahl der vor der Dekomprimierung gescannten Byte zahlen.
Das GZIP
Versuchen Sie beim Komprimieren von Textdateien wie CSV Daten JSON und ein ausgewogenes Verhältnis zwischen der Anzahl der Dateien und der Größe der Dateien zu erreichen. Bei den meisten Komprimierungsformaten muss der Leser Dateien von Anfang an lesen. Das bedeutet, dass komprimierte Textdateien im Allgemeinen nicht parallel verarbeitet werden können. Große unkomprimierte Dateien werden häufig zwischen Workern aufgeteilt, um eine höhere Parallelität bei der Abfrageverarbeitung zu erreichen. Dies ist jedoch bei den meisten Komprimierungsformaten nicht möglich.
Wie in Zu viele Dateien vermeiden diskutiert, ist es besser, weder zu viele noch zu wenige Dateien zu haben. Da die Anzahl der Dateien das Limit dafür ist, wie viele Worker die Abfrage verarbeiten können, gilt diese Regel insbesondere für komprimierte Dateien.
Weitere Informationen zur Verwendung der Komprimierung in Athena finden Sie unter Verwenden Sie die Komprimierung in Athena.
Verwenden Sie Bucketing für die Suche nach Schlüsseln mit hoher Kardinalität
Beim Bucketing handelt es sich um eine Technik zur Verteilung von Datensätzen in separate Dateien, die auf dem Wert einer der Spalten basieren. Dadurch wird sichergestellt, dass sich alle Datensätze mit demselben Wert in derselben Datei befinden. Bucketing ist nützlich, wenn Sie einen Schlüssel mit hoher Kardinalität haben und viele Ihrer Abfragen nach bestimmten Werten des Schlüssels suchen.
Nehmen wir beispielsweise an, Sie fragen eine Reihe von Datensätzen für einen bestimmten Benutzer ab. Wenn die Daten nach Benutzer-IDs zusammengefasst sind, weiß Athena im Voraus, welche Dateien Datensätze für eine bestimmte ID enthalten und welche nicht. Dadurch kann Athena nur die Dateien lesen, die die ID enthalten können, wodurch die Menge der gelesenen Daten erheblich reduziert wird. Es reduziert auch die Rechenzeit, die andernfalls erforderlich wäre, um die Daten nach der spezifischen ID zu durchsuchen.
Vermeiden Sie Buckets, wenn Abfragen häufig nach mehreren Werten in einer Spalte suchen
Bucketing ist weniger nützlich, wenn Abfragen häufig nach mehreren Werten in der Spalte suchen, nach der die Daten gruppiert sind. Je mehr Werte abgefragt werden, desto höher ist die Wahrscheinlichkeit, dass alle oder die meisten Dateien gelesen werden müssen. Wenn Sie beispielsweise drei Buckets haben und eine Abfrage nach drei verschiedenen Werten sucht, müssen möglicherweise alle Dateien gelesen werden. Bucketing funktioniert am besten, wenn Abfragen nach einzelnen Werten suchen.
Weitere Informationen finden Sie unter Verwenden Sie Partitioning und Bucketing.
Zu viele Dateien vermeiden
Datensätze, die aus vielen kleinen Dateien bestehen, führen insgesamt zu einer schlechten Abfrageleistung. Wenn Athena eine Abfrage plant, listet es alle Partitionsspeicherorte auf, was einige Zeit in Anspruch nimmt. Die Bearbeitung und Anforderung jeder Datei ist ebenfalls mit einem Rechenaufwand verbunden. Daher ist das Laden einer einzigen größeren Datei aus Amazon S3 schneller als das Laden derselben Datensätze aus vielen kleineren Dateien.
In extremen Fällen können Sie auf Servicebeschränkungen in Amazon S3 stoßen. Amazon S3 unterstützt bis zu 5 500 Anfragen pro Sekunde an eine einzelne Indexpartition. Anfänglich wird ein Bucket als eine einzelne Indexpartition behandelt, aber wenn die Anforderungslast zunimmt, kann er in mehrere Indexpartitionen aufgeteilt werden.
Amazon S3 untersucht Anforderungsmuster und Aufteilungen auf der Grundlage von Schlüsselpräfixen. Wenn Ihr Datensatz aus vielen tausend Dateien besteht, können die Anfragen von Athena das Anforderungskontingent überschreiten. Selbst bei weniger Dateien kann das Kontingent überschritten werden, wenn mehrere gleichzeitige Abfragen für denselben Datensatz durchgeführt werden. Andere Anwendungen, die auf dieselben Dateien zugreifen, können zur Gesamtzahl der Anfragen beitragen.
Wenn die Anforderungsrate limit überschritten wird, gibt Amazon S3 den folgenden Fehler zurück. Dieser Fehler ist in den Statusinformationen für die Abfrage in Athena enthalten.
SlowDown: Bitte reduzieren Sie Ihre Anforderungsrate
Stellen Sie zur Fehlerbehebung zunächst fest, ob der Fehler durch eine einzelne Abfrage oder durch mehrere Abfragen verursacht wurde, die dieselben Dateien lesen. Wenn letzteres der Fall ist, koordinieren Sie die Ausführung von Abfragen, sodass sie nicht gleichzeitig ausgeführt werden. Um dies zu erreichen, fügen Sie Ihrer Anwendung einen Warteschlangenmechanismus oder sogar Wiederholungsversuche hinzu.
Wenn das Ausführen einer einzelnen Abfrage den Fehler auslöst, versuchen Sie, Datendateien zu kombinieren oder die Abfrage so zu ändern, dass weniger Dateien gelesen werden. Kleine Dateien lassen sich am besten kombinieren, bevor sie geschrieben werden. Ziehen Sie dazu die folgenden Techniken in Betracht:
-
Ändern Sie den Prozess, der die Dateien schreibt, um größere Dateien zu schreiben. Sie könnten beispielsweise Datensätze für einen längeren Zeitraum zwischenspeichern, bevor sie geschrieben werden.
-
Platzieren Sie Dateien an einem Speicherort auf Amazon S3 und verwenden Sie ein Tool wie GlueETL, um sie zu größeren Dateien zu kombinieren. Verschieben Sie dann die größeren Dateien an den Speicherort, auf den die Tabelle verweist. Weitere Informationen finden Sie unter Lesen von Eingabedateien in größeren Gruppen im AWS Glue Entwicklerhandbuch und Wie kann ich einen AWS Glue ETL Job so konfigurieren, dass größere Dateien ausgegeben werden?
im AWS re:POST Knowledge Center. -
Reduzieren Sie die Anzahl der Partitionsschlüssel. Wenn Sie zu viele Partitionsschlüssel haben, enthält jede Partition möglicherweise nur wenige Datensätze, was zu einer übermäßigen Anzahl kleiner Dateien führt. Hinweise zur Entscheidung, welche Partitionen erstellt werden sollen, finden Sie unter Wählen Sie Partitionsschlüssel aus, die Ihre Abfragen unterstützen.
Vermeiden Sie zusätzliche Speicherhierarchien außerhalb der Partition
Um den Aufwand bei der Planung von Abfragen zu vermeiden, speichern Sie Dateien in einer flachen Struktur an jedem Partitionsspeicherort. Verwenden Sie keine zusätzlichen Verzeichnishierarchien.
Wenn Athena eine Abfrage plant, listet es alle Dateien in allen Partitionen auf, denen die Abfrage entspricht. Obwohl Amazon S3 per se keine Verzeichnisse hat, ist es üblich, den /-Schrägstrich als Verzeichnistrennzeichen zu interpretieren. Wenn Athena Partitionsspeicherorte auflistet, listet es rekursiv alle gefundenen Verzeichnisse auf. Wenn Dateien innerhalb einer Partition in einer Hierarchie organisiert sind, kommt es zu mehreren Auflistungsrunden.
Wenn sich alle Dateien direkt am Speicherort der Partition befinden, muss meistens nur ein Listenvorgang ausgeführt werden. Allerdings sind mehrere sequentielle Listenoperationen erforderlich, wenn Sie mehr als 1 000 Dateien in einer Partition haben, da Amazon S3 nur 1 000 Objekte pro Listenvorgang zurückgibt. Mehr als 1 000 Dateien in einer Partition können auch zu anderen, schwerwiegenderen Leistungsproblemen führen. Weitere Informationen finden Sie unter Zu viele Dateien vermeiden.
SymlinkTextInputFormat nur bei Bedarf verwenden
Die Verwendung der SymlinkTextInputFormat
Durch die Verwendung von Symlinks wird die Abfrageausführung jedoch um ein gewisses Maß an Indirektion erweitert. Diese Ebenen der Indirektion wirken sich auf die Gesamtleistung aus. Die Symlink-Dateien müssen gelesen und die Speicherorte, die sie definieren, müssen aufgelistet werden. Dadurch werden mehrere Roundtrips zu Amazon S3 hinzugefügt, die für herkömmliche Hive-Tabellen nicht erforderlich sind. Zusammenfassend lässt sich sagen, dass Sie SymlinkTextInputFormat nur verwenden sollten, wenn bessere Optionen wie das Reorganisieren von Dateien nicht verfügbar sind.
