Wednesday, December 3, 2014

The Machine und BigData

HP's Projekt "The Machine" verfolge ich nun schon seit der ersten Veröffentlichung. Bis 2020 soll das Projekt industriereif, ab 2018 sollen erste Edge Devices verfügbar sein. Ob es die Welt der Informatik revolutioniert, bleibt abzuwarten. Extrem interessant ist der Ansatz von HP auf jeden Fall, vor allem im Hinblick auf BigData und die weitere Industrialisierung analytischer Ansätze.

Genutzt wird die Memristor-Technologie (http://en.wikipedia.org/wiki/Memristor). Ein Memristor ist nicht flüchtig, bisher langsamer als DRAM, aber bis zu 100 mal schneller als Flash. Und es kann in relativ kleinen Rackfarmen extrem viel Speicherplatz bereitgestellt werden (4TB haben derzeit den 3.5 Zoll Formfaktor, es könnten aber auch bis zu 100TB per 3.5 Zoll machbar sein).
Das grundlegend neue dabei ist – ein Memristor kann bis zu 10 Zustände speichern (Trinity Memristor). Hierbei wird der Integer auf Basis von 10 berechnet, was im Gegensatz zur herkömmlichen Basis von 8 (64Bit) ein Speicherung auf 20 Bit ermöglicht (bisher 64bit). Folglich hätten die Speicher mit dieser Technologie und bei derzeitiger Fertigungstechnologie die dreifache Kapazität. Ein weiterer interessanter Ansatz ist auch flüchtige Caches in Prozessoren durch nicht flüchtige Speicher zu ersetzen – was wiederum das Computing revolutionieren könnte, etwa durch das Nutzen bereits berechneter Teilmengen in weiteren Verarbeitungsschritten, beispielsweise Mustererkennung in vorhandenen Daten und Übergabe der Muster an einem weiteren Thread zur MCMC Analyse. 

Denkt man an Spark, macht es The Machine durchaus reizvoll – zumal mit Spark vorwiegend nur flüchtige Teilmengen berechnet werden (und bei Bedarf auf ein Speichermedium geschrieben werden, um die berechneten Spills zu persistieren). Und ein solches System wie The Machine würde auch verteilte Dateisysteme wie HDFS oder Ceph größtenteils überflüssig machen, da das Gesamtsystem (also Speicher, RAM, Persistenzlayer, Fast Caching) als ein homogener, nicht flüchtiger Speicherblock funktioniert und jeden bereits berechneten Zustand per se vorrätig halten kann. Diese Teilblöcke könnten dann beliebig wiederverwendet, integriert oder extrapoliert werden, ohne dabei Teile durch volatile caches zu verlieren.

Quellen:


Sunday, November 16, 2014

Hadoop server performance tuning


To tune a Hadoop cluster from a DevOps perspective needs an understanding of the kernel principles and linux. The following article will describe the most important parameters together with tricks for an optimal tuning.

Memory

Typically modern Linux systems (Linux 2.6 +) use swapping to avoid OOM (Out of Memory) to protect the system from kernel freezes. But Hadoop uses Java, and typically Java is configured with MAXHEAPSIZE per service (HDFS, HBase, Zookeeper etc). The configuration has to match the available memory in the system. A common formula for MapReduce1:
TOTAL_MEMORY = (Mappers + Reducers) * CHILD_TASK_HEAP + TT_HEAP + DN_HEAP + RS_HEAP + OTHER_SERVICES_HEAP + 3GB (for OS and caches)

For MapReduce2 YARN takes care about the resources, but only for services which are running as YARN Applications. [1], [2]

Disable swappiness is done one the fly per
echo 0 > /proc/sys/vm/swappiness

and persistent after reboots per sysctl.conf:
echo “vm.swappiness = 0” >> /etc/sysctl.conf

Additionally, RedHat implemented in kernel 2.6.39 THP (transparent huge pages swapping). THP reduces the I/O of an I/O based application at linux systems up 30%. It’s highly recommended to disable THP.
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/redhat_transparent_hugepage/defrag


To do that at boot time automatically, I used /etc/rc.local:
if test -f /sys/kernel/mm/redhat_transparent_hugepage/enabled; then
echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled
fi
if test -f /sys/kernel/mm/redhat_transparent_hugepage/defrag; then
echo never > /sys/kernel/mm/redhat_transparent_hugepage/defrag
fi


Another nice tuning trick is the use of vm.overcommit_memory. This switch enables the overcommitting of virtual memory. Mostly, virtual memory sparse arrays using zero pages - as Java does when the memory for a VM is allocated. In most circumstances these pages contain no data, and the allocated memory can be reused (overcommitted) by other pages. With this switch the OS knows that always enough memory is available to backup the virtual pages.

This feature can be configured at runtime per:
sysctl -w vm.overcommit_memory = 1
sysctl -w vm.overcommit_ratio = 50


and permanently per /etc/sysctl.conf.

Network / Sockets

On highly used and large Linux based clusters the default sockets and network configuration can slow down some operations. This section covers some of the possibilities I figured out over the years. But please be aware of the use, since this affects the network communications.

First of all, enable the whole available port range of max available sockets:
sysctl -w net.ipv4.ip_local_port_range = 1024 65535

Additionally, increasing the recycling time of sockets avoids large TIME_WAIT queues. Re-useing the sockets for new connections can speed up the network communication. It’s to be used with caution and depends highly on the network stack and the running jobs within your cluster. The performance can grow, but also drop dramatically, since we now fast recycle the connections in the WAIT status. Typically used in clusters with a high ingest rate like HBase or Storm, Kafka etc.
sysctl -w net.ipv4.tcp_tw_recycle = 1
sysctl -w net.ipv4.tcp_tw_reuse = 1

For the same purpose, the network buffers backlog can be overfilled. In this case, new connections can be dropped or deleted - which leads to performance issues. Raising the backlog up to 16MB / Socket is mostly enough, together with the number of outstanding syn - requests and backlog sockets.
sysctl -w net.core.rmem_max = 16777216
sysctl -w net.core.wmem_max = 16777216
sysctl -w net.ipv4.tcp_max_syn_backlog = 4096
sysctl -w net.ipv4.tcp_syncookies = 1
sysctl -w net.core.somaxconn = 1024

=> Remember, this is not a generic tuning trick. On generic purpose clusters playing around with the network stack is not safe at all.  

Disk / Filesystem / File descriptors

Linux tracks the file access time, and that means a lot more disk seeks. But HDFS writes once, reads many times, and the Namenode tracks the time. Hadoop doesn't need to track the access time on the OS level, it’s safe to disable this per data disk per mount options.
/dev/sdc /data01 ext3 defaults,noatime 0

Eliminate the root reserved space on partitions. The nature of EXT3/4 reserves 5% of per disk for root. That means the systems will have a lot of unused space. Disable the root reserved space on Hadoop disk
mkfs.ext3 –m 0 /dev/sdc

If the disk is already mounted this can be done forever per 
tune2fs -m 0 /dev/sdc

An optimal server has one HDFS mount point per disk, and one or two dedicated disks for logs and the operating system.

File handler and processes

Typically a Linux system has very conservative file handles configured. Mostly, these handlers are enough for small application servers, but not for Hadoop. When the file handler are to less, Hadoop reports that per java.io.FileNotFoundException: Too many open files - to avoid that raise the limits up.
echo hdfs – nofile 32768 >> /etc/security/limits.conf
echo mapred – nofile 32768 >> /etc/security/limits.conf

Additionally the max. processes, too
echo hbase – nofile 32768 >> /etc/security/limits.conf
echo hdfs – nproc 32768 >> /etc/security/limits.conf
echo mapred – nproc 32768 >> /etc/security/limits.conf
echo hbase – nproc 32768 >> /etc/security/limits.conf


DNS / Name resolution

The communication of Hadoop’s Ecosystem depends highly on a correct DNS resolution. Typically the name resolution is configured per /etc/hosts. Important is, that the canonical name must be the FQDN of the server, see the example.

1.1.1.1 one.one.org one namenode
1.1.1.2 two.one.og two datanode


If DNS is used the system’s hostname must match the FQDN in forward as well as reverse name resolution.To reduce the latency of DNS lookups use the name service caching daemon (nscd), but don’t cache passwd, group, netbios informations.

There are also a lot of specific tuning tricks within the Hadoop Ecosystem, which will be discussed in one of the following articles.

Wednesday, July 16, 2014

Switch to HiveServer2 and Beeline

In Hive 0.11 HiveServer2 [2] was introduced, its time to switch from the old Hive CLI to the modern version. Why?
First, security [1]. Hive CLI bypasses the Apache HiveServer2 and calls a MR job directly. This behavior compromises any security projects like Apache Sentry [3]. With HiveServer2 the Kerberos impersonation brings fine granulated security down to HiveSQL. Its possible to enable a strong security layer with Kerberos, Apache Sentry [3] and Apache HDFS ACL [4], like other DWHs have.
Second, HiveServer2 brings connection concurrency to Hive. This allows multiple connections from different users and clients per JDBC (remote and per Beeline) over Thrift.
Third, the Hive CLI command could be deprecated in the future, this is discussed within the Hive Developer Community.

For the first steps a beeline connection can be established per

beeline -u jdbc:hive2://<SERVER>:<PORT>/<DB> -n USERNAME -p PASSWORD

The URI describes the JDBC connection string, followed by the database the user want to query. The same string can be used for remote JDBC connections, too. Additional, the connection parameters are easy to default in a Kerberos enabled environment per .bashrc like

alias hive2='beeline -u jdbc:hive2://HOST:PORT/DB -n $USER'

(The use of hive should be prohibited (per chmod 700, as example) to avoid bypassing HiveServer2.)

All leading distributions have HiveServer2 included, and the use of Beeline is well documented and pretty easy. Cloudera wrote a great Blogpost [5] about a migration from Hive CLI to Beeline, additional client information are available in the Beeline-Wiki [7]. Beeline and HS2 works in a multi-tenant Tez environment [8].

Snippets

 

Use Beeline in background [6]:
export HADOOP_CLIENT_OPTS="-Djline.terminal=jline.UnsupportedTerminal"
nohup beeline -u jdbc:hive2://<HOST>:<PORT>/DB -n <USER> -p <PASS> -d org.apache.hive.jdbc.HiveDriver -f hql_script &”


Query a table per CLI:
beeline -u jdbc:hive2://<HOST>:<PORT>/DB -n <USER> -p <PASS> -e "select count(*) from (select a.sender, a.recipient, b.recipient as c from transactions a join transactions b on a.recipient = b.sender where a.time < b.time and b.time - a.time < 5) i;"

Tuesday, July 8, 2014

XAttr are coming to HDFS

HDFS 2006 [1] describes the use of Extended Attributes. XAttr, known from *NIX Operating Systems, connects physically stored data with describing metadata above the strictly defined attributes by the filesystem. Mostly used to provide additional information, like hash, checksum, encoding or security relevant information like signature or author / creator.
According to the source code [2] the use of xattr can be configured by dfs.namenode.fs-limits.max-xattrs-per-inode and dfs.namenode.fs-limits.max-xattr-size in hdfs-default.xml. The default for dfs.namenode.fs-limits.max-xattrs-per-inode is 32, for dfs.namenode.fs-limits.max-xattr-size the default is 16384.

Within HDFS, the extended user attributes will be stored in the user namespace as an identifier.The identifier has four namespaces, like the Linux FS kernel implementation has: security, system, trusted and user. Only the superuser can access the trusted namespaces (system and security).
The xattr definitions are free and can be interpreted by additional tools like security frameworks, backup systems, per API or similar. Additionally, the attributes are case-sensitive and the namespace interpretes the definition as it is (case-insensitive).

An attribute can be set per dfs command like this:

hadoop dfs -setfattr -n 'alo.enc_default' -v UTF8 /user/alo/definition_table.txt

and can be read per:

hadoop dfs -getfattr -d /user/alo/definition_table.txt

# file: /user/alo/definition_table.txt
user.enc_default='UTF8'


HDFS 2006 is already committed [3] and will be available in HDFS 2.5.x, is enabled per default and will have no impact on performance if you don't use them.

[1] https://issues.apache.org/jira/browse/HDFS-2006

Friday, July 4, 2014

Cloudera + Intel + Dell = ?

Wie Cloudera in einer Pressemitteilung [1] veröffentlichte, kommt nach dem Intel-Investment [2] nun der Schulterschluss mit Dell. Hier meine Meinung dazu.

Seit Jahren versprechen Analysten Wachstumsraten im hohen zweistelligen Prozentbereich bis 2020 [3], schlussendlich ist es nur logisch das Intel über den augenblicklichen Platzhirsch Cloudera in das "BigData Business" investiert, nachdem augenscheinlich die eigene Distribution nicht so erfolgreich war als gehofft. Zudem erkauft sich Intel hier einen bedeutenden Einfluss auf das Hadoop Projekt. Neben Hortonworks ist Cloudera einer der bedeutendsten Committer des gesamten Ecosystems.
Der Einfluss Intels beginnt bei Kryptographie (Rhino) [4], weitere Möglichkeiten wären optimierter Bytecode für Intel CPU's in Impala / Spark, Advanced Networking Features im Hadoop Core (IPv6) oder die Unterstützung proprietärer Lösungen Intels, die nur in CDH verfügbar sein werden. Da Cloudera in nahezu allen relevanten Projekten des Apache Hadoop Ecosystems vertreten ist kann diese Votingmacht durchaus genutzt werden um Apache Hadoop in eine Richtung zu beeinflussen, welche von beiden Unternehmen gewünscht ist.

Langsamer Abschied von Open Source?
Bei den beiden Distributionen CDH (Cloudera) und HDP (Hortonworks) ist eine zunehmende Fragmentierung zu sehen. Sehr deutlich bei den neuesten Erwerbungen - Cloudera kauft Gazzang, Hortonworks XA Secure. Damit sind alle Distributionen ab Einsatz der jeweiligen per Distribution proprietären Verschlüsselung nicht mehr kompatibel. Deutlich wird hier sicher die Diskrepanz wenn Intels Cryptocards zum Einsatz kommen und Gazzang dahingehend optimiert wird [5].
Auch im Hadoop Core wird die Strategie sichtbar - Cloudera setzt auf das Parquet Fileformat, Hortonworks auf ORCFile. Doch die Unterschiede gehen weiter: Hortonworks setzt auf OpenSource Tools wie Ambari, Storm, Shark und Falcon, Cloudera dagegen im Umsatzträchtigen Enterpriseumfeld auf Closed Open Code (Sourcecode öffentlich, aber keine Community basierte Entwicklung) wie Impala und Closed Source bei Management (Cloudera Manager und Enterprise AddOns), Verschlüsselung (Gazzang) und Data Lineage (Navigator).
Da sowohl Hortonworks als auch Cloudera (100% of the top 5 US intelligence agencies run Cloudera) den Public und Intelligence Sector in den USA / UK bedienen darf gefragt werden ob Closed Source im umsatzstarken deutschen Umfeld (NSA Untersuchungsausschuss) eine clevere Strategie ist. Zumindest bei HDP besteht die Möglichkeit eines kompletten Audits.

Kooperation mit DELL
Dell schwächelte, bedingt durch den Einbruch im PC Markt und die bisherige Konzentration auf Bürohardware, bereits seit 2012. Michael Dell gelang es 2013 Dell wieder in eine private Gesellschaft zu überführen - gemeinsam mit den Finanzinvestor Silver Lake. Die Dell Aktie verschwand von der Börse, und der Weg war frei das Unternehmen drastisch umzubauen und auf Vertrieb zu trimmen.
Dell's Vertriebsmodell ist Stückzahlen getrieben, es zählt nur das verkaufte Blech. Da Dell keinerlei nennenswerten Umsatz mit Dienstleistungen macht und diese an Partner outsourced, ist Dell natürlich der ideale Partner für Intel und Cloudera. Es findet keine Kannibalisierung des bisherigen Geschäfts statt, im Gegenteil. Da das Geschäftsmodell aller Hadoop Distributoren auf wiederkehrenden Subscriptions beruht, ist dieser Deal nahezu unschlagbar. Dell bekommt ein Alleinstellungsmerkmal, verkauft mehr Server - Intel verdient an CPU, Memory, SSDs, Netzwerk, und Cloudera an Subscriptions [1]:
"Driven by collaboration with the open source community and efforts across Dell, Intel and Cloudera, the Dell appliance is a best of breed big data solution stack. Designed from the silicon up, this appliance can enable certain applications to run up to 100x faster, is easy to use and deploy, and is compatible with existing solutions. [...] The Dell In-Memory Appliances for Cloudera Enterprise will be available in pre-sized, pre-configured options so that enterprise customers can choose and quickly deploy the version that is right for their applications. Value-added consulting services for custom configurations are also available through Dell."
Mit anderen (saloppen) Worten - wenn der Kunde einen modernden Hadoop CDH Analytics Cluster betreiben will, ist die einzige sinnvolle und zukunftsträchtige Lösung eine Lösung von Dell / Intel / Cloudera. Denn dieses Angebot ist das beste was auf dem Markt ist und weiter sein wird. Dafür wird Intel / Cloudera / Dell sorgen. Und wenn der Kunde nun eine Hardware Lösung von $commodity_hardware_vendor will, kann er das gern machen. Nur hat er dann eben nicht die Performance, die möglich wäre - wenn man denn auf CDH setzt:
"Together, the partners said they are attempting to build a “big data ecosystem” that combines data analytics hardware and software to move advanced data analytics to mainstream applications." [6]
Was könnte diese Strategie für die Zukunft bringen?
Die Aussage, einige Anwendungen werden mit dieser Lösung bis zu 100x schneller (Anmerkung: Bis zu 100x schneller scheint ein beliebter Term im amerikanischen Marketing zu sein) werden, legt nahe das mit sehr hoher Wahrscheinlichkeit Server und Software aufeinander abgestimmt zum Einsatz kommen. Damit wird die Flexibilität in der Wahl des Herstellers seitens des Kunden erheblich eingeschränkt. Und das sieht etwas nach einem Vendor Lock durch die Hintertür aus, was aus Sicht aller (außer des Kunden) der beste Weg ist die bestehende Abhängigkeit von wiederkehrenden Subscriptions und Services zu negieren. Cloudera's CEO, Tom Reilly, zeigt deutlich in einem Interview wohin die Reise gehen soll [7]:
Intel is working on a chip that’s going to ship in five years from now. They’re sharing those designs with us and we’re collaborating with them on how we can write and take advantage of instructions in the chip to actually make them perform better for analytic workloads. So if a customer is going to build a scale-out grid, and they were planning to have a thousand nodes driving it, the work with Intel might say they can do it with 600, which is significant cost savings in the long run. That’s huge. That’s a five-year roadmap.
Ob das wirklich der Weg zum "Big Data King" ist wird die Zukunft zeigen.

[1] http://www.cloudera.com/content/cloudera/en/about/press-center/press-releases/2014/06/24/cloudera-dell-and-intel-advance-enterprise-deployments-of-hadoop.html
[2] http://www.cloudera.com/content/cloudera/en/about/press-center/press-releases/2014/06/02/cloudera-names-intel-cio-to-board-of-directors-and-announces-the.html
[3] http://www.datanami.com/2014/05/29/hadoop-market-grow-58-2020-report-says/
[4] http://blog.cloudera.com/blog/2014/06/project-rhino-goal-at-rest-encryption/
[5] http://www.cloudera.com/content/cloudera/en/about/press-center/press-releases/2014/06/03/cloudera-strengthens-hadoop-security-with-acquisition-of-gazzang.html
[6] http://www.datanami.com/2014/06/24/cloudera-dell-intel-target-big-data-ecosystem/
[7] http://www.information-age.com/it-management/strategy-and-innovation/123458167/one-year-ceo-clouderas-tom-reilly-just-cant-wait-be-big-data-king

Thursday, June 12, 2014

Remove HDP and Ambari completely

Its a bit hard to remove HDP and Ambari completely - so I share my removal script here. Works for me perfect, just adjust the HDFS directory. In my case it was /hadoop
#!/bin/bash
echo "==> Stop Ambari and Hue"
ambari-server stop && ambari-agent stop
/etc/init.d/hue stop
sleep 10
echo "==> Erase HDP and Ambari completely"
yum -y erase ambari-agent ambari-server ambari-log4j hadoop libconfuse nagios ganglia sqoop hcatalog\* hive\* hbase\* zookeeper\* oozie\* pig\* snappy\* hadoop-lzo\* knox\* hadoop\* storm\* hue\*
# remove configs
rm -rf /var/lib/ambari-*/keys /etc/hadoop/ /etc/hive /etc/hbase/ /etc/oozie/ /etc/zookeeper/ /etc/falcon/ /etc/ambari-* /etc/hue/
# remove ambaris default hdfs dir
rm -rf /hadoop
# remove the repos
echo "==> Remove HDP and Ambari Repo"
rm -rf /etc/yum.repos.d/HDP.repo /etc/yum.repos.d/ambari.repo
# delete all HDP related users
echo "==> Delete the user accounts"
userdel -f hdfs && userdel -f sqoop && userdel -f hue && userdel -f yarn && userdel -f hbase && userdel -f && hive userdel -f oozie && userdel -f hcat && userdel -f puppet && userdel -f storm && userdel -f ambari-qa && userdel -f ambari_qa && userdel -f tez && userdel -f flume && userdel -f hadoop_deploy && userdel -f hcatalog && userdel -f zookeeper && userdel -f falcon && userdel -f rrdcached
# remove the unwanted sockets
echo "==> remove the HDFS socket and logs"
rm -rf /var/run/hdfs-sockets
rm -rf /var/log/sqoop2 /var/log/hdfs* /var/log/hadoop-* /var/log/hbase* /var/log/hue* /var/log/nagios /var/log/oozie /var/log/storm /var/log/zookeeper /var/log/falcon /var/log/flume* /var/run/flume-ng/ /var/run/hadoop* /var/run/hbase/ /var/run/hue/ /var/run/nagios/ /var/run/oozie/ /var/run/solr/ /var/run/spark/ /var/run/sqoop2/ /var/run/storm/ /var/run/zookeeper/ 
/var/lib/oozie/
For CDH just follow the guidance here:
http://www.cloudera.com/content/cloudera-content/cloudera-docs/CM5/latest/Cloudera-Manager-Installation-Guide/cm5ig_uninstall_cm.html

And MapR here:


Tuesday, May 20, 2014

Facebook's Presto

In November 2013 Facebook published their Presto engine as Open Source, available at GitHub. Presto is a distributed interactive SQL query engine, able to run over dozens of modern BigData stores, based on Apache Hive or Cassandra. Presto comes with a limited JDBC Connector, supports Hive 0.13 with Parquet and Views.

Installation

Just a few specialties. Presto runs only with Java7, does not support Kerberos and does not have built-in user authentication, neither. To protect data a user should not be able to read, the use of HDFS Acl's / POSIX permissions should be considered. The setup of Presto is pretty easy and well documented. Just follow the documentation, use "uuidgen" to generate a unique ID for your Presto Node (node.id in node.properties) and add "hive" as datasource (config.properties: datasources=jmx,hive). I used user "hive" to start the server with:
export PATH=/usr/jdk64/jdk1.7.0_45/bin:$PATH && presto-server-0.68/bin/launcher start

After the successful start you should be able to connect to Presto's Webinterface (discovery.uri in config.properties). The UI is pretty simple, but a good point to see what happens with your queries, how many splits are created and what time each step takes.

The CLI is a stand-alone self-executing jar file and can be placed on any computer which has installed Java7 and can connect to the Presto Instance. To be sure that the client is using the correct Java version a PATH inclusion may make sense:
export PATH=/usr/jdk64/jdk1.7.0_45/bin:$PATH && /software/presto --server [your-presto-server]:[port] --catalog hive --schema default

presto:default> show tables;
    Table
--------------
 building
 hvac
 sample_07
 sample_08
 transactions

Now let's test if Presto is really fast and can compare with Impala. To make the tests more simple I wrote a small script which uses MR to generate sample data. Its available in my git-repo. Just run it as the user you want to be, maybe make it executable or use "sh". With the script I mentioned before I created a table called transactions, and this table we want to query. I post only 2 exemplary queries, but the script has a few more.

1. Finding highest gainers

select id, sum(amount) as amount from (select sender as id, amount * -1 as amount from transactions union all select recipient as id, amount from transactions) unionResult group by id order by amount desc limit 10;

Results
Hive: 39.078 seconds, Fetched: 10 row(s)
Tez: 18.227 seconds, Fetched: 10 row(s)
Presto: 0:02 [1.2M rows, 38.2MB] [720K rows/s, 22.9MB/s]


2. Finding fraudsters

select count(*) from (select a.sender, a.recipient, b.recipient as c from transactions a join transactions b on a.recipient = b.sender where a.time < b.time and b.time - a.time < 5) i;

Results
Hive: 208.065 seconds, Fetched: 1 row(s)
Tez: 101.758 seconds, Fetched: 1 row(s)
Presto: 1:02 [600K rows, 19.1MB] [9.7K rows/s, 317KB/s]

Conclusion

Since Tez brings a significant better performance, Presto brings light speed into Hadoop based SQL and can be measured with Impala. The advantage of Presto is the flexibility of connectors - the Presto Team will add more connectors for Oracle, MySQL, PostgresSQL and HBase very soon. Also Authentication (Kerberos), Authorization and SQL Grants will be supported within the next month [1].

Wednesday, May 14, 2014

Cloudera Manager fails to upgrade Sqoop2 when parcels are enabled

Cloudera Manager fails to update the generic Sqoop2 connectors when parcels are enabled, and the Sqoop2 server won't start anymore. In the logs a error like:

Caused by: org.apache.sqoop.common.SqoopException: JDBCREPO_0026:Upgrade required but not allowed - Connector: generic-jdbc-connector

is shown.
This issue can be fixed by adding two properties into the service safety valve of sqoop:

org.apache.sqoop.connector.autoupgrade=true
org.apache.sqoop.framework.autoupgrade=true


This happen trough the missing autoupdate of the default sqoop connectors in Cloudera Manager. After the properties are added, SqoopServer should be able to update the drivers and will start sucessfully.

Monday, May 12, 2014

Test: HDP 2.1 und Ambari 1.5.1

Im Rahmen einiger Analysen stelle ich hier die verschiedenen Distributionen in einem recht einfachen Verfahren gegenüber. Es kommt mir hierbei vor allem auf die Einfachheit und Schnelligkeit der Installation eines Clusters an, auf technischen Differenzen und Besonderheiten gehe ich jeweils kurz ein.

Vorbereitungen
Als Basis dient ein frisches CentOS 6.5 in einem Oracle VirtualBox VM Container, 6GB Memory, 4 CPU und 100 GB HDD. Als Gastsystem kommt Windows zum Einsatz - einfach weil Windows üblicherweise auf Bürorechnern installiert ist.
Da Ambari erst vor 2 Wochen die Version 1.5.1 veröffentlicht hat, starte ich mit hiermit. Das Einspielen der entprechenden Pakete ist hinlänglich und ausführlich in der Dokumentation beschrieben. Nachdem der Ambari Server gestartet wurde ist ein problemloses Einloggen auf der Webkonsole per http://FQHN:8080 möglich.
Wichtig ist hierbei, das die zu installierenden Server per DNS lookup erreichbar sind. Im Falle der VM stellte dies ein geringfügiges Problem dar, da das Gastsystem erst den Namen per C:\Windows\System32\drivers\etc\hosts auflösen musste. Hierzu ist der Windows-eigene Editor mit Administratorrechten zu starten und die folgenden Änderungen einzutragen:
<IP-Adresse der VM>    hdp    hdp.alo

Installation
Nachdem dies erledigt ist, kann mit der Installation des Clusters begonnen werden. Hierbei fällt auf, das Ambari (und demzufolge HDP) nur FQHN (Full qualified host names) akzeptiert. Im Folgenden war die SSH Installation nicht funktionsfähig, der private key wurde schlicht nicht übertragen (keyfile=/var/run/ambari-server/bootstrap/5/sshKey passwordFile null), was zu einem unschönen Abbruch führte - ohne entsprechende Fehlermeldungen. Dies kann durch die manuelle Installation des ambari-client (siehe Dokumentation) workarounded werden. Ab nun lief die Installation recht einfach und ohne Komplikationen. Bevor Hive und Oozie installiert werden können muss eine entsprechende Datenbank (in diesem Fall MySQL) installiert und initialisiert werden (anlegen der Datenbanken und Berechtigungen der User). Hier wäre ein intuitives Interface wünschenswert. Nach etwa 25 Minuten war HDP installiert und Ambari meldete die Einsatzbereitschaft.


Das aufgeräumte Interface macht einen guten Eindruck, ebenso die erweiterte Verwaltung wie Jobmanagement, Heatmaps, Services und Admin waren sehr aufgeräumt. Persönlich gut gelöst fand ich die Integration von Ganglia und Nagios, hier ist die Anbindung des Clusters an eine bestehende Infrastruktur recht einfach.


Allerdings waren beim Tab "Hosts" keinerlei Metriken zu sehen, was auf fehlerhafte Nagios Implementation hindeutet. Auch bei HDFS und YARN zeigten die eingeblendeten Metriken gar keine Daten, was gerade bei einem frisch installierten Cluster eher Unsicherheiten erzeugt.




Leider wird Hue nicht per default installiert, sondern muss manuell nachinstalliert werden. Das ist unschön, aber auch einfach per yum install hue erledigt. Allerdings muss in  /etc/hue/conf/hue.ini die entsprechenden Einträge von localhost mit dem FQHN angepasst und in der HDFS Konfiguration die "Custom core-site.xml" editiert und die Properties hadoop.proxyuser.hue.group und hadoop.proxyuser.hue.hosts hinzugefügt und mit "*" belegt werden. Dasselbe muss mit der WebHcat Konfiguration per "Custom webhcat-site.xml" mit den Properties hadoop.proxyuser.webhcat.group und hadoop.proxyuser.webhcat.hosts
ebenfalls geschehen. Nach einem Speichern und anschließenden Restarten der Services HDFS, YARN, WebHCat und MapReduce2 und dem Restart des Hue-Servers ist dieser wie gewohnt einsatzbereit.
Allerdings bleibt der Job Reiter bei Jobs, die aus Hue abgesetzt wurden, leer.  Die reibungslose Integration ist hier leider nicht vorhanden.


Test Tez vs. MR

Um die unterschiedlichen Frameworks mittels Hue zu nutzen muss die entsprechende Engine unter Settings definiert werden. Neugierig bin ich vor allem auf die Finalen Ergebisse der Stinger Initiative und deren vektorbasierte Beschleunigung vor allem im Vergleich mit InMemory Tools wie Spark oder Impala. Hierzu benutze ich Tutorialdaten von Hortonworks, bereitgestellt bei Amazon S3. Der Wechsel zwischen MR und Tez klappt ohne Probleme, der versprochene Geschwindigkeitszuwachs ist ebenfalls merkbar.Um die Differenz genau zu messen, führe ich dieselben Abfragen per Hive CLI aus:

set hive.execution.engine=mr;

select a.buildingid, b.buildingmgr, max(a.targettemp-a.actualtemp)
from hvac a join building b
on a.buildingid = b.buildingid
group by a.buildingid, b.buildingmgr;


[...]
Time taken: 45.22 seconds, Fetched: 20 row(s)

Dasselbe mit Tez:
set hive.execution.engine=tez;

select a.buildingid, b.buildingmgr, max(a.targettemp-a.actualtemp)
from hvac a join building b
on a.buildingid = b.buildingid
group by a.buildingid, b.buildingmgr;


[...]
Time taken: 19.59 seconds, Fetched: 20 row(s)

Alles in allem eine Geschwindigkeitssteigerung von etwa 2,4 - was beeindruckend ist. Allerdings sehe ich von den oft proklamierten "100 times faster" hier nichts, was an dem Datenset liegen kann.

Zusammenfassung
Ambari ist Open Source, kann aber derzeit nur Hortonworks' Version von Apache Hadoop installieren und verwalten, was Ambari zu einem Verwaltungstool für HDP "only" macht. Dessen muss man sich klar sein. Alles in allem überzeugen die fehlenden Metriken und die fehlende Integration von Hue nicht - dagegen der Einsatz von Stinger vollstens. Hier merkt man den Geschwindigkeitsvorteil deutlich. Falcon scheint noch etwas wackelig zu sein, so werden Tez Jobs teilweise mit Laufzeiten von 35 Minuten angezeigt. Oder sie fehlen ganz - und es ist nicht ersichtlich ob diese von der CLI oder per HCat (Hue) abgesetzt wurden.
Grundsätzlich lässt sich ein HDP basierender Cluster recht einfach verwalten, nur das Verschieben von Services ist nicht möglich - was einen Cluster etwas unflexibel macht. Nicht getestet wurde LDAP und Kerberos Integration, Rolling Restarts und Namenode HA.

Edit 23.05.2014

Das Problem der fehlenden Graphs liegt am nicht automatisch gestarteten Apache Webserver - Nagios braucht diesen. Nach dem Start und einschalten des Systemstarts (chkconfig httpd on) waren alle Graphen verfügbar.

Tuesday, May 6, 2014

The Forrester Wave (Or: We're all the leaders)

Forrester Research, an independent market research firm, released in February 2014 the quarterly Forrester Wave Big Data Hadoop Solutions, Q1 2014 Report [1]. The report shows this graphic, and it looks like that all major, minor and non-hadoop Vendors think they lead. It looks really funny when you follow the mainstream press news.

IBM [5] think they lead, Hortonworks [4] claim the leadership too, MapR [3] leads too, Teradata is the true leader (they say) [6]. Cloudera [2] ignores the report. The metapher is - all of the named companies are in the leader area, but nobody leads.

Forrester Wave Big Data Hadoop Solutions, Q1 2014 Report
Anyway, let us do a quick overview about the "Big Three" - Cloudera, MapR, Hortonworks.

The 3 major Hadoop firms (Horton, MapR, Cloudera) are nearly in the same position. All distributions have the sweet piece, which lets the customer decide which one fits most. And that is the most important point - the customer wins. Not the marketing noise.

Cloudera [2] depends on Apache Hadoop, has Cloudera Manager, a strong, sophisticated and great tool to manage an entire hadoop cluster, including add, relocate and remove services from a node to another. In addition to the Open Source version of Hadoop they offer Closed Source Applications on top, like Cloudera Manager Enterprise, Cloudera Navigator (Data Lineage), BDR, Snapshotting, Data Replication. But these additional services aren't OpenSource.

MapR [3] is the most convenient guy here - the press release on their website is clear, no big noise. The message: Choose what is the best for your business. Makes the company a bit friendly. MapR has 3 different solutions - M3, the free-to-use edition, M5 - the Enterprise Edition with NFS Support, Snapshotting, independent code support and M7, the Enterprise Database Edition, optimized for Low Latency and High Throughput. MapR Editions aren't Open Source, and the management console is not as feature-rich as Cloudera Manager. Additionally, the company created their own HDFS-like file system (MapR-FS), mostly written in C(++).

Hortonworks [4] is the youngest player in the market. Originally Horton comes from Yahoo and is a spin-off from the core developers on Apache Hadoop MapReduce, Apache Hadoop HDFS and Apache Hadoop Yarn. HDP, the Hortonworks Edition of Apache Hadoop, is the only 100% Open Source distribution in the market. The managing tool, Apache Ambari (incubating) is also not so feature-rich as Cloudera Manager, but it's Open Source and works well. Furthermore, Horton sells only Apache Projects in their distribution, for Data Governance Falcon, and for Security Purposes Knox.

All of  these three players have a strong support department as well as service delivery (Solution Architect), Pre- and Post Sales and a significant amount of customers.

In my eyes, I see only one true leader. Apache Hadoop. All of those "BigData" companies rely on a great idea, originally developed at Google and rebuilt by the Apache Open Source Community. This is what true leadership means - evolve and divide.

[1] http://www.forrester.com/pimages/rws/reprints/document/112461/oid/1-PBE69P
[2] http://www.cloudera.com
[3] http://www.mapr.com/forrester-wave-hadoop-distribution-comparison-and-benchmark-report
[4] http://info.hortonworks.com/ForresterWave_Hadoop.html
[5] http://www.ibmbigdatahub.com/whitepaper/forrester-wave-big-data-hadoop-solutions-q1-2014
[6] http://www.teradata.de/News-Releases/2014/Teradata-is-a-Leader-in-Big-Data-Hadoop-Solutions-in-2014/?LangType=1031