15_Imoprtance of strategic IT planning

Present Situation and Prospect of Data Warehouse Architecture under the Background of Big Data

Lihua Sun* Nanjing NARI Group Corporation

Nanjing, China e-mail: [email protected]

Kaiyin Ren Nanjing NARI Group Corporation

Nanjing, 210000, China e-mail: [email protected]

Mu Hu Nanjing NARI Group Corporation

Nanjing, 210000, China e-mail: [email protected]

Mingming Ren Nanjing NARI Group Corporation

Nanjing, 210000, China e-mail: [email protected]

Abstract—Compared with the traditional data warehouse applications, the big data analysis is characterized by its large data size and complex query analysis. In order to design the data warehouse architecture suitable for the big data analysis, this paper analyzes and summarizes the current mainstream implementation platform-parallel database, MapReduce and the hybrid architecture based on the above-mentioned two architectures. Moreover, it presents respectively their advantages and disadvantages and describes various researches of and the author’s efforts on the big data analysis to make prospects for the future study.

Keywords-big data; data warehouse; large scale; MapReduce; parallel database; deep analysis

I. INTRODUCTION In recent years, data warehouse has become a hot field of

data management research because the current data warehouse system experiences fundamental changes in the aspects of data source, data service and hardware environment. Under the historical background of the big data, this paper takes a new look of the existing data warehouse system implementation scheme (mainly including the parallel database and MapReduce) and provides theoretical reference to the design of the data warehouse system which can meet the requirements of our times. Due to the limited space, it classifies the studies into three categories: parallel database, MapReduce and the hybrid architecture of parallel database and MapReduce technology. The third architecture can be subdivided as parallel-database- dominated architecture, MapReduce-dominated architecture, and integrated architecture of parallel database and MapReduce. Part 2-4 summarize and analyze the features of various platforms; part 5-6 tracks and concludes the latest researches in this field; part 7 makes prospects for the future study and part 8 makes the conclusion.

II. PARALLEL DATABASE Dating back to the 1980s, the current mainstream parallel

database is similar to the early parallel databases such as Gamma and Grace. These databases all support the standard

SQL and implement many advanced technologies in the database field over the past 3 decades. It mainly adopts the shared-nothing structure which horizontally partitions the relational tables among nodes and makes use of optimizer to schedule and manage the executing process. The goal is to realize the high performance and availability. The greatest advantage of parallel database is the performance. This mainly benefits from many research achievements during the last decades in the database industry. These achievements mainly include advanced technologies and algorithms like index, data compression, materialized view, result buffering, I/O share and optimized data connection. But under the background of big data, just as mentioned in the introduction, the implementation model of data movement will affect the performance.

The parallel database provides data access service through SQL which is widely used because its usability. Therefore, most BI tools support the data interactions based on the standard SQL, making relational database better compatible with many current BI tools. Some databases, like IBM DB2, even make some optimizations for the BI tools. But for the big data analysis, SQL interface faces great challenges. Because of its packaging of the underlying data access, SQL can show its advantages. But this will also affect its openness in a way. Moreover, user-defined functions of parallel databases are mostly designed according to the database examples and they cannot be executed in parallel in a cluster of computers. This means the traditional implementation models do not suit the processing and analysis of big data. And, implementing the use-defined functions in the parallel database usually needs conducting complex systemic interaction and even being familiar with the interior structure and system call of the database. This also makes it difficult to use this method.

III. MAPREDUCE MapReduce abstracts a series of Map-Reduce operation

pairs from the data processing tasks. Map is mainly responsible for the filtering operation of data and Reduce completes the aggregation operation. The input and output data are stored in the format of (key, value). When applying

2013 International Conference on Information Science and Cloud Computing Companion

978-1-4799-5245-8/14 $31.00 © 2014 IEEE

DOI 10.1109/ISCC-C.2013.102

529

Authorized licensed use limited to: University of the Cumberlands. Downloaded on December 01,2020 at 03:38:55 UTC from IEEE Xplore. Restrictions apply.

this programming model, the user just uses his familiar language to implement Map function and Reduce function. And MapReduce framework will automatically divide the tasks and execute these tasks in parallel.

