DevilKing's blog

原文链接

Alluxio为上层计算框架提供了统一的客户端和统一的API全局命名空间。在AI场景下，底层存储使用ceph，上层应用是特征计算，使用Alluxio作为中间层提供分布式共享缓存服务

核心功能：

• 分布式缓存
• 多种类型的接口，如hdfs/posix
• 统一的命令空间

实践部分，主要是基于alluxio on ceph的例子来讲

• 由于ceph-mds的性能不够，所以采用alluxio on ceph fs的方式
• 我们希望业务pod和Alluxio worker pod可以尽可能亲和性部署、尽量运行在同一个节点上，用domain socket 技术提升读性能。在业务上线前，通过distributeLoad命令把ceph的热点数据加载到Alluxio worker
• 同样面临master的压力很大的情况，采用ratis-shell的方式，扩展HA的使用
• 以及fuse-shell部分的调整，提升fuse部分的使用效率
• 增加master同client之间的动态参数配置
• 其他的一些调优策略：
  • 日志
  • HA下的元数据同步

后续的计划部分：

• 利用 Alluxio CSI 解耦业务和 Alluxio FUSE
• Alluxio localcache + Alluxio metadatacache 优化
• 通过类似负载均衡的功能分摊负载压力，智能读写调度策略等

原文链接

PPT

目标:

• filter and aggregate as fast as possible
• GROUP BY

设计方式:

• NOT top-down

• 基于硬件能力设计

• • we will do GROUP BY in memory
  • will put all data in a hash table
  • if the hash table is large, it will not fit in L3 cache of CPU
  • if the values of GROUP BY keys are not distributed locally, then we have L3 cache miss for every row in a table
  • L3 cache miss has 70..100 ns latency
  • How many keys per second we can process?

基于硬件设计，内存，cpu，cache，从底层的角度入手，而非单纯的软件角度在外围在处理。。。

• 解决一个问题，要分场景，不同场景有不同解决方案

• • Hash Table
  • memcpy
  • 甚至对于小规模数据，有一个特化版本, memcpySmallAllowReadWriteOverflow15
  • 不排斥新算法，选取实际效果最优的

• 对于不同数据规模，有不同的实现

• • quantileTiming

  • uniqCombined

  • • 小规模: flat array
    • 中规模: hash table
    • 极大规模: HyperLogLog
• • keep in mind low-level details when designing your system
  • design based on hardware capabilities
  • choose data structures and abstractions based on the needs of the task
  • provide specializations for special cases
  • try the new, “best” algorithms, that you read about yesterday
  • choose algorithm in runtime based on statistics
  • benchmark on real datasets
  • test for performance regressions in CI
  • measure and observe everything
  • even in production environment
  • and rewrite code all the time

基于硬件的设计，是很大的一个看重点

merge tree，定期合并碎片化文件

存储与计算分离的思考模式？

最开始单纯就是解决group by 问题

算法是最重要，抽象性是其次的，也就是性能是最重要的，普适性并不是一开始考虑的

原文链接

Mesa

mesa的预聚合数据模型

针对广告的背景，原始数据没有意义，但查询的时候需要有各种维度的数据

上面的 Table A～D 其实表示的是同一批原始数据的在四个不同维度的聚合结果，供不同的业务查询使用

只支持按照batch来更新，同spark-streaming天然贴合？

每次导入的 delta 数据不会立即和基线数据合并，而是会先以单独的文件存在，积累一定数量后再做 Compaction

kylin的预聚合？

Doris

支持以下三种模型的表：

1. Aggregate 表：需要定义 Key 列和 Value 列，Key 列相同的数据行会自动合并，合并时 Value 列的数据按预先定义好的聚合函数进行聚合
2. Duplicate 表：不会自动合并 Key 相同的数据，其语义类似于其他数据库中的关系表，Key 表示表的排序键（sort key）而不是唯一键
3. Uniq 表，Key 列相同时新的行覆盖（Replace）旧的行，本质上是一种特化的 Aggregate 表

Base->ROLLUP

物化视图的概念，允许用户基于明细表（Duplicate 表）定义预聚合。Doris 的物化视图仅支持定义聚合（Group-By）

没想到又开始更新了，断更了一年之后，又可以恢复更新了