Lösungen für vom Kunden gehostete Architekturen: Schritt-für-Schritt-Anleitungen für Komponenten

Auf dieser Seite werden gängige Vorgehensweisen für bestimmte Komponenten der Looker-Architektur beschrieben und es wird erläutert, wie Sie sie in einem Deployment konfigurieren.

Für das Hosten des Servers, die Verarbeitung von Ad-hoc- und geplanten Arbeitslasten, die Nachverfolgung der iterativen Modellentwicklung usw. hat Looker eine Reihe von Abhängigkeiten. Solche Abhängigkeiten werden auf dieser Seite als Komponenten bezeichnet. Jede Komponente wird in den folgenden Abschnitten ausführlich behandelt:

Hostkonfiguration

Betriebssystem und Vertrieb

Looker funktioniert gut mit den gängigsten Linux-Versionen: RedHat, SUSE und Debian/Ubuntu. Ableitungen dieser Distributionen, die für die Ausführung in einer bestimmten Umgebung entwickelt und optimiert wurden, sind in der Regel in Ordnung. Die Google Cloud - oder AWS-Distributionen von Linux sind beispielsweise mit Looker kompatibel. Debian/Ubuntu ist die am häufigsten verwendete Linux-Variante in der Looker-Community und Looker-Support ist mit diesen Versionen am besten vertraut. Am einfachsten ist es, Debian/Ubuntu oder ein Betriebssystem für einen bestimmten Cloud-Anbieter zu verwenden, das von Debian/Ubuntu abgeleitet ist.

Looker wird in der Java Virtual Machine (JVM) ausgeführt. Achten Sie bei der Auswahl einer Distribution darauf, dass die Versionen des OpenJDK 11 auf dem neuesten Stand sind. Auf älteren Linux-Distributionen kann Looker möglicherweise ausgeführt werden, aber die Java-Version und ‑Bibliotheken, die für bestimmte Looker-Funktionen erforderlich sind, müssen auf dem neuesten Stand sein. Wenn die JVM nicht alle empfohlenen Looker-Bibliotheken und ‑Versionen enthält, funktioniert Looker nicht normal. Für Looker ist Java HotSpot 1.8 Update 161+ oder Java OpenJDK 11.0.12+ erforderlich.

CPU und Arbeitsspeicher

Knoten mit 4 × 16 (4 CPUs und 16 GB RAM) reichen für ein Entwicklungssystem oder eine einfache Looker-Testinstanz aus, die von einem kleinen Team verwendet wird. Für den produktiven Einsatz ist das jedoch in der Regel nicht ausreichend. Unserer Erfahrung nach bieten 16x64-Knoten (16 CPUs und 64 GB RAM) ein gutes Preis-Leistungs-Verhältnis. Mehr als 64 GB RAM können sich auf die Leistung auswirken, da Garbage Collection-Ereignisse Single-Threaded sind und alle anderen Threads angehalten werden, um ausgeführt zu werden.

Festplattenspeicher

100 GB Speicherplatz sind für ein Produktionssystem in der Regel mehr als ausreichend.

Hinweise zu Clustern

Looker wird auf einer Java-JVM ausgeführt und Java kann Schwierigkeiten haben, Arbeitsspeicher mit mehr als 64 GB zu verwalten. Als allgemeine Regel gilt, dass Sie dem Cluster zusätzliche 16x64-Knoten hinzufügen sollten, wenn mehr Kapazität erforderlich ist, anstatt die Größe der Knoten über 16x64 hinaus zu erhöhen. Möglicherweise bevorzugen wir auch eine Clusterarchitektur, um die Verfügbarkeit zu erhöhen.

In einem Cluster müssen die Looker-Knoten bestimmte Teile des Dateisystems gemeinsam nutzen. Die freigegebenen Daten umfassen Folgendes:

  • LookML-Modelle
  • Die LookML-Modelle des Entwicklers
  • Git-Serververbindung

Da das Dateisystem freigegeben ist und eine Reihe von Git-Repositories hostet, ist die Verarbeitung von gleichzeitigem Zugriff und Dateisperrung von entscheidender Bedeutung. Das Dateisystem muss POSIX-konform sein. Das Network File System (NFS) funktioniert und ist unter Linux verfügbar. Sie sollten eine zusätzliche Linux-Instanz erstellen und NFS so konfigurieren, dass das Laufwerk freigegeben wird. Standard-NFS ist potenziell ein Single Point of Failure. Erwägen Sie daher ein Failover- oder Hochverfügbarkeitssetup.

Die Looker-Metadaten müssen ebenfalls zentralisiert werden. Die interne Datenbank muss also zu MySQL migriert werden. Dies kann ein MySQL-Dienst oder eine dedizierte MySQL-Bereitstellung sein. Weitere Informationen finden Sie auf dieser Seite im Abschnitt Interne (Backend-)Datenbank.

