Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(Cassandra): add Cassandra implementation of EntityService #3286

Merged
merged 135 commits into from Apr 26, 2022

Conversation

xdl
Copy link
Contributor

@xdl xdl commented Sep 22, 2021

This PR implements a new EntityService (DatastaxEntityService) and its associated DAO, aspect classes etc. in order to support Datastax's Cassandra for DataHub's document store component.

The implementation (Cassandra Datastax or Ebean SQL) can be set with the DAO_SERVICE_LAYER environment variable (e.g. in /docker/datahub-gms/env/docker.cassandra.env). The other corresponding DB configs that can be set are:

  • DATASTAX_DATASOURCE_USERNAME (e.g. cassandra)
  • DATASTAX_DATASOURCE_PASSWORD (e.g. cassandra)
  • DATASTAX_HOSTS (e.g. localhost)
  • DATASTAX_PORT (e.g. 9042)
  • DATASTAX_DATACENTER (e.g. datacenter1)
  • DATASTAX_KEYSPACE (e.g. datahubpoc)
  • DATASTAX_USE_SSL (e.g. false)

To test out locally, do a build and then run ./docker/dev-with-cassandra.sh.

Motivation

While evaluating DataHub for internal use, we identified that it was important for the query serving to be able to be horizontally scalable, as we've come up with scaling issues for one of our use cases relying on a traditional SQL store that DataHub would replace. Along with the requirement that the database should be highly available and with native support for multi DC replication, this led us to evaluate the use of Cassandra, a horizontally scalable database as part of our data catalog solution.

Technical Notes

Overview

  • We use the Cassandra library from testcontainers to provide an out-of-process Cassandra instance for integration tests (DatastaxEntityServiceTest.java)
  • The architecture (and tests) is inspired from the EbeanEntityService and the other Ebean implementations
  • Some nuances to queries, inserts and updates in a distributed database (e.g. see Paging and Sorting), are discussed below

Conditional Updates vs Transactions

Cassandra does not have ACID transactions; it does however have conditional updates which we make use of in DatastaxAspectDao.batchSaveLatestAspect and DatastaxAspectDao.condUpsertAspect to avoid a potential race condition when ingesting new entities (see #3231).

SCSI Support

Since Cassandra does not support JOINs, it would be difficult to implement SCSI without adding more columns into the metadata_aspect table, although it's our understanding that if this feature is about to be dropped, this wouldn't be a long-term issue.

Paging and Sorting

This mostly relates to the reimplementing of the listLatestAspects method. A new column in the DB has been added for the entity type (e.g. corpuser), populated upon insertion. The alternative to this would be to use a SASI, although there are some sources suggesting that it won't be any more performant (https://www.scnsoft.com/blog/cassandra-performance).

Furthermore, the sorting order (ascending by URN) feature has been dropped as it would have to be done in memory (since URN is used as the partition key), and this condition has been relaxed in testListLatestAspects.

Cassandra's paging has been implemented using the OffsetPager; there does not seem to be a performant way of getting the total number of matches back (e.g. https://www.datastax.com/blog/running-count-expensive-cassandra). Our use case isn't heavily focused on the frontend so there hasn't been much effort expended in optimising this.

Anticipated Further Work

  • Update to use DAO (https://docs.datastax.com/en/developer/java-driver/4.4/manual/mapper/daos/update/) class annotations which would be more idiomatic than the current implementation of the DatastaxAspect class
  • Implement and update to use EntityService.ingestProposal
  • Further investigation into rolling back (deleting) aspects
  • Optimisation around the batchGet method
  • Optimisation around frontend (listLatestAspects, listUrns) use cases

import static org.testng.Assert.assertTrue;


public class DatastaxEntityServiceTest {
Copy link
Contributor

@EnricoMi EnricoMi Oct 5, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This file is very similar to EbeanEntityServiceTest. The tests and common helper methods should be moved into a base test class and only implementation specific tests and code should be in these test classes that derive from the base.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks Enrico and good spot, have moved those over to an BaseEntityServiceTest class and overrode the ones with different behaviour.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I named the base class for GraphServiceTests GraphServiceTestBase. So to be aligned with that, the class should be named EntitySearchTestBase.

https://github.com/linkedin/datahub/blob/master/metadata-io/src/test/java/com/linkedin/metadata/graph/GraphServiceTestBase.java.

Copy link
Collaborator

@RyanHolstien RyanHolstien left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes since last review lgtm


@Bean(name = "ebeanAspectDao")
@DependsOn({"gmsEbeanServiceConfig"})
@ConditionalOnProperty(name = "ENTITY_SERVICE_IMPL", havingValue = "ebean", matchIfMissing = true)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We've not used this annotation before -- where does this property come from? Env variables? Recently we've been trying to use application.yml config wherever possible

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, it comes from the env. Now that you mention it, Cassandra config properties aren't in the application.yml at all.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Specifically it comes from the Spring env, which includes application.yml properties. If it's present in the application.yml it should still get picked up by ConditionalOnProperty

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but in the application.yml we should be doing something like

entityService:
    impl: 'ebean' 
    config
....

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added entityService.impl and cassandra config to the application.yml


@Bean(name = "entityService")
@DependsOn({"ebeanAspectDao", "kafkaEventProducer", TopicConventionFactory.TOPIC_CONVENTION_BEAN, "entityRegistry"})
@DependsOn({"cassandraAspectDao", "kafkaEventProducer", TopicConventionFactory.TOPIC_CONVENTION_BEAN, "entityRegistry"})
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome. Same comment about the environment variable- I'd prefer if we could use the YAML

@ConditionalOnProperty(name = "ENTITY_SERVICE_IMPL", havingValue = "cassandra")
@Nonnull
protected RetentionService createCassandraInstance(CqlSession session) {
RetentionService retentionService = new CassandraRetentionService(_entityService, session, _batchSize);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Huge improvement to the retention service, to decouple from Ebean. Awesome work.

@@ -27,7 +27,7 @@ public class BootstrapManagerFactory {
@Qualifier("entityService")
private EntityService _entityService;

@Autowired
@Autowired(required = false)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this is not provided, will the IngestDataPlatformInstancesStep step break?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this even should be wired here. It doesn't get used directly in this class. If one of the beans used in this configuration class needs EbeanServer to be present, Spring should resolve it at that level through its dependency traversal (assuming it either wires it in or has some other form of DependsOn semantics)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah it should. Each step should have its own factory but nonetheless the step shouldn't be depending on Ebean specifically. This seems dangerous

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missed it getting passed into the constructor here, yeah this will cause that step to fail if it's not present. We should pull this functionality out directly into the EntityService rather than have this step directly accessing the EbeanServer.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, it would be best if it just depended on the EntityService. Should it be sorted in this PR?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have decided to address this on our side in a followup. No need to churn you kind folks on it.

Copy link
Collaborator

@jjoyce0510 jjoyce0510 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Few final minor comments. Overall this looks ready to ship. Incredible work & greatly appreciate your patience with a fast-moving code base like ours

Justin Marozas and others added 3 commits April 25, 2022 19:01
Cassandra datacenter naming consistency
add cassandra entity service configuration to application.yml
Copy link
Collaborator

@jjoyce0510 jjoyce0510 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM - Thank you guys for all the hard work.

@jjoyce0510 jjoyce0510 merged commit 01a5b13 into datahub-project:master Apr 26, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

10 participants