左值右值
左值、右值、移动语义，std::move, std::forward 等一些基本概念
xsimd
xsimd 介绍
Ambari架构
介绍 Ambari 的基本功能，依赖的其他开源组件，主要模块 Ambari-Server、Agent、web、metrics 的介绍
Gluten和相关依赖
对Spark性能增加的一个方案，将处理密集型数据部分的逻辑，由 JVM 交给 C++处理，Gluten只是一个胶水层，本身不做太多的事情，它将Spark的物理计划转为Substrait计划，然后序列化再转发给底层的向量化引擎，如Velox、ClickHouse等。对于不支持的算子会交给原生Spark处理，这种思路跟Databricks 发表的论文Photon是很类似的
大数据采集
总结一下大数据采集框架：Flumen、Fluentd、Sqoop、Datax、SeaTunel
JVM GC 介绍
基于分带的几款老 GC，Serial、ParNew、Parallel Scavenge、Serial Old、Parallel Old、CMS，以及新一代基于region划分的 G1、ZGC、ShenandoahGC，以及用于测试环境的 Epsilon，一共 10 款 GC
Presto在各大公司的应用
Presto在 B站、字节跳动等 各大公司的应用
Spark性能调优
Spark性能调优
BitWeaving: Fast Scans for Main Memory Data Processing
基于主内存数据库的 scan 优化，提出的技术：BitWeaving，又分为两种：BitWeaving/V 和 BitWeaving/H；BW/H 相当于是bit 级别的水平分布，将列的数据水平的分布到不同segment 中，通过亦或、以及各种位运算技术，实现了 =、!=、<、<= 的比较操作，比较完之后，每个process word 分隔符bit就会被设置为 1 或者0，然后将上下四组分别做不同的位移在 or，就能得到最终结果；BW/V 实现bit 级别的列存储，一列数据将每个数据的第一个bit存到 process word v1中，第二列存到 v2中，按照这种分布就可以实现早期裁剪，SIMD 再进一步优化，他的scan很快，但是查找需要跨多个processor word，相当于是垂直的从左往右计算，性能会 BW/H要差；而对于 VBP，其真实数据布局可以再优化，比如原先 9个processor word 一个segment，变成一个segment 3个 bit group，每个bit group 3个 processor word，这样做 cut-off的时候可以不用再加载斗鱼的processor word，节省了内存带宽，减少cache miss；从性能对比看，BW 技术在scan方面是最好的，SIMD有打包和对其开销所以效果远不如 BW，而BW 存在选择 BW/V 和 BW/H 布局的问题，也是待研究的问题
Cache Conscious Indexing for Decision-Support in Main Memory
对于主内存 OLAP 场景，提出的针对 cache有效性的优化，如果排序数组远大于 cache line，则二分查找的 cache miss 是很严重的，基本每查找一次就有一次cache miss；T树 看起来是缓存友好的，但每次查找只有 min、max做了匹配，仍然会有很大的 cache miss，B 树虽然是面向磁盘的，但有多个子节点，一次可以做多个匹配，所以cache miss 比 T 树更好一些，hash index需要占用大量空间，当然二分的好处是不用空间；在这些基础上论文提出了针对cache line的 CSS树(Cache Sensitive Search Trees)，他在排序数组基础上，增加了一个字典数组，使得整个树可以被平铺，有点像 树堆，不过它的节点有多个，个数一般跟 cache line有关，它没有子节点指针，而是用数组下标来代替，这样一个 node 内可以放更多的数据，查找起来的cache miss就会小很多；值得注意的是类似满二叉树，CSS树的字典指向的排序数组其 part-1、part-2整合跟正常排序数组是相反的；从测试结果看CSS 树的表现也不错，随着CPU和内存差距越来越大，CSS树可能会变现的更好