When it comes to BI, there are multiple ways to pull the data for the end users. You can build reports, build a dashboard, or generate OLAP cubes for example. The problem with building OLAP cube is that you are building another layer of complexity. That means more overhead into cycle times in how long it takes to get data from point A to point B. From your source, through the transformations, to the end user. Overhead might not mean anything to you in the beginning but think long term when you think about data warehousing. If you build it right up front it will pay off in time and stress on the back end.
One day in your future, you will wake up and have a problem with your data. The source system had issues. The ETL process broke. The data was dirty. You come into the office ready to tackle the day and you have a Severity 1 staring you in the face. What do you do about it?
- You analyze the issue
- You correct the issue
- THEN you have to reload the data
Time is of the essence. If your load take 6 hours to complete, do you do anything at all? Do you try to load the data and then load the cube? Hey it will happen and what is the answer?
The second issue that I have with the cube is that it takes time to generate your model. Then you come to the customer. The customer may not like the way you put the cube together because there are assumptions that have to be made in order to build your cube. You have business rules that might not meet the need of your new customer. What do you do now? Do you build a new cube for every new customer? My client just changed the way we calculate persistency for the business. The first year persistency looked great. The second year, it tanked because of considerations made for year 1. So the answer was to change the model. Now we don't use cubes for this client but changing that model and then changing the cube would not be fun.
These are my quirks with OLAP. You may think differently. I would appreciate the feedback.
Joe
No comments:
Post a Comment