JVM-Konfiguration

Die JVM-Einstellungen für Looker werden im Looker-Startskript definiert. Nach jeder Aktualisierung muss Looker neu gestartet werden, damit die Änderungen wirksam werden. Die Standardkonfigurationen sind wie folgt: 

java \
  -XX:+UseG1GC -XX:MaxGCPauseMillis=2000 \
  -Xms$JAVAMEM -Xmx$JAVAMEM \
  -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps \
  -Xloggc:/tmp/gc.log ${JAVAARGS} \
  -jar looker.jar start ${LOOKERARGS}

Ressourcen

Die Ressourceneinstellungen werden im Looker-Startskript definiert. 

JAVAMEM="2300m"
METAMEM="800m"

Bei der Speicherzuweisung für die JVM muss der Betriebssystem-Overhead berücksichtigt werden, auf dem Looker ausgeführt wird. Als Faustregel gilt, dass der JVM bis zu 60% des Gesamtspeichers zugewiesen werden können. Je nach Maschinengröße gibt es jedoch Einschränkungen. Für Maschinen mit dem Mindestspeicher von 8 GB empfehlen wir eine Zuweisung von 4–5 GB für Java und 800 MB für Meta. Bei größeren Maschinen kann ein geringerer Anteil des Arbeitsspeichers für das Betriebssystem zugewiesen werden. Für Maschinen mit 60 GB Gesamtspeicher empfehlen wir beispielsweise, 36 GB für Java und 1 GB für Meta zuzuweisen. Die Speicherzuweisung von Java sollte in der Regel mit dem Gesamtspeicher der Maschine skaliert werden. 1 GB sollte für Meta jedoch ausreichen.

Da Looker Systemressourcen mit anderen Prozessen wie Chromium für das Rendern teilt, sollte die für Java zugewiesene Menge an Arbeitsspeicher im Kontext der erwarteten Rendering-Last und der Größe des Computers ausgewählt werden. Wenn die Rendering-Last voraussichtlich gering ist, kann Java ein größerer Anteil des Gesamtspeichers zugewiesen werden. Auf einem Computer mit insgesamt 60 GB Arbeitsspeicher können Java beispielsweise sicher 46 GB zugewiesen werden. Das ist mehr als die allgemeine Empfehlung von 60 %. Die genauen Ressourcenzuweisungen, die für die einzelnen Bereitstellungen erforderlich sind, variieren. Verwenden Sie daher 60% als Baseline und passen Sie sie nach Bedarf an.

Automatische Speicherbereinigung

Looker bevorzugt die Verwendung des modernsten Garbage Collectors, der für die Java-Version verfügbar ist. Das Standardzeitlimit für die Garbage Collection beträgt 2 Sekunden. Sie können es ändern, indem Sie die folgende Option in der Startkonfiguration bearbeiten: 

-XX:MaxGCPauseMillis=2000

Auf einer größeren Maschine mit mehreren Kernen kann das Zeitlimit für die automatische Speicherbereinigung verkürzt werden.

Logs

Die Looker-Logs zur automatischen Speicherbereinigung werden standardmäßig in /tmp/gc.log gespeichert. Dies kann durch Bearbeiten der folgenden Option in der Startkonfiguration geändert werden: 

-Xloggc:/tmp/gc.log

JMX

Die Verwaltung von Looker erfordert möglicherweise eine Überwachung, um die Ressourcenplanung zu optimieren. Wir empfehlen, die JVM-Arbeitsspeichernutzung mit JMX zu überwachen.

Looker-Startoptionen

Die Startoptionen werden in einer Datei mit dem Namen lookerstart.cfg gespeichert. Diese Datei wird im Shell-Script, mit dem Looker gestartet wird, als Quelle verwendet.

Thread pools

Als Multithread-Anwendung verfügt Looker über eine Reihe von Threadpools. Diese Threadpools reichen vom Core-Webserver bis hin zu spezialisierten Subservices wie Planung, Rendering und externen Datenbankverbindungen. Je nach Ihren Geschäftsprozessen müssen diese Pools möglicherweise von der Standardkonfiguration abweichen. Insbesondere gelten spezielle Überlegungen für die Cluster-Topologien, die auf der Seite Architekturmuster und Best Practices für die vom Kunden gehostete Infrastruktur beschrieben werden.

Optionen für hohen Planungsdurchsatz

Fügen Sie für alle Knoten, die nicht als Scheduler fungieren, --scheduler-threads=0 zur Umgebungsvariable LOOKERARGS in lookerstart.cfg hinzu. Ohne Planer-Threads werden auf diesen Knoten keine geplanten Jobs ausgeführt.

Fügen Sie für alle dedizierten Scheduler-Knoten --scheduler-threads=<n> der Umgebungsvariable LOOKERARGS in lookerstart.cfg hinzu. Looker beginnt standardmäßig mit 10 Scheduler-Threads, diese Anzahl kann jedoch auf <n> erhöht werden. Mit <n> Scheduler-Threads kann jeder Knoten <n> gleichzeitige Planungsjobs ausführen. Im Allgemeinen wird empfohlen, <n> auf weniger als das Doppelte der Anzahl der CPUs festzulegen. Der größte empfohlene Host hat 16 CPUs und 64 GB Arbeitsspeicher. Die Obergrenze für Scheduler-Threads sollte also unter 32 liegen.

Optionen für hohen Rendering-Durchsatz

Fügen Sie für alle Nicht-Render-Knoten --concurrent-render-jobs=0 zur Umgebungsvariable LOOKERARGS in lookerstart.cfg hinzu. Ohne Renderer-Knoten werden auf diesen Knoten keine Render-Jobs ausgeführt.

Fügen Sie für alle dedizierten Renderknoten --concurrent-render-jobs=<n> der Umgebungsvariable LOOKERARGS in lookerstart.cfg hinzu. Looker beginnt standardmäßig mit zwei Rendering-Threads, die Anzahl kann aber auf <n> erhöht werden. Mit <n> Rendering-Threads kann jeder Knoten <n> gleichzeitige Rendering-Jobs ausführen.

Jeder Rendering-Job kann eine erhebliche Menge an Arbeitsspeicher belegen. Planen Sie etwa 2 GB pro Rendering-Job ein. Wenn dem Looker-Kernprozess (Java) beispielsweise 60% des Gesamtspeichers zugewiesen werden und 20% des verbleibenden Speichers für das Betriebssystem reserviert sind, bleiben die letzten 20% für Rendering-Jobs. Auf einem Computer mit 64 GB bleiben 12 GB übrig, was für 6 gleichzeitige Rendering-Jobs ausreicht. Wenn ein Knoten für das Rendern vorgesehen ist und nicht im Load-Balancer-Pool enthalten ist, der interaktive Jobs verarbeitet, kann der Arbeitsspeicher des Looker-Kernprozesses reduziert werden, um mehr Renderjobs zu ermöglichen. Auf einer Maschine mit 64 GB Arbeitsspeicher können Sie dem Looker-Kernprozess etwa 30% (20 GB) zuweisen. Wenn Sie 20% für die allgemeine Betriebssystemnutzung reservieren, bleiben 50% (32 GB) für das Rendern übrig, was für 16 gleichzeitige Renderjobs ausreicht.

Interne (Backend-)Datenbank

Der Looker-Server speichert Informationen zu seiner eigenen Konfiguration, Datenbankverbindungen, Nutzern, Gruppen und Rollen, Ordnern, benutzerdefinierten Looks und Dashboards sowie verschiedene andere Daten in einer internen Datenbank.

Bei einer eigenständigen Looker-Instanz mittlerer Größe werden diese Daten in einer speicherinternen HyperSQL-Datenbank gespeichert, die in den Looker-Prozess eingebettet ist. Die Daten für diese Datenbank werden in der Datei <looker install directory>/.db/looker.script gespeichert. Diese Datenbank ist zwar praktisch und leichtgewichtig, weist aber bei starker Nutzung Leistungsprobleme auf. Daher empfehlen wir, mit einer Remote-MySQL-Datenbank zu beginnen. Wenn das nicht möglich ist, empfehlen wir, zu einer Remote-MySQL-Datenbank zu migrieren, sobald die Datei ~/looker/.db/looker.script 600 MB erreicht. Für Cluster muss eine MySQL-Datenbank verwendet werden.

Der Looker-Server führt viele kleine Lese- und Schreibvorgänge in der MySQL-Datenbank aus. Jedes Mal, wenn ein Nutzer einen Look oder ein Explore ausführt, prüft Looker in der Datenbank, ob der Nutzer noch angemeldet ist, ob er Berechtigungen für den Zugriff auf die Daten hat und ob er Berechtigungen zum Ausführen des Looks oder des Explores hat. Looker schreibt auch Daten in die MySQL-Datenbank, z. B. den tatsächlich ausgeführten SQL-Code und die Start- und Endzeit der Anfrage. Eine einzelne Interaktion zwischen einem Nutzer und der Looker-Anwendung kann zu 15 oder 20 kleinen Lese- und Schreibvorgängen in der MySQL-Datenbank führen.

MySQL

Der MySQL-Server sollte Version 8.0.x haben und für die Verwendung der utf8mb4-Codierung konfiguriert sein. Das InnoDB-Speichermodul muss verwendet werden. Die Einrichtungsanleitung für MySQL sowie eine Anleitung zum Migrieren von Daten aus einer vorhandenen HyperSQL-Datenbank zu MySQL finden Sie auf der Dokumentationsseite Looker-Backend-Datenbank zu MySQL migrieren.

