快手大数据平台服务化实践.docxVIP

快手大数据平台服务化实践 数据开发工程师除了开发完数据表外，通常还需要思考如下问题： 数据如何交付：业务通常期望使用数据接口方式来使用数据，而非数据表，这会愈加机警、解耦、高效。数据开发工程师因而需要建立对应的数据服务。 服务如何开发：数据服务有多种方式，通常要求开发工程师有微服务学问、服务发觉注册、高并发等。 权限、可用性问题：开发完数据服务后，需要考虑权限问题，确保数据资源能被平安的访问；此外还需要考虑可用性问题，要以多种手段保障数据访问的稳定性。 运维问题：数据服务本身涉及多种运维问题，如扩容、迁移、下线、接口变更、服务报警等。 以上问题都需要数据开发工程师去处理。这要求数据开发不只仅是开发出数据表，还需要将数据表包装成一个独立的、机警的、高可用的、平安的数据服务。这对于数据开发工程师要求很高：除了具备基本的业务需求捕获、数据建模、SQL开发等力量外，还要具备开发高可用、高功能的数据服务力量（包括java开发、微服务等）。 痛点二：反复开发数据服务 快手很多业务线（如领取业务、直播业务、账户业务等），都存在数据需求，各业务线都做着：1）数据同步到线上数据库和缓存；2）建设微服务等开发，其中不同业务线下，数据同步和微服务通常有很多共同之处，反复烟囱式的开发意味要反复开发数据服务，形成了人力资源铺张，而且开发效率低，从数据开发到最终交付数据服务，需要经受较长的周期。 基于上述痛点，我们开头建设统一的数据服务化平台。由此开启一个新模式去处理问题。 大数据服务化平台 数据平台本身的定位是一站式自助数据服务平台。用户通过平台来创建数据服务接口、运维服务、调用服务。平台秉承“配置即服务”的理念：数据开发工程师不再需要手写数据服务，只需要在平台上进行简约配置，平台便可自动生产和部署数据服务，从而提升效率。 系统架构 大数据服务化业务架构如下所示，Data Lake 数据湖中存储原始数据，经过数据开发之后，构成按主题域组织的数据资产。此时数据资产通常是在数据仓库，访问速度较慢，因而需要通过数据加速到更高速的存储介质，最终经过多场景服务接口，服务于业务。 在技术架构方面，数据接口方式有 RPC 和 HTTP 两类接口。RPC 接口不需要反复建立链接，且传输数据时会被高效序列化，适用于高吞吐场景下的微服务，实现负载均衡、流控、降级、调用链追踪等功能。相对而言，HTTP 接口传输效率低一些，但使用格外简约。 关键技术一：配置即开发 平台用户分为两类角色：其一是数据服务生产方，其二是数据服务调用方。数据服务生产方只需要配置，做到“配置即开发”，配置包括：1）数据源；2）数据加速到何处；3）接口外形，访问方式；4）配置独立的测试环境，访问隔离的测试数据。当配置完毕后，数据服务平台便会依据配置清单，完成接口的自动化生产和部署。生产和部署完毕后，调用方在平台申请服务权限调用。通过自动化生产，达到配置即开发的目的，从而极大的提升效率。 关键技术二：多模式服务外形 数据服务有多种服务外形，包括： KV API：简约点查，可以支撑百万QPS、毫秒延迟。这类API是通过模板自动化创建出来，支持单查、批量查询等接口，前往的结果是 Protobuf (PB) 结构体，从而将结果自动做了 ORM，对于主调方愈加友好。典型场景包括：依据IP查询geo位相信息、依据用户Id查询用户标签画像信息等。 SQL API：简单机警查询，底层基于 OLAP/OLTP 存储引擎。通过 Fluent API 接口，用户可自在组合搭配一种或若干种嵌套查询条件，可查询若干简约字段或者聚合字段，可分页或者全量取回数据。典型场景包括：用户圈选（组合若干用户标签筛选出一批用户）。 Union API：融合API，可自在组合多个原子API，组合方式包括串行和并行方式。调用方不再需要调用多个原子API，而是调用融合API，通过服务端代理访问多个子查询，可以极大降低访问延迟。 关键技术三：高效数据加速 前面提及的数据资产，通常是存在于低速的存储引擎中，无法支撑线上业务高访问流量。因而需要以系统化的方式进行数据加速。目前有两种加速方式：1）全量数据加速；2）多级缓存（部分数据加速）。 全量数据加速 从多个数据源摄入原始数据（如Kafka，MySQL、线上访问日志等），进行加工建模后，得到数据资产。数据资产经由独立的数据同步服务，同步至其他更高速的存储引擎，如 redis、hbase、druid等。数据同步支持一次性或者周期性（小时、天、周等）将数据从Hive同步至其他存储中，数据同步本身是基于分布式的调度系统，内核是基于 datax 进行数据同步。大数据服务化平台单日同步的数据量达到1200亿条，数据size达到20TB。 多级缓存 大数据服务化平台会使用 Redis、Hbase、Druid、Cli