原文：Procella: Unifying serving and analytical data at YouTube

TL;DR

Procella是一种可以适应不同查询需求的分析引擎，它的特点：

• 松耦合的schema要求，只要数据schema与table schema兼容，不需要完全一致，且文件本身的索引结构也可以惰性生成。
• 使用了新的列存格式Artus，内带索引结构，同时支持高性能的点查和扫描，且使用高性能的、不解压就可以操作的压缩算法。
• 使用Lambda架构，实时节点与compaction节点分离，前者支持高性能读写，后者可以在后台做复杂的优化。
• 多种优化，包括自适应的基于运行期抽样的query优化。
• 广泛使用多种cache。
• 完整的SQL支持。

TL;DR

NoSQL系统中的一个常见问题就是写、读、compaction三类操作的资源争抢导致服务质量受到影响。这里脑洞一个方案，通过单独的FileMeta Service来管理文件的元数据与生命期，从而解耦前面三类操作，实现资源的隔离，提升服务质量。

进一步地，分离三类操作后，我们甚至可以针对不同操作使用不同的分区策略，从而进一步解耦三类操作，释放出更高的能力。

idea来源于我在阿里云Tablestore时的一次讨论，参考了Google的Procella和F1-lightning的实现方式。

原文：F1 Lightning: HTAP as a Service

TL;DR

F1 Lightning是一种提供HTAP服务的系统，本身并不是一个完整的HTAP系统。它的切入点是为已有的OLTP（F1、Spanner）用户提供列式存储，供其它的OLAP系统（F1 Query）使用。这样用户不需要迁移转换已有的数据就能享受到更快捷的分析能力。

F1 Lightning依赖于OLTP系统的ChangeDataCapture（CDC）接口，从而将OLTP的修改应用到Lightning列存上；另一端，它依赖于OLAP系统下推部分算子，从而充分利用列式存储的扫描优势。

HTAP现在已经不那么新颖了，但F1 Lightning的切入点很独特，也是因为Google内部系统间合作比较容易，且已有数据量非常大，这种不需要迁移，与已有系统充分结合的方案才有用武之地。

原文：Alibaba Hologres: A Cloud-Native Service for Hybrid Serving/Analytical Processing

TL;DR

Hologres是一种融合了NoSQL的写和OLAP的读的系统，它自称为HSAP，即Hybrid Srerving and Analytical Processing，目标是针对那些同时有着大量在线写入和实时分析需求的场景。

Hologres的主要特点：

• 计算存储分离。
• 兼容PostgreSQL。
• 同时支持行列两种存储形式，从而支持高性能的写入、点查、扫描。
• 高效的高并发实现。
• TableGroup，支持表之间colocate。
• 还支持其它存储引擎，实现federation query。

（没有讲schema change）

原文：AnalyticDB: Real-time OLAP Database System at Alibaba Cloud

TL;DR

AnalyticDB（以下简称ADB）是一种支持复杂ad-hoc查询的实时分析系统。

ADB的主要特点：

• 读写节点分离，之间通过pangu异步交换数据，或通过RPC同步交换数据。优点是可以避免相互影响，缺点是高数据可见性就会有一定的性能损失。
• 索引功能强大：
  • 全量数据中所有列都有索引，增量数据也有简单的索引。
  • 运行期可以基于选择率跳过部分索引，不会因过度使用索引而导致性能下降。
  • 索引类型丰富，string、int、JSON、向量等类型的列都可以建索引，还可以创建全文搜索索引。
• 仔细设计过的列存格式。
• 使用MapReduce做全量数据的compaction。

这篇文章中有些细节看得不是很明白，以下内容部分来自脑补。

总体感觉ADB的性能确实好。缺点是可能成本会比较高，索引的构建过程的计算开销与所有列的索引对应的存储开销都挺高的。存储开销可以通过更好的编码和压缩来控制，但会导致计算开销更高，这样base compaction时间会更长，常规路径的数据可见性会受到一些影响。

如果将compaction分成更多级别，一步步提高优化等级，优点是数据可见性比较好，缺点是第一次compaction时如果还是要为每列都建索引，则优化不够的话存储开销大，或者读开销也会大。而通常query都会更倾向于读近期的数据，相当于大多数query都只享受到了低优化等级。

