网络词汇
“一阵笑声……我问妈妈介意网络术语吗？我觉得大人和孩子的想法不同，他们不会认识网络术语。我以前看过一篇大人写的文章，作者拒绝了互联网术语。我觉得不如中文深奥，而且我也不提倡用互联网词汇。我觉得这是作者个人的想法，每个人的想法不同。年纪大的人不喜欢创新，而是认为网络词汇很非正式，谎言很多，是观念问题，固执，保守，不习惯改变，年轻人恰恰相反，喜欢创新，喜欢改变，喜欢简单，而这正是有了这些想法，网络词汇就会不断出现、不断完善，并逐渐深入人心。前几天，我在晚报上看到一篇关于网络词汇的报道。我认为新颖性和独特性是网络词汇的巨大优势之一。
现在流行“超级女声”，我的家人也很关注她们。 我第一次看的时候，妈妈问我“PK”是什么意思。 我回答：“这是一个网络术语，几乎就是决斗的意思，在网络游戏中用得很多。” 然后我就笑她落伍了。 妈妈语气悠然地说）！ “一阵笑声……我问妈妈介意网络术语吗？我觉得大人和孩子的想法不同，他们不会认识网络术语。我以前看过一篇大人写的文章，作者拒绝了互联网术语。我觉得不如中文深奥，而且我也不提倡用互联网词汇。我觉得这是作者个人的想法，每个人的想法不同。年纪大的人不喜欢创新，而是认为网络词汇很非正式，谎言很多，是观念问题，固执，保守，不习惯改变，年轻人恰恰相反，喜欢创新，喜欢改变，喜欢简单，而这正是有了这些想法，网络词汇就会不断出现、不断完善，并逐渐深入人心。
我妈妈说她不排斥网络俚语。 很多中文单词最初都是由外来词音译而来的，比如“咖啡”、“沙发”等，现在不是还被人们所接受吗？ 外来词是丰富汉语词汇的重要途径。 人们也喜欢简单的词汇，网络词汇新颖、幽默。 这类词汇应该在不久的将来慢慢融入汉语，逐渐被人们认可。
前几天，我在晚报上看到一篇关于网络词汇的报道。 同样是“玉米”、“粉丝”、“小可爱”。 专家们知道它们的新含义，但老母亲却不知道。 有人担心这些词语造成交流障碍，汉语的纯洁性受到挑战，应立法规范。 我认为这就像适者生存。 网络词汇如果不好，自然会被人们遗忘、淘汰。 相反，有些词朗朗上口，人们逐渐习惯并取代了原来的词。
报道称，“干部”和“逻辑”这两个词现在是汉语基本词汇，但事实上，“干部”是从日本借用的，“逻辑”是一个英文单词的音译。 它们不但没有污染汉语的纯洁性，反而丰富了汉语的词汇； 在经历了语言的大浪潮之后，它们并没有被淘汰，而是在汉语词汇大家族中变得“朗朗上口”。 那时的人们能够接受外来词。 现在为什么不呢？
我认为新颖性和独特性是网络词汇的巨大优势之一。 很快人们就会接受它。
本文转载自| 快手星球作者| 钟良
1.Hadoop上的SQL简介
SQL on Hadoop，顾名思义，是基于Hadoop生态系统的SQL引擎架构。 事实上，我们经常听说 Hive、SparkSQL、Presto 和 Impala 架构。 接下来我简单介绍一下常用的架构。
1.蜂巢
HIVE，一个数据仓库系统。 它将数据结构映射到存储数据，并通过SQL读取、写入和管理大规模分布式存储数据。
根据定义的数据模式和输出存储，对输入的SQL进行编译和优化，生成与引擎对应的任务，然后调度和执行生成的任务。
HIVE目前支持的引擎类型有：MR、SPARK、TEZ。
基于HIVE自身的架构，还有一些额外的服务提供方式。 例如，HiveServer2和MetaStoreServer都是Thrift架构。
另外，HiveServer2提供了远程客户端提交SQL任务的功能，MetaStoreServer提供了远程客户端操作元数据的功能。
2. 火花
Spark是一个快速、易用的统一分析引擎，以DAG为执行模式进行大规模数据处理。 主要模块分为SQL引擎、流处理、机器学习、图处理。
3.SPARKSQL
SPARKSQL基于SPARK的计算引擎，实现统一的数据访问，集成Hive，支持标准的JDBC连接。 SPARKSQL常用于数据交互分析场景。
SPARKSQL的主要执行逻辑是首先将SQL解析成语法树，然后进行语义分析生成逻辑执行计划，然后与元数据交互优化逻辑执行计划，最后将逻辑执行转换为物理执行计划，即 RDD 谱系 ，并执行任务。
4.急速
PRESTO，一个用于交互式分析查询的开源分布式 SQL 查询引擎。
由于是基于内存计算，因此PRESTO的计算性能大于有大量IO操作的MR和SPARK引擎。 具有易于弹性扩展的特点，支持可插拔连接。
业界有很多用例，包括FaceBook、AirBnb、美团等，都在大规模使用。
5、其他行业解决方案
我们看到了这么多SQL on Hadoop架构，这说明这个架构更加实用和成熟。 使用SQL on Hadoop架构，可以满足我们支持海量数据处理的需求。
2. 快手SQL on Hadoop平台概述
1、平台规模
查询平台日总SQL量在70万条左右，日总DQL量在18万条左右。 AdHoc集群主要用于交互式分析和机器查询。 平均DQL时间为300s； AdHoc内部有Loacl任务和加速引擎应用，所以查询要求相对较低。
ETL集群主要用于ETL处理和报告生成。 DQL平均耗时1000秒，DQL P50平均耗时100秒，DQL P90平均耗时4000秒。 除了以上两个集群外，其他小集群主要用于个体业务。
2、服务水平
服务层适用于上层。 上层有四个模块，包括同步服务、ETL平台、AdHoc平台和用户程序。
在调度的上层，还有四个方面的数据，比如服务器日志。 处理完之后会直接连接到HDFS，稍后我们会进行清理； 服务管理数据和数据库信息，然后会通过同步服务录入对应的数据源，我们将元数据信息存储在后端元数据系统中。
从网络上爬取的数据将存储在HBase中，并在稍后进行清洗和处理。
3. 平台组件说明
HUE和NoteBook主要提供交互式查询系统。 报表系统和BI系统主要用于ETL处理和通用报表生成，附加元数据系统用于对外服务。 快手目前的引擎支持MR、Presto和Spark。
管理系统主要是用来管理我们当前的集群的。 HiveServer2集群路由系统主要用于引擎选择。 监控系统和运维系统主要对HiveServer2引擎进行操作和维护。
我们在使用HiveServer2的过程中遇到了很多问题。 接下来我会详细讲解快手是如何优化和实践的。
3、快手SQL on Hadoop的实践背景
1.HiveServer2多集群架构
目前有多个HiveServer2集群，即AdHoc和ETL集群，以及其他小型集群。 不同的集群有对应的连接ZK，客户端可以通过ZK连接到HiveServer2集群。
为了保证核心任务的稳定性，ETL集群分为核心集群和通用集群。 当客户端连接到HS2时，我们将确定任务优先级。 高优先级任务将被路由到核心集群，低优先级任务将被路由到通用集群。
2、HiveServer2服务内部流程图
3.BeaconServer服务
BeaconServer服务是后端Hook Server服务，与HS2中的Hook配合，实现HS2服务之外所需的功能。 目前支持的模块包括路由、审计、SQL重写、任务控制、错误分析、优化建议等。
BeaconServer服务无状态，支持水平扩展。 根据请求的大小，可以灵活调整服务规模。
动态配置加载，BeaconServer服务支持动态配置加载。 各模块均支持交换机，业务可动态加载、配置上下线。 例如，路由模块可以根据后端加速引擎集群的资源状况调整路由比例甚至熔断。
无缝升级，BeaconServer服务后端模块可独立离线升级，不影响Hook端HS2服务。
4.实践中遇到的痛点分析及改进
1. 高性能
1）使用新发动机加速时面临的问题
2）智能发动机解决方案
3）智能发动机：主流发动机方案对比
4）智能引擎：HiveServer2自定义执行引擎的模块设计
基于HiveServer2，有两种实现方式。 JDBC方式是通过JDBC接口向后端加速引擎启动的集群发送SQL。 PROXY方式是将SQL下推到本地加速引擎启动的客户端。
JDBC方式启动的后端集群都是基于YARN的，可以实现资源的分时复用。 例如，AdHoc集群的资源在夜间自动回收，重新用作报表系统的资源。
5）智能引擎：SQL路由方案设计架构
该路由方案基于HS2的Hook架构。 HS2侧实现了相应的Hook，用于引擎切换； 路由服务在后端BeaconServer服务中实现，用于SQL路由规则的匹配处理。 不同的集群可以配置不同的路由规则。
为了保证计算后路由服务的稳定性，团队还设计了Rewrite Hook，用于重写AdHoc集群中的SQL，并自动添加LIMIT上限，防止大数据量的SCAN。
6）智能引擎：SQL路由规则列表
7）智能引擎：方案优势
① 易于集成，目前主流的SQL引擎都可以轻松实现JDBC和PROXY方式。 通过配置，可以轻松集成新的查询引擎，例如impala、drill等。
② 自动引擎选择，降低了用户的引擎使用成本，也让迁移变得更容易。 并且当加速引擎过载时，可以动态调整该比例，防止过载对加速性能的影响。
③自动降级，保证运行可靠性。 SQL 路由支持故障恢复模块。 您可以根据配置选择路由引擎执行失败后是否回滚到MR。
④模块复用。 对于新增加的引擎，HiveServer2定制的血统采集、权限认证、并发锁控制等方案可以复用，大大降低了使用成本。
⑤资源复用，即席查询占用的资源可以及时动态调整，有效保证集群资源的利用率。
8）智能引擎DQL应用效果
9）HiveServer2中的性能问题
10）FetchTask加速：预排序和逻辑优化
当查询完成后，本机会轮询结果文件，直到获得LIMIT大小，然后返回。 这样的话，当后端有大量小文件、大文件时，会造成bad case，不断与HDFS交互获取文件信息和文件数据，大大拉长运行时间。
在 Fetch 之前对结果文件的大小进行预排序可以将性能提高数百倍。
示例：当前有 200 个文件。 有199个小文件，1条记录a，1个大文件，混合记录a和test，共200条记录。 大文件名在小文件之后索引。
Hive中有一个SimpleFetchOptimizer优化器，它会直接生成FetchTask，以减少资源申请时间和调度时间。 但这种优化会存在瓶颈。 如果数据量较小，但文件数量较多，需要返回的项较多，则有Filter条件可以过滤掉大量的结果数据。 此时输入文件是串行读取的，导致查询延迟较大，但没有加速效果。
在SimpleFetchOptimizer优化器中，新增了文件数的判断条件，最后将任务提交到集群环境，通过增加并发来实现加速。
示例：读取当前分区的500个文件。 优化后的文件数阈值为100。
11) 大表的描述表优化
如果一个表有大量的子分区，其DESC过程将与元数据交互以获取所有分区。 但最终返回的结果只包含与表相关的信息。
在与元数据交互时，整个DESC查询会出现延迟，元数据压力大时甚至无法返回结果。
对于TABLE的DESC过程，直接省去了与元数据交互获取分区的过程，加速时间与子分区数量成正比。
示例：desc 一个包含 100,000 个分区的大表。
12）其他改进
2、高可用
1）快手使用的SQL on Hadoop：常见可用性问题
2）HiveServer2服务启动优化
HS2启动时会初始化物化视图函数并轮询整个元数据数据库，导致HS2的启动时间非常长。 下线到重新上线的时间间隔太长，可用性很差。
将物化视图功能修改为延迟加载和单独线程加载，不影响HS2的服务启动。 物化视图支持在加载时获取缓存信息，保证功能的可用性。
HS2 启动时间从 5 分钟以上增加到
3）HiveServer2配置热加载
HS2本身线上线下成本较高，需要保证服务上的所有任务都完成后才能运营。 配置修改可以作为更高频率的操作来执行，并且需要热加载。
我们为 HS2 的 ThriftServer 层添加了一个接口。 与运维系统连接后，在配置下推更新时会自动调用，从而使配置的热重载生效。
4）HiveServer2的Scratchdir优化
HiveServer2的scratchdir主要用于运行时的临时文件存储。 HS2 中的会话创建时会创建暂存目录。 当HDFS压力较大时，在scratchdir创建过程中会阻塞大量会话，导致连接数累积到上限。 最终，HS2 服务将无法再连接到新连接，从而影响服务可用性。
对此，我们首先将普通查询和创建临时表查询的scratch目录分开，并支持创建临时表查询的scratch的延迟创建。 当create temporay table创建大量临时文件时，会影响HDFS NameNode延迟时间，一般查询scratchdir HDFS NameNode可以正常响应。
此外，HS2还支持多重划痕的配置。 不同的scratch可以设置加载比例，实现HDFS的负载均衡。
5）Hive Stage并发调度异常修复
Hive调度存在两个问题。
1）当子任务处于非执行状态完成后，如果有多轮父任务包含该子任务，则该子任务会重复加入调度队列。 此时需要将非执行状态修改为初始化状态。
2）在判断子任务是否可执行的过程中，由于状态检测异常，导致需要调度的子任务无法正常添加，导致查询丢失stage。 对于这种情况，我们的做法是在执行完成后添加一轮阶段执行结果状态检查。 一旦发现下游阶段尚未完成，则直接抛出错误，实现查询结果状态的完整性检查。
6）其他改进
3. 易于使用
1）为什么要开发SQL专家系统？
2）SQL专家系统
SQL专家系统基于HS2的Hook架构，在BeaconServer后端实现了三个主要模块，即SQL规则控制模块、SQL错误分析模块和SQL优化建议模块。 SQL专家系统的知识库包含关键字、原因解释、处理方案等几大信息。 存储在后台数据库中，并已累计。
通过SQL专家系统，后端可以控制查询SQL的异常，避免异常SQL浪费资源或影响集群的稳定性。 当用户遇到问题时，可以直接获取问题的解决方案，降低使用成本。
示例：空分区查询控件。
3）作业诊断系统
SQL专家系统可以解决HS2任务执行的部分错误诊断需求，但是作业健康度、任务执行异常等问题原因的判断需要专门的系统来解决。 为此，我们设计了一个工作诊断系统。
在YARN级别，作业诊断系统分析收集到的不同执行引擎的计数器和配置。 在执行层面，提出了相关的优化建议。
作业诊断系统的数据也可以通过API提供给SQL专家系统，补充问题原因进行分析。
作业诊断系统提供查询页面来查询正在运行的任务。 以下是map输入命中过多规则的任务查询流程：
