Auf dieser Seite werden gängige Praktiken für bestimmte Komponenten der Looker-Architektur beschrieben und erläutert, wie sie in einer Bereitstellung konfiguriert werden.
Looker hat eine Reihe von Abhängigkeiten für das Hosting des Servers, die Bereitstellung sowohl von Ad-hoc- als auch von geplanten Arbeitslasten, die Nachverfolgung der iterativen Modellentwicklung usw. Diese Abhängigkeiten werden auf dieser Seite als Komponenten bezeichnet. Jede Komponente wird in den folgenden Abschnitten ausführlich behandelt:
- Hostkonfiguration
- JVM-Konfiguration
- Looker-Startoptionen
- Interne (Back-End-)Datenbank
- Git-Dienst
- Netzwerk
Hostkonfiguration
Betriebssystem und Distribution
Looker läuft gut auf 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. Beispielsweise sind die Google Cloud- oder AWS-Distributionen von Linux mit Looker kompatibel. Debian/Ubuntu ist die am stärksten verwendete Linux-Variante in der Looker-Community. Diese Versionen sind dem Looker-Support 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. Überlegen Sie bei der Auswahl einer Distribution, ob die Versionen von OpenJDK 11 aktuell sind. Auf älteren Linux-Distributionen kann Looker möglicherweise ausgeführt werden. Die Java-Version und ‑Bibliotheken, die Looker für bestimmte Funktionen benötigt, müssen jedoch 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 höher oder Java OpenJDK 11.0.12 oder höher erforderlich.
CPU und Arbeitsspeicher
4 x 16-Knoten (4 CPUs und 16 GB RAM) sind für ein Entwicklungssystem oder eine Looker-Basistestinstanz, die von einem kleinen Team verwendet wird, ausreichend. In einer Produktionsumgebung reicht dies jedoch in der Regel nicht aus. Unserer Erfahrung nach bieten 16x64-Knoten (16 CPUs und 64 GB RAM) ein gutes Gleichgewicht zwischen Preis und Leistung. Mehr als 64 GB RAM können sich auf die Leistung auswirken, da Garbage-Collection-Ereignisse ein einzelnes Thread haben und alle anderen Threads anhalten.
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. Bei Java kann es zu Problemen beim Verwalten von mehr als 64 GB Arbeitsspeicher kommen. Allgemein gilt: Wenn mehr Kapazität benötigt wird, sollten Sie dem Cluster weitere 16x64-Knoten hinzufügen, anstatt die Knotengröße auf über 16x64 hinaus zu erhöhen. Möglicherweise bevorzugen wir auch eine Clusterarchitektur für eine höhere Verfügbarkeit.
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 gemeinsam genutzt wird und mehrere Git-Repositories hostet, sind der gleichzeitige Zugriff und die Dateisperrung von entscheidender Bedeutung. Das Dateisystem muss POSIX-konform sein. Network File System (NFS) funktioniert bekanntermaßen und ist mit Linux leicht verfügbar. Sie sollten eine zusätzliche Linux-Instanz erstellen und NFS zur Freigabe des Laufwerks konfigurieren. Standard-NFS ist potenziell ein Single Point of Failure. Daher sollten Sie eine Failover- oder Hochverfügbarkeitseinrichtung in Betracht ziehen.
Die Looker-Metadaten müssen ebenfalls zentralisiert werden, sodass die interne Datenbank zu MySQL migriert werden muss. Dies kann ein MySQL-Dienst oder eine dedizierte MySQL-Bereitstellung sein. Weitere Informationen finden Sie im Abschnitt Interne Datenbank (Back-End) auf dieser Seite.
JVM-Konfiguration
Die Looker-JVM-Einstellungen werden im Looker-Startskript definiert. Nach allen Aktualisierungen muss Looker neu gestartet werden, damit Änderungen am Manifest vorgenommen werden. Die Standardkonfigurationen sind:
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 Arbeitsspeicherzuweisung für die JVM muss der Overhead des Betriebssystems berücksichtigt werden, auf dem Looker ausgeführt wird. Als Faustregel gilt: Die JVM kann bis zu 60% des Gesamtarbeitsspeichers zugewiesen werden, es gibt jedoch je nach Maschinengröße Einschränkungen. Für Maschinen mit mindestens 8 GB Arbeitsspeicher empfehlen wir, 4–5 GB für Java und 800 MB für Meta zuzuweisen. Bei größeren Maschinen kann dem Betriebssystem ein geringerer Anteil des Arbeitsspeichers zugewiesen werden. Für Maschinen mit 60 GB Arbeitsspeicher empfehlen wir beispielsweise, 36 GB für Java und 1 GB für Meta zuzuweisen. Die Arbeitsspeicherzuweisung von Java sollte normalerweise mit dem Gesamtspeicher des Computers skalieren. 1 GB sollte für Meta jedoch ausreichen.
Da Looker Systemressourcen für das Rendern mit anderen Prozessen wie Chromium teilt, sollte die Menge des Java-Arbeitsspeichers im Hinblick auf die erwartete Renderlast und die Größe des Computers ausgewählt werden. Wenn eine geringe Rendering-Last erwartet wird, kann Java ein größerer Anteil des Gesamtspeichers zugewiesen werden. Auf einem Rechner mit insgesamt 60 GB Arbeitsspeicher könnte Java beispielsweise 46 GB sicher zugewiesen werden, was über der allgemeinen Empfehlung von 60% liegt. Die genauen Ressourcenzuweisungen für jede Bereitstellung variieren, verwenden Sie also 60% als Ausgangsbasis und passen Sie die Ressourcen nach Bedarf an.
Automatische Speicherbereinigung
Looker bevorzugt die Verwendung des modernsten Garbage Collectors, der für seine Java-Version verfügbar ist. Standardmäßig beträgt das Zeitlimit für die Garbage Collection 2 Sekunden. Sie können es jedoch ä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
Standardmäßig werden die Looker-Logs für die automatische Speicherbereinigung in /tmp/gc.log gespeichert. Sie können dies ändern, indem Sie die folgende Option in der Startkonfiguration bearbeiten:
-Xloggc:/tmp/gc.log
JMX
Die Verwaltung von Looker erfordert möglicherweise ein Monitoring, um die Ressourcen besser zu optimieren. Wir empfehlen die Verwendung von JMX, um die JVM-Arbeitsspeichernutzung zu überwachen.
Looker-Startoptionen
Die Startoptionen sind in einer Datei namens lookerstart.cfg gespeichert. Diese Datei stammt aus dem Shell-Skript, das Looker startet.
Threadpools
Da Looker eine mehrstufige Anwendung ist, hat sie eine Reihe von Threadpools. Diese Threadpools reichen vom Webserverkern bis hin zu spezialisierten Unterdiensten wie Planung, Rendering und externen Datenbankverbindungen. Abhängig von Ihren Geschäftsworkflows müssen diese Pools möglicherweise im Vergleich zur Standardkonfiguration geändert werden. Insbesondere für die Clustertopologien, die auf der Seite Architekturmuster und Praktiken für vom Kunden gehostete Infrastrukturen erwähnt werden, sind spezielle Überlegungen zu beachten.
Optionen für einen hohen Planungsdurchsatz
Fügen Sie für alle Knoten, die nicht zum Planer gehören, der Umgebungsvariablen LOOKERARGS in lookerstart.cfg --scheduler-threads=0 hinzu. Ohne Planerthreads werden auf diesen Knoten keine geplanten Jobs ausgeführt.
Fügen Sie für alle dedizierten Planerknoten --scheduler-threads=<n> zur Umgebungsvariable LOOKERARGS in lookerstart.cfg hinzu. Looker beginnt standardmäßig mit 10 Planer-Threads, aber dieser Wert kann auf <n> erhöht werden. Mit <n> Planer-Threads, jeder Knoten kann <n> ausführen gleichzeitigen geplanten Jobs. Im Allgemeinen wird empfohlen, <n> auf weniger als das Doppelte der Anzahl der CPUs festzulegen. Der größte empfohlene Host ist einer mit 16 CPUs und 64 GB Arbeitsspeicher. Daher sollte die Obergrenze der Planer-Threads kleiner als 32 sein.
Optionen für hohen Renderingdurchsatz
Fügen Sie für alle Nicht-Rendering-Knoten der Umgebungsvariable LOOKERARGS in lookerstart.cfg --concurrent-render-jobs=0 hinzu. Ohne Rendererknoten werden auf diesen Knoten keine Renderjobs ausgeführt.
Fügen Sie für alle dedizierten Renderingknoten der Umgebungsvariable LOOKERARGS in lookerstart.cfg --concurrent-render-jobs=<n> hinzu. Looker startet standardmäßig mit zwei Rendering-Threads, die Anzahl kann aber auf <n> erhöht werden. Mit <n> Rendering-Threads kann jeder Knoten <n> parallele Rendering-Jobs ausführen.
Jeder Renderingjob kann viel Arbeitsspeicher verbrauchen. Das Budget beträgt etwa 2 GB pro Renderingjob. Wenn dem Looker-Kernprozess (Java) beispielsweise 60% des Gesamtspeichers zugewiesen werden und 20% des verbleibenden Arbeitsspeichers für das Betriebssystem reserviert sind, bleiben die letzten 20% für Renderingjobs übrig. Auf einem 64-GB-Rechner bleiben 12 GB übrig, was für sechs gleichzeitige Renderjobs ausreicht. Wenn ein Knoten für das Rendern vorgesehen ist und nicht in dem Load-Balancer-Pool enthalten ist, der interaktive Jobs verarbeitet, kann der Kern des Looker-Prozessspeichers reduziert werden, um mehr Renderingjobs zu ermöglichen. Auf einer 64-GB-Maschine könnten dem Looker-Kernprozess etwa 30% (20 GB) zugewiesen werden. 20% werden für die allgemeine Nutzung des Betriebssystems reserviert, sodass 50% (32 GB) für das Rendering übrig bleiben, was für 16 gleichzeitige Renderingjobs ausreicht.
Interne (Backend-)Datenbank
Der Looker-Server verwaltet Informationen über seine eigene Konfiguration, Datenbankverbindungen, Benutzer, Gruppen und Rollen, Ordner, benutzerdefinierte 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 sind in der Datei <looker install directory>/.db/looker.script gespeichert. Obwohl diese Datenbank praktisch und schlank ist, kommt es bei starker Nutzung zu Leistungsproblemen. Wir empfehlen daher, mit einer Remote-MySQL-Datenbank zu beginnen. Wenn dies nicht möglich ist, empfehlen wir die Migration zu einer MySQL-Remote-Datenbank, sobald die Datei ~/looker/.db/looker.script 600 MB erreicht. Cluster müssen eine MySQL-Datenbank verwenden.
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, ob er Berechtigungen für die Ausführung des Looks oder Explores hat usw. Looker schreibt auch Daten in die MySQL-Datenbank, z. B. die tatsächlich ausgeführte SQL-Abfrage und die Uhrzeit, zu der die Anfrage gestartet und beendet wurde. Eine einzelne Interaktion zwischen einem Nutzer und der Looker-Anwendung kann 15 oder 20 kleine Lese- und Schreibvorgänge in der MySQL-Datenbank auslösen.
MySQL
Der MySQL-Server muss die Version 8.0.x haben und für die Verwendung der utf8mb4-Codierung konfiguriert sein. Das Speichermodul InnoDB 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-Back-End-Datenbank zu MySQL migrieren.
Wenn Sie Looker für die Verwendung von MySQL konfigurieren, muss eine YAML-Datei mit den Verbindungsinformationen erstellt werden. Nennen Sie die YAML-Datei looker-db.yml und fügen Sie die Einstellung -d looker-db.yml in den Abschnitt LOOKERARGS der Datei lookerstart.cfg ein.
MariaDB
MySQL ist doppelt lizenziert und sowohl als Open Source als auch als kommerzielles Produkt verfügbar. Oracle hat MySQL kontinuierlich verbessert und MySQL wird als MariaDB verzweigt. Es ist bekannt, dass die MariaDB-Äquivalente von MySQL mit Looker kompatibel sind, aber nicht für die Looker-Engineering-Teams entwickelt oder getestet werden. Die Funktionalität wird daher nicht unterstützt oder garantiert.
Cloud-Versionen
Wenn Sie Looker in Ihrer Cloud-Infrastruktur hosten, ist es logisch, die MySQL-Datenbank in derselben Cloud-Infrastruktur zu hosten. Die drei großen Cloud-Anbieter: Amazon AWS, Microsoft Azure und Google Cloud. Die Cloud-Anbieter übernehmen einen Großteil der Wartung und Konfiguration der MySQL-Datenbank und bieten Dienste wie die Verwaltung von Sicherungen und die schnelle Wiederherstellung. Diese Produkte funktionieren bekanntermaßen gut mit Looker.
Systemaktivitätsabfragen
In der MySQL-Datenbank werden Informationen darüber gespeichert, wie Nutzer Looker verwenden. Jeder Looker-Nutzer, der die Berechtigung zum Ansehen des Modells Systemaktivität hat, hat Zugriff auf eine Reihe vordefinierter Looker-Dashboards, um diese Daten zu analysieren. Benutzer können auch auf Explores von Looker-Metadaten zugreifen, um weitere Analysen zu erstellen. Die MySQL-Datenbank wird vor allem für kleine, schnelle "operative" Abfragen. Die großen, langsamen „analytischen“ Abfragen, die vom Systemaktivitätsmodell generiert werden, können mit diesen betrieblichen Abfragen konkurrieren und Looker verlangsamen.
In diesen Fällen kann die MySQL-Datenbank in einer anderen Datenbank repliziert werden. Sowohl selbstverwaltete als auch bestimmte cloudbasierte Systeme bieten eine grundlegende Konfiguration der Replikation in anderen Datenbanken. Das Konfigurieren der Replikation wird in diesem Dokument nicht behandelt.
Wenn Sie das Replikat für Abfragen zur Systemaktivität verwenden möchten, erstellen Sie eine Kopie der Datei looker-db.yml, z. B. mit dem Namen looker-usage-db.yml, ändern Sie sie so, dass sie auf das Replikat verweist, und fügen Sie dem Abschnitt LOOKERARGS der Datei lookerstart.cfg 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 getestet.
MySQL-Leistungskonfiguration
Zusätzlich zu den Einstellungen, die für die Migration der Looker-Back-End-Datenbank zu MySQL erforderlich sind, können hochaktive Cluster von einer zusätzlichen Feinabstimmung und Konfiguration profitieren. Diese Einstellungen können für die Datei /etc/my.cnf oder für in der Cloud verwaltete Instanzen über die Google Cloud Console vorgenommen werden.
Die Konfigurationsdatei my.cnf ist in mehrere Teile unterteilt. Die folgenden in diesem Abschnitt beschriebenen Einstellungsänderungen werden im Bereich [mysqld] vorgenommen.
Größe des InnoDB-Pufferpools festlegen
Die Größe des InnoDB-Pufferpools ist der gesamte RAM, der zum Speichern des Status der InnoDB-Dateien im Arbeitsspeicher verwendet wird. Wenn der Server für die Ausführung von MySQL vorgesehen ist, sollte innodb_buffer_pool_size auf 50–70 % des gesamten Systemspeichers festgelegt werden.
Wenn die Datenbank insgesamt klein ist, kann der InnoDB-Pufferpool auf die Größe der Datenbank und nicht auf 50% oder mehr des Arbeitsspeichers eingestellt werden.
In diesem Beispiel hat ein Server 64 GB Arbeitsspeicher. Daher sollte der InnoDB-Pufferpool zwischen 32 GB und 45 GB groß sein. Je größer, desto 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 konfliktfrei zugreifen können. Standardmäßig ist der Pufferpool in 8 Instanzen unterteilt. Dies kann zu einem Engpass bei 8 Threads führen. Durch eine Erhöhung der Anzahl der Pufferpoolinstanzen wird die Wahrscheinlichkeit eines Engpasses verringert. Die Instanzen 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 verbindlich wird, kann die Datenbank die Daten in der tatsächlichen Datei aktualisieren oder Details zur Transaktion im Protokoll speichern. Wenn die Datenbank abstürzt, bevor die Datendateien aktualisiert wurden, kann die Protokolldatei "wiedergegeben" werden. um die Änderungen zu übernehmen. Das Schreiben in die Protokolldatei ist ein kleiner Append-Vorgang. Es ist effizient, dem Protokoll zum Zeitpunkt des Commits etwas hinzuzufügen und dann mehrere Änderungen an den Datendateien in einem einzigen E/A-Vorgang zu schreiben. Wenn die Protokolldatei gefüllt ist, muss die Datenbank die Verarbeitung neuer Transaktionen unterbrechen und alle geänderten Daten zurück auf das Laufwerk schreiben.
Als Faustregel gilt: Die InnoDB-Logdatei sollte groß genug sein, um Transaktionen von einer Stunde aufzunehmen.
Normalerweise gibt es zwei InnoDB-Logdateien. Sie sollten etwa 25% Ihres InnoDB-Pufferpools ausmachen. Bei einer Beispieldatenbank mit einem Pufferpool von 32 GB sollten die InnoDB-Protokolldateien insgesamt 8 GB bzw. 4 GB pro Datei enthalten.
[mysqld] ... innodb_log_file_size=8GB
InnoDB-E/A-Kapazität konfigurieren
MySQL drosselt die Geschwindigkeit, mit der Schreibvorgänge auf der Festplatte 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 dann mit diesem Wert die E/A-Kapazität so konfigurieren, dass MySQL Daten schneller schreibt.
Bei einem in der Cloud gehosteten System sollte der Cloud-Anbieter die Leistung der Laufwerke, die für die Datenspeicherung verwendet werden, erfassen können. Messen Sie bei einem selbst gehosteten MySQL-Server die Geschwindigkeit zufälliger Schreibvorgänge auf das 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 ein halbes bis drei Viertel davon für innodb_io_capacity verwendet. Im folgenden Beispiel sehen wir die Werte, die wir bei 800 IOPS gemessen haben.
[mysqld] ... innodb_io_capacity=500 innodb_io_capacity_max=800
InnoDB-Threads konfigurieren
MySQL öffnet mindestens einen Thread für jeden bereitgestellten Client. Wenn viele Clients gleichzeitig verbunden sind, kann das zu einer enormen Anzahl von Threads führen, die verarbeitet werden müssen. Dies kann dazu führen, dass das System mehr Zeit für das Auslagern als für die Verarbeitung aufwendet.
Die ideale Anzahl von Threads sollte durch Benchmarking ermittelt werden. Legen Sie für den Test die Anzahl der Threads zwischen der Anzahl der CPUs (oder CPU-Kerne) im 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
Transaktionsdauer
Der Transaktionswert 1 zwingt MySQL, für jede Transaktion auf ein Laufwerk zu 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. Es besteht jedoch das Risiko, dass Datentransaktionen von einigen Sekunden verloren gehen.
[mysqld] ... innodb_flush_log_at_trx_commit=1
Spülenmethode festlegen
Das Betriebssystem puffert normalerweise Schreibvorgänge auf dem Laufwerk. Da sowohl MySQL als auch das Betriebssystem zwischenspeichern, 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, was die Leistung und die Datenverwaltung verbessert.
[mysqld] ... innodb_file_per_table=ON
Statistiken zu Metadaten deaktivieren
Mit dieser Einstellung wird die Erfassung von Statistiken in internen Metadatentabellen deaktiviert, was die Leseleistung verbessert.
[mysqld] ... innodb_stats_on_metadata=OFF
Abfrage-Cache deaktivieren
Der Abfragecache wurde verworfen. Wenn Sie query_cache_size und query_cache_type auf 0 festlegen, wird er deaktiviert.
[mysqld] ... query_cache_size=0 query_cache_type=0
Join-Puffer 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 des maximalen Heaps vergrößern
tmp_table_size und max_heap_table_size legen angemessene Standardeinstellungen für temporäre speicherinterne Tabellen fest, bevor sie auf ein Laufwerk erzwungen 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 Cache, der die Dateideskriptoren für geöffnete Tabellen enthält. Durch die Einstellung table_open_cache_instances wird der Cache in mehrere kleinere Teile aufgeteilt. Es besteht die Gefahr von Threadkonflikten in der table_open_cache. Durch die Aufteilung in kleinere Teile lässt sich die Parallelität erhöhen.
[mysqld] ... table_open_cache=2048 table_open_cache_instances=16
Git-Dienst
Looker wurde für die Verwendung mit einem Git-Dienst entwickelt, um die Versionsverwaltung der LookML-Dateien zu ermöglichen. Alle gängigen Git-Hosting-Dienste werden unterstützt, darunter GitHub, GitLab und Bitbucket. Git-Dienstanbieter bieten zusätzliche Mehrwerte wie eine grafische Benutzeroberfläche zum Ansehen von Codeänderungen und Unterstützung für Workflows wie Pull-Anfragen und Änderungsgenehmigungen. 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 Dienstanbieter 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 ein unterstütztes kommerzielles Produkt.
In den folgenden Abschnitten sind Nuancen für die gängigsten Dienstanbieter aufgeführt.
GitHub/GitHub Enterprise
Auf der Dokumentationsseite zum Einrichten und Testen einer Git-Verbindung wird GitHub als Beispiel verwendet.
GitLab/gitlab.com
Detaillierte Einrichtungsschritte für GitLab finden Sie im Looker-Communitybeitrag GitLab für die Versionskontrolle in Looker verwenden. Wenn Ihr Repository in Untergruppen enthalten ist, können diese der Repository-URL entweder im HTTPS- oder im 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-Deployment-Schlüssel oder als global freigegebener Deployment-Schlüssel. Eine ausführlichere Erläuterung finden Sie in der GitLab-Dokumentation.
Google Cloud Source
Im Communitybeitrag Cloud Source Repositories für die Versionskontrolle in Looker verwenden finden Sie eine Anleitung zum Einrichten von Git mit Cloud Source Repositories.
Bitbucket Cloud
Informationen zum Einrichten von Git mit Bitbucket Cloud finden Sie im Communitybeitrag Bitbucket für die Versionsverwaltung in Looker verwenden. Seit August 2021 werden in Bitbucket Cloud keine Geheimnisse in Deploy-Webhooks unterstützt.
Bitbucket Server
Wenn Sie Pull-Requests mit Bitbucket Server verwenden möchten, müssen Sie möglicherweise die folgenden Schritte ausführen:
- Wenn Sie eine Pull-Anfrage öffnen, verwendet Looker automatisch die Standard-Portnummer (7999) in der URL. Wenn Sie eine benutzerdefinierte Portnummer verwenden, müssen Sie die Portnummer in der URL manuell ersetzen.
- Sie müssen den Bereitstellungs-Webhook des Projekts aufrufen, um den Produktionszweig in Looker mit dem Hauptzweig des Repositorys zu synchronisieren.
Phabricator-Diffusion
Im Communitybeitrag Phabricator und Looker für die Versionskontrolle einrichten finden Sie eine Anleitung zum Einrichten von Git mit Phabricator.
Netzwerk
Eingehende Verbindungen
Looker-Webanwendung
Standardmäßig wartet Looker auf HTTPS-Anfragen an Port 9999. Looker verwendet ein selbst signiertes Zertifikat mit der CN self-signed.looker.com. Alternativ kann der Looker-Server für Folgendes konfiguriert werden:
- HTTP-Verbindungen von einem Load Balancer/Proxy mit SSL-Beendigung mit dem
--ssl-provided-externally-by=<s>Startup-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 nur HTTP-Verbindungen von dieser IP-Adresse. - Verwenden Sie ein vom Kunden bereitgestelltes SSL-Zertifikat mit dem Start-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 Haupt-Webanwendung. Wir empfehlen, einen anderen Port als 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 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 Benutzer eine große Anforderung in Looker startet, kann dies zu einer Abfrage führen, deren Ausführung in der Datenbank teuer werden kann. Wenn der Nutzer diese Anfrage auf irgendeine Weise abbricht, z. B. indem er den Laptop schließt, die Verbindung zum Netzwerk trennt oder den Tab im Browser schließt, muss Looker diese Datenbankabfrage beenden.
Wenn die Client-Webanwendung eine Anfrage zum Ausführen einer Datenbankabfrage stellt, öffnet der Browser eine Socket-Verbindung mit einer langlebigen HTTP-Anfrage an den Looker-Server. Diese Verbindung bleibt offen und inaktiv. Dieser Socket wird getrennt, wenn die Client-Webanwendung auf irgendeine Weise beendet oder getrennt wird. Der Server erkennt, dass alle zugehörigen Datenbankabfragen getrennt und abgebrochen werden.
Load Balancer erkennen diese offenen, inaktiven Verbindungen häufig und beenden sie. Damit Looker effizient ausgeführt werden kann, muss der Load Balancer so konfiguriert sein, dass diese Verbindung so lange geöffnet bleibt, wie die längste Abfrage eines Nutzers ausgeführt wird. 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, wie die Installation von Chromium, wofür der Zugriff auf die Paket-Repositories für die Linux-Distribution erforderlich ist.
Die folgenden ausgehenden Verbindungen müssen möglicherweise von Looker hergestellt werden.
Interne Datenbankverbindung
Standardmäßig überwacht MySQL Verbindungen an Port 3306. Die Looker-Knoten müssen über diesen Port Verbindungen zu MySQL herstellen können. Je nachdem, wie das Repository gehostet wird, müssen Sie möglicherweise eine Firewall durchqueren.
Externe Dienstleistungen
Die Telemetrie- und Lizenzserver von Looker 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, fragen Sie bei Ihrem Datenbankhost nach den Netzwerkdetails.
SMTP-Dienste
Standardmäßig sendet Looker ausgehende E-Mails mit SendGrid. Möglicherweise müssen Sie smtp.sendgrid.net:587 einer Zulassungsliste hinzufügen. Die SMTP-Einstellungen können in der Konfiguration so geändert werden, dass ein anderer E-Mail-Handler verwendet wird.
Action Hubs, Action-Server und Webhooks
Bei vielen Zielen des Zeitplaners, insbesondere bei Webhooks und solchen, die im Looker-Admin-Bereich aktiviert sind, werden Daten per HTTPS-Anfrage gesendet.
- Bei Webhooks werden diese Ziele von Nutzern zur Laufzeit angegeben und können dem Ziel der Firewall für ausgehende Verbindungen widersprechen.
- Bei einem Action-Hub werden diese Anfragen an
actions.looker.comgesendet. Weitere Informationen finden Sie in der Looker Action Hub-Konfigurationsdokumentation. - Bei anderen Aktionsservern werden diese Anfragen von Administratoren im Looker-Bereich Admin an die Domains gesendet, die in der Konfiguration des Aktionsservers angegeben sind.
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 in einem Cluster ausgeführt wird, sollten Sie dem Dhttp.nonProxyHosts-Argument in der Regel die IP-Adressen/Hostnamen aller Knoten im Cluster hinzufügen.
Kommunikation zwischen Knoten
Interne Host-ID
Innerhalb eines Clusters muss jeder Knoten mit den anderen Knoten kommunizieren können. Dazu wird in der Startkonfiguration der Hostname oder die IP-Adresse jedes Knotens angegeben. Beim Starten des Knotens 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 der Umgebungsvariablen LOOKERARGS in lookerstart.cfg -H node1.looker.example.com hinzu.
Da der Hostname pro Knoten eindeutig sein muss, muss die lookerstart.cfg-Datei auf jeder Instanz eindeutig sein. Als Alternative zur Hartcodierung 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 der Umgebungsvariablen LOOKERARGS in lookerstart.cfg -H $(hostname -I) oder -H $(hostname --fqdn) hinzu.
Interne Ports
Zusätzlich zu den Ports 9999 und 19999, die jeweils für die Web- und 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 den Endnutzerverkehr geöffnet sein, 1551 und 61616 jedoch zwischen Clusterknoten.