一、常见目录介绍以及查找
1. Linux中软件、硬件、文档都属于文件
/bin ：系统启动时需要执行的文件（二进制）
/dev ：设备文件目录
/etc ：操作系统配置文件目录（防火墙、启动项）
/home ： 用户信息存放目录、用户默认的工作目录
/usr ：程序和数据存放目录
/var ：包含在正常操作中被改变的文件：假脱机文件、记录文件、 加锁文件、临时文件和页格式化文件等
2. 常见目录以及用处
切目录：cd 目录—分绝对路径（以斜杠开头）和相对路径（当前目录下就能找到的用相对路径 …/表示返回上一级
ps：cd与目录之间有空格，若只写cd 则回切到当前用户的家目录

run ：运行中的启动项、配置项、日志等
sys ： 系统硬件之类的
获取当前位置的绝对路径：pwd
4、查看当前目录下的内容 —相关操作

ls -a 所有文件–包括隐藏文件
ls -l 除文件名称外，会将文件型态、权限、文件大小等信息展示
注：效果同ll查看当前目录下的文件
新建文件夹：mkdir 目录路径（绝-相） 不加/是新建在当前目录下
删除文件夹：rmdir
ps：无法删除有有文件或目录的文件夹
修改文件： mv 原路径 新路径 ps:只针对位置(路径) --类给文件重命名
新建文件 touch 文件路径 不加-是当前目录下建 （规则同文件夹的创建）
删除文件 rm 文件路径
ps:强制删除文件或目录：rm -rf 目录或文件
修改文件： mv 原路径 新路径–类似修改文件名
复制文件 cp 原路径+复制的文件 新路径
vi 文件名–>进入编辑模式（见vi模块）
head -n 文件名 从头部查看文件 n行数据
ctrl+b 向上翻页 空格向下翻页 不带缓冲区，一次性加载全部。
less: 有缓存区，显示多少加载多少； 搜索与vi编辑器类似、回车：向后一行、y向前一行、o<其他文件>把加载的文件内容输出到其他文件中。
管道符（|）：前面的命令|后面的命令 把前面的命令的执行结果作为后面命令的输入。

包含：查看模式 编辑模式 、尾行模式

1. vi 文件名 进入文件编辑（查看模式）
2. 由查看模式进入编辑模式
   （1）a 在光标后面插入 A 在光标所在行的行末插入
   （2）i 在光标所在位置插入 I在光标所在行的行首插入
   （3）o 在光标所在行新建下行并插入、O 在光标所在行上行新建插入
3. 退出查看模式：Esc键
4. 由查看模式进入尾行模式 输入：（英文模式）
   （1）w 保存 、q退出、q！强制退出（不保存）、wq保存并退出（wq等同x）ngg跳到第n行-从文档首行开始计算
   n+回车 直接跳转到第n行-从当前行往下找n行
5. 复制粘贴（查看模式下进行）
   （1）单行复制 yy 粘贴 p
   （2）多行复制 nyy（当前行数n行复制）
   
6. 删除（查看模式下进行）
   (3) 剪切：删除后想粘贴的地方 按 p进行粘贴
7. 重复上一个动作 ：查看模式: 按 .
8. x 当前光标后面的删除
   （1）：set nu 显示所有行号
   （2）查找： /字符串 向下查找 ？字符串 向上查找 n下一个 N上一个ps：n,ms表示第n行到第m行，s代表替换。g表示范围内替换所有。（如果不加g，只会替换查找范围内的第一个old）
   ps：%表示查找范围是整篇文档。
   ps：^正则表达式表示行首，把行首变成#。
   ps：^#意思是把行首的#去掉。正则表达式是包含匹配，如果只写#，表示n到m行所有的#都去掉。

（1）增加用户 创建用户：useradd 用户名 只能在root目录下建立
（2）切换用户 su 用户名
修改用户登陆名：usermod -l 新用户名 旧用户名
修改用户所属分组：usermod -g 新组名称 用户名 (-g 是组的意思)

