The trend of ETL and ELT products viewed from Oracle acquisition sunopsis

The trend of ETL and ELT products viewed from Oracle acquisition sunopsis

Date:2008-6-17 Source:amteam I want to comment

Big| Medium |Small

• Submission
• Print

Introduction: This article mainly from Oracle Acquisition sunopsis analysis of ETL and ELT products trends and explain that the ELT tools than ETL tools can handle large data volume more efficient reasons.

Keywords: Oracle sunopsis ETL ELT

October 10 received a message from Oracle acquisition sunopsis. began to feel a little accident. A careful consideration should be reasonable.

First, Sunopsis uses an ELT architecture in other words, Sunopsis uses the functionality of the RDBMS it uses to complete ETL work, which should be consistent with the strategy of RDBMS vendors such as Oracle to implement ETL products.

Second, Sunopsis uses an open architecture that supports Oracle, which is supported by almost all of the current popular RDBMS. This is an irreplaceable product for Oracle's coveted non-Oracle platform Data Warehousing solution, sunopsis on ETL tools.

3rd, the focus of sunopsis products is on the application of EAI, which Oracle is also involved in. The 4th and important point is that sunopsis is developed in Java, which is consistent with Oracle and helps Oracle incorporate it into its future fusion middleware.

Okay, here's some digression, we're going to cut into today's theme, "ETL vs. Elt", which is more like a bet.

One side is currently the mainstream ETL manufacturers with their own development of the data engine to complete the extract,load,transformation task. The ELT vendors are betting on the current popular RDBMS vendors (that is, using the local SQL statements and tools of their respective RDBMS to complete the e,l,t three tasks). In fact, the idea of ELT manufacturers and we hand-written to complete the ETL task of the idea is consistent. is to fully utilize the functions of the source and destination RDBMS to complete the ETL task. However, the ELT tool has implemented many ETL tools (such as metadata management, visual design environment, load Balancing, automatic code generation, multi-user collaborative development, version control, CDC, slow change dimension processing, etc.). It also supports the code that automatically generates the ETL implementation process.

Last week, I was talking to a client, and he kept asking how the ELT tools could implement every step of the process. He said you extracted the source data into the staging area and then loaded it into the destination database to complete the conversion. Not with my ETL tools to load ETL tools on the destination side of the effect is not the same?

What I'm going to say here is that ELT was first introduced by Sunopsis to this concept. But we see from the code produced by the standard ELT process of its products that the conversion takes place not only on the destination side, but also on the source data side of the staging. The principle is that the conversion is the best thing to do to improve efficiency. I feel that ELT is more of a sign of advertising language than it proposes. Another reason is because the target side of the RDBMS function is relatively strong, from the point of view of the efficiency of the more t occurred at the destination, it changed LT to a sequence. This will give you more attention.

Essentially a tool such as ELT (like Sunopsis). is actually a manual completion of the ETL task Code automatic Generator. Let's imagine that if we don't adopt ETL tools, we use handwriting to complete an ETL task. We certainly will not put all the work of conversion on the destination side. We will also follow the principle of efficiency first, can be at the source end of the fast conversion at the source, if the source can not complete the conversion, we will be in the staging area or destination.

Some readers will ask, "Why is it that the ELT tools are more efficient than ETL tools to handle big data volumes?"

The answer lies in the fact that ETL vendors develop data engine mounts and SQL statements and current mainstream RDBMS in loading and local SQL statements who have strong issues. Is that the ELT tools make full use of local SQL statements and corresponding tools for the source and destination RDBMS. Just like our handwritten code. The fundamental reason for the higher efficiency of ELT is that the functionality of the current RDBMS vendor's products and the local SQL statements are too powerful, and this power continues to grow over time. It is much stronger than the 90 's mid-term RDBMS product in terms of data loading and conversion. And the current mainstream ETL tools have been developed in the 90 's, they have to develop a data engine on their own, otherwise it will not be able to complete the data warehouse level of data conversion, conversion tasks.

In fact, the crux of the problem is that the RDBMS manufacturers of products in the conversion, loading features almost no. ETL vendors do not have to develop a data engine themselves with no other hope. Today, the transformation and loading capabilities of mainstream RDBMS vendors (like Oracle, Db2,sql Server) and their ability to develop such stronger capabilities in the future are beyond doubt. So who else would have doubted that RDBMS would be the standard for ETL industry?

The trend of ETL and ELT products viewed from Oracle acquisition sunopsis