Avoid skewed join between entity_df & feature views

[MattDelac]

What this PR does / why we need it:

The problem is that if we ask for historical features coming from multiple entities that have a 1:many relationship between them, then we encounter skewed join

That's basically how the JOIN is performed with the current template
Imagine that driver_id=1 contains millions of rides

And that's what this PR is proposing

Let's have a look about the statistics of the SQL template on our use case (4 FeatureViews, 2 entities, entity_dataframe containing 100M rows)

SQL template currently in production
I cancelled the query as it was still running after 25min

9:14 AM Query has been running for 25 min

SQL template of this PR
Elapsed time 2 min 34 sec
Slot time consumed 1 day 21 hr
Bytes shuffled 3.27 TB
Bytes spilled to disk 0 B

Note: On our full entity_dataframe (3B rows) the current SQL template was still running after 45 min while the SQL template of this PR finished after 15min

Which issue(s) this PR fixes:

Fixes None

Does this PR introduce a user-facing change?:

NONE

[feast-ci-bot]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[codecov-commenter]

Codecov Report

Merging #1712 (c2e08d3) into master (703c4be) will increase coverage by 1.14%.
The diff coverage is 66.66%.

@@            Coverage Diff             @@
##           master    #1712      +/-   ##
==========================================
+ Coverage   83.32%   84.47%   +1.14%     
==========================================
  Files          76       79       +3     
  Lines        6794     7071     +277     
==========================================
+ Hits         5661     5973     +312     
+ Misses       1133     1098      -35     

Flag	Coverage Δ
integrationtests	84.40% <66.66%> (+1.15%)	⬆️
unittests	69.45% <11.11%> (-0.34%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
sdk/python/feast/infra/offline_stores/bigquery.py	80.60% <66.66%> (+4.45%)	⬆️
sdk/python/feast/entity.py	88.28% <0.00%> (-8.11%)	⬇️
sdk/python/feast/infra/offline_stores/file.py	93.49% <0.00%> (-3.54%)	⬇️
sdk/python/feast/feature_view.py	84.25% <0.00%> (-0.88%)	⬇️
sdk/python/feast/registry.py	80.82% <0.00%> (-0.48%)	⬇️
sdk/python/feast/repo_operations.py	31.06% <0.00%> (-0.31%)	⬇️
sdk/python/tests/test_historical_retrieval.py	99.09% <0.00%> (-0.01%)	⬇️
...dk/python/tensorflow_metadata/proto/v0/path_pb2.py	100.00% <0.00%> (ø)
.../python/tensorflow_metadata/proto/v0/schema_pb2.py	100.00% <0.00%> (ø)
...hon/tensorflow_metadata/proto/v0/statistics_pb2.py	100.00% <0.00%> (ø)
... and 16 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 703c4be...c2e08d3. Read the comment docs.

[woop]

What isn't clear to me is what the before and after of this test is. What is the problem that we are seeing and how do we know we are solving it? I realize it has to do with one-to-many relationships. Can we add a test that uses a 1:many relationship and shows how this test actually fixes the response? Or could we just extend our existing historical retrieval to have one of these relationships?

[MattDelac]

What is the problem that we are seeing and how do we know we are solving it?

That's an optimization problem. So beside running some benchmark on my side and prove you that this new template is better to scale, I don't have an idea of a good unit test for it.

Can we add a test that uses a 1:many relationship and shows how this test actually fixes the response? Or could we just extend our existing historical retrieval to have one of these relationships?

As I was saying, this is an optimization problem. We can extend the current test if we think that the coverage is not enough. A dedicated test for that does not seem like a good option IMO

Also I am going to spend time in benchmarking the 2 templates on our use case and will publish as many detail as possible in this PR

[woop]

What is the problem that we are seeing and how do we know we are solving it?

That's an optimization problem. So beside running some benchmark on my side and prove you that this new template is better to scale, I don't have an idea of a good unit test for it.

Can we add a test that uses a 1:many relationship and shows how this test actually fixes the response? Or could we just extend our existing historical retrieval to have one of these relationships?

As I was saying, this is an optimization problem. We can extend the current test if we think that the coverage is not enough. A dedicated test for that does not seem like a good option IMO

Also I am going to spend time in benchmarking the 2 templates on our use case and will publish as many detail as possible in this PR

Thanks. As long as it's purely an optimization change then I don't see a need for a new test. Let me know when/if you feel comfortable merging after your analysis.

[woop]

/lgtm

[feast-ci-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: MattDelac, woop

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [woop]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment