ES最佳实践

集群配置最佳实践

1.磁盘选择

  • 尽可能使用使用 SSD,ES 最大的瓶颈往往是磁盘读写性能,SSD 要比 SATA 查询快 5-10 倍,所以查询要求高的业务建议选择 SSD 或者 PCIE,查询要求不那么高的业务可以选择 SATA
  • 对于数据节点建议使用单机器 500G 以上的磁盘
  • 对于协调节点,200G 足矣,协调节点不存数据,只做转发和聚合

2.内存选择

  • 尽可能选择 16G 以上,由于 ES 的段文件(索引文件)存储在缓存中,尽量满足所有的段文件都存在缓存中,提高查询的效率
  • ES JVM 配置机器一半的内存,但是不要超过 32G
  • 内存和磁盘 1:10

3.集群角色配置

  • 数据节点和协调节点隔离,避免协调节点因数据问题 down 机之后导致整个集群崩溃
  • 集群尽量配置固定数量的协调节点(一般 3 个足矣),数据节点可以扩展

4.分片和副本设置

  • 每个数据节点上都尽量分配某个索引的一个分片,使数据足够均匀
  • 每个索引分片不要超过 30G
  • 单节点数据控制再 2T 以内
Read more
ES搜索原理剖析

一、索引建立

1.1 数据类型

搜索的前提是索引已经建立好,ES 中的数据分为 2 类

  • 精确值:如 id,ip 等,精确值只能精确匹配,适用于 term 查询,查询的时候是根据二进制来比较
  • 全文:指文本内容,比如日志,邮件内容,url 等,适用于 match 查询,只能查出看起来像的结果

以下对五条 doc 建立索引

Name Age Address
Alan 33 West Street Ca USA
Alice 13 East Street La USA
Brad 19 Suzhou JiangSu China
Alice 15 Nanjing JiangSu China
Alan 11 Changning Shanghai China

1.2 索引建立流程

Read more
2020年回顾与感想

一、前言

在想以何种样式来写年度总结,之前2018年的总结以挑出各个维度的几件事来总结,通过此来反思做的好的,做的差的,以及来年目标,这种挺新颖,但目标量化性不够,聚焦性不足。正好最终工作上要进行季度述职,所以打算用比较枯燥但深刻的述职模板来承载2020年总结吧。

二、2020年总结

请重点回顾在本人在周期内的关键策略进展、重要进展、目标达成等。

1、个人目标

上阶段有什么个人目标

阶段性目标 路径
技术能力 1,提升系统架构能力,能够通用性、易用性、扩展性延伸
2,提升技术决策能力,多调研,多总结
表达能力 1,提升自我沟通表达能力
经济知识能力 1,增加自己以经济视角看待问题能力,尝试不同的投资类型

2、目标完成情况及工作成果

上阶段目标完成情况,取得了什么亮点/成果(如有对标情况,请列举),有什么认知迭代

Read more
doris介绍

1.基本概念

1.1Doris(Palo) 简介

Doris 是一个 MPP 的在线 OLAP 系统,主要整合了 Google Mesa (数据模型),Apache Impala (MPP query engine) 和 ORCFile / Parquet (存储格式,编码和压缩) 的技术。

Doris 具有以下特点:

  • 无外部系统依赖
  • 高可靠,高可用,高可扩展
  • 同时支持 高并发点查询和高吞吐的 Ad-hoc 查询
  • 同时支持 批量导入和近实时 mini-batch 导入
  • 兼容 MySQL 协议
  • 支持 Rollup Table 和 Rollup Table 的智能查询路由
  • 支持多表 Join
  • 支持 Schema 在线变更
  • 支持存储分级,旧的冷数据用 SATA,新的热数据用 SSD

Doris 的系统架构如下:

Doris 主要分为 FE 和 BE 两种角色,FE 主要负责查询的编译,分发和元数据管理(基于内存,类似 HDFS NN);BE 主要负责查询的执行和存储系统。


Read more
Flink:什么是 Watermark?

1、什么是 watermark

watermark 网上有翻译成水印,但更应该是水位线,即 Flink 接受的数据就相当于浮在水面的物体, 基于物理知识,水位线的高度只会升高不会降低,那么每当新数据进来,会重新计算水位线的时间,计算结果小于当前水位线时间,则不会更新现有的水位线。 当水位线到达窗口触发时间时才会触发窗口的计算。watermark 的意义在于数据无序传递的时候有一定容错率,如果晚来的数据在容错范围之内,会当做正常传递来处理。

乍一看还是懵逼,那么就看下面的分析。

2、什么是流处理

Flink 被称为真正的流式实时计算框架,其批处理中是流处理的特殊情况。而所谓的流处理,本质特点是在处理数据时,接受一条处理一条。而批处理则是累积数据到一定程度在处理。这是他们本质的区别。