1: 首位 -代表文件 d代表目录 .代表结束
ps:有代表1 无代表0 rwx等同于111 -wx等同于011 rw-等同于110 (二进制),使用时用的每个代表的十进制的数
第二组rwx所在组的其他用户（g）的权限
第三组rwx其他组的用户(o)权限
3: 给用户减少执行的权限
ps:4其他组的用户只有读的权限没有写和执行的权限
5: 改变文件或用户的从属 chown 用户名：组名 文件名或目录名(中间有空格)

PS: 需要注意各个命令中间的空格

摘要：本文由网易 Java 技术专家吴良波分享，主要内容为 Apache Flink 在网易的实践，文章提纲如下：

在很久以前，网易内部基本上都是使用 Storm 来处理实时的计算任务，比较主要的使用场景是实时邮件反垃圾，广告，新闻推荐等业务。如今内部仍有一部分任务是运行在 Storm 上，目前正往 Flink 上迁移。

• 16 年左右 Flink 社区在网络上逐渐开始火起来，网易这边开始调研 Flink，发现 Flink 具有很多优秀的特性，比如高吞吐、低延迟、支持 Checkpoint、支持 Exactly once 语义，支持 Event time 等，能够很好的满足业务实时计算的场景，因此很多项目开始使用 Flink 来作为流计算的引擎来搭建流计算平台。

• 在 2017 年 2 月份，网易杭州研究院成立了一个代号为 Sloth 的项目，基于 SQL 的实时计算平台，底层计算引擎采用 Apache Flink。

但是这套系统做的并不是很成功，一方面是因为平台化，产品化做的不是很到位，用户使用起来不是很方便，SLA 也没有得到很好的保障。另一方面对 Flink 底层的代码改动较大，导致后面跟不上社区的节奏。于是在今年年初对系统进行重新改造，重新拥抱社区，在 SQL 方面采用了阿里巴巴年初新开源的 Blink，使用 Blink 来提交 SQL 任务，同时支持用户直接写 JAVA 代码来提交流计算任务，方便那些有开发能力的同学开发 Flink 任务。

网易杭研在做流计算平台的同时，公司一些大的业务方也在开发自己的流计算平台，这样一来就造成了公司很大的资源和人力上的浪费。为了整合公司资源，以及应对各个业务不断增长的实时计算任务的需求，决定和各个业务方一起共建分布式的实时计算平台，将业务方的任务全部迁移到新的分布式实时计算平台上，杭研负责底层平台和接口的研发与维护，业务方则更加关注业务本身。

目前网易流计算规模已经达到了一千多个任务，2 万多个 vcores 以及 80 多 T 的内存。

目前网易流计算覆盖了绝大多数场景，包括广告、电商大屏、ETL、数据分析、推荐、风控、搜索、直播等。

在 2017 年初的时候,因为当时社区版本的 Flink 对于 SQL 的支持不是很完善，所以 Sloth 平台自定义了 SQL 规范，自己实现了 DDL 等。但当时这个平台的架构存在很多问题，特别是版本升级的时候，代码迁移等的工作量非常大，运维起来也非常困难。另外当时实时计算只是作为离线计算平台的一个功能模块，因此 Sloth 的前端是和离线平台绑定在一起的，实时计算模块前端每次升级发布都需要和离线计算平台一起，非常不方便。

在 Sloth 的 1.0 版本中，Flink 版本实现了插件化管理，每次 Flink 升级的时候就不需要进行复杂的代码合并工作了，这一点主要通过父子进程架构来实现的。此外，Sloth 1.0 版本的运维方便了许多，并且也支持 jar 包任务开发，用户可以直接通过 Stream API 来写流计算任务。Sloth 的 1.0 版本还支持了阿里巴巴开源的 Blink SQL，并且在监控方面还接入了 Grafana，任务 metrics 存储则使用了网易自研的时序数据库 Ntsdb。

