And thank you everyone for coming to today's session. Before we delve into our discussion, let me first give a very brief introduction about myself.

I am Ilana Makover and I am a machine learning engineer at BlueVine. Now let's get back to the real reason everyone's here, which is to let your data tell its story.

Let's talk about a fictional streaming service.

Let's call this service Flicks. Every time you hit that play button, Flicks quietly collects information.

It tracks things like how long you watched, whether you paused, or skipped ahead. One data point they store, let's say it's called average watch duration.

That one data point behind the scenes has a whole story. When you press Flick's play button, an event is sent by the playback service.

That event is then collected into the streaming logs. Then a daily analytics job reads that event to calculate the user's average watch time.

Then the recommendation model reads this data point, average watch duration, in addition to others, to determine what TV shows and movies to suggest to you tomorrow.

Next, your marketing team reads this data point, average watch duration, in addition to others, to decide which email you receive in the next email campaign.

And finally, the BI dashboard reads this data point, average watch duration, aggregates over all users, and then shows executive engagement trends.

This one data point, average watch duration, quietly flows through many different systems, powering recommendations, marketing, and business decisions.

Oftentimes, people look at data at face value. They check things like the data type, data integrity, and trends in the data. But Many forget to zoom out and look at the bigger picture.

Let's go back to our Flicks example. Let's say Flick changed its data point of average watch duration from seconds to minutes.

Would you know the downstream impact of such a change? Would you know which teams have to be involved in such a change?

Which models have to be retrained, dashboards need to be updated, and let's say Flick's recommendation engine starts acting weird suddenly.

Would you be able to identify upstream causes of such behavior and trace it back to this updated data point? And finally, this is an aspect some of us overlook.

Is this data even used? Perhaps Flick is still getting data from an external provider, yet no one is using it.

Perhaps Flick is generating data for a research project that ended ages ago. Now there is data floating around, taking up space, costing money.

This is where data lineage enters the picture. Data lineage allows us to understand and even visualize this network of dependencies and allows us to quickly answer these questions in front of you.

Data lineage is a story of listening to your data as it jumps across your data pipeline.

Listening to things like where it came from, how it moved, and how it was used.

These stories allow us to see the data's true value. Today we'll explore how to listen to that story and together we'll build a lightweight data lineage solution.

Our agenda for today will be as follows. We will first discuss what we want to listen to.

This will answer three major questions: What data? Which data interactions? And what details? Then we will go into our data lineage solution step by step, which of course answers the above questions.

And finally, we'll top it off with a great visualization.

The first step when we want to plan our data lineage solution is to think about what data you’d like to track. For better or for worse, not all data is created equal.

Some data might be more useful to your organization than others.

Data can be obtained from an external provider, and it can be generated in-house. Right? Companies may want to know some information about their users.

They could buy this information from an external provider, and other information they can generate in-house. Do you want to track data obtained from an external provider?

Data generated in-house? Data can be stored across multiple databases and data warehouses.

Do you want to track data from specific databases? Data from specific data warehouses? Some of them, all of them.

For our example purposes, we will say we want to track all of our processes that read and write our in-house generated data that is stored in our tabular DB and our graph.

Amazing. Now we get on to our next section, which is data interactions. We will now start exploring data interactions in our system. Most data journeys are composed of many interactions, whether it be reading from a database, dumping a file onto some cloud storage, or interacting with a model.

To understand the data journey, we will need to identify our interactions between agents in our system and the data itself. You could say these data pipeline interactions help shape the data's character, like in a story.

Let’s walk back to our original example, which includes a recommendation model.

This model makes a decision on what TV shows and movies to recommend to you based on input data.

This interaction between data and the model is something we want to track. This is vital. In addition to tracking this specific interaction between this data and this specific model, we also want to track other interactions between our data and all of our models.

So we want to find the common entry point where this data interaction happens, where all of our data and our models interact in this one common area.

And here, our engineering best practices come into play. We will be under the assumption that your team created some generic API to handle model inference that is model agnostic.

Amazing. And this generic API, right, it could be that some models call some of the methods here, while other models call other methods, but at the end of the day, based on our engineering best practices, all models will begin their model inference journey at a common entry point.

And for our purposes, let’s say it all begins.

All the models, their common entry point is in this predict method. This predict method is where we want to locate our data interaction for data models.

Now we have located one such example of a data interaction. Now we simply have to locate all the other major data interactions for your APIs, microservices, and internal tools which leverage your data.

This is the key. This will make implementing your solution much easier.

Once you have located and leveraged these central entry points, you can then record valuable information about your data and its current location in its journey.

Once you localize this part, the storytelling bit will seamlessly fall into place. One final aspect we need to discuss is categorization.

Every data interaction will be categorized in a very simplistic manner. Either it is a read interaction or it is a write interaction.

