原文： medium.com/intrinsic/w…

早在 2012 年，PHP 和 Ruby on Rails 仍是统治渲染 web 应用的服务器端技术。但是，一个大胆的竞争者在社区中搅起风暴。这项在当年的一篇博文中宣称通过了百万级并发连接测试的技术并非其他，正是 Node.js，其流行程度从那时至今也在稳定增长。

不像当时的大多数同类技术，Node.js 自带一个 web server。拥有这个 server 意味着开发者可以绕过诸如 php.ini的种种配置文件以及一个包含了若干 .htaccess文件的层级结构。内置的 web server 同样提供了其他便利，如处理上传文件的能力或易于实现 WebSockets 等。

由 Node.js 驱动的 web 应用每天都顺畅地处理数以亿计的请求。世界上大多数大公司都在某些方面被 Node.js 影响。说 Node.js 可用于生产环境肯定是个保守的说法。但是，对于构建 Node.js 仍有一个适用的建议：

不应直接把一个 Node.js 进程暴露到 web 上，而应该将其隐藏在一个反向代理背后。

在我们揭示原因之前，先看看那是什么吧。

反向代理是什么？

一个反向代理（reverse proxy）基本上就是一种用于接受请求并将它们转发到某处的另一个 HTTP server 上的特殊 web server，也会接受响应并转发回给原始的请求者。

反向代理通常不会精确地发送原始请求，典型的做法是会在某些方面对请求作出修改。例如，如果反向代理位于 www.example.org:80并转发请求到 ex.example.org:8080的话，大概就是它重写了原始的 Host header 以匹配目标地址。反向代理也可能通过其他方式修改请求，比如清理一个有缺陷的请求或是在协议之间作出转换。

一旦反向代理收到一个响应，可能也会对其进行某方面的转换。常用的途径同样是修改 Host header 以匹配原始请求。

请求的 body 也能被修改。一种通常的修改是在响应时执行 gzip 压缩。另一种常见改变是当基础服务只是 HTTP 时启用 HTTPS 支持。

反向代理也可以将到来的请求分发给多个后端实例。如果一个服务暴露于 api.example.org，那么一个反向代理可以转发请求到 api1.internal.example.org、 api2.internal.example.org等处。

有很多种不同的反向代理。两种更流行的分别是 Nginx和 HAProxy。这两种工具都能够执行 gzip 压缩和增加 HTTPS 支持，它们也能很好地适用于其它领域。Nginx 更流行一些，并且也有诸如从文件系统运行静态文件服务器等一些其它有益的能力，所以我们将在本文中使用它作为例子。

现在我们知道 何为反向代理了，下面来看看 为何我们要将其用于 Node.js。

为何应该使用一个反向代理？

SSL 终端

SSL 终端是使用反向代理的最主要原因之一。将一个应用的协议从 http变为 https可不止添加一个 s字母那么简单。Node.js 本身 能够对 https执行必要的加密和解密，也能被配置为读取必要的证书文件。

但是，配置一个用于和我们的应用通信的协议，并管理一个永不过期的 SSL 凭证，并非真的是我们的应用需要关注的事情。检查一个代码库中的证书不只是麻烦，同时也是一种安全风险。在应用启动时从特定位置获取证书也有其风险。

有鉴于此，最好在应用之外执行 SSL 终端，通常就由一个反向代理来承担。受惠于像 certbot这样的技术，通过 Nginx 维护证书也像设置一个定时任务一样简单。这样的一个任务可以自动安装新证书并动态重配置 Nginx 进程。与重启每个 Node.js 应用实例相比，这是一个破坏性小得多的过程。

同时，通过允许一个反向代理来执行 SSL 终端，这也意味着 只有被反向代理的作者编写的代码可以访问你的私有 SSL 证书。反之，如果由你的 Node.js 应用处理 SSL，那么你的应用用到的每一个单独的第三方模块 -- 即便是潜在的恶意模块，都能访问你的私有 SSL 证书了。

gzip 压缩

gzip 是另一个你应该由应用让渡到反向代理的特性。gzip 压缩策略最好在管理级别设置，而不是不得不为每个应用指定和配置。

最好使用某些逻辑来决定对什么采用 gzip。例如，很小的文件，或许比 1kb 还小的，或许就不值得压缩，因为其 gzip 压缩版本没准会变得更大，亦或客户端对其解压的 CPU 开销也更不划算。同时，当处理二进制数据时，取决于其格式可能也无法从压缩中获益。有时 gzip 也无法被简单地启用或禁用，为了兼容压缩算法需要检查接收到的 Accept-Encoding header。

集群化

JavaScript 是一种单线程语言，相应的，Node.js 天然也是一种单线程的服务器平台（尽管 Node.js v10 中开始出现的实验性 worker 线程支持致力于改变这一点）。这意味着要从一个 Node.js 应用中获取尽可能更大的吞吐量需要运行和 CPU 核数差不多相同的实例数量。

Node.js 自带的 cluster模块可以实现集群化。收到的 HTTP 请求将会被交给一个 master 进程而后再被分发给 cluster workers。

但是，动态伸缩 cluster workers 会有点费劲。通常也会通过运行一个额外的 Node.js 进程作为分发主进程来增加吞吐量。但是，跨机器伸缩进程对于 cluster来说还是有点强人所难了。

基于这些原因，有时使用一个反向代理来分发正在运行的 Node.js 进程会更好。反向代理能被动态配置以指向新出现的应用进程。说实在的，一个应用就应该只关注其自身的工作，而不是管理多个拷贝并分发请求。

企业路由

