写点什么

CrateDb 在携程机票 BI 的实践

2021 年 1 月 15 日

CrateDb在携程机票BI的实践

一、前言


随着整个互联网流量红利进入末期,各大厂在着力吸引新客的同时,在既有客户群体的运营上也是煞费苦心,各种提高客户体验、个性化服务的场景层出不穷。


携程机票大数据部门在实践过程中需要同步数据、选型引擎来存储处理数据,利用接口将模型结果开放给生产环境调用,因此我们的数据存储修炼之旅会涉及到接口现状、接口大道之旅、安装部署、同步数据、生产应用以及未来的趋势-如何实现容器化。这当中,我们遇到了很多问题,也解决了很多问题,本文将分享机票大数据平台在数据存储这一块的实践经验。


二、机票大数据接口现状


携程机票大数据平台接口组碰到的问题:


  • 如何存储

  • 如何查询

  • 如何维护


2.1 如何存储


机票大数据基础架构团队接口组在 2018 年之前,数据的存储方案基本是:hive、mysql、redis。以下是我们现有的存储选型:


接口需求HiveMysqlRedis
性能要求请求QPS
>1s<1
<1s<10
<500ms>100
<100ms>100


这就造成了机票大数据部门的 redis 集群内存需求暴涨,目前我们统计 redis 使用的数据:挂在机票大数据部门的 redis 集群数量有几十个,内存达到了十几个 T。当然接口的性能也达到了前所未有的快速和高效,基本都是 10ms 左右。


2.2 如何查询


Redis 的查询方式比较单一:通过唯一 key 去查询 value。这种查询方式在简单的唯一值查询中比较有效,但是当遇到,同一个数据源多关键字查询的时候,就得维护多份数据源。举例:在价格趋势的接口中,我们提供了多种价格趋势组合:国内、国际、单程、往返、航线、航班。如果使用 redis 存储,需要维护同一份数据多种 key 的存储方式,极大地浪费了存储空间。


Redis 还有一个问题是时间范围的筛选,还是在上面的价格趋势接口中,需要按照查询时间返回历史同期在一定起飞时间范围的价格数据,所以我们需要存储多个时间日期的数据(当然也可以用 set 等结构,但是会面临如何删除过期数据的问题),同时在查询的时候需要循环取一定时间范围的价格。


2.3 如何维护

1)接口维护


大数据基础平台团队一共维护了几百个接口,其中 1/3 的接口是提供数据给调用方的,这当中又有一些接口只是提供简单的查询操作,但就是这些简单的查询,需要我们提供海量的数据存储、快速精准的查询。每个接口的上线需要经过项目资源申请(包括机器资源、人员资源)、数据同步、开发、测试流程,最后才能上线。一整套流程走下来,耗费 2-3 天/人,而且基本上都是是重复性的工作。如何解放这些人力和机器资源,就变得很迫切了。


2)数据同步


提供给外部使用的数据大部分都是存储在 hive 中,在不使用 presto api 的方式访问时,我们需要将 hive 数据导入到 redis 或者 mysql 中,供接口访问。在 zeus 平台上,我们建立了各种导数据的流程,如何将这些简单、重复度高的流程自动化呢?


整个接口的架构图如下:



图 1 redis/mysql 作为主要存储的架构图


三、机票大数据接口的大道之旅


认真研究了接口调用方本身的性能,我们发现调用方在调用第三方提供的接口时,基本都是异步进行的。如果把调用方调用的所有第三方接口当成一个木桶,机票大数据基础架构团队的接口就是其中的一块木板,只要不是最短的木板,就可以在保证性能的情况下降低整个接口的响应时间(当然这不是技术上的退步,而是选择合适的方案)。通过上面的存储选型对比之后,发现在 100ms-500ms 这个性能段里面没有一个合适的存储方案能够提供。


我们调研了几种 NOSQL 数据库方案,综合存储、查询等指标发现 CrateDB 比较符合现实需求。将几种存储做了一个对比,如下:


对比RedisMongoCrateDB
查询速度<10ms100ms~500ms100ms~500ms
SQL不支持不支持支持
数据结构化不支持支持支持
存储机制hashSharding+partitionSharding+partition
资源利用内存资源硬盘+内存硬盘+内存
数据可重复使用不支持,单一固定key支持支持


3.1 CrateDB 介绍


CrateDB 是构建在 NoSQL(ElasticSearch)基础之上的分布式 SQL 数据库,它结合了 SQL 的通晓程度和 NoSQL 的可扩展性和数据灵活性:


