尽管我们对百度今年工作焦点的关注集中在这个中国搜索巨头在深度学习方面的举措上，许多其他的关键的，尽管不那么前沿的应用表现出了大数据带来的挑战。

正如百度的欧阳剑在本周 Hot Chips 大会上谈论的，百度坐拥超过 1 EB 的数据，每天处理大约 100 PB 的数据，每天更新 100 亿的网页，每 24 小时更新处理超过 1 PB 的日志更新，这些数字和 Google 不分上下，正如人们所想象的。百度采用了类似 Google 的方法去大规模地解决潜在的瓶颈。

正如刚刚我们谈到的，Google 寻找一切可能的方法去打败摩尔定律，百度也在进行相同的探索，而令人激动的、使人着迷的机器学习工作是迷人的，业务的核心关键任务的加速同样也是，因为必须如此。欧阳提到，公司基于自身的数据提供高端服务的需求和 CPU 可以承载的能力之间的差距将会逐渐增大。

对于百度的百亿亿级问题，在所有数据的接受端是一系列用于数据分析的框架和平台，从该公司的海量知识图谱，多媒体工具，自然语言处理框架，推荐引擎，和点击流分析都是这样。简而言之，大数据的首要问题就是这样的：一系列各种应用和与之匹配的具有压倒性规模的数据。

当谈到加速百度的大数据分析，所面临的几个挑战，欧阳谈到抽象化运算核心去寻找一个普适的方法是困难的。“大数据应用的多样性和变化的计算类型使得这成为一个挑战，把所有这些整合成为一个分布式系统是困难的，因为有多变的平台和编程模型（MapReduce，Spark，streaming，user defined，等等）。将来还会有更多的数据类型和存储格式。”

尽管存在这些障碍，欧阳讲到他们团队找到了（它们之间的）共同线索。如他所指出的那样，那些把他们的许多数据密集型的任务相连系在一起的就是传统的 SQL。“我们的数据分析任务大约有 40% 是用 SQL 写的，而其他的用 SQL 重写也是可用做到的。” 更进一步，他讲道他们可以享受到现有的 SQL 系统的好处，并可以和已有的框架相匹配，比如 Hive，Spark SQL，和 Impala 。下一步要做的事情就是 SQL 查询加速，百度发现 FPGA 是最好的硬件。

这些主板，被称为处理单元（ 下图中的 PE ），当执行 SQL 时会自动地处理关键的 SQL 功能。这里所说的都是来自演讲，我们不承担责任。确切的说，这里提到的 FPGA 有点神秘，或许是故意如此。如果百度在基准测试中得到了如下图中的提升，那这可是一个有竞争力的信息。后面我们还会继续介绍这里所描述的东西。简单来说，FPGA 运行在数据库中，当其收到 SQL 查询的时候，该团队设计的软件就会与之紧密结合起来。

欧阳提到了一件事，他们的加速器受限于 FPGA 的带宽，不然性能表现本可以更高，在下面的评价中，百度安装了 2 块12 核心，主频 2.0 GHz 的 intl E26230 CPU，运行在 128G 内存。SDA 具有 5 个处理单元，（上图中的 300MHz FPGA 主板）每个分别处理不同的核心功能（ 筛选 （ filter ） ， 排序 （ sort ） ， 聚合 （ aggregate ） ， 联合 （ join ） 和 分组 （ group by ） ）

为了实现 SQL 查询加速，百度针对 TPC-DS 的基准测试进行了研究，并且创建了称做处理单元（PE）的特殊引擎，用于在基准测试中加速 5 个关键功能，这包括 筛选 （ filter ） ， 排序 （ sort ） ， 聚合 （ aggregate ） ， 联合 （ join ） 和 分组 （ group by ） ，（我们并没有把这些单词都像 SQL 那样大写）。SDA 设备使用卸载模型，具有多个不同种类的处理单元的加速卡在 FPGA 中组成逻辑，SQL 功能的类型和每张卡的数量由特定的工作量决定。由于这些查询在百度的系统中执行，用来查询的数据被以列格式推送到加速卡中（这会使得查询非常快速），而且通过一个统一的 SDA API 和驱动程序，SQL 查询工作被分发到正确的处理单元而且 SQL 操作实现了加速。

