Extract, Transform, and Load (ETL) is not a specific tool. It’s a philosophy that’s rapidly evolving. Explore your options and learn why you should be aware of it.
You may have read my MC Press Online articles about Microsoft SQL Server Integration Services (SSIS). I’d like to broaden the topic to discuss Extract, Transform, and Load in a philosophical sense to give you a better understanding of how you could use it. However you decide to implement it is up to you.
I was once told that the better you understand something, the simpler you can describe it. With many years of experience, you can start to recognize patterns, regardless of your profession, but particularly in software development. I’ve always enjoyed the ability to create a software product that is the actualization of an idea. The result isn’t something you can touch; it’s an idea that’s running on a piece of hardware. With software, you can take the patterns you’ve learned and create a philosophy that can be literally implemented to create those products in a more efficient manner that provides more reliable results. This statement is not a new concept; you can look back to the origins of IBM products that have been object-oriented way back at the beginning.
When I first discovered ETL, I was amazed by its simplicity. I reflected on all the custom coding that I’d done in the past to achieve the same tasks over and over. Throughout my years in software development, my employers were either acquiring other companies or being acquired. When these events occurred, we would consume the external data into a centralized system, or migrate it to newer systems, or export it to external systems. These could be either one-time processes, such as data conversions, or daily processes, such as feeding external website content or data warehouses.
Microsoft SQL Server Integration Services (SSIS)
My introduction to ETL came from Microsoft SQL Server Integration Services (SSIS). Being familiar with C# development in Visual Studio, I understood the environment, and the simplicity of the user experience made the learning curve very small, enabling me to provide reliable and consistent results within short development cycles.
This led to building more and more SSIS packages for multiple applications, and my interest inspired me to eventually co-write a book called Extract, Transform and Load with SQL Server Integration Services. Of course, I recommend my book, which shows you not only how to use SSIS but why you would want to use it in real-world scenarios.
ETL Batch Tools
I found SSIS to be a good introduction to ETL, and I recommend it to anyone—whether you’re a newbie or an experienced pro. SSIS is easy to learn, and you can use its functionalities on a daily basis. As I began to implement SSIS more, I especially liked using it for batch processing. In the beginning, this was more than adequate to support my initial needs that could be run on a schedule, but when it comes to a real-time solution (possibly using change data capture (CDC)), it has its limits.
For batch ETL, SSIS is not the only option on the market. There are quite a few, and here are some of the big names to get you started:
- Microsoft SQL Server Integration Services (SSIS)
- IBM InfoSphere DataStage\Information Server
- Informatica PowerCenter
- Oracle Data Integrator
I found SSIS to be a good start because it’s free, easily accessible, and simple to use. It also connects to multiple databases and has great documentation.
Enterprise Service Bus (ESB)
On another topic that may initially seem disconnected, while I was working with SSIS to support ETL needs such as synchronizing data between multiple systems, I was also working on projects relating to the Enterprise Service Bus (ESB) with queues and micro-services. I saw them as separate tools for separate purposes at that time, and I still believe that’s true, but I feel as though the technologies are growing closer together, which leads me to the relevance of the ESB with my next topic: real-time ETL. In fact, when I was looking into ETL initially, I was leaning toward the Java version at first, because that was the technology of preference in my shop, and I found that Sun Java CAPS (an ETL tool that’s no longer updated since the Oracle purchase) continues to be supported by the open-source community under OpenESB, which in my mind reaffirms the similarities and evolution of ETL and ESB.
Considering the growing needs for real-time data, I started to look beyond the batch processing that SSIS provides. In fact, a colleague of mine pointed me toward Talend’s Open Studio, which led me to other real-time options that utilize queues and micro-service. Here are some of those big names, which also have tons of useful information and concepts in the world of real-time ETL:
After reviewing the real-time ETL options, I immediately went back to the ESB technologies I was using, which were Red Hat Fuse with Apache Camel, and did not find any ETL reference directly, but I’m seeing the lines getting blurred with all the abilities to extract, transform, and load in real time with black-box components, queues, and micro-services.
ETL vs. ESB
When looking at the two philosophies on a higher level, ETL has a primary objective to move large amounts of data in an efficient way, whereas ESB has typically been used to move small amounts of data in real time. With the current need for real-time ETL, these two different concepts start to blend together. And if you look at the frameworks of both, you can see a common pattern of connecting black boxes to perform a series of operations to bring about a result.
Bringing It All Together
I know that I’ve covered several different technologies with different directions. This may seem intimidating at first, but let me try to pull all of these thoughts together.
If anything, when you start to use ETL, regardless of the technology that you implement, you could benefit by reducing your development time, thereby supporting business needs in a reliable way with a quicker turnaround time to allow your team to be more productive. You could continue to support your ETL needs by writing custom applications in the high-level language of your choice, but I feel as though there are better ways to utilize the development resources without writing repeated code that requires extensive testing.
As an additional indirect benefit, it helps you to think bigger and look beyond what you currently support on existing projects and move up to the next levels of integration and performance. With this new insight, your team can provide bigger solutions, which makes everyone on your team more valuable, larger contributors to your company. And you’ll actually be building in the time to do this along the way.
Even though I started my discussion with batch ETL, talked about its limitations, and explained why I support real-time ETL, I am not saying that real-time ETL is the solution to all of your problems. I believe there is a time and a place for each. I recommend starting with batch ETL as there could be a lot of conceptual realizations along the way. With batch ETL, you can start on solid ground to build a foundation for future skills and understanding.
If you’re interested in learning more about ETL using SSIS, you can check out some of my content, published either in print or online here:
- Extract, Transform, and Load with SQL Server Integration Services book by Thomas Snyder and Vedish Shah
- Simplify Common Database Operations, Including ETL, with a Few Point-and-Clicks
- Easily Create Excel Spreadsheets from Your IBM i Using SSIS
- TechTip: SSIS Data Sources for IBM i DB2 and Microsoft SQL Databases
- TechTip: Data Warehouse Updates from IBM i Using SSIS
I’m hoping this article leads you into a journey of some new concepts and piques your interest in starting to use these philosophies in your everyday projects.