On the topic of implementing Hadoop on the basis of the open-sourcing of MapReduce, this paper presents below the main features of MapReduce. MapReduce is designed for the large scale clusters of thousands of low- and mid-range computers. Its scalability benefits from its shared-nothing structure, loose coupling of nodes and strong software fault tolerance: nodes can be removed arbitrarily from the cluster of computers almost with no possibility to affect the existing task. This technology is called as RAIN (Redundant/Reliable Array of Independent (and Inexpensive) Nodes). The outstanding scalability of MapReduce has been fully validated in the industrial circles (Google, Facebook, Baidu, Taobao, etc). MapReduce has lower requirements for hardware and builds the cluster of computers with inexpensive heterogeneous hardwires. It can even freely open source. So its building cost is much lower than that of parallel database. However, the MapReduce-based application software is relatively scarce and users have to develop many data analysis functions on their own. As a result, the use costs increase.

IV. ARCHITECTURE OF PARALLEL DATABASE AND MAPREDUCE

Based on the above analysis, we can clearly find that, the data warehouse system based on parallel database and MapReduce is not the ideal alternative for big data analysis. Recently there has been a debate on the problem which architecture is more suitable for our needs, in the industry. The industry has reached a consensus: parallel database and MapReduce are complementary and should learn from each other. Based on this view, many researches combine the two technologies to design a data analysis platform which can have both advantages. These architectures can be divided into three categories: parallel-database-dominated architecture, MapReduce-dominated architecture and integrated architecture of MapReduce and parallel database.

A. Parallel-Database-Dominated Architecture The method focuses on how to use MapReduce to

enhance the data processing ability of parallel database. Representatives of these systems are the Greenplum (acquired by EMC) and AsterData (acquired by Teradata).

Combining SQL and MapReduce, AsterData analyzes the SQL/MapReduce framework in view of the large data analysis. This framework allows the user to apply the programming languages like C++, java and Python to work out the MapReduce function which can be employed as a sub-query in SQL and obtain the accessibility of SQL and openness of MapReduce. Additionally, based on MapReduce, AsterData implements more than 30 statistical software packages, making the data analysis conducted in the database (internal database analysis) to greatly improve the performance of the data analysis.

Greenplum also introduces the processing functions of MapReduce into its database [1]. Its execution engine can

handle SQL query and MapReduce tasks at the same time. This method integrates SQL and MapReduce at the code level: the SQL can directly use the output of MapReduce tasks and MapReduce tasks can also take the SQL query results as the input at the same time.

Overall, these systems all focus on the application of MapReduce to improve the data processing function of parallel database, but the fundamental problems of scalability and fault tolerance ability still exist

B. MapReduce-Dominated Architecture This research mainly emphasizes the application of SQL

interface and its model support to improve the usability of MapReduce. The representative systems are Hive and PigLatin.

Hive is a large-scale data warehouse proposed by Facebook on a basis of Hadoop. It aims at simplifying operations of the data aggregation, ad-hoc query and big data analysis to reduce the burdens of the programmer. Referring to technologies including the model management of relational database and SQL interface, it reflects the structured data files as database tables and provides the programmer with the descriptive language HiveQL similar to SQL. It can automatically turn the HiveQL sentences into optimized task execution sequences. Besides, it also supports the user-defined MapReduce functions.

PigLatin, put forwarded by Yahoo!, is a big data analysis platform similar to Hive. Their difference lies in the language interface. Fig.1 is a query processing example of PigLat. The purpose of this query is to find out 5 pages most frequently visited by users at the age of 18-25. From Fig.3, we can find that the operation interface provided by Pig is similar to the operator of the relational database (each row of orders in the right part of the figure) and the query script for the user is similar to the logic query plan (the left part of the figure): Hive provides the interface similar to SQL while PigLatin offers a data-flow interface based on the operators. So, it can also say that Pig makes use of the operator to package Hadoop while Hive takes advantage of SQL to package it.

Figure 1. A query example of Pig Latin (the actual script is in the right side)

C. Integrated Architecture of MapReduce and Parallel Database Representatives are HadoopDB proposed by the Yale

University (commercialized as Hadapt in 2011), Vertica

530

Authorized licensed use limited to: University of the Cumberlands. Downloaded on December 01,2020 at 03:38:55 UTC from IEEE Xplore. Restrictions apply.

database designed by Stonebraker et al and Teradata database of NCR Company.