Either it is consuming data, reading data, or writing data; it is generating data.

Now let's tie our section together here with a clean example, and this example will follow us through today's session.

So let's say we have a central method called retabular DB, and our group uses this method in order to query from our tabular database.

This is our central entry point. We have now localized this. Now we want to categorize it as a read interaction because it is consuming data.

It is reading data. Again, this method is used to query our tabular databases.

The hardest part of all this will be deciding what information is critical to understanding your data. Every story needs a good genesis. What is your data's hero's journey?

We will go over some possible examples now, but keep in mind you will have to answer the overarching question of what information will be useful to understand your data.

Again, some examples. What process is requesting this data? If we go back to our example, we'll say a recommendation engine is requesting this data.

When did this request occur? November 4th, 2025.

Which main entry point was called? The retabular DB method. What data was requested? We can say two columns were requested: average watch duration and average time paused.

What is the source of the data? We can say a table called user watching metrics.

What is the source type of the data? It is a database. And finally, what type of interaction is this? This is a read interaction.

Now before we dig into the implementation aspect, let's take a little step back and discuss the functional requirements of our data lineage solution.

Data lineage should trace, visualize, and understand the journey of data across our systems from the moment that data is consumed through its transformations to its ultimate points of use. We have five functional requirements. The first one is that we want to list every possible downstream process, model, or system that uses a data point.

Next, we want to identify exactly where a data point starts. Who creates this data point? Which process, model, or system creates this data point? Next, we want to visualize the full data journey. This will help us both understand the possible downstream impact of data failure or data change and also identify upstream causes of odd behavior.

Put simply, we want to understand if a data point is even used, and if it’s not used, let's eliminate it and improve efficiency.

And finally, our last functional requirement: we want lineage to be automatically collected and updated as our jobs evolve, as our systems evolve. So we want to have the latest view of our pipelines.

Now we get to our high-level solution. Now we can focus on listening to our data as it moves across our pipeline. In front of you is the lightweight in-house data lineage solution. Our solution will require two things: one of which is a queuing system of your choice and a table.

The queuing system will need to have a mechanism to ensure that no two processes interfere with each other.

Identical messages can be queued. So to break this down even further, let's say a message is in the queue. An identical message cannot be queued at this point.

And the table will store all of our data interactions. Now let's go step by step into our solution.

Once the information details are agreed upon and finalized, the main entry points which we identified earlier, each main entry point will have to obtain the relevant data details, and they will get these data details, package them as one message, and send it to a queue.

We mentioned an entry point earlier called read tabular DB. As mentioned, all of our queries to our tabular database enter this location.

And let's say our recommendation engine calls this entry point three different times for three different queries.

Let's follow the light green here. We can see three different times for three different queries. That means we see three different messages in the raw interactions part.

So now we have three different messages. Let's break this down even further. Let's talk about a very specific example.

Let's say our read tabular DB gets this query as input. This query is very straightforward, very simple.

We can see select two columns. One is called average watch duration, and the other is average time paused from user watching metrics. The read tabular DB entry point has to get this query, parse it, extract the relevant information in order to write something like this to extract this message from that data interaction.

And we see here again this is all happening in read tabular DB. It takes this one query. It extracts the relevant data details.

It extracts that the process that called this entry point is called the recommendation engine. It extracts the request time, which is November 4th, 2025.

It extracts two columns that were called. One is called average watch duration, and the other is called average time paused. It also extracts that the table that was requested.

The source is called user watching metrics, etc. This is an example of one process of one entry point that has to obtain this information and send it as a message to a queue.

This is all happening at the same time that the existing process is happening.

So, the relational database and all other main entry points have to extract this information and send it as a message to a queue very quickly because once this happens, it needs to continue on with its regularly scheduled programming.

Now, this one message here can be a bit sloppy and not so easy to read.

We will call it the data's first draft of storytelling. Right? It looks clean to you now, but imagine the query were slightly different in our case.

Imagine we were querying 20 columns. Then the message would look very sloppy, right?

So now we have a very sloppy message, a lot of information. And now we get on to our next part of the process.

Now we have a new independent process. This process, what it does, is it dequeues from that queue which has all of our messages that talk about many data interactions, and this process takes a message and splits it into more bite-sized pieces where each piece talks about exactly one data point.

Right? So why do we do this? Because When you want to tell a story, you want to talk clearly and concisely.

Let's go back to our example at this stage. Our example of one message, by the time it gets to this independent process, it gets split into two different messages.

If we look at the top part of the screen, this message is more or less the same message that we have seen earlier.

The only difference is that what is marked in red now talks about exactly one data point.

Now we only talk about the column average watch duration in the message, and then if we look at the bottom message, we only talk about average time paused.

