本文参考InfoQ记者采访快手高级架构师，架构团队负责人赵建博的采访实录。

前言

快手大数据架构团队成立于2017年。
短短三年内就已经完成了一个万亿级规模的大数据架构体系，同时还完成了春晚红包活动。
在Hadoop的应用上，快手又有那些亮点？

问题1

能否详细给我们介绍一下快手大数据架构的发展历程，目前各个关键部分的技术选型是什么?出于什么目的？

出于目的和成本的考虑，快手的大数据架构服务大部分是使用开源系统构建的。
截止到目前为止，快手的大数据架构的发展大致分为三个阶段。

• 从0到1的建设
  初期，快手大数据架构服务主要以离线分析场景为主。
  基础选择了当时的最佳解决方案--Hadoop，版本是CDH Hadoop2.6。原因是这个版本是稳定版本，以可靠性和稳定性出发。
  重度依赖kafka，原因是当时的业务（除了离线日志收集外，还有在线消息队列和cache同步）同时还有在业内已经有大厂（LinkedIn）的实践。核心问题是kafka集群的扩容问题，要做到扩容对业务无影响。
  

  解决方案架构
  2018 上半年，大数据架构服务开始延伸到实时计算以及交互式分析场景。
  对于实时计算，快手选择了Fink。主要是因为 Fink 完全是原生的实时计算引擎，相比于 Storm，有着丰富实时语义的实现、窗口抽象、状态存储等能力，为开发者提供了非常多便利的工具。相比于 Spark，Flink 的实时性更好。
  对于 OLAP 分析需求，快手采用 Druid 引擎，并且配套了轻量级BI工具--- Superset 。
  没有选择kylin的主要的原因是 Druid 有着更好的实时性、更多查询能力以及更大的查询灵活性。
  Kylin 虽然有数据立方体建模加速查询能力，但是 Druid 的物化能力也可以做到类似的效果。
  短视频文件存储是使用内部系统blobstore,采用 HDFS 服务存储对象的数据本身，同时采用 HBase 存储对象的索引，整体由 gateway 服务进行对象存储逻辑层的实现。
  运维工具--ambari。同时快手坚持将运维与研发放在一个团队中，让双方磨合。

• 大数据架构服务深度定制阶段
  这一阶段就是为了让架构更贴近业务，降低设备成本，增强稳定性，更易扩展，提高性能。
  在存储服务上，HDFS/HBase 服务主要的改进包括：单点故障快速恢复、读写性能优化、服务分级保障与回退等待、服务柔性可用、fastfail、QPS 限流、扩展性改进等，此外我们还自研了位图数据库 BitBase，用于 UV 计算，留存计算等场景。
  简单介绍下 HDFS 服务分级保障能力。HDFS 主节点 RPC 服务采用多队列设计，将不同优先级的作业请求路由到不同队列，处理线程池线程按照不同比例从不同队列取请求进行处理，一旦高优先级队列请求出现高时延情况，则直接降低低优先级队列请求处理比例，将资源向高优先级队列倾斜，从而保障高优先级作业请求的延迟稳定。如果低优先级队列满，则反馈给客户端特殊信号，客户端进行 backoff 等待重试。由于核心作业相对稳定，负载也相对稳定，基本不会出现由于核心作业导致服务过载的情况。通过这个能力的控制，可以保障核心作业的数据产出延迟稳定，不受低优异常作业流量徒增的影响。
  在消息服务上，主要改进包括单点故障快速恢复、平滑扩容、Mirror 服务集群化、资源隔离、Cache 改造、智能限速、QPS 限流、柔性可用、Kafka On HDFS 存储计算分离等。
  在调度引擎上，主要改进点是资源超配功能以及自研了 YARN 的新版本调度器 KwaiScheduler。
  在计算引擎上，自研了智能 SQL 引擎 Beacon。
  在运维上，基于 ambari 自研了可以管理 10w+ 机器规模的服务管理平台 Kalaxy。

• 大数据架构服务整合统一、云化阶段
  从 2020 年开始，快手大数据架构整体上会做进一步整合，并朝向云化服务发展，为公司各业务线提供一体式的大数据基础服务。

问题2