SDA 架构采用一种数据流模型，加速单元不支持的操作被退回到数据库系统然后在那里本地运行，比其他任何因素，百度开发的 SQL 加速卡的性能被 FPGA 卡的内存带宽所限制。加速卡跨整个集群机器工作，顺便提一下，但是数据和 SQL 操作如何分发到多个机器的准确原理没有被百度披露。

我们受限与百度所愿意披露的细节，但是这些基准测试结果是十分令人鼓舞的，尤其是 Terasort 方面，我们将在 Hot Chips 大会之后跟随百度的脚步去看看我们是否能得到关于这是如何连接到一起的和如何解决内存带宽瓶颈的细节。

via: http://www.nextplatform.com/2016/08/24/baidu-takes-fpga-approach-accelerating-big-sql/

作者：Nicole Hemsoth 译者：LinuxBars 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

Hive 可以让你在 Hadoop 上使用 SQL，但是在分布式系统上优化 SQL 则有所不同。这里是让你可以轻松驾驭 Hive 的12个技巧。

Hive 并不是关系型数据库（RDBMS），但是它大多数时候都表现得像是一个关系型数据库一样，它有表、可以运行 SQL、也支持 JDBC 和 ODBC。

这种表现既有好的一面，也有不好的一面：Hive 并不像关系型数据库那样执行 SQL 查询。我在 Hive 上花费了大量时间，光是我自己在工作中就为了优化它花费了超过80个小时。不说你也知道，我就像呆在蜂巢（Hive）旁边一样脑袋嗡嗡作响。所以，为了让你免受这种痛苦，我决定将它们写出来，以便让你在你的下一个 Hive 项目中逃离这种折磨。

1、不要使用 MapReduce

不管你是不是觉得 Tez、Spark 或 Impala 能行，但是不要指望 MapReduce。它本身就很慢，比 Hive 还慢。如果你用的是 Hortonwork 的版本，你可以在脚本前面写上 set hive.execution.engine=tez ；用 Cloudera 的话，使用 Impala。如果 Impala 不适用的话，我希望到时候可以使用 hive.execution.engine=spark 。

2、不要在 SQL 中做字符串匹配

绝不要，特别是在 Hive 中！如果你坚持要在 WHERE 语句中使用 LIKE 匹配，就会产生一个跨产品的警告。本来你的查询可能只用几秒钟，但是使用字符串匹配的话就会变成几分钟。最好的办法是使用那些可以在 Hadoop 中进行搜索的工具，可以试试 Elasticsearch 的 Hive 集成版本 或 Lucidwork 的 Solr，以及 Cloudera Search。关系型数据库这方面表现并不好，但是 Hive 则更糟糕。

3、不要用表连接子查询

你最好创建一个临时表，然后对这个临时表进行连接，而不是让 Hive 自己智能处理子查询。即不要这样做：

select a.* from something a inner join 
  (select ... from somethingelse union b select ... from anotherthing c) d 
  on a.key1 = d.key1 and a.key2 = b.key2 where a.condition=1

而是应该这样：

create var_temp as select ... from somethingelse b 
  union select ... from anotherthing c 
and then 
select a.* from something a inner join from var_temp b 
  where a.key1=b.key1 and a.key2=b.key2 where a.condition=1

一般来说，这会比 Hive 自己处理子查询要快许多。

4、使用 Parquet 或 ORC，但是不要转换使用

也就是说，使用 Parquet 或 ORC 而不要用 TEXTFILE。然而，如果你要把文本数据中导入到更具结构性的数据中，应该做一些转换再导入到目标表中。你不应该用 LOAD DATA 将文本文件加载到 ORC 中，而是应该将其加载到一个文本中。

如果你要创建另外一个表，并最终大多数分析都是对它进行的，那么你就该对该表进行 ORC 化，因为转换到 ORC 或 Parquet 要花费很多时间，并不值得将其放到你的 ETL 处理中。如果你有一个简单的普通文本要导入，也没做过任何优化，你应该将其加载到一个临时表并通过 select create 放到 ORC 或 Parquet 中。不过，这有点慢。

5、开关矢量化试试

在你的脚本前面加上 set hive.vectorized.execution.enabled = true 和set hive.vectorized.execution.reduce.enabled = true ，然后试着打开或关闭它们看看。因为最近版本的 Hive 的矢量化有点问题。