So again, this part of the process simply takes a message and breaks it down into multiple messages where each message talks about exactly one data point.

Both these messages are now sent to a new queue. Now we get to one of the last parts of the architecture.

Now we get to populate the data lineage table. This new independent process will dequeue messages from that second queue, and it will update and insert these messages into a table.

This is how it will look like. Those two messages that we have seen in the previous step will be two rows now in our data lineage table.

Amazing. We can see here we have in our table the process which is called the recommendation engine. The entry point is called the tabular DB.

The data point is average time paused. The source is user watching metrics. Amazing. Again, this is done in update and insert format when we interact with the table.

This is an example of just that one message that we saw turned into two messages and now into two rows.

But imagine all of our data interactions for all of our processes are in the table. Now we'll have much more information and with this information at the moment we can do so much with this when it's just in the table format.

Ilana Makover: Let Your Data Tell Its Story | PyData Tel Aviv 2025

PyData is an educational program of NumFOCUS, a 501(c)3 non-profit organization in the United States. PyData provides a forum for the international community of users and developers of data analysis tools to share ideas and learn from each other. The global PyData network promotes discussion of best practices, new approaches, and emerging technologies for data management, processing, analytics, and visualization. PyData communities approach data science using many languages, including (but not limited to) Python, Julia, and R.

We aim to be an accessible, community-driven conference, with novice to advanced level presentations. PyData tutorials and talks bring attendees the latest project features along with cutting-edge use cases.

PyData

데이터 리니지(data lineage)는 데이터의 이동, 변환, 사용 내역을 추적하고 시각화하여 데이터의 가치와 흐름을 이해하는 데 필수적입니다.

데이터 리니지 솔루션을 구축하려면 추적할 데이터의 유형, 데이터 상호 작용의 공통 진입점, 그리고 데이터 흐름에 대한 중요한 세부 정보(예: 프로세스, 시간, 데이터 소스, 상호 작용 유형)를 정의해야 합니다.

효과적인 데이터 리니지는 데이터 문제 발생 시 디버깅 시간을 단축하고, 데이터 변경의 하위 시스템 영향을 파악하며, 사용되지 않는 데이터를 식별하여 시스템 효율성을 개선하는 데 기여합니다.

데이터 리니지의 중요성: 데이터의 이야기 경청하기

이 세션에서는 데이터가 스스로 이야기를 하도록 하는 방법에 대해 논의합니다. 특히 가상의 스트리밍 서비스인 'Flicks'의 예시를 통해 **하나의 데이터 포인트 뒤에 숨겨진 전체 스토리**를 이해하는 것이 얼마나 중요한지 강조합니다. Flicks는 사용자가 재생 버튼을 누를 때마다 시청 시간, 일시 중지 여부, 건너뛰기 여부 등 다양한 정보를 수집하며, 이 데이터는 추천, 마케팅, 비즈니스 결정에 중요한 영향을 미칩니다.

데이터는 종종 액면 그대로 받아들여지지만, **더 큰 그림을 보지 못하면 중요한 다운스트림 영향을 간과할 수 있습니다.** 예를 들어, Flicks가 평균 시청 시간 데이터 단위를 초에서 분으로 변경할 경우, 이 변경이 어떤 팀에 영향을 미치고, 어떤 모델을 재학습시켜야 하며, 어떤 대시보드를 업데이트해야 하는지 파악하기 어렵습니다. 또한, 추천 엔진이 이상하게 작동할 때 그 업스트림 원인을 추적하는 것도 어렵습니다. 심지어 데이터가 실제로 사용되고 있는지 여부도 파악하기 힘들 수 있습니다.

이러한 문제들을 해결하기 위해 **데이터 리니지가 필요합니다.** 데이터 리니지는 데이터가 데이터 파이프라인을 따라 이동할 때 그 이야기를 경청하고, 데이터가 어디에서 왔고, 어떻게 이동했으며, 어떻게 사용되었는지 이해하고 시각화하여 데이터의 진정한 가치를 발견하는 데 도움을 줍니다. 본 세션에서는 데이터 리니지 솔루션을 구축하는 방법을 단계별로 살펴봅니다.

데이터 리니지 솔루션 계획: 무엇을 경청할 것인가?

데이터 리니지 솔루션을 계획할 때 가장 먼저 고려해야 할 것은 **어떤 데이터를 추적할 것인지 결정하는 것입니다.** 모든 데이터가 동일하게 중요하지 않으므로, 조직에 더 유용한 데이터를 식별해야 합니다. 외부 제공업체에서 얻은 데이터와 자체적으로 생성한 데이터 중 어떤 것을 추적할지, 특정 데이터베이스나 데이터 웨어하우스의 데이터를 추적할지 등을 결정해야 합니다. 예를 들어, 테이블 형식 DB와 그래프에 저장된 자체 생성 데이터를 읽고 쓰는 모든 프로세스를 추적할 수 있습니다.

