The process of fetching data from multiple sources and combining it to achieve a single “unified view” is termed DI. The Data we mention here is “Big Data,” which is very complex and rapidly growing. So handling this data with traditional approaches becomes impossible with time.
Although we can’t have a single pattern for such complex data to solve the problem, the very first key step to any DI technique is “Data Ingestion.” Data Ingestion is collecting data from various sources and moving it for further analysis (ETL).
Why Data Integration?
It solves the problem of Data Silos and gives us a unified view of whole data, providing structured and accurate insight. Which can be very useful to grow business.
Barriers to Successful DI:
Slow or no adaptation to new technologies.
Having the poor quality of data.
Unwanted Access to data.
As Data Integration is a very useful tool, It is essential to have a standardized method for developing such tools.
Data Integration Pattern is a standardized method for integrating data. DIP helps to standardize the overall process of it. So, our goal here is to provide the patterns of the standardized approaches for it.
DIP can be categorized into five types:
Data Migration Pattern
The Broadcast Pattern
Figure 1.1 Various Data Integration Patterns
Why it is required?
Gone are those days when we could just use traditional methods to integrate data. As we are entering the new era of data, we need evolving tools to cope up with high technological innovations. Therefore we develop data patterns to keep us updated in the field of Data Integration. Developing its patterns for various types of data provided by data sources and acceptable to various destinations can be helpful in the following ways:
Time-Saving: A lot of time is saved, and a lot of efforts are reduced with the use of DIP as we develop an integration pattern for particular situations.
Reduces Errors: Errors are reduced, as we will not be integrating data manually. Rather it would be a standardized pattern that is most of the time based on a one-click application.
Better Business Decisions: Using DIP can be very helpful in business growth, as one can see the whole data at a place or Unified View. Data can also be synchronized between various departments using DIP.
Adaptability: DIP makes sure our systems are adaptable to new technologies coming up. As we define DIP on our system, it provides us with a standardized method of integration, which takes care of new tools coming up in that pattern.
Reusability: DIP provides an approach to integrating data, which can be reused on a one-click application basis.
Reliability: DIP makes sure that data integration is reliable. While transferring data, we face a data pattern mismatch problem, which DIP uses a unified approach in DI.
Better Communication: Communication between various departments can be improved with the help of DIP as it removes data silos problems.
What is Data Redundancy?
All the companies are using multiple applications within, and there we need any method to sync the data between different applications. Otherwise, we would get into the problem of data redundancy and data Silos. Redundancy is saving the same data at multiple places. But in some cases having redundant data is also helpful. For instance, We cannot run queries on big data and instead, we just run queries on operational data. For this purpose, replicas of data can be helpful in some cases. But one needs to be very careful while making these replicas. E.g., if we create a DB for the sales dept and save customer address here and another DB for marketing dept where the replica of that address is saved. So updating the address in one dept should also reflect in another database.
Data Integration Patterns can be broadly divided into five ways, classification of each its patterns is described below:
Data Migration Pattern
Data Migration is Migrating data from one system to another. A scenario where data migration pattern can be implemented is:
Figure 2.1 Data Migration Pattern
If any changes happen in the job portal database, it should be reflected in the HR & Recruitment application.
Steps To Develop a Data Migration Pattern:
Define the source of data.
The frequency at which you want to migrate data, which can be real-time or scheduled.
Define criteria for the data to be sent. For instance, in our case, say the students who applied before Monday should reflect in the recruitment DB.
They are making Data more enriched and transforming data into the desired format.
Finally, show the status of the migration.
The broadcast pattern can be defined as a near real-time sync approach where we send data from the source system to one or many destinations. Only that data is sent, which has been changed since the last broadcast happened.
Figure 2.2 Data Broadcast Pattern
If any student applies for a new job, those changes should reflect in all the connected systems, which should happen in real-time. But there is no notification sent back to the source that the data has been received or not. So there can be a risk of data loss if the pattern is not working correctly.
Key Cases one need to keep in mind while creating a Broadcast pattern
Case1: Source System can send the notification, including the actual data.
Case2: Source System can send only the notification without actual data, and the broadcast pattern will fetch data from it.
Case3: Broadcast pattern or the layer will check the source system for any changes in job portal DB.
In Bi-directional Sync, we want to create a pattern that will make 2 systems work together to achieve a single business goal.
Example scenario: Suppose we have 2 apps, the student data collecting app and the Analysis app. We want these 2 apps to work together.
The job portal app collects all the student data and sends it to the Analytics app, and the Analytics app takes its time in analysis and sends back a report to the job portal. So here, the Job portal used the functionality of analysis without having such a system developed on its own.
This pattern is almost similar to bi-directional sync, but sync happens whenever there is a requirement of having similar data in another system.
Example scenario: suppose we have 2 offices, office A and office B. Now an Employee has to be transferred from officeA to officeB. In this case, we are not going to enter employees’ information into office B manually. Instead, we will use the correlation pattern to transfer employee data from office A to office B.
Aggregation is the process of collecting data at one place and giving a unified view to the whole data for analysis and other applications. Points to remember while making an Aggregation pattern:
Data from various branches should be synced with one another, i.e., changes in one DB should reflect in another DB.
There should not be a need to manage the aggregate DB manually.
Various Type of Data, Data Sources, and Destinations
Data Sources: Data Sources can be categorized into 2 types mainly:
API: While fetching data from the source, we got to see API as a data source most of the time, and in a general fashion, they usually provide data in Json format.
File System: File systems like Hadoop or S3 is one of the data sources from which we can fetch data in a file format or a tabular format
Data Destination: We can have plenty of data destinations, but all of them can be generally divided into two formats:
Analysis purpose: We write data in such databases where analysis can be done or operational queries run. So data stored here always needs to be organized.
Data Store Purpose: Sometimes, we store data as a backup to our real data. In this case, we do not put effort on organizing that data, and rather we just dump data into a datastore.
Type of data transfer: When Integrating data, we also need to consider the data transfer type to make our system more efficient. We have 3 types of data transfers mainly:
Real-Time: This type of transfer is required when speed is the crucial factor for transferring data. For instance, in an ATM system, data transfer needs to be real quick for transactions to happen. E.g. Data streaming, radar system
Near Real-Time: In near real-time, speed is essential, but you don’t need it immediately. E.g., any monitoring system in IT or processing Sensor data.
Batch: In the Batch system, data is transferred in batches, for instance, activities that happen on a long cycle of time, E.g., Month salary or analyzing a batch of collected data over time.
How we can Implement Solutions for various sources and destinations?
For implementing the Data Integration pattern for our system, one needs to be clear about the above-discussed points i.e, Data source and destination type, data transfer type. After these points are clear, one needs to find suitable tools for generating a pattern.
Below are some pre implemented examples for data integration:
Data Coming from API in Batch and stored for analysis and storage.
Conclusion and Future Scope
Data integration patterns can be divided into 5 main categories, But one needs to take care of which pattern can be used to fulfill their requirements. That can be found by defining source, destination, and transfer type. The Future Scope of this blog would be to find accurate tools to define patterns of each category as described in point 7.