当着手于大型 web 应用，特别是被有多个团队的企业创建的应用时，使用一个反向代理来决定如何转发请求是非常有用的。例如，指向 example.org/search/*的请求可被路由到内部搜索应用，而其它指向 example.org/profile/*的请求可以被分发到内部资料应用上。

这样的加工处理提供了其它强大的特性，如粘滞会话、蓝/绿部署、A/B测试等等。我个人就曾在这样一个由应用执行这些逻辑的代码库中工作，这种实现方式让应用极难维护。

性能收益

Node.js 是高可塑性的。它可以从文件系统架设静态资源服务、对 HTTP 响应执行 gzip 压缩、内建支持 HTTPS，另有很多其它特性。它甚至有能力通过 cluster模块，运行一个应用的多个实例并分发其自身的请求。

然而，基本上让一个反向代理来处理这些操作，而不是靠 Node.js 应用去做，才是符合我们利益的。除了以上列出的原因之外，另一个想要在 Node.js 之外做这些操作的原因是由于效率。

SSL 加密和 gzip 压缩是两个高计算密集型的操作。专用型反向代理工具，如 Nginx 和 HAProxy，对这些操作术业有专攻，执行速度要快于 Node.js。用 Nginx 这样的 web server 从磁盘上读取静态内容也比 Node.js 来得快。有时甚至比起用额外的 Node.js 进程来执行集群化，用 Nginx 反向代理实现的效率都更高，内存和 CPU 的占用都更少。

但是，耳听为虚。让我们运行一些基准测试！

以下负载测试是使用 siege（译注：一个 http/https 回归测试和基准测试工具）执行的。我们用并发值 10 运行命令（模拟用户的请求），并且该命令会迭代运行 2 万次（总体会有 20 万次请求）。

为检验内存使用量我们在基准测试期间运行命令 pmap | grep total若干次并取 平均值作为结果（译注：Linux 中的 pmap 命令用于查看进程用了多少内存）。当使用单个 worker 线程运行 Nginx 时，最终会运行两个实例，一个是主线程，另一个是 worker 线程；然后将两个值相加。当运行一个包含 2 个节点的 Node.js 集群时，将有 3 个进程，一个是主进程，另两个是 worker 进程。下表中的 approx memory列是给定测试中每个 Nginx 和 Node.js 进程的总和。

在 node-cluster基准测试中我们使用了 2 个 worker，这意味着共有 3 个 Node.js 进程在运行：1 个 master 和 2 个 worker。在 nginx-cluster-node基准测试中我们有 2 个 Node.js 进程在运行。每个 Nginx 测试都有一个单独的 Nginx 主进程和一个单独的 Nginx worker 进程。基准测试包括从磁盘读取一个文件，且无论是 Nginx 还是 Node.js 都被配置为将文件缓存在内存中。

使用 Nginx 为 Node.js 执行 SSL 终端带来了约 16% (746rps 到 865rps) 的吞吐量增长。使用 Nginx 执行 gzip 压缩则让吞吐量增加了约 50% (5,047rps 到 7,590rps)。使用 Nginx 管理一个进程集群造成了约 1% (8,006rps 到 7,908rps) 的性能损失，大概是归因于在回环网络设备间传递额外请求的开销吧。

一个基本的 Node.js 单进程单内存使用量是约 600MB，而 Nginx 进程的约 50MB。这些使用量会根据使用了那些特性而小幅波动，例如，Node.js 使用了额外的约 13MB来执行 SSL 终端，以及 Nginx 使用了额外的 4MB（译注：652 - 601 - 46.1）来作为 Node.js 的反向代理并架设从文件系统读取静态内容的服务。可以注意到一个有趣的事情是 Nginx 在其生命周期中保持了稳定的内存吞吐量；然而 Node.js 的内存吞吐量由于 JavaScript 天然的垃圾回收机制而时常起伏。

以下是执行此次基准测试的软件版本：

• Nginx: 1.14.2
• Node.js: 10.15.3
• Siege: 3.0.8

测试执行在一台有 16GB内存的机器上，有一块 i7-7500U CPU 4x2.70GHz，Linux 内核为 4.19.10。项目地址位于： github.com/IntrinsicLa…。

简化应用代码

基准测试全面又出彩，但从我的观点来说，将部分工作从 Node.js 应用让渡给反向代理带来的最大收益是代码的简化。我们得以减少了大量可能造成潜在 bug 的必须应用代码并将其换成了声明式的配置。开发者中的一个普遍观点是他们对于让 Nginx 等外部团队编写这部分代码，而不是由他们自己编写更有信心。

不同于要安装和管理 gzip 压缩中间件并在多个 Node.js 项目中保持其最新，我们可以在一处统一配置它。和加载 SSL 证书后再重启应用进程不同，我们可以使用已有的证书管理工具。与其在应用中添加条件语句检查进程是 master 还是 worker，不如将其交给其它工具判断。

反向代理允许我们的应用聚焦于业务逻辑并忽略协议和进程管理。

尽管 Node.js 拥有运行在生产环境的完美能力，但将反向代理和生产环境的 HTTP Node.js 应用结合使用带来了种种收益。像 SSL 和 gzip 这样的操作变得更快。管理 SSL 证书也会更简单。大量所需应用代码也被减少了。

--End--

查看更多前端好文
请搜索 fewelife 关注公众号

转载请注明出处

题外话：前后端的工作职责越来越明确，现在的前端都称之为大前端，技术栈以及生态圈都已经非常成熟；以前后端人员瞧不起前端人员，那现在后端人员要重新认识一下前端，前端已经很成体系了。

接口交互

返回格式

{  

#返回状态码  

code:integer,   

#返回信息描述  

message:string,  

#返回值  

data:object  

}   

CODE状态码

• 200 – 请求成功
• 301 – 资源（网页等）被永久转移到其它URL
• 404 – 请求的资源（网页等）不存在
• 500 – 内部服务器错误

• 1000～1999 区间表示参数错误
• 2000～2999 区间表示用户错误
• 3000～3999 区间表示接口异常

Message

Data

控制层Controller

美观优化

优雅优化

1. 每个方法的返回都是Result封装对象，没有业务含义。
2. 在业务代码中，成功的时候我们调用Result.success，异常错误调用Result.failure。是不是很多余。
3. 上面的代码，判断id是否为null，其实我们可以使用hibernate validate做校验，没有必要在方法体中做判断。

实现方案

1. 定义一个注解@ResponseResult，表示这个接口返回的值需要包装一下
2. 拦截请求，判断此请求是否需要被@ResponseResult注解
3. 核心步骤就是实现接口ResponseBodyAdvice和@ControllerAdvice，判断是否需要包装返回值，如果需要，就把Controller接口的返回值进行重写。

注解类

拦截器

重写返回体

重写Controller

总结

本文使用「署名 4.0 国际 (CC BY 4.0)」许可协议，欢迎转载、或重新修改使用，但需要注明来源。 署名 4.0 国际 (CC BY 4.0)

本文作者: 苏洋

创建时间: 2020年02月02日 统计字数: 12171字 阅读时间: 25分钟阅读 本文链接: soulteary.com/2020/02/02/…

使用 Docker 和 Traefik v2 搭建 Phabricator

这篇文章躺在草稿箱里有一个多月了，恰逢最近一段时间远程协作需求，以及 Traefik v2 的升级，于是便有了这篇文章。

如果你的团队也需要一个内部看板，Phabricator 是个不错的选择：能提供简单的任务管理、能提供工作看板、支持代码讨论、甚至能够让设计师也使用起来，当然还有它主打的代码审计 / Review和管理功能。

写在前面

最早接触它是在 2012 年，八年之后，这款工具的开源版本变的更加好用了。

• 开源仓库： secure.phabricator.com/source/phab…
• 镜像仓库： github.com/phacility/p…
• SaaS 版本： www.phacility.com/phabricator…

从开源仓库可以看到，社区版的代码一直在持续更新，而且现在还提供了 SaaS 版本，考虑到私密性和账户集成等定制要求，这里决定自建服务，并自行封装容器镜像。

考虑到不是所有人都有定制需求，这里分别提供两个方案，Bitnami 的容器方案，和完全基于官方代码进行定制的容器方案。

目前社区最新版是 《stable - Promote 2020 Week 5》 ，Bitnami 会定时从官方仓库中获取版本，并进行容器封装，仓库地址： github.com/bitnami/bit…，相比官方更新会稍有延时，但是基本不影响使用。

准备数据库

生产环境推荐使用云服务商提供的数据库，但是如果小规模使用，使用容器启动一个数据库示例也未尝不可。

version: '3.7'

services:

  mariadb:
    image: mariadb
    environment:
      - MYSQL_ROOT_PASSWORD=phabricator
      - MYSQL_DATABASE=phabricator
    command: --max_allowed_packet=33554432 --sql_mode="STRICT_ALL_TABLES" --local-infile=0
    ports:
      - 13306:3306
    networks:
      - traefik
    healthcheck:
      test: "mysqladmin --password=phabricator ping -h 127.0.0.1"
      timeout: 5s
      retries: 20
    volumes:
      - './mariadb_data:/var/lib/mysql'

networks:
  traefik:
    external: true
复制代码

将上面的内容保存为 docker-compose.yml并执行 docker-compose up -d即可。

准备好数据库后，我们聊聊怎么简单启动一个 phabricator 服务。

Bitnami 容器方案

这里提供两个版本的配置文件，更多搭配 Traefik 使用的前置知识可以在 过往的文章中找到。

搭配 Traefik v1 使用

如果你还在使用 Traefik v1 ，那么使用下面的配置，可以一键启动封装好的稳定版本。

version: '2'
services:

  phabricator:
    image: 'bitnami/phabricator:2019'
    expose:
      - 80
      - 443
    volumes:
      - './phabricator_data:/bitnami'
      - './extensions:/opt/bitnami/phabricator/src/extensions'
    environment:
      - PHABRICATOR_HOST=phabricator.soulteary.com
      - PHABRICATOR_USERNAME=soulteary
      - PHABRICATOR_PASSWORD=soulteary
    networks:
      - traefik
    labels:
      - "traefik.enable=true"
      - "traefik.port=80"
      - "traefik.frontend.rule=Host:phabricator.soulteary.com"
      - "traefik.frontend.entryPoints=https,http"

networks:
  traefik:
    external: true
复制代码

搭配 Traefik v2 使用

当然，这里更推荐搭配 Traefik v2 一起使用。

version: '3.7'

services:

  phabricator:
    image: 'bitnami/phabricator:2019'
    expose:
      - 80
    networks:
      - traefik
    labels:
      - "traefik.enable=true"
      - "traefik.docker.network=traefik"
      - "traefik.http.routers.phab0.middlewares=https-redirect@file"
      - "traefik.http.routers.phab0.entrypoints=http"
      - "traefik.http.routers.phab0.rule=Host(`phabricator.lab.io`,`phabricator-file.lab.io`)"
      - "traefik.http.routers.phab1.middlewares=content-compress@file"
      - "traefik.http.routers.phab1.entrypoints=https"
      - "traefik.http.routers.phab1.tls=true"
      - "traefik.http.routers.phab1.rule=Host(`phabricator.lab.io`,`phabricator-file.lab.io`)"
      - "traefik.http.services.phabbackend.loadbalancer.server.scheme=http"
      - "traefik.http.services.phabbackend.loadbalancer.server.port=80"
    volumes:
      - './phabricator_data:/bitnami'
      - './extensions:/opt/bitnami/phabricator/src/extensions'

networks:
  traefik:
    external: true
复制代码

对程序进行汉化

感谢社区网友提供了程序的 汉化补丁，下载仓库中的 ** PhabricatorSimplifiedChineseTranslation.php** 并放置于上面配置文件指定的 extensions目录中后，启动应用，等待应用启动就绪后，在个人设置中切换中文即可。

接下来开始正餐，如何基于源代码对 phabricator 进行容器封装。

封装 Phabricator 容器镜像

官方安装文档写的比较详细，甚至封装了一个基础的安装脚本，我们基于此进行容器的 Dockerfile 的编写。

FROM ubuntu:18.04

LABEL maintainer="soulteary@gmail.com"

ENV DEBIAN_FRONTEND noninteractive

RUN apt-get update && apt-get upgrade -y && \
    echo 'debconf debconf/frontend select Noninteractive' | debconf-set-selections && export DEBIAN_FRONTEND=noninteractive && \
    apt-get install -y lsb-release curl && \
    # deps from: https://raw.githubusercontent.com/phacility/phabricator/stable/scripts/install/install_ubuntu.sh
    apt-get install -y tzdata sudo && \
    ln -fs /usr/share/zoneinfo/Asia/Shanghai /etc/localtime && \
    apt-get install -y git apache2 libapache2-mod-php php php-mysql php-gd php-curl php-apcu php-cli php-json php-mbstring php-zip python python-pip && \
    a2enmod rewrite && \
    pip install Pygments

WORKDIR /opt

RUN git clone https://github.com/phacility/phabricator.git --branch=stable --depth=1 && \
    cd phabricator && \
    git checkout cc11dff7d317b5a1e82e24ab571fef9abb633a49

RUN git clone https://github.com/phacility/arcanist.git --branch=stable --depth=1 && \
    cd arcanist && \
    git checkout 729100955129851a52588cdfd9b425197cf05815

RUN git clone https://github.com/phacility/libphutil.git --branch=stable --depth=1 && \
    cd libphutil && \
    git checkout 034cf7cc39940b935e83923dbb1bacbcfe645a85

RUN git clone https://github.com/arielyang/phabricator_zh_Hans.git --branch=master --depth=1 && \
    cd phabricator_zh_Hans && \
    git checkout ba5e602d934a6efacdc09082cd3a762449de45cf && \
    cp dist/\(stable\)\ Promote\ 2019\ Week\ 50/PhabricatorSimplifiedChineseTranslation.php ../phabricator/src/extensions/

COPY phabricator/docker-assets ./assets

RUN sed -i -e "s/post_max_size = 8M/post_max_size = 32M/g" /etc/php/7.2/apache2/php.ini && \
    sed -i -e "s/;opcache.validate_timestamps=1/opcache.validate_timestamps = 0/g" /etc/php/7.2/apache2/php.ini

RUN useradd daemon-user && \
    mkdir -p /data/repo && \
    chown -R daemon-user:daemon-user /data/repo && \
    ln -s /usr/lib/git-core/git-http-backend /usr/bin/ && \
    echo "Cmnd_Alias GIT_CMDS = /usr/bin/git*" >> /etc/sudoers.d/www-user-git && \
    echo "www-data ALL=(daemon-user) SETENV: NOPASSWD: GIT_CMDS" >> /etc/sudoers.d/www-user-git && \
    chmod 0440 /etc/sudoers.d/www-user-git

ENTRYPOINT ["bash", "-c", "/opt/assets/entrypoint.sh"]

EXPOSE 80
复制代码

Dockerfile 主要分为三个部分，第一部分进行基础系统环境配置、系统环境依赖；第二部分获取当前这个版本的程序代码和应用依赖；第三部分配置应用权限、设置容器启动脚本。

这里所需的程序启动脚本 entrypoint.sh内容如下：

#!/usr/bin/env bash

./phabricator/bin/storage upgrade --force && \
./phabricator/bin/phd start

apachectl -D FOREGROUND
复制代码

执行的工作也很简单：初始化Phabricator 配置，并启动 Web Server。

相关代码我已经上传至 GitHub，并推送至 DockerHub有需求的同学可以自取。

编写服务配置

服务配置分为两部分，第一部分是 Web Server 使用的。

  ServerName phabricator.lab.io
  DocumentRoot /opt/phabricator/webroot
  RewriteEngine on
  RewriteRule ^(.*)$/index.php?__path__=$1 [B,L,QSA]

  SetEnv HTTPS true

  "/opt/phabricator/webroot">
    Require all granted




  ServerName phabricator-file.lab.io
  DocumentRoot /opt/phabricator/webroot
  RewriteEngine on
  RewriteRule ^(.*)$/index.php?__path__=$1 [B,L,QSA]

  "/opt/phabricator/webroot">
    Require all granted


复制代码

将上面内容中的域名替换为自己实际使用的地址后，保存为 ** phabricator.conf**，接着准备应用配置：

{"phabricator.base-uri": "https://phabricator.lab.io/","security.alternate-file-domain":"https://phabricator-file.lab.io/","pygments.enabled": true,"phabricator.timezone":"Asia/Shanghai","storage.local-disk.path":"/data/stor","repository.default-local-path": "/data/repo","phd.user": "daemon-user","mysql.pass": "phabricator","mysql.user": "root","mysql.port": "3306","mysql.host": "mariadb"
}
复制代码

同样，替换域名为你自己的，并且将配置中的数据库相关内容替换为实际的数值，将文件保存为 local.json。（如果数据库使用的是本文的内容，可以不需要修改）

编写容器启动配置

将上面保存的配置文件放置到指定目录后，编写应用启动使用的 docker-compose.yml：

version: '3.7'

services:

  phabricator:
    image: soulteary/phabricator:stable-2020-week-5
    expose:
      - 80
    networks:
      - traefik
    labels:
      - "traefik.enable=true"
      - "traefik.docker.network=traefik"
      - "traefik.http.routers.phab0.middlewares=https-redirect@file"
      - "traefik.http.routers.phab0.entrypoints=http"
      - "traefik.http.routers.phab0.rule=Host(`phabricator.lab.io`,`phabricator-file.lab.io`)"
      - "traefik.http.routers.phab1.middlewares=content-compress@file"
      - "traefik.http.routers.phab1.entrypoints=https"
      - "traefik.http.routers.phab1.tls=true"
      - "traefik.http.routers.phab1.rule=Host(`phabricator.lab.io`,`phabricator-file.lab.io`)"
      - "traefik.http.services.phabbackend.loadbalancer.server.scheme=http"
      - "traefik.http.services.phabbackend.loadbalancer.server.port=80"
    volumes:
      - ./phabricator_data/stor:/data/stor
      - ./phabricator_data/repo:/data/repo
      - ./phabricator/docker-assets/phabricator.conf:/etc/apache2/sites-available/000-default.conf:ro
      - ./phabricator/docker-assets/local.json:/opt/phabricator/conf/local/local.json:ro

networks:
  traefik:
    external: true
复制代码

使用 docker-compose up -d将应用启动，并执行 docker-compose logs -f查看应用启动状况。

Creating phabricator-dockerize_phabricator_1 ... done
Attaching to phabricator-dockerize_phabricator_1
phabricator_1  | Loading quickstart template onto "mariadb:3306"...
phabricator_1  | Applying patch "phabricator:db.paste" to host "mariadb:3306"...
phabricator_1  | Applying patch "phabricator:20190523.myisam.01.documentfield.sql" to host "mariadb:3306"...
phabricator_1  | Applying patch "phabricator:20190718.paste.01.edge.sql" to host "mariadb:3306"...
phabricator_1  | Applying patch "phabricator:20190718.paste.02.edgedata.sql" to host "mariadb:3306"...
phabricator_1  | Applying patch "phabricator:20190718.paste.03.paste.sql" to host "mariadb:3306"...
phabricator_1  | Applying patch "phabricator:20190718.paste.04.xaction.sql" to host "mariadb:3306"...
phabricator_1  | Applying patch "phabricator:20190718.paste.05.comment.sql" to host "mariadb:3306"...
phabricator_1  | Applying patch "phabricator:20190802.email.01.storage.sql" to host "mariadb:3306"...
phabricator_1  | Applying patch "phabricator:20190802.email.02.xaction.sql" to host "mariadb:3306"...
phabricator_1  | Applying patch "phabricator:20190815.account.01.carts.php" to host "mariadb:3306"...
phabricator_1  | Applying patch "phabricator:20190815.account.02.subscriptions.php" to host "mariadb:3306"...
phabricator_1  | Applying patch "phabricator:20190816.payment.01.xaction.sql" to host "mariadb:3306"...
phabricator_1  | Applying patch "phabricator:20190816.subscription.01.xaction.sql" to host "mariadb:3306"...
phabricator_1  | Applying patch "phabricator:20190822.merchant.01.view.sql" to host "mariadb:3306"...
phabricator_1  | Applying patch "phabricator:20190909.herald.01.rebuild.php" to host "mariadb:3306"...
phabricator_1  | Applying patch "phabricator:20190924.diffusion.01.permanent.sql" to host "mariadb:3306"...
phabricator_1  | Applying patch "phabricator:20190924.diffusion.02.default.sql" to host "mariadb:3306"...
phabricator_1  | Applying patch "phabricator:20191028.uriindex.01.rebuild.php" to host "mariadb:3306"...
phabricator_1  | Applying patch "phabricator:20191113.identity.01.email.sql" to host "mariadb:3306"...
phabricator_1  | Applying patch "phabricator:20191113.identity.02.populate.php" to host "mariadb:3306"...
phabricator_1  | Applying patch "phabricator:20191113.identity.03.unassigned.sql" to host "mariadb:3306"...
phabricator_1  | Applying patch "phabricator:20191114.email.01.phid.sql" to host "mariadb:3306"...
phabricator_1  | Applying patch "phabricator:20191114.email.02.populate.php" to host "mariadb:3306"...
phabricator_1  | Storage is up to date. Use "storage status" for details.
phabricator_1  | Synchronizing static tables...
phabricator_1  | Verifying database schemata on "mariadb:3306"...
phabricator_1  | 
phabricator_1  | 
phabricator_1  | Database                 Table                 Name         Issues
phabricator_1  | phabricator_differential differential_revision phid         Surplus Key
phabricator_1  | phabricator_differential differential_revision key_modified Missing Key
phabricator_1  | phabricator_differential differential_revision key_phid     Missing Key
phabricator_1  | phabricator_repository   repository_identity   key_email    Missing Key
phabricator_1  | phabricator_phortune     phortune_accountemail key_account  Missing Key
phabricator_1  | phabricator_phortune     phortune_accountemail key_address  Missing Key
phabricator_1  | phabricator_phortune     phortune_accountemail key_phid     Missing Key
phabricator_1  | phabricator_user         user_email            key_phid     Missing Key
phabricator_1  | phabricator_conpherence  conpherence_index                  Better Table Engine Available
phabricator_1  | Applying schema adjustments...
phabricator_1  | Completed applying all schema adjustments.
phabricator_1  |  ANALYZE  Analyzing tables...
phabricator_1  |  ANALYZED  Analyzed 535 table(s).
phabricator_1  | Freeing active task leases...
phabricator_1  | Freed 0 task lease(s).
phabricator_1  | Starting daemons as daemon-user
phabricator_1  | Launching daemons:
phabricator_1  | (Logs will appear in "/var/tmp/phd/log/daemons.log".)
phabricator_1  | 
phabricator_1  |     (Pool: 1) PhabricatorRepositoryPullLocalDaemon
phabricator_1  |     (Pool: 1) PhabricatorTriggerDaemon
phabricator_1  |     (Pool: 1) PhabricatorFactDaemon
phabricator_1  |     (Pool: 4) PhabricatorTaskmasterDaemon
phabricator_1  | 
phabricator_1  | Done.
phabricator_1  | AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.20.0.4. Set the 'ServerName' directive globally to suppress this message
复制代码

当看到 Done.的时候，就可以打开浏览器对 Phabricator 进行进一步配置啦。

打开浏览器，输入你配置的域名后，Phabricator 将跳转至 Dashboard。

剩下的事情就是根据你自己的需求进行应用配置啦。

最后

Phabricator 的搭建只是第一步，与现有仓库集成、与CI 集成等内容留与后续再写吧。

--EOF

我现在有一个小小的折腾群，里面聚集了一些喜欢折腾的小伙伴。

在不发广告的情况下，我们在里面会一起聊聊软件、HomeLab、编程上的一些问题，也会在群里不定期的分享一些技术沙龙的资料。

喜欢折腾的小伙伴欢迎扫码添加好友。（请注明来源和目的，否则不会通过审核）

关于折腾群入群的那些事

微服务的缺陷

• 服务并没有解决复杂系统如何应对需求变化这个问题，甚至还加剧了这个问题。
• 当一个需求变化了，需要花大量的精力去识别这个变化影响到了哪些微服务，这些服务的多个团队之间，需要通过无休止的扯皮去决定哪个服务多一些，哪些服务少改一些。
• 然后测试团队还需要做昂贵的这种联调测试
• 即便如此呢，开发团队依然不放心，还要通过一系列的开关控制，小心翼翼的去做切流，去做灰度发布。

DDD功用

• 功能纬度
• 质量纬度，比如性能，可用性
• 工程纬度

拆分案例

关于领域

• 商品子域
• 订单子域
• 库存子域等等。

划分系统内部架构边界

边界清晰的好处

• 资源倾斜
• 使用弹力设计模式：比如重试，熔断，降级
• 使用特殊技术：比如Go语言
• 具备独立代码库：有独立团队和运维人员，和A和B的运行期做到隔离不互相影响

• 聚合根用来保证内部实体规则的正确性和数据的一致性
• 外部对象只能通过ID来引用聚合根，不能引用聚合根内部的实体
• 聚合根之间不能共享一个数据库事务，它们之间的数据一致性需要通过最终的一致性来保障

编者按：本文来自微信公众号 “人力资源分享汇”（ID：hrgogogo），作者 HRGO，36氪经授权发布。

疫情还在继续。

从今天开始，大部分人就已经开始为期一周，甚至更长的远程办公生涯。

这一周的在家远程办公，对国家是至关重要的，因为自我隔离，可以有效防止疫情的传播，我们每个人其实都在为战胜疫情而做出自己的贡献。

但远程办公，并没有那么容易，它最大的挑战就是人和人无法面对面的交流，管理效率和沟通效率会大幅下降，同时员工的工作状态不可控、工作进度不可控，团队的协同不可控，团队的氛围不可控... ...

诸多挑战下，要做好远程办公，这10点最关键。

01 每日明确固定沟通机制

公司内部可以这样规定：

①从今天开始，每天早晨9点，开启远程早会机制。

②每天下午6点，开启晚会机制，把每天的的工作进度进行规整。

③每天晚上12点前，相关责任人要将工作进度表发到邮箱/钉钉中。

不管是早会还是晚会，内容建议在公司范围内全部公开，尽量让所有人都周知每位成员的在这一周远程办公的工作内容，方便内部协作。

以此可以让所有人都知道，虽然不在办公室上班，工作地点变了，但是你的工作的时间和工作的内容，都没有变。

02 每日明确任务的分配

在远程办公的过程中，因为人和人无法面对面沟通，导致沟通中信息量大量缺失，所以对任务指令的精准性提出更高的要求。

所以要求分配任务时：

1、明确目的、任务描述、完成时限、成员构成和明确的责任人；

2、责任人要根据完成时限，合理地评估在什么时间内可以完成；

3、责任人只要抓执行结果，跟进任务计划中的问题，不要在过程中查收；

而任务一旦接受开始执行后，围绕任务执行进度、问题和计划的沟通都可以在微信群里逐步展开。

03 每日明确任务响应时间

远程办公的时候，经常会让人感觉很无力，因为看不到对方的状态，同事之间对响应时间的期待变得不确定。

这会让团队之间的协同出现很大的问题，所以必须明确任务的响应的时间，譬如：

①随时看工作群消息，@你的消息，10分钟内回复

②所有任务都需要设定明确的Deadline

③所有指令明确时间，比如：《招聘需求表》请下午5点前提交

04 提前准备远程办公工具箱

HRGO整理了一套《人力资源从业者远程办公常用工具箱》，内容非常多，你可以点击图片进行查看，文末也有思维导图的PDF文件下载方式。

05 正常作息，穿戴整齐，保持日常仪式感

对于个人而言，要保证高效的远程工作，仪式感还是少不了。

所以你要保证每天早晨起来后工作，要和上班时间时候的作息是一样的。换上正式一些的衣服，离开你的卧室，出来书房或者客厅办公，保持日常的仪式感。

最好要保证你的桌面整洁有序，这样效率也会提高。

（上图：HRGO年卡用户小杨同学的书桌）

06 利用好每一个早晨，可参考「罐头工作法」

要保证远程办公的高效，那么早晨就千万不能接触杂乱信息：知乎、微博、豆瓣、抖音、快手、今日头条....都不要看。

接受杂乱无章的碎片信息会让你头脑混乱，毁掉早晨的状态，也会耽误你一整天的状态。

在家里，没有人监督和敦促你，你就更需要快速地进入工作状态，你必须立即投入到紧张、有序、逻辑化、体系化的工作中。

村上春树说，自己工作的时候，一般就是独自闷在屋里，有时状态连贯甚至不吃午饭，效率奇高，它把这种工作模式叫：罐头工作法。

07 让自己进入心流状态

早上的工作，先处理自己擅长的事情。

因为当你处理自己擅长事情的时候，你会将个人精神力完全投注在某种活动上，同时感到兴奋及充实感，这就是进入了心流状态。

只要当天你的工作进入了心流状态，那么你今天可以解决的问题就会很多，远超平常。

想要进入心流状态，那么就一定要有工具利器、固定且规律的时间、专属的位置、不受打扰的环境，这样的远程办公，你值得拥有。

08 注意让自己即时记录

在家办公的环境下，很少有人、有场景、有变化地去提醒你。

那么你就要将听到任何重要信息、被分配到任何事务，第一时间快速记下要点。等不忙的时候，再拿出来这些笔记，进行补充、拓展、延伸、完善、思考。

甚至，你可以发展出自己的一套速记法，用记号表达特定含义。比如，用叹号表示优先级，用粗线表示截止时间，用箭头表示对接人，用三角表示重点等等。

09 记得要做 Checklist

在每个远程办公结束的晚上，做一下你当天的 Checklist。

任务指令、布置安排、项目推进、人员配备，都需要一条条予以确认。尤其是领导或者同事没有把需求或指令说清楚的项目，都要写在Checklist里面，跟对方确认。

从理论上来说，只要Checklist做得足够严密，执行时严格确认每一条，任务的完成就不会出问题。

这是在不可控的环境中，找到可控地解决问题的最佳办法。

10 找你的同事，打卡互相监督

现在很流行打卡社群。

那不如和你的同事，一起组建一个团队内部，远程办公的打卡社群。

每天按时上线工作、每天能按时吃饭运动，每天能按时休息学习，如果漏掉打卡就得发红包。

通过这种互相监督，让团队所有人都自律起来。HRGO就是通过「你打卡我退费」，让上千位HR保持学习习惯，并同时提升自己的能力，已经超过5000位HR一起抱团学习。

最后，希望能帮到在家办公的你。

对于谷歌母公司Alphabet来说，除了网页搜索、安卓操作系统之外，网络视频YouTube以及云计算也是其他两个极为重要的业务，过去谷歌从未披露过这两个业务的营收。据外媒最新消息，作为史上第一次，谷歌周一在其2019年第四季度收益报告中公布了其YouTube和云计算业务的经营数据。

据国外媒体报道，2019年，YouTube通过视频广告创造了151.5亿美元的收入，仅第四季度就有47.2亿美元。该部门在2018年创造了111.6亿美元的收入，包括当年第四季度的36.1亿美元。对比可以发现，YouTube去年的广告收入同比增长了三分之一，虽然是一项非常老牌的网络视频服务，但是增速仍然保持了高位。

需要指出的是，这一部分收入不包括YouTube的非广告收入，比如“YouTube电视”（互联网电视频道直播服务）的会员费，这些收入囊括在了谷歌的其他收入部分。

谷歌的云计算业务在2019年创造了89.2亿美元的收入，第四季度创造了26.1亿美元。相比之下，2018财年云计算业务的收入为58.4亿美元，当年第四季度为17.1亿美元。两相比较，谷歌云计算业务去年同比增长了近一半。

云计算是谷歌高管并不满意的业务，市场研究公司的报告显示，谷歌云计算的份额仅为个位数，甚至仅相当于行业领先者亚马逊和微软公司的几分之一。

据报道，谷歌高管过去曾经开会，掌门人佩奇差一点决定放弃云计算业务，但是最终决定扩大投资，希望能够在这一市场进入前两名，这意味着至少要超过排名第二位的微软公司。

在公布四季度财报后，谷歌母公司Alphabet的股价下跌约3.5%。

分析师们长期以来一直呼吁谷歌单独报告YouTube的收益，因为它被认为是其网络广告业务的重要组成部分。

如果把YouTube当做一个独立的影视媒体公司，2018年，该公司从广告中获得的收入超过了探索公司（探索频道母公司），后者的年收入为106亿美元，而YouTube为112亿美元。探索公司尚未报告其2019年全年的结果。

谷歌的云计算业务是该公司中一个年轻但快速增长的部分，正在拼命追赶微软和亚马逊。今年7月，谷歌表示，其云计算部门的年收入刚刚达到80亿美元，并计划在未来几年内将其销售额增加两倍。

Alphabet第一次披露YouTube和云计算的业务，或许和该公司最近的高层人事变动有关系。

众所周知的是，之前，谷歌首席执行官皮查伊兼任Alphabet首席执行官，过去的首席执行官佩奇和总裁布林辞去职位，退出了日常管理。皮查伊执掌的谷歌和Alphabet正在呈现出更大的透明度。

另外，包括谷歌在内的美国四大科技巨头（谷歌、苹果、Facebook和亚马逊）正在接受美国政府多个部门的反垄断调查，谷歌业务信息的透明化，也有助于谷歌配合监管机构的调查，减少外界对于谷歌垄断市场的议论。

据悉，一个由来自不同州和地区的50名司法部长组成的联盟之前宣布了他们对谷歌网络广告业务的调查。新的披露让投资者对调查人员可能正在关注的谷歌广告板块的不同部分有了更多的了解。

在过去一年中，行业内掀起了网络视频大涨，更多的互联网公司、好莱坞和电视台正在效仿奈飞公司的模式，进入原创影视视频市场，这让奈飞、亚马逊等视频平台面临更大的竞争压力。

不过，YouTube的商业模式则截然不同，YouTube是全世界最大的网民原创视频网站，视频制作质量不如奈飞的原创影视作品，但是内容规模庞大丰富，仍然占据了不菲的播放时间比例。

根据早前美国派杰公司的一个调查，在美国青少年群体中，奈飞和YouTube各自占到了三分之一的视频播放时长，换言之，两个商业模式截然不同的视频巨头霸占了三分之二的时间份额。

之前，YouTube也曾经“赶时髦”，进入了原创影视领域，投资拍摄美剧等作品，通过会员费获取收入。但是据外媒报道，YouTube在原创影视领域的战略并不成功，目前已经基本放弃，原先制作的一些美剧影视作品已经免费对大众开放，将通过视频广告回笼投资。

构建增长模型在我们的增长全景图中，处于找到增长发力点的下半部分，那么在构建模型之后在应用模型时也会帮助我们找到聚焦领域。

No.1 什么是增长模型？

增长模型就是找到所有对北极星指标有影响的所有细分指标，并用一个简单的公式，把这些细分指标联系起来的过程。其实就是从北极星指标到细分指标的拆解过程。

为什么要构建增长模型？

1. 比如：大家都会玩游戏，在玩游戏时对游戏中的人物有一个指令输入，经过游戏机或者电脑的处理 ，形成了输入导致游戏人物或者剧情有个结果。所以想要控制输入是通过控制输入而完成的。

2. 比如：你想要减肥，改变体重是你的北极星指标。

通过可以改变控制的输入变量 行为 去影响你的输出变量 结果 也就是北极星指标

3. 比如：我们在做增长的时候同样的道理。

你的北极星指标是日活跃用户，我们很难直接做一些什么来提升日活，我们能做的是影响这些的细分指标，app下载量、用户激活率、老用户留存。

输入变量：单一因素、团队可直接操作、行为；

输出变量：受多种因素影响，团队不可直接操作、结果。

所以增长模型就是帮助大家把不可以操作的一个结果一个北极星指标，分解成可以操作的一些细分指标，然后大家可以通过细分指标改善最终的结果；

No.2 如何构建增长模型？

构建增长模型3步走：

举例说明：对于网易云音乐是个听歌的应用，所以：

• 第一步：北极星指标为总听歌时间
• 第二步：绘制用户核心转化路径
• 第三步：组装增长模型

介绍两个比较常用的增长模型框架：

1. 增长模型一应用：全链漏斗模型

总听歌时间=应用下载量*首次访问%*首次听歌%*持续听歌%*平均听歌时长

比如说每天下载量30000，每天有50%人首次打开我的app，在首次访问里的人有33%首次听歌，持续听歌人数5%（老用户听歌人数/老用户总数（天））平均听歌时长20分钟。

全链漏斗模型：优点把影响北极星指标的主要细分指标都显示出来，并标注转化率，找到机会点，容易搭建。

缺点：不能直接计算北极星指标。

2. 增长模型二应用：因子分解模型

• 因子分解模型：优点把影响北极星指标的主要细分指标都显示出来，并标注转化率，找到机会点，容易搭建。
• 缺点：不能直接计算北极星指标。

No.3 如何应用增长模型？

1. 应用一：找到聚焦领域-四两拨千斤的增长发力点

• 问题一：想要增长北极星指标，AARRR里可做的事情很多，如何决定先做什么后做什么？
• 问题二：小公司资源有限，如何找到性价比最高的点将增长效果最大化？

案例一：Airbnb通过增长模型找到发力点

行业平均值这个指标如果不能提升到和行业一样的水平，那么想办法拉来很多流量其实没什么意义很多都会浪费掉，所以在现阶段这个点就是airbnb最重要的发力点。

案例二：Sass软件用不同用户分群，分解增长模型，寻找机会。

粗略的看起来好像发现除了使用购买率低一点，别的好像看不出来什么问题。这个时候比较有用的一个方法，我们按照一些重要的用户纬度，把增长模型进行分解。

获客渠道最重要的两个部分是公号和广告，客户可能有大公司和小公司按人数来把增长模型进一步拆分出来，拆出之后可对比分析发现一些潜在的机会。

比如说付费广告来源的用户试用注册率和购买率偏低但是订阅长度却很长，可能提示我们这个渠道并不是很多我们的精准用户要想办法提高精准程度，但通过这个渠道来源的用户成为付费用户后生命周期比较长，说明还可以优化这个渠道找到更感兴趣的用户不要盲目的追求流量。

再比如小公司的分解纬度试用购买率很低同时付费用户订阅的长度也比较低，那可能我们的软件是不是不太适合小公司，可能是团队合作的软件对小公司来说访问量虽然很大但对于他们需求并不大，那么大公司可能是我们主要发力的群组。

通过分群的模式分解增长模型对比不同的维度，他的增长模型的细分指标，也可以帮助我们找到改善北极星指标的机会。

2. 应用二：寻找具体的增长思路

• 问题一：业务很复杂，感觉千头万绪，不知道从何下手推动增长。
• 问题二：想要改善北极星指标，但是落实到产品、运营等还是没有具体的想法如何做？

案例：淘宝通过增长模型简化业务，寻找增长思路

为了提升订单价或者让用户到达指定感兴趣的页面，增长模型很好的一点是把复杂的东西抽象化，反而比较容易理清思路。

3. 应用三：指导指标拆分和团队协作

• 问题一：作为增长负责人，定了北极星目标，如何把活分下去，并保证执行团队和我的思路一致减少失误？
• 问题二：作为执行团队，如何清晰的知道自己的任务，可以在快节奏的日常工作中作出正确的决定？
• 问题三：如果公司里有多个团队合作推动增长，如何保证大家劲往一处使？

通过增长模型把北极星指标拆分为细分指标。

常见的因子分解增长模型框架：

• 横向分解：先按照用户群组，通过“加法”分解
• 纵向分解：在按照用户漏斗，通过“乘法”分解

注意⚠️：拆分细分指标关键

遵循MECE原则：

• ME：相互独立，每个细分指标完全独立（避免后续分配给团队时互相打架）
• CE：完全穷尽，细分指标涵盖影响增长重要因素（避免增长中的盲点）

协作模式一：每个跨功能团队单独承担一个细分指标

协作模式二：多个团队合作推动同一细分指标

细分指标还可以进一步拆分，以新用户量为例：

目标：年度新用户数量50万

新用户量=运营渠道获客团队（40万）+BD商务合作团队（5万）+产品推荐团队（5万：比如老带新功能等）

运营渠道获客团队为负责新用户指标主要团队，BD和产品为支持团队。

案例：网易的多团队如何协作推动增长

情景：商业化部门将年收入目标，拆分到各个产品线，在单个产品线收入目标下，需要有好几个部门来协作如何推？

第一次尝试：各部门背独立KPI，但出现各部门指标互相影响的情况下，比如广告部收入指标涨，但产品部用户活跃指标降，部门之间难以及时沟通，每个团队都是领域专家，但是汇集到一起反而降低产出。

第二次尝试：成立用户增长中心，改成OKR模式，各部门首先有一个共同的北极星指标，同时给产品部、体验部拆分不同的细分指标，保证细分指标之间没有交集，团队不能考虑仅仅提升细分指标还要最终支持北极星的增长，避免了互相伤害的情况。

总结：构建和应用三种增长模型

本文由@叶子 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自Unsplash, 基于CC0协议

题记

随着 Elastic 的上市，ELK Stack 不仅在 BAT 的大公司得到长足的发展，而且在各个中小公司都得到非常广泛的应用，甚至连“婚庆网站”都开始使用 Elasticsearch 了。随之而来的是 Elasticsearch 相关部署、框架、性能优化的文章早已铺天盖地。

初学者甚至会进入幻觉——“一键部署、导入数据、检索&聚合、动态扩展， So Easy，妈妈再也不用担心我的 Elastic 学习”！

但，实际上呢？仅就 Elasticsearch 索引设计，请回答如下几个问题：

• 每天几百 GB 增量实时数据的TB级甚至PB级别的大索引如何设计？
• 分片数和副本数大小如何设计，才能提升 ES 集群的性能？
• ES 的 Mapping 该如何设计，才能保证检索的高效？
• 检索类型 term/match/matchphrase/querystring /match_phrase _prefix /fuzzy 那么多，设计阶段如何选型呢？
• 分词该如何设计，才能满足复杂业务场景需求？
• 传统数据库中的多表关联在 ES 中如何设计？......

这么看来，没有那么 Easy，坑还是得一步步的踩出来的。

正如携程架构师 WOOD 大叔所说“做搜索容易，做好搜索相当难！”，

VIVO 搜索引擎架构师所说“ 熟练使用 ES 离做好搜索还差很远！”。

本文主结合作者近千万级开发实战经验，和大家一起深入探讨一下Elasticsearch 索引设计......

索引设计的重要性

在美团写给工程师的十条精进原则中强调了“设计优先”。无数事实证明，忽略了前期设计，往往会带来很大的延期风险。并且未经评估的不当的设计会带来巨大的维护成本，后期不得不腾出时间，专门进行优化和重构。

而 Elasticsearch 日渐成为大家非结构数据库的首选方案，项目前期良好的设计和评审是必须的，能给整个项目带来收益。

索引层面的设计在 Elasticsearch 相关产品、项目的设计阶段的作用举重若轻。

• 好的索引设计在整个集群规划中占据举足轻重的作用，索引的设计直接影响集群设计的好坏和复杂度。
• 好的索引设计应该是充分结合业务场景的时间维度和空间维度，结合业务场景充分考量增、删、改、查等全维度设计的。
• 好的索引设计是完全基于“设计先行，编码在后”的原则，前期会花很长时间，为的是后期工作更加顺畅，避免不必要的返工。

1、PB 级别的大索引如何设计？

单纯的普通数据索引，如果不考虑增量数据，基本上普通索引就能够满足性能要求。

我们通常的操作就是：

• 步骤 1：创建索引；
• 步骤 2：导入或者写入数据；
• 步骤 3：提供查询请求访问或者查询服务。

1.1 大索引的缺陷

如果每天亿万+的实时增量数据呢，基于以下几点原因，单个索引是无法满足要求的。在 360 技术访谈中也提到了大索引的设计的困惑。

1.1.1 存储大小限制维度

单个分片（Shard）实际是 Lucene 的索引，单分片能存储的最大文档数是：2,147,483,519 (= Integer.MAX_VALUE - 128)。如下命令能查看全部索引的分隔分片的文档大小：

GET _cat/shardsapp_index                       2 p STARTED      9443   2.8mb 127.0.0.1 Hk9wFwUapp_index                       2 r UNASSIGNEDapp_index                       3 p STARTED      9462   2.7mb 127.0.0.1 Hk9wFwUapp_index                       3 r UNASSIGNEDapp_index                       4 p STARTED      9520   3.5mb 127.0.0.1 Hk9wFwUapp_index                       4 r UNASSIGNEDapp_index                       1 p STARTED      9453   2.4mb 127.0.0.1 Hk9wFwUapp_index                       1 r UNASSIGNEDapp_index                       0 p STARTED      9365   2.3mb 127.0.0.1 Hk9wFwUapp_index                       0 r UNASSIGNED

1.1.2 性能维度

当然一个索引很大的话，数据写入和查询性能都会变差。

而高效检索体现在：基于日期的检索可以直接检索对应日期的索引，无形中缩减了很大的数据规模。

比如检索：“2019-02-01”号的数据，之前的检索会是在一个月甚至更大体量的索引中进行。

现在直接检索"index_2019-02-01"的索引,效率提升好几倍。

1.1.3 风险维度

一旦一个大索引出现故障，相关的数据都会受到影响。而分成滚动索引的话，相当于做了物理隔离。

1.2 PB 级索引设计实现

综上，结合实践经验，大索引设计建议：使用模板+Rollover+Curator动态创建索引。动态索引使用效果如下：

index_2019-01-01-000001index_2019-01-02-000002index_2019-01-03-000003index_2019-01-04-000004index_2019-01-05-000005

1.2.1 使用模板统一配置索引

目的：统一管理索引，相关索引字段完全一致。

1.2.2 使用 Rollver 增量管理索引

目的：按照日期、文档数、文档存储大小三个维度进行更新索引。使用举例：

POST /logs_write/_rollover{"conditions": {"max_age":   "7d","max_docs":  1000,"max_size":  "5gb"}}

1.2.3 索引增量更新原理

一图胜千言。

索引更新的时机是：当原始索引满足设置条件的三个中的一个的时候，就会更新为新的索引。为保证业务的全索引检索，一般采用别名机制。

在索引模板设计阶段，模板定义一个全局别名：用途是全局检索，如图所示的别名：indexall。每次更新到新的索引后，新索引指向一个用于实时新数据写入的别名，如图所示的别名：indexlatest。同时将旧索引的别名 index_latest 移除。

别名删除和新增操作举例：

POST /_aliases{"actions" : [{ "remove" : { "index" : "index_2019-01-01-000001", "alias" : "index_latest" } },{ "add" : { "index" : "index_2019-01-02-000002", "alias" : "index_latest" } }]}

经过如上步骤，即可完成索引的更新操作。

1.2.4 使用 curator 高效清理历史数据

目的：按照日期定期删除、归档历史数据。

一个大索引的数据删除方式只能使用 delete_by_query，由于 ES 中使用更新版本机制。删除索引后，由于没有物理删除，磁盘存储信息会不减反增。有同学就反馈 500GB+ 的索引 delete_by_query 导致负载增高的情况。

而按照日期划分索引后，不需要的历史数据可以做如下的处理。

• 删除——对应 delete 索引操作。

• 压缩——对应 shrink 操作。

• 段合并——对应 force_merge 操作。

而这一切，可以借助：curator 工具通过简单的配置文件结合定义任务 crontab 一键实现。

注意：7.X高版本借助iLM实现更为简单。

举例，一键删除 30 天前的历史数据：

  [root@localhost .curator]# cat action.yml   actions:1:action: delete_indicesdescription: >-Delete indices older than30days (basedonindex name),forlogstash-prefixed indices.Ignore the errorifthe filter does not resultinanactionable list ofindices(ignore_empty_list) and exit cleanly.options:ignore_empty_list: Truedisable_action: Falsefilters:- filtertype: patternkind: prefixvalue: logs_- filtertype: agesource: namedirection: oldertimestring: '%Y.%m.%d'unit: daysunit_count: 30

2、分片数和副本数如何设计？

2.1 分片/副本认知

• 1、分片：分片本身都是一个功能齐全且独立的“索引”，可以托管在集群中的任何节点上。

数据切分分片的主要目的：

（1）水平分割/缩放内容量 。 

（2）跨分片（可能在多个节点上）分布和并行化操作，提高性能/吞吐量。 

注意：分片一旦创建，不可以修改大小。

• 2、副本：它在分片/节点出现故障时提供高可用性。

副本的好处：因为可以在所有副本上并行执行搜索——因此扩展了搜索量/吞吐量。

注意：副本分片与主分片存储在集群中不同的节点。副本的大小可以通过：number_of_replicas动态修改。

2.2 分片和副本实战中设计

最常见问题答疑

2.2.1 问题 1：索引设置多少分片？

Shard 大小官方推荐值为 20-40GB, 具体原理呢？Elasticsearch 员工 Medcl 曾经讨论如下：

Lucene 底层没有这个大小的限制，20-40GB 的这个区间范围本身就比较大，经验值有时候就是拍脑袋，不一定都好使。

Elasticsearch 对数据的隔离和迁移是以分片为单位进行的，分片太大，会加大迁移成本。

一个分片就是一个 Lucene 的库，一个 Lucene 目录里面包含很多 Segment，每个 Segment 有文档数的上限，Segment 内部的文档 ID 目前使用的是 Java 的整型，也就是 2 的 31 次方，所以能够表示的总的文档数为Integer.MAXVALUE - 128 = 2^31 - 128 = 2147483647 - 1 = 2,147,483,519，也就是21.4亿条。

同样，如果你不 forcemerge 成一个 Segment，单个 shard 的文档数能超过这个数。

单个 Lucene 越大，索引会越大，查询的操作成本自然要越高，IO 压力越大，自然会影响查询体验。

具体一个分片多少数据合适，还是需要结合实际的业务数据和实际的查询来进行测试以进行评估。

综合实战+网上各种经验分享，梳理如下：

• 第一步：预估一下数据量的规模。一共要存储多久的数据，每天新增多少数据？两者的乘积就是总数据量。

• 第二步：预估分多少个索引存储。索引的划分可以根据业务需要。

• 第三步：考虑和衡量可扩展性，预估需要搭建几台机器的集群。存储主要看磁盘空间，假设每台机器2TB，可用：2TB0.85(磁盘实际利用率）0.85(ES 警戒水位线）。

• 第四步：单分片的大小建议最大设置为 30GB。此处如果是增量索引，可以结合大索引的设计部分的实现一起规划。

前三步能得出一个索引的大小。分片数考虑维度：

• 1）分片数 = 索引大小/分片大小经验值 30GB 。
• 2）分片数建议和节点数一致。设计的时候1）、2）两者权衡考虑+rollover 动态更新索引结合。

每个 shard 大小是按照经验值 30G 到 50G，因为在这个范围内查询和写入性能较好。

经验值的探推荐阅读：

Elasticsearch究竟要设置多少分片数？

探究 | Elasticsearch集群规模和容量规划的底层逻辑

2.2.2 问题 2：索引设置多少副本？

结合集群的规模，对于集群数据节点 >=2 的场景：建议副本至少设置为 1。

之前有同学出现过：副本设置为 0，长久以后会出现——数据写入向指定机器倾斜的情况。

注意：

单节点的机器设置了副本也不会生效的。副本数的设计结合数据的安全需要。对于数据安全性要求非常高的业务场景，建议做好：增强备份（结合 ES 官方备份方案）。

3、Mapping 如何设计？

3.1 Mapping 认知

Mapping 是定义文档及其包含的字段的存储和索引方式的过程。例如，使用映射来定义：

• 应将哪些字符串字段定义为全文检索字段；
• 哪些字段包含数字，日期或地理位置；
• 定义日期值的格式（时间戳还是日期类型等）；
• 用于控制动态添加字段的映射的自定义规则。

3.2 设计 Mapping 的注意事项

ES 支持增加字段 //新增字段

PUT new_index{"mappings": {"_doc": {"properties": {"status_code": {"type":       "keyword"}}}}}

• ES 不支持直接删除字段
• ES 不支持直接修改字段
• ES 不支持直接修改字段类型 如果非要做灵活设计，ES 有其他方案可以替换，借助reindex。但是数据量大会有性能问题，建议设计阶段综合权衡考虑。

3.3 Mapping 字段的设置流程

索引分为静态 Mapping（自定义字段）+动态 Mapping（ES 自动根据导入数据适配）。

实战业务场景建议：选用静态 Mapping，根据业务类型自己定义字段类型。

好处：

• 可控；
• 节省存储空间（默认 string 是 text+keyword，实际业务不一定需要）。

设置字段的时候，务必过一下如下图示的流程。根据实际业务需要，主要关注点：

• 数据类型选型；
• 是否需要检索；
• 是否需要排序+聚合分析；
• 是否需要另行存储。

核心参数的含义，梳理如下：

3.4 Mapping 建议结合模板定义

索引 Templates——索引模板允许您定义在创建新索引时自动应用的模板。模板包括settings和Mappings以及控制是否应将模板应用于新索引。

注意：模板仅在索引创建时应用。更改模板不会对现有索引产生影响。

第1部分也有说明，针对大索引，使用模板是必须的。核心需要设置的setting（仅列举了实战中最常用、可以动态修改的）如下：

• index.numberofreplicas 每个主分片具有的副本数。默认为 1（7.X 版本，低于 7.X 为 5）。
• index.maxresultwindow 深度分页 rom + size 的最大值—— 默认为 10000。
• index.refresh_interval 默认 1s：代表最快 1s 搜索可见；

写入时候建议设置为 -1，提高写入性能；

实战业务如果对实时性要求不高，建议设置为 30s 或者更高。

3.5 包含 Mapping 的 template 设计万能模板

以下模板已经在 7.2 验证 ok，可以直接拷贝修改后实战项目中使用。

PUT _template/test_template{"index_patterns": ["test_index_*","test_*"],"settings": {"number_of_shards": 1,"number_of_replicas": 1,"max_result_window": 100000,"refresh_interval": "30s"},"mappings": {"properties": {"id": {"type": "long"},"title": {"type": "keyword"},"content": {"analyzer": "ik_max_word","type": "text","fields": {"keyword": {"ignore_above": 256,"type": "keyword"}}},"available": {"type": "boolean"},"review": {"type": "nested","properties": {"nickname": {"type": "text"},"text": {"type": "text"},"stars": {"type": "integer"}}},"publish_time": {"type": "date","format": "yyyy-MM-dd HH:mm:ss||yyyy-MM-dd||epoch_millis"},"expected_attendees": {"type": "integer_range"},"ip_addr": {"type": "ip"},"suggest": {"type": "completion"}}}}

4、分词的选型

主要以 ik 来说明，最新版本的ik支持两种类型。ik_maxword 细粒度匹配，适用切分非常细的场景。ik_smart 粗粒度匹配，适用切分粗的场景。

4.1 坑 1：分词选型

实际业务中：建议适用ik_max_word分词 + match_phrase短语检索。

原因：ik_smart有覆盖不全的情况，数据量大了以后，即便 reindex 能满足要求，但面对极大的索引的情况，reindex 的耗时我们承担不起。建议ik_max_word一步到位。

4.2 坑 2：ik 要装集群的所有机器吗？

建议：安装在集群的所有节点上。

4.3 坑 3：ik 匹配不到怎么办？

• 方案1：扩充 ik 开源自带的词库+动态更新词库；原生的词库分词数量级很小，基础词库尽量更大更全，网上搜索一下“搜狗词库“。

动态更新词库：可以结合 mysql+ik 自带的更新词库的方式动态更新词库。

更新词库仅对新创建的索引生效，部分老数据索引建议使用 reindex 升级处理。

• 方案2：采用字词混合索引的方式，避免“明明存在，但是检索不到的”场景。 探究 | 明明存在，怎么搜索不出来呢？
  

5、检索类型如何选型呢？

前提：5.X 版本之后，string 类型不再存在，取代的是text和keyword类型。

• text 类型作用：分词，将大段的文字根据分词器切分成独立的词或者词组，以便全文检索。

适用于：email 内容、某产品的描述等需要分词全文检索的字段；

不适用：排序或聚合（Significant Terms 聚合例外）

• keyword 类型：无需分词、整段完整精确匹配。

适用于：email 地址、住址、状态码、分类 tags。

以一个实战例子说明：

PUT zz_test{"mappings": {"doc": {"properties": {"title": {"type": "text","analyzer":"ik_max_word","fields": {"keyword": {"type": "keyword","ignore_above": 256}}}}}}}GET zz_test/_mapping
PUT zz_test/doc/1{"title":"锤子加湿器官方致歉,难产后临时推迟一个月发货遭diss耍流氓"}

POST zz_test/_analyze{"text": "锤子加湿器官方致歉,难产后临时推迟一个月发货遭diss耍流氓","analyzer": "ik_max_word"}

ik_max_word的分词结果如下：

锤子、锤、子、加湿器、湿、器官、官方、方、致歉、致、歉、难产、产后、后、临时、临、时、推迟、迟、一个、 一个、 一、个月、 个、 月、 发货、发、货、遭、diss、耍流氓、耍、流氓、氓。

5.1 term 精确匹配

• 核心功能：不受到分词器的影响，属于完整的精确匹配。
• 应用场景：精确、精准匹配。
• 适用类型：keyword。
• 举例：term 最适合匹配的类型是 keyword，如下所示的精确完整匹配：

POST zz_test/_search{"query": {"term": {"title.keyword": "锤子加湿器官方致歉,难产后临时推迟一个月发货遭diss耍流氓"}}}

• 注意：如下是匹配不到结果的。

POST zz_test/_search{"query": {"term": {"title": "锤子加湿器"}}}

• 原因：对于 title 中的锤子加湿器，term 不会做分词拆分匹配的。且 ik_max_word 分词也是没有“锤子加湿器”这组关键词的。

5.2 prefix 前缀匹配

• 核心功能：前缀匹配。
• 应用场景：前缀自动补全的业务场景。
• 适用类型：keyword。

如下能匹配到文档 id 为 1 的文章。

POST zz_test/_search{"query": {"prefix": {"title.keyword": "锤子加湿器"}}}

5.3 wildcard 模糊匹配

• 核心功能：匹配具有匹配通配符表达式 keyword 类型的文档。支持的通配符：*，它匹配任何字符序列（包括空字符序列）；？，它匹配任何单个字符。

• 应用场景：请注意，选型务必要慎重！此查询可能很慢多组关键次的情况下可能会导致宕机，因为它需要遍历多个术语。为了防止非常慢的通配符查询，通配符不能以任何一个通配符*或？开头。

• 适用类型：keyword。

如下匹配，类似 MySQL 中的通配符匹配，能匹配所有包含加湿器的文章。

POST zz_test/_search{"query": {"wildcard": {"title.keyword": "*加湿器*"}}}

5.4 match 分词匹配

• 核心功能：全文检索，分词词项匹配。
• 应用场景：实际业务中较少使用，原因：匹配范围太宽泛，不够准确。
• 适用类型：text。
• 如下示例，title 包含"锤子"和“加湿器”的都会被检索到。

POST zz_test/_search{"profile": true,"query": {"match": {"title": "锤子加湿器"}}}

5.5 match_phrase 短语匹配

• 核心功能：match_phrase 查询首先将查询字符串解析成一个词项列表，然后对这些词项进行搜索; 只保留那些包含 全部 搜索词项，且 位置"position" 与搜索词项相同的文档。

• 应用场景：业务开发中 90%+ 的全文检索都会使用 match_phrase 或者 query_string 类型，而不是 match。

• 适用类型：text。

• 注意：

POST zz_test/_analyze{"text": "锤子加湿器","analyzer": "ik_max_word"}

• 分词结果：

锤子， 锤，子， 加湿器， 湿，器。而：id为1的文档的分词结果：锤子, 锤, 子, 加湿器, 湿, 器官。所以，如下的检索是匹配不到结果的。

POST zz_test/_search{"query": {"match_phrase": {"title": "锤子加湿器"}}}

如果想匹配到，怎么办呢？这里可以字词组合索引的形式。

推荐阅读：

探究 | 明明存在，怎么搜索不出来呢？

5.6 multi_match 多组匹配

• 核心功能：match query 针对多字段的升级版本。
• 应用场景：多字段检索。
• 适用类型：text。
• 举例：

POST zz_test/_search{"query": {"multi_match": {"query": "加湿器","fields": ["title","content"]}}}

5.7 query_string 类型

• 核心功能：支持与或非表达式+其他N多配置参数。
• 应用场景：业务系统需要支持自定义表达式检索。
• 适用类型：text。

POST zz_test/_search{"query": {"query_string": {"default_field": "title","query": "(锤子 AND 加湿器) OR (官方 AND 道歉)"}}}

5.8 bool 组合匹配

• 核心功能：多条件组合综合查询。
• 应用场景：支持多条件组合查询的场景。
• 适用类型：text 或者 keyword。一个 bool 过滤器由三部分组成：

{"bool" : {"must" :     [],"should" :   [],"must_not" : [],"filter":    []}}

• must ——所有的语句都 必须（must） 匹配，与 AND 等价。
• must_not ——所有的语句都 不能（must not） 匹配，与 NOT 等价。
• should ——至少有一个语句要匹配，与 OR 等价。
• filter——必须匹配，运行在非评分&过滤模式。

6、多表关联如何设计？

6.1 为什么会有多表关联

多表关联是被问的最多的问题之一。几乎每周都会被问到。

主要原因：常规基于关系型数据库开发，多多少少都会遇到关联查询。而关系型数据库设计的思维很容易带到 ES 的设计中。

6.2 多表关联如何实现

方案一：多表关联视图，视图同步 ES

MySQL 宽表导入 ES，使用 ES 查询+检索。适用场景：基础业务都在 MySQL，存在几十张甚至几百张表，准备同步到 ES，使用 ES 做全文检索。

将数据整合成一个宽表后写到 ES，宽表的实现可以借助关系型数据库的视图实现。

宽表处理在处理一对多、多对多关系时，会有字段冗余问题，如果借助：logstash_input_jdbc，关系型数据库如 MySQL 中的每一个字段都会自动帮你转成 ES 中对应索引下的对应 document 下的某个相同字段下的数据。

• 步骤 1：提前关联好数据，将关联的表建立好视图，一个索引对应你的一个视图，并确认视图中数据的正确性。

• 步骤 2：ES 中针对每个视图定义好索引名称及 Mapping。

• 步骤 3：以视图为单位通过 logstash_input_jdbc 同步到 ES 中。

方案二：1 对 1 同步 ES

MySQL+ES 结合，各取所长。适用场景：关系型数据库全量同步到 ES 存储，没有做冗余视图关联。

ES 擅长的是检索，而 MySQL 才擅长关系管理。

所以可以考虑二者结合，使用 ES 多索引建立相同的别名，针对别名检索到对应 ID 后再回 MySQL 通过关联 ID join 出需要的数据。

方案三：使用 Nested 做好关联

适用场景：1 对少量的场景。

举例：有一个文档描述了一个帖子和一个包含帖子上所有评论的内部对象评论。可以借助 Nested 实现。

Nested 类型选型——如果需要索引对象数组并保持数组中每个对象的独立性，则应使用嵌套 Nested 数据类型而不是对象 Oject 数据类型。

当使用嵌套文档时，使用通用的查询方式是无法访问到的，必须使用合适的查询方式（nested query、nested filter、nested facet等），很多场景下，使用嵌套文档的复杂度在于索引阶段对关联关系的组织拼装。

方案四：使用ES6.X+ 父子关系 Join 做关联

适用场景：1对多量的场景。

举例：1 个产品和供应商之间是1对N的关联关系。

Join 类型：join 数据类型是一个特殊字段，用于在同一索引的文档中创建父/子关系。关系部分定义文档中的一组可能关系，每个关系是父名称和子名称。

当使用父子文档时，使用has_child 或者has_parent做父子关联查询。

方案三、方案四选型对比：

注意：方案三&方案四选型必须考虑性能问题。文档应该尽量通过合理的建模来提升检索效率。

Join 类型应该尽量避免使用。nested 类型检索使得检索效率慢几倍，父子Join 类型检索会使得检索效率慢几百倍。

尽量将业务转化为没有关联关系的文档形式，在文档建模处多下功夫，以提升检索效率。

干货 | 论Elasticsearch数据建模的重要性

干货 | Elasticsearch多表关联设计指南

小结

7、实战中遇到过的坑

如果能重来，我会如何设计 Elasticsearch 系统？

来自累计近千万实战项目设计的思考。

• 坑1: 数据清洗一定发生在写入 es 之前！而不是请求数据后处理，拿势必会降低请求速度和效率。

• 坑2：高亮不要重复造轮子，用原生就可以。

• 坑3：让 es 做他擅长的事，检索+不复杂的聚合，否则数据量+复杂的业务逻辑大会有性能问题。

• 坑4：设计的工作必须不要省！快了就是慢了，否则无休止的因设计缺陷引发的 bug 会增加团队的戳败感！

• 坑5：在给定时间的前提下，永远不会有完美的设计，必须相对合理的设计+重构结合，才会有相对靠谱的系统。

• 坑6：SSD 能提升性能，但如果系统业务逻辑非常负责，换了 SSD 未必达到预期。

• 坑7：由于 Elasticsearch 不支持事务 ACID 特性，数据库作为实时数据补充，对于实时数据要求严格的场景，必须同时采取双写或者同步的方式。这样，一旦实时数据出现不一致，可以通过数据库进行同步递增更新。

8、小结

本文从选题和撰写历时2周+的时间，期间反复梳理了开发过程中遇到的问题、社区/QQ 群/知识星球等中大家提问的问题。

将TOP N 大家最关注的问题也是实战中得得确确容易混淆的问题梳理出来，目的是：让更多的后来人看到，不要再走一遍弯路。

相信经过几天梳理的实战文档，能给你带来帮助！感谢您的反馈和交流。

推荐阅读：

1、百亿级日志系统架构设计及优化 http://t.cn/RsGCUGs 

2.探讨理想的Elasticsearch索引设计原则。http://t.cn/Rusfb0U

公众号：铭毅天下 

博客：elastic.blog.csdn.net

更短时间更快习得更多干货！

1.概述

在进行数据传输中，批量加载数据到HBase集群有多种方式，比如通过HBase API进行批量写入数据、使用Sqoop工具批量导数到HBase集群、使用MapReduce批量导入等。这些方式，在导入数据的过程中，如果数据量过大，可能耗时会比较严重或者占用HBase集群资源较多（如磁盘IO、HBase Handler数等）。今天这篇博客笔者将为大家分享使用HBase BulkLoad的方式来进行海量数据批量写入到HBase集群。

2.内容

在使用BulkLoad之前，我们先来了解一下HBase的存储机制。HBase存储数据其底层使用的是HDFS来作为存储介质，HBase的每一张表对应的HDFS目录上的一个文件夹，文件夹名以HBase表进行命名（如果没有使用命名空间，则默认在default目录下），在表文件夹下存放在若干个Region命名的文件夹，Region文件夹中的每个列簇也是用文件夹进行存储的，每个列簇中存储就是实际的数据，以HFile的形式存在。路径格式如下：

/hbase/data/default/<tbl_name>/<region_id>/<cf>/<hfile_id>

2.1 实现原理

按照HBase存储数据按照HFile格式存储在HDFS的原理，使用MapReduce直接生成HFile格式的数据文件，然后在通过RegionServer将HFile数据文件移动到相应的Region上去。流程如下图所示：

2.2. 生成HFile文件

HFile文件的生成，可以使用MapReduce来进行实现，将数据源准备好，上传到HDFS进行存储，然后在程序中读取HDFS上的数据源，进行自定义封装，组装RowKey，然后将封装后的数据在回写到HDFS上，以HFile的形式存储到HDFS指定的目录中。实现代码如下：

/**
 * Read DataSource from hdfs & Gemerator hfile.
 * 
 * @author smartloli.
 *
 *         Created by Aug 19, 2018
 */