다음으로, **데이터 상호 작용을 식별하는 것이 중요합니다.** 데이터 여정은 데이터베이스에서 읽거나, 클라우드 스토리지에 파일을 덤프하거나, 모델과 상호 작용하는 등 다양한 상호 작용으로 구성됩니다. 이러한 상호 작용은 데이터의 특징을 형성하는 데 기여하며, 데이터 파이프라인의 에이전트와 데이터 자체 간의 관계를 이해하는 데 필수적입니다. 특히, 데이터와 모델 간의 상호 작용을 추적하는 것이 매우 중요하며, 이를 위해 모델 추론을 처리하는 **공통 API와 같은 중앙 진입점을 활용해야 합니다.**

모든 데이터 상호 작용은 **읽기 상호 작용과 쓰기 상호 작용으로 단순하게 분류될 수 있습니다.** 데이터를 소비하거나(읽기), 데이터를 생성하는(쓰기) 방식으로 구분합니다. 예를 들어, 테이블 형식 데이터베이스를 쿼리하는 `retabular DB`라는 중앙 메서드를 통해 데이터를 소비하는 것은 '읽기 상호 작용'으로 분류됩니다. 이처럼 중앙 진입점을 지역화하고 상호 작용 유형을 분류하는 것이 솔루션 구현을 용이하게 합니다.

마지막으로, **데이터를 이해하는 데 어떤 정보가 중요한지 결정해야 합니다.** 이는 데이터의 '영웅 여정'을 파악하는 데 필수적입니다. 예를 들어, 어떤 프로세스가 데이터를 요청하는지(예: 추천 엔진), 언제 요청이 발생했는지(예: 2025년 11월 4일), 어떤 주요 진입점이 호출되었는지(예: `retabular DB` 메서드), 어떤 데이터가 요청되었는지(예: 평균 시청 시간, 평균 일시 중지 시간), 데이터의 소스는 무엇인지(예: 사용자 시청 메트릭 테이블), 그리고 어떤 유형의 상호 작용인지(예: 읽기 상호 작용) 등의 세부 정보를 파악해야 합니다.

데이터 리니지 솔루션의 기능적 요구 사항

데이터 리니지 솔루션은 데이터의 여정을 추적, 시각화 및 이해해야 합니다. 이를 위한 5가지 기능적 요구 사항은 다음과 같습니다. 첫째, **데이터 포인트를 사용하는 모든 다운스트림 프로세스, 모델 또는 시스템을 나열해야 합니다.** 둘째, 데이터 포인트가 정확히 어디에서 시작되는지, 즉 누가 이 데이터 포인트를 생성하는지 파악해야 합니다. 셋째, **전체 데이터 여정을 시각화하여 데이터 실패나 변경의 다운스트림 영향을 이해하고 이상 동작의 업스트림 원인을 식별할 수 있어야 합니다.** 넷째, 데이터 포인트가 실제로 사용되고 있는지 여부를 이해하고, 사용되지 않는다면 제거하여 효율성을 개선해야 합니다. 마지막으로, **리니지는 작업과 시스템이 발전함에 따라 자동으로 수집 및 업데이트되어야 합니다.**

가벼운 데이터 리니지 솔루션 구축

가벼운 사내 데이터 리니지 솔루션은 크게 두 가지 요소로 구성됩니다. 하나는 선택한 **대기열 시스템**이며, 다른 하나는 모든 데이터 상호 작용을 저장할 **테이블**입니다. 대기열 시스템은 두 프로세스가 서로 간섭하지 않도록 보장하며, 테이블은 모든 데이터 상호 작용의 기록을 보관합니다.

솔루션의 첫 번째 단계는 **주요 진입점에서 데이터 세부 정보를 확보하고 이를 메시지로 패키징하여 대기열로 보내는 것입니다.** 예를 들어, `테이블 DB 읽기` 진입점은 들어오는 쿼리를 구문 분석하여 추천 엔진, 요청 시간, 요청된 열(평균 시청 시간, 평균 일시 중지 시간), 소스 테이블(사용자 시청 메트릭)과 같은 관련 정보를 추출합니다. 이 정보는 하나의 조잡한 '초고' 메시지로 대기열에 들어갑니다. 이 과정은 기존 프로세스와 동시에 매우 빠르게 발생하여 정규 프로그래밍을 방해하지 않아야 합니다.

다음 단계는 **큐에서 메시지를 꺼내 각 메시지가 정확히 하나의 데이터 포인트를 이야기하는 더 작은 조각으로 분할하는 것입니다.** 이는 명확하고 간결한 스토리텔링을 위해 필수적입니다. 예를 들어, 평균 시청 시간과 평균 일시 중지 시간을 모두 포함하는 하나의 메시지는 평균 시청 시간에 대한 메시지와 평균 일시 중지 시간에 대한 메시지 두 개로 분할됩니다. 이 분할된 메시지들은 새로운 큐로 전송됩니다.

