Rahim Mahat
Senior Data Engineer · 4+ yrs · Pune, India · remote worldwide
rahimmahat07@gmail.com · github.com/RahimMahat · www.linkedin.com/in/rahim-mahat/
Summary
I build the pipelines other people's dashboards quietly depend on. Four years of it, all at Infocepts — Glue and PySpark on AWS, Terraform underneath, and enough production incidents to have opinions about error handling. Given the choice I take the unglamorous work: the job that runs at 3am and nobody thinks about, because that is the one that has to be right. Lately I have been pointing the same instincts at applied AI, where the interesting problem is still data movement — just with a more expensive consumer at the end of the pipe.
Experience
Senior Data Engineer, Infocepts
Apr 2024 – present (2y 6m) · Pune, India
Own the ingestion and transformation layers end to end — architecture, the Terraform underneath them, and the pager when they break. Most of the work is event-driven: ingestion that has to stay available while upstream systems do not.
Data Engineer, Infocepts
Aug 2022 – Apr 2024 (1y 8m) · Nagpur, India
Built the first version of the platform the senior role now maintains: Glue and S3 into Redshift, real-time paths on Lambda and SQS, CI on GitHub Actions and Jenkins. This is where I learned that tuning a query is easy and tuning the thing that calls the query is not.
Assistant Analyst, Infocepts
Feb 2022 – Aug 2022 (6m) · Nagpur, India
First exposure to cloud data work: AWS, GCP and dbt, mostly reading other people's pipelines and automating the repetitive parts in Python.
Projects
The landing zone
paid work at Infocepts · AWS Glue, PySpark, AWS Lambda, Amazon SQS, API Gateway, Amazon S3, Jenkins
The ingestion layer of a multi-source AWS platform: Glue and PySpark for batch, and one contract every source meets before anything downstream reads it.
- scale
- Several upstream systems on one contract — batch through Glue, and the platform's first event path behind the same landing zone
- outcome
- 50% lower end-to-end processing time than the pipeline it replaced
Warehouse and serving layer
paid work at Infocepts · Amazon Redshift, Amazon S3, Denodo, Amazon QuickSight, SQL
The serving layer — Redshift models, a Denodo virtualization tier, and the QuickSight dashboards the business actually opens on a Monday morning.
- scale
- One modelled Redshift layer behind a virtualization tier, serving every BI consumer
- outcome
- 35% faster query execution after performance tuning
Retail point-of-sale ETL
paid work at Infocepts · AWS Glue, PySpark, Amazon Redshift, Amazon S3, Python, SQL, pytest
Twenty-nine Glue processors that turn fourteen retail partners' sales and inventory files into one Redshift star schema, a feed at a time.
- scale
- 29 processors (13 dimension, 16 fact) across 14 retail partner feeds, each with its own unit tests
- outcome
- A new retailer is a processor, a config entry and a test file, not a new pipeline
SAP object onboarding
paid work at Infocepts · AWS AppFlow, AWS Glue, Python, pandas, Amazon S3, Parquet, Terraform, AWS CDK, Amazon Athena
Ninety SAP services taken from "it exists in SAP" to "it is a partitioned table in Athena", through a fleet of 400+ AppFlow flows and a parameterised Glue job.
- scale
- 90 SAP objects onboarded and 140+ source-to-lake mappings added, in a fleet of 400+ flows on schedules from every twenty minutes to weekly
- outcome
- Delta-enabled feeds moved from one extraction a day to one an hour, with hour-level partitions to match
Infrastructure as code
paid work at Infocepts · Terraform, AWS CDK, Jenkins, GitHub Actions, Python
Terraform and AWS CDK modules that moved environment setup out of the console and into reviewed pull requests.
- scale
- Every environment defined in code — no console-assembled infrastructure left
- outcome
- 40% less manual effort per deployment
The data catalog as code
paid work at Infocepts · Terraform, AWS Glue Data Catalog, Amazon Athena, Amazon S3, Parquet, HCL
More than 150 partitioned Glue catalog tables and 5,000 columns declared in Terraform, a third of the platform's catalog.
- scale
- 154 tables and 5,000+ columns across 12 SAP functional areas; 166 Terraform modules in all, the most of any contributor
- outcome
- A table is reviewable in a pull request before it exists, and identical in every environment after
Supply-planning ingestion
paid work at Infocepts · AWS Glue, Python, pandas, pandera, Terraform, Amazon S3, Parquet, Amazon Athena
Ten scheduled Glue jobs that check planning-system extracts against a declared schema and land them as partitioned tables.
- scale
- 10 Glue jobs with catalog tables, on daily, weekday and weekly schedules, in a family of 32
- outcome
- A file that cannot be processed fails the run and names itself
Analytics event API
paid work at Infocepts · Amazon API Gateway, AWS Lambda, Amazon SQS, AWS CDK, AWS Glue, Python, Amazon S3, OpenAPI, Terraform
A REST endpoint, a queue, two Lambdas and a Glue job that take usage events from client applications to a partitioned table, built alone in three phases.
- scale
- One API, two queues, two Lambda functions and a daily Glue job, consuming batches of up to 1,000 messages per invocation
- outcome
- Three phases shipped in under four months, from first endpoint to queryable table
Flow operations utility
paid work at Infocepts · AWS Lambda, AWS AppFlow, Python, boto3, Amazon SNS, AWS CDK, pytest
A Lambda that suspends, reactivates, reschedules and reports on a fleet of more than 400 AppFlow flows, so nobody does it one flow at a time in the console.
- scale
- Four modes over a fleet of 400+ flows, selected by criteria, covered by 33 unit tests
- outcome
- A bulk suspend or reactivate is one invocation with a filter
Daily snapshots
paid work at Infocepts · Amazon Athena, SQL, Jinja, AWS Step Functions, AWS Lambda, Amazon S3, Parquet, Terraform
Nine Athena queries that turn change-record tables into one current row per key, once a day, as partitioned Parquet.
- scale
- 9 snapshot tables, deployed to two environments, on the platform's existing query runner
- outcome
- A consumer reads one day's de-duplicated partition in place of the full change history
WarehouseGPT
independent · LangGraph, dbt, DuckDB, PySpark, Delta Lake, LiteLLM, sqlglot, LanceDB, FastAPI, OpenTelemetry, Python
A text-to-SQL agent, and an ablation suite built to measure why agents like it fail. Context took the smallest model from 63.5% to 98.0%.
- scale
- Nine source tables and about 1.5M rows — 99,441 orders, 96,096 customers, 3,095 sellers — into a seven-table star schema behind 17 governed metrics, 31 Spark data-quality checks and 49 dbt tests, on a $0 budget
- outcome
- Execution accuracy on 52 answerable golden questions, with 6 must-refuse ones scored separately: 63.5% on raw DDL, 98.0% (50/51) on the full context. Documentation alone was worth 10–19 points, and with everything switched on the smallest model beat both larger ones running on docs alone
Leakproof
independent · LightGBM, Redpanda, Redis, DuckDB, FastAPI, Streamlit, Docker, Python
The same fraud model built carelessly and point-in-time correct, then both scored on live stream features. The careless one lost half its PR-AUC.
- scale
- The last 15% of transactions by time — 88,581 rows over 30.8 days — replayed through Redpanda and Redis, where all 14 streamed features matched the offline ones on every row, largest difference 1.8e-12
- outcome
- POST /score at p50 2.8 ms, p95 4.3 ms, p99 5.9 ms, down from 121 ms. The careless model fell from 0.999 to 0.901 ROC-AUC and from 0.986 to 0.513 PR-AUC between offline and live; the honest one went from 0.954 to 0.947 ROC-AUC and from 0.695 to 0.665 PR-AUC
Lossproof
independent · PostgreSQL, Debezium, Apache Kafka, Apache Iceberg, Terraform, AWS Step Functions, AWS Lambda, dbt, Amazon Athena, AWS Glue, Amazon S3, Python
The same CDC pipeline built carelessly and correctly, then faulted. With every fault in one run, 69% of the careless lake was wrong. The correct one matched.
- scale
- 100,000 source transactions and about 320,000 messages through one stream into two lakes, then every source row compared with every lake row by key: 53,785 of 77,962 wrong for the careless consumer, 0 of 77,962 for the correct one
- outcome
- A nightly Step Functions run compacts each table from 15 data files to one, reconciles 8,229 rows to zero differences, then builds 7 dbt models and 10 tests — and fails on LakeDiverged before building a single mart if one row disagrees
Nightshift
independent · AWS CDK, AWS Lambda, Amazon SQS, Amazon S3, Amazon API Gateway, AWS Glue Data Catalog, Amazon Athena, Amazon CloudWatch, Parquet, MCP, Docker, Python
A receipt-extraction lake with an LLM as an ETL step and an agent on call, both measured. A 101-line script fixed 15 of 16 incidents. The agent fixed 11.
- scale
- 100 receipts from the CORD test split for each of three models, scored against the dataset's labels, then 16 injected incidents handled by four responders through one policy layer, each judged by a reconciler that compares the lake with a fault-free run
- outcome
- Contracts and a repair loop removed 36% to 66% of wrong values for 24% to 35% more tokens, and 24% on a held-out split. On call, the scripted runbook got 15 of 16 right in a median 9 s; the agent got 11 in 37 s, and 9 without the runbook as text
Skills
- ingestion
- AWS Glue (PySpark ETL jobs, batch side), Lambda + SQS (event-driven, stream side), API Gateway (token-authenticated integrations)
- transformation
- PySpark, dbt, SQL (Redshift), Python (the glue between all of it)
- orchestration
- Jenkins (pipeline scheduling and CI), GitHub Actions (build and deploy)
- storage
- Amazon Redshift, Amazon S3 (landing and curated zones), Denodo (virtualization over the warehouse)
- platform
- AWS (Solutions Architect Associate, in progress), Terraform + CDK (reusable modules, reviewed in PRs), Linux + Bash, Containers
- bi
- QuickSight (business stakeholders, not engineers)