[AMA CLOSED] Sisense/Snowflake Optimization Community AMA on March 22

What makes the Sisense/Snowflake relationship powerful is the ability to use either Sisense ElastiCubes or Live Models with any Snowflake instance. Allowing customers to use either ElastiCubes or Live Models allows for incredible flexibility for any use cases or SLAs that may exist.

In addition to supporting multiple data sources, ElastiCubes are a great option if there aren’t stringent data latency SLAs required from your data. If a refresh every hour doesn’t impact your business, then having an ElastiCube on a scheduled refresh may make a lot of sense.

When data is loaded into Snowflake, it is stored in an underlying database. To access or interact with that information, a cluster of compute resources is required. In Snowflake, each resource compute cluster is referred to as a virtual warehouse, or just simply, a warehouse. A warehouse is what Sisense will connect to as the engine to perform the necessary actions to support an ElastiCube or Live Model.

Live Models have one primary advantage over ElastiCubes: real-time data. If the nature of your business requires real-time data, or you have user SLAs that require real-time data, Live Models can support this.

The root of the issue lies with the location where Sisense is querying data from. The first level of optimization that should be considered is having a dedicated virtual warehouse for your BI tool. Then, Snowflake is a columnar data store, which is much faster than a row-store system. The major difference here being data is physically stored in columns rather than rows. There are several others that I would want to know more about specific issues to solve the issue!

All of the security role assignments can be written out using queries on the Snowflake UI. The security roles allow you to break down users into "groups" with different levels of access. Snowflake allows you to then assign these roles access as high as warehouse and databases down to row or column level access. The Snowflake documentation is a great place to start for this. It clearly lays out each permission for each level of access.

Yes, for sure. We actually have a current client where we have put this into use. The 3 by 2 system works perfectly when everything is constrained to simply moving data from the source, transforming for production, and loading into Sisense. The use case for a fourth warehouse comes in handy when you have "too many hands in the cookie jar". For instance, this client has an entire research team that is actively using Snowflake daily to improve their data quality. This team was previously using the PROD_WAREHOUSE (meant only to move data from production database to Sisense). This was causing a conflict over the compute resource and a jump in Snowflake costs. We fixed this by adding a RESEARCH_WAREHOUSE. This fourth warehouse allowed us to better understand how compute resources were being used, where costs were coming from, and allowed Sisense dashboards to not be impacted by backend queries being written on the same warehouse.

Access control is similar to most databases and warehouses where a user is created to access Snowflake. Users can be granted permissions directly or have roles assigned to them with permissions already granted. Users can only view use the databases and warehouses they have permissions to and perform actions granted to them. You can authenticate using username & password, federation authentication & sso, key pairs, oauth and you can also implement MFA.