在春晚红包活动中，快手的大数据架构面临了哪些问题，做了哪些针对性的调整优化？

• 线上场景
  线上主要的问题就是能不能抗住极端的峰值流量。
  我们在三个月的时间内开发并上线了过载保护、服务限流与快速 failover、分级保障等能力，实现了 HDFS、HBase、Kafka 三类服务的柔性可用，以及灵活的服务请求控制能力，使得 HDFS、HBase、Kafka 服务在极端压力下，也可以保持峰值吞吐提供服务。同时精确预测了春晚的流量峰值，布置了多条物理链路，如果某一条链路出现问题可以马上切换。

• 离线场景
  离线场景下，主要面临的问题是日志服务可能会被降级，会导致生产 ODS 层数据延迟，进而导致公司级别的离线核心数据的产出出现延迟。
  快手对于yarn的理解和扩展是很厉害的，他们使用了问题分级调度的方式，保证优先级高的问题可以得到足够的资源，这就需要对yarn的二次扩展有一个把握能力。

问题3

快手在调度系统方面有哪些值得业界借鉴的经验？

大数据架构团队针对资源调度系统 YARN 做了很多非常好的改进以及资源上的规划。

• 在资源管理上、
  1）采用了”队列隔离 + 优先级调度能力”的双层保障。规划了生产队列、adhoc 队列、回溯队列、test 队列，以便做到不同大类别作业的资源消耗的隔离，不同类型的作业相互之间不受影响。此外，每个作业都要设置优先级，并在队列内部提供了按照作业优先级进行资源调度与隔离的能力，可细粒度控制不同等级作业资源消耗，最终实现分级保障的目标；
  2）给每个业务线设置 quota（quota 等于 minshare），并保障在任何情况下，每个业务线都可以使用到 quota 数量的资源。

• 在调度策略上
  1）针对同一集群不同性质的作业利用标签调度进行物理隔离，例如离线作业、实时作业之间的物理隔离；
  2）针对 adhoc 场景，提供按照个人用户公平的资源的调度策略，以便保障每个人都能获得相同资源，避免一个人由于提交作业过多而占用大量资源的情况；
  3）重构并开启了资源抢占功能，解决由于大作业长时间占用资源不释放导致 quota 资源量不能被快速满足的情况。
  4）开发上线 App Slot 抢占能力，避免高优先级受最大 APP 限制不能快速执行的问题。

问题4

能否详细介绍一下快手在 Hadoop 方面的应用实践？Hadoop 对快手而言重点解决了什么问题？

Hadoop狭义上是指MR，HDFS，YARN三种服务。

• MR
  MR是Hadoop的痛点，也是因为受时代限制的结果。他是一个十分可靠的老旧工具，但是还是会被spark引擎慢慢替代。不过核心还是要依靠MR引擎。
• HDFS
  HDFS是一个很可靠的文件存储系统，存储量达到了EB级别。
  为了降低成本，我们还采用 EC 技术进一步降低副本空间，目前快手 EC 的数据规模达数百 PB。
• Yarn
  yarn是快手的杀手锏，他研发的kwaiScheduler已经达到了最新Hadoop性能的20-30倍。

Hadoop 是非常核心的底层基础服务，在快手大数据架构体系中占据着核心地位。

问题5

关于国内外唱衰 Hadoop 的言论，您怎么看？

最近流行的Fink，Spark，Druid，Clickhouse，他们只是对MR进行的提升和补充。
但是存储系统肯定是HDFS，资源调度系统是yarn。因为他们在各自的领域中都有了很好的实现，而且没有新兴的流行工具。
哪怕是K8S，他也是针对线上服务领域，对于离线数据处理，还是要依靠yarn。未来可以考虑将yarn和K8S整合，形成一个通用资源调度系统。

问题6

如何看待大数据架构与云架构之间的关系？类似 Hadoop 的大数据技术会在云服务的冲击下逐渐没落吗？

大数据技术不会没落，他会作为PaaS中的一部分，为客户提供大数据场景的业务快速构建能力，架构能力，一站式数据分析服务。
从这个角度来看，大数据不会落寞，随着大数据上云，就可以与云架构结合蓬勃发展。