Carrefour has come a long way since its first store opened close to a crossroads — giving the company its name — in Annecy, France, in 1960. The retail titan now operates operates around 14,000 stores worldwide and is enjoying particularly strong growth in Romania with more than 400 stores of various sizes and formats.

When Carrefour Romania embarked on its Google Cloud Platform (GCP) project, it envisaged multiple benefits from using a public cloud service, including faster delivery of new customer offerings. However, most of its data storage facilities were on-premises, either in stores or local data centers. The logic of moving to the cloud – and the multiple opportunities it offered – was beyond question for Carrefour Romania. Its existing network gave the business the stability it needed but capacities were limited and structures excessively complex.

Carrefour Romania saw that Talend Cloud Data Fabric was the tool it needed to turn multiple, disparate sources of data into a high-speed, high-value resource. Critical to the choice was the extensive range of prebuilt connectors available within Talend and the decentralized architecture it offered, as was Carrefour Romania’s collaboration with local consultancy btProvider.

Carrefour Romania now has around 50 separate flows operated either by btProvider or other partners. Sources include BigQuery, PostgreSQL and Carrefour Romania’s ERP solution.

The new data environment at Carrefour Romania has enabled it to develop and enhance processes across the business and its speed of implementation has meant that Talend quickly began to deliver results.

Some of the most successful projects cover regulatory areas such as metal and plastic recycling, e-Transport, which regulates the transport of potentially high-risk goods, and Standard Audit File for Tax (SAF-T), which manages the digital transfer of accounting data to auditors.

Elsewhere, Carrefour Romania’s marketing operation can now build out the Act for Good customer loyalty program, using high-speed data access to develop personalized customer promotions and incentives. Near-real-time synchronization of prices and stock availability are also improving the customer experience.

The broad range of integrations and use cases that Carrefour Romania has been able to build with Talend and btProvider illustrates the speeds of development that are available to any business.

Siloed and disparate data sources don’t have to be insurmountable obstacles. With Talend, businesses of all sizes and sectors can turn them into powerful assets that deliver tangible value and impressive results. As with Carrefour Romania, it can also act as a springboard for a host of other exciting digital initiatives and accelerated processes.

Database synchronisation is the process of keeping two or more databases consistent and up-to-date by exchanging data changes between them. Database-to-database synchronisation is the primary use case for Qlik and Talend solutions. There are four strategic initiatives that companies typically implement to drive a database sync project. These initiatives are not exclusive, and organisations often implement several projects concurrently.

To improve the efficiency of their analytics and reporting processes, many organisations start by building a data infrastructure. An organisation typically begins by creating a central data warehouse in the cloud as a single source of truth. There are many popular cloud-based data warehouse platforms, including Amazon Redshift, Google BigQuery, Microsoft Azure, Snowflake and Databricks. But no matter which solution you choose, the key to success is feeding the warehouse with relevant and accurate data.

Not surprisingly, Qlik + Talend has fabulous data integration and quality offerings that make these tasks a breeze. In particular, Qlik + Talend market-leading CDC solutions help you quickly replicate data between databases or warehouses to enable more efficient query and analysis of your data without impacting the performance of the primary database.

The second scenario for data-to-database synchronisation is when organisations want to re-architect or re-platform existing infrastructure to take advantage of the latest technologies.

For example, an organisation may want to refactor monolithic applications into discrete microservices that leverage public cloud infrastructure. In this scenario, a new cloud database is often deployed as the primary data source for the microservice applications. As a result, enterprise data sources then replicate data from across the organisation to ensure that the new cloud database always contains consistent and accurate data.

The third use case for database-to-database synchronisation is extremely useful when modernising legacy applications such as SAP or legacy infrastructures such as mainframes. The modernisation process preserves the integrity of the original systems by offloading data updates to a secondary data store, which is then used as a data source for operational analytics or online analytical processing (OLAP).

Not only do organisations see an improvement in query performance without having to upgrade the legacy applications, but they also don't put new query workloads on these critical legacy systems. Again, the best practice is to use an ELT (aka CDC) philosophy to hydrate the secondary data store.

The final use case is sometimes referred to as cloud data migration. Again, the organisation is looking to leverage new cloud technologies for new initiatives such as machine learning (ML). However, ML often requires multiple data sets for training and a live data set for production predictions. As a result, organisations are replicating data from their on-premises data sources into the databases required for ML projects. Again, ELT is typically the preferred approach for data synchronisation, but sometimes ETL is used to replicate training datasets because data timeliness is less of an issue.

One question that frequently crops up when we discuss database-to-database synchronization is when you should use an ELT (extract, load, transform) approach versus ETL (extract, transform, load).

The rule of thumb is to consider the importance of a fresh data replica and the type of data destination. If you need the data in near real-time for data warehousing, then ELT is preferred. However, if you don’t need an exact copy of your source data and require more curated data sets then batch ETL should be considered.