This is an automated email from the ASF dual-hosted git repository.
shaofengshi pushed a commit to branch document
in repository https://gitbox.apache.org/repos/asf/kylin.git
The following commit(s) were added to refs/heads/document by this push:
new 1b8a81a minor format in 2.6.0 announcement
1b8a81a is described below
commit 1b8a81aecf9347a52e94cce9e383adf3daafe14b
Author: shaofengshi <[email protected]>
AuthorDate: Mon Jan 21 12:09:11 2019 +0800
minor format in 2.6.0 announcement
---
.../_posts/blog/2019-01-18-release-v2.6.0.cn.md | 50 +++++++++++-----------
1 file changed, 25 insertions(+), 25 deletions(-)
diff --git a/website/_posts/blog/2019-01-18-release-v2.6.0.cn.md
b/website/_posts/blog/2019-01-18-release-v2.6.0.cn.md
index 2c3f812..587648c 100644
--- a/website/_posts/blog/2019-01-18-release-v2.6.0.cn.md
+++ b/website/_posts/blog/2019-01-18-release-v2.6.0.cn.md
@@ -14,51 +14,51 @@ Apache Kylin 是一个开源的分布式分析引擎，旨在为极大数据集
### 针对以JDBC为数据源的SDK
Kylin目前已经支持通过JDBC连接包括Amazon Redshift, SQL Server在内的多种数据源。
-为了便于开发者更便利地处理各种SQL dialect的不同以更加简单地开发新的基于JDBC的数据源，Kylin提供了相应的SDK和统一的API入口：
+为了便于开发者更便利地处理各种 SQL 方言（dialect） 的不同以更加简单地开发新的 JDBC 数据源，Kylin 提供了相应的 SDK 和统一的
API 入口：
* 同步元数据和数据
-* 构建cube
+* 构建 cube
* 当找不到相应的cube来解答查询时，下推查询到数据源
更多内容参见 KYLIN-3552。
-### Memcached作Kylin的分布式缓存
-在过去，Kylin对查询结果的缓存不是十分高效，主要有以下两个方面的原因。
-一个是当Kylin的metadata发生变化时，会主动盲目地去删除大量有效的缓存，使得缓存会被频繁刷新而导致利用率很低。
-另一点是由于只使用本地缓存而导致Kylin server之间不能共享彼此的缓存，这样查询的缓存命中率就会降低。
-本地缓存还有一个缺点就是大小受到限制，不能像分布式缓存那样水平扩展。这样导致能缓存的查询结果量受到了限制。
+### 使用 Memcached 作 Kylin 的分布式缓存
+在过去，Kylin 对查询结果的缓存不是十分高效，主要有以下两个方面的原因：
+一个是当 Kylin 的 metadata 发生变化时，会主动盲目地去清除大量缓存，使得缓存会被频繁刷新而导致利用率降低。
+另一点是由于只使用本地缓存而导致 Kylin server 之间不能共享彼此的缓存，这样查询的缓存命中率就会降低。
+本地缓存的一个缺点是大小受到限制，不能像分布式缓存那样水平扩展。这样导致能缓存的查询结果量受到了限制。
针对这些缺陷，我们改变了缓存失效的机制，不再主动去清理缓存，而是采取如下的方案：
1. 在将查询结果放入缓存之前，根据当前的元数据信息计算一个数字签名，并与查询结果一同放入缓存中
2. 从缓存中获取查询结果之后，根据当前的元数据信息计算一个数字签名，对比两者的数字签名是否一致。如果一致，那么缓存有效；反之，该缓存失效并删除
-我们还引入了Memcached作为Kylin的分布式缓存。这样Kylin server之间可以共享查询结果的缓存，而且由于Memcached
server之间的独立性，非常易于水平拓展，更加有利于缓存更多的数据。
-相关开发任务是KYLIN-2895, KYLIN-2894, KYLIN-2896, KYLIN-2897, KYLIN-2898, KYLIN-2899。
+我们还引入了 Memcached 作为 Kylin 的分布式缓存。这样 Kylin server 之间可以共享查询结果的缓存，而且由于 Memcached
server 之间的独立性，非常易于水平拓展，更加有利于缓存更多的数据。
+相关开发任务是 KYLIN-2895, KYLIN-2894, KYLIN-2896, KYLIN-2897, KYLIN-2898, KYLIN-2899。
-### ForkJoinPool简化fast cubing的线程模型
-在过去进行fast cubing时，Kylin使用自己定义的一系列线程，如split线程，task线程，main线程等等进行并发的cube构建。
+### ForkJoinPool 简化 fast cubing 的线程模型
+在过去进行 fast cubing 时，Kylin 使用自己定义的一系列线程，如 split 线程，task 线程，main 线程等等进行并发的 cube
构建。
在这个线程模型中，线程之间的关系十分的复杂，而且对异常处理也十分容易出错。
-现在我们引入了ForkJoinPool，在主线程中处理split逻辑，构建cuboid的任务以及子任务都在fork join
pool中执行，cuboid构建的结果可以被异步的收集并且可以更早地输出给下游的merge操作。更多内容参见 KYLIN-2932。
+现在我们引入了 ForkJoinPool，在主线程中处理 split 逻辑，构建 cuboid 的任务以及子任务都在 fork join
pool中执行，cuboid 构建的结果可以被异步的收集并且可以更早地输出给下游的 merge 操作。更多内容参见 KYLIN-2932。
-### 改进HLLCounter的性能
-对于HLLCounter， 我们从两方面进行了改进：构建HLLCounter和计算调和平均的方式。
-1. 关于HLLCounter的构建，我们不再使用merge的方式，而是直接copy别的HLLCounter里面的registers
-2. 关于计算HLLCSnapshot里面的调和平均，做了以下三个方面的改进：
+### 改进 HLLCounter 的性能
+对于 HLLCounter， 我们从两方面进行了改进：构建 HLLCounter 和计算调和平均的方式。
+1. 关于 HLLCounter 的构建，我们不再使用merge的方式，而是直接copy别的HLLCounter里面的registers
+2. 关于计算 HLLCSnapshot 里面的调和平均，做了以下三个方面的改进：
* 缓存所有的1/2^r
* 使用整型相加代替浮点型相加
-* 删除条件分支，例如无需检查registers[i]是不是为0
+* 删除条件分支，例如无需检查 registers[i] 是不是为0
更多内容参见 KYLIN-3656。
-### 改进Cube Planner算法
-在过去，cube planner的phase two增加未被预计算的cuboid的方式只能通过mandatory
cuboid的方式。而一个cuboid是否为mandatory，又有两种方式：
-手动设置，查询时rollup的行数足够大。这里通过判断查询时rollup的行数是否足够大来判断是否为mandatory cuboid的方式有两大缺陷：
-* 一个是估算rollup的行数的算法不是很好
-* 一个是很难设立一个静态的阈值来做判定
+### 改进 Cube Planner 算法
+在过去，cube planner 的 phase two 增加未被预计算的 cuboid 的方式只能通过 mandatory cuboid 的方式。而一个
cuboid 是否为 mandatory，又有两种方式：
+手动设置，查询时 rollup 的行数足够大。这里通过判断查询时 rollup 的行数是否足够大来判断是否为 mandatory cuboid
的方式有两大缺陷：
+* 一是估算 rollup 的行数的算法不是很好
+* 二是很难设立一个静态的阈值来做判定
-现在我们不再从rollup行数的角度看问题了。一切都是从cuboid行数的角度看问题，这样就和cost based的cube planner算法做了统一。
-为此我们通过使用rollup比率来改进了未被预先构建的cuboid的行数的估算，然后让cost based的cube
planner算法来判定哪些未被构建的cuboid该被构建，哪些该被遗弃。
-通过这样的改进，无需通过设定静态的阈值来推荐mandatory cuboid了，而mandatory cuboid只能被手动设置，不能被推荐了。更多内容参见
KYLIN-3540。
+现在我们不再从 rollup 行数的角度看问题了。一切都是从 cuboid 行数的角度看问题，这样就和 cost based 的 cube planner
算法做了统一。
+为此我们通过使用 rollup 比率来改进了未被预先构建的 cuboid 的行数的估算，然后让 cost based 的 cube planner
算法来判定哪些未被构建的 cuboid 该被构建，哪些该被遗弃。
+通过这样的改进，无需通过设定静态的阈值来推荐 mandatory cuboid 了，而 mandatory cuboid
只能被手动设置，不能被推荐了。更多内容参见 KYLIN-3540。
__下载__
