Contributed by @SriramGopal from Agilisium Consulting
The pipeline is designed to fetch records on an incremental basis from document-oriented NoSQL database system (Mongo in this case) and load to cloud storage (Amazon S3) with partitioning logic. This use case is applicable to Cloud Data Lake initiatives.
This pipeline also includes, the Date based Data Partitioning at the Storage layer and Data Validation trail between source and target.
S3 Writer Child Pipeline
Audit Update Child Pipeline
Control Table - Tracking
The Control table is designed in such a way that it holds the source load type (RDBMS, FTP, API etc.) and the corresponding object name. Each object load will have the load start/end times and the records/ documents processed for every load. The source record fetch count and target table load count is calculated for every run. Based on the status (S-success or F-failure) of the load, automated notifications can be triggered to the technical team.
Control Table Attributes:
- UID – Primary key
- SOURCE_TYPE – Type of Source RDBMS, API, Social Media, FTP etc
- TABLE_NAME – Table name or object name.
- START_DATE – Load start time
- ENDDATE – Load end time
- SRC_REC_COUNT – Source record count
- RGT_REC_COUNT – Target record count
- STATUS – ‘S’ Success and ‘F’ Failed based on the source/ target load
For every load, the data gets partitioned automatically based on the transaction timestamp in the storage layer (S3)
Sources : NoSQL Database, MongoDB Table
Targets : AWS Storage
Snaps used :
- Parent Pipeline: MongoDB - Find, Sort, File Writer, Mapper, Router, Copy, JSON Formatter, Redshift Insert, Redshift Select, Redshift - Multi Execute, S3 File Writer, S3 File Reader, Aggregate, Pipeline Execute
- S3 Writer Child Pipeline: Mapper, JSON Formatter, S3 File Writer
- Audit Update Child Pipeline: File Reader, JSON Parser, Mapper, Router, Aggregate, Redshift - Multi Execute