本质上数据可见性与优化就是矛盾的，没有万能药，只能靠工程上的tradeoff。

原文：Druid: A real-time analytical data store

TL;DR

Druid是一种实时分析系统，它主要面向时序数据的复杂分析。Druid使用了lambda架构，使用实时节点来服务新数据，历史节点来服务历史数据，从而同时保证了查询效率、空间效率、数据可见性。Druid是存储计算分离架构，支持多种存储引擎，如HDFS、AWS S3等。

Druid比较有价值的点是它的lambda架构、列存、倒排索引、良好的可伸缩性和高可用性。

原文：F1 query: declarative querying at scale

TL;DR

F1 query是一种federated query processing平台，它的特点是：

1. 计算存储分离。
2. 支持不同的存储引擎，如BigTable、Spanner、Mesa等，因此称为federated query processing。
3. 使用三种不同的模式处理不同规模的query：单节点模式处理短的实时query；分布式模式处理中等query；远程模式使用MapReduce处理大型query。
4. 使用启发式的query optimizer。

这里面最有价值的部分就是它如何融合不同的数据源与处理模式。

原文：Mesa: Geo-Replicated, Near Real-Time, Scalable Data Warehousing

TL;DR

Mesa是一种面向Google Ads的特定模式数据的准实时数仓，而不是面向非常通用场景的离线数仓。Mesa的设计上偏向于高伸缩性和准实时响应，目标是保证简单query场景的高性能；相对地，Mesa不支持完整的ad-hoc查询（似乎也不支持SQL），可以支撑支持SQL的更上层系统（如MySQL、F1、Dremel）。

Mesa依赖Google的Colossus、BigTable、MapReduce，数据被水平分片并复制到多个datacenter。Mesa会批量导入数据，每行数据都有version，使用MVCC，周期性提升可见的数据版本。为了保证跨datacenter的更新一致性，Mesa还使用了基于Paxos的同步协议。

Mesa比较有特色的是它的聚合函数、数据版本管理、以及多datacenter同步。

原文：Pebblesdb: Building key-value stores using fragmented log-structured merge trees

TL;DR

PebblesDB在LevelDB（实际是HyperLevelDB）的基础上，借鉴了SkipList中的guard概念，提出了一种Fragmented Log-Structured Merge Trees（FLSM），将整个fileset分成了多层的，层内多个不重叠的区间，每个区间内可以有多个文件。这样compaction可以只在level i做，而不涉及level i+1，从而显著降低了写放大。代价是读的时候从level 1开始每层都可能引入多个文件（对比LevelDB每层一个），开销会变大。PebblesDB因此也引入了一些优化以降低读路径的延时。

生产中有大量写多的workload，这些场景下PebblesDB的意义很大，且它的实践难度并不高，值得集成到现有系统中。

原文：Dynamo: amazon’s highly available key-value store

TL;DR

Dynamo是一种去中心化的KV分布式存储系统。它的主要设计目标是：

• 高可用性（always writable）。
• 高可伸缩性。
• 高性能（低延时）。
• 面向异构机器。

为此Dynamo在CAP中选择了AP，牺牲了一部分的一致性（最终一致）。针对潜在的数据修改的冲突，Dynamo将选择权交给了用户，读取会返回一个“vector clock”，由用户自己解决冲突。

另外为了避免单点问题影响可用性，Dynamo选择了去中心化架构，所有节点都是相同地位的，通过一致性哈希决定数据分片，通过gossip协议在不同节点间同步节点列表和所管理的数据范围。

Dynamo使用了quorum协议（即R+W>N）来读写不同replica的数据。为了进一步提升集群发生错误时的可用性，Dynamo使用了“sloppy quorum”以允许少数派节点也可以临时写入数据，因此造成的数据冲突由上面提到的vector clock来解决。

Dynamo与BigTable是同一个时期非常不同的两种技术选择，前者看重可用性，后者看重一致性，且有着更复杂的数据模型。目前来看，用户似乎通常不太喜欢自己来解决数据冲突，默认的“last write win”策略已经够好了。对于只在一个datacenter内的后继系统来说，Dynamo有点过于复杂了，中心节点可以极大简化系统设计。但对于跨datacenter的系统，quorum的价值一下子提高了很多。