Knowledge Hub

As discussed in topic i.e., Data Warehouse or Data Mart that Star schema and Snowflake Schema both refer to Ralph Kimball Data Warehousing approach. But what about Galaxy Schema?

You must be wondering that we have been hearing about Facts and Dimensions in both Star and Snowflake schema(s) but where are Conformed Dimensions, so here it is.

Galaxy Schema is also known as Fact Constellation Schema and is more complex than Star and Snowflake schema. It’s further divide Star Schema into small Star Schema(s) where there are more than one Fact Table and have Reusable Dimension to connect multiple Fact Tables.

These dimensions which can connect with multiple Fact tables across multiple Star Schema(s) are known as Conformed Dimensions.

Cubes are a very controversial element of OLAP world where most of the folks think, it not worth having those.

Cubes host data from facts and dimensions in one table so query can be super-fast, in Cubes multi-dimensional data is pre-loaded.

Disadvantages

• These are huge in size.
• Very difficult to refresh in real time.
• Housekeeping is a challenge.

Below is Star or Snowflake schema representation. When data is joined from Fact and Dimension and loaded on one table it is called an OLAP Cube.

There are multiple types of OLAP i.e.  ROLAP, MOLAP, HOLAP, HTAP, WOLAP, DOLAP and SOLAP.

• ROLAP [Relational On-Line Analytical Processing]: It sits directly on top of RDBMS which can be Star/ Snowflake Schema(s) and can be built using standard SQL. Another benefit, ROLAP doesn’t need additional storage as it runs on top of RDBMS.
• MOLAP [Multi-dimensional OLAP]: Cubes are the best example of MOLAP where multi-dimensional data can be loaded in a separate storage but in an extremely fast manner. Using Cubes, users can slice, dice, and drill up/ down, roll up and pivot the data within the same one cube eliminating the need to join with other tables. If a Cube has more than 3 dimensions of data in it, it’s called Hypercube.
• HOLAP [Hybrid]: This is a mixture of ROLAP or MOLAP.
• HTAP [Hybrid Transaction / Analytical Processing]: This is for in-memory data systems that do both online transaction processing (OLTP) and online analytical processing (OLAP).
• WOLAP [Web-enabled]: This refers to the only Web-Based OLAP with no connectivity with on-premises and is utilized through the internet browser.
• DOLAP [Desktop On-Line Analytical Processing]: In this OLAP, users can download a portion of OLAP on their machine for offline working.
• SOLAP [Spatial]: This is to tackle issues in the field of Geo-Business Intelligence.

Before I came into the Big Data domain, in early 2010, my assumption was, standard SQL will not work for NoSQL databases, but I was 180 degrees wrong. NoSQL means Not-Only-SQL. Yeah, I felt dumb after knowing this lolz 😊.

In the past, we had only one Database Type i.e., RDBMS which here is referred to as SQL but with the introduction of Big Data, 4 more types of NoSQL databases came onto the surface i.e., Key-Value, Columnar, Document and Graph DB.

Examples of SQL database types are Oracle, DB2, Teradata, SQL Server, MySQL etc. which we all have been using for decades.

Hope we are on the same page that all SQL/RDBMS databases are just empty storage. The same is true with all these new NoSQL databases; these are again empty storages. In contrast with SQL/RDBMS databases which use server OS file systems like EXT, FAT21 etc. the new NoSQL database can additionally use HDFS.

Now, there is big confusion for storage selection in Hadoop as for a normal person, there are 5 new data stores in Hadoop i.e., 1) Hive 2) Key-Value DB (NoSQL) 3) Columnar DB (NoSQL) 4) Document DB (NoSQL) and 5) Graph DB (NoSQL). Yes, there are 5 data stores but there is 1 storage that is HDFS Hadoop Files Storage.

Data Mesh is normally confused with Data Mashup (explained separately), but both are totally different.

Data Mesh is a modern approach to data architecture and governance that emphasizes decentralization and domain-driven ownership of data products. Unlike traditional centralized data systems, which rely on a monolithic team to manage and deliver data assets across an organization, Data Mesh shifts the focus towards empowering individual domains to become autonomous in managing their data products. This paradigm fosters scalability, improves data usability, and ensures alignment with specific business needs.

Understanding the Foundations of Data Mesh

At its core, Data Mesh revolves around four key principles:

1. Domain-Oriented Decentralization: The fundamental premise of Data Mesh is the distribution of data ownership to individual domains. A domain, in this context, refers to a specific business area or operational unit, such as marketing, sales, or customer service. Each domain is responsible for defining, managing, and maintaining its own data products. By doing so, Data Mesh reduces the bottlenecks and inefficiencies associated with centralized data teams.
2. Data as a Product (DAaP): Data Mesh introduces the concept of treating data as a product. This means that data products must be designed with the same rigor and customer-centricity as any software product. Each data product must:

Data Swamp is a term famous as nightmare for CDO.