마지막으로, **데이터 계보 테이블을 채웁니다.** 두 번째 큐에서 메시지를 꺼내 테이블에 업데이트하거나 삽입합니다. 이렇게 하면 각 메시지는 테이블의 하나의 행이 되며, 프로세스, 진입점, 데이터 포인트, 출처 등 구체적인 정보가 기록됩니다. 이 테이블만으로도 데이터 포인트의 종속성을 파악하는 등 **다양한 추론과 분석이 가능합니다.** 예를 들어, 추천 엔진이 의존하는 4가지 데이터 포인트를 식별하거나, 이 데이터 포인트를 누가 작성했는지(재생 서비스, 데이터 수집기 등) 파악할 수 있습니다.

데이터 이야기 시각화 및 실제 적용

모든 데이터 상호 작용이 테이블에 기록되면, **재귀를 사용하는 헬퍼 메서드를 활용하여 데이터의 전체 여정을 스토리로 구성할 수 있습니다.** 이 헬퍼 메서드는 데이터 포인트를 입력으로 받아 해당 데이터 포인트의 전체 여정(원하는 만큼의 종속성 수준 포함)을 반환합니다. 이는 특정 데이터 포인트에 누가 쓰고, 누가 읽으며, 어떤 프로세스가 관여하는지 등을 단계별로 추적하는 과정을 거칩니다.

Python 패키지인 **PiViz를 활용하여 이 데이터 스토리를 시각화할 수 있습니다.** 예를 들어, '평균 시청 시간' 데이터 포인트에 대한 이야기를 그리면, '일일 사용자 지표' 프로세스가 이 데이터를 쓰고, 두 개의 다른 프로세스가 이 데이터를 활용하는 것을 시각적으로 확인할 수 있습니다. 이를 통해 **데이터가 사용 중인지 여부를 명확하게 파악할 수 있습니다.** 만약 어떤 프로세스도 특정 데이터 포인트를 활용하지 않고 쓰기만 한다면, 그 데이터는 '고아 데이터'로 분류되어 제거될 수 있습니다 (예: 평균 건너뛰기 횟수).

이 시각화는 데이터 리니지의 기능적 요구 사항을 충족하는 데 큰 도움이 됩니다. 예를 들어, 평균 시청 시간이 초에서 분으로 업데이트될 경우, **추천 엔진과 BI 참여 추세가 영향을 받을 수 있음을 명확히 확인할 수 있어 디버깅 시간을 줄이고 노력의 초점을 맞출 수 있습니다.** 반대로, 추천 엔진이 이상하게 작동하기 시작하면, 이상 동작의 **업스트림 원인(예: 평균 시청 시간 데이터)을 식별하여 디버그 시간을 지역화할 수 있습니다.**

데이터의 이야기에 귀 기울이고 데이터의 여정을 파악함으로써, **최신 데이터 파이프라인과 시스템을 이해하고 디버깅 시간을 줄일 수 있습니다.** 데이터 오류나 변경의 다운스트림 영향을 빠르게 파악하여 시간과 에너지를 효율적으로 집중할 수 있으며, 이상한 동작의 업스트림 원인 파악에도 도움이 됩니다. 또한, 데이터 계보를 통해 **낭비를 없애고 효율성을 높일 수 있습니다.** 예를 들어, 특정 외부 제공업체의 데이터가 사용되지 않는다는 것을 명확히 알게 되면 해당 업체와의 계약을 중단할 수도 있습니다.

발표자가 제안하는 데이터 계보 솔루션을 구축하기 위한 세 가지 주요 질문은 무엇인가요?

Flicks 예시에서 평균 시청 시간 데이터 포인트가 초에서 분으로 변경될 경우 발생할 수 있는 주요 다운스트림 영향은 무엇이며, 데이터 계보가 이러한 상황에서 어떻게 도움이 될 수 있을까요?

제시된 데이터 계보 솔루션 아키텍처에서 '대기열 시스템'과 '테이블'은 각각 어떤 역할을 하며, 메시지가 큐에서 테이블로 이동하는 과정은 어떻게 되나요?

데이터 계보 테이블을 활용하여 추천 엔진의 '1단계 종속성'과 '2단계 종속성'을 어떻게 파악할 수 있는지 설명해주세요.

데이터 계보 시각화를 통해 데이터가 '고아'인지, 즉 사용되지 않는지 여부를 어떻게 판단할 수 있으며, 이는 조직에 어떤 이점을 가져다주나요?

