千万QPS毫秒响应：快手数据中台建设实践

数据开发的痛点

快手是一家数据驱动的公司，数据扮演了非常重要的角色，而数据的生产加工主要依靠数据开发工程师，其工作内容会涉及多个方面。

数据开发工程师则首先根据业务需求开发好高质量的数据，通常是结构化数据（数据表）；其次，开发稳定可靠的数据服务，并通过 API 方式交付给业务方使用。

数据开发工程师有两个痛点，这其中包括：

• 开发数据服务门槛高

• 重复开发数据服务

开发数据服务门槛高

数据开发工程师除了开发完数据表外，通常还需要思考如下问题：

①数据如何交付： 业务通常期望使用数据接口方式来使用数据，而非数据表，这会更加灵活、解耦、高效。数据开发工程师因此需要建立对应的数据服务。

②服务如何开发： 数据服务有多种形式，通常要求开发工程师有微服务知识、服务发现注册、高并发等。

③权限、可用性问题： 开发完数据服务后，需要考虑权限问题，确保数据资源能被安全的访问；此外还需要考虑可用性问题，要以多种手段保障数据访问的稳定性。

④运维问题： 数据服务本身涉及多种运维问题，如扩容、迁移、下线、接口变更、服务报警等。

以上问题都需要数据开发工程师去解决。这要求数据开发不仅仅是开发出数据表，还需要将数据表包装成一个独立的、灵活的、高可用的、安全的数据服务。

这对于数据开发工程师要求很高：除了具备基本的业务需求捕获、数据建模、SQL 开发等能力外，还要具备开发高可用、高性能的数据服务能力（包括 Java 开发、微服务等）。

重复开发数据服务

快手很多业务线（如支付业务、直播业务、账户业务等），都存在数据需求，各业务线都做着：

① 数据同步到线上数据库和缓存。

② 建设微服务等开发，其中不同业务线下，数据同步和微服务通常有很多共同之处，重复烟囱式的开发意味要重复开发数据服务，造成了人力资源浪费，而且开发效率低，从数据开发到最终交付数据服务，需要经历较长的周期。

基于上述痛点，我们开始建设统一的数据服务化平台。由此开启一个新模式去解决问题。

大数据服务化平台

数据平台本身的定位是一站式自助数据服务平台。用户通过平台来创建数据服务接口、运维服务、调用服务。

平台秉承“配置即服务”的理念：数据开发工程师不再需要手写数据服务，只需要在平台上进行简单配置，平台便可自动生产和部署数据服务，从而提升效率。

系统架构

大数据服务化业务架构如下所示，Data Lake 数据湖中存储原始数据，经过数据开发之后，形成按主题域组织的数据资产。

此时数据资产通常是在数据仓库，访问速度较慢，因此需要通过数据加速到更高速的存储介质，最后经过多场景服务接口，服务于业务。

在技术架构方面，数据接口形式有 RPC 和 HTTP 两类接口。

RPC 接口不需要重复建立链接，且传输数据时会被高效序列化，适用于高吞吐场景下的微服务，实现负载均衡、流控、降级、调用链追踪等功能。相对而言，HTTP 接口传输效率低一些，但使用非常简单。

关键技术一：配置即开发

平台用户分为两类角色：其一是数据服务生产方，其二是数据服务调用方。数据服务生产方只需要配置，做到“配置即开发”。

配置包括：

• 数据源

• 数据加速到何处

• 接口形态，访问方式

• 配置独立的测试环境，访问隔离的测试数据
  

当配置完毕后，数据服务平台便会根据配置清单，完成接口的自动化生产和部署。

生产和部署完毕后，调用方在平台申请服务权限调用。通过自动化生产，达到配置即开发的目的，从而极大的提升效率。

关键技术二：多模式服务形态

数据服务有多种服务形态，包括：

①KV API： 简单点查，可以支撑百万 QPS、毫秒延迟。这类 API 是通过模板自动化创建出来，支持单查、批量查询等接口，返回的结果是 Protobuf (PB) 结构体，从而将结果自动做了 ORM，对于主调方更加友好。

典型场景包括：根据 IP 查询 geo 位置信息、根据用户 Id 查询用户标签画像信息等。

②SQL API： 复杂灵活查询，底层基于 OLAP/OLTP 存储引擎。通过 Fluent API 接口，用户可自由组合搭配一种或若干种嵌套查询条件，可查询若干简单字段或者聚合字段，可分页或者全量取回数据。

典型场景包括：用户圈选（组合若干用户标签筛选出一批用户）。

③Union API： 融合 API，可自由组合多个原子 API，组合方式包括串行和并行方式。

调用方不再需要调用多个原子 API，而是调用融合 API，通过服务端代理访问多个子查询，可以极大降低访问延迟。

关键技术三：高效数据加速

前面提及的数据资产，通常是存在于低速的存储引擎中，无法支撑线上业务高访问流量。因此需要以系统化的方式进行数据加速。

目前有两种加速方式：

