你的SQL中使用了好多 in 关键字，效率肯定不高了，例如下面的SQL
SELECTCOUNT(p.id)pstn_totalnum
FROMportp
WHEREp.device_idin(SELECTde.id
FROMdevicede
WHEREde.local_net_id=810
ANDde.sub_type=2001)
你完全可以不使用 in 关键字，如：
SELECTCOUNT(p.id)pstn_totalnum
FROMportp,devicede
WHEREp.device_id=de.id
andde.local_net_id=810
andde.sub_type=2001
都是同样的结果，但效率肯定是不一样的，device 符合条件的数据越多，效率越慢，至于上面的一些SQL，肯定还有优化的地方，比如 exists 关键字内部的SQL，效率也不会高，根据逻辑看看有没有需要优化的地方。
B. DSL是什么意思
两个意思，一个是数字用户线路，另一个是领域特定语言。
DSL的中文名是数字用户线路，是以电话线为传输介质的传输技术组合。DSL技术在传递公用电话网络的用户环路上支持对称和不对称的传输方式，解决了网络服务商与终端用户之间经常出现的“最后一公里”传输瓶颈问题。
领域特定语言（英语：domain-specific language、DSL）指的是专注于某个应用程序领域的计算机语言。又译作领域专用语言。同名着作是DSL领域的一部不朽作品。该书由世界一流的软件开发大师和软件开发“教父”Martin Fowler撰写多年而成，ThoughtWorks中国翻译。
(2)sql转esdsl扩展阅读：
领域特定语言的分类：
1、外部DSL：与应用程序系统中使用的语言不同，通常使用用户定义的语法。宿主应用的代码采用文本解析技术来解析外部DSL编写的脚本。例子如：正则表达式、SQL、AWK以及Struts的配置文件等。
2、内部DSL：通用语言的特定语法，内部DSL编写的脚本是一个合法的程序，但它有特定的风格，而且只使用部分语言特性来处理整个系统的一个小方面。
3、语言工作台：一个特殊的IDE用于定义和构造DSL。具体来说，语言工作台不仅用于确定DSL的语言结构，还用于确定编写DSL脚本的人员的编辑环境。最后一个脚本将编辑环境与语言本身结合起来。
C. DSL是什么意思
DSL（Digital Subscriber Line）的中文名是数字用户线路，是以电话线为传输介质的传输技术组合。DSL包括ADSL(Asymmetric Digital Subscriber Line，非对称数字用户线)、RADSL、HDSL和VDSL等等。
DSL技术在传递公用电话网络的用户环路上支持对称和非对称传输模式，解决了经常发生在网络服务供应商和最终用户间的“最后一公里”的传输瓶颈问题。由于DSL 接入方案无需对电话线路进行改造，可以充分利用可以已经被大量铺设的电话用户环路，大大降低额外的开销。
因此，利用铜缆电话线提供更高速率的因特网接入，更受用户的欢迎，在一些国家和地区得到大量应用。
(3)sql转esdsl扩展阅读：
用户终端设备是DSL调制解调器。它转换二进制数据到数字电脉冲，使得信号在数字音频流的频段内传输。
另外如果用户在同一根线路上使用老式电话，还需要加装一个被动电子滤波器。这样就能保证DSL调制解调器和电话只接受他们设计使用的信号。如果使用"wires-only"服务，用户可以把滤波器插入一个现有的电话插槽，或者DSL运营商可能安装它。
在交换局端使用数字用户线路访问复用器（DSLAM）将DSL电路上的数据汇聚然后转发到其他的网络。它还能分离出语音部分。
参考资料来源：网络-DSL
D. 为什么sparkSQL
Shark和sparkSQL 但是，随着Spark的发展，其中sparkSQL作为Spark生态的一员继续发展，而不再受限于hive，只是兼容hive；而hive on spark是一个hive的发展计划，该计划将spark作为hive的底层引擎之一，也就是说，hive将不再受限于一个引擎，可以采用map-rece、Tez、spark等引擎。
Shark为了实现Hive兼容，在HQL方面重用了Hive中HQL的解析、逻辑执行计划翻译、执行计划优化等逻辑，可以近似认为仅将物理执行计划从MR作业替换成了Spark作业（辅以内存列式存储等各种和Hive关系不大的优化）；同时还依赖Hive Metastore和Hive SerDe（用于兼容现有的各种Hive存储格式）。这一策略导致了两个问题，第一是执行计划优化完全依赖于Hive，不方便添加新的优化策略；二是因为MR是进程级并行，写代码的时候不是很注意线程安全问题，导致Shark不得不使用另外一套独立维护的打了补丁的Hive源码分支（至于为何相关修改没有合并到Hive主线，我也不太清楚）。
此外，除了兼容HQL、加速现有Hive数据的查询分析以外，Spark SQL还支持直接对原生RDD对象进行关系查询。同时，除了HQL以外，Spark SQL还内建了一个精简的SQL parser，以及一套Scala DSL。也就是说，如果只是使用Spark SQL内建的SQL方言或Scala DSL对原生RDD对象进行关系查询，用户在开发Spark应用时完全不需要依赖Hive的任何东西。
E. “日记”ElasticSearch7.x新功能介绍
说明：ElasticSearch7.X很多新功能主要基于lucene8.X新特性，故对于lucene8.X新特性不赘述。
在6.1中已加入这个功能，但是默认是关闭的，在7.0中开始默认开启。若有两个节点，且其中一个节点上有一个索引的主分片，另一个节点上有同一个索引的副本分片，在6.X中关闭此特性时，不管每个节点状态如何，是否在做耗时操作，如GC等，每次请求过来时，都会通过轮询的方式访问两个分片其中之一；而在7.X开启后，ES会统计每次请求耗时，根据每个节点访问响应的耗时长度，对每个节点的访问频次进行自动调整。
Elasticsearch 7.0 中若分片在30秒内无请求访问，则分片进入"search idle"状态。一旦进入此状态且分片所在索引没有明确设置refresh间隔时间的（默认每秒执行），则定时的refresh停止直到下一个访问请求达到才进行下一次的refresh，在此期间相比原来，将明显增强索引数据的吞吐。如果明确设置了refresh间隔时间，则仍按配置中的间隔时间进行调度执行。
Elasticsearch5.3中发布了跨集群搜索（cross-cluster search）功能，供用户跨多个集群进行查询，如本地协调节点去访问多个不同机房的ES集群查询日志信息等。Elasticsearch 7.0中引入ccs_minimize_roundtrips执行模式可以减少一次请求来回的网络开销。
详情： https://www.elastic.co/guide/en/elasticsearch/reference/7.x/moles-cross-cluster-search.html
Elasticsearch 6.x 及之前的版本使用名为 Zen Discovery 实现，存在一些缺点，如选主时间较慢（秒级）、部分配置存在易于错配等情况。
Elasticsearch 7重新设计了集群协调子系统，移除了minimum master nodes设置，由集群自己选择可以形成法定数量的节点。并且新的子系统可以在很短时间内（亚秒级）完成选主。
Elasticsearch 7.0新增加了一个熔断器，更好的追踪内存使用量，准确地根据内存用量去拒绝客户端请求，避免节点异常；另外聚合操作返回的bucket限制为10000以内。
在 Elasticsearch 6.5中作为beta功能引入，6.7、7.X中GA，可以用在跨机房、跨地区情况下的集群数据同步。在这个版本中加入了一些监控的特性，解决了一些例如主从同步异常的问题。
详情： https://www.elastic.co/guide/en/elasticsearch/reference/7.6/ccr-getting-started.html
索引生命周期管理（Index Lifecycle Management）作为一个beta特性在6.6发布，在7.0GA。索引生命周期管理现在可以管理frozen indices，他作为其cold阶段的一部分；也可以对其管理的索引使用CCR功能。
frozen indices详情： https://www.elastic.co/guide/en/elasticsearch/reference/7.0/frozen-indices.html
ILM详情： https://www.cnblogs.com/sanzxcvbnm/p/12083735.html ； https://www.jianshu.com/p/94e37a5b0878?hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io
Elasticsearch SQL可以让用户能够使用SQL进行交互查询Elasticsearch中索引数据。该功能在Elasticsearch 6.3中作为alpha版本引入，目前在Elasticsearch 6.7和7.0中也能够生产使用。 通过 Elasticsearch REST endpoints 、 Elasticsearch SQL command line interface 、 JDBC driver 、 ODBC driver 可以使用es sql。
从Elasticsearch 7.0.0开始，High-level REST Client（HLRC）API的所有功能已经宣布完成。原来TransportClient使用者可以计划将TransportClient迁移到HLRC。
Elasticsearch 7.0.0引入了JDK8原生时间库，可以处理纳秒精度时间戳。
JDK11可以支持TLS1.3，所以如果使用JDK11，那在es中可以选择使用TLS1.3.另外TLS1.0被移除，使用老版本jdk的可以选择使用TLS1.1或者1.2。
内置了OpenJDK，使得上手起来更加快速。
在日志目录下，我们会看到有.json拓展的日志。这便于我们使用类似jq的工具去查看日志，同时也在日志中加入了许多额外结构化信息，例如node.id, cluster.uuid, type。
这是lucene8中的重要版本功能更新。在之前的版本中，查询会计算所有命中的文档，但是用户经常查询 'a' , 'the' 等词汇，这种词汇不会增加多少文档得分，但迫使查询过程为大量的文档进行打分。
因此，如果检索结果只需要返回 TOP-K 的结果，而非范围准确的命中数量，可以对此进行优化，Lucene 8 中引入了 WAND 算法来实现此特性。当检索结果小于指定的结果总数时，该优化不会生效。
在停止计算命中文档总数之后，查询 QPS 得到大幅提升，以下结果来自 lucene 官方基准测试
Bool AND 查询，提升 2.3 倍左右。
Bool OR 查询，提升 2.5 倍左右。
Term 查询，提升 40 倍左右。
在 Elasticsearch 7中，要在查询中返回 TOP-K 的结果，通过 track total hits 参数来指定，默认值为10000，根据自己的需要设置返回前 K 个命中结果，或者设置为 true，返回全部命中结果数量。
计算 TOP-K 的过程中需要评估文档的最大得分，这需要在索引过程中写入一些额外的信息。Lucene 将词典划分一个个的 block，并构建了一个跳跃表，在查询的时候跳过不匹配的文档，现在，索引过程中会为每个块中最高影响(impacts）的摘要添加到该跳表中，可以计算出该块可能产生的最大得分，如果该得分不具有竞争力，则可以跳过它。更多信息可以阅读 此处 。
Elasticsearch 7.0 中新增了两个数据类型： rank_feature and rank_features 。他们只作用于数值型数据，且底层实现上可以利用上面top hits的特性。故可以看作是function score简化出的一个功能，利用他们可以对排序打分进行干预且查询效率更快。更多可以看以下详情： https://www.elastic.co/cn/blog/easier-relevance-tuning-elasticsearch-7-0
别名function score2。拓展性更佳，可以支持多种脚本语言及java插件，function score原有功能也都可以支持。详情： https://www.elastic.co/guide/en/elasticsearch/reference/7.0/query-dsl-script-score-query.html
在ElasticSearch7.2+后关闭状态的索引也可以进行分片复制，以便于后面集群异常时可以成为主分片，或者进行数据恢复。
可以作于搜索联想功能，用户输入部分查询词后，返回联想词列表。与Completion suggester和Context Suggester功能大部分重复，但两者有不同的底层实现，search_as_you_type可以利用到最新top hits的特性，而suggester底层使用FST数据结构。之所以重新开发了一个数据字段，原因归结为：新数据字段更有利于占用更少的内存开销；新数据字段功能拓展性更加，可以用在普通的query语句中，结合其他filter等语法。
详情： https://www.elastic.co/guide/en/elasticsearch/reference/7.6/search-as-you-type.html ； https://github.com/elastic/elasticsearch/issues/33160 ； https://stackoverflow.com/questions/42127894/whats-the-difference-between-search-as-you-type-and-context-suggester
只能作用于date, date_nanos, 及 geo_point数据类型的字段。可以放置于query语法中，在查询中过滤不符合范围的时间或者距离，查询语法中需要设置origin（即初始的时间节点或者经纬度）。
一个只能在选举时投票而不能成为主节点的角色被引入了，这有助于高可用，且相对于主节点，这些节点只需要消耗非常少量的CPU和内存开销。
新的 Analyzer reload API 允许去修改运行时的分析器及其相应资源。例如，在之前版本中，重载同义词需要先关闭索引，再打开索引。使用这个api就不需要再关闭索引了。
通过这个字段可以直接索引json数据。仅为整个JSON对象创建一个字段映射，这可以帮助防止由于大量不同的字段映射而导致 映射爆炸 。
详情： https://blog.csdn.net/UbuntuTouch/article/details/103713730
有两种字段类型： sparse_vector 和 dense_vector ，用于计算和查询向量之间的余弦相似度和点积。
如题。
仅限于设置为只读的别名索引可以同步，write索引不可以同步。
如题。
在ElasticSearch6.X中，使用 Terms Aggregation会占用更多的内存，此版本进行了优化，降低内存消耗压力。
使用无监督的异常检测算法分析索引中每条doc的数值型字段，并在每条doc中记录一个异常值，以比较彼此之间的异常差异。提供 evaluate data frame analytics API ，以获取在算法使用期间的一些指标数据。
它会聚合出在特定字段中很少出现的字段值。计划使用它去替换terms aggregation中的"order" : { "_count" : "asc" }配置项。
提供新接口 pinned query ，可以指定排在返回结果前列的docs，适用于需要使用引导数据的场景。
支持AdoptOpenJDK 13，并将其打包在ES包中。
如果查询是以_search结尾，那么当对端连接被关闭后，查询也会被中止。
通过这个字段可以在es插入一个几何范围，即每条doc都是通过一串坐标点定义的几何范围，而通过shape query结合relationship配置，可以对每条doc计算是否是包含、相交等等关系，并将符合条件的取出。
详情： https://www.elastic.co/guide/en/elasticsearch/reference/7.x/query-dsl-shape-query.html ； https://blog.csdn.net/wjzt7322/article/details/103385560 ；
增加了一个新的圆形预处理，把圆形定义的几何图形转化为一个近似的规则几何，便于查询、聚合、索引等操作。图形如下：
详情： https://www.elastic.co/guide/en/elasticsearch/reference/7.x/ingest-circle-processor.html
现在直方图和日期直方图将支持范围字段，例如用其去计算特定时间段内的电话数等。
如题。
Elasticsearch 5.x版本中引入了Ingest Node的概念（预处理节点），它使得Es在事实上具备了Logstash的部分功能，即对索引数据的预处理。
在7.5增加了一个新的ingest processor，它可以使得新数据索引时从原有其他索引中抽取字段数据丰富正在插入的doc。
详情： https://www.felayman.com/articles/2017/11/24/1511527532643.html ； https://blog.csdn.net/UbuntuTouch/article/details/103400061
新的快照生命周期管理功能，允许用户设置定时策略去删除老的索引。
新增暂停和恢复接口，使用户可以临时暂停自动复制的模式
分类分析是一个有监督的机器学习算法，可以预测离散的分类值。在Es中可以进行二分类的算法执行，即将数据分为两个可能的类别。
详情： https://www.elastic.co/guide/en/machine-learning/7.x/dfa-classification.html
暂略（ https://www.elastic.co/guide/en/elasticsearch/reference/7.x/histogram.html ）
新版本lucene对这方面进行了重构，重构后也能在排序时过滤在打分上没有竞争力的文档(类似top hits)，在查询效率上提升至少10倍。
ElasticSearch 7.2.0中引入，现在GA。 Transforms and Transform APIs 提供给我们一个能力，即指定索引中不同字段进行聚合，并将聚合结果索引入一个新建索引中（聚合结果中可以产生出其他新的字段，如同类型字段值的出现数量等），在这个过程中我们可以通过管理接口进行管理，每次聚合结果索引入新索引后，原索引中都会有一个checkpoint，故后面可以继续做批量聚合。
详情： https://www.elastic.co/guide/en/elasticsearch/reference/7.x/transforms.html
参考资料：
https://gitbook.cn/gitchat/column/5ce4ff9a308dd66813d92799/topic/5d47cfa4cb702a087ef8b77b
https://blog.csdn.net/UbuntuTouch/article/list/1
https://www.elastic.co/guide/en/elasticsearch/reference/7.x/release-highlights-7.3.0.html
F. jooq 为什么不直接写sql
JOOQ设计上，就是通过类去操作数据库，减少开发人员直接写SQL的麻烦。可以说它是基于ORM却高于ORM的一个设计。通过DSL编写，继承了传统的ORM框架的优点，也弥补了Mybatis这类半自动化框架的不足。总之这个框架设计思想还是不错的。
G. elasticsearch基本查询笔记（三）-- es查询总结
term 查询是简单查询，接受一个字段名和参数，进行精准查询，类似sql中：
ES中对应的DSL如下：
在ES5.x及以上版本，字符串类型需设置为keyword或text类型，根据类型来进行精确值匹配。
当进行精确值查询，可以使用过滤器，因为过滤器的执行非常快，不会计算相关度（ES会计算查询评分）,且过滤器查询结果容易被缓存。
bool过滤器组成部分：
当我们需要多个过滤器时，只须将它们置入 bool 过滤器的不同部分即可。
terms是包含的意思，如下：
name包含["奥尼尔","麦迪"]
返回结果：
range查询可同时提供包含（inclusive）和不包含（exclusive）这两种范围表达式，可供组合的选项如下：
类似sql中的范围查询：
ES中对应的DSL如下：
如下sql，age不为null：
ES中对应的DSL如下：
如下sql，age为null：
ES中对应的DSL如下：
注：missing查询在5.x版本已经不存在。
匹配包含 not analyzed（未分词分析）的前缀字符：
匹配具有匹配通配符表达式（ (not analyzed ）的字段的文档。 支持的通配符：
1） * 它匹配任何字符序列（包括空字符序列）；
2） ? 它匹配任何单个字符。
请注意，此查询可能很慢，因为它需要遍历多个术语。
为了防止非常慢的通配符查询，通配符不能以任何一个通配符*****或 ? 开头。
正则表达式查询允许您使用正则表达式术语查询。
举例如下：
注意： * 的匹配会非常慢，你需要使用一个长的前缀，
通常类似.*?+通配符查询的正则检索性能会非常低。
模糊查询查找在模糊度中指定的最大编辑距离内的所有可能的匹配项，然后检查术语字典，以找出在索引中实际存在待检索的关键词。
举例：
检索索引test_index中，type为user的全部信息。不过在 es6.x 版本，一个index仅有一个type，未来 es7.x 版本，将取消type，所以这个查询没啥意义。
返回指定id的全部信息。
全文检索查询，是通过分析器，对查询条件进行分析，然后在全文本字段进行全文查询。
全文搜索取决于mapping中设定的analyzer（分析器），这里使用的是ik分词器。
所以在进行查询开发时候，需要先了解index的mapping，从而选择查询方式。
匹配查询接受文本/数字/日期类型，分析它们，并构造查询。
对查询传入参数进行分词，搜索词语相同文档。
match_phrase查询分析文本，并从分析文本中创建短语查询。
用户已经渐渐习惯在输完查询内容之前，就能为他们展现搜索结果，这就是所谓的即时搜索（instant search） 或输入即搜索（search-as-you-type） 。
不仅用户能在更短的时间内得到搜索结果，我们也能引导用户搜索索引中真实存在的结果。
例如，如果用户输入 johnnie walker bl ，我们希望在它们完成输入搜索条件前就能得到： Johnnie Walker Black Label 和 Johnnie Walker Blue Label 。
match_phrase_prefix与match_phrase相同，除了它允许文本中最后一个术语的前缀匹配。
H. Dsl转为sql drools
1、打开使用的编程软件，找到设置并点击进入。
2、找到格式设置，将Dsl转换为sql，并将drools选项打开就完成格式的转换了。
I. sql中怎么设置默认值
1、首先新建一个学生表：student，需求：字段password的默认值是1213142。
J. 日志平台的一点思考
日志平台的对开发、运维人员的帮助是非常大的，它可以方便开发、运维人员快速定位问题，从这个角度，日志平台是个搜索平台；同时还可以做有效的数据分析，比如分析 pv, uv，httpstatus，用户行为，资源消耗，网络攻击、trace等等，应用场景非常丰富，这时候它又是个数据分析平台，在马上到来的5G时代，物联网的真正兴起，日志平台会发挥更大的价值。
日志其实是比较宽泛的概念，应用打印的server log,Linux文件系统的syslog，/var/messages 等等都是日志，日志本质上其实是一种时序数据，类似于监控领域的metrics，只不过metrics一般是比较结构化的，每个字段数据长度都比较小，通常是时间+tag+value ，而日志也带有时间，但是单条日志可能会比较长（有时候不止一行） ，同时大多数都是非结构化的文本数据，它们共同的特点是数据产生后不会被更新。
简单说日志平台既要存储又要计算
功能上，日志平台应该具备以下几个基本的功能点
1、日志的采集
2、日志数据的存储
3、日志数据的快速检索和分析
日志要搜索，就要集中存储，就要采集日志，以前日志采集分2种，一种是agent的方式，一种是agentless的方式，前者是在要采集的服务器上部署一个agent，agent将日志不断的发送给日志server端，agentless的方式是通过类似ssh远程登录服务器去抓日志。
agentless的方式不需要部署agent，一般是定时的方式去拉日志过来，这种方式时效性很差，不能实时监听文件系统获取最新的日志数据，基本上业内很少有人采用了，以前阿里巴巴的TLog似乎是采用这种方式。
现在大部分是采用部署agent的方式获取日志，比较有名的是flume,logstash,filebeat等等，flume和logstash在使用的时候，不方便控制占用的cpu和内存资源，在微服务化架构的环境中，采集日志对agent的性能要求越来越高，同时资源消耗要尽可能的低，filebeat相对比较轻量，功能也非常强大，使用人越来越多。
agent的方式本质上是调用server的api接口将数据发送给日志的server，因此另一种使用方式就是app直接调用日志server的api，比如将这个功能做成log4j的插件，或者写入其它的常用的日志组件中，这样日志采集的成本最低，但是当日志服务不可用的时候，日志数据恢复成了稍微麻烦的事情。
通常在一个成规模的企业内部，使用agent的方式采集日志，管理agent也是一个问题，比如阿里巴巴目前声称SLS的agent部署超过200万个节点，不要说200万个节点，就是200个节点，我们总不能挨个登陆去修改agent的配置文件吧，因此采集任务的自动下发，生效，更改非常重要，同时还要能够自动管理agent的状态，升级agent等等。
以前阿里巴巴的TT也有agent采集，部署规模也较大，在实现方面，有些场景下agent会请求服务端的clientAPI，这种设计在双11降级恢复的时候，会给clientAPI带来非常大的压力，因此，在设计应用于大规模的agent部署场景的时候，应该考虑这种问题。
写的目的是为了读，要更好的读，就要设计更合理的存储方案。既要满足检索，又要做数据统计和分析，似乎解决方案只有倒排索引了？开源社区一提到日志的存储，一般都会选择elasticsearch，一些创业公司也会基于或者借鉴es来做存储的方案，这个东西的确开箱即用，一个命令拉起来，日志灌进去，搜索效果似乎也不错，kibana也能分析，但是当我们实际部署应用起来，就会发现用es存日志是一个成本非常昂贵的方案。
在一家稍有规模的公司，日志数据10w/s每秒的写入是非常容易出现的，实时索引，然后刷到文件系统缓存才可见，es这种实现方式，本身就不适合迎接这种高tps的写入，同时它读写不分离，一般情况下，Lucene的设计在日志场景下需要经过特殊的优化，比如将那些常驻内存的数据进行lru处理，将不常用的索引关闭，在merge的时候对避免重复IO，segment关系映射内存优化等等，越深入了解，越发现这种方案真的太奢华了，业内用es做日志存储的基本上都是土豪，动辄几百上千的服务器堆砌 + 精细化运维，性价比极低，真是暴殄天物，日志规模较大的，财力一般的公司就不要考虑这种败家的方案了。
日志的存储实际上需要实时求是，根据日志的特点，灵活的设计存储方案。
日志搜索也是一种典型的交互式查询的场景, 当然是越快越好，比较理想的情况是1-3秒返回结果，但是时间跨度非常大的场景，十几秒用户也能接受，超大规模查询最慢不超过30秒等等，检索方面，除了输入关键字，还希望能够支持功能强大的分析、过滤、统计。这种特点，其实给存储留下了非常大的设计空间，也是不小的挑战。
存储首先应该是分布式的，可以方便水平扩展的，同时根据日志的特点，做少量的必要的索引。比如日志一般是按照时间范围搜索和分析的，那么时间显然是最重要的索引，同时日志来自哪些机器，属于哪个应用，什么机房，应该会有一些标签，那做一些基于标签的索引就足够了，那么现有的一些存储系统能不能直接利用呢？
前面说了日志是一种时序数据，那么opentsdb能不能做日志的存储呢？opentsdb本身依赖hdfs，hbase，从部署角度讲，太复杂，同时它一行就存储一小时的数据，每一行是一个metric，这种方式，你日志怎么存，显然不合理。
kafka这种东西呢，它也给每条消息加了时间戳信息，支持按照时间戳seek，kafka的架构设计其实给了我很多日志存储设计的启发，但是它的索引仅有时间是不够的，也许你会想能不能在topic名字上做点文章，我想也是不可以，因为我们要索引的东西还是蛮多的，kafka在topic数量非常大的情况下，性能会下降的比较明显。
日志统计和分析方面阿里巴巴的SLS是通过标准SQL来做的，但是我更喜欢类似shell命令行的风格和方式，sql思维需要一些时间转变，用户并不一定都会喜欢sql，但是不管怎么样，要分析、统计日志，需要在日志存储系统上面搭建一套DSL分析引擎，能够加入常用的算子，同时还能分布式执行这些运算，同时快速的返回结果，曾经想过用MLSQL加载日志的数据然后用sql分析完将结果取回，这其实也是一条很好的思路，虽然MLSQL不需要每次都提交spark作业的过程，但是搬运数据还是会牺牲掉一部分时效性，好处是计算和存储是分离的，同时我还希望日志平台能够实时的监听一些我感兴趣的日志事件，然后在自定义的dashboard中展示，支持报警等等。
最近1-2年一直在研究探索更具性价比的日志管理平台，后续会将一些心得体会、解决方案记录下来跟大家分享。