Private corporate batches, live online cohorts and 1-on-1 mentoring in HDFS, YARN and MapReduce internals, the Hive and HBase ecosystem, and cluster operations — taught by a practitioner who runs it in production.
20 years across DevOps, SRE and Security · 10,000+ engineers trained · Trained teams at JPMorgan Chase, Verizon, Nokia and the World Bank
Principal DevOps Engineer & Architect
Rajesh teaches Hadoop at the level of the daemons rather than the demo: NameNode metadata, fsimage and edits, block placement and rack awareness, high availability with JournalNodes and ZooKeeper failover, and YARN scheduling with capacity and fair queues. Sessions run against a real multi-node cluster and cover the operational work that decides whether an estate stays healthy — balancing, commissioning and decommissioning, Kerberos and keytabs, rolling upgrades, distcp for disaster recovery, and reading a Hive query plan that has gone wrong.
Twenty years across DevOps, SRE and Security, in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe and others. He has trained engineers at JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus — more than 10,000 people personally. He teaches what he runs, not what he reads.
You are booked with a named engineer, and that is who turns up. Marketplaces and larger providers rotate whoever is free, so the person who sold you the agenda is rarely the person teaching it.
The same trainer is available for the next engagement, which matters when a team builds on what it learned last time.
Your batch is assigned a named trainer before it starts, and that is who teaches it. See the full faculty.
Engagements are matched on the tool, not the calendar. For Hadoop that means a trainer who has run it in production — HDFS, YARN and MapReduce internals, the Hive and HBase ecosystem, and cluster operations — rather than whoever is free that week. You are told who is teaching before you commit, and that person is on the discovery call that shapes the agenda.
Where a batch is large enough to need a second trainer, the pairing is declared up front. The lead trainer stays accountable for the syllabus and the assessment either way.
Principal DevOps Engineer & Architect
Twenty years across DevOps, SRE and Security in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe, IBM/Emptoris, Ness, MindTree and Accenture. He has trained more than 10,000 engineers personally, at organisations including JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus. He teaches what he runs, not what he reads.
Teams of 8–30
Custom agenda, your timezone, onsite or online, NDA-friendly.
Request a quoteIndividual engineers
A private instructor and a curriculum built around your goal.
₹99,999Individuals who want peers
Scheduled batch, max 8 to 10 hours of live instruction.
₹34,999A private batch starts with a discovery call. We look at the stack you actually run — the CI system, the cloud, the constraints — and map the agenda onto it, so examples use your topology rather than a generic one.
Delivery is onsite at your premises, live online, or hybrid, scheduled around your release calendar rather than ours. Batches run 8 to 30 engineers.
Every attendee leaves with recordings, slides, lab repositories and a completion certificate. You receive an attendance and assessment report. Invoicing supports PO and GST.
Talk to us about a private Hadoop batchHadoop is an open-source framework for storing and processing data across a cluster of commodity machines. It has three core pieces. HDFS is a distributed filesystem that splits every file into large blocks, replicates each block across several nodes, and keeps all the metadata in a single NameNode process while the DataNodes hold the bytes. YARN is the cluster resource manager that decides which application gets which containers on which nodes. MapReduce is the original processing framework built on top of both, expressing computation as a map phase, a shuffle and sort, and a reduce phase.
The design assumption behind all of it is that moving computation to data is cheaper than moving data to computation, and that hardware fails routinely. Blocks are replicated three times by default and placed with rack awareness so a rack failure does not lose data. Tasks that fail are retried elsewhere; tasks that run slowly are duplicated speculatively. That fault tolerance is why Hadoop could run on cheap machines, and it is also why its latency characteristics are what they are.
Around the core sits the ecosystem that most Hadoop work actually uses: Hive for SQL over files with a metastore, partitions, buckets and columnar formats; HBase for random read and write access on top of HDFS; Sqoop and Flume or Kafka for ingestion; Oozie for workflow; ZooKeeper for coordination and high availability; and Spark, which now runs most of the processing that MapReduce originally handled while still using YARN and HDFS underneath. Operating a Hadoop cluster means understanding NameNode high availability, scheduler queues, Kerberos authentication and the maintenance work — balancing, decommissioning, upgrades — that keeps a multi-node estate healthy.
Hadoop is no longer the platform teams start on, but it is very much the platform they still run. Large estates in banking, telecom, retail and government hold years of data and thousands of scheduled jobs on HDFS and YARN, and those systems have to keep working while a migration is planned around them.
That creates a specific and well-paid kind of demand. Someone has to keep the NameNode healthy, keep the scheduler queues fair, keep Kerberos working, diagnose why a Hive query that ran in nine minutes now runs in ninety, and safely decommission nodes. At the same time, someone has to decide what each legacy job becomes on the target platform — which is impossible without understanding what the job depends on today.
The concepts also transfer directly. Blocks, replication, partitioning, the shuffle, resource queues and data locality are the vocabulary of every distributed engine that followed, and Spark, Hive and modern lakehouse formats still carry Hadoop's design decisions in their behaviour. Engineers who learned only a managed cloud service often cannot explain why a job is slow; engineers who understand the Hadoop layer usually can.
What Hadoop is made of and how a real cluster is arranged. The problem it was designed for, every daemon and its role, master and worker node layout, deployment modes from standalone to fully distributed, and the configuration files that everything else in the course modifies.
Topics: The problem Hadoop was built to solve · Core components: HDFS, YARN, MapReduce, Hadoop Common · Daemons and their responsibilities · Master and worker node layout, and edge nodes · Standalone, pseudo-distributed and fully distributed modes · core-site, hdfs-site, yarn-site and mapred-site · Configuration precedence and per-job overrides · Distributions, versions and what changed in Hadoop 3 · Sizing a cluster for a stated workload
The filesystem in detail. NameNode metadata in memory and on disk, DataNode block storage, the read and write pipelines, rack awareness and replica placement, then high availability, federation, and the command-line tools used to run it every day.
Topics: NameNode metadata, fsimage and edit logs · Checkpointing and the Secondary NameNode's real job · DataNodes, blocks, block size and replication factor · Rack awareness and replica placement policy · The write pipeline and the read path · NameNode HA with JournalNodes and ZooKeeper failover · HDFS federation and multiple namespaces · Quotas, snapshots and trash · hdfs dfs, fsck, dfsadmin and the balancer · Erasure coding as an alternative to replication
How the cluster decides who gets to run. ResourceManager, NodeManager, ApplicationMaster and containers; the application submission lifecycle; capacity and fair scheduling with queues, ACLs and preemption; and diagnosing the two most common complaints — my job is stuck, and my job is slow.
Topics: ResourceManager, NodeManager and ApplicationMaster roles · Containers, vcores and memory allocation · The application submission and execution lifecycle · Capacity Scheduler: queues, capacities and elasticity · Fair Scheduler and pools · Queue ACLs, preemption and priorities · ResourceManager high availability · Node labels and heterogeneous hardware · Log aggregation and reading container logs · Diagnosing starved, stuck and slow applications
The original processing framework, taught because its mechanics explain every engine that followed. Mapper, reducer, combiner and partitioner; input formats and record readers; the shuffle and sort phase where the time actually goes; counters, speculative execution, and joins. Then an honest account of why Spark replaced it for most work.
Topics: The map, shuffle, reduce model · Mappers, reducers, combiners and partitioners · InputFormat, RecordReader and split calculation · The shuffle and sort phase in detail · Counters and job instrumentation · Speculative execution and stragglers · Map-side and reduce-side joins · Distributed cache and side data · Tuning: memory, spills, sort buffer and compression · Why Spark replaced MapReduce for most workloads
How most Hadoop data is actually queried. The metastore and what it stores, managed against external tables, partitioning and bucketing, columnar formats and compression, execution engines, and the design choices that decide whether a query prunes partitions or scans the whole table.
Topics: Hive architecture and the metastore · Managed vs external tables and what DROP means for each · Partitioning, dynamic partitions and partition pruning · Bucketing and sorted buckets for joins · File formats: text, Avro, Parquet and ORC · Compression and predicate pushdown · Execution on MapReduce vs Tez, and vectorisation · Joins: map join, bucket map join and skew join · ACID tables, transactions and compaction · HiveServer2, Beeline and JDBC access · Reading and acting on an EXPLAIN plan · Impala and Presto positioned against Hive
The components that surround HDFS and YARN in a working estate. HBase for low-latency random access, Sqoop for relational ingestion, Flume and Kafka for streams, Oozie for workflow, ZooKeeper for coordination, and Spark running on the same cluster.
Topics: HBase architecture: regions, RegionServers, HFiles, WAL · HBase schema and row-key design for access patterns · When HBase is right and when it is not · Sqoop imports, exports and incremental loads · Flume and Kafka ingestion into HDFS · Oozie workflows, coordinators and bundles · ZooKeeper's role in coordination and HA · Spark on YARN alongside existing workloads · Pig and legacy pipeline maintenance
Running the cluster like production. Kerberos authentication and keytabs, delegation tokens, authorisation policies, encryption at rest and in transit, then the ongoing operational work — commissioning and decommissioning, rolling upgrades, backup and disaster recovery, capacity review — and finally how to plan a move to a cloud platform.
Topics: Kerberos authentication, principals and keytabs · Delegation tokens and long-running jobs · Authorisation with Ranger or Sentry policies · HDFS encryption zones and the key management server · Wire encryption and secure RPC · Commissioning and decommissioning nodes safely · Rolling upgrades and version compatibility · Backup and disaster recovery with distcp · Monitoring, alerting and capacity review · Cost and utilisation analysis of an existing cluster · Planning a migration to cloud storage and engines
We rebuild the agenda around the tools you actually run.
Request a custom agendaLoad data at a chosen block size and replication factor, kill a DataNode mid-write, and trace re-replication and recovery through fsck and the NameNode UI.
Configure JournalNodes and ZooKeeper failover controllers, then fail the active NameNode while jobs are running and confirm nothing is lost.
Configure capacity queues with ACLs and preemption so a heavy batch job cannot starve interactive queries, then prove it under simultaneous load.
Take a text-format table queried daily, rebuild it as partitioned bucketed ORC, and demonstrate the plan change and the runtime difference.
Enable Kerberos end to end, create principals and keytabs, apply authorisation policies, and run a job as a restricted user without disabling security to make it work.
Take a cluster through node decommissioning, a rolling upgrade, a rebalance and a distcp disaster-recovery copy while scheduled jobs keep running.
Billed yearly at ₹9,996
Max 8 to 10 hours of live instruction
Full program, private instructor
8–30 engineers · custom agenda · onsite or online · PO and GST invoicing
Refunds. If we cancel or postpone a cohort, you get a full refund within 15 days. There is no money-back guarantee otherwise.
Terms. Course material remains licensed to the attendee. Read the terms.
Your data. We don't share it with third parties. Privacy policy.
Certificate of completion
Rajesh is a very good trainer I have experienced in DevSecOps training. The number of contents in different topics he has posted on the DevOpsSchool public website are amazing and user friendly for beginners and experienced professionals.
The trainer (Rajesh) provided very good sessions on SRE profession. Not only hands-on learning on the tools but also SRE mindset.
Very good training session. Well explained from the basics to the complex concepts. Also tried to cover practicals and demos within the 3 hour sessions. The learning content and videos are of a great deal of help.
Basics explanation was exemplary from Rajesh where he dealt with complicated topics to be simple. Great learning stuff personally for me.
Very detailed explanation and has lots of patience in attending the questionnaire. Thanks again for your wonderful sessions.
Good discussion, helped us to understand different tools in SRE.
| What matters | YouTube + blogs | Generic online course | Freelance marketplace | DevOpsSchool |
|---|---|---|---|---|
| Named practitioner | No | Rarely | Varies per booking | Yes — same trainer each time |
| Production experience | Unknown | Unknown | Unverified | 20 years, named employers |
| Custom agenda | No | No | Sometimes | Built from your stack |
| Onsite delivery | No | No | Sometimes | Yes |
| Lab environment | None | Sandbox that expires | Varies | Your own cloud — skill goes with you |
| Assessment | None | Quiz | Rarely | Assignments + capstone per module |
| Per-attendee certificates | No | Sometimes | Rarely | Yes |
| Corporate invoicing | No | Limited | Varies | PO and GST |
| Post-training support | None | Forum, time-limited | None | Lifetime forum access |
Tell us the team, the stack and the timeline. You'll get a straight answer, not a sales sequence.
Talk to an advisorPrefer to call or email?
More ways to reach us on the contact page.