Wenn Sie Looker für die Verwendung von MySQL konfigurieren, muss eine YAML-Datei mit den Verbindungsinformationen erstellt werden. Geben Sie der YAML-Datei den Namen looker-db.yml und fügen Sie die Einstellung -d looker-db.yml im Abschnitt LOOKERARGS der Datei lookerstart.cfg hinzu.

MariaDB

MySQL ist dual lizenziert und sowohl als Open-Source- als auch als kommerzielles Produkt verfügbar. Oracle hat MySQL weiter verbessert und MySQL wurde als MariaDB abgespalten. Die entsprechenden MariaDB-Versionen von MySQL funktionieren bekanntermaßen mit Looker, werden aber nicht von den Looker-Entwicklungsteams entwickelt oder getestet. Daher wird die Funktionalität nicht unterstützt oder garantiert.

Cloud-Versionen

Wenn Sie Looker in Ihrer Cloud-Infrastruktur hosten, ist es sinnvoll, die MySQL-Datenbank in derselben Cloud-Infrastruktur zu hosten. Die drei wichtigsten Cloud-Anbieter: Amazon AWS, Microsoft Azure und Google Cloud. Die Cloud-Provider übernehmen einen Großteil der Wartung und Konfiguration für die MySQL-Datenbank und bieten Dienste wie die Verwaltung von Back-ups und die schnelle Wiederherstellung an. Diese Produkte sind dafür bekannt, dass sie gut mit Looker funktionieren.

Systemaktivitätsabfragen

In der MySQL-Datenbank werden Informationen dazu gespeichert, wie Nutzer Looker verwenden. Alle Looker-Nutzer, die die Berechtigung zum Aufrufen des Modells System Activity haben, können auf eine Reihe vorgefertigter Looker-Dashboards zugreifen, um diese Daten zu analysieren. Nutzer können auch auf Explores von Looker-Metadaten zugreifen, um zusätzliche Analysen zu erstellen. Die MySQL-Datenbank wird hauptsächlich für kleine, schnelle „operative“ Abfragen verwendet. Die großen, langsamen „Analyse“-Abfragen, die vom Systemaktivitätsmodell generiert werden, können mit diesen Betriebs-Abfragen konkurrieren und Looker verlangsamen.

In diesen Fällen kann die MySQL-Datenbank in eine andere Datenbank repliziert werden. Sowohl selbstverwaltete als auch bestimmte cloudverwaltete Systeme bieten eine grundlegende Konfiguration der Replikation in andere Datenbanken. Die Konfiguration der Replikation wird in diesem Dokument nicht behandelt.

Damit Sie das Replikat für die Systemaktivitätsabfragen verwenden können, erstellen Sie eine Kopie der Datei looker-db.yml, z. B. mit dem Namen looker-usage-db.yml. Ändern Sie die Kopie so, dass sie auf das Replikat verweist, und fügen Sie der Datei lookerstart.cfg im Abschnitt LOOKERARGS die Einstellung --internal-analytics-connection-file looker-usage-db.yml hinzu.

Die Systemaktivitätsabfragen können für eine MySQL-Instanz oder eine Google BigQuery-Datenbank ausgeführt werden. Sie werden nicht mit anderen Datenbanken verglichen.

MySQL-Leistung konfigurieren

Zusätzlich zu den Einstellungen, die für die Migration der Looker-Backend-Datenbank zu MySQL erforderlich sind, können stark aktive Cluster von zusätzlichen Optimierungen und Konfigurationen profitieren. Diese Einstellungen können in der Datei /etc/my.cnf oder über die Google Cloud -Konsole für cloudverwaltete Instanzen vorgenommen werden.

Die Konfigurationsdatei my.cnf ist in mehrere Teile unterteilt. Die in diesem Abschnitt beschriebenen Änderungen an den Einstellungen werden im [mysqld]-Teil vorgenommen.

Größe des InnoDB-Pufferpools festlegen

Die Größe des InnoDB-Pufferpools ist der gesamte RAM, der zum Speichern des Status der InnoDB-Datendateien im Arbeitsspeicher verwendet wird. Wenn der Server ausschließlich für die Ausführung von MySQL vorgesehen ist, sollte innodb_buffer_pool_size auf 50–70 % des gesamten Systemspeichers festgelegt werden.

Wenn die Gesamtgröße der Datenbank gering ist, kann der InnoDB-Pufferpool auf die Größe der Datenbank und nicht auf 50% oder mehr des Arbeitsspeichers festgelegt werden.

In diesem Beispiel hat ein Server 64 GB Arbeitsspeicher. Der InnoDB-Pufferpool sollte daher zwischen 32 GB und 45 GB liegen. Größere Bilder sind in der Regel besser. 

[mysqld]
...
innodb_buffer_pool_size=45G

InnoDB-Pufferpoolinstanzen festlegen