오늘 세션에 와주신 모든 분들께 감사드립니다. 논의에 들어가기 전에 먼저 제 소개를 아주 간단하게 드리겠습니다.

저는 일라나 마코버이고 BlueVine의 머신 러닝 엔지니어입니다. 이제 모두가 여기에 온 진짜 이유, 즉 데이터가 스스로 이야기를 하도록 하는 것에 대해 이야기해 봅시다.

가상의 스트리밍 서비스에 대해 이야기해 보겠습니다.

이 서비스를 Flicks라고 부르겠습니다. 여러분이 재생 버튼을 누를 때마다 Flicks는 조용히 정보를 수집합니다.

시청 시간, 일시 중지 여부, 건너뛰기 여부 등을 추적합니다. 저장하는 데이터 포인트 중 하나를 평균 시청 시간이라고 가정해 보겠습니다.

그 하나의 데이터 포인트 뒤에는 전체 스토리가 있습니다. Flicks 재생 버튼을 누르면 재생 서비스에서 이벤트가 전송됩니다.

그런 다음 해당 이벤트는 스트리밍 로그에 수집됩니다. 그런 다음 일일 분석 작업은 해당 이벤트를 읽어 사용자의 평균 시청 시간을 계산합니다.

그런 다음 추천 모델은 이 데이터 포인트, 즉 평균 시청 시간을 다른 데이터와 함께 읽어 내일 어떤 TV 프로그램과 영화를 추천할지 결정합니다.

다음으로 마케팅 팀은 이 데이터 포인트, 즉 평균 시청 시간을 다른 데이터와 함께 읽어 다음 이메일 캠페인에서 어떤 이메일을 받을지 결정합니다.

마지막으로 BI 대시보드는 이 데이터 포인트, 즉 평균 시청 시간을 읽고 모든 사용자를 집계한 다음 경영진 참여 추세를 보여줍니다.

이 하나의 데이터 포인트, 즉 평균 시청 시간은 여러 시스템을 통해 조용히 흘러 추천, 마케팅 및 비즈니스 결정을 지원합니다.

종종 사람들은 데이터를 액면 그대로 봅니다. 데이터 유형, 데이터 무결성 및 데이터 추세와 같은 것을 확인합니다. 하지만 많은 사람들이 확대해서 더 큰 그림을 보는 것을 잊습니다.

Flicks 예제로 돌아가 보겠습니다. Flicks가 평균 시청 시간 데이터 포인트를 초에서 분으로 변경했다고 가정해 보겠습니다.

이러한 변경의 다운스트림 영향을 알 수 있습니까? 이러한 변경에 어떤 팀이 참여해야 하는지 알 수 있습니까?

어떤 모델을 재교육해야 하고, 대시보드를 업데이트해야 하며, Flicks의 추천 엔진이 갑자기 이상하게 작동하기 시작한다고 가정해 보겠습니다.

이러한 동작의 업스트림 원인을 식별하고 이 업데이트된 데이터 포인트로 다시 추적할 수 있습니까? 그리고 마지막으로, 이것은 우리 중 일부가 간과하는 측면입니다.

이 데이터가 실제로 사용되고 있습니까? 아마도 Flicks는 여전히 외부 제공업체에서 데이터를 가져오고 있지만 아무도 사용하지 않고 있습니다.

어쩌면 플릭은 오래전에 종료된 연구 프로젝트를 위해 데이터를 생성하고 있을지도 모릅니다. 이제 데이터가 떠돌아다니며 공간을 차지하고 비용을 발생시키고 있습니다.

이때 데이터 리니지가 등장합니다. 데이터 리니지를 통해 이러한 의존성 네트워크를 이해하고 시각화할 수 있으며, 눈앞의 질문에 빠르게 답변할 수 있습니다.

데이터 리니지는 데이터가 데이터 파이프라인을 따라 이동할 때 데이터를 경청하는 이야기입니다.

데이터가 어디에서 왔는지, 어떻게 이동했는지, 어떻게 사용되었는지 등을 경청하는 것입니다.

이러한 이야기를 통해 데이터의 진정한 가치를 알 수 있습니다. 오늘은 그 이야기를 경청하는 방법을 살펴보고 함께 가벼운 데이터 리니지 솔루션을 구축해 보겠습니다.

오늘의 의제는 다음과 같습니다. 먼저 무엇을 경청하고 싶은지 논의하겠습니다.

여기에는 세 가지 주요 질문에 대한 답변이 포함됩니다. 어떤 데이터? 어떤 데이터 상호 작용? 그리고 어떤 세부 사항? 그런 다음 데이터 리니지 솔루션을 단계별로 살펴보겠습니다. 물론 위의 질문에 대한 답변도 포함됩니다.

마지막으로 멋진 시각화로 마무리하겠습니다.

