DAMEWARE design and architecture

The early design stage of the DAMEWARE resource had as main goal to provide a web application for data mining on MDS. For the computational infrastructure two main requirements emerged: a-synchronous access and scalability. Most available web based data mining services run synchronously. This means that they execute jobs during a single HTTP transaction. This might be considered useful and simple, but it does not scale well when it is applied to long-run tasks. With synchronous operations, all the entities in the chain of command (client, workflow

1http://dame.dsf.unina.it

engine, broker, processing services) must remain up for the duration of the activity.

If any component stops, the context of the activity is lost. DAME was conceived to provide the scientific community with an extensible, integrated environment for data mining and exploration. In order to do so, DAME had to:

• Support the VObs standards and formats, especially for data interoperability;

• To abstract the application deployment and execution, so to provide the VObs with a general purpose computing platform exploiting modern technologies.

With web applications, a remote user does not require to install program clients on his desktop, and has the possibility to collect, retrieve, visualize and organize data, configure and execute mining applications through the web browser and in an asynchronous way. An added value of such approach being the fact that the user does not need to directly access large computing and storage facilities. He can transparently make his experiments by exploiting computing networks and archives located worldwide, requiring only a local laptop (or a smartphone) with a network connection. For what the DAMEWARE functionalities are concerned, we need to distinguish between supervised and unsupervised algorithms. In the first case, we have a set of data points or observations, for which we know the desired output, class, target variable, or outcome. The outcome may take one of many values called

“classes” or “labels”. The target variable provides some level of supervision in that it is used by the learning algorithm to adjust parameters or make decisions that allow it to predict labels for new data. Finally, when the algorithm is predicting labels to observations, we call it a classifier. Some classifiers are also capable of providing a probability for a data point to belong to a given class and are often referred to as probabilistic models or regression, not to be confused with statistical regression models (cf. Duda et al. 2001).

In the unsupervised case, instead of trying to predict a set of known classes, we are trying to identify the patterns inherent to the data, without outcomes or labels. In other words, unsupervised methods try to create clusters of data that are inherently similar. In the DAME data mining infrastructure, the choice of any machine learning model is always accompanied by the functionality domain. To be more precise:

several machine learning models can be used in the same functionality domain, since it represents the experiment domain context in which the exploration of data is performed. In what follows we shall therefore adopt the following terminology:

• Data mining model: any of the data mining models integrated in the DAME suite. It can be either a supervised machine learning algorithm or an unsu-pervised one, depending on the available Knowledge Base (KB), i.e. the set of training or template cases available, and the scientific target of the experiment;

• Functionality: one of the already discussed functional domains, in which the user wants to explore the available data (like for example, regression,

Model Category Functionality MLPBP Supervised Classification, regression MLPQNA Supervised Classification, regression MLP Supervised Classification, regression SVM Supervised Classification, regression

SOFM Unsupervised Clustering

K-Means Unsupervised Clustering PPS unsupervised Dimensional Reduction GAME supervised Classification, regression

Table 3.1: The available data mining models and functionalities in the DAMEWARE web application, MLPBP stands for: Multi Layer Perceptron (MLP) trained by Back Propagation learning rule; MLPQNA stands MLP for trained by Quasi Newton learning rule; MLPGA stands for MLP trained by Genetic Algorithm; SVM stands for Support Vector Machines; SOFM stands for Self Organizing Features Maps; PPS stands for Probabilistic Principal Surfaces; GAME stands for Genetic Algorithm Model Experiment.

classification or clustering). The choice of the functionality target can limit the choice of the data mining model;

• Experiment: it is the scientific workflow (including optional pre-processing or preparation of data) and includes the choice of a combination of, a data mining model and a functionality;

• Use Case: for each data mining model, different running cases are exposed to the user . These can be executed singularly or in a prefixed sequence. Being the models derived from the machine learning paradigm, each may have training, test, validation and run use cases, in order to, respectively, perform learning, verification, validation and execution phases. In most models there is also the “full” use case that automatically executes all listed cases as a sequence.

