https://dl.acm.org/citation.cfm?id=2903741
paper-snowflake-elastic-data-warehouse#shared-nothingp 216: Shared-nothing architectures have become the dominant system architecture in high-performance data warehousing, for two main reasons: scalability and commodity hardware paper-snowflake-elastic-data-warehouse#shared-nothing
paper-snowflake-elastic-data-warehouse#small-broadcast-dimension-table-large-partitioned-fact-tablep 216: This design scales well for star-schema queries, because very little bandwidth is required to join a small (broadcast) dimension table with a large (partitioned) fact table paper-snowflake-elastic-data-warehouse#small-broadcast-dimension-table-large-partitioned-fact-table
paper-snowflake-elastic-data-warehouse#data-shuffling1 2p 216: If the set of nodes changes; either as a result of node failures, or because the user chooses to resize the system; large amounts of data need to be reshuffled. Since the very same nodes are responsible for both data shuffling and query processing, a significant performance impact can be observed, limiting elasticity and availability. paper-snowflake-elastic-data-warehouse#data-shuffling1 2
paper-snowflake-elastic-data-warehouse#membership-changes-the-normp 216: At the same time, node failures are more frequent and performance can vary dramatically, even among nodes of the same type [45]. Membership changes are thus not an exception, they are the norm paper-snowflake-elastic-data-warehouse#membership-changes-the-norm
paper-snowflake-elastic-data-warehouse#hotp 217: Instead, local disk is used exclusively for temporary data and caches, both of which are hot (suggesting the use of high-performance storage devices such as SSDs). paper-snowflake-elastic-data-warehouse#hot
p 217: multi-cluster shared-data architecture
paper-snowflake-elastic-data-warehouse#hybrid-columnar1p 217: Within each file, the values of each attribute or column are grouped together and heavily compressed, a well-known scheme called PAX or hybrid columnar in the literature [2]. Each table file has a header which, among other metadata, contains the offsets of each column within the file. Because S3 allows GET requests over parts of files, queries only need to download the file headers and those columns they are interested in. paper-snowflake-elastic-data-warehouse#hybrid-columnar1
paper-snowflake-elastic-data-warehouse#server-side-cursors1p 217: Storing query results in S3 enables new forms of client interactions and simplifies query processing, since it removes the need for server-side cursors found in traditional database systems. paper-snowflake-elastic-data-warehouse#server-side-cursors1
p 218: Each worker process lives only for the duration of its query. A worker process by itself—even if part of an update statement—never causes externally visible effects, because table files are immutable, cf. Section 3.3.2. Worker failures are thus easily contained and routinely resolved by retries. Snowflake does not currently perform partial retries though, so very large, long-running queries are an area of concern and future work.
paper-snowflake-elastic-data-warehouse#mvcc1p 219: MVCC is a natural choice given the fact that table files are immutable, a direct consequence of using S3 for storage. paper-snowflake-elastic-data-warehouse#mvcc1
paper-snowflake-elastic-data-warehouse#min-bax-based-pruning1p 219: min-max based pruning, also known as small materialized aggregates [38], zone maps [29], and data skipping [49] paper-snowflake-elastic-data-warehouse#min-bax-based-pruning1
paper-snowflake-elastic-data-warehouse#data-distribution-information1 2 3p 219: Here, the system maintains the data distribution information for a given chunk of data (set of records, file, block etc.), in particular minimum and maximum values within the chunk paper-snowflake-elastic-data-warehouse#data-distribution-information1 2 3
paper-snowflake-elastic-data-warehouse#dynamic-pruning-and-build-side-and-probe-side-and-bloom-joins1 2 3 4p 220: Besides this static pruning, Snowflake also performs dynamic pruning during execution. For example, as part of hash join processing, Snowflake collects statistics on the distribution of join keys in the build-side records. This information is then pushed to the probe side and used to filter and possibly skip entire files on the probe side. This is in addition to other well-known techniques such as bloom joins [40]. paper-snowflake-elastic-data-warehouse#dynamic-pruning-and-build-side-and-probe-side-and-bloom-joins1 2 3 4
paper-snowflake-elastic-data-warehouse#node-failures1 2p 220: Snowflake tolerates individual and correlated node failures at all levels of the architecture, shown in Figure 2 paper-snowflake-elastic-data-warehouse#node-failures1 2
paper-snowflake-elastic-data-warehouse#hard-state1p 220: All hard state is kept in a transactional key-value store and is accessed through a mapping layer which takes care of metadata versioning and schema evolution paper-snowflake-elastic-data-warehouse#hard-state1
Snowflake's claim to be "designed from the ground up for the cloud" becomes very credible when you look into its detailed implementation. The cloud offers great benefits like real elasticity, multi-datacenter (and multi-region) compute, as well as high level abstractions around things like highly available, reasonably low-cost, and extremely durable storage, like S3. The cloud also comes with its own special challenges, like variable node performance, network congestion, and commodity hardware with high failure rates. Snowflake is designed to leverage the advantages and protect against the challenges.