The core idea of HadoopDB is to use Hadoop for scheduling and network communication and take the relational database as the execution engine to put the query into the database processing. Its target is to take advantage of Hadoop framework to obtain better fault tolerance and support for heterogeneous environment; it also intends to achieve the performance advantages of the relational database in the execution process of putting the query into the database. The idea of HadoopDB is profound but there is no application case. Reasons are : (1) the data preprocessing is costly: data can be used only after data being decomposed for twice and database being loaded for once; (2) there is few cases that the query can be put into the database layer; in most cases, the query is completed by Hive; data warehouse queries often involve multiple table connections which are very complex, so it is difficult to divide the connected multiple tables according to a certain model in the condition of the locality of connection data; (3) the maintenance cost is too high, involving the maintenance of Hadoop and the nodes of each database; (4) it cannot support dynamic partitioning of data and needs manually dividing the data once for all. In general, the HadoopDB sometimes can achieve the high performance of the relational database and scalability and fault tolerance of MapReduce at the same time but lose some advantages of both architectures, such as the low preprocessing and maintenance costs of MapReduce and dynamic data redistribution of the relational database.

Vertica takes the coexistence strategy: partitioning the data processing tasks according to the processing advantages of Hadoop and Vertica. For example, Hadoop is responsible for the processing of unstructured data while Vertica is responsible for the structured data processing; Hadoop is responsible for the complex time-consuming batch processing while Vertica is responsible for the high- performance interactive query; therefore, it is necessary to combine these two technologies. Vertica actually uses 2 sets of system, supporting the direct access of the Vertica database data in the MapReduce tasks. Because the structured data are still processed in Vertica, there are some scalability problems in the query analysis process of structured data. Additionally, putting the query in the Hadoop may cause performance problems. So the scalability problems of Vertica and the performance problems of Hadoop may coexist in the system.

To sum up, the current architectures can be divided into three categories: parallel-database-dominated architecture, MapReduce-dominated architecture and integrated architecture of MapReduce and parallel database (Table 1 shows the comparative analyses of three architectures).

V. RESEARCH STATUS For parallel database, the key problem lies in the limited

scalability and the soft-level fault tolerance ability; the biggest problem of MapReduce is performance, especially the performance of the join operation; the key factor of the hybrid architecture is to put as many as tasks to the proper execution engines (parallel database and MapReduce). This

part analyzes and summarizes the researches of these problems.

A. Scalability and Fault Tolerance Studies of Parallel Database University of Washington proposed the parallel

execution plan optimizer of different fault tolerance levels in the literature [2]. This optimizer can generate a parallel execution plan of fault tolerance ability according to the input parallel execution plan, the fault tolerance strategy of each operator and the expectation value of the query failure. In this plan, each operator can adopt different fault tolerance strategies. In case of any failure, only the tasks of sub- operators will be re-executed (operators running on a node) to avoid the re-execution of the whole query.

MIT designs the Osprey based on the data distribution strategies that the dimension table fully copies and the fact table conducts horizontal partition of redundant backups in 2010. This system divides the star query into many independent sub-queries. Each sub-query can be re-executed at the backup node without re-executing the entire query, which ensures the fault tolerance similar to that of MapReduce.

B. Performance Optimization Study of MapReduce The performance optimization research of MapReduce

lies in the transplantation of advanced technologies and properties of the relational database.

Facebook cooperated with Ohio State University to apply the hybrid storage model of the relational database into the Hadoop platform to propose the RCFile storage format. In contrast, the literature [3] introduced the sequence storage technology into the Hadoop platform. Hadoop++ system employed the index technology of the traditional database and improved the performance through the co-partition of the data of sub-districts. The literature [4, 5], based on MapReduce, had realized the data transmission among the various operators in the way of flow line to shorten the task execution time. And the operation mode of online aggregation allows the user to see some early returned results in the process of query execution. Their difference is that the former still adopts the sort-merge method to implement the flow line just leaving the operations like sorting in the reducer and resulting in the pause of the flow line in some cases; while the latter distributes the data in the way of hash to achieve a better parallel flow line. The literature [6] proposed the MRShare architecture which could transform the batch queries and integrate a group of tasks including share scanning and share Map output to improve the performance. National University of Singapore conducted a deep analysis on the factors affecting the performance of Hadoop and put forward five effective optimization technologies, tripling the performance of Hadoop close to that of the relational database.

VI. COMBINATION OF MAPREDUCE AND RELATIONAL DATABASE TECHNOLOGY

To sum up, the current researches mostly focus on the transplantation of functions or properties-learning new

