Mobux

Hue Performance Issues

Kurt Klinner -

Hue wird in zahlreichen Big-Data-Projekten (Achtung: Buzz-Word-Session started jetzt :-)) eingesetzt und ist ein meiner Meinung nach gelungenes Tool um Hive, Spark etc. über ein Web-UI anzusprechen.

In einer unserer CDH-Umgebung stieße wir auf einiges an Performanceproblemen, nachdem nach einer mehr oder weniger Defaultinstallation SSL in Hue selbst aktiviert wurde. Eine tiefere Analyse des Problems ergab zwei Optimierungsansätze

a) Wechsel der von Hue genutzen Backend-DB von sqlite nach mysql oder postgres
b) Deaktivieren von SSL

Als erstes machte ich mich an die Umstellung der DB und folgte brav der von Cloudera gelieferten Anleitung
http://www.cloudera.com/content/cloudera/en/documentation/cloudera-manager/v5-1-x/Cloudera-Manager-Managing-Clusters/cm5mc_hue_service.html#cmig_topic_15_unique_1.

Im Großen und Ganzen verlief die Migration problemfrei, jedoch gab es ein Problem, welches sich in Form eines 500er widerspiegelte, so bald man sich nach der Migration an hue anmeldete oder versuchte die Oozie Workflows aufzulisten.

Das Aktivieren des Debugging brachte ein wenig mehr Licht ins Dunkel

Entgegen der Erwartungen werden multiple Dokumente zurückgeliefert und die entsprechende Stacktrace generiert.

Nach einiges an Recherche stellte sich folgendes Vorgehen als praktikable Lösung heraus

  • Hue stoppen
  • Backup der zugrunde liegenden MySql Datenbank machen
mysql -u USER -H HOST -P PASSWORD --databases hue > hue.sql
  • Nachdem ich auf einem Cloudera Cluster Zugange war findet sich die Hue Konfiguration nicht unter /etc, sondern /var/run/cloudera-scm-agent/process/-hue-HUE_SERVER
    eben jener Pfad muss mittels der Umgebungsvariable HUE_CONF_DIR referenziert werden
export HUE_CONF_DIR=/var/run/cloudera-scm-agent/process/<HUESPID>-hue-HUE_SERVER
  • Synchronisieren / Korrigieren der fehlerhaften Einträge
hue sync_documents

ggf. muss der Pfad zum hue binary komplett angegeben werden.

Das Reaktiveren von SSL kam nicht wirklich in Frage (obwohl das Setup gerade bei Downloads über den Filemanager ein echter Performancekiller war), so das ich mich dafür entschied, SSL auf einem vorgelagerten nginx terminieren zu lassen, der wiederum als Reverseproxy fungiert

#http to https rewriting
server {
    listen      80;
    server_name SERVER.DOMAIN;
    rewrite ^ https://$server_name$request_uri permanent;
}

server {
        #ssl configuration
	listen 443 ssl ;
	server_name SERVER.DOMAIN;
	ssl on;
	ssl_certificate /etc/ssl/hadoop/hadoop.crt;
	ssl_certificate_key /etc/ssl/hadoop/hadoop.key;
	ssl_protocols SSLv3 TLSv1;
	ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv3:+EXP;
	ssl_prefer_server_ciphers on;
    #the error_page directive is used to forward plain 
    #http requests to the right url (just in case 
#someone uses a strange url)
	error_page 497 301 =307 https://<SERVER>.<DOMAIN>$request_uri;

	location / {
              proxy_pass http://hue;
 	         proxy_set_header X-Forwarded-Proto https;
        	  proxy_set_header X-Forwarded-Ssl on;
	 }
}

#upstream is only used as i'm a lazy guy and copied
#the config from another site where several servers #are adressed 
upstream hue {
    ip_hash;
    server <INTERNALIP>:8888 max_fails=3;
}

Die Kombination beider Anpassungen behob das Performanceproblem, so das ein ungestörtes Arbeiten für alle Beteiligten wieder möglich ist.

In diesem Sinne "Happy Hue"