在 Sloth 的 2.0 版本中，实现了平台的 PaaS 化以及平台的高可用。Sloth 平台提供对外的平台 API，Sloth 开发了一套独立部署的前端界面，同时业务方也可以开发跟自己业务更为紧密的前端界面，通过平台的 API 来提交任务以及后续的任务运维等等。

以前的计算平台都是单点的，都是部署在同一台服务器，一旦服务器出了故障，整个平台就挂了，所以 Sloth 2.0 设计成分布式的，可以部署多个 Server，使用 Nginx 作为负载均衡器，来达到系统的高可用。同时支持了更多的 Flink 版本，因为各个业务以前用的版本都可能不一样，为了将任务直接迁移过来，需要支持这些历史的版本，所以平台支持了 Flink

下图所示是 Sloth 的模块图。在 Web 端，业务方可以搭建自己的任务管控平台 Web，业务方所需要的前端平台可能和公用 Sloth 的前端平台不同，业务方内部还包括各种不同的部门，他们需要对于各个部门的用户权限进行控制等。Sloth-Server 模块，包括用户的权限管理，会话管理，任务开发，元数据管理，任务运维，标签管理，内核调度，文件管理。Sloth-Bill 模块主要是对资源以及用量的统计，Sloth-admin 模块包括监控，报警，任务恢复，以及任务诊断。Sloth-Kernel 模块负责任务执行、语法检测以及 SQL 调试。

对于分布式平台的任务操作而言，当前任务只允许一个人操作，而不允许两个人同时操作，这就需要以下几个模块来共同配合：

• Server：事件执行的发起者，接受事件的请求，进行数据校验，拼装，将事件发送给 Kernel 执行。

• Kernel：事件具体逻辑的执行者，根据请求向集群发送指令(Shell 脚本方式)。

• Admin：事件执行结果的确认者，根据事件类型，获取事件的最终结果，保证结果的正确性。

• 首先，Server 会接收到来自用户的启动请求，之后会创建一个分布式锁，Admin 会监控这个锁。

• 然后， Server 向 Kernel 提交任务，提交之后会立即返回，返回之后就会立即更新数据库中的状态，将状态更新为启动中，这样在页面上用户就能够看到任务是启动中的状态了。

• 上的任务状态，如果获取到任务状态是运行中，就将数据库的任务状态更新为运行中，这会在前端看到任务就已经是运行状态了。

• 最后一步是 Admin 更为完数据库之后，会释放掉 Zookeeper 上的锁，其他人这时候就可以操作这个任务了。

Server、Kernel 和 Admin 这三个模块都是不可靠的，那么如何保证其稳定和高可用呢？Server 可以通过部署多个，水平扩展来实现，Kernel 则会由 Server 来进行监听，当发现 Kernel 挂了，可以由 Server 重新拉起或者重新创建。而 Admin 的高可用则是通过热备来实现的，如果主 Admin 挂掉了，可以马上迁移到备 Admin，备 Admin 可以迅速将元数据以及任务信息全部加载进来接替工作，进而实现高可用。

对于内核调度而言，是基于父子进程的架构实现的。Server 会通过 Sloth RPC 启动不同的 kernel 子进程，分为常驻子进程模式和临时子进程模式。常驻子进程负责处理启动，停止，语法检查，表结构解析，获取提交结果的请求，临时子进程是用于 SQL 的 Debug 的，当调试完成需要将这个子进程关闭掉，将资源进行回收。内核通过子进程来实现的好处在于当 Kernel 挂掉的时候，Server 可以通过监听自动拉起来。

平台的任务状态主要由 Server 和 Admin 来控制。Server 主要控制初始状态的执行，Admin 则主要负责控制所有与 YARN 相关的状态交互。

任务开发的界面支持的功能主要有：任务调试、任务 Tab 页、语法检查、任务标签、元数据管理、用户资源文件管理以及任务复制等。

SQL 类型的任务支持调试功能，用户可以根据不同的 source 表和 dim 表，上传不同的 csv 文件作为输入数据，进行调试。调试执行由指定的 kernel 来完成，sloth-server 负责组装请求，调用 kernel，返回结果，搜集日志。

