Apache Hive vs CDAP: 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, CDAP is detailed as "Open source virtualization platform for Hadoop data and apps". Cask Data Application Platform (CDAP) is an open source application development platform for the Hadoop ecosystem that provides developers with data and application virtualization to accelerate application development, address a broader range of real-time and batch use cases, and deploy applications into production while satisfying enterprise requirements.
Apache Hive and CDAP belong to "Big Data Tools" category of the tech stack.
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, CDAP provides the following key features:
- Streams for data ingestion
- Reusable libraries for common Big Data access patterns
- Data available to multiple applications and different paradigms
Apache Hive and CDAP are both open source tools. Apache Hive with 2.62K GitHub stars and 2.58K forks on GitHub appears to be more popular than CDAP with 346 GitHub stars and 178 GitHub forks.
What is Apache Hive?
What is CDAP?
Need advice about which tool to choose?Ask the StackShare community!
Why do developers choose Apache Hive?
Why do developers choose CDAP?
What are the cons of using Apache Hive?
What are the cons of using CDAP?
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