We all are aware of Data Lake or many other datastores where structure, semi and unstructured data is stored in an organized manner with proper Master Data, Metadata and Data Lineage. On the other hand, if datastores is missing Master Data, Metadata and Data Lineage, it becomes Data Swamp.

Data Swamp is a datastore that is not organized and from which it's very hard to extract information, which has a lot of duplications, and which has a lot of data quality issues.

In other words, retrieving and transforming data is no longer possible when it becomes a Data Swamp.

Data Swamps can happen quickly and can create a serious problem for companies relying on this storage, extraction, and transformation system for analytics.

Any organization which is in the process of becoming a Data-Driven Organization must first focus on Data Governance, Metadata Management, Master Data Management, Data Lineage. Having a data-driven organization with no clues like what and where data is residing is a nightmare and a waste of time and effort.

HTAP stands for Hybrid Transactional/ Analytical Processing. It is a new architecture proposed by Garner in 2014.

In previous topics, we have established that there is an OLTP database for operational tasks and then Data Warehouse, Data Lake, Delta Lake, Data Lakehouse, Data/ Business Vault etc. for analysis and analysis. All keep data separately in their own storage for management decisions.

HTAP is proposing to use one system for both transaction and analytical workload. It is offering an in-memory plus columnar approach for analytical processes.

With the advancements in hardware, in-memory and Cloud, Gartner thinks it is very much possible to have both Transactional and Analytical processing on the same database.

Advantages

• No duplication of data as data will not move from the same one operational database.
• Business or Management can make decisions on actual data in real-time, in contrast if data must move from OLTP to OLAP systems.

Data Rooms or Datastore are both the same entity. Data Rooms are normally used for due diligence of confidential documents like handling Business Mergers or Acquisitions by bidders & advisers, compliance & audit teams.

Traditionally, there are Physical Data Rooms with Physical Documents. These Physical Data Rooms are for restricted people only, secured by guards with a maximum of one or two parties to go in at any given point-in-time which delays the process if multiple parties are using the same Physical Data Room.

With the growing businesses globally, it was a very expensive affair for multiple teams to fly over to be near these Physical Data Rooms. As an alternate and more viable solution, VDRs (Virtual Data Room) came into the picture which are available Online, behind Firewalls and with proper Access Control. VDRs have changed the game, now sellers can invite a bigger audience and teams sitting in one part of the world to participate in a bid process happening in the other part of the world. VDRs have cut down the cost and expedited the process.

As per the name depiction, Data Locality looks like knowing the location of the data; it is partially relevant.

Traditionally, to use data for analysis, at the backend the data is fetched from storage/ data nodes into master nodes, for computation. There is a complete history of how initially whole data was pulled then blocks were pulled then the columnar pull concept came-in, etc. so we won't go into detail about how technology has evolved to process data.

Since semi and unstructured data has become a necessary part of the Data World, it comes with huge storage requirements i.e., in TB and even in PB. To host this humongous data, clusters of 100s of storage/ data nodes are set up, so it is not possible to pull this size of data for computation in master nodes which are normally few. It was a critical requirement to process queries where data is residing.

With the introduction of Big Data/ Hadoop/ HDFS where data is stored in the shape of blocks, the concept surfaced i.e., instead of fetching data for computation, let's take the query to the storage/ data nodes, process it there and fetch only processed data. This process of moving the computation close to where the actual data resides on the storage/ data node, instead of moving large data to computation, is called Data Locality.

When we say Data is the most relevant demanding term in the current era then the question comes where to store it. There are 3 types of storage at the hardware level i.e., Object Storage, File Storage and Block Storage.

• Object Storage considers all types of data as an object. Here data is stored in a flat open storage area, with no folders or subfolders concept, along with its metadata and unique identifier which forms a storage pool keeping all details about that data near to it.
• File Storage keeps data as one piece of information inside folders and subfolders which is in a way is in Hierarchy mode, in contrast with Object storage e.g., you must remember how we used to keep manual papers in files in our school days. It’s the same concept here. So, when you need any specific data, you just need to know the location or path of the folder.
• Block storages consider a file as a single block of data and each block is stored as a separate piece of information. A unique address is given to each block for reference. Traditional databases are stored in blocks, and at the backend Hadoop files are also stored in blocks.

Hadoop and its relationship with Big Data. The Big Data ecosystem has many components like NoSQL databases, In-Memory process, MPP, 3 Vs etc. but Hadoop is the backbone, and it was the main reason for the popularity of Big Data. In other words, Hadoop was the Selling Pitch for Salespeople.

'Hadoop is a Java-based framework.' Currently, its latest version is Apache Hadoop 3.3.4.’

Please note, Hadoop is not a solution, it's again an EMPTY storage. One must load data first just like we do in traditional databases before any analytics can be generated. For the first 5-7 years, Sales keep selling Big Data in such a way that you buy Big Data, and it will do magic for you, where all kinds of Analytics will be readily available but no it didn't happen, and you already bought it lolz. Learning: For every new technology, first hire a specialist internally and then invest 😊.

Let's go a little deeper.