6、不要在表连接中使用 structs

我必须承认我大脑里面的 SQL 格式还是 SQL-92 时代的，所以我无论如何都不会想到去用 structs。但是如果你做一些超级复杂的操作，比如在联合主键上使用 ON 语句，那么 structs 就很方便。不幸的是，Hive 对它们很不适应，特别是在 ON 语句上。当然，大多数情况下，在较小的数据集和 yields 下是没错误的。在 Tez 里面，你会得到一个有趣的矢量错误。这个限制并未见于我所知的任何文档，也许这是一个探索你的执行引擎内部的好办法。

7、检查你的容器大小

你也许需要为 Impala 或 Tez 增加你的容器大小。如果有你的节点大小比较大，“推荐的”容器大小可能就不适用于你的系统。你也许需要确保你的 YARN 队列和常规的 YARN 内存大小合适。你也许应该注意默认的队列并不适合所有的常规使用。

8、启用统计

Hive 在表连接时会做一些蠢事，除非启用了统计。你也可以在 Impala 中使用查询提示。

9、考虑 MapJoin 优化

如果你分析你的查询，你可能发现最新的 Hive 已经可以足够智能地进行自动优化了。但是你也许需要再调整一下。

10、如果可以，将大表放到最后

如标题。

11、分区总会帮到你，不管多少

如果你有一个出现在许多地方的东西，比如语句中的日期（但不是日期范围）或重复的地点，你也许应该做分区。分区的基本意思是“拆分到它自己的目录里面”，而不是到一个大的文件中去查找。当你在你的 join/where 语句中仅检索 location=’NC’这样一个小数据集时，Hive 就可以在一个文件中查找。此外，和列值不同，你可以在你的 LOAD DATA 语句中加上分区。另外，要记住，HDFS 并不喜欢小文件。

12、使用哈希进行列比较

如果你要在每个查询中比较同样的10个字段，可以考虑使用 hash() 来比较它们的校验值。在一个输出表中展示它们也许很有用。注意，在 Hive 0.12 中，哈希功能比较差，0.13中的哈希更好一些。

以上就是我的12点经验，我希望这些能够帮到你，让你从 Hive 的嗡嗡声中逃离出来。

Linux 有一个显著的特点，在正常情况下，你可以通过日志分析系统日志来了解你的系统中发生了什么，或正在发生什么。的确，系统日志是系统管理员在解决系统和应用问题时最需要的第一手资源。我们将在这篇文章中着重讲解 Apache HTTP web server 生成的 Apache access 日志。

这次，我们会通过另类的途径来分析 Apache access 日志，我们使用的工具是 asql。asql 是一个开源的工具，它能够允许使用者使用 SQL 语句来查询日志，从而通过更加友好的格式展现相同的信息。

Apache 日志背景知识

Apache 有两种日志：

• Access log：存放在路径 /var/log/apache2/access.log (Debian) 或者 /var/log/httpd/access\_log (Red Hat)。Access Log 记录所有 Apache web server 执行的请求。
• Error log：存放在路径 /var/log/apache2/error.log (Debian) 或者 /var/log/httpd/error\_log (Red Hat)。Error log 记录所有 Apache web server 报告的错误以及错误的情况。Error 情况包括（不限于）403（Forbidden，通常在请求被拒绝访问时被报告），404（Not found，在请求资源不存在时被报告）。

虽然管理员可以通过配置 Apache 的配置文件来自定义 Apache access log 的详细程度，不过在这篇文章中，我们会使用默认的配置，如下：

远程 IP - 请求时间 - 请求类型 - 响应代码 - 请求的 URL - 远程的浏览器信息 (也许包含操作系统信息)

因此一个典型的 Apache 日志条目就是下面这个样子：

192.168.0.101 - - [22/Aug/2014:12:03:36 -0300] "GET /icons/unknown.gif HTTP/1.1" 200 519 "http://192.168.0.10/test/projects/read_json/" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:30.0) Gecko/20100101 Firefox/30.0"

但是 Apache error log 又是怎么样的呢？因为 error log 条目主要记录 access log 中特殊的请求（你可以自定义），所以你可以通过 access log 来获得关于错误情况的更多信息（example 5 有更多细节）。