데이터 리니지 솔루션을 계획할 때 가장 먼저 해야 할 일은 추적할 데이터를 생각하는 것입니다. 좋든 싫든 모든 데이터가 동일하게 생성되는 것은 아닙니다.

일부 데이터는 다른 데이터보다 조직에 더 유용할 수 있습니다.

데이터는 외부 제공업체에서 얻을 수도 있고, 자체적으로 생성할 수도 있습니다. 그렇죠? 기업은 사용자에 대한 몇 가지 정보를 알고 싶어할 수 있습니다.

이러한 정보를 외부 제공업체에서 구매할 수도 있고, 자체적으로 생성할 수도 있습니다. 외부 제공업체에서 얻은 데이터를 추적하시겠습니까?

자체적으로 생성한 데이터는요? 데이터는 여러 데이터베이스와 데이터 웨어하우스에 저장할 수 있습니다.

특정 데이터베이스의 데이터를 추적하시겠습니까? 특정 데이터 웨어하우스의 데이터는요? 일부, 전부 다요.

예를 들어, 테이블 형식 DB와 그래프에 저장된 자체 생성 데이터를 읽고 쓰는 모든 프로세스를 추적한다고 가정해 보겠습니다.

훌륭합니다. 이제 다음 섹션인 데이터 상호 작용으로 넘어갑니다. 이제 시스템에서 데이터 상호 작용을 살펴보겠습니다. 대부분의 데이터 여정은 데이터베이스에서 읽거나, 일부 클라우드 스토리지에 파일을 덤프하거나, 모델과 상호 작용하는 등 많은 상호 작용으로 구성됩니다.

데이터 여정을 이해하려면 시스템의 에이전트와 데이터 자체 간의 상호 작용을 식별해야 합니다. 이러한 데이터 파이프라인 상호 작용은 마치 이야기 속 인물처럼 데이터의 특징을 형성하는 데 도움이 된다고 할 수 있습니다.

추천 모델이 포함된 원래 예제로 돌아가 보겠습니다.

이 모델은 입력 데이터를 기반으로 어떤 TV 프로그램과 영화를 추천할지 결정합니다.

데이터와 모델 간의 이러한 상호 작용은 추적해야 합니다. 이는 매우 중요합니다. 이 특정 데이터와 이 특정 모델 간의 상호 작용을 추적하는 것 외에도 데이터와 모든 모델 간의 다른 상호 작용도 추적하려고 합니다.

따라서 이 데이터 상호 작용이 발생하는 공통 진입점, 즉 모든 데이터와 모델이 이 하나의 공통 영역에서 상호 작용하는 곳을 찾고 싶습니다.

여기서 엔지니어링 모범 사례가 적용됩니다. 팀에서 모델에 구애받지 않는 모델 추론을 처리하기 위해 몇 가지 일반 API를 만들었다고 가정하겠습니다.

훌륭합니다. 그리고 이 일반 API는 일부 모델이 여기에 있는 일부 메서드를 호출하는 반면 다른 모델은 다른 메서드를 호출할 수 있지만 결국 엔지니어링 모범 사례를 기반으로 모든 모델은 공통 진입점에서 모델 추론 여정을 시작합니다.

그리고 우리의 목적을 위해 모든 것이 시작된다고 가정해 보겠습니다.

모든 모델의 공통 진입점은 이 예측 메서드에 있습니다. 이 예측 메서드는 데이터 모델에 대한 데이터 상호 작용을 찾을 위치입니다.

이제 데이터 상호 작용의 한 가지 예를 찾았습니다. 이제 API, 마이크로서비스 및 데이터를 활용하는 내부 도구에 대한 다른 모든 주요 데이터 상호 작용을 찾아야 합니다.

이것이 핵심입니다. 이렇게 하면 솔루션 구현이 훨씬 쉬워집니다.

이러한 중앙 진입점을 찾아 활용하면 데이터와 여정에서 현재 위치에 대한 귀중한 정보를 기록할 수 있습니다.

이 부분을 지역화하면 스토리텔링 비트가 원활하게 제자리에 놓입니다. 마지막으로 논의해야 할 측면은 분류입니다.

모든 데이터 상호 작용은 매우 단순한 방식으로 분류됩니다. 읽기 상호 작용이거나 쓰기 상호 작용입니다.

데이터를 소비하거나, 데이터를 읽거나, 데이터를 쓰거나, 데이터를 생성합니다.

이제 깨끗한 예제로 이 섹션을 함께 묶겠습니다. 이 예제는 오늘 세션 내내 우리를 따라올 것입니다.

예를 들어 retabular DB라는 중앙 메서드가 있고 우리 그룹은 이 메서드를 사용하여 테이블 형식 데이터베이스에서 쿼리한다고 가정해 보겠습니다.