531

Authorized licensed use limited to: University of the Cumberlands. Downloaded on December 01,2020 at 03:38:55 UTC from IEEE Xplore. Restrictions apply.

technologies[7] from a platform and realizing and integrating the technologies on another platform without involving the execution core; thus, never fundamentally solving the problems of big data analysis. In view of this, there is another way of thinking: starting from the two core execution layers of the data organization and query, combining two technologies of the relational database and MapReduce and designing the high-performance scalable abstract data warehouse query processing framework. Supporting the high scalability[8], this framework also has the performance of the relational database at the same time. Today people has tried two research directions: (1) referring to the idea of MapReduce to make OLAP query processing obtain the high scalability of MapReduce (the prototype of LinearDB); (2) taking advantage of the technologies of the relational database to make MapReduce acquire the performance of the relational database when it is processing the OLAP (the prototype of Dumbo).

A. LinearDB LinearDB prototype system does not directly adopt the

star model based on connection (Snowflake Schema), but changes it and designs a scanning-based JFSS[9] (Join-Free Snowflake Schema) of better scalability. The design of this schema takes the idea of universal relation model for reference and adopts the hierarchical coding technology to compress the dimension table information into the fact table. In this way, the fact table can independently execute the operations of predicate judgment and aggregation to realize the locality of the connected data on the large-scale cluster of computers and eliminate the join operation. Fig.2 is the corresponding schematic diagrams of star schema and JFSS.

Figure 2. Contrast: a typical star schema and its corresponding JFSS

In the execution hierarchy, LinearDB absorbs the design idea of MapReduce process model, summarizing the

processing of data warehouse query as 3 operations- Transform, Reduce and Merge (TRM execution model[10]): (1) Transform. The major node preprocesses the query, turning the operations in the dimension table (predicate judgment and group-by aggregation). (2) Reduce. Each data node scans and aggregates the local data in parallel and then returns the results to the main node. (3) Merge. The master node merges the results returned by each data node and executes the following filtering and sorting operations. Based on TRM execution model[11], queries can be classified into many independent subtasks which can be in parallel performed on the large-scale cluster of computers. During the execution process, any failure subtask can be re- conducted on the back-up nodes to gain good fault tolerance ability. Results show, its performance is at least of a higher magnitude order than that of HadoopDB. The scalability, fault tolerance and high performance of LinearDB lie in the ingenious combination of technologies of the relational database (hierarchical coding technology and universal relation schema) and the design ideas of MapReduce processing schema. From this, it can be seen that the different combination methods can result in the significant differences of the system capability.

B. Dumbo The core idea of Dumbo[12] is to change the OLAP

query processing according to the processing schema of filtering->aggregation of MapReduce to make it fit for MapReduce framework.

Dumbo adopts the data organization schema similar to that of LinearDB, taking advantage of hierarchical coding technology to compress the dimension table information into the fact table. It is different that Dumbo applies an effective coding method and optimizes data storage according to the characteristics of the Hadoop distributed file systems.

In the execution hierarchy, Dumbo extends the MapReduce framework and designs a new OLAP query processing framework (Transform->Map->Reduce- >Postprocess) (shown in Fig.3). In this framework, the master node firstly transforms the query and generates a MapReduce task to execute the query. This task scans and aggregates the local data in the way of flow line at the Map phase and just transforms the local aggregation data to the Reduce phase to conduct the merging, aggregation and sorting operations of data.

532

Authorized licensed use limited to: University of the Cumberlands. Downloaded on December 01,2020 at 03:38:55 UTC from IEEE Xplore. Restrictions apply.

Figure 3. Dumbo architecture (the dark grey part is the new module and

the left is the built-in module of Hadoop)

We can find that the complex OLAP query, under the MapReduce framework, can also obtain the performance close to or even surpassing that of the relational database. The key is how to combine the two technologies of the relational database and MapReduce. It is difficult to fundamentally solve the problems of big data analysis if we just stay on the surface of the transplantation and integration. Literature [13] also showed how to make use of the complex analysis to operate efficient percentile computational problems based on this new data organization method.

VII. RESEARCH PROSPECT Although LinearDB and Dumbo can basically achieve

the desired design goal, both of them need to preprocess the data resulting in a preprocessing cost 7 times higher than that of the common loading time. So the ability to cope with changes is still weak, which should be an important part of our future work.