Wenn mehrere Threads versuchen, einen großen Pufferpool zu durchsuchen, kann es zu Konflikten kommen. Um dies zu verhindern, wird der Pufferpool in kleinere Einheiten unterteilt, auf die verschiedene Threads ohne Konflikte zugreifen können. Standardmäßig ist der Pufferpool in 8 Instanzen unterteilt. Dadurch kann es zu einem Engpass bei 8 Threads kommen. Wenn Sie die Anzahl der Pufferpoolinstanzen erhöhen, verringert sich die Wahrscheinlichkeit eines Engpasses. Die innodb_buffer_pool_instances sollten so festgelegt werden, dass jeder Pufferpool mindestens 1 GB Arbeitsspeicher erhält. 

[mysqld]
...
innodb_buffer_pool_instances=32

InnoDB-Logdatei optimieren

Wenn eine Transaktion committet wird, kann die Datenbank die Daten in der tatsächlichen Datei aktualisieren oder Details zur Transaktion im Log speichern. Wenn die Datenbank abstürzt, bevor die Datendateien aktualisiert wurden, kann die Logdatei „wiedergegeben“ werden, um die Änderungen anzuwenden. Das Schreiben in die Protokolldatei ist ein kleiner Anhänge-Vorgang. Es ist effizient, das Log zum Zeitpunkt des Commits zu ergänzen, dann mehrere Änderungen an den Datendateien zusammenzufassen und in einem einzigen E/A-Vorgang zu schreiben. Wenn die Logdatei voll ist, muss die Datenbank die Verarbeitung neuer Transaktionen pausieren und alle geänderten Daten auf die Festplatte zurückschreiben.

Als allgemeine Faustregel gilt, dass die InnoDB-Logdatei groß genug sein sollte, um Transaktionen von einer Stunde zu enthalten.

Normalerweise gibt es zwei InnoDB-Logdateien. Sie sollten etwa 25% Ihres InnoDB-Pufferpools ausmachen. Bei einer Beispieldatenbank mit einem 32 GB großen Pufferpool sollten die InnoDB-Logdateien insgesamt 8 GB groß sein, also 4 GB pro Datei. 

[mysqld]
...
innodb_log_file_size=8GB

InnoDB-E/A-Kapazität konfigurieren

MySQL drosselt die Geschwindigkeit, mit der Schreibvorgänge auf dem Laufwerk aufgezeichnet werden, um den Server nicht zu überlasten. Die Standardwerte sind für die meisten Server konservativ. Für eine optimale Leistung sollten Sie mit dem Dienstprogramm sysbench die zufällige Schreibgeschwindigkeit auf das Datenlaufwerk messen und diesen Wert dann verwenden, um die E/A-Kapazität so zu konfigurieren, dass MySQL Daten schneller schreibt.

Bei einem in der Cloud gehosteten System sollte der Cloud-Anbieter die Leistung der für die Datenspeicherung verwendeten Festplatten angeben können. Messen Sie für einen selbst gehosteten MySQL-Server die Geschwindigkeit zufälliger Schreibvorgänge auf dem Datenlaufwerk in E/A-Vorgängen pro Sekunde (IOPS). Das Linux-Dienstprogramm sysbench ist eine Möglichkeit, dies zu messen. Verwenden Sie diesen Wert für innodb_io_capacity_max und einen Wert, der zwischen der Hälfte und drei Vierteln dieses Werts liegt, für innodb_io_capacity. Im folgenden Beispiel würden wir die Werte sehen, wenn wir 800 IOPS gemessen hätten. 

[mysqld]
...
innodb_io_capacity=500
innodb_io_capacity_max=800

InnoDB-Threads konfigurieren

MySQL öffnet mindestens einen Thread für jeden Client, der bedient wird. Wenn viele Clients gleichzeitig verbunden sind, kann das dazu führen, dass eine große Anzahl von Threads verarbeitet wird. Das kann dazu führen, dass das System mehr Zeit mit dem Swapping als mit der Verarbeitung verbringt.

Durch Benchmarking sollte die ideale Anzahl von Threads ermittelt werden. Legen Sie zum Testen die Anzahl der Threads zwischen der Anzahl der CPUs (oder CPU-Kerne) auf dem System und dem Vierfachen der Anzahl der CPUs fest. Bei einem System mit 16 Kernen liegt dieser Wert wahrscheinlich zwischen 16 und 64. 

[mysqld]
...
innodb_thread_concurrency=32

Transaktionsdauerhaftigkeit

Bei einem Transaktionswert von 1 muss MySQL für jede Transaktion auf die Festplatte schreiben. Wenn der Server abstürzt, geht die Transaktion nicht verloren, aber die Datenbankleistung wird beeinträchtigt. Wenn Sie diesen Wert auf 0 oder 2 festlegen, kann die Leistung verbessert werden. Allerdings besteht dann das Risiko, dass Daten von einigen Sekunden verloren gehen. 

[mysqld]
...
innodb_flush_log_at_trx_commit=1

