elasticSearch
Doc Values
https://www.elastic.co/guide/cn/elasticsearch/guide/current/_deep_dive_on_doc_values.html
Doc Values 是在索引时与 倒排索引 同时生成。也就是说 Doc Values 和 倒排索引 一样，基于 Segement 生成并且是不可变的。同时 Doc Values 和 倒排索引 一样序列化到磁盘，这样对性能和扩展性有很大帮助。
Doc Values 通过序列化把数据结构持久化到磁盘，我们可以充分利用操作系统的内存，而不是 JVM 的 Heap 。 当 working set 远小于系统的可用内存，系统会自动将 Doc Values 驻留在内存中，使得其读写十分快速；不过，当其远大于可用内存时，系统会根据需要从磁盘读取 Doc Values，然后选择性放到分页缓存中。很显然，这样性能会比在内存中差很多，但是它的大小就不再局限于服务器的内存了。如果是使用 JVM 的 Heap 来实现那么只能是因为 OutOfMemory 导致程序崩溃了。
从广义来说，Doc Values 本质上是一个序列化的 列式存储 。 正如我们上一节所讨论的，列式存储 适用于聚合、排序、脚本等操作。
而且，这种存储方式也非常便于压缩，特别是数字类型。这样可以减少磁盘空间并且提高访问速度。现代 CPU 的处理速度要比磁盘快几个数量级（尽管即将到来的 NVMe 驱动器正在迅速缩小差距）。所以我们必须减少直接存磁盘读取数据的大小，尽管需要额外消耗 CPU 运算用来进行解压。
es之Setting
B树的概念
https://blog.youkuaiyun.com/ailiandeziwei/article/details/104648321
一个m阶的B树具有如下几个特征：
1.根结点至少有两个子女。
2.每个中间节点都包含k-1个元素和k个孩子，其中 m/2 <= k <= m
3.每一个叶子节点都包含k-1个元素，其中 m/2 <= k <= m
4.所有的叶子结点都位于同一层。
5.每个节点中的元素从小到大排列，节点当中k-1个元素正好是k个孩子包含的元素的值域分划。
一个m阶的B+树具有如下几个特征：
1.有k个子树的中间节点包含有k个元素（B树中是k-1个元素），每个元素不保存数据，只用来索引，所有数据都保存在叶子节点。
2.所有的叶子结点中包含了全部元素的信息，及指向含这些元素记录的指针，且叶子结点本身依关键字的大小自小而大顺序链接。
3.所有的中间节点元素都同时存在于子节点，在子节点元素中是最大（或最小）元素。
B+树最下面是链表
B+树的特征：
1.有k个子树的中间节点包含有k个元素（B树中是k-1个元素），每个元素不保存数据，只用来索引，所有数据都保存在叶子节点。
2.所有的叶子结点中包含了全部元素的信息，及指向含这些元素记录的指针，且叶子结点本身依关键字的大小自小而大顺序链接。
3.所有的中间节点元素都同时存在于子节点，在子节点元素中是最大（或最小）元素。
B+树的优势：
1.单一节点存储更多的元素，使得查询的IO次数更少。
2.所有查询都要查找到叶子节点，查询性能稳定。
3.所有叶子节点形成有序链表，便于范围查询。
现在我们可以回答“为什么Elasticsearch/Lucene检索可以比mysql快了。Mysql只有term dictionary这一层，是以b-tree排序的方式存储在磁盘上的。检索一个term需要若干次的random access的磁盘操作。而Lucene在term dictionary的基础上添加了term index来加速检索，term index以树的形式缓存在内存中。从term index查到对应的term dictionary的block位置之后，再去磁盘上找term，大大减少了磁盘的random access次数。
https://zhuanlan.zhihu.com/p/33671444
Bitmap索引
https://www.huaweicloud.com/articles/d93482b4b99e516a1b524b7cbc58add4.html
bitmap 有个硬伤，就是不管你有多少个文档，你占用的空间都是一样的，之前说过，Lucene Posting List 的每个 Segement 最多放 65536 个文档ID，举一个极端的例子，有一个数组，里面只有两个文档 ID：
倒排索引
https://zhuanlan.zhihu.com/p/76485252
在没有搜索引擎时，我们是直接输入一个网址，然后获取网站内容，这时我们的行为是：
document -> to -> words
通过文章，获取里面的单词，此谓「正向索引」，forward index.
后来，我们希望能够输入一个单词，找到含有这个单词，或者和这个单词有关系的文章：
word -> to -> documents
spark新特性
https://aws.amazon.com/cn/blogs/china/application-and-actual-combat-of-new-features-of-apache-spark-3-0-in-freewheels-core-business-data-team/
Kafka Exactly Once实现原理
Kafka的EOS主要体现在3个方面：
幂等producer：保证发送单个分区的消息只会发送一次，不会出现重复消息
事务(transaction)：保证原子性地写入到多个分区，即写入到多个分区的消息要么全部成功，要么全部回滚
流处理EOS：流处理本质上可看成是“读取-处理-写入”的管道。此EOS保证整个过程的操作是原子性。注意，这只适用于Kafka Streams
幂等producr只能保证单分区上无重复消息；
事务可以保证多分区写入消息的完整性；
而流处理EOS保证的是端到端(E2E)消息处理的EOS。用户在使用过程中需要根据自己的需求选择不同的EOS。以下是启用方法：
启用幂等producer：在producer程序中设置属性enable.idempotence=true，但不要设置transactional.id。注意是不要设置，而不是设置成空字符串或"null"
启用事务支持：在producer程序中设置属性transcational.id为一个指定字符串(你可以认为这是你的事务名称，故最好起个有意义的名字)，同时设置enable.idempotence=true
启用流处理EOS：在Kafka Streams程序中设置processing.guarantee=exactly_once
幂等producer的设计与实现
所谓幂等producer指producer.send的逻辑是幂等的，即发送相同的Kafka消息，broker端不会重复写入消息。同一条消息Kafka保证底层日志中只会持久化一次，既不会丢失也不会重复。幂等性可以极大地减轻下游consumer系统实现消息去重的工作负担，因此是非常实用的功能。值得注意的是，幂等producer提供的语义保证是有条件的：
单分区幂等性：幂等producer无法实现多分区上的幂等性。如前所述，若要实现多分区上的原子性，需要引入事务
单会话幂等性：幂等producer无法跨会话实现幂等性。
即使同一个producer宕机并重启也无法保证消息的EOS语义
虽然有上面两个限制，幂等producer依然是一个非常实用的新功能。下面我们来讨论下它的设计原理。如果要实现幂等性， 通常都需要花费额外的空间来保存状态以执行消息去重。Kafka的幂等producer整体上也是这样的思想。
首先，producer对象引入了一个新的字段：Producer ID(下称PID)，它唯一标识一个producer，当producer启动时Kafka会为每个producer分配一个PID（64位整数），因此PID的生成和分配对用户来说是完全透明的，用户无需考虑PID的事情，甚至都感受不到PID的存在。其次，0.11 Kafka重构了消息格式，引入了序列号字段(sequence number，下称seq number)来标识某个PID producer发送的消息。和consumer端的offset类似，seq number从0开始计数并严格单调增加。同时在broker端会为每个PID(即每个producer)保存该producer发送过来的消息batch的某些元信息，比如PID信息、消息batch的起始seq number及结束seq number等。这样每当该PID发送新的消息batch时，Kafka broker就会对比这些信息，如果发生冲突(比如起始seq number和结束seq number与当前缓存的相同)，那么broker就会拒绝这次写入请求。倘若没有冲突，那么broker端就会更新这部分缓存然后再开始写入消息。这就是Kafka实现幂等producer的设计思路：
1. 为每个producer设置唯一的PID；
2. 引入seq number以及broker端seq number缓存更新机制来去重。
PID与Sequence Number的引入实现了写操作的幂等性
PID标记了Producer、topic、partition的唯一性，Seq标记了PID下每一个消息得唯一性。broker会记录已经收到得seq值，下一个seq一定是上一个seq+1，如果大于1，抛InvalidSequenceNumber异常（丢数据了），如果小于1，抛DuplicateSequenceNumber异常（数据重复了），生产端需要对这两种情况做处理
写操作的幂等性结合At Least Once语义实现了单一 Session 内的Exactly Once语义
Transaction Marker（引入事务协调者）与PID提供了识别消息是否应该被读取的能力，从而实现了事务的隔离性
Offset 的更新标记了消息是否被读取，从而将对读操作的事务处理转换成了对写（Offset）操作的事务处理
Kafka 事务的本质是，将一组写操作（如果有）对应的消息与一组读操作（如果有）对应的 Offset 的更新进行同样的标记（即Transaction Marker）来实现事务中涉及的所有读写操作同时对外可见或同时对外不可见
Kafka 只提供对 Kafka 本身的读写操作的事务性，不提供包含外部系统的事务性
简单的说，其实就是把所有操作都那个小本本写下来，所有人都能看到，就避免了重复问题和丢数据问题。
当然，这只是说kafka内部得事务实现，至于kafka的上游生产者，下游消费者的事务，需要使用方自己实现
1、https://blog.youkuaiyun.com/code52/article/details/50475511
https://blog.youkuaiyun.com/lrxcmwy2/article/details/82853300
https://www.cnblogs.com/cyfonly/p/5954614.html
. producer 先从 zookeeper 的 “/brokers/…/state” 节点找到该 partition 的 leader
. producer 将消息发送给该 leader
. leader 将消息写入本地 log
. followers 从 leader pull 消息，写入本地 log 后 leader 发送 ACK
. leader 收到所有 ISR 中的 replica 的 ACK 后，增加 HW（high watermark，最后 commit 的 offset） 并向 producer 发送 ACK
- At most once 消息可能会丢，但绝不会重复传输
- At least one 消息绝不会丢，但可能会重复传输
- Exactly once 每条消息肯定会被传输一次且仅传输一次
当 producer 向 broker 发送消息时，一旦这条消息被 commit，由于 replication 的存在，它就不会丢。但是如果 producer 发送数据给 broker 后，遇到网络问题而造成通信中断，那 Producer 就无法判断该条消息是否已经 commit。虽然 Kafka 无法确定网络故障期间发生了什么，但是 producer 可以生成一种类似于主键的东西，发生故障时幂等性的重试多次，这样就做到了 Exactly once，但目前还并未实现。所以目前默认情况下一条消息从 producer 到 broker 是确保了 At least once，可通过设置 producer 异步发送实现At most once。
Flink消费Kafka数据指定offset的五种模式
FlinkKafkaConsumer consumer = new FlinkKafkaConsumer("topic", new SimpleStringSchema(), props);
/**
* Flink从topic中最初的数据开始消费
*/
consumer.setStartFromEarliest();
/**
* Flink从topic中指定的时间点开始消费，指定时间点之前的数据忽略
*/
consumer.setStartFromTimestamp(1559801580000l);
/**
* Flink从topic中指定的offset开始，这个比较复杂，需要手动指定offset
*/
consumer.setStartFromSpecificOffsets(offsets);
/**
* Flink从topic中最新的数据开始消费
*/
consumer.setStartFromLatest();
/**
* Flink从topic中指定的group上次消费的位置开始消费，所以必须配置group.id参数
*/
consumer.setStartFromGroupOffsets();
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