The current three kinds of research cannot perfectly solve the problems of big data analytics, which means that each research direction is very challenging for us.

For the parallel database, its scalability has been substantially improved in recent years (Greenplum and AsterData are designed and developed for the PB data scale). But it still cannot satisfy the analysis needs of big data. As a result, it is a challenging job to improve the scalability of the parallel database and this will involve the consistency protocol, fault tolerance and performance of data in the field of database. The hybrid architecture which has achieved some results can be basically reused with little development work. However, the simple functional integration cannot effectively solve the problems of big data analysis, so this research direction requires much further work. For example,

it is meaningful to research the data model and query processing schema to make them naturally combine together.

Compared with the former two technologies, the performance optimization of MapReduce makes great progress with its performance gradually close to the relational database. The research direction can also be divided into two sub-directions: the theoretical circle focuses on the application of relational database technology and the theory to improve the performance of MapReduce; and the Industrial circle emphasizes the development of efficient application software based on MapReduce platform. As for the data warehouses, the following research directions are very important and there are few researches having involved in these fields:

1) Pre-computing of multidimensional data: MapReduce mainly focuses on the once-for-all analysis

operation. Although it is difficult to predict the big data analysis operation, the traditional analyses of big data account for the majority, such as the analyses based on the statements and multidimensional data. So, MapReduce platform can also take advantage of the means like pre- computing to accelerate the speed of data analysis. Taking the storage space into consideration (it can be imagined that the computing data cube on the explosion data needs high storage cost), MOLAP is unacceptable and hybrid OLAP (HOLAP) is the optimal OLAP implementation scheme of MapReduce platform. The specific studies are as follows:

effective Cube computing algorithm based on MapReduce framework; the selection of materialized views, namely, which data to materialize; materialized means of different analysis operations (such as the materialization of forecast analysis) and complex analysis operations based on the materialized data (such as the selection of data access path).

2) Parallel implementation of various analysis operations:

The big data analysis requires the support of efficient complex statistical analysis functions. IBM integrated the open-sourcing statistical analysis software R into the Hadoop platform, enhancing the statistical analysis function of Hadoop. But the more challenging question is how to design an efficient analysis algorithms based on MapReduce framework. In particular, it is necessary to stress, in view of the huge costs of mobile data, these algorithms should be realized on a basis of mobile computing.

3) Query sharing: MapReduce adopts the processing method of

materialization of each step, leading to the high costs of I/O and network transmission. One effective way[14] to reduce the cost is to share the intermediate results of materialization across multiple queries (even the raw data) to share the cost and avoid double counting. So it is of practical value to study how to share the intermediate results of multiple queries.

4) User interface: Achieve the displays and operations of data analysis,

especially the visual display of complex analysis operations. 5) Reliable research of Hadoop:

533

Authorized licensed use limited to: University of the Cumberlands. Downloaded on December 01,2020 at 03:38:55 UTC from IEEE Xplore. Restrictions apply.

The current Hadoop adopts the subordinative construction, resulting in the condition that the whole system may break down if the master node fails. So it is a practical research to improve the reliability of the master node without affecting the existing implementation of Hadoop.

6) Multidimensional indexing research: Implement the multidimensional indexing according to

the MapReduce framework and speed up the retrieval of multidimensional data. Of course, there is still much challenging and significant research work in this field, such as the real-time data analysis, flexible research and data consistency based on Hadoop. Limited by the space, we won’t describe them in details here.

VIII. CONCLUSIONS This paper conducts evaluation, induction and contrast

analysis on the mainstream implementation platforms of big data analysis (parallel database, MapReduce and the mix architecture of the above-mentioned two architectures). From this paper, we may find that every analysis platform is not perfect. As for the big data analysis, there is still a long way to go. The big data analysis forces us to reflect on the traditional data warehouse architecture and modestly research the new platforms. In this way, we can think about these problems at a higher lever to find the data warehouse architecture which can satisfy the needs of our times.

REFERENCE [1] Stonebraker M, Abadi D J, DeWitt D J, Madden S, PaulsonE, Pavlo

A, Rasin A. MapReduce and parallel DBMSs:Friends or foes? Communications of the ACM, 2010, 53(1):64-71

[2] Dean J, Ghemawat S. MapReduce: A flexible data process-ing tool. Communications of the ACM, 2010, 53(1): 72-77

