100% Free Forever
AI-Powered Learning
Industry Expert Content
Certificates & Badges
Learn At Your Own Pace
Programming

Pig Basics

An introduction to Apache Pig's procedural data-flow language, Pig Latin, its execution model, and how it compares to Hive.

Ecosystem ToolsBeginner8 min readJul 10, 2026
Analogies

What Is Pig?

Apache Pig is a data-flow scripting platform for Hadoop built around Pig Latin, a language that expresses a computation as a sequence of transformation steps, LOAD, FILTER, GROUP, JOIN, rather than a single declarative SQL statement, which makes it a natural fit for multi-step ETL pipelines where each intermediate result matters. Under the hood, the Pig engine parses a script into a logical plan, optimizes it into a physical plan, and compiles that into a series of MapReduce or Tez jobs, so a Pig user reasons about data flow explicitly instead of relying on Hive's query optimizer to infer the right join order.

🏏

Cricket analogy: Pig Latin is like a coach scripting a training session step by step, warm-up laps, then net bowling, then fielding drills, rather than handing the team a single outcome goal like Hive's declarative SQL and trusting them to sequence it themselves.

Pig Latin: Relations and Operators

A typical Pig Latin script starts with a LOAD statement that reads data into a relation with an inferred or declared schema, then chains FOREACH...GENERATE to project and transform fields, FILTER to drop rows by a boolean condition, GROUP to bucket rows by a key (producing a relation of key plus a nested bag of matching records), and JOIN to combine two relations, with the final result written out via STORE; because each step produces a named intermediate relation, a developer can DUMP any of them to inspect data mid-pipeline, which makes debugging a long ETL chain considerably easier than debugging a single monolithic SQL query.

🏏

Cricket analogy: Naming each intermediate relation is like a scoring app that lets you inspect the tally after every single over, not just the final scorecard, so a coach can catch a scoring error at over 14 instead of only seeing a wrong final total.

pig
logs      = LOAD 's3://analytics-bucket/web_logs/' USING PigStorage(',')
              AS (user_id:chararray, event_type:chararray, event_ts:long);
clicks    = FILTER logs BY event_type == 'click';
grouped   = GROUP clicks BY user_id;
counted   = FOREACH grouped GENERATE
              group AS user_id,
              COUNT(clicks) AS click_count;
top_users = ORDER counted BY click_count DESC;
STORE top_users INTO 's3://analytics-bucket/top_clickers/' USING PigStorage(',');

Execution Modes and the Pig Engine

Pig scripts can run in local mode, where all processing happens on a single machine against the local filesystem, useful for quick testing on a small sample, or in mapreduce mode (the default), where the Grunt shell submits compiled jobs to a live YARN cluster against HDFS data; the pig -x local flag switches modes without changing a single line of the actual Pig Latin script, since the language itself is execution-environment agnostic and only the runtime target changes.

🏏

Cricket analogy: Like a batter rehearsing shot selection in the nets on a local practice pitch before facing the same bowling plan out in an actual World Cup match, the shot technique itself doesn't change, only the venue and stakes do.

The Grunt shell's DUMP command is invaluable while developing a script, but never leave a DUMP on a full-size relation in a production script: it forces materialization and console output of potentially billions of rows, which will hang the client and flood logs.

UDFs and Extending Pig

When Pig Latin's built-in operators aren't enough, developers write User Defined Functions (UDFs) in Java, Python, or JavaScript, register them with REGISTER, and call them like any other function inside FOREACH...GENERATE, and Piggybank, Pig's own contributed function library, ships prebuilt UDFs for common tasks like string manipulation and date parsing so teams don't need to reinvent them; however, Pig's popularity has declined substantially since the mid-2010s as Spark's DataFrame API absorbed most of the same data-flow use cases with better performance and a single unified engine, so most Hadoop shops today maintain legacy Pig scripts rather than writing new ones.

🏏

Cricket analogy: A custom UDF is like a specialist analytics consultant a franchise brings in to compute a bespoke metric, say a pressure-adjusted strike rate, that the standard scorecard software doesn't calculate out of the box.

Pig is largely a legacy technology in modern Hadoop deployments; while understanding Pig Latin is useful for maintaining older ETL pipelines, new data-flow pipelines are typically written in Spark's DataFrame or Dataset API, which offers comparable expressiveness with better performance and a single unified execution engine.

  • Pig Latin is a procedural, step-by-step data-flow language, in contrast to Hive's declarative SQL-like HiveQL.
  • A Pig script compiles through a logical plan and physical plan into MapReduce or Tez jobs.
  • Core operators include LOAD, FOREACH...GENERATE, FILTER, GROUP, JOIN, and STORE.
  • Named intermediate relations can be inspected with DUMP mid-pipeline, aiding debugging of long ETL chains.
  • The pig -x local flag runs a script against the local filesystem for fast iteration before running on a real cluster.
  • UDFs written in Java, Python, or JavaScript extend Pig Latin's built-in operator set; Piggybank ships common prebuilt ones.
  • Pig's popularity has declined significantly as Spark's DataFrame API absorbed most of its use cases with better performance.

Practice what you learned

Was this page helpful?

Topics covered

#Programming#HadoopStudyNotes#PigBasics#Pig#Latin#Relations#Operators#StudyNotes#SkillVeris#ExamPrep