1能否详细给我们介绍一下快手大数据架构的发展历程，目前在各个关键部位的技术选型是什么？出于什么样的考虑？
快手大数据架构团队是在 2017 年开始组建的，整个大数据架构服务也是从那时开始演进发展的。出于目标与成本上的考虑，快手的大数据架构服务大部分都是基于开源系统构建的。截止到目前为止，快手的大数据架构的发展大概经历 3 个阶段：
1. 大数据架构基础服务从 0 到 1 建设
2017 年左右，快手大数据架构服务主要以支持离线分析场景为主，服务建设首先从离线存储计算服务起步，行业内已经公认 Hadoop 是解决这类场景的最佳方案，考虑到后续我们会基于这个版本之上进行持续开发迭代，所以我们选择下载 CDH Hadoop 2.6 的源代码（选择 CDH 版本是因为比 apache 版本要更加稳定，且没有选择更高版本，也是基于稳定性的考虑，不过现在想起来，其实当时可以换到最新版本），并编译源码进行部署。主要以推广应用、解决业务问题，以及做一些轻量型的改进为主。此外，快手在一开始就重度依赖 Kafka 服务，除了离线日志收集传输场景外，还包括在线服务消息队列以及 cache 同步场景。选择 Kafka 主要是因为其性能好且有大厂（LinkedIn）最佳实践。我们对 Kafka 系统的建设起步还算比较早的，那时主要在解决 Kafka 集群扩展性与可用性的问题，在 2017 年 11 月，我们就解决了 Kafka 集群的扩容问题，能够做到集群扩容对业务基本无影响，且整个扩容流程自动化完成，有兴趣的同学可参考 2019 年北京 QCon 上分享的议题：《快手万亿级别 Kafka 集群应用实践与技术演进之路》。
https://www.infoq.cn/article/Q0o*QzLQiay31MWiOBJH?utm_source=tuicool&utm_medium=referral
大概在 2018 上半年，大数据架构服务开始延伸到实时计算以及交互式分析场景。对于实时计算场景，我们采用了 Flink 引擎，主要是因为 Flink 完全是原生的实时计算引擎，相比于 Storm，有着丰富实时语义的实现、窗口抽象、状态存储等能力，为开发者提供了非常多便利的工具。相比于 Spark，Flink 的实时性更好。对于 OLAP 分析需求，我们采用 Druid 引擎，并同时提供了配套的 Superset 交互分析可视化平台。该系统一经落地，受到了广泛研发同学的喜爱，并得到了快速的发展。在 OlAP 引擎上，我们最终没有选择 Kylin，主要的原因是 Druid 有着更好的实时性、更多查询能力以及更大的查询灵活性。Kylin 虽然有数据立方体建模加速查询能力，但是 Druid 的物化能力也可以做到类似的效果（不过当时物化功能开源版本没有实现，后来我们自己实现了）。
快手的大数据架构存储服务除了支持离线存储场景之外，还同时在支持快手短视频在线存储场景。快手短视频存储平台（对象存储平台），内部代号 blobstore，采用 HDFS 服务存储对象的数据本身，同时采用 HBase 存储对象的索引，整体由 gateway 服务进行对象存储逻辑层的实现。作为对象存储服务而言，这套架构设计的简单且实用。截止到目前，快手的对象存储服务仍沿用着这套基础架构，并进行了功能与能力上的大范围增强。前期我们主要做了一些 HDFS、HBase 服务面向在线场景下的可用性改进，如单点宕机快速恢复等。
还有一个方面是运维，我一直坚持大数据架构服务运维和研发要在同一个团队，主要是因为大数据架构服务众多，导致运维流程繁多，且非常复杂。整体运维和研发的沟通协作非常频繁。同一个团队可以更加密切配合。在运维上，我们一开始就主张尽可能通过平台化的方式提效整个运维工作，所以在开始阶段，我们就强调运维操作的复用性，运维以自动化，工具化构建为主，并引入 ambari 作为大数据服务运维的基础平台，逐渐开始接管各类大数据架构服务，并鼓励运维同学多总结目前没有被平台化的操作流程，提炼流程的通用性，为下一步全面平台化运维做好准备工作。
截止到 2018 年 6 月左右，整个大数据架构系统已经初步完成存储、调度、计算层服务与运维的从 0 到 1 的建设，并已经在快手大范围应用起来了。
2、大数据架构服务深度定制阶段
公司业务进一步扩大与高速增长，给整个大数据架构服务的稳定性、扩展性、性能都带来了巨大的冲击。作为应对，在大数据架构服务从 0 到 1 的构建之后，我们开始夯实各层服务的现有能力，对现有的开源服务进行大量的深度开发与定制。受限于篇幅限制，这里主要会挑一些重点的改进简单介绍下。
在存储服务上，HDFS/HBase 服务主要的改进包括：单点故障快速恢复、读写性能优化、服务分级保障与回退等待、服务柔性可用、fastfail、QPS 限流、扩展性改进等，此外我们还自研了位图数据库 BitBase，用于 UV 计算，留存计算等场景。简单介绍下 HDFS 服务分级保障能力，这个功能主要是面对离线场景的。在离线计算的场景下，集群整体业务负载基本上没有固定规律，因为个别大作业启动起来后，会直接造成 HDFS 主节点的满载，满载的主要表现是服务延迟升高，QPS 打平，RPC 服务请求堆积。一旦该现象出现在凌晨时段，将会影响核心链路数据的产出，造成故障。为了保障核心链路的生产的稳定，我们引入了优先级的概念，并连同计算资源调度服务一起，给核心作业（高优先级）提供计算与存储资源的整体保障。在实现上，HDFS 主节点 RPC 服务采用多队列设计，将不同优先级的作业请求路由到不同队列，处理线程池线程按照不同比例从不同队列取请求进行处理，一旦高优先级队列请求出现高时延情况，则直接降低低优先级队列请求处理比例，将资源向高优先级队列倾斜，从而保障高优先级作业请求的延迟稳定。如果低优先级队列满，则反馈给客户端特殊信号，客户端进行 backoff 等待重试。由于核心作业相对稳定，负载也相对稳定，基本不会出现由于核心作业导致服务过载的情况。通过这个能力的控制，可以保障核心作业的数据产出延迟稳定，不受低优异常作业流量徒增的影响。
在 Kafka 消息服务上，主要改进包括单点故障快速恢复、平滑扩容、Mirror 服务集群化、资源隔离、Cache 改造、智能限速、QPS 限流、柔性可用、Kafka On HDFS 存储计算分离等。简单介绍下 Kafka On HDFS 这个能力，Kafka 服务的性能主要依赖内存 cache 层，一旦读数据 miss cache，会产生磁盘读操作（lag 读），由于目前磁盘主要还是机械盘，因此一旦 lag 读，性能会急剧下降。此外，如果 topic 的 consumer group 很多的话，非常容易造成磁盘单盘热点，使得性能进一步恶化，甚至影响 broker 上的其他 topic 的读写操作。另一方面，随着业务快速发展，Kafka 集群规模也越来越大，原有 Kafka 的架构模式在超大规模下会造成大量的运维成本。为了解决上述两个问题，我们开发了 Kafka On HDFS 方案，并控制一旦 group 的读操作产生了 cache miss，broker 会直接从 HDFS 读取数据返回给消费者，且由于 HDFS 的数据是按照块打散的，所以在消费者 lag 读的时候，能够充分利用多盘的能力支持读，进而提升 lag 读性能。另一方面，由于 Kafka On HDFS 方案可实现存储与计算的分离，这样 broker 变成了无状态的服务，在单点宕机的时候，可以直接从 HDFS 上恢复，感兴趣的同学可以关注 2020 年 Qcon 北京的议题：《快手实时处理系统存储架构演进之路》
https://qcon.infoq.cn/2020/beijing/presentation/2344
在调度引擎上，主要改进点是资源超配功能以及自研了 YARN 的新版本调度器 KwaiScheduler，改进调度性能，并定制了大量的调度策略、例如标签调度、作业分级阻断、基于用户的公平调度、基于优先级的调度等，此外还重构了资源抢占模块。其中 KwaiScheduler 采用了分批与并行混合调度方案，SLS 工具评测出来的调度性能相比于 apache hadoop3.0 的版本有 20~30 倍提升，调度性能可达：2.5w/s~3.5w/s。
YARN 的新版本调度器 KwaiScheduler：
https://www.infoq.cn/article/vkH8pdfqAZFh3YXaSSsG
在计算引擎上，自研了智能 SQL 引擎 Beacon，可以自动路由 Presto、Spark、MR 引擎，整个引擎路由完全对用户透明，提升了性能并降低了使用成本。OLAP 引擎上，深度定制 Druid 系统，开发了物化视图功能、精准去重功能、中心节点优化改进单集群扩展性、资源隔离以及可用性改进点等。此外，我们还引入了 Clickhouse 引擎，并同时自研了 Clickhouse On HDFS 服务 KwaiCH，彻底解决了 Clickhouse 服务运维难，扩容难的问题。实时引擎上，增加新的状态存储引擎 SlimBase，Source 同步消费功能，JobManger 高可用、实时 SQL 建模等。
智能 SQL 引擎 Beacon：
https://www.infoq.cn/article/BN9cJjg1t-QSWE6fqkoR?utm_source=related_read
Clickhouse On HDFS 服务 KwaiCH
https://www.infoq.cn/article/vGabIOdeUM87hv6X8qlL?from=singlemessage
状态存储引擎 SlimBase
https://open.mi.com/conference/hbasecon-asia-2019
在运维上，基于 ambari 自研了可以管理 10w+ 机器规模的服务管理平台 Kalaxy，基本囊括了大数据服务运维、基础运维的全部场景。极大提升了运维效率。
3、大数据架构服务整合统一、云化阶段
从 2020 年开始，快手大数据架构整体上会做进一步整合，并朝向云化服务发展，为公司各业务线提供一体式的大数据基础服务。具体详情，敬请期待。
2在春晚红包活动中，快手的大数据架构面临了哪些问题，做了哪些针对性的调整优化？
当听到快手成为 2020 年春节联欢晚会独家互动合作伙伴时，我是非常兴奋的，同时也是压力巨大的。和春晚活动相关的大数据服务包括：在线短视频上传服务、在线消息中间件服务、实时计算、日志上传与离线计算。
在线场景下，主要是要能扛住极端并发下的峰值流量，保障活动期间服务整体稳定运行。原有的 HDFS、HBase、Kafka 服务在面对超高并发请求的压力下，可能会出现服务雪崩以及大规模的节点不可用的情况，将会造成重大事故。于是，为了应对可能的极限峰值压力，我们在三个月的时间内开发并上线了过载保护、服务限流与快速 failover、分级保障等能力，实现了 HDFS、HBase、Kafka 三类服务的柔性可用，以及灵活的服务请求控制能力，使得 HDFS、HBase、Kafka 服务在极端压力下，也可以保持峰值吞吐提供服务。当然也不能只依赖服务管控的方式，在服务容量规划与评估上，我们也做了大量的工作，最终也是比较精准的预测了春晚的流量。在整个三个月里，我们也进行了非常多次的全链路压测与故障演练，以便确认系统在超高压力下的能够提供高稳定性的服务。
实时计算场景下，主要是保障活动实时大盘的高稳定性运行。为了保障实时服务整体稳定，我们除了开发并上线服务柔性可用的能力以及进行压测之外，还针对活动以及核心数据的实时生产，建设了多条互备的物理链路，一旦单条物理链路出现问题，可以随时切换到另外一条上，保障了活动期间实时数据的产出的高稳定性。
离线场景下，主要面临的问题是日志服务可能会被降级，会导致生产 ODS 层数据延迟，进而导致公司级别的离线核心数据的产出出现延迟。此外，活动当天的数据规模以及日志服务恢复时可能带来的峰值不好预期，所以数据真实的恢复时间也不好评估，给离线链路的核心数据产出的预案设计带来了非常大的困难。为了应对这种情况，我们首先把作业按照重要性进行了分级，并制定了多种情况下的数据恢复以及数据的分级产出方案。在资源保障上，YARN 提供了按照优先级进行作业阻断提交与回收的能力，以及按照作业优先级进行资源调度的能力，保障了离线链路上核心数据的及时产出。
通过对大数据架构服务，面向以上几种场景下能力的改造，我们顺利完成了整个春晚活动的稳定性保障任务。整体活动期间，各类大数据架构服务整体稳定平稳，全部达成了之前稳定性预期的目标。
3快手在调度系统方面有哪些值得业界借鉴的经验？
大数据架构团队针对资源调度系统 YARN 做了很多非常好的改进以及资源上的规划。
在资源管理上，1）采用了”队列隔离 + 优先级调度能力”的双层保障。规划了生产队列、adhoc 队列、回溯队列、test 队列，以便做到不同大类别作业的资源消耗的隔离，不同类型的作业相互之间不受影响。此外，每个作业都要设置优先级，并在队列内部提供了按照作业优先级进行资源调度与隔离的能力，可细粒度控制不同等级作业资源消耗，最终实现分级保障的目标；2）给每个业务线设置 quota（quota 等于 minshare），并保障在任何情况下，每个业务线都可以使用到 quota 数量的资源。
在调度策略上，1）针对同一集群不同性质的作业利用标签调度进行物理隔离，例如离线作业、实时作业之间的物理隔离；2）针对 adhoc 场景，提供按照个人用户公平的资源的调度策略，以便保障每个人都能获得相同资源，避免一个人由于提交作业过多而占用大量资源的情况；3）重构并开启了资源抢占功能，解决由于大作业长时间占用资源不释放导致 quota 资源量不能被快速满足的情况。4）开发上线 App Slot 抢占能力，避免高优先级受最大 APP 限制不能快速执行的问题。
4能否详细介绍一下快手在 Hadoop 方面的应用实践？Hadoop 对快手而言重点解决了什么问题？
Hadoop 是快手大数据架构体系的一部分，通常说的 Hadoop 指的是 HDFS、YARN、MR 这三个服务。目前 Hadoop 主要应用在离线数据分析场景。
HDFS 是海量离线数据存储底层基础服务，快手所有离线的数据都存储在 HDFS 上，其规模达 EB 级别，为了降低成本，我们还采用 EC 技术进一步降低副本空间，目前快手 EC 的数据规模达数百 PB。
YARN 系统为各种计算类型作业（MR、Spark、FLink 等）进行资源的分配与调度。我们自研了 YARN 的新型调度器 KwaiScheduler，评测的调度性能可达：2.5w/s~3.5w/s，相比于 Apache Hadoop 3.0 的版本有 20~30 倍提升。此外，kwaiScheduler 提供了可插拔的调度策略，增加调度策略变得极其容易，目前借助该功能提供了混合式的调度策略：针对 adhoc 场景，提供面向个人公平的资源调度策略；针对数据例行生产，提供面向作业优先级的调度策略；面向实时场景，提供资源均衡的调度策略等等。
此外，为了进一步改进性能，我们在进行 Spark 引擎替换 MR 引擎的工作，快手的 MR 引擎的作业占比在逐渐减低中，但是由于 MR 引擎出色的稳定性表现，在部分核心 ETL 场景下，MR 引擎可能会被保留。
综上所述，Hadoop 是非常核心的底层基础服务，在快手大数据架构体系中占据着核心地位。
5关于国内外唱衰 Hadoop 的言论，您怎么看？Hadoop 如何摆脱目前的尴尬现状？
Hadoop（狭义 Hadoop）主要指的是 HDFS、YARN、MR 这三个服务，主要解决了企业离线数据分析的场景需求。近几年新型开源分析系统 Spark、Flink、Druid、Clickhouse 等在实时性，性能上比 Hadoop 有很大程度的提升与补充。但是这些系统也仅仅是对 MR 这个计算引擎的替换，目前在大数据场景下，主流的存储与资源管理系统仍然是 HDFS 和 YARN，且短期内不会出现什么变化。
之所以存储会选择 HDFS，一方面是因为 HDFS 系统的稳定性、可靠性以及扩展性非常出色，另一方面，企业现有的数据已经存储到 HDFS 系统上，迁移本身成本也是比较大的。整体上没有什么强烈理由需要替换。
对于 YARN 系统而言，虽然 K8s 目前发展势头强劲，但是大部分企业仍然应用 K8s 在在线服务领域，离线数据分析领域实践少之又少。主要是因为 K8s 系统在调度能力上，以及对现有分析引擎的支持上还不是特别完善。而 YARN 本身也在快速迭代，且各大互联网公司对 YARN 的调度能力以及扩展性、甚至资源超配都做到很大的改进。整体上替换 YARN 的动力也不强。未来一个可能的方向是要考虑如何将 YARN 和 K8S 服务整体一起，提供统一的调度服务。
所以，我觉得对于自己组建大数据架构服务的企业来说，要对整个大数据生态的基础服务有比较深入的了解。从应用上看，Hadoop 仍然是一个很好的大数据基础服务，只不过要因地制宜，且把更多能力更强的新型系统引入到企业中，帮助解决不同场景下的需求。最后再做到服务整合，在提升性能的前提下，减少业务的使用成本。
6如何看待大数据架构与云架构之间的关系？类似 Hadoop 的大数据技术会在云服务的冲击下逐渐没落吗？
首先再明确下这两个概念：
大数据架构：是为解决大数据业务场景需求的分布式基础服务，其定位可以认为是大数据方向的基础架构。整体上可划分为三个层次
- 分布式存储层：主要包括各类大数据场景的存储服务，如分布式文件系统（HDFS）、分布式 KV 系统（HBase）以及分布式消息缓存（Kafka）等。主要解决的是海量数据的存储问题（也有相当多的互联网公司利 Kafka 系统进行数据传输接入）
- 分布式调度层：资源调度层目前主要使用的 YARN，提供了一个资源池抽象层，把各类计算引擎作业统一管理与调度。
- 计算引擎层：是面向各类场景的计算引擎，包括解决实时计算场景需求的 Flink 系统，解决离线计算场景的 SQL 类引擎，以及解决交互式分析场景下的 adhoc 以及 olap 引擎。
云架构：是实现云计算能力的底层基础服务与设施，行业内公认的云架构分为三大层次：
- 基础设施层（IaaS，基础设施即服务）：将基础设施，例如网络，机器等硬件资源抽象成服务，提供给客户使用，解决了客户在如何采购机器，建设机房，以及构建网络等基础类工作的问题。
- 平台层（PaaS，平台即服务）：将平台，例如开发、存储、调度与计算平台等，做整合抽象成服务，为用户提供了开发环境，解决用户快速构建业务服务的能力。
- 软件服务层（SaaS，软件即服务）：将软件，例如推送、反作弊等应用，作为服务提供。客户可以根据需求通过互联网向厂商订购，并使用应用软件服务。
从这两个概念上看，大数据架构可以认为是云架构中 PaaS 层的一部分。专注于为客户提供在大数据场景下的业务快速构建能力。大数据架构服务，连同数据生产开发套件一起为面向数据分析的客户提供一体式的 PaaS 层解决方案。从这个方面上看，即使在云架构中，依然会保留大数据架构技术。
从各自发展上来看，创业企业、小型企业以及一部分中型企业，需求相对来说可能会比较简单，出于成本、人力的考虑，会投向云架构提供的服务上，以便快速实现业务逻辑提供产品获取利润。对于大型企业以及一部分中型企业而言，业务体量很大，面临的需求也会变得丰富、个性化且复杂，云架构所提供的服务，不一定能够完全满足具体的场景与需求，此外，如果放到云上，数据本身也存在安全层面的隐患，所以除了成本因素外，还会考虑快速支持、安全等因素，通常会自建大数据架构服务，以便有效支撑企业发展。当然在这些企业中的大数据架构技术并不是简单的拿来应用，与此同时，还会对其进行大量深度定制开发，以便满足企业发展需求。整个大数据架构技术会也会向着服务能力整合统一，以及企业内部云化的方向发展。
所以从上述两个方面看，大数据架构技术并不会没落，且会和云架构一样继续蓬勃发展。
