This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
|
teaching:mfe:is [2017/04/19 11:01] svsummer |
teaching:mfe:is [2018/04/30 11:06] svsummer |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== MFE 2017-2018 : Web and Information Systems ====== | + | ====== MFE 2018-2019 : Web and Information Systems ====== |
| ===== Introduction ===== | ===== Introduction ===== | ||
| Line 24: | Line 24: | ||
| * Contact : [[ezimanyi@ulb.ac.be|Esteban Zimanyi]] | * Contact : [[ezimanyi@ulb.ac.be|Esteban Zimanyi]] | ||
| + | |||
| + | ===== Dynamic Query Processing on GPU Accelerators ===== | ||
| + | |||
| + | This master thesis is put forward in the context of the DFAQ Research Project: "Dyanmic Processing of Frequently Asked Queries", funded by the Wiener-Anspach foundation. | ||
| + | |||
| + | Within this project, our lab is hence developing novel ways for processing "fast Big Data", i.e., processing of analytical queries where the underlying data is constantly being updated. The analytics problems envisioned cover wide areas of computer science and include database aggregate queries, probabilistic inference, matrix chain computation, and building statistical models. | ||
| + | |||
| + | The objective of this master thesis is to build upon the novel dynamic processing algorithms being developed in the lab, and complement these algorithms by proposing dynamic evaluation algorithms that execute on modern GPU architectures, thereby exploiting their massive parallel processing capabilities. | ||
| + | |||
| + | Since our current development is done in the Scala programming language, prospective students should either know Scala, or being willing to learn it within the context of the master thesis. | ||
| + | |||
| + | **Validation of the approach** Validation of master thesis' work should be done on two levels: | ||
| + | * a theoretical level; by proposing and discussing alternative ways to do incremental computation on GPU architectures, and comparing these from a theoretical complexity viewpoint | ||
| + | * an experimental level; by proposing a benchmark collection of CEP queries that can be used to test the obtained versions of the interpreter/compiler, and report on the experimentally observed performance on this benchmark. | ||
| + | |||
| + | **Deliverables** of the master thesis project | ||
| + | * An overview of query processing on GPUs | ||
| + | * A definition of the analytics queries under consideration | ||
| + | * A description of different possible dynamic evaluation algorithms for the analytical queries on GPU architectures. | ||
| + | * A theoretical comparison of these possibilities | ||
| + | * The implementaiton of the evaluation algorithm(s) (as an interpreter/compiler) | ||
| + | * A benchmark set of queries and associated data sets for the experimental validation | ||
| + | * An experimental validation of the compiler, and analysis of the results. | ||
| + | |||
| + | **Interested?** | ||
| + | * Contact : //Stijn Vansummeren// | ||
| + | |||
| + | **Status**: available | ||
| + | |||
| + | ===== Multi-query Optimization in Spark ===== | ||
| + | |||
| + | Distributed computing platforms such as Hadoop and Spark focus on addressing the following challenges in large systems: (1) latency, (2) scalability, and (3) fault tolerance. Dedicating computing resources for each application executed by Spark can lead to a waste of resources. Unified distributed file systems such as Alluxio has provided a platform for computing results among simultaneously running applications. However, it is up to the developers to decide on what to share. | ||
| + | |||
| + | The objective of this master thesis is to optimize various applications running on a Spark platform, optimize their execution plans by autonomously finding sharing opportunities, namely finding the RDDs that can be shared among these applications, and computing these shared plans once instead of multiple times for each query. | ||
| + | |||
| + | **Deliverables** of the master thesis project | ||
| + | * An overview of the Apache Spark architecture. | ||
| + | * Develop a performance model for queries executed by Spark. | ||
| + | * An implementation that optimizes queries executed by Spark and identify sharing opportunities. | ||
| + | * An experimental validation of the developed system. | ||
| + | |||
| + | **Interested?** | ||
| + | * Contact : //Iman Elghandour// or //Stijn Vansummeren// | ||
| + | |||
| + | **Status**: available | ||
| + | |||
| + | ===== Accelerated Distributed Platform for Spatial Queries ===== | ||
| + | |||
| + | It is now common to query terabytes of spatial data. Several new frameworks extend distributed computing platforms such as Hadoop and Spark to enable them to efficiently process spatial queries by providing (1) mechanisms to efficiently store spatial data and index them ; and (2) packages of built in spatial operations for these platforms. Meanwhile, it is now common to accelerate Hadoop and Spark using accelerators such as GPUs and FPGAs. | ||
| + | |||
| + | The objective of this master thesis is to build a framework that efficiently executes spatial queries on a Spark version that is enabled to run its tasks on GPUs. | ||
| + | |||
| + | **Deliverables** of the master thesis project | ||
| + | * An overview of Spatial queries and frameworks for processing big spatial data. | ||
| + | * A study of best approaches to represent spatial data while it is queried by Spark and GPUs. | ||
| + | * An implementation of common spatial operations and computational geometry algorithm on GPUs and Spark. | ||
| + | * An experimental validation of the developed system. | ||
| + | |||
| + | **Interested?** | ||
| + | * Contact : //Iman Elghandour// or //Stijn Vansummeren// | ||
| + | |||
| + | **Status**: available | ||
| + | |||
| + | ===== Co-locating Big Spatial Data Stored in HDFS ===== | ||
| + | |||
| + | Spatial databases employ spatial indexes to speedup the access of spatial data. New frameworks are introduced to build such indexes for Hadoop and Spark. However, there are not fully integrated on the file system level. | ||
| + | |||
| + | The objective of this master thesis is to build these indexes within the layer of HDFS and use this implementation to co-locate files that are typically accessed together by the spatial queries. | ||
| + | |||
| + | **Deliverables** of the master thesis project | ||
| + | * An overview of spatial queries and frameworks for processing big spatial data. | ||
| + | * A study of different types of indexes how they can be built in HDFS, and how we can use the replicas of HDFS to store multiple types of indexes | ||
| + | * An implementation of spatial indexes in HDFS. | ||
| + | * An experimental validation of the developed system. | ||
| + | |||
| + | **Interested?** | ||
| + | * Contact : //Iman Elghandour// or //Stijn Vansummeren// | ||
| + | |||
| + | **Status**: available | ||
| + | |||
| + | ===== Complex Event Processing in Apache Spark and Apache Storm ===== | ||
| + | |||
| + | The master thesis is put forward in the context of the SPICES "Scalable Processing and mIning of Complex Events for Security-analytics" research project, funded by Innoviris. | ||
| + | |||
| + | Within this project, our lab is developping a declarative language for Complex Event Processing (CEP for short). The goal in Complex Event Processing is to derive pre-defined patterns in a stream of raw events. Raw events are typically sensor readings (such as "password incorrect for user X trying to log in on machine Y" or "file transfer from machine X to machine Y"). The goal of CEP is then to correlate these events into complex events. For example, repeated failed login attempts by X to Y should trigger a complex event "password cracking warning" that refers to all failed login attempts. | ||
| + | |||
| + | The objective of this master thesis is to build an interpreter/compiler for this declarative CEP language that targets the distributed computing frameworks Apache Spark and/or Apache Storm as backends. Getting aquaintend with these technologies is part of the master thesis objective. | ||
| + | |||
| + | **Validation of the approach** Validation of the proposed interpreter/compiler should be done on two levels: | ||
| + | * a theoretical level; by comparing the generated Spark/Storm processors to a processor based on "Incremental computation" that is being developped at the lab | ||
| + | * an experimental level; by proposing a benchmark collection of CEP queries that can be used to test the obtained interpreter/compiler, and report on the experimentally observed performance on this benchmark. | ||
| + | |||
| + | **Deliverables** of the master thesis project | ||
| + | * An overview of the processing models of Spark and Storm | ||
| + | * A definition of the declarative CEP language under consideration | ||
| + | * A description of the interpretation/compilation algorithm | ||
| + | * A theoretical comparison of this algorithm wrt an incremental evaluation algorithm. | ||
| + | * The interpreter/compiler itself (software artifact) | ||
| + | * A benchmark set of CEP queries and associated data sets for the experimental validation | ||
| + | * An experimental validation of the compiler, and analysis of the results. | ||
| + | |||
| + | **Interested?** | ||
| + | * Contact : //Stijn Vansummeren// | ||
| + | |||
| + | **Status**: available | ||
| ===== Complex Event Processing in Apache Spark and Apache Storm ===== | ===== Complex Event Processing in Apache Spark and Apache Storm ===== | ||
| Line 130: | Line 235: | ||
| **Status**: available | **Status**: available | ||
| - | =====Assessing Existing Communication Protocols In The Context Of DaaS ===== | ||
| - | Data-as-a-Service (DaaS) is an emerging cloud model. The main offering of DaaS is to allow data producers/owners to publish data services on the cloud. The idea of publishing data via a service interface is not new. SOA protocols have enabled this long ago. Yet, these protocols were not developed with the cloud and the big data in mind. This is probably why the term DaaS has emerged. It marks the need for protocols and tools that enable big data exchange. | ||
| - | |||
| - | DaaS services need to exchange large amounts of data. Large here refers to large message size, large message count, or a combination of both. RESTful services, for instance, communicate over HTTP, which is not a good choice for communicating large messages/files. SOAP services are not bound to HTTP, but they introduce another overhead of requiring messages to be strictly formatted in XML. This is why researchers started to reconsider older protocols like the BitTorrent, and suggesting extension to existing protocols like the SOAP with Attachments. | ||
| - | |||
| - | The topic of this thesis is to perform a comprehensive survey on the protocols data exchange, and assess their suitability for DaaS. A quantitative comparison of protocols need to be done, considering at least these two dimensions: (1) the protocol: SOAP, REST, BitTorrent, etc, and (2) the message: short inline, long inline, file. The assessment should be in terms of reliability, performance, and security. | ||
| - | |||
| - | **Deliverables** of the master thesis project | ||
| - | * A report that reviews the state of art communication protocols. | ||
| - | * Propose a tool for DaaS developers to choose the best protocol/s based on their application needs. Such a tool might also provide means of automatically switching between protocols on certain thresholds. | ||
| - | * Experiments to assess the suitability of protocols for DaaS, and to compare between them. These experiments need to be repeatable, so that others can use them on their own datasets and configurations. | ||
| - | |||
| - | **Interested?** | ||
| - | * Contact : [[ezimanyi@ulb.ac.be|Esteban Zimanyi]] | ||
| - | |||
| - | **Status**: available | ||