Flush-Methode festlegen

Das Betriebssystem puffert Schreibvorgänge auf der Festplatte normalerweise. Da sowohl MySQL als auch das Betriebssystem puffern, kommt es zu Leistungseinbußen. Wenn Sie die Flush-Methode um eine Pufferebene reduzieren, kann sich die Leistung verbessern. 

[mysqld]
...
innodb_flush_method=O_DIRECT

Eine Datei pro Tabelle aktivieren

Standardmäßig verwendet MySQL eine einzelne Datendatei für alle Daten. Bei der Einstellung innodb_file_per_table wird für jede Tabelle eine separate Datei erstellt. Das verbessert die Leistung und die Datenverwaltung. 

[mysqld]
...
innodb_file_per_table=ON

Statistiken zu Metadaten deaktivieren

Mit dieser Einstellung wird die Erfassung von Statistiken für interne Metadatentabellen deaktiviert, was die Leseleistung verbessert. 

[mysqld]
...
innodb_stats_on_metadata=OFF

Abfrage-Cache deaktivieren

Der Abfragecache ist veraltet. Wenn Sie query_cache_size und query_cache_type auf 0 setzen, wird er deaktiviert. 

[mysqld]
...
query_cache_size=0
query_cache_type=0

Join-Zwischenspeicher vergrößern

Der join_buffer wird verwendet, um Joins im Arbeitsspeicher auszuführen. Durch eine Erhöhung kann die Leistung bestimmter Vorgänge verbessert werden. 

[mysqld]
...
join_buffer_size=512KB

Größe der temporären Tabelle und maximale Heap-Größe erhöhen

Mit tmp_table_size und max_heap_table_size werden angemessene Standardwerte für temporäre In-Memory-Tabellen festgelegt, bevor sie auf die Festplatte geschrieben werden. 

