上个月老板让我搭一个日志分析系统，选用了 ELK 作为技术栈，网上的文章较为混乱，前期刚接触的时候查资料踩了很多坑，所以根据我总共一个星期的接触（包括安装和后期运维），大致总结一下我个人的最佳实践。

本文主要内容为：

• 架构逻辑
• 安装
• 配置
• Docker 方案

这张图相信足以证明 ELK Stack 的强大之处了：

架构逻辑

E(lasticsearch) L(ogstash) K(ibana) 本身这里并不做过多介绍。

值得一提的是，为了让整个系统更好的分层，是非常建议引入 Redis 的。Redis 作为一个缓存，能够帮助我们在主节点上屏蔽掉多个从节点之间不同日志文件的差异，负责管理日志端（从节点）的人可以专注于向 Redis 里生产数据，而负责数据分析聚合端的人则可以专注于从 Redis 内消费数据。

同时，Kibana 本身并不具备访问限制，这不是我们期望的，因此可以用考虑用 Nginx 做一层反向代理，并做身份验证。

综上所述，整个 ELK 的架构应该是下图所示的样子：

今天在熊猫 TV 上看乌云白帽子大会，下面有三道互动的题目挺有意思的。

前面两题都很简单，第一题是解一个莫斯电码、第二题答案很简单，但是要提交答案需要在网页源码上懂点手脚。

第三题是重头戏，不过难度也不高，题目如下：

第三题每个人的答案都不一样，图片里被我划掉的这部分是我的用户名（手机号） K。

红色部分的一串数字就是经过上面的 DEKHash 算出的结果，所以题意就很明显了，找到 K' 使得 DEKHash(K') == DEKHash(K)。

题目中给出的是 Java 代码，我作为 Java 黑，显然是不能忍受的，所以弄成了 C++的版本：

1
2
3
4
5
6
7

long DEKHash(string str) {
    long hash = str.length();
    for(int i = 0; i < str.length(); i++) {
        hash = ((hash<<5)^(hash>>27))^str.at(i);
    }
    return hash;
}

下面来看我是怎么寻找这样的 K'。

整个例子从 Sat Jun 4 22:45:55 CST 2016 开始，于 Sun Jun 5 11:16:53 CST 2016 结束，共经历约 12 个小时。

在 TIMIT 的代码中，一共分为了以下几个示例：

1. 数据预处理；
2. MFCC 特征提取 & 训练集和测试集的 CMVN，这里只提取了 MFCC，Kaldi 里支持 MFCC，PLP，PITCH；
3. 单音树训练和解码，是语音识别最基础的部分
4. 三音素的训练和解码（Deltas + Delta-Deltas）
5. 三音素模型基础上做了LDA + MLLT变换的训练和解码
6. 三音素模型基础上做了LDA + MLLT +SAT变换的训练和解码
7. 三音素模型基础上做了SGMM2的训练和解码，SGMM2是povey 提出的
8. 三音素模型基础上做了 MMI + SGMM2 的训练和解码
9. DNN 混合训练和解码（povey 版本模型，看网上说不建议使用？）
10. 系统融合(DNN+SGMM)
11. Karel DNN 通用深度学习模型的训练和解码
12. 获取结果

Kaldi 上提供了很多例子让我们学习，这里有一个 Kaldi 上提供例子的列表：

http://kaldi-asr.org/doc/examples.html

但是大部分的数据库来源于LDC，并且需要成为会员才能下载。

我们这里使用一个叫做 TIMIT 的例子，当然他也是需要付费才能使用的数据集。

然而幸运的是我们可以在这个链接里找到所有的内容：

http://www.fon.hum.uva.nl/david/ma_ssp/2007/TIMIT/

因为版权问题我不准备提供直接下载的链接，但是我作为老司机可以指一条路：wget -r，剩下的就看你自己的造化了。

数据拿到后，目录下会多出很多 .html 的文件。我这里写了一个脚本用于删除这些多余的文件，并将小写目录转换成大写目录（在 Kaldi 的 TIMIT 脚本中写出的目录都是大写的）：

Kaldi 是一个用于语音识别的开发平台（工具包），目前已经较为成熟，而且文档很多。

本文提供一个 Kaldi 在 Mac OS X 10.11。5 下的安装教程，如果你用 Windows，请买一台 Mac。

下载源码

Kaldi 在 Github 上开源，我们应该直接下载他最新的源码执行编译。

1

git clone https://github.com/kaldi-asr/kaldi

编译

编译这种大型框架不应该去互联网上搜索任何安装教程，而是应该阅读官方的安装教程。（那我写这篇文章干嘛呢…(╯‵□′)╯︵┻━┻

目录

• 写在前面的话
• 科研创意的来源
• 准备篇
  • 主题的选取
  • 确定论文的类型
  • 提出论点
  • 会议投稿
  • 期刊投稿
• 写作篇
  • 写作动机
  • 写作阶段
• 工具篇
  • 写作工具
  • 版本控制和存储
  • 文献工具
  • 图表工具
• 后记
• 进一步阅读的文献

原文链接：https://swift.org/documentation/api-design-guidelines/

译者：Changkun Ou

2016-05-11 初稿

本文未经授权禁止转载

目录

• 目录
• 基本准则
• 命名
  • 明确用法
  • 为使用舒适而努力
  • 合理使用术语
• 约定
  • 一般约定
  • 形参
  • 实参标签
• 特殊说明

译者注：

Argument 和 Parameter 两个词在很多文献中均翻译为参数，这是一个历史遗留问题。

但实际上 Argument 专用于 Actual Argument（实际参数，实参），Parameter 专用于 Formal Parameter（形式参数，形参）。

本译文在上下文没有歧义的情况下均翻译为参数，在其他情况下使用实参和形参来对 Argument 和 Parameter 加以区分。

进一步阅读：ISO/IEC 9899 - 在这份标准中，第 3 页的 actual parameter 和第 6 页的 formal argument 两种说法均被弃用。