public class GemeratorHFile2 {
    static class HFileImportMapper2 extends Mapper<LongWritable, Text, ImmutableBytesWritable, KeyValue> {
        protected final String CF_KQ = "cf";

        @Override
        protected void map(LongWritable key, Text value, Context context) throws IOException, InterruptedException {
            String line = value.toString();
            System.out.println("line : " + line);
            String[] datas = line.split(" ");
            String row = new Date().getTime() + "_" + datas[1];
            ImmutableBytesWritable rowkey = new ImmutableBytesWritable(Bytes.toBytes(row));
            KeyValue kv = new KeyValue(Bytes.toBytes(row), this.CF_KQ.getBytes(), datas[1].getBytes(), datas[2].getBytes());
            context.write(rowkey, kv);
        }
    }

    public static void main(String[] args) {
        if (args.length != 1) {
            System.out.println("<Usage>Please input hbase-site.xml path.</Usage>");
            return;
        }
        Configuration conf = new Configuration();
        conf.addResource(new Path(args[0]));
        conf.set("hbase.fs.tmp.dir", "partitions_" + UUID.randomUUID());
        String tableName = "person";
        String input = "hdfs://nna:9000/tmp/person.txt";
        String output = "hdfs://nna:9000/tmp/pres";
        System.out.println("table : " + tableName);
        HTable table;
        try {
            try {
                FileSystem fs = FileSystem.get(URI.create(output), conf);
                fs.delete(new Path(output), true);
                fs.close();
            } catch (IOException e1) {
                e1.printStackTrace();
            }

            Connection conn = ConnectionFactory.createConnection(conf);
            table = (HTable) conn.getTable(TableName.valueOf(tableName));
            Job job = Job.getInstance(conf);
            job.setJobName("Generate HFile");

            job.setJarByClass(GemeratorHFile2.class);
            job.setInputFormatClass(TextInputFormat.class);
            job.setMapperClass(HFileImportMapper2.class);
            FileInputFormat.setInputPaths(job, input);
            FileOutputFormat.setOutputPath(job, new Path(output));

            HFileOutputFormat2.configureIncrementalLoad(job, table);
            try {
                job.waitForCompletion(true);
            } catch (InterruptedException e) {
                e.printStackTrace();
            } catch (ClassNotFoundException e) {
                e.printStackTrace();
            }
        } catch (Exception e) {
            e.printStackTrace();
        }

    }
}