[mysqld
...
tmp_table_size=32MB
max_heap_table_size=32MB

Cache für geöffnete Tabellen anpassen

Die Einstellung table_open_cache bestimmt die Größe des Caches, der die Dateideskriptoren für geöffnete Tabellen enthält. Bei der Einstellung table_open_cache_instances wird der Cache in mehrere kleinere Teile aufgeteilt. Im table_open_cache kann es zu Thread-Konflikten kommen. Wenn Sie ihn in kleinere Teile aufteilen, können Sie die Nebenläufigkeit erhöhen. 

[mysqld]
...
table_open_cache=2048
table_open_cache_instances=16

Git-Dienst

Looker ist für die Verwendung mit einem Git-Dienst konzipiert, um die Versionsverwaltung der LookML-Dateien zu ermöglichen. Wichtige Git-Hostingdienste wie GitHub, GitLab und Bitbucket werden unterstützt. Git-Dienstanbieter bieten zusätzliche Vorteile wie eine GUI zum Anzeigen von Codeänderungen und Unterstützung für Workflows wie Pull-Anfragen und Änderungsfreigaben. Bei Bedarf kann Git auf einem einfachen Linux-Server ausgeführt werden.

Wenn ein Git-Hostingdienst aufgrund von Sicherheitsregeln nicht für Ihre Bereitstellung geeignet ist, bieten viele dieser Anbieter Versionen an, die in Ihrer eigenen Umgebung ausgeführt werden können. Insbesondere GitLab wird häufig selbst gehostet und kann als Open-Source-Produkt ohne Lizenzkosten oder als unterstütztes lizenziertes Produkt verwendet werden. GitHub Enterprise ist als selbst gehosteter Dienst verfügbar und ist ein unterstütztes kommerzielles Produkt.

In den folgenden Abschnitten werden die Besonderheiten der gängigsten Dienstanbieter aufgeführt.

GitHub/GitHub Enterprise

Auf der Dokumentationsseite Git-Verbindung einrichten und testen wird GitHub als Beispiel verwendet.

GitLab/gitlab.com

Eine detaillierte Anleitung zur Einrichtung von GitLab finden Sie im Looker-Community-Beitrag Using GitLab for version control in Looker. Wenn sich Ihr Repository in Untergruppen befindet, können diese der Repository-URL im HTTPS- oder SSH-Format hinzugefügt werden: 

https://gitlab.com/accountname/subgroup/reponame


git@gitlab.com:accountname/subgroup/reponame.git

Außerdem gibt es drei verschiedene Möglichkeiten, von Looker generierte SSH-Schlüssel in GitLab zu speichern: als Nutzer-SSH-Schlüssel, als Repository-Deploy-Schlüssel oder als globaler freigegebener Deploy-Schlüssel. Eine ausführlichere Erklärung finden Sie in der GitLab-Dokumentation.

Google Cloud Quelle

Eine Anleitung zum Einrichten von Git mit Cloud Source Repositories finden Sie im Community-Beitrag Cloud Source Repositories für die Versionsverwaltung in Looker verwenden.

Bitbucket Cloud

Eine Anleitung zum Einrichten von Git mit Bitbucket Cloud finden Sie im Community-Beitrag Bitbucket für die Versionsverwaltung in Looker verwenden. Seit August 2021 werden keine Secrets in Webhooks für die Bereitstellung in Bitbucket Cloud unterstützt.

Bitbucket Server

Wenn Sie Pull-Anfragen mit Bitbucket Server verwenden möchten, müssen Sie möglicherweise die folgenden Schritte ausführen:

  1. Wenn Sie einen Pull-Request öffnen, verwendet Looker automatisch die Standardportnummer (7999) in der URL. Wenn Sie eine benutzerdefinierte Portnummer verwenden, müssen Sie die Portnummer in der URL manuell ersetzen.
  2. Sie müssen den Webhook für die Bereitstellung des Projekts aufrufen, um den Produktionszweig in Looker mit dem Hauptzweig des Repositorys zu synchronisieren.

Phabricator-Diffusion

Im Community-Beitrag Phabricator und Looker für die Versionsverwaltung einrichten finden Sie eine Anleitung zum Einrichten von Git mit Phabricator.

Netzwerk

Eingehende Verbindungen

Looker-Webanwendung

Standardmäßig überwacht Looker HTTPS-Anfragen an Port 9999. Looker verwendet ein selbst signiertes Zertifikat mit dem CN self-signed.looker.com. Der Looker-Server kann alternativ so konfiguriert werden, dass er Folgendes ausführt:

  1. HTTP-Verbindungen von einem Load-Balancer/Proxy mit SSL-Beendigung mit dem --ssl-provided-externally-by=<s>-Start-up-Flag akzeptieren. Der Wert sollte entweder auf die IP-Adresse des Proxys oder auf einen Hostnamen festgelegt werden, der lokal in die IP-Adresse des Proxys aufgelöst werden kann. Looker akzeptiert HTTP-Verbindungen nur von dieser IP-Adresse.
  2. Verwenden Sie ein vom Kunden bereitgestelltes SSL-Zertifikat mit dem Startup-Flag --ssl-keystore=<s>.

Looker API

Die Looker API überwacht Port 19999. Wenn für die Installation Zugriff auf die API erforderlich ist, sollte der Load-Balancer die erforderlichen Weiterleitungsregeln haben. Es gelten dieselben SSL-Überlegungen wie bei der Hauptwebanwendung. Wir empfehlen, einen anderen Port als für die Webanwendung zu verwenden.

Load-Balancer

Ein Load Balancer wird häufig verwendet, um eine HTTPS-Anfrage an Port 443 mit dem Zertifikat des Kunden anzunehmen und die Anfrage dann mit dem selbstsignierten Zertifikat oder über HTTP an den Looker-Serverknoten an Port 9999 weiterzuleiten. Wenn Load-Balancer das selbst signierte Zertifikat von Looker verwenden, müssen sie so konfiguriert werden, dass sie dieses Zertifikat akzeptieren.

Inaktive Verbindungen und Zeitüberschreitungen

Wenn ein Nutzer eine umfangreiche Anfrage in Looker startet, kann dies zu einer Abfrage führen, deren Ausführung in der Datenbank kostspielig sein kann. Wenn der Nutzer die Anfrage auf irgendeine Weise abbricht, z. B. indem er den Laptopdeckel schließt, die Verbindung zum Netzwerk trennt oder den Tab im Browser schließt, muss Looker dies erkennen und die Datenbankabfrage beenden.

Um diese Situation zu bewältigen, öffnet der Browser eine Socket-Verbindung mit einer langlebigen HTTP-Anfrage an den Looker-Server, wenn die Client-Webanwendung eine Anfrage zum Ausführen einer Datenbankabfrage stellt. Diese Verbindung bleibt offen und inaktiv. Diese Socket-Verbindung wird getrennt, wenn die Client-Webanwendung beendet oder auf andere Weise getrennt wird. Der Server erkennt die Trennung und bricht alle zugehörigen Datenbankabfragen ab.

Load Balancer erkennen diese offenen Leerlaufverbindungen oft und beenden sie. Damit Looker effektiv ausgeführt werden kann, muss der Load Balancer so konfiguriert sein, dass diese Verbindung so lange geöffnet bleibt, wie die längste Abfrage, die ein Nutzer ausführen kann. Es wird ein Zeitlimit von mindestens 60 Minuten empfohlen.

Ausgehende Verbindungen

Looker-Server können uneingeschränkten ausgehenden Zugriff auf alle Ressourcen haben, einschließlich des öffentlichen Internets. Dies vereinfacht viele Aufgaben, z. B. die Installation von Chromium, für die Zugriff auf die Paket-Repositories für die Linux-Distribution erforderlich ist.

Die folgenden ausgehenden Verbindungen sind möglicherweise für Looker erforderlich.

Interne Datenbankverbindung

Standardmäßig überwacht MySQL Verbindungen an Port 3306. Die Looker-Knoten müssen Verbindungen zu MySQL über diesen Port herstellen können. Je nachdem, wie das Repository gehostet wird, müssen Sie möglicherweise eine Firewall durchlaufen.

Externe Dienstleistungen

Die Looker-Telemetrie- und Lizenzserver sind über HTTPS im öffentlichen Internet verfügbar. Traffic von einem Looker-Knoten zu ping.looker.com:443 und license.looker.com:443 muss möglicherweise einer Zulassungsliste hinzugefügt werden.

Data-Warehouse-Verbindungen

Für in der Cloud gehostete Datenbanken ist möglicherweise eine Verbindung über das öffentliche Internet erforderlich. Wenn Sie beispielsweise BigQuery verwenden, müssen accounts.google.com:443 und www.googleapis.com:443 möglicherweise einer Zulassungsliste hinzugefügt werden. Wenn sich die Datenbank außerhalb Ihrer eigenen Infrastruktur befindet, wenden Sie sich an Ihren Datenbankhost, um Informationen zum Netzwerk zu erhalten.

SMTP-Dienste

Standardmäßig sendet Looker ausgehende E-Mails über SendGrid. Dazu müssen Sie möglicherweise smtp.sendgrid.net:587 einer Zulassungsliste hinzufügen. Die SMTP-Einstellungen können in der Konfiguration geändert werden, um auch einen anderen Mail-Handler zu verwenden.

Action Hubs, Action-Server und Webhooks

Bei vielen Planerzielen, insbesondere bei Webhooks und den im Looker-Adminbereich aktivierten Zielen, werden Daten über HTTPS-Anfragen gesendet.

  • Bei Webhooks werden diese Ziele zur Laufzeit von Nutzern angegeben und können dem Ziel, ausgehende Verbindungen durch Firewalls zu schützen, entgegenstehen.
  • Bei einem Aktions-Hub werden diese Anfragen an actions.looker.com gesendet. Weitere Informationen finden Sie in der Dokumentation zur Konfiguration des Looker Action Hub.
  • Bei anderen Aktionsservern werden diese Anfragen von Administratoren im Looker-Administratorbereich an die in der Konfiguration des Aktionsservers angegebenen Domains gesendet.

Proxyserver

Wenn das öffentliche Internet nicht direkt erreichbar ist, kann Looker so konfiguriert werden, dass ein Proxyserver für HTTP(S)-Anfragen verwendet wird. Fügen Sie dazu eine Zeile wie die folgende zu lookerstart.cfg hinzu: 

JAVAARGS="-Dhttp.proxyHost=myproxy.example.com
  -Dhttp.proxyPort=8080
  -Dhttp.nonProxyHosts=127.0.0.1|localhost
  -Dhttps.proxyHost=myproxy.example.com
  -Dhttps.proxyPort=8080"

Die Kommunikation zwischen Knoten erfolgt über HTTPS. Wenn Sie also einen Proxyserver verwenden und Ihre Instanz geclustert ist, sollten Sie in der Regel die IPs/Hostnamen für alle Knoten im Cluster dem Dhttp.nonProxyHosts-Argument hinzufügen.

Kommunikation zwischen Knoten

Interne Host-ID

Innerhalb eines Clusters muss jeder Knoten mit den anderen Knoten kommunizieren können. Dazu wird der Hostname oder die IP-Adresse jedes Knotens in der Startkonfiguration angegeben. Wenn der Knoten gestartet wird, wird dieser Wert in das MySQL-Repository geschrieben. Andere Mitglieder des Clusters können dann auf diese Werte verweisen, um mit diesem Knoten zu kommunizieren. Wenn Sie den Hostnamen oder die IP-Adresse in der Startkonfiguration angeben möchten, fügen Sie -H node1.looker.example.com der Umgebungsvariable LOOKERARGS in lookerstart.cfg hinzu.

Da der Hostname pro Knoten eindeutig sein muss, muss die Datei lookerstart.cfg auf jeder Instanz eindeutig sein. Alternativ zum Festcodieren des Hostnamens oder der IP-Adresse können Sie den Befehl hostname -I oder hostname --fqdn verwenden, um diese zur Laufzeit zu ermitteln. Fügen Sie dazu -H $(hostname -I) oder -H $(hostname --fqdn) in lookerstart.cfg der Umgebungsvariable LOOKERARGS hinzu.

Interne Ports

Zusätzlich zu den Ports 9999 und 19999, die für die Web- bzw. API-Server verwendet werden, kommunizieren die Clusterknoten über einen Message Broker-Dienst, der die Ports 1551 und 61616 verwendet. Die Ports 9999 und 19999 müssen für Endnutzer-Traffic geöffnet sein, die Ports 1551 und 61616 müssen zwischen Clusternknoten geöffnet sein.