Transcript The Future of Information Technology and The Indiana University

Implementing parts of HPC-ABDS in a multidisciplinary collaboration
HPC 2016 HIGH PERFORMANCE COMPUTING
FROM CLOUDS AND BIG DATA TO EXASCALE AND BEYOND
June 27- July 1 2016 Cetraro
http://www.hpcc.unical.it/hpc2016/
Geoffrey Fox
June 30, 2016
[email protected]
http://www.dsc.soic.indiana.edu/,
http://spidal.org/
http://hpc-abds.org/kaleidoscope/
Department of Intelligent Systems Engineering
School of Informatics and Computing, Digital Science Center
Indiana University Bloomington
1
Abstract
• We introduce the High Performance Computing enhanced
Apache Big Data software Stack HPC-ABDS and give several
examples of advantageously linking HPC and ABDS.
• In particular we discuss a Scalable Parallel Interoperable Data
Analytics Library SPIDAL that is being developed to embody
these ideas and is the HPC-ABDS instantiation of well known
Apache libraries Mahout and MLlib.
• SPIDAL covers some core machine learning, image
processing, graph, simulation data analysis and network
science kernels. It is a collaboration between teams at
Arizona, Emory, Indiana (lead), Kansas, Rutgers, Virginia
Tech, and Utah universities.
• We give examples of data analytics running on HPC systems
including details on persuading Java to run fast.
5/17/2016
2
SPIDAL Project
Datanet: CIF21 DIBBs: Middleware and
High Performance Analytics Libraries for
Scalable Data Science
•
•
•
•
•
•
•
•
•
NSF14-43054 started October 1, 2014
Indiana University (Fox, Qiu, Crandall, von Laszewski)
Rutgers (Jha)
Virginia Tech (Marathe)
Kansas (Paden)
Stony Brook (Wang)
Arizona State (Beckstein)
Utah (Cheatham)
A co-design project: Software, algorithms, applications
02/16/2016
3
Co-designing Building Blocks
Collaboratively
Software: MIDAS
HPC-ABDS
5/17/2016
4
Main Components of SPIDAL Project
•
Design and Build Scalable High Performance Data Analytics Library
•
SPIDAL (Scalable Parallel Interoperable Data Analytics Library): Scalable
Analytics for:
– Domain specific data analytics libraries – mainly from project.
– Add Core Machine learning libraries – mainly from community.
– Performance of Java and MIDAS Inter- and Intra-node.
•
NIST Big Data Application Analysis – features of data intensive Applications.
•
HPC-ABDS: Cloud-HPC interoperable software performance of HPC (High
Performance Computing) and the rich functionality of the commodity Apache Big
Data Stack.
•
MIDAS: Integrating Middleware – from project.
•
Applications: Biomolecular Simulations, Network and Computational Social
Science, Epidemiology, Computer Vision, Geographical Information Systems,
Remote Sensing for Polar Science and Pathology Informatics, Streaming for
robotics, streaming stock analytics
•
Implementations: HPC as well as clouds (OpenStack, Docker)
5/17/2016
5
HPC-ABDS
Kaleidoscope of (Apache) Big Data Stack (ABDS) and HPC Technologies
CrossCutting
Functions
1) Message
and Data
Protocols:
Avro, Thrift,
Protobuf
2) Distributed
Coordination
: Google
Chubby,
Zookeeper,
Giraffe,
JGroups
3) Security &
Privacy:
InCommon,
Eduroam
OpenStack
Keystone,
LDAP, Sentry,
Sqrrl, OpenID,
SAML OAuth
4)
Monitoring:
Ambari,
Ganglia,
Nagios, Inca
21 layers
Over 350
Software
Packages
January
29
2016
17) Workflow-Orchestration: ODE, ActiveBPEL, Airavata, Pegasus, Kepler, Swift, Taverna, Triana, Trident, BioKepler, Galaxy, IPython, Dryad,
Naiad, Oozie, Tez, Google FlumeJava, Crunch, Cascading, Scalding, e-Science Central, Azure Data Factory, Google Cloud Dataflow, NiFi (NSA),
Jitterbit, Talend, Pentaho, Apatar, Docker Compose, KeystoneML
16) Application and Analytics: Mahout , MLlib , MLbase, DataFu, R, pbdR, Bioconductor, ImageJ, OpenCV, Scalapack, PetSc, PLASMA MAGMA,
Azure Machine Learning, Google Prediction API & Translation API, mlpy, scikit-learn, PyBrain, CompLearn, DAAL(Intel), Caffe, Torch, Theano, DL4j,
H2O, IBM Watson, Oracle PGX, GraphLab, GraphX, IBM System G, GraphBuilder(Intel), TinkerPop, Parasol, Dream:Lab, Google Fusion Tables,
CINET, NWB, Elasticsearch, Kibana, Logstash, Graylog, Splunk, Tableau, D3.js, three.js, Potree, DC.js, TensorFlow, CNTK
15B) Application Hosting Frameworks: Google App Engine, AppScale, Red Hat OpenShift, Heroku, Aerobatic, AWS Elastic Beanstalk, Azure, Cloud
Foundry, Pivotal, IBM BlueMix, Ninefold, Jelastic, Stackato, appfog, CloudBees, Engine Yard, CloudControl, dotCloud, Dokku, OSGi, HUBzero, OODT,
Agave, Atmosphere
15A) High level Programming: Kite, Hive, HCatalog, Tajo, Shark, Phoenix, Impala, MRQL, SAP HANA, HadoopDB, PolyBase, Pivotal HD/Hawq,
Presto, Google Dremel, Google BigQuery, Amazon Redshift, Drill, Kyoto Cabinet, Pig, Sawzall, Google Cloud DataFlow, Summingbird
14B) Streams: Storm, S4, Samza, Granules, Neptune, Google MillWheel, Amazon Kinesis, LinkedIn, Twitter Heron, Databus, Facebook
Puma/Ptail/Scribe/ODS, Azure Stream Analytics, Floe, Spark Streaming, Flink Streaming, DataTurbine
14A) Basic Programming model and runtime, SPMD, MapReduce: Hadoop, Spark, Twister, MR-MPI, Stratosphere (Apache Flink), Reef, Disco,
Hama, Giraph, Pregel, Pegasus, Ligra, GraphChi, Galois, Medusa-GPU, MapGraph, Totem
13) Inter process communication Collectives, point-to-point, publish-subscribe: MPI, HPX-5, Argo BEAST HPX-5 BEAST PULSAR, Harp, Netty,
ZeroMQ, ActiveMQ, RabbitMQ, NaradaBrokering, QPid, Kafka, Kestrel, JMS, AMQP, Stomp, MQTT, Marionette Collective, Public Cloud: Amazon
SNS, Lambda, Google Pub Sub, Azure Queues, Event Hubs
12) In-memory databases/caches: Gora (general object from NoSQL), Memcached, Redis, LMDB (key value), Hazelcast, Ehcache, Infinispan, VoltDB,
H-Store
12) Object-relational mapping: Hibernate, OpenJPA, EclipseLink, DataNucleus, ODBC/JDBC
12) Extraction Tools: UIMA, Tika
11C) SQL(NewSQL): Oracle, DB2, SQL Server, SQLite, MySQL, PostgreSQL, CUBRID, Galera Cluster, SciDB, Rasdaman, Apache Derby, Pivotal
Greenplum, Google Cloud SQL, Azure SQL, Amazon RDS, Google F1, IBM dashDB, N1QL, BlinkDB, Spark SQL
11B) NoSQL: Lucene, Solr, Solandra, Voldemort, Riak, ZHT, Berkeley DB, Kyoto/Tokyo Cabinet, Tycoon, Tyrant, MongoDB, Espresso, CouchDB,
Couchbase, IBM Cloudant, Pivotal Gemfire, HBase, Google Bigtable, LevelDB, Megastore and Spanner, Accumulo, Cassandra, RYA, Sqrrl, Neo4J,
graphdb, Yarcdata, AllegroGraph, Blazegraph, Facebook Tao, Titan:db, Jena, Sesame
Public Cloud: Azure Table, Amazon Dynamo, Google DataStore
11A) File management: iRODS, NetCDF, CDF, HDF, OPeNDAP, FITS, RCFile, ORC, Parquet
10) Data Transport: BitTorrent, HTTP, FTP, SSH, Globus Online (GridFTP), Flume, Sqoop, Pivotal GPLOAD/GPFDIST
9) Cluster Resource Management: Mesos, Yarn, Helix, Llama, Google Omega, Facebook Corona, Celery, HTCondor, SGE, OpenPBS, Moab, Slurm,
Torque, Globus Tools, Pilot Jobs
8) File systems: HDFS, Swift, Haystack, f4, Cinder, Ceph, FUSE, Gluster, Lustre, GPFS, GFFS
Public Cloud: Amazon S3, Azure Blob, Google Cloud Storage
7) Interoperability: Libvirt, Libcloud, JClouds, TOSCA, OCCI, CDMI, Whirr, Saga, Genesis
6) DevOps: Docker (Machine, Swarm), Puppet, Chef, Ansible, SaltStack, Boto, Cobbler, Xcat, Razor, CloudMesh, Juju, Foreman, OpenStack Heat,
Sahara, Rocks, Cisco Intelligent Automation for Cloud, Ubuntu MaaS, Facebook Tupperware, AWS OpsWorks, OpenStack Ironic, Google Kubernetes,
Buildstep, Gitreceive, OpenTOSCA, Winery, CloudML, Blueprints, Terraform, DevOpSlang, Any2Api
5/17/2016
5) IaaS Management from HPC to hypervisors: Xen, KVM, QEMU, Hyper-V, VirtualBox,
OpenVZ, LXC, Linux-Vserver, OpenStack, OpenNebula,
Eucalyptus, Nimbus, CloudStack, CoreOS, rkt, VMware ESXi, vSphere and vCloud, Amazon, Azure, Google and other public Clouds
Networking: Google Cloud DNS, Amazon Route 53
6
5/17/2016
7
HPC-ABDS Mapping of Activities
Green is MIDAS
Black is SPIDAL
• Level 17: Orchestration: Apache Beam (Google Cloud Dataflow) integrated
with Heron/Flink and Cloudmesh on HPC cluster
• Level 16: Applications: Datamining for molecular dynamics, Image
processing for remote sensing and pathology, graphs, streaming,
bioinformatics, social media, financial informatics, text mining
• Level 16: Algorithms: Generic and custom for applications SPIDAL
• Level 14: Programming: Storm, Heron (Twitter replaces Storm), Hadoop,
Spark, Flink. Improve Inter- and Intra-node performance; science data
structures
• Level 13: Runtime Communication: Enhanced Storm and Hadoop (Spark,
Flink, Giraph) using HPC runtime technologies, Harp
• Level 11: Data management: Hbase and MongoDB integrated via use of
Beam and other Apache tools; enhance Hbase
• Level 9: Cluster Management: Integrate Pilot Jobs with Yarn, Mesos,
Spark, Hadoop; integrate Storm and Heron with Slurm
• Level 6: DevOps: Python Cloudmesh virtual Cluster Interoperability
5/17/2016
8
Java Grande
Revisited on 3 data analytics codes
Clustering
Multidimensional Scaling
Latent Dirichlet Allocation
all sophisticated algorithms
02/16/2016
9
Some large scale
analytics
100,000 fungi
Sequences
Eventually
120 clusters
3D phylogenetic
LCMS Mass Spectrometer Peak Clustering. tree
Sample of 25 million points. 700 clusters
Jan 1 2004  December 2015
02/16/2016
10
Daily Stock Time Series in 3D
MPI, Fork-Join and Long Running Threads
• Quite large number of cores per node in simple main stream clusters
– E.g. 1 Node in Juliet 128 node HPC cluster
• 2 Sockets, 12 or 18 Cores each, 2 Hardware threads per core
• L1 and L2 per core, L3 shared per socket
• Denote Configurations TxPxN for N nodes each with P processes and T
threads per process
• Many choices in T and P
• Choices in Binding of
processes and threads
• Choices in MPI where
best seems to be SM
“shared memory” with all
messages for node
combined in node shared
memory
Socket 0
1 Core – 2 HTs
11
5/16/2016
Socket 1
Java MPI performs better than Threads I
• 48 24 core Haswell nodes 200K DA-MDS Dataset size
• Default MPI much worse than threads
• Optimized MPI using shared memory node-based messaging is much
better than threads (default OMPI does not support SM for needed collectives)
All MPI
All Threads
02/16/2016
12
Intra-node
Parallelism
• All Processes: 32
nodes with 1-36 cores
each; speedup
compared to 32 nodes
with 1 process;
optimized Java
• Processes (Green) and
Threads (Blue) on 48
nodes with 1-24 cores;
speedup compared to
48 nodes with 1
process; optimized
Java
02/16/2016
13
Java MPI performs better than Threads II
128 24 core Haswell nodes on SPIDAL DA-MDS Code
Speedup compared to 1
process per node on 48 nodes
Best MPI; inter
and intra node
MPI; inter/intra
node; Java not
optimized
Best Threads intra
node; MPI inter node
02/16/2016
14
MPI, Fork-Join and Long Running Threads
K-Means 1 million 2D points and 1k centers
•
•
•
Case 0: FJ threads
– Proc bound to T
cores using MPI
– Threads inherit
the same binding
Case 1: LRT threads
– Procs and threads
are both unbound
Case 2: LRT threads
– Similar to Case 0
with LRT threads
Case 3: LRT threads
– Proc bound to all
cores (= non
bound)
– Each worker
thread is bound to
a core
P0,P1..,P7
C0
C1
C2
Socket 0
C3
C4
C5
C6
Socket 1
45000
C7
All Threads
50000
All MPI
Fork Join
40000
35000
30000
Time (ms)
•
25000
LRT
20000
15000
10000
5000
0
Case 0: FJ proc-bound thread-bound
Case 1: LRT proc-unbound thread-unbound
Case 2: LRT proc-bound thread-bound
Case 3: LRT proc-unbound thread-bound
Differ in
helper
threads
1x24x16
2x12x16
3x8x16
4x6x16
6x4x16
24x1x16
15
Parallel Pattern -- T x P x N where T is threads per process, P is process per node, and N is number of
nodes.
8x3x16
12x2x16
DA-PWC Non Vector Clustering
Speedup referenced to
1 Thread, 24 processes,
16 nodes
Increasing
problem
size
Circles 24 processes
Triangles: 12 threads, 2
processes on each node
02/16/2016
16
MIDAS
02/16/2016
17
Pilot-Hadoop/Spark Architecture
HPC into Scheduling Layer
http://arxiv.org/abs/1602.00345
5/17/2016
18
Harp (Hadoop Plugin) brings HPC to ABDS
• Basic Harp: Iterative HPC communication; scientific data abstractions
• Careful support of distributed data AND distributed model
• Avoids parameter server approach but distributes model over worker nodes
and supports collective communication to bring global model to each node
• Applied first to Latent Dirichlet Allocation LDA with large model and data
See Qiu’s talk
Wednesday
5/17/2016
HPC into Programming/communication Layer
19
Workflow in HPC-ABDS
• HPC familiar with Taverna, Pegasus, Kepler, Galaxy … but
ABDS has many workflow systems with recently Crunch, NiFi
and Beam (open source version of Google Cloud Dataflow)
– Use ABDS for sustainability reasons?
– ABDS approaches are better integrated than HPC
approaches with ABDS data management like Hbase and
are optimized for distributed data.
• Heron, Spark and Flink provide distributed dataflow runtime
• Beam prefers Flink as runtime and supports streaming and
batch data
• Use extensions of Harp as parallel computing interface and
Beam as streaming/batch support of parallel workflows
5/17/2016
20
SPIDAL Algorithms
1.
2.
3.
4.
Core
Optimization
Graph
Domain Specific
02/16/2016
21
SPIDAL Algorithms – Core I
• Several parallel core machine learning algorithms; need to add SPIDAL
Java optimizations to complete parallel codes except MPI MDS
– https://www.gitbook.com/book/esaliya/global-machine-learning-with-dsc-spidal/details
• O(N2) distance matrices calculation with Hadoop parallelism and various
options (storage MongoDB vs. distributed files), normalization, packing to
save memory usage, exploiting symmetry
• WDA-SMACOF: Multidimensional scaling MDS is optimal nonlinear
dimension reduction enhanced by SMACOF, deterministic annealing and
Conjugate gradient for non-uniform weights. Used in many applications
– MPI (shared memory) and MIDAS (Harp) versions
• MDS Alignment to optimally align related point sets, as in MDS time series
• WebPlotViz data management (MongoDB) and browser visualization for
3D point sets including time series. Available as source or SaaS
• MDS as 2 using Manxcat. Alternative more general but less reliable
solution of MDS. Latest version of WDA-SMACOF usually preferable
• Other Dimension Reduction: SVD, PCA, GTM to do
5/17/2016
22
SPIDAL Algorithms – Core II
•
•
•
•
•
•
•
Latent Dirichlet Allocation LDA for topic finding in text collections; new algorithm
with MIDAS runtime outperforming current best practice
DA-PWC Deterministic Annealing Pairwise Clustering for case where points
aren’t in a vector space; used extensively to cluster DNA and proteomic
sequences; improved algorithm over other published. Parallelism good but needs
SPIDAL Java
DAVS Deterministic Annealing Clustering for vectors; includes specification of
errors and limit on cluster sizes. Gives very accurate answers for cases where
distinct clustering exists. Being upgraded for new LC-MS proteomics data with one
million clusters in 27 million size data set
K-means basic vector clustering: fast and adequate where clusters aren’t
needed accurately
Elkan’s improved K-means vector clustering: for high dimensional spaces; uses
triangle inequality to avoid expensive distance calcs
Future work – Classification: logistic regression, Random Forest, SVM, (deep
learning); Collaborative Filtering, TF-IDF search and Spark MLlib algorithms
Harp-DaaL extends Intel DAAL’s local batch mode to multi-node distributed modes
– Leveraging Harp’s benefits of communication for iterative compute models
5/17/2016
23
SPIDAL Algorithms – Optimization I
• Manxcat: Levenberg Marquardt Algorithm for non-linear 2
optimization with sophisticated version of Newton’s method
calculating value and derivatives of objective function. Parallelism in
calculation of objective function and in parameters to be determined.
Complete – needs SPIDAL Java optimization
• Viterbi algorithm, for finding the maximum a posteriori (MAP) solution
for a Hidden Markov Model (HMM). The running time is O(n*s2)
where n is the number of variables and s is the number of possible
states each variable can take. We will provide an "embarrassingly
parallel" version that processes multiple problems (e.g. many
images) independently; parallelizing within the same problem not
needed in our application space. Needs Packaging in SPIDAL
• Forward-backward algorithm, for computing marginal distributions
over HMM variables. Similar characteristics as Viterbi above. Needs
Packaging in SPIDAL
5/17/2016
24
SPIDAL Algorithms – Optimization II
• Loopy belief propagation (LBP) for approximately finding the maximum a
posteriori (MAP) solution for a Markov Random Field (MRF). Here the
running time is O(n2*s2*i) in the worst case where n is number of variables, s
is number of states per variable, and i is number of iterations required (which
is usually a function of n, e.g. log(n) or sqrt(n)). Here there are various
parallelization strategies depending on values of s and n for any given
problem.
– We will provide two parallel versions: embarrassingly parallel version for
when s and n are relatively modest, and parallelizing each iteration of the
same problem for common situation when s and n are quite large so that
each iteration takes a long time.
– Needs Packaging in SPIDAL
• Markov Chain Monte Carlo (MCMC) for approximately computing marking
distributions and sampling over MRF variables. Similar to LBP with the same
two parallelization strategies. Needs Packaging in SPIDAL
5/17/2016
25
SPIDAL Graph Algorithms
100
50
5/17/2016
0
Suri et al.
Park et al. 2013 Park et al. 2014
Algorithms
PATRIC
Our Algo.
0
Miami
Twitter
572.67
359.6
26
212.1
200
168.95
Old New
VT
150
87.73
200
400
237.09
250
67.34
300
180.59
350
Runtime (minutes)
Harp
Pure Hadoop
MH Old version
DG SPIDAL
600
2.45
Runtime Performance on Twitter
400
5.39
450
Generation Time (s)
• Subgraph Mining: Finding patterns specified by a template in graphs
– Reworking existing parallel VT algorithm Sahad with MIDAS middleware
giving HarpSahad which runs 5 (Google) to 9 (Miami) times faster than
original Hadoop version
• Triangle Counting: PATRIC improved memory use (factor of 25 lower) and
good MPI scaling
• Random Graph Generation: with particular degree distribution and
clustering coefficients. new DG method with low memory and high
performance, almost optimal load balancing and excellent scaling.
– Algorithms are about 3-4 times faster than the previous ones.
• Last 2 need to be packaged for SPIDAL using MIDAS (currently MPI)
• Community Detection: current work
Weblinks Friendster UK-Union
DataSet
Applications
1.
2.
3.
4.
5.
6.
Network Science: start on graph algorithms earlier
General Discussion of Images
Remote Sensing in Polar regions: image processing
Pathology: image processing
Spatial search and GIS for Public Health
Biomolecular simulations
a. Path Similarity Analysis
b. Detect continuous lipid membrane leaflets in a MD
simulation
02/16/2016
27
Imaging Applications: Remote Sensing,
Pathology, Spatial Systems
•
•
•
•
•
•
•
Both Pathology/Remote sensing working on 2D moving to 3D images
Each pathology image could have 10 billion pixels, and we may extract a
million spatial objects per image and 100 million features (dozens to 100
features per object) per image. We often tile the image into 4K x 4K tiles for
processing. We develop buffering-based tiling to handle boundary-crossing
objects. For each typical study, we may have hundreds to thousands of images
Remote sensing aimed at radar images of ice and snow sheets; as data from
aircraft flying in a line, we can stack radar 2D images to get 3D
2D problems need modest parallelism “intra-image” but often need parallelism
over images
3D problems need parallelism for an individual image
Use many different Optimization algorithms to support applications (e.g.
Markov Chain, Integer Programming, Bayesian Maximum a posteriori,
variational level set, Euler-Lagrange Equation)
Classification (deep learning convolution neural network, SVM, random forest,
etc.) will be important
5/17/2016
28
2D Radar Polar Remote Sensing
• Need to estimate structure of earth (ice, snow, rock) from radar signals from
plane in 2 or 3 dimensions.
• Original 2D analysis (called [11]) used Hidden Markov Methods; better
results using MCMC (our solution)
Extending to
snow radar
layers
5/17/2016
29
3D Radar Polar Remote Sensing
• Uses Loopy belief propagation LBP to analyze 3D radar images
Radar gives a cross-section view,
parameterized by angle and
range, of the ice structure, which
yields a set of 2-d tomographic
slices (right) along the flight path.
Each image
represents a 3d
depth map, with
along track and cross
track dimensions on
the x-axis and y-axis
respectively, and
depth coded as
colors.
Reconstructing bedrock in 3D, for (left) ground truth, (center) existing algorithm
based on maximum likelihood estimators, and (right)
our technique based on a
5/17/2016
30
Markov Random Field formulation.
RADICAL-Pilot Hausdorff distance:
all-pairs problem
Clustered distances for two methods
for sampling macromolecular
transitions (200 trajectories each)
showing that both methods produce
distinctly different pathways.
• RADICAL Pilot benchmark run for
three different test sets of
trajectories, using 12x12 “blocks”
per task.
• Should use general SPIDAL library
5/17/2016
31