在HDFS目录/tmp/person.txt中，准备数据源如下：

1 smartloli 100
2 smartloli2 101
3 smartloli3 102

然后，将上述代码编译打包成jar，上传到Hadoop集群进行执行，执行命令如下：

hadoop jar GemeratorHFile2.jar /data/soft/new/apps/hbaseapp/hbase-site.xml

如果在执行命令的过程中，出现找不到类的异常信息，可能是本地没有加载HBase依赖JAR包，在当前用户中配置如下环境变量信息：

export HADOOP_CLASSPATH=$HBASE_HOME/lib/*:classpath

然后，执行source命令使配置的内容立即生生效。

2.3. 执行预览

在成功提交任务后，Linux控制台会打印执行任务进度，也可以到YARN的资源监控界面查看执行进度，结果如下所示：

等待任务的执行，执行完成后，在对应HDFS路径上会生成相应的HFile数据文件，如下图所示：

2.4 使用BulkLoad导入到HBase

然后，在使用BulkLoad的方式将生成的HFile文件导入到HBase集群中，这里有2种方式。一种是写代码实现导入，另一种是使用HBase命令进行导入。

2.4.1 代码实现导入

通过LoadIncrementalHFiles类来实现导入，具体代码如下：

/**
* Use BulkLoad inport hfile from hdfs to hbase.
* 
* @author smartloli.
*
* Created by Aug 19, 2018
*/
public class BulkLoad2HBase {