a、使用 SQL 处理结构化或非结构化的任何类型的数据


b、以实时速度执行 SQL 查询,甚至 JOIN 和聚合


c、简单缩放


3.2 CrateDB 与接口存储


CrateDB 很好地解决了 100ms-500ms 性能段的短板,并且使用磁盘+内存的方式存储数据,减少了内存的使用。目前在我们生产时间中,通过 12 台 8 核 24G 虚拟机 30%的磁盘空间覆盖了 10 亿数据(如果是 redis 至少需要 300G 的内存,如果做 slave,容量 double)。


3.3 CrateDB 与接口查询


CrateDB 提供了如 MYSQL 的表、字段等概念(底层使用 ES 存储引擎),我们可以将同一份数据源进行多维度的操作,比如上述讲到的价格趋势里面基于航线和航班的价格趋势,这两个接口可以使用同一套数据源,因为航线的价格可以基于航班数据进行聚合操作,这样就大大减少了冗余的数据。同时类 MYSQL 表的特性使得时间范围的查询变的 so easy 了。


3.4 CrateDB 与接口维护

1)与接口结合使用


因为 CrateDB 支持标准的 SQL,我们开发了机票大数据基础平台的通用性 api 系统,通过将取数逻辑 SQL 化的方式,同时利用 qconfig api 将新增的数据需求进行模板化、配置化,统一了接口代码开发的流程。配置页面如下:



图 2 接口配置页面

2)数据同步


通过 zeus api 将同步数据流程模板化,配置页面如下图。并且在 zeus 平台上,使用 spark shell 方式将 hive 数据导入到 CrateDB 中,抛弃了以前 jar 包的方式。这种方案可以在几分钟内导入千万级的数据(取决于 CrateDB 表的数据结构,减少索引、doc_values 以及刷新间隔会都有利于导入的速度)。



图 3 zeus 流程配置页面


3)容器化


如何更加有效地管理、维护 CrateDB 集群?为此我们上了 k8s,将 CrateDB 容器化。为了更好地管理这些 k8s 集群,引入了 rancher,rancher 是开源的企业级容器管理平台,通过 rancher,我们再也不必自己去从头搭建容器服务平台。同时 rancher 提供了在生产环境中使用的管理 docker 和 kubernetes 的全栈化容器部署与管理平台。将网络、磁盘虚拟化之后,资源的利用率大大提高,减少了虚拟机的使用。自动水平扩展,以及 pod 的监控等特性,都极大地提高了维护 CrateDB 的能力,我们管理的 CrateDB 集群如下:



图 4 rancher 管理 CrateDB 集群图

3.5 与接口结合的其他优势


1)存储机制多样化,底层的存储机制支持多样化的数据类型,同时支持 partition、sharding;


2)数据结构化,CrateDB 提供结构化的展示,有利于数据的可视化以及降低非技术人员的理解难度,解决了 redis 可读性差的问题;


3)存储可靠性,数据持久化存储在磁盘上,支持 replica,相比于 redis 的内存存储更加可靠(当然 redis 也可以落盘,但这就会限制 redis 的速度);


4)成熟的优化机制,针对 es 的优化我们有丰富经验的技术人员支持。举个例子:我们有 9000 万+的用户行程数据,因为数据比较详细,字段的内容比较庞大。通过去掉部分字段的索引,去掉 doc_values 等操作将数据存储大小从 90G 降到了 30G,同时也提升了搜索速度。


目前在生产上我们部署了 2 个 CrateDB 集群,其中一个集群由 12 台 8 核 24G 内存虚拟机组成。在集群中建立了 12 个数据表,存储了 20+亿条数据,经受了生产的实际考验,接口性能指标如下:


数据量99line95lineavg查询特点描述
10亿+200ms80ms10ms多关键字、时间范围查询整个集群请求量1500qps
500w+150ms50ms10ms多关键字查询、排序单个表请求量400qps
9000w+200ms100ms60ms多关键字查询单个表请求量10qps


性能满足了大部分调用方的使用需求,同时系统数据上线的流程由以前的申请资源、开发代码、测试、上线,到现在的系统配置、测试、上线,释放了部分的开发资源,并且保证了数据的质量。接口上线时间由以前平均 2-3 天,缩短为 2-3 小时。新的接口架构图如下:



图 5 CrateDB 作为主要存储的架构图

四、安装部署


CrateDB 有官方版以及社区版,为了更好地进行自维护,我们选择了社区版(通过源码编译)。CrateDB 的部署与 ES 的部署基本一致。需要注意的是,在分配内存的时候尽量多留一些内存给系统,这将有利于数据查询速度。部署后的 webui 如下:



