抖音网站0.5块钱100个本文是围绕着快手的数据服务化中台进行介绍。第一部份是背景介绍，包括数据开发的痛点，第二部份是介绍大数据服务化平台，包括平台构架以及关键细节解读，第三部份是经验总结和未来思索。（本文内容早已在2020年Top100全球软件案例研究论坛进行过分享。）
背景
快手是一家数据驱动的公司，数据饰演了十分重要的角色，而数据的生产加工主要借助数据开发工程师，其工作内容会涉及多个方面：数据开发工程师则首先依照业务需求开发好高质量的数据，一般是结构化数据（数据表）；其次，开发稳定可靠的数据服务，并通过API方法交付给业务方使用。
数据开发工程师有两个痛点：1）开发数据服务门槛高；2）重复开发数据服务。
痛点一：开发数据服务门槛高
数据开发工程师不仅开发完数据表外，一般还须要思索如下问题：
数据怎么交付：业务一般期望使用数据插口形式来使用数据，而非数据表，这会愈加灵活、解耦、高效。数据开发工程师因而须要构建对应的数据服务。
服务怎么开发：数据服务有多种方式，一般要求开发工程师有微服务知识、服务发觉注册、高并发等。
权限、可用性问题：开发完数据服务后，须要考虑权限问题，确保数据资源能被安全的访问；据悉还须要考虑可用性问题，要以多种手段保障数据访问的稳定性。
运维问题：数据服务本身涉及多种运维问题，如扩容、迁移、下线、接口变更、服务报案等。
以上问题都须要数据开发工程师去解决。这要求数据开发不仅仅是开发出数据表，还须要将数据表包装成一个独立的、灵活的、高可用的、安全的数据服务。这对于数据开发工程师要求很高：不仅具备基本的业务需求捕获、数据建模、SQL开发等能力外，还要具备开发高可用、高性能的数据服务能力（包括java开发、微服务等）。
痛点二：重复开发数据服务
快手好多业务线（如支付业务、直播业务、账户业务等），都存在数据需求，各业务线都做着：1）数据同步到线上数据库和缓存；2）建设微服务等开发，其中不同业务线下，数据同步和微服务一般有好多共同之处，重复水塔式的开发意味要重复开发数据服务，导致了人力资源浪费，并且开发效率低快手在线自助业务平台，从数据开发到最终交付数据服务，须要经历较长的周期。
基于上述痛点，我们开始建设统一的数据服务化平台。由此开启一个新模式去解决问题。
大数据服务化平台
数据平台本身的定位是一站式自助数据服务平台。用户通过平台来创建数据服务插口、运维服务、调用服务。平台秉持“配置即服务”的理念：数据开发工程师不再须要手写数据服务，只须要在平台上进行简单配置，平台便可手动生产和布署数据服务，进而提高效率。
系统构架
大数据服务化业务构架如下所示，DataLake数据湖中储存原始数据，经过数据开发以后，产生按主题域组织的数据资产。此时数据资产一般是在数据库房，访问速率较慢，因而须要通过数据加速到更高速的储存介质，最后经过多场景服务插口，服务于业务。
在技术构架方面，数据插口方式有RPC和HTTP两类插口。RPC插口不须要重复构建链接，且传输数据时会被高效序列化，适用于高吞吐场景下的微服务，实现负载均衡、流控、降级、调用链追踪等功能。相对而言，HTTP插口传输效率低一些快手在线自助业务平台，但使用十分简单。
关键技术一：配置即开发
平台用户分为两类角色：其二是数据服务生产方，其一是数据服务调用方。数据服务生产方只须要配置，做到“配置即开发”，配置包括：1）数据源；2）数据加速到何处；3）插口形态，访问方法；4）配置独立的测试环境，访问隔离的测试数据。当配置完毕后，数据服务平台便会根据配置清单，完成插口的手动化生产和布署。生产和布署完毕后，调用方在平台申请服务权限调用。通过手动化生产，达到配置即开发的目的，因而极大的提高效率。
关键技术二：多模式服务形态
数据服务有多种服务形态，包括：
KVAPI：简单点查，可以支撑百万QPS、毫秒延后。这类API是通过模板手动化创建下来，支持单查、批量查询等插口，返回的结果是Protobuf(PB)结构体，进而将结果手动做了ORM，对于主调方愈发友好。典型场景包括：按照IP查询geo位置信息、根据用户Id查询用户标签画像信息等。
SQLAPI：复杂灵活查询，底层基于OLAP/OLTP储存引擎。通过FluentAPI插口，用户可自由组合搭配一种或若干种嵌套查询条件，可查询若干简单数组或则聚合数组，可分页或则全量拿回数据。典型场景包括：用户圈选（组合若干用户标签筛选出一批用户）。
UnionAPI：融合API，可自由组合多个原子API，组合形式包括串行和并行形式。调用方不再须要调用多个原子API，而是调用融合API，通过服务端代理访问多个子查询，可以极大减少访问延后。
关键技术三：高效数据加速
上面提到的数据资产，一般是存在于低速的储存引擎中，难以支撑线上业务高访问流量。因而须要以系统化的方法进行数据加速。目前有两种加速方法：1）全量数据加速；2）多级缓存（部份数据加速）。
全量数据加速
从多个数据源摄取原始数据（如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网段，因而享受已有的基础网段能力，为业务提供数据服务能力。
作者简介：倪顺，本硕结业于上海学院，曾就职于Hulu，从事视频领域大数据研制工作，包括视频播放质量的数据建设以及基于数据驱动的播放体验提高。目前就职于快手，从事数据中台领域工作，主要负责大数据服务化基础平台建设。
-EOF-