    public static void main(String[] args) throws Exception {
        if (args.length != 1) {
            System.out.println("<Usage>Please input hbase-site.xml path.</Usage>");
            return;
        }
        String output = "hdfs://cluster1/tmp/pres";
        Configuration conf = new Configuration();
        conf.addResource(new Path(args[0]));
        HTable table = new HTable(conf, "person");
        LoadIncrementalHFiles loader = new LoadIncrementalHFiles(conf);
        loader.doBulkLoad(new Path(output), table);
    }
}

执行上述代码，运行结果如下：

2.4.2 使用HBase命令进行导入

先将生成好的HFile文件迁移到目标集群（即HBase集群所在的HDFS上），然后在使用HBase命令进行导入，执行命令如下：

# 先使用distcp迁移hfile
hadoop distcp -Dmapreduce.job.queuename=queue_1024_01 -update -skipcrccheck -m 10 /tmp/pres hdfs://nns:9000/tmp/pres

# 使用bulkload方式导入数据
hbase org.apache.hadoop.hbase.mapreduce.LoadIncrementalHFiles /tmp/pres person

最后，我们可以到指定的RegionServer节点上查看导入的日志信息，如下所示为导入成功的日志信息：

2018-08-19 16:30:34,969 INFO  [B.defaultRpcServer.handler=7,queue=1,port=16020] regionserver.HStore: Successfully loaded store file hdfs://cluster1/tmp/pres/cf/7b455535f660444695589edf509935e9 into store cf (new location: hdfs://cluster1/hbase/data/default/person/2d7483d4abd6d20acdf16533a3fdf18f/cf/d72c8846327d42e2a00780ac2facf95b_SeqId_4_)

2.5 验证

使用BulkLoad方式导入数据后，可以进入到HBase集群，使用HBase Shell来查看数据是否导入成功，预览结果如下：

3.总结

本篇博客为了演示实战效果，将生成HFile文件和使用BulkLoad方式导入HFile到HBase集群的步骤进行了分解，实际情况中，可以将这两个步骤合并为一个，实现自动化生成与HFile自动导入。如果在执行的过程中出现RpcRetryingCaller的异常，可以到对应RegionServer节点查看日志信息，这里面记录了出现这种异常的详细原因。

4.结束语

这篇博客就和大家分享到这里，如果大家在研究学习的过程当中有什么问题，可以加群进行讨论或发送邮件给我，我会尽我所能为您解答，与君共勉！