{"id":8958,"date":"2021-05-27T12:52:29","date_gmt":"2021-05-27T11:52:29","guid":{"rendered":"https:\/\/ee.yelkdev.site\/?p=8958"},"modified":"2024-03-28T13:48:28","modified_gmt":"2024-03-28T13:48:28","slug":"six-must-have-key-principles-of-data-pipeline-projects","status":"publish","type":"post","link":"https:\/\/www.equalexperts.com\/blog\/our-thinking\/six-must-have-key-principles-of-data-pipeline-projects\/","title":{"rendered":"Six \u2018must have\u2019 key principles of data pipeline projects"},"content":{"rendered":"

Facing an ever-growing set of new tools and technologies, high functioning analytics teams have come to rely increasingly on data engineers. Building and managing production data engineering pipelines is an inherently complex process, which can prove hard to scale without a systematic approach.<\/span><\/p>\n

To help navigate this complexity, we have compiled our top advice for successful solutions. Here we examine some of the key guiding principles to help data engineers (of all experience levels) effectively build and manage data pipelines. These have been compiled using the experience of the data engineers at Equal Experts. They collectively recommend the adoption of these principles as they will help you lay the foundation to create sustainable and enduring pipelines.\u00a0\u00a0<\/span><\/p>\n

About this series<\/b><\/h2>\n

This is part three in our six part series on the data pipeline, taken from our<\/span> latest playbook<\/span><\/a>. First we looked at the basics, in <\/span>What is a data pipeline<\/span><\/a>. Next we looked at the <\/span>six main benefits of an effective data pipeline<\/span><\/a>. Now we consider the \u201cmust have\u201d key principles of data pipeline projects. Before we get into the details, we just want to cover off what\u2019s coming in the rest of the series. In part four<\/a>, we look at the six key practices needed for a data pipeline. In part five<\/a> we investigate more of those practices, and in part six<\/a> we look at the many pitfalls you can encounter in a data pipeline project.\u00a0<\/span><\/p>\n

The growing need for good data engineering<\/b><\/h2>\n

If I have learned anything from my years working as a data engineer, it is that practically every data pipeline fails at some point. Broken connections, broken dependencies, data arriving too late, or unreachable external systems or APIs. There are many reasons. But, regardless of the cause, we can do a lot to mitigate the impact of a data pipeline\u2019s failure. These \u2018must have\u2019 principles are built up over the years to help to ensure that projects are successful. They are based on my knowledge, and the Equal Experts team\u2019s collective experience, gained across <\/span>many data pipeline engagements.\u00a0\u00a0<\/span><\/p>\n

Data pipelines are products<\/b><\/h2>\n

Pipelines bring data from important business sources. In many cases, they feed reports and analyses that endure for a long time. Unless your business does not expect to alter how it operates, or there are no amendments to low-level processes, the data pipelines will always need to adapt to the changes in the fundamental processes, new IT, or the data itself.\u00a0 As something that should respond to and embrace regular change, pipelines should be treated as products rather than projects.<\/span><\/p>\n

This means that there should be multi-year funding to monitor and maintain the existing pipelines. Providing headroom to add new ones, and supporting the analysis and retirement of old ones. Pipelines need product managers to understand the pipelines’ current status and operability, and to prioritise the work. (See<\/span> this <\/span>Forbes article<\/span><\/a> for a wider description of working in product-mode over project-mode.)<\/span><\/p>\n

Find ways for making common use of the data<\/b><\/h2>\n

The data collected for a given problem or piece of analysis will nearly always be useful in answering other questions. When creating pipelines, we try to architect them in a way that allows reuse, whilst also remaining lean in our implementation choices.<\/span><\/p>\n

In many cases there are simple ways of achieving this. For example, there are usually a variety of places where data is stored in the pipeline. Raw ingested data might be useful for unanticipated purposes. And it can often be made available to skilled users by providing them access to the landing zone.<\/span><\/p>\n

Appropriate identity and access technologies, such as role-based access, can support reuse while permitting strict adherence to data-protection policies and regulations. The fundamental architecture can stay the same, with access being provided by adding or amending access roles and permissions to data buckets, databases or data warehouses.<\/span><\/p>\n

A pipeline should operate as a well-defined unit of work<\/b><\/h2>\n

Pipelines have a cadence driven by the need for decision-making and limited by the availability of source data. The developers and users of a pipeline should understand and recognise this as a well-defined unit of work – whether every few seconds, hourly, daily, monthly or event-driven.<\/span><\/p>\n

Pipelines should be built around use cases<\/b><\/h2>\n

In general, we recommend building pipelines around the use case rather than the data source. This will help ensure that business value is achieved early. In some cases, the same data source might be important to several use cases, each with different cadences and access rights. Understanding when to reuse parts of pipelines and when to create new ones is an important consideration. For example, faster pipelines can always be used for slower cadences, but it typically requires more effort to maintain and adapt them. It might be simpler to create a simpler batch pipeline to meet a new low-latency use case that is not expected to change substantially than to focus on upgrading a fast-streaming pipe to meet the new requirements.\u00a0<\/span><\/p>\n

Continuously deliver your pipelines<\/b><\/h2>\n

We want to be able to amend our data pipelines in an agile fashion as the data environment and needs of the business change. So, just like any other piece of working software, continuous delivery practices should be adopted to enable continuous updates of data pipelines in production. Adopting this mindset and these practices is essential to support continuous improvement and create feedback loops that rapidly expose problems and address user feedback.<\/span><\/p>\n

Consider how you name and partition your data<\/b><\/h2>\n

Data pipelines are a mix of code and infrastructure that can become confusing as they grow if care is not taken with the naming. Pipelines will include at least a set of databases, tables, attributes, buckets, roles, etc., and they should be named in a consistent way to facilitate understanding and maintenance of the pipelines, as well as make the data meaningful to the end-users.<\/span><\/p>\n

In many architectures, naming will directly affect how your data is partitioned, which in turn affects the speed of the search and retrieval of data. Consider what will be the most frequent queries when specifying bucket names, table partitions, shards, and so on.<\/span><\/p>\n

Want to know more?<\/b><\/h2>\n

These guiding principles have been born out of our engineers and use each of their 10+ years of data engineering for end-to-end machine learning solutions. We are sure there are lots of other principles, so please do let us know of any approaches you have found effective in managing data pipelines.\u00a0<\/span><\/p>\n

In our next blog post in this series we will start laying out some of the key practices of data pipelines.\u00a0 Until then, for more information on data pipelines in general, take a look at our <\/span>Data Pipeline Playbook<\/span><\/a>.\u00a0\u00a0<\/span><\/p>\n

Contact us!<\/b><\/h2>\n

If you\u2019d like us to share our experience of data pipelines with you, get in touch using the form below.<\/span><\/p>\n

 <\/p>\n

\n\t\t\t\t\t\t