此外要提前说明的， access log 是系统级别的日志文件。要分析虚拟主机的日志文件，你需要检查它们相应的配置文件（例如： 在 /etc/apache2/sites-available/[virtual host name] 里（Debian））。

在 Linux 上安装 asql

asql 由 Perl 编写，而且需求以下两个 Perl 模块：SQLite 的 DBI 驱动以及 GNU readline。

在 Debian, Ubuntu 以及其衍生发行版上安装 asql

使用基于 Debian 发行版上的 aptitude，asql 以及其依赖会被自动安装。

# aptitude install asql

在 Fedora，CentOS，RHEL 上安装 asql

在 CentOS 或 RHEL 上，你需要启用 EPEL repository，然后运行以下代码。在 Fedora 中，直接运行以下代码：

# sudo yum install perl-DBD-SQLite perl-Term-Readline-Gnu
# wget http://www.steve.org.uk/Software/asql/asql-1.7.tar.gz
# tar xvfvz asql-1.7.tar.gz
# cd asql
# make install

asql 是如何工作的？

从上面代码中的依赖中你就可以看出来，asql 转换未结构化的明文 Apache 日志为结构化的 SQLite 数据库信息。生成的 SQLite 数据库可以接受正常的 SQL 查询语句。数据库可以通过当前以及之前的日志文件生成，其中也包括压缩转换过的日志文件，类似 access.log.X.gz 或者 access\_log.old。

首先，从命令行启动 asql：

# asql

你会进入 asql 内置的 shell 交互界面。

输入 help 列表可执行的命令：

首先在 asql 中加载所有的 access 日志：

asql > load <apache-access-logs 的路径>

比如在 Debian 下：

asql > load /var/log/apache2/access.*

在 CentOS/RHEL 下：

asql > load /var/log/httpd/access_log*

当 asql 完成对 access 日志的加载后，我们就可以开始数据库查询了。注意一下，加载后生成的数据库是 "temporary" （临时）的，意思就是数据库会在你退出 asql 的时候被清除。如果你想要保留数据库，你必须先将其保存为一个文件。我们会在后面介绍如何这么做（参考 example 3 和 4）。

生成的数据库有一个名为 logs 的表。输入下面的命令列出 logs 表中提供的域：

一个名为 .asql 的隐藏文件，保存于用户的 home 目录下，记录用户在 asql shell 中输入的命令历史。因此你可以使用方向键浏览命令历史，按下 ENTER 来重复执行之前的命令。

asql 上的示例 SQL 查询

下面是几个使用 asql 针对 Apache 日志文件运行 SQL 查询的示例：

Example 1：列出在 2014 年 10 月中请求的来源 / 时间以及 HTTP 状态码。

SELECT source, date, status FROM logs WHERE date >= '2014-10-01T00:00:00' ORDER BY source;

Example 2：从小到大显示单个客户端处理的请求大小（bytes）。

SELECT source, SUM(size), AS NUMBER FROM logs GROUP BY source ORDER BY Number DESC;

Example 3：在当前目录中保存数据库为 [filename]。

save [filename]

这样做可以避免使用 load 命令对日志的语法分析所占用的处理时间。

Example 4：在重新进入 asql 后载入数据库。

restore [filename]

Example 5：返回 access 日志中记录的 error 情况。在这个例子中，我们将显示所有返回 HTTP 状态码为 403（access forbidden）的请求。

SELECT source, date, status, request FROM logs WHERE status='403' ORDER BY date

这个例子想要表现的是：虽然 asql 只分析 access 日志，我们还是可以通过使用请求的状态域来显示有 error 情况的请求。

小结：

我们体验了 asql 如何帮助我们分析 Apache 日志文件，并将结果通过友好的格式输出。虽然你也可以通过使用命令行的工具（例如 cat 与 grep，uniq，sort，wc 等等之间的管道）来实现类似功能，与此比较起来 asql 展示了它如同瑞士军刀一般的强大功能，使我们在自己的需求下能够通过标准 SQL 查询语句来过滤日志。

希望这篇教程能帮助到你们。

请不要拘束地将评论文章，分享文章，提出疑问。

via: http://xmodulo.com/sql-queries-apache-log-files-linux.html

作者：Gabriel Cánepa 译者：ThomazL 校对：wxy

本文由 LCTT 原创翻译，Linux中国 荣誉推出