《快手数据中台建设-大数据服务化之路》

专注开源技术，共建鸿蒙生态

“

本文整理自快手数据平台部，数据服务化中台负责人倪顺发表的《快手数据中台建设-大数据服务化之路》的讲演。

图片来自Pexels

他围绕数据资产服务化，服务于业务形成商业价值进行了分享：

数据开发的痛点

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

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

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

开发数据服务门槛高

数据开发工程师不仅开发完数据表外，一般还须要思索如下问题：

①数据怎么交付：业务一般期望使用数据插口形式来使用数据，而非数据表，这会愈加灵活、解耦、高效。数据开发工程师因而须要构建对应的数据服务。

②服务怎么开发：数据服务有多种方式，一般要求开发工程师有微服务知识、服务发觉注册、高并发等。

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

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

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

这对于数据开发工程师要求很高：不仅具备基本的业务需求捕获、数据建模、SQL开发等能力外快手在线自助业务平台，还要具备开发高可用、高性能的数据服务能力（包括Java开发、微服务等）。

重复开发数据服务

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

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

②建设微服务等开发，其中不同业务线下，数据同步和微服务一般有好多共同之处，重复水塔式的开发意味要重复开发数据服务，导致了人力资源浪费，并且开发效率低，从数据开发到最终交付数据服务，须要经历较长的周期。

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

大数据服务化平台

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

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

系统构架

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

此时数据资产一般是在数据库房，访问速率较慢，因而须要通过数据加速到更高速的储存介质，最后经过多场景服务插口，服务于业务。

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

RPC插口不须要重复构建链接快手在线自助业务平台，且传输数据时会被高效序列化，适用于高吞吐场景下的微服务，实现负载均衡、流控、降级、调用链追踪等功能。相对而言，HTTP插口传输效率低一些，但使用十分简单。

关键技术一：配置即开发

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

配置包括：

当配置完毕后，数据服务平台便会依照配置清单，完成插口的手动化生产和布署。

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

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

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

①KVAPI：简单点查，可以支撑百万QPS、毫秒延后。这类API是通过模板手动化创建下来，支持单查、批量查询等插口，返回的结果是Protobuf(PB)结构体，进而将结果手动做了ORM，对于主调方愈发友好。

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

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

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

③UnionAPI：融合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、容器显存等情况。

资源隔离

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

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

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

全链路监控

服务很难防止出现问题或则故障，一旦出现问题，及早发觉及早介入是极其重要的。

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

总结和展望

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

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

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

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

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

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

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

主要包括三个方面：