Integration and optimization of multiple big data processing platforms. Issue 6 (1st August 2016)

• Record Type: Journal Article
• Authors: Chang, Bao-Rong; Tsai, Hsiu-Fen; Tsai, Yun-Che; Kuo, Chin-Fu; Chen, Chi-Chung
• Editors: Teen-Hang Meen, Dr
• Is Part Of: Engineering computations. Volume 33:Issue 6(2016)
• Page Start: 1680
• Page End: 1704
• Publication Date: 2016-08-01
• Subjects: Data warehouse -- Distributed file system -- Distributed memory storage -- In-memory computing -- Multiple big data processing platforms -- SQL-like query; Computer-aided engineering -- Periodicals; Computer graphics -- Periodicals; 620.00285
• DOI: 10.1108/EC-08-2015-0247
• Languages: English
• ISSNs: 0264-4401

Abstract

Abstract : Purpose: – The purpose of this paper is to integrate and optimize a multiple big data processing platform with the features of high performance, high availability and high scalability in big data environment. Design/methodology/approach: – First, the integration of Apache Hive, Cloudera Impala and BDAS Shark make the platform support SQL-like query. Next, users can access a single interface and select the best performance of big data warehouse platform automatically by the proposed optimizer. Finally, the distributed memory storage system Memcached incorporated into the distributed file system, Apache HDFS, is employed for fast caching query results. Therefore, if users query the same SQL command, the same result responds rapidly from the cache system instead of suffering the repeated searches in a big data warehouse and taking a longer time to retrieve. Findings: – As a result the proposed approach significantly improves the overall performance and dramatically reduces the search time as querying a database, especially applying for the high-repeatable SQL commands under multi-user mode. Research limitations/implications: – Currently, Shark's latest stable version 0.9.1 does not support the latest versions of Spark and Hive. In addition, this series of software only supports Oracle JDK7. Using Oracle JDK8 or Open JDK will cause serious errors, and some software will be unable to run. Practical implications: – The problem with this system is that some blocks are missing when too many blocks are stored in one result (about 100, 000 records). Another problem is that the sequential writing into In-memory cache wastes time. Originality/value: – When the remaining memory capacity is 2 GB or less on each server, Impala and Shark will have a lot of page swapping, causing extremely low performance. When the data scale is larger, it may cause the JVM I/O exception and make the program crash. However, when the remaining memory capacity is sufficient, Shark is faster than Hive and Impala. Impala's consumption of memory resources is between those of Shark and Hive. This amount of remaining memory is sufficient for Impala's maximum performance. In this study, each server allocates 20 GB of memory for cluster computing and sets the amount of remaining memory as Level 1: 3 percent (0.6 GB), Level 2: 15 percent (3 GB) and Level 3: 75 percent (15 GB) as the critical points. The program automatically selects Hive when memory is less than 15 percent, Impala at 15 to 75 percent and Shark at more than 75 percent.