图 6 CrateDB webUI

五、数仓中的实现


目前在数仓中的应用主要体现在各种指标 dashboard、metrics 的展示,比如 fltinsight。与以往通过 presto 接口获取数据的方式相比,更加直接、高效。而且 CrateDB 支持各种字段的聚合、统计,是各种指标存储、展示的不二之选。当然后续数仓组也会在数据展示这一块全面推广 CrateDB 的使用。


六、小结


没有完美的存储方案,只有最适合的存储方案。通过上述机票大数据平台在数据存储这一块的实践经验,相信每个团队在面对选择存储方案的时候,结合自身需求去选择适合自己的存储技术方案,达到“大道”。


文章转载自: 携程技术(ID:ctriptech)

原文链接:CrateDb在携程机票BI的实践

2021 年 1 月 15 日 07:00856

评论

发布
暂无评论
发现更多内容

初步解析 Elasticsearch Document 核心元数据

escray

elastic 日更挑战 28天写作 死磕Elasticsearch 60天通过Elastic认证考试

android开发培训!深度解析跳槽从开始到结束完整流程,系列篇

欢喜学安卓

android 程序员 面试 移动开发

架构师训练营第三周作业 - 学习总结

阿德儿

阿里云 RTC QoS 屏幕共享弱网优化之若干编码器相关优化

阿里云视频云

WebRTC 音视频会议 网络 RTC 视频会议

【Java虚拟机】- Java虚拟机之逃逸分析

双木之林

DDD分层架构最佳实践

程序员小毕

Java 编程 架构 面试 DDD

首次公开!阿里巴巴技术团队共同携手编写的“大厂面试参考指南”v1.0版本

Crud的程序员

Java 架构 Java 面试

区块链电子合同技术方案,区块链电子合同存证

135深圳3055源中瑞8032

区块链数字货币交易所系统软件APP开发

开發I852946OIIO

系统开发

Kafka 中的消息存储在磁盘上的目录布局是怎样的?

码农架构

Java kafka 架构 设计模式

【Redis】- Redis Cluser之数据分布

双木之林

认识产品经理(第一节)

让我思考一会儿

Hadoop编程实战:HDFS用户Shell详解

罗小龙

hadoop 最佳实践 28天写作 hdfs shell

Spring全家桶笔记:Spring+Spring Boot+Spring Cloud+Spring MVC

Crud的程序员

Java spring 程序员 架构

EXCEL数据太“脏”无从下手?何须用python,ETL一分钟搞定

智分析

Excel ETL

无敌!全面对标字节跳动2-2:算法与数据结构突击手册(leetcode)

Java成神之路

Java 程序员 架构 面试 编程语言

新“庖丁解牛”,华为云技术全牛图解

陈泽涛

蝉联 Apache 最活跃项目,Flink 社区是如何保持高速发展的?

Apache Flink

flink

第一周作业

Esther

一文读懂 Serverless,将配置化思想复用到平台系统中

Serverless Devs

Serverless 云原生 PaaS

二面阿里Java岗惨败,问的全是源码、Redis、中间件、Dubbo,整吐了

Java成神之路

Java 程序员 架构 面试 编程语言

天猫双十一订单峰值58.3万笔/秒的背后,秘密都在这份文档里

Java成神之路

Java 程序员 架构 面试 编程语言

Android经典面试:46道面试题带你了解中高级Android面试,附面试题答案

欢喜学安卓

android 程序员 面试 移动开发

快了何止100%?阿里巴巴Java性能调优实战(2021华山版)PDF版开源

Java架构追梦

Java 阿里巴巴 架构 性能优化 华山版

《价值》- 护城河(6)

石云升

读书笔记 护城河 28天写作

Redis 学习笔记 08:数据结构与对象小结

架构精进之路

redis 日更挑战 28天写作

江苏智慧平安社区建设,智慧社区管理平台开发

135深圳3055源中瑞8032

架构师训练营第三周作业 -命题作业

阿德儿

Web UI自动化测试之元素定位

行者AI

软件测试 测试 自动化测试

AQS之ReentrantReadWriteLock精讲分析上篇

伯阳

AQS 读写锁 ReentrantReadWriteLock 多线程与高并发 lock

吉他谱怎么看?看谱大攻略送上!

懒得勤快

音乐 吉他学习 吉他谱 看谱

CrateDb在携程机票BI的实践-InfoQ