Overlapping time period problem in the event table | by Eddie Lin | Towards Data Science

In the data science world, people tend to think cleaning data is boring and desire more of machine learning and modeling challenges, but sometimes some problems might arise like a fun brain teaser or an algorithmic puzzle during data cleaning. Here’s a fun one I recently ran into when I am cleaning an event table. It’s not anything like crazy ML algorithms or new cool python tools but a small interesting problem worth a couple of minutes to figure out.
The event table is pretty common when we are building any kind of data pipeline or ML pipeline, especially when we are dealing with prediction problem. An event table is like a transaction table that normally has a start time, end time, person ID, and other event attributes. Each row is an event and some events might overlap which could be a problem. An event table in real-world might look like this:
   person_id      start        end0          1 2017-01-01 2017-06-011          1 2017-02-01 2017-03-012          1 2017-05-01 2017-08-013          1 2017-09-01 2017-10-014          1 2017-11-01 2018-02-015          1 2018-01-01 2018-03-01
Sometimes we can just live with it, but sometimes we want to merge those overlapping rows into one row with the earliest start time and the latest end time like this:
   person_id      start        end0          1 2017-01-01 2017-08-011          1 2017-09-01 2017-10-012          1 2017-11-01 2018-03-01
That being said, since the second event and the third event both overlap with the first event even though the third event doesn’t overlap with the second event, we would like the merged event to have the first event’s start time and the third event’s end time. It looks pretty simple but it’s not so straightforward to figure out a good solution.
Here I am solving this in python.
Simple case:
In the first solution, we can treat this as a graph connectivity problem. Each event is a node. If two events overlap, then they connect with an edge. Therefore, the first three events will form a connected sub-graph, the third event is an isolated node kind of sub-graph, and the fourth and fifth events will form another connected sub-graph. We assign each sub-graph a group_id in the original DataFrame. Now we can group by the group_id and aggregate by min(start time) and max(end time) and then we have the answer.
To implement that, we will create an adjacency matrix to represent the graph. First, we want to define “overlap”. The overlap here means: for any two nodes A and B. If node A’s start date is before node B’s end date and node A’s end date is after node B’s start date, then A and B overlap. We can implement the logic with numpy array to create a sparse matrix. There are several algorithms existed to solve the connectivity graph problem. We can just use one of the off-the-shelf functions scipy.sparse.csgraph.connected_components to achieve this. scipy implement the function with something similar to Tarjan’s algorithm. Then, we just do the simple pandas groupbymethod to get the result we want.
This is a pretty solution for its mathematical approach. That’s just for one person. If we have thousand or million people, which is normally the real-world case, the graph will grow very large and the space complexity it’s gonna grow in n2. We can still implement this by adding another “&” logic in the line of creating the adjacency matrix.
Theoretically, the time complexity of Tarjan’s algorithm is linear. The n^2 space complexity makes it not able to scale. This made me think about how to solve it in a scalable way along with pandas.
Honestly, I am not a fan of pandas due to its unintuitive way of querying things, but it does provide good performance if we can have a vectorized solution.
The vectorized solution is like this.
Let’s forget about all the graphs and nodes and edges and rethink this problem with some pure simple time-series data. First of all, we break the start time and end time to create a one-dimensional time series by sorting it. We have a column start_end to indicate if it's a start time or an end time where1 is the start time and -1 is the end time. Then we perform a cumulative sum on the series as the column cumsum. By looking at it, we notice that the new start time is a start time where its cumsum is 1. A new end time is an end time where its cumsum is 0. So now we have a new_start column. Next, we perform another cumulative sum on the new_start column to get the group_id. Last, we do the same aggregation to get the answer.
It’s probably easier to look at the mergedf to understand what's going on here.
   person_id       time  start_end  cumsum  new_start  group0          1 2017-01-01          1       1       True    1.01          1 2017-02-01          1       2      False    1.01          1 2017-03-01         -1       1      False    1.02          1 2017-05-01          1       2      False    1.00          1 2017-06-01         -1       1      False    1.02          1 2017-08-01         -1       0      False    1.03          1 2017-09-01          1       1       True    2.03          1 2017-10-01         -1       0      False    2.04          1 2017-11-01          1       1       True    3.05          1 2018-01-01          1       2      False    3.04          1 2018-02-01         -1       1      False    3.05          1 2018-03-01         -1       0      False    3.0
Performance
Since I don’t want to go too deep into the implementation of scipy’s connected_component and analyze its complexity, I simply want to compare the scalability in an empirical way. What I did is just to duplicate the example n times to create a big event table and measure the runtime and peak memory with n growing in the orders of magnitude.
Both approaches are kind of similar in runtime and memory before n hits 102. After that, it’s pretty clear that the graph approach explodes in both runtime and memory very soon. I actually ran into memory leakage when running the graph approach with n=100000 on a machine with 200GB RAM. There definitely are some ways to optimize the graph approach which I’d love to see, but what I’m trying to make points here is that the operation behind scipy’s connected_componentmore memory-intense than the vectorization in pandas. I guess sometimes ugly algorithms might just beat beautiful algorithms.
       size    mem     runtime       approach0        10     82    0.083125          graph1        50     83    0.111390          graph2       100     85    0.094990          graph3       500    150    0.458318          graph4      1000    305    1.544724          graph5      5000   6964   27.119864          graph6     10000  27576  113.710234          graph7    100000    inf         inf          graph8        10     82    0.092768  vectorization9        50     83    0.125092  vectorization10      100     83    0.121607  vectorization11      500     86    0.091670  vectorization12     1000     89    0.168066  vectorization13     5000    101    0.154213  vectorization14    10000    115    0.224327  vectorization15    50000    216    1.523057  vectorization16   100000    351    2.482687  vectorization17   500000   1407    6.840897  vectorization18  1000000   2707   12.607009  vectorization