假如我们自己写一个流式框架。我们该如何处理消息。如下,我们看到消息按照顺序一个个发送,接受后按照顺序处理,这是没有什么问题的。

如果消息不按照顺序发送,产生了乱序,这时候该怎么处理?

其实水位线 Watermark 就是其中的解决方案之一。

Read more
推荐系统技术演进趋势:从召回到排序再到重排

推荐系统技术,总体而言,与NLP和图像领域比,发展速度不算太快。不过最近两年,由于深度学习等一些新技术的引入,总体还是表现出了一些比较明显的技术发展趋势。这篇文章试图从推荐系统几个环节,以及不同的技术角度,来对目前推荐技术的比较彰显的技术趋势做个归纳。个人判断较多,偏颇难免,所以还请谨慎参考。

在写技术趋势前,照例还是对推荐系统的宏观架构做个简单说明,以免读者迷失在技术细节中。

实际的工业推荐系统,如果粗分的化,经常讲的有两个阶段。首先是召回,主要根据用户部分特征,从海量的物品库里,快速找回一小部分用户潜在感兴趣的物品,然后交给排序环节,排序环节可以融入较多特征,使用复杂模型,来精准地做个性化推荐。召回强调快,排序强调准。当然,这是传统角度看推荐这个事情。

但是,如果我们更细致地看实用的推荐系统,一般会有四个环节,如下图所示:

四个环节分别是:召回、粗排、精排和重排。召回目的如上所述;有时候因为每个用户召回环节返回的物品数量还是太多,怕排序环节速度跟不上,所以可以在召回和精排之间加入一个粗排环节,通过少量用户和物品特征,简单模型,来对召回的结果进行个粗略的排序,在保证一定精准的前提下,进一步减少往后传送的物品数量,粗排往往是可选的,可用可不同,跟场景有关。之后,是精排环节,使用你能想到的任何特征,可以上你能承受速度极限的复杂模型,尽量精准地对物品进行个性化排序。排序完成后,传给重排环节,传统地看,这里往往会上各种技术及业务策略,比如去已读、去重、打散、多样性保证、固定类型物品插入等等,主要是技术产品策略主导或者为了改进用户体验的。

那么,每个环节,从技术发展的角度看,都各自有怎样的发展趋势呢?下面我们分头说明。

Read more
HBase内存管理之MemStore进化论

Java工程中内存管理总是一个绕不过去的知识模块,无论HBase、Flink还是Spark等,如果使用的JVM堆比较大同时对读写延迟等性能有较高要求,一般都会选择自己管理内存,而且一般都会选择使用部分堆外内存。HBase系统中有两块大的内存管理模块,一块是MemStore ,一块是BlockCache,这两块内存的管理在HBase的版本迭代过程中不断进行过各种优化,接下来笔者结合自己的理解,将这两个模块的内存管理迭代过程通过几篇文章梳理一遍,相信很多优化方案在各个系统中都有,举一反三,个人觉得对内核开发有很大的学习意义。本篇文章重点集中介绍MemStore内存管理优化。

基于跳表实现的MemStore基础模型

实现MemStore模型的数据结构是SkipList(跳表),跳表可以实现高效的查询\插入\删除操作,这些操作的期望复杂度都是O(logN)。另外,因为跳表本质上是由链表构成,所以理解和实现都更加简单。这是很多KV数据库(Redis、LevelDB等)使用跳表实现有序数据集合的两个主要原因。跳表数据结构不再赘述,网上有比较多的介绍,可以参考。

JDK原生自带的跳表实现目前只有ConcurrentSkipListMap(简称CSLM,注意:ConcurrentSkipListSet是基于ConcurrentSkipListMap实现的)。ConcurrentSkipListMap是JDK Map的一种实现,所以本质上是一种Map,不过这个Map中的元素是有序的。这个有序的保证就是通过跳表实现的。ConcurrentSkipListMap的结构如下图所示:

基于ConcurrentSkipListMap这样的基础数据结构,按照最简单的思路来看,如果写入一个KeyValue到MemStore中,肯定是如下的写入步骤:

  1. 在JVM堆中为KeyValue对象申请一块内存区域。

  2. 调用ConcurrentSkipListMap的put(K key, V value)方法将这个KeyValue对象作为参数传入。

Read more
从一句情话来了解语言模型的发展

问题定义

一段文字,例如:今夜月色真美。代表的是什么含义?如果在春天温度适宜的 9、10 点站在阳台的人对你脱口而出地说出这句话,你会怎么理解这句话,亦或者你会怎么回应他(她)呢?

