From self-driven cars to automatic tagging in images, data science has come a long way. Data scientists and analysts have become an integral part of any organisation because of the value they add. But, in all honesty, a data scientist is only as good as the data they work with. Most of the organisations today have their data stored in a variety of formats and across numerous platforms. Here comes a need for data engineers!
Data engineers are people who make this data workable for the data scientists and analysts. Data engineers are responsible for building pipelines that transform the heaps of data into a format that is usable for data scientists. They mostly work behind the scenes and hence are devoid of all the glamors of a data scientist/analyst – but mind you, they’re equally (if not more) essential to the functioning of any organisation.
If data scientists are race car drivers, data engineers are race car builders. The former gets the excitement of speeding along a track and thrill of winning in front of an applauding crowd. The latter, on the other hand, gets the joy of tuning engines and creating a powerful, robust machine. A race car builder makes the job of the driver a lot easier (or tougher, depending on the quality of the builder).
In this respect, data engineers are pretty much the unsung heroes of any data analytics team. Without a sound data engineer, a data scientist will just be scratching his head looking for clues in unformatted data.
Let’s see what all does the job of a data engineer entail.
For the sake of better understanding, let’s assume you’re a data engineer at a competitor of Swiggy (let’s name it Twiggy). You have an app that users can use on any device and access your services. They order food, the order gets redirected to the appropriate restaurant, the food gets picked up from there, and it reaches you.
To keep this service in sync, you’ll need:
- A mobile app for users
- A mobile app for restaurant owners
- A robust server to handle multiple requests at once.
As you might have understood by now, this application will generate HUGE amounts of data. Further, you’ll need some data stores:
- A database that contains the users’ and restaurants’ details.
- Server access logs. These will include any request made to the server from the app.
- Server error logs containing all the server-side errors.
- App event logs. These will contain information about what actions users or restaurant owners took in the application.
- App error logs that contain app-based errors.
- Customer service database. This will contain the data about your interaction with your customers.
Now, let’s say a data scientist of your team wants to analyse the user behaviour on your services and see what actions correlate with high-spending users. To help them create this, you’ll need to combine all the information from the server access logs and the app event logs.
You’ll need to:
- Gather app analytics logs regularly.
- Combine app analytics logs with server log entries for the relevant users.
- Develop an API that returns the event history of any user.
That’s a lot of work right there!
To do all of this, you’ll need to create a pipeline that can efficiently ingest mobile app logs and server logs in real-time, parse them, and link them to the appropriate user. Further, you’ll need to store the parsed logs in a database so that the API can easily query them. There’ll be a lot of servers you’ll need to spin up behind a load balancer for parsing the incoming logs.
Majority of the issues you’ll encounter will be around distributed systems and reliability. If you have millions of devices to gather logs from and dynamic demands (in the afternoon, you get many log entries, but not as many during midnight), you’ll need to develop a system that can automatically scale the server count up and down depending on the traffic.
the next biggest thing
Roughly, the operations in a generic data engineering pipeline undergo the following phases:
- Ingestion: gathering the needed data.
- Processing: processing the data to get the desired result.
- Storage: storing the result for faster retrieval.
- Access: enabling a tool to access the results of the data pipeline.
A data engineer is expected to possess the knowledge in the following domains.
- Data Warehousing:
- RDBMS like MySQL, MS SQL Server, etc.
- NoSQL databases like HBase, MongoDB, CouchDB, Cassandra, etc.
- Data Collection:
- RESTful APIs
- Knowledge of data modelling and expertise in SQL.
- Data transformation:
- ETL tools like Informatica, Datastage, Redpoint, etc.
- Any scripting language like Python, Ruby, Perl, etc.
Let’s look at some myths and misconceptions revolving around the lives and jobs of these data engineers.
Myth #1: Data engineers extract value from the collected data.
There’s a lot that comes in between collecting the data and extracting the knowledge. Data engineers are primarily responsible for converting the data into a form suitable for scientists to analyse and work on. In this respect, they don’t extract any value from the data, in fact, they present the data on a plate to the data scientists who then discover value from it.
Myth #2: Data engineers need to make all the data pristine.
You’ll realise the preposterousness of this if you read the above sentence slowly. A data engineer deals with incoming data streams throughout the day. This data needs to be cleaned and acted upon immediately lest it’ll turn stale. By stale, we mean uninsightful and old. So, data engineers don’t go about making all of the data pristine. They work with the data at hand combined with other data that are necessary for the problem at hand. Cleaning the complete datasets will take months, and by then it’ll be of no use.
Myth #3: Data engineers dump the data on readymade tools and enjoy the clean/workable data as the output.
Please don’t say it out loud in front of any data engineer. Ever. No self-respecting data engineer will tolerate such a blatant insult. Like any other engineer (software, mechanical, chemical, etc.), data engineers require having their thinking caps on all the while. There’s no one-shoe-fits-all approach in data engineering, and data engineers need to mould algorithms to fit their use-case continuously. They need to be aware of the latest techniques and methods around their work to ensure perfect efficiency.
Myth #4: Data engineers are just software engineers who work on Big Data.
Software engineers work on mobile/web app development. Their job involves lots of diverse problems and the difficulty is in managing the tasks – think, communicate and organise the code. Data engineers, on the other hand, generally have fewer problems, but the individual problems are much more difficult technically. From outlook to the skillset, everything is entirely different for a data engineer than it is for a software engineer.