The functionalities and models currently available in DAMEWARE, beta re-lease, are listed in Table 3.1. Depending on the specific experiment and on the execution environment, the use of any of the above models can take place with a more or less advanced degree of parallelization. All the models require some parameters that cannot be defined a priori, thus causing the necessity of iterated experiment interactive sessions in order to find the best tuning. For this reason not all the models can be developed under the MPI (Message Passing Interface) paradigm (Chu et al., 2007). But the possibility to execute more jobs at once (spe-cific grid case) intrinsically exploits the multi-processor architecture. As for all data mining models integrated in the DAME framework, there is instanced a specialized plugin (called DMPlugin) for each couple model-functionality, that includes the specific parameter configuration. In this way, it is also possible to easily replace

Figure 3.1: The general Software Architecture of DAMEWARE.

and/or upgrade models and functionalities without any change or modification to the DAME software components (Brescia et al., 2010b).

The plugin extension facility represents also a practical baseline prototype for a more reliable and performing approach to handling massive datasets, by truly over-coming the data transfer bandwidth limitations.

In order to deal with MDS, DAMEWARE offers asynchronous access to the infras-tructure tools, thus allowing the running of activity jobs and processes outside the scope of any particular web-service operation and without depending on the user connection status. The user, via a simple web browser, can access the application resources and has the possibility to keep track of his jobs by recovering related information (partial/complete results) without having the need to maintain open the communication socket. Furthermore DAMEWARE has been designed to run both on a server and on a hybrid distributed computing infrastructure. From the technological point of view, DAME consists of five main components: Front End (FE), Framework (FW), Registry and Data Base (REDB), Driver (DR) and Data Mining Models (DMM).

The scheme in Fig. 3.1 shows the component diagram of the entire suite with their main interface/ information exchange layout. While details on the DAME infrastructure can be found in (Brescia et al., 2010b) and the documentation available on the DAME web site, here we shall just outline a few relevant features. The DAME design architecture is implemented following the standard LAR (Layered

Application Architecture) strategy, which leads to a software system based on a layered logical structure, where different layers communicate with each other via simple and well-defined rules:

• Data Access Layer (DAL): the persistent data management layer, responsible of the data archiving system, including consistency and reliability mainte-nance.

• Business Logic Layer (BLL): the core of the system, responsible of the management of all services and applications implemented in the infrastructure, including information flow control and supervision.

• User Interface (UI): responsible of the interaction mechanisms between the BLL and the users, including data and command I/O and views rendering.

A direct implication of the LAR strategy adopted in DAME is the Rich Internet Application (RIA; Bozzon et al. 2010), consisting in applications having traditional interaction and interface features of computer programs but usable via simple web browsers, i.e. not needing any installation on user local desktop. RIAs are particularly efficient in terms of interaction and execution speed. By keeping this in mind, the main concepts behind the distributed data mining applications implemented in the DAME Suite are based on three issues:

• Virtual organization of data: this is the extension of the already remarked basic feature of the VObs;

• Hardware resource-oriented: this is obtained by using computing infrastruc-tures, like grid, which enable parallel processing of tasks, using idle capacity.

The paradigm in this case is to obtain large numbers of instances running for short periods of time;

• Software service-oriented: this is the base of usual cloud computing paradigm (Shende, 2010). The data mining applications implemented runs on top of virtual machines seen at the user level as services (specifically web services), standardized in terms of data management and working flow.

The complete Hardware infrastructure of the DAME Program is shown in Fig.

3.2, where the grid sub-architecture provided by the S.Co.P.E. supercomputing facility (Merola, 2008; Brescia et al., 2010b) is incorporated into the more general cloud scheme, including a network of multi-processor and multi-HDD PCs and workstations, each of them dedicated to a specific function.

There are two sub-networks addressable from an unique access point, the web-site, which provides an embedded access to the user to all DAME web applications and services. The integrity of the system, including the grid public access, is guar-anteed by a registration procedure, which gives the possibility to access all facilities from just one account. In particular, a robot certificate is automatically handled by the DAME system to provide transparent access to the S.Co.P.E. grid resources