这句话是十九世纪末的文学家 夏目漱石对 I love you 的英译日标注结果(今夜は月が綺麗ですね)。根据他的标注 我爱你今夜月色真美 表达了相同的意义。但是计算机这么认为吗?输入 今夜月色真美,它理解这句话和 我爱你 是相似的含义吗?这个可以被归类为自然语言理解(NLU)领域的语义匹配问题。

众所周知在计算机中一切都是数字信号,那么如果想让计算机理解一句话的含义,解决 今夜月色真美我爱你 的语义匹配问题,那么先决问题是将一句话表示为一系列的数字信号。一个理所当然的想法是将语料库中的每一个词w用一个唯一的 n 维向量v=[v1​,v2​,…,vn​]来表达,那么数个向量的序列seq={v1​,v2​,…,vm​}就可以表达一句话,这一类方法就是词嵌入模型。本期文章通过对比这个 case 在 one-hotn-gramword2vecBERT 四种语言模型的结果,分析各个方法的优缺点。

one-hot

一个最简单的想法就是使用 one-hot 向量来表达一个词。具体流程:

  1. 遍历语料库,统计词的集合W,集合大小为K
  2. 将每个词在集合W中的下标的元素为 1,其他位置元素为 0,构建长度为K的 0-1 向量

假设我们对 今夜月色真美 的分词结果为:今夜、月色、真、美。那么使用 one-hot 向量就能将这个句子表示为4×K的 0-1 矩阵。我们假设语料库中一共有 10 个词:{我、爱、你、今夜、月色、真、美、今晚、漂亮、喜欢}。那么V今夜​=[0,0,0,1,0,0,0,0,0],V今晚​=[0,0,0,0,0,0,0,1,0,0],V我​=[1,0,0,0,0,0,0,0,0,0]。

one-hot 词嵌入方法优点在于简单,并且最大程度地保留了每个词的信息。但是缺点也很明显:

  1. 对于从未出现在语料库中的未登录词,无法进行兼容。假如词 需要编码,那么只能编码为零向量,否则需要对所有词向量进行更新,扩展向量维度。
  2. 丢失了词与词之间的相关信息。例如 今夜今晚 本身是相近语义的词,但是通过 one-hot 编码的向量差异并没有比 今夜 小。
Read more
Dataflow 模型

Dataflow 模型:是谷歌在处理无边界数据的实践中,总结的一套 SDK 级别的解决方案,其目标是做到在非有序的,无边界的海量数据上,基于事件时间进行运算,并能根据数据自身的属性进行 window 操作,同时数据处理过程的正确性,延迟,代价可根据需求进行灵活的调整配置。

DataFlow 模型核心

和 Spark 通过 micro batch 模型来处理 Streaming 场景的出发点不同,Dataflow 认为 batch 的处理模式只是 streaming 处理模式的一个子集。在无边界数据集的处理过程中,要及时产出数据结果,无限等待显然是不可能的,所以必然需要对要处理的数据划定一个窗口区间,从而对数据及时的进行分段处理和产出,而各种处理模式(stream,micro batch,session,batch),本质上,只是窗口的大小不同,窗口的划分方式不同而已。Batch 的处理模式就只是一个窗口区间涵盖了整个有边界的数据集这样的一种特例场景而已。一个设计良好的能处理无边界数据集的系统,完全能在准确性和正确性上做到和“Batch”系统一样甚至应该更好。

Read more
来美团3个月总结

来美团也三个月了,也渐渐习惯这边的风格。再流程制度上,有让我觉得很不错的地方,也有一些需要改善的地方。自己的能力模型上,还有哪些需要提高的,接下来自己需要在这些地方进步。

好的地方

  • 文档。在文档这方便做的挺好的,把工作中很多都能记录下来,比如会议纪要,产品PRD,技术方案,月度总结等,以及各个系统的详细文档等。而且也能搜到很多技术方案设计,能力模型等。这样比较详细的学习别人怎样去做的,怎样设计的。
  • 各个基础平台和系统。在这边不用什么都从头开始,公司提供了各种基础平台,比如服务发布的CI/CD工具,微服务的RPC框架,服务治理,熔断降级等系统。以及各种存储,KV存储,es平台,大数据平台等,让自己能够专注于业务,而不需要放很多精力在以来的平台开发运维上面。
  • 流程规范。大公司流程还是比较规范的,如开发上线流程,整套流程每一步都细化,大家按照这套流程开发。极大的规避掉一些因为个人理解偏差和信息对齐上面造成的上线问题,能够保质保量的进行新功能迭代上线。
  • 制定绩效合同,后面绩效根据此打,更大化的做得客观。
  • 因为我原来是做大数据平台的,更多的面向的是公司内部,而现在是面向用户。可以感受到这边对监控,线上问题的也紧要重视。(这个主要是我岗位的变化)
Read more