Private corporate batches, live online cohorts and 1-on-1 mentoring in distributed storage, file layout, batch and streaming architecture, and the economics of scale — 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 Big Data as architecture and cost rather than a product tour: why a shuffle is the expensive operation, how partitioning and file format decide whether a query prunes or scans, when a warehouse beats a lakehouse, and where exactly-once semantics are worth paying for. Sessions position Hadoop, Spark, Kafka, streaming engines and cloud warehouses against each other with the trade-offs made explicit, and every design decision is followed through to what it costs per month at the volumes the team actually runs.
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 Big Data that means a trainer who has run it in production — distributed storage, file layout, batch and streaming architecture, and the economics of scale — 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 Big Data batchBig Data is the engineering problem that begins when a dataset no longer fits the assumptions of a single machine and a single database. The familiar description — volume, velocity, variety, veracity and value — is only useful once it is made concrete: volume means you must decide how bytes are laid out on disk before you can query them affordably, velocity means the data arrives faster than a nightly batch can absorb, and variety means the schema is discovered at read time rather than declared at write time.
The architectural response has been consistent for two decades. Split the data into partitions, store them on many machines, move the computation to the data rather than the reverse, and accept that a coordinated shuffle across the network is the expensive operation everything else is designed to avoid. Hadoop with HDFS and MapReduce was the first widely adopted implementation of that idea; Spark replaced the execution engine; cloud object storage replaced the distributed filesystem; and open table formats such as Delta Lake, Apache Iceberg and Apache Hudi added the transactional guarantees that object storage lacked.
What a Big Data engineer actually decides is therefore narrower and more consequential than the marketing suggests. Which file format and compression codec. How to partition so that queries prune rather than scan. Whether a workload belongs in a warehouse, a lakehouse or a stream processor. Where exactly-once semantics are worth their cost. How to keep small files from destroying performance. And, increasingly, how much every one of those choices costs per month, because in a cloud platform the storage and compute bill is the direct consequence of design decisions made months earlier.
The centre of gravity has moved from on-premise clusters to cloud platforms, and that has changed which skills are scarce. Standing up a Hadoop cluster is no longer the hard part. Deciding what belongs in object storage against a warehouse, when a table format earns its complexity, and how to keep a platform's cost from growing faster than its data is the hard part.
Most organisations are living in the middle of that transition. They have legacy clusters that still run critical jobs, cloud warehouses that grew organically, streaming pipelines added for one urgent use case, and a bill nobody can fully explain. Engineers who understand the underlying mechanics — partitioning, shuffle, file layout, consistency models — can reason across all of it. Engineers who only know one product cannot.
Demand has also broadened beyond dedicated data teams. Platform and DevOps engineers now run the infrastructure these systems sit on; application engineers publish to Kafka and read from lakehouse tables; analytics engineers write transformations whose cost depends entirely on how the underlying data was laid out. Understanding Big Data architecture has become a shared requirement rather than a specialisation.
The characteristics that force a distributed design, made concrete rather than repeated as slogans. Scale-up against scale-out, the CAP and consistency trade-offs that follow from distribution, the batch and streaming split, and an honest look at the very common case where one well-indexed relational database is still the right answer.
Topics: Volume, velocity, variety, veracity and value made concrete · Scale-up vs scale-out and the cost curve of each · Distribution consequences: CAP, consistency and partition tolerance · Schema-on-write vs schema-on-read · OLTP vs OLAP workload characteristics · Batch, micro-batch and streaming · The storage and compute cost model · When a single Postgres instance beats a cluster
The layer that quietly determines every query's cost. Distributed filesystems and cloud object stores and how they differ; columnar against row formats; compression codecs and the split between speed and ratio; and the partitioning, bucketing and file-size decisions that decide whether an engine reads a gigabyte or a terabyte.
Topics: HDFS and cloud object storage compared · Consistency, listing cost and throughput on object stores · Row formats vs columnar: Avro, Parquet and ORC · Compression codecs: Snappy, Zstandard, Gzip and the trade-offs · Column pruning and predicate pushdown · Partitioning strategy and partition explosion · Bucketing and sort order · The small-file problem and compaction · Schema evolution in file formats
How the engines actually execute. MapReduce as the original model, DAG engines that replaced it, MPP warehouses and vectorised query engines. Then the concept that governs performance everywhere — the shuffle — plus data locality, skew and the reason a single hot key can dominate a job's runtime.
Topics: MapReduce: the model and its limits · DAG execution engines and in-memory processing · MPP warehouses and vectorised query engines · Hadoop, YARN and Spark positioned against each other · Shuffle: what it costs and why it dominates · Data locality and network as the bottleneck · Partitioning and parallelism in execution · Skew and the hot-key problem · Choosing an engine per workload class
Getting data in reliably. Batch and incremental loading patterns, log-based streaming with Kafka, stream processing semantics — event time against processing time, watermarks, windows, exactly-once — and change data capture from operational databases without hammering them.
Topics: Batch, incremental and full-refresh loading patterns · Kafka: topics, partitions, offsets, consumer groups · Retention, compaction and replay · Stream processing engines and their models · Event time vs processing time · Watermarks, late data and windowing · Delivery semantics: at-least-once vs exactly-once and their cost · Change data capture from relational sources · Backpressure, ordering and idempotent sinks
The architectural choice most teams get wrong first. What a data lake gives you and what it costs in governance; what a warehouse gives you and what it costs in flexibility; and what open table formats added to object storage to close the gap — ACID transactions, time travel, schema enforcement and efficient upserts.
Topics: Data lake, data warehouse and lakehouse defined precisely · Why raw object storage lacks transactions · Delta Lake, Apache Iceberg and Apache Hudi compared · ACID on object storage, time travel and snapshots · MERGE, upserts and deletes for compliance · Table maintenance: compaction, clustering, vacuum · Cloud warehouses: Snowflake, BigQuery, Redshift, Synapse · Hive metastore and modern catalogues · Query engines: Trino and Presto over the lake · Medallion and layered architectures
Making the data usable once it is stored. Dimensional modelling and where denormalisation is correct, slowly changing dimensions, aggregate and rollup tables, and the serving-layer choice — low-latency OLAP stores, wide-column stores and document stores each fit different access patterns.
Topics: Star and snowflake schemas at scale · Denormalisation and why it is right here · Slowly changing dimensions and history · Aggregate, rollup and materialised tables · Incremental models and idempotent rebuilds · Low-latency OLAP: ClickHouse and Druid · Wide-column and key-value stores: HBase and Cassandra · Document stores and access-pattern-first modelling · Choosing a serving layer per consumer
The operational half. Capacity planning and cost control, autoscaling and spot capacity, workload isolation and queues, the full security stack from authentication to masking, catalogue and lineage, monitoring and SLAs, and the migration path from an on-premise cluster to a cloud platform.
Topics: Capacity planning and cluster sizing · Cost control: storage tiers, compute isolation, spot and autoscaling · Workload isolation, queues and noisy neighbours · Authentication: Kerberos and cloud identity · Authorisation, row and column level policies · Encryption at rest and in transit, masking and tokenisation · Catalogue, classification and lineage · Monitoring, SLAs and data freshness alerting · Disaster recovery and cross-region strategy · Migrating from on-premise Hadoop to cloud
We rebuild the agenda around the tools you actually run.
Request a custom agendaTake a CSV dataset and a set of real queries, then convert to partitioned columnar storage with the right compression and prove the scan reduction.
Profile a distributed join that runs for hours because of one skewed key, then fix it and account for the runtime change stage by stage.
Build a Kafka ingestion path with idempotent sinks, then replay from an offset and prove the destination is identical rather than duplicated.
Convert a lake table to an open table format, run concurrent writers, perform a MERGE for a deletion request, and time travel to prove history.
Model a fact table with slowly changing dimensions, add rollups, load a low-latency OLAP store and hit a stated dashboard latency target.
Deliver ingestion, storage layout, processing, lakehouse layers, serving, governance and a cost model for one real workload, with every choice justified.
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
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.
Got good lab sessions which kept the new DevOps tool learnings to the point and it helped a lot in my career.
| 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.