As you know, Sanjay and I have been hard at work on this topic for the last two years. I am preparing to release some of the findings soon, in fact, I will release some thoughts, and difficult questions that we propose to the market place in this blog entry. I encourage you to offer your feedback to the questions we pose by supplying replies to this blog entry. NOTE: This is a result of discussions and hands-on that both Sanjay & I have had over the past two to three years. These are my opinions.
Defining our #nosql Platform
There are so many #nosql platforms and now, newSQL platforms in the market, that I thought it wise to discuss the very platforms that Sanjay and I have actually been working with – and why. We have several platforms we’ve been testing with. The first, is pure Apache Hadoop & HDFS – let it be known that when I say “Hadoop” in this post, that is the context under which I am discussing the tests. When I say “Hadoop Platform” I am referring to the additional components such as Sqoop, Flume, and the rest of the applications on top of Hadoop. When I say the Hadoop Ecosystem, I’m referring to all of the above PLUS the hardware we are running on.
Our second platform is a stripped down version of Cloudera – Sanjay removed many of the additional tools that we did not wish to test with.
Our third platform is Hadoop + HBase – specifically for HBase testing purposes.
Our fourth platform is Hadoop + Hive (Internal and external)
Our fifth platform is now Hadoop + Stinger
What are we trying to accomplish?
We are trying to put the entire enterprise data warehouse (including Data Vault 2.0 modeling, analytics, real-time feeds, batch feeds, cleansing, business rules, managed self-service BI, quality, metrics, control / security, access, etc…) all on the Hadoop Ecosystem. Our primary focus is to answer the following questions:
- What pit-falls are there when compared to a standard / traditional relational DB for EDW ecosystem?
- What positives / good things are there when compared to a traditional relational DB for EDW ecosystem?
- What best practices should be standardized on in this environment?
- What happens to Data Modeling in the Hadoop Ecosystem that we need to be aware of?
We have about 50 more questions but I won’t bore you with the list. There are other, far more pertinent questions which I respectfully ask you to reply on, that I’ve posted further down in this blog.
A bit of history around Data Vault 2.0 System Of BI
For those who don’t know, DV2 is a system of business intelligence that includes: agility, CMMI, six sigma, KPA/KPI’s, PMP, best practice data modeling, best practice data integration, separation of hard & soft business rules, and more, all for the purposes of building an enterprise data warehouse in an incremental fashion with rapid build out.
Ok, back to point….
There are pitfalls of these Hadoop based ecosystems that vary with the physical setup and implementation choices. There are over 50 different significant pitfalls (some are mitigated by other technology, some are not). Here (below) are a few – again, keep in mind these are dependent on the physical layout, storage, and implementation chosen.
- HDFS does not allow update in place to “files” (this can be seen as a benefit actually)
- HDFS does not understand indexing – ie, every access is a full file scan
- Hadoop has a big learning curve for non-programmers
- HDFS can implement many different “physical storage formats” – causing problems for, OR helping performance.
- Hadoop on MPP still exhibits the data co-location, and cross-node “join” problems.
- Hadoop itself, doesn’t understand JOINS without writing Map & Reduce code.
- Hadoop Schema on read makes it extremely difficult to optimize performance for ad-hoc queries
- The general population doesn’t understand Schema on read vs Schema on Write
- Data modeling doesn’t/can’t/won’t apply to ALL data absorbed by Hadoop (think Word Docs, images, movie files, sound files)
- Every Hadoop based “solution” is different than the last, meaning consistent design doesn’t work across “Hadoop platforms”.
- There is no governance over Hadoop – anyone with a login has access to EVERYTHING in the HDFS (Hadoop file store)
- There is no metadata lineage / data lineage in Hadoop, no way to know where data came from, who’s accessing it / when, why, or even what they are doing with it.
- Hadoop is not transactional driven, it’s a file store – it is “batch load” of a FILE.
- Hadoop keeps history of everything all the time, Managing that history can be a nightmare without additional tooling on top.
Therefore, I will make the following theoretically applied statement: everything in HDFS / pure Hadoop, is just a data dump, a data junkyard – it is NOT nor will it ever be, a data lake. Not without mitigating the issues above, which in turn requires additional solutions to manage. At the bottom of this post, we’ll get in to what this means to a Data Vault Model (nothing else at this time), there is more to come…
Benefits / Positives over a Traditional RDBMS EDW
Now, let’s take an opinionated look at what I’ve found to be some of the benefits. These are nothing new – most of these benefits have been described as the REASON for Hadoops’ existence. This is not rocket science, but it does take quite a bit of digging and learning to figure all this out.
- Schema on read, means ingestion of Large Files is SUPER FAST (doesn’t enforce the overhead of a schema and data aligning to columns, tables, and rows while loading). ie: a load is a COPY FILE command
- MPP arbitrarily splits the data through hashing and bucketizing, allowing massive scalability on commodity hardware.
- More knobs, bells, whistles and switches mean more tweaking & tuning can be done at the core-level of the system, resulting in more performance (that’s the goal anyhow).
- Open-architecture and open-source, means more innovation (in this case), and more tooling to choose from (both a benefit and a drawback).
- No need to EVER run a delta check – all history is kept of every file that is ever loaded. However, if you really need to know what’s changed, YOU have to code the logic to find out.
- No restructuring of the data set UNTIL or UNLESS you need to access the data and turn it in to information. (Structure on demand is kind of like schema on read).
These are still being worked out. One of the first best practices to emerge is to use Hadoop and HDFS as a persistent staging area, then only source the data and it’s history when the business needs it. At that time, load it to a relational store for further analysis and ad-hoc query execution. (along with Indexing, Joining, governance, and so on).
What about Data Modeling in Hadoop?
This is a question on everyone’s mind. The fact is, Hadoop shifts the paradigm to schema on read. This notion of schema on read is very similar to Cobol Copybook: Redefines. Only difference is that Redefines is fixed based on a data flag. Schema on read means that the schema or structure is defined at QUERY / Request time, and then applied to the data set underneath. IF and ONLY if the data MATCHES the schema, then it is returned. Any data that does not match the schema is completely ignored by the processing engine. This is something that has to be learned. Unfortunately, it’s not an easy thing for people to grasp without getting hands-on experience.
That said, that raises the next set of questions around: Data Vault Modeling IN Hadoop, using Schema on read. The following questions now come to light:
- What is the value of a Hub? What is a Hub in Hadoop?
- What is the value of a Link? What is a Link in Hadoop?
- What is the value of a Satellite? What is a Satellite in Hadoop?
To summarize, why and /or DO I need a Data Vault Model in Hadoop??
Well now we’ve come to the point of this entry…
Let’s start with the Hub structure…
The Hub is a list of unique business keys defined to be “soft-integrated”, ie: those of the same semantic meaning and same grain can be stored in the same Hub structure. Now, isn’t one of the purposes of an Enterprise Data Warehouse to assist with Master Data? In principle at least.. If this is one of the goals, then it would make sense to construct a Hub – as a central point of business key integrations.
However, the PHYSICAL Hub structure holds no weight, doesn’t add value to the physical storage components that I can find. Which means: you should still model Hub entities (do the integration work, do the hard work of understanding the business) at least at the logical level.
Back to the physical store for a second… If you have a bunch of data sitting in a file, how do you “identify” it? well – for one, you have to scan it at least once. Second, you *should* be looking for keys, keywords, key phrases, something that will either uniquely identify the file, or at a minimum identify the file as part of a GROUP (ie: enter tagging). Ok, but what if you have MORE than one key IN the file? What if you have a GROUP of keys identifying multiple things in the file?
Well – it goes without saying, that every time you want to DIG this information out, you MUST file-scan the whole file, UNLESS you have something that is “kind of like” an index, and can quickly identify what’s IN the file, and what’s not. OR you absorb the data in to a storage format that allows Indexing, and go from there.
So – is there a need for physical Hubs after all?
I reserve judgement on this one, until further tests have been run. But so far, the tests are indicating there’s no need for PHYSICAL Hub structures, but there is a need for Logical Design of Hubs so that we understand the data sets sitting in the data dump. IE: A Hub Still is a unique list of business keys, BUT it is a LOGICAL ENTITY rather than a physical structure.
What about Links?
Ok, next part… The Link tables. Links, love them or hate them, are association tables – just like factless facts. (I can’t stand that term, it is a non-sensical term that truly has no meaning). I prefer the 3rd normal form definition: Many to Many relationship table. A link has been extended in the Hadoop context to be a fact table, inclusive of Bridge table definitions, and Point-in-time table definitions. It functions as a JOIN table in many ways, don’t get me wrong, it’s not a PURE fact table – it doesn’t have surrogate keys pointing to dimensions… no-no, that’ won’t do. It has a set of KEYS (either from the Hub, OR natural keys), including aggregations, computed fields, and begin / end dates (temporal dates) for when the relationship is active.
The Link table is necessary in a physical sense for several reasons.
- To join across MPP, and create ON-NODE joins before moving data across the network. This is VITAL to scalability of data sets, and alleviating big data joins.
- To provide FASTER access of a STRUCTURED / pre-assembled set of answers.
- To avoid file scans of the root data set until necessary.
- To possibly MAP the results to a relational database perhaps through Hash or Natural Keys
But are they true Link tables as defined in the Data Vault Modeling components? No.
They are Link-like tables, but in reality they are 3rd normal form: Many To Many relationship tables, that appear as fact tables and link tables at the same time. They are: for all intensive purposes, Join tables with post-business rule data sets.
These are truly built on the fly / on demand – unless 80% of the “queries” use the shared data sets, then Hadoop caches versions of these things as they are built. If anything, they are indirection / pointer tables, join tables, and aggregate tables. There is no “formal name” for these things yet, they are not factless facts, nor are the fact tables. They certainly are not conformed, as the raw data underneath that they point to is also not conformed.
But that begs the question: SHOULD these tables be conformed, and if the answer is YES – then that means they are BUSINESS MART tables complete and total, that they ARE flat-wide report collection tables / structures, or simply put: aggregate collections of munged data, a result of business rule applied data. Remember, if the answer is YES, then that means you are using Hadoop processing to PICK UP all data you “want”, keys and all, run it through some set of processes, and then store the full result – with NO relation to the raw data anymore. We are right back to auditability problems… food for thought.
Interesting how the game changes? Well the truth is, the game is changing and will continue to change as we explore best practices for utilizing a Hadoop platform.
Ok, What about Satellites?
Well, we are in the home stretch of this blog entry. Satellites are easy (comparatively). If you accept the premise that Hubs are necessary logically and that Links are necessary (both logically and physically), then that makes the rest of the files (in what ever format they are in), Satellites. In other words, you are still after “replicating only the data as needed to access the full source on demand.” Otherwise, you would go with “copying/munging/changing” and writing a new file (report collection as defined above).
The only thing left to do, is to say: HOW do we access Satellites / files efficiently through pointers and “joins”? Do we use natural keys? do we use Hash Keys? do we use Links? do we pick up the data, and move what we want to a relational DB/Structured world so ad-hoc works properly? Do we wait for the Hadoop Ecosystem to “catch up” to the Relational space in it’s functionality?
These are all good questions, and ones you will have to answer on-site depending on your needs. Today, Sanjay & I leave the files in place, but tag them with Hash Keys where possible, we then implement Hive Internal structures to provide “indexing” and “joining” kinds of things, on the data sets that CAN be structured. Sanjay and I are still using the full Data Vault contexts of Hubs, Links, and Satellites to work through all these issues.
I would love to have your feedback, if you’ve run any trials or test cases, please elaborate here on what you’ve found. We need to explore these concepts as a world-wide group.
Hope this helps,