이것이 우리의 중앙 진입점입니다. 이제 이것을 지역화했습니다. 이제 데이터를 소비하고 있기 때문에 읽기 상호 작용으로 분류하려고 합니다.

데이터를 읽고 있습니다. 다시 말하지만, 이 메서드는 테이블 형식 데이터베이스를 쿼리하는 데 사용됩니다.

이 모든 것 중에서 가장 어려운 부분은 어떤 정보가 데이터를 이해하는 데 중요한지 결정하는 것입니다. 모든 이야기에는 훌륭한 기원이 필요합니다. 데이터의 영웅 여정은 무엇입니까?

지금부터 몇 가지 가능한 예시를 살펴보겠지만, 데이터를 이해하는 데 어떤 정보가 유용할지에 대한 포괄적인 질문에 답해야 한다는 점을 명심하세요.

다시 몇 가지 예를 들어보겠습니다. 어떤 프로세스가 이 데이터를 요청하고 있습니까? 이전 예제로 돌아가서 추천 엔진이 이 데이터를 요청하고 있다고 가정해 보겠습니다.

이 요청은 언제 발생했습니까? 2025년 11월 4일입니다.

어떤 주요 진입점이 호출되었습니까? retabular DB 메서드입니다. 어떤 데이터가 요청되었습니까? 평균 시청 시간과 평균 일시 중지 시간이라는 두 개의 열이 요청되었다고 말할 수 있습니다.

데이터의 소스는 무엇입니까? 사용자 시청 메트릭이라는 테이블이라고 말할 수 있습니다.

데이터의 소스 유형은 무엇입니까? 데이터베이스입니다. 마지막으로, 이것은 어떤 유형의 상호 작용입니까? 이것은 읽기 상호 작용입니다.

구현 측면을 살펴보기 전에 잠시 물러서서 데이터 리니지 솔루션의 기능적 요구 사항에 대해 논의해 보겠습니다.

데이터 리니지는 데이터가 사용되는 순간부터 변환을 거쳐 최종 사용 지점에 이르기까지 시스템 전체에서 데이터의 여정을 추적, 시각화 및 이해해야 합니다. 우리에게는 5가지 기능적 요구 사항이 있습니다. 첫 번째는 데이터 포인트를 사용하는 모든 가능한 다운스트림 프로세스, 모델 또는 시스템을 나열하는 것입니다.

다음으로 데이터 포인트가 정확히 어디에서 시작되는지 파악하려고 합니다. 누가 이 데이터 포인트를 만듭니까? 어떤 프로세스, 모델 또는 시스템이 이 데이터 포인트를 만듭니까? 다음으로 전체 데이터 여정을 시각화하려고 합니다. 이는 데이터 실패 또는 데이터 변경의 가능한 다운스트림 영향을 이해하고 이상 동작의 업스트림 원인을 식별하는 데 도움이 될 것입니다.

간단히 말해서 데이터 포인트가 사용되는지 여부를 이해하고 싶고, 사용되지 않는다면 제거하여 효율성을 개선하고 싶습니다.

마지막으로, 마지막 기능적 요구 사항은 작업이 발전하고 시스템이 발전함에 따라 리니지가 자동으로 수집 및 업데이트되기를 원한다는 것입니다. 따라서 파이프라인의 최신 뷰를 보고 싶습니다.

이제 고차원적인 솔루션을 얻었습니다. 이제 파이프라인을 통해 데이터가 이동할 때 데이터에 귀를 기울이는 데 집중할 수 있습니다. 눈앞에 보이는 것은 가벼운 사내 데이터 리니지 솔루션입니다. 우리 솔루션에는 두 가지가 필요합니다. 그중 하나는 선택한 대기열 시스템이고 다른 하나는 테이블입니다.

대기열 시스템은 두 프로세스가 서로 간섭하지 않도록 하는 메커니즘을 갖춰야 합니다.

동일한 메시지를 대기열에 넣을 수 있습니다. 좀 더 자세히 살펴보겠습니다. 메시지가 대기열에 있다고 가정해 보겠습니다. 이 시점에서는 동일한 메시지를 대기열에 넣을 수 없습니다.

그리고 테이블은 모든 데이터 상호 작용을 저장합니다. 이제 솔루션에 대해 단계별로 살펴보겠습니다.

정보 세부 사항이 합의되고 확정되면, 앞에서 식별한 주요 진입점은 각각 관련 데이터 세부 사항을 확보해야 하며, 이러한 데이터 세부 사항을 하나의 메시지로 패키징하여 대기열로 보냅니다.

앞서 테이블 DB 읽기라는 진입점을 언급했습니다. 언급했듯이 테이블 데이터베이스에 대한 모든 쿼리는 이 위치로 들어갑니다.

Ilana Makover: Let Your Data Tell Its Story | PyData Tel Aviv 2025

스크립트