Knowledge Hub

Sharding

We know what Partitioning is. Sharding has similar features with some architectural differences. It also divides tables into multiple smaller datasets but in contrast with Partitions, Sharding stores each Shard on one dedicated node, so it’s called Shared-nothing Architecture. Advantages of Sharding is, referring to the same example from the topic on Partitioning, when the query runs for Year 2 & 3, each node with each Shard will process each dataset individually so will be much faster as compared to standard Partitioning where many partitions can reside on one node in Shared Architecture.

Sharding Architectures

• Key Based: It is also known as hash based Sharding, which involves using a value taken from newly written data and plugging it into a hash function to determine which shard the data should go to.
• Range Based: It involves Sharding data based on ranges of a given value.
• Directory Based: One must create and maintain a lookup table that uses a shard key to keep track of which shard holds which data.

Normally, ACID and Insert/Update/Delete are mixed, but they have different functions and at the same time work together.

There are 4 traits of ACID i.e., atomicity, consistency, isolation, and durability.

• Atomicity: It makes sure data is completely written in a destination with no partial data left behind.
• Consistency: It makes sure that once an application performs an operation, the results of that operation are visible to every next query. For example, sometimes a user is reading a particular data and at the same time it might get updated or even may get deleted. This should not impact the user query consistency.
• Isolation: An incomplete operation by one user does not cause unexpected side effects for other users.
• Durability: Once an operation is completed, it will be preserved even in the event of the machine or system failure. For example, in databases there is a concept of Transaction Log which holds every query statement run in the database so in case data is lost, it can still be reproducible.

To start with, ACID and BaSE both are Data Consistency models which compete on a use case requirement basis. In the previous topic, we discussed ACID, let’s discuss BaSE. What is BaSE? Never heard about it right 😊.

The basic difference between ACID and BaSE models is the way they deal with this limitation.

• The ACID model provides a consistent system.
• The BASE model provides high availability.

‘ACID is about Atomicity, Consistency, Isolation and Durability.’

‘BaSE is about Basically Availability, Soft State and Eventually Consistent.’

There are 3 traits of BaSE i.e., basically available, soft state and eventually consistent.

• Basically Available: The system is guaranteed to be available in the event of failure.
• Soft State: Due to the lack of immediate consistency, data values may change over time. The BaSE model breaks off with the concept of a database that enforces its consistency, delegating that responsibility to developers.
• Eventually Consistent: The fact that BASE does not enforce immediate consistency does not mean that it never achieves it. However, until it does, data reads are still possible (even though they might not reflect reality).

Starting with DevOps, we all know Waterfall and Agile methodologies. We won’t go into details of these methodologies but for audience comfort, DevOps is mostly about operationalizing Agile processes where a set of practices combines software development (Dev) and IT Operations (Ops) to make i.e., DevOps.

‘DevOps is a physical face Agile.’

‘DevOps includes Plan, Create, Verify, Package, Release, Configure, Monitor, and Version Control.’

In DevOps, activities are mainly executed based on use cases, user stories and tasks, there are also other practices conducted by different organizations.

Engineers in DevOps independently accomplish tasks (for example, deploying code or provisioning infrastructure) that normally would have required assistance from other teams. Responsibilities are shared by all team members.

Please note, when we say Engineers in DevOps independently accomplish all tasks, it can only happen if most of the activities are automated from provisioning of resources, services, VMs, compute, memory, testing, integration testing, training, deployment etc.

You must be confused between DevOps and CI/ CD.

‘CI stands for Continuous Integration and CD stands for Continuous Delivery/ Deployment.’

We know, in development and implement life cycle there are multiple steps involved e.g., development of code, packaging it, testing it, and then deploying in production.

The challenge in traditional approach is, once development is completed rest of the steps in above cycle were very time consuming as there are a lot of manual processes involve plus dependencies on many departments for review, approval, and deployment manually. Due to manual processes, there was always risk of human errors. Many a times, we have seen one deployment can affect other’s code as well. For example, there are 5 deployments conducted at the same time, 4 deployments went smooth but 5th one impact last 4 as well. We won’t go into details but trust me, I have personally seen the above incidents many times. OK OK OK, yes once me deployment screwed other deployments as well lolz 😊. The point is whenever there is human involvement, errors are inevitable.

