Knowledge Hub

We have discussed IaaS and CaaS where only Infrastructure and Container level resources are rented on Cloud. Next stage of this paradigm change is to deploy Functions ONLY and pay for resources required to run those only. FaaS (Function as A Service) is one level lower than CaaS to rent resources on Cloud.

One of the biggest challenges to date is, whenever there is a change in the requirement, the whole code-set must redeploy. When code changes, it was always challenging to redeploy ONLY the changed code as there are always dependencies. Breaking the bigger code set into smaller pieces of code sets i.e., functions, can assist in mitigating this challenge wherever possible. Agree, in Data Pipelines it might be difficult but worth having this option to be utilized whenever possible.

As the name says itself, FaaS (Function as A Service) is about deploying ONLY Functions in Cloud. This saves us to manage Infrastructure on our own in Cloud, now we can deploy our Functions ONLY and underneath it the infrastructure will be managed by Cloud providers. Most of the Cloud providers are offering FaaS.

As we move from IaaS and PaaS to SaaS, it becomes very confusing segregating PaaS and SaaS, but please hold on to your horses’ 😊 we are going to nail it down in this topic.

To understand this example, pre-requisite topics are 1) ‘On-Promises vs Cloud’ and 2) IaaS and 3) PaaS.

In IaaS, we established that only Infrastructure/ Servers and Storage is provided by Cloud providers then in PaaS we establish along with Infrastructure/ Servers and Storage, Software(s) BUT EMPTY Software(s) are also made available along with rest of all the activities to be managed by the Cloud providers EXCEPT NO IMPLEMENTED SOLUTION.

In SaaS, there are pre-built or OOTB Solutions available in the Cloud. Please note, it’s not mandatory that all solutions are owned by Cloud providers, most of the solutions are created and maintained by the third parties. Third Parties use compute and storage from Cloud providers and build their own solutions and sell to customers. Now, customers just need to log-in into the Solution in Cloud as a Service that is why it’s called Software as A Service. A solution is owned and its management like installation/ upgradation, compute, storage, HA, DR etc., all are taken care of by the Solution Owner, again which can be by Cloud Providers or any Third Parties. Customers just need to subscribe to the SaaS service and start using the Solution.

Data Observability is one of the most underrated terms, as its name says, it's about observing and providing analysis and analytics for decision making.

‘Data Observability comes under Metadata Management.’

Yes, Data Observability aims to focus on observing every data pipeline, data transformation, DDL, DML, data governance standards, security & privacy policies etc. across the organization. It creates a holistic view of everything, it assists to find out where the problem is and debugging steps assist to make future decisions, so the same problem don't occur in future.

Pillars of Data Observability

1. Freshness
2. Lineage
3. Schema
4. Volume
5. Distribution

Now the question is, observe but how? Do we or can we give access to one framework on all the frameworks in Enterprise? Of course, the Security, Risk, Compliance and Audit departments won't let it happen. But NOT-IF the access is requested only on tools for Metadata Management. Yes, Data Observability mainly access Enterprise Metadata Data.

Data Preservation, Data Security, Data Privacy, Data Integrity, Data Compliance all refer to the protection of the data.

Data Preservation is about securing and maintaining the safety and integrity of the data after it’s been processed, for future reference.

‘Data which is preserved cannot be changed and hardly purged or deleted.’

Things to consider for Data Preservation

• What data to be preserved? Not all data is worth preserving.
• What is the retention period to preserve data? Like for how long to keep data.
• Who will be responsible for preserving data? A custodian is required for data repository.

In the current era with big data having huge semi and unstructured datasets, it’s not worth rather not possible to preserve everything. One must decide what to preserve and for how long.

For example, in datastore like Data Warehouse or a Data Mart or in Data Lake etc., there are certain datasets to preserve. One can start from the list of compliance requirements e.g., traditionally in banking sector, the customers who has left the bank or in other words closed their accounts, their history is preserved or saved for 7 years from the day they closed their accounts.

Data Subsetting is as simple as taking a small piece of data, with referential integrity in place, for some activity. For example, there is a requirement to build a data science model and it requires data for users aged between 25-35 from X Location having certain buying/ spending patterns. For this requirement, a particular dataset will be extracted for the data science development team to build and train their data models.

Don't confuse Data Subsetting with Data Masking. Data Masking is still required on this smaller piece of the dataset from a security point of view. Having said that, conducting a Data Subsetting exercise is not as simple. One first must understand the functional requirements of the use case, then one must also understand what data is there in the database as whole. Wrongs or partial Data Subsetting will end up producing wrong data model results and will damage trust in data by decision-makers.

In the current era there are many data stores like Database, Data Warehouse, Data Marts, Big Data, Data Lake, Data Vault, Business Vault, SQL, and NoSQL etc. Use of all these terms is different with their own horizon, their own skill sets whereas tools and languages can be the same for all of these.

First one must understand is that Database is a datastore, we can’t link it to any data modelling solution. In other words, OLTP or Data Warehouse or Data Mart or OLAP all use databases as a medium to store their datasets. Additionally, Databases can be SQL or NoSQL.

Now, OLTP is on one side of the line and Data Warehouse/ Data Marts and Big Data/ Data Lake etc. are on the other side. Normally, databases are called OLTP (Online Transactional Processing) whereas Data Warehouse/ Data Marts fall under the term OLAP (Online Analytical Processing).

As far as Big Data/ Data Lake is concerned, Data World has yet to tag these with either OLTP or OLAP but for sure these are not meant for OLTP. At the same time NoSQL is stepping into OLTP zone and is supporting OLTP as well.

The term Big Data emerged in the early 2000s as enterprises began facing unprecedented growth in the amount, speed, and diversity of information being generated. Traditional databases and warehouses, while reliable for structured data, were not designed to handle this new reality. Big Data describes not only the massive scale of data itself but also the ecosystem of technologies, methods, and practices developed to capture, store, and analyze it.

At the heart of Big Data is the concept of the “three Vs”, later extended to four or more:

• Volume: the enormous scale of data generated from transactions, machines, sensors, mobile devices, and social platforms.
• Velocity: the speed at which data arrives, often requiring real-time or near real-time processing instead of traditional batch updates.
• Variety: the diversity of data formats, structured (tables), semi-structured (JSON, XML), and unstructured (text, images, videos, audio, logs).
• Veracity (sometimes added): the need to ensure trustworthiness and quality despite scale and diversity.

One of the biggest criticisms of early Data Lakes was their lack of reliability. While they excelled at storing vast volumes of structured, semi-structured, and unstructured data, they struggled to provide the transactional integrity and data consistency that relational databases and warehouses delivered as a matter of course. Operations such as inserts, updates, and deletes, known collectively as DML (Data Manipulation Language), were difficult to perform reliably on file-based storage systems like Hadoop Distributed File System (HDFS) or cloud object stores such as Amazon S3.

To achieve performance and flexibility, many organizations turned to Apache Spark, an in-memory processing engine capable of handling both batch and real-time streaming workloads. However, Spark introduced a different problem: while it enabled fast queries and analytics, it was not ACID-compliant. Without atomicity, consistency, isolation, and durability, organizations faced the risk of incomplete writes, corrupted data, or inconsistencies when jobs failed midway. Workarounds existed, but they were complex and fragile.

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.

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.