Monitoring WLCG with lambda-architecture: a new scalable data store and analytics platform for monitoring at petabyte scale. Issue 5 (December 2015)

• Record Type: Journal Article
• Authors: Magnoni, L; Suthakar, U; Cordeiro, C; Georgiou, M; Andreeva, J; Khan, A; Smith, D R
• Is Part Of: Journal of physics. Volume 664:Issue 5(2015)
• Publication Date: 2015-12
• Subjects: Physics -- Congresses; 530.5
• DOI: 10.1088/1742-6596/664/5/052023
• Languages: English
• ISSNs: 1742-6588

Abstract

Abstract: Monitoring the WLCG infrastructure requires the gathering and analysis of a high volume of heterogeneous data (e.g. data transfers, job monitoring, site tests) coming from different services and experiment-specific frameworks to provide a uniform and flexible interface for scientists and sites. The current architecture, where relational database systems are used to store, to process and to serve monitoring data, has limitations in coping with the foreseen increase in the volume (e.g. higher LHC luminosity) and the variety (e.g. new data-transfer protocols and new resource-types, as cloud-computing) of WLCG monitoring events. This paper presents a new scalable data store and analytics platform designed by the Support for Distributed Computing (SDC) group, at the CERN IT department, which uses a variety of technologies each one targeting specific aspects of big-scale distributed data-processing (commonly referred as lambda-architecture approach). Results of data processing on Hadoop for WLCG data activities monitoring are presented, showing how the new architecture can easily analyze hundreds of millions of transfer logs in a few minutes. Moreover, a comparison of data partitioning, compression and file format (e.g. CSV, Avro) is presented, with particular attention given to how the file structure impacts the overall MapReduce performance. In conclusion, the evolution of the current implementation, which focuses on data storage and batch processing, towards a complete lambda-architecture is discussed, with consideration of candidate technology for the serving layer (e.g. Elasticsearch) and a description of a proof of concept implementation, based on Apache Spark and Esper, for the real-time part which compensates for batch-processing latency and automates problem detection and failures.