Apache Hive vs Apache Impala: What are the differences?
Developers describe Apache Hive as "Data Warehouse Software for Reading, Writing, and Managing Large Datasets". Hive facilitates reading, writing, and managing large datasets residing in distributed storage using SQL. Structure can be projected onto data already in storage. On the other hand, Apache Impala is detailed as "Real-time Query for Hadoop". Impala is a modern, open source, MPP SQL query engine for Apache Hadoop. Impala is shipped by Cloudera, MapR, and Amazon. With Impala, you can query data, whether stored in HDFS or Apache HBase – including SELECT, JOIN, and aggregate functions – in real time.
Apache Hive and Apache Impala can be primarily classified as "Big Data" tools.
Some of the features offered by Apache Hive are:
- Built on top of Apache Hadoop
- Tools to enable easy access to data via SQL
- Support for extract/transform/load (ETL), reporting, and data analysis
On the other hand, Apache Impala provides the following key features:
- Do BI-style Queries on Hadoop
- Unify Your Infrastructure
- Implement Quickly
Apache Hive and Apache Impala are both open source tools. It seems that Apache Hive with 2.68K GitHub stars and 2.63K forks on GitHub has more adoption than Apache Impala with 2.19K GitHub stars and 825 GitHub forks.
According to the StackShare community, Apache Hive has a broader approval, being mentioned in 36 company stacks & 42 developers stacks; compared to Apache Impala, which is listed in 17 company stacks and 37 developer stacks.
What is Apache Hive?
What is Apache Impala?
Need advice about which tool to choose?Ask the StackShare community!
Why do developers choose Apache Hive?
What are the cons of using Apache Hive?
What are the cons of using Apache Impala?
Sign up to get full access to all the companiesMake informed product decisions
Sign up to get full access to all the tool integrationsMake informed product decisions
To provide employees with the critical need of interactive querying, we’ve worked with Presto, an open-source distributed SQL query engine, over the years. Operating Presto at Pinterest’s scale has involved resolving quite a few challenges like, supporting deeply nested and huge thrift schemas, slow/ bad worker detection and remediation, auto-scaling cluster, graceful cluster shutdown and impersonation support for ldap authenticator.
Our infrastructure is built on top of Amazon EC2 and we leverage Amazon S3 for storing our data. This separates compute and storage layers, and allows multiple compute clusters to share the S3 data.
We have hundreds of petabytes of data and tens of thousands of Apache Hive tables. Our Presto clusters are comprised of a fleet of 450 r4.8xl EC2 instances. Presto clusters together have over 100 TBs of memory and 14K vcpu cores. Within Pinterest, we have close to more than 1,000 monthly active users (out of total 1,600+ Pinterest employees) using Presto, who run about 400K queries on these clusters per month.
Each query submitted to Presto cluster is logged to a Kafka topic via Singer. Singer is a logging agent built at Pinterest and we talked about it in a previous post. Each query is logged when it is submitted and when it finishes. When a Presto cluster crashes, we will have query submitted events without corresponding query finished events. These events enable us to capture the effect of cluster crashes over time.
Each Presto cluster at Pinterest has workers on a mix of dedicated AWS EC2 instances and Kubernetes pods. Kubernetes platform provides us with the capability to add and remove workers from a Presto cluster very quickly. The best-case latency on bringing up a new worker on Kubernetes is less than a minute. However, when the Kubernetes cluster itself is out of resources and needs to scale up, it can take up to ten minutes. Some other advantages of deploying on Kubernetes platform is that our Presto deployment becomes agnostic of cloud vendor, instance types, OS, etc.
#BigData #AWS #DataScience #DataEngineering