• 全量数据加速

• 多级缓存（部分数据加速）

全量数据加速： 从多个数据源摄入原始数据（如 Kafka，MySQL、线上访问日志等），进行加工建模后，得到数据资产。

数据资产经由独立的数据同步服务，同步至其他更高速的存储引擎，如 Redis、Hbase、Druid 等。

数据同步支持一次性或者周期性（小时、天、周等）将数据从 Hive 同步至其他存储中，数据同步本身是基于分布式的调度系统，内核是基于 datax 进行数据同步。

大数据服务化平台单日同步的数据量达到 1200 亿条，数据 size 达到 20TB。

多级缓存： 大数据服务化平台会使用 Redis、Hbase、Druid、Clickhouse 等方式存储所有数据，但是部分存储如 Hbase 速度可能较慢，针对热点数据需要使用额外的热点缓存来 Cache 数据。

热点缓存是多级缓存，针对每个 API 接口，用户可自由搭配组合多级缓存、灵活设置缓存策略。

此外，针对数据较大的 API，还可配置数据压缩，通过多种压缩方式（如 ZSTD，SNAPPY，GZIP 等），可将数据量显著减少（部分 API 甚至能减少 90% 的数据存储量） 。

关键技术四：高可用保障

服务可用性是微服务领域内的一大核心，服务的高可用通常需要组合多种手段来保障。

快手数据服务化平台通过多种方式来达到高可用的目的，主要包括：

• 弹性服务框架

• 资源隔离

• 全链路监控

弹性服务框架

数据服务是部署在容器云环境，容器云是快手自研的弹性可伸缩的容器服务，部署在其中的 RPC 服务会注册到 KESS （快手自研服务注册与发现中心），供主调方去调用，如有离群坏点，会自动摘除。

服务调用是基于 RPC，全链路都有监控，包括服务可用性、延迟、QPS、容器CPU、容器内存等情况。

资源隔离

资源隔离是可用性保障的常见手段之一，通过隔离将意外故障等情况的影响面降低。

不管是微服务，还是存储，我们都按照业务+优先级（高、中、低）粒度隔离部署，独立保障，业务之间互不影响、业务内不同级别也互不影响。

同一业务线内可能有多个不同数据服务，通过混合部署，提高资源使用率。

全链路监控

服务很难避免出现问题或者故障，一旦出现问题，及早发现及早介入是非常重要的。

服务平台构建了全链路监控，包括：

• 数据同步： 对数据资产同步至高速存储的过程进行监控，包括数据质量检测（过滤脏数据）、同步超时或者失败检测等 。

• 服务稳定性： 构建一个独立的哨兵服务，来监测每个 API 的运行指标（如延迟、可用性等），客观的评估健康度。

• 业务正确性： 数据服务需要确保用户访问的数据内容和数据资产表内容是一致的，因此哨兵服务会从数据一致性层面去探查，确保每个 API 的数据一致性。

总结和展望

大数据服务化平台从 2017 年演化至今，已经支持多类应用场景，涵盖直播、短视频、电商、商业化等在线业务，生产者中台等准在线业务，运营系统等偏内部数据系统等，目前平台在线业务总 QPS 达到 1000W，平均延迟在毫秒级。

对于准在线业务和内部数据系统，基于 CH、Druid 等多种数据引擎，支持多种灵活查询。

数据服务平台支持了多种模式 API，很好满足了多元化需求。此外数据服务平台也支持服务权限、API 市场等丰富功能，进一步赋能业务。

大数据服务化平台未来进一步发展方向主要包括：

①贴近业务需求： 数据服务平台本身是为业务服务，通过赋能业务而对企业带来价值，业务本身在不断发展，未来也会有更多的需求出现，因此数据服务平台本身会不断抽象和沉淀出公共数据服务能力。

②深耕 数据资产 ： 数据资产是数据服务之根本，如果没有完善的数据资产建设，上面就很难构建出结构化的统一的数据服务，针对数据资产有较多内容，包括资产注册和审核、资产地图、资产标签、资产管理、资产开放和服务。

大数据服务平台的能力建设会朝着统一的 OneService 体系前进。

主要包括三个方面：

• 支持丰富的数据源 ：包括大宽表、文本文件、机器学习模型（模型也是一种数据资产），来构建完善的数据服务。

• 支持多样取数方式： 除了支持同步快速取数之外，还支持异步查询取数、推送结果、定时任务等多样化方式，以满足业务多种场景需求。

• 建设统一的 API 网关： 集成权限管控、限流降级、流量管理等于一体，不仅平台创建的服务可以注册进 API 网关，用户自己开发的 API 也可注册进 API 网关，从而享受已有的基础网关能力，为业务提供数据服务能力。

编辑：陶家龙

出处： 转载自公众号壹佰案例（ID：Top100Case）

精彩文章推荐：

滴滴为啥值3600亿？看它的数据中台就知道了

阿里“拆台”，中台真的不香了？

为什么要从Druid迁移到ClickHouse？