DevSecOps is nothing less DevOps but with addition step of security.

Due to the quick and fast deployment cycles, security has become an alarming factor in DevOps, so security has been included right before the creation process and therefore DevSecOps (development, security, and operations) came onto the surface.

DataOps follows the same principles just like DevOps/ DevSecOps but here it has few more elements related to Data domain.

DataOps focuses on data related aspects of operations. It makes sure data is properly integrated with source and target, its flowing-in using automated and best practices data pipelines, its highly secured, it’s of high quality etc.

DevOps doesn’t care whether its data project or mobile application project or any other technology project, but DataOps focuses on Data like where it is coming and where it will go, why it is coming and how it will be used, how much it costed and how much it will monetize etc.

As mentioned above, DataOps includes all the steps or processes involved in DevOps/ DevSecOps but at the same time it also introduces a few additional steps.

DataOps Process Flow

• Regular Integration
• Regular Development
• Regular Build
• Regular Testing
• Regular Deployment
• Regular Delivery/ Run
• Regular Monitoring and Feedback

This is one of the most confusing topics now a days as data is the most useable element of organizations now a day.

I won’t be going into details as we have discussed each as a separate topic but will only try to elaborate the difference between both.

Below is the high-level difference between both the practices.

• DevOps focuses on development by software developers, quality, and operations whereas DataOps focuses on source and target integrations, data transformation from data engineers, data quality and security.
• DevOps makes sure there is no hindrance in environment for HIGH QUALITY development cycle whereas DataOps makes sure, end users get HIGH QUALITY data, trusted data, ready to use data and actionable KPIs.
• DevOps make sure, all IT team members, operational team members, business team members are aligned to SPEED-UP the process after every sprint where DataOps makes sure, IT team members, development team members and business team members roles and responsibilities are aligned for FASTER collaborative work across teams.
• DevOps make sure, automation of all the servers management, versions control, configurations, testing, release management, etc. are AUTOMATED whereas DataOps makes sure, data acquisition, integration, metadata management, self-service, data governance, cross cloud, etc. are all in place and working in AUTOMATED fashion.
• DevOps works with stakeholders for real-time feedback after every sprint for FEEDBACK-ORIENTED optimization whereas DataOps works with stakeholders to get regular insights from new data flowing-in in real-time or in batch for RESULT-ORIENTED optimization.
• DevOps goes for regular implementations for QUICK recovery to cater failures in agile mode whereas DataOps goes for regular implementations to QUICKLY fix data quality and minimum metadata discovering in agile mode.

MLOps is also from the same family of DevOps, DevSecOps, DataOps, etc. Just like DataOps has a focus on data, MLOps focuses on Machine Learning Model’s end to end journey.

As the name says itself, MLOps (Machine Learning Operations) means from the availability of raw data till the ML model is deployed in PROD, this whole journey is called MLOps.

Please note, CI/ CD is a very critical part of MLOps as in Machine Learning world, 90% models do not go to Production. Most of the models are created, trained, and decommissioned due to N number of reasons. CI/CD plays a vital role of moving models from development to training area again and again and once confirmed by the owner, moved to Prod.

As mentioned, MLOps was extracted from the concept of DevOps, it follows the same pattern but has a different agenda.

The key phases of MLOps are: [These are taken from Best Practice on Databricks, Google and few other places.]

DLOps is like MLOps and belongs to Data Science domain.

Before we try to understand DLOps as compared to MLOps, one must understand the difference between Machine Learning and Deep Learning. (There is separate topic on difference between Machine Learning and Deep Learning)

‘It won’t be wrong to say, MACHINE LEARNING is for simpler and more structured & semi-structured use cases whereas DEEP LEARNING is for complex and unstructured use cases.’

Let’s try to understand with a simple example. If we need to find out how many cars, bikes or buses there are in structured or semi-structured datasets then it’s relatively easy as data is in rows and columns format. We can have the width, length, and height of each car, bike or bus so using MACHINE LEARNING models we can easily ready this dataset and produce expected output. But what if we give pictures to ML models to extract the same result, will it be possible? The answer is No as ML models normally work on structured or semi-structured datasets. To find out cars, bikes, or buses from pictures, DEEP LEARNING models are used which can recognize the objects in the pictures and find out which presents car or bike or a bus.