Figure 3.2: The general Hardware Architecture of DAME applications

(Deniskina et al., 2009). Depending on the computing and storage power requested by the job and by the processing load currently running on the network, an internal mechanism redirects the jobs to a job-queue in a pre-emptive scheduling scheme.

The interaction with the infrastructure is completely asynchronous and a specialized software component (DR, DRiver) has the responsibility to store off-line job results in the user storage workspaces, that can be retrieved and downloaded in subsequent accesses.

This hybrid architecture, renders it possible to execute simultaneous experiments that gathered all together, bring the best results.

Even if the individual job is not parallelized, we obtain a running time improve-ment by reaching the limit value N of the Amdahl’s law (Amdahl, 1967), shown in equation 3.1:

1

(1+ P) + _N^P (3.1)

where P is the fraction of a program that can be made parallel (i.e. which can benefit from parallelization), and (1 − P) is the fraction that cannot be parallelized (remains serial), then the resulting maximum speed-up that can be achieved by using N processors is obtained by the law expressed above. For instance, in the case of the AGN (Active Galactic Nucleus) classification experiment (Cavuoti et al., 2008; Brescia et al., 2009), which used SVM (Support Vector Machines) each of the 110 jobs runs for about a week on a single processor. By exploiting the GRID

S.Co.P.E.², the experiment running time was reduced to about one week instead of more than 2 years. From the software point of view, the baselines behind the engineering design of DAME Suite were:

• Modularity: software components with standard interfacing, easy to be re-placed;

• Standardization: basically, in terms of information I/O between user and infrastructure as well as between software components (in this case based on XML-schema);

• Hardware virtualization: i. e. independent from the hardware deployment platform (single or multi processor, grid etc.);

• Interoperability: by following VO requirements;

• Expandability: many parts of the infrastructure require to be increased and updated along its lifetime. This is particularly true concerning computing architecture, framework capabilities, GUI (Graphical User Interface) features, data mining functionalities and models (this also includes the integration within the system of end user proprietary algorithms);

• Asynchronous interaction: the end user and the client-server mechanisms do not require a synchronous interaction. In other words, the user is not constrained to remain connected after launching an experiment in order to wait for the end of execution. Moreover, by using the Ajax (Asynchronous Javascript and XML described in Garrett 2005) mechanism, the web applica-tions can retrieve data from the server asynchronously in background without interfering with the display and behavior of the existing page.

• Language-independent Programming: this basically concerns the API (Ap-plication Programming Interface) forming the data mining model libraries and packages. Although most of the available models and algorithms were internally implemented, this is not considered as mandatory (it is possible to re-use existing tools and libraries, integration of end user tools etc.). So far, the Suite provided a Java based standard wrapping system to achieve the standard interface with multi-language APIs;

2S.Co.P.E. is a general purpose GRID infrastructure of the University Federico II in Naples funded through the Italian National Plan (PON) by the Italian Government to support both fundamental research and small/medium size companies. The infrastructure has been conceived as a metropolitan GRID, embedding different (and in some cases pre-existing) and heterogeneous computing centers each with its specific vocation: high energy physics, astrophysics, bioinformatics, chemistry and material sciences, electric engineering, social sciences. Its intrinsically multi-disciplinary nature renders the S.Co.P.E. an ideal test bed for innovative middleware solutions and for interoperable tools and applications finely tuned on the needs of a distributed computing environment (Brescia et al., 2009).

• Distributed computing: the components can be deployed on the same machine as well as on different networked computers;

• Pluggable: with the new plugin procedure users can extend the data mining model library integrated into the web app, by simply download and run a Java applications, which through a driven procedure generate source code to be integrated into the web app software infrastructure. This procedures are the first prototype of our proposal (IVOA Interoperabilty Workshop 2011, Naples) of a new vision of the KDD App approach: shared apps that can move on demand to the various datacenter plugged in each other, that could be extended to every VO App, in order to obtain a new generation of instruments, based on the minimization of data transfer and maximization of interoperability in the VO community.