在 YARN 集群的每个节点上面部署 Filebeat，通过 Filebeat 将节点上面的任务日志写入到 Kafka 消息队列中，然后通过 Logstash 进行解析处理，之后写入 ES 集群中。主要用于两个用途，一个是通过界面 Kibana 来提供给开发和运维人员使用，另外一个就是将运行时状态的任务日志直接在界面上展示供用户进行搜索和查看。

在监控方面，使用的是 influxdb metric report 组件对于指标进行监控。时序数据库使用的是网易自研的 ntsdb 时序数据库，其能够支持动态扩展和高可用等功能。监控指标的使用方式有两种：

• 一种是通过 Grafana 的界面来查看指标；

• 另外一种是报警模块会从Ntsdb中获取相关指标数据并进行监控报警。

Sloth 流计算平台支持常见的任务失败，数据滞留延迟，failover 报警，也支持用户自定义规则报警，包括对于输入 QPS、输出 QPS，户自定义延迟的监控等。以输入 QPS 为例，可以设置当连续几个周期内 QPS 低于某一值时就触发报警。此外，报警方式也支持多样化的工具，比如各种网易内部的聊天工具、邮件、电话以及短信等，对于任务调试阶段，为了避免被骚扰，可以设置任务报警抑制时间间隔。

AI 智能对话服务场景中，客户在前端配置知识库数据，通过 Sloth 实时处理后，写入到 ES 中供查询场景使用。

目前网易很多产品已经开始实时数仓的建设了，但仍旧处于持续完善过程中。实时数仓的建设和离线数仓大致相同，只不过实时数仓是经过实时计算平台进行处理的。大致的过程就是首先收集日志、埋点数据等，将其写入到 Kafka 里面，经过实时计算平台进行处理，将 ODS 层中的明细数据抽取出来，在进行汇总以及维度关联等操作，将结果写入到 Redis，Kudu 等，再通过数据服务提供给前端的业务使用。

电商的数据分析场景主要包括实时活动分析、首页资源分析、流量漏斗以及实时毛利计算等。简要的逻辑就是从 Hubble 收集用户的访问日志推动到 Kafka，使用 Sloth 清洗出明细层，写入 Kafka，再用 Sloth 任务，关联维度，实时写入 Kudu，落入 Kudu 表的数据，一方面可以提供给业务方使用，分析师可以开发实时查询；另外一方面，可以在这个实例的 Kudu 表上面，提供给数据应用。

电商的搜索推荐场景则主要包括用户实时足迹、用户实时特征、商品实时特征、实时 CTR CVR 样本组建、首页 A 区轮播、B 区活动精选等 UV、PV 实时统计等。简要的逻辑就是使用 Sloth 读取应用日志，进行数据清洗和维度拆分，写入 Kafka，再使用 Sloth 读取 Kafka 的数据，实时统计多维特征，实时统计多维特征 5min、30min、1 小时的 PV 和 UV，写入 Redis，供线上工程计算 CTR、CVR 以及优化搜索和推荐结果。

网易在流计算方面对于未来发展的思考主要包括以下五点：

1. 任务的自动配置功能，平台能根据业务类型，流量自动配置内存，并发度等，既保证业务 SLA，也能提升计算集群的资源利用率。

2. 智能诊断，对 UDF 以及代码构建的流计算任务，调试成本高，运行出错让业务和平台方疲于奔命，智能诊断是流计算平台根据任务的各种 Metric 信息，直指问题所在，减少业务和平台定位问题的时间，对于存在风险的任务，可以提前给出预警，并对调优给出建议。

3. 更多地参与到社区中去。

作者介绍：吴良波，网易 JAVA 技术专家，2011 年加入网易后从事 JAVA 后台系统的研发，如网易邮件反垃圾系统，网易分布式云爬虫系统等，目前负责网易实时计算平台的研发。