[3] http: //www.greenplum.com/technology/map- reduce/ [4] Azza Abouzeid, Kamil Bajda-Pawlikowski, Daniel J Abadi,

Alexander Rasin, Avi Silberschatz. HadoopDB: An architec-tural hybrid of MapReduce and DBMS technologies for ana-lytical workloads, Proceedings of the 35th International Conference on Very Large Data Bases (VLDB.09). VLDB Endowment, vol.2, Sep 2009, pp 922-933

[5] Upadhyaya P, Kwon Y C, Balazinska M. A latency and fault- tolerance optimizer for online parallel query plans//Proceedings of the ACM SIGMOD International Conference on Management of Data(SIGMOD.11). ACM New York, NY, USA, Jun 2011:241-252

[6] Yang C, Yen C, Tan C, Madden S. Osprey: Implementing MapReduce style fault tolerance in a shared-nothing distributed database//Proceedings of the 24th International Conference on Data Engineering(ICDE.10).Long Beach, California, USA, IEEE Press,Oct 2010: 657-668

[7] Floratou A, Patel J M, Shekita E J, Tata Sandeep. Column oriented storage techniques for MapReduce. PVLDB, 2011,4(7): 419-429

[8] Nykiel T, Potamias M, Mishra C, Kollios G, Koudas N.MRShare: Sharing across multiple queries in MapReduce. PVLDB, 2010, 3(1): 494-505

[9] Blanas S, Patel Jignesh, Ercegovac V, Rao J, Shekita E J, Tian Y. A comparison of join algorithms for log processing in MaPreduce//Proceedings of the ACM SIGMOD International Conference on Management of Data(SIGMOD.10). Indianapolis, Indiana, USA, ACM New York, NY, USA, Dec 2010: 975-986

[10] Yang H-C, Dasdan A, Hsiao R-L, Parker D S. Map-reduce merge: Simplified relational data processing on large clusters//Proceedings of

the ACM SIGMOD International Conference on Management of Data (SIGMOD.07). Beijing, China, ACM New York, NY, USA ,Aug 2007: 1029-1040

[11] Okcan A,Riedewald M.Processing theta-joins using MapReduce //Proceedings of the ACM SIGMOD International Conference on Management of Data (SIGMOD.11 ). Athens, Greece, ACM New York, NY, USA, Nov 2011: 949-960

[12] Wang Huiju, Wang Shan, Qin Xiongpai, Li Furong, Zhou Xuan, Qin Zuoyan, Zhu Qing. Efficient star query processing on Hadoop)A hierarchy encoding based approach (Technical report), unpublished

[13] Qin Xiongpai, Wang Huiju, Du Xiaoyong, Wang Shan. Parallel aggregation queries over star schema: A hierarchical encoding scheme and efficient percentile computing as a case//Proceedings of the 9th IEEE International Symposium on Par-allel and Distributed Processing with Applications(ISPA.11).Busan, Korea, IEEE Press,May 2011, 329-334

[14] Das S, Sismanis Y, Beyer K S, Gemulla R, Haas P J, McPherson J. Ricardo: Integrating R and Hadoop//Proceedings of the ACM SIGMOD International Conference on Management of Data(SIGMOD.10). Athens, Greece, Indianapolis, Indiana, USA, ACM New York, NY, USA, Dec 2010, 987-998

534

Authorized licensed use limited to: University of the Cumberlands. Downloaded on December 01,2020 at 03:38:55 UTC from IEEE Xplore. Restrictions apply.

TABLE I COMPARATIVE ANALYSES OF HYBRID ARCHITECTURE SOLUTIONS

Solutions Focus Typical systems Defects

Parallel-database- dominated architecture

Taking advantage of MapReduce technology to increase its openness to achieve the scalability of

the process ability

Greenplum Aster Data

Scalability problem

MapReduce-dominated architecture

Learning the SQL interface and model support to improve its usability

Hive Pig Latin

Performance problem

Integrated architecture of MapReduce and parallel

database

Integrating these two technologies to give full play

to the advantages of each technology

Hadoop DB

Only few queries can be conducted on the database layer and some advantages of each architecture disappear after the integration

Vertica Failure to achieve performance and scalability at the same time

Teradata Scalability problem

535

Authorized licensed use limited to: University of the Cumberlands. Downloaded on December 01,2020 at 03:38:55 UTC from IEEE Xplore. Restrictions apply.