科技说 | TiDB 在海航易建科技与香港航空研发收益支持系统过程中的实践
今天，小编要和大家聊聊……
对，聊聊技术！
em……我们易建流弊的技术这么多！
小编会跟大家聊哪一个呢？
先来播报一则重要消息~
2017年12月，大客户事业群-智慧航旅事业部的航司收益支持产品团队为香港航空建设的收益支持系统正式上线！后续易建团队将与港航持续合作，逐步迭代落地新一代航司收益支持系统。
目前，该系统第一阶段建设工作已经完成。面对客户已有的海量数据、飞速增长的并发量、数据量及后续核心业务的海量数据分析预测，传统的数据库厂商解决方案已无法满足。通过多方的考察和评估，易建团队选择了目前互联网中分布式数据库解决方案厂商核心三家厂商之一的TiDB作为核心数据解决方案。
通过实际使用，该解决方案确实很好的解决了我们在海量数据处理上的瓶颈，同时也成为收益支持系统在海量数据处理方面相对于其他竞品的优势，提升了我们系统的竞争力。目前国内外众多知名互联网公司（Mobike、Qunaer、今日头条、360等等）也积极使用该方案解决各自海量数据处理的瓶颈问题。
接下来
小编将为大家详细叙述该解决方案的思路和优势
走过路过不要错过~
背景介绍
收益支持系统（Revenue Support System，简称 RSS）是易建科技与香港航空共同研发的基于大数据实时分析处理的航空业务支持和决策系统。RSS 的目标在于根据顾客需求进行市场细分和定价，在科学分析的基础上通过价格和座位库存控制手段平衡需求和供给的关系，将产品销售给合适的旅客，其核心价值在于支撑和帮助航空公司业务人员和决策者进行业务管理和科学决策。 RSS 在航空公司角色和定位，决定了该系统对 OLAP 和 OLTP 的操作在准确性和实时性方面具有很高的要求，并且由于航空公司每天产生海量的订票、值机、离港和财务数据，使得要求系统在数据存储方面要有很好的水平扩展能力。
那么我们易建团队是如何研发成功的呢？
中间遇到了怎样的苦难？是如何克服的？
跟着小编一起来揭秘啦！
1
前期方案前期我们主要使用 MySQL 数据库,但是单表记录大于2000 万行时，现有的业务报表查询和导出操作明显变慢，通过各种sql调优和代码优化手段，也无法继续满足服务等级协议，只能通过分库分表来解决，但是这会增加的后续业务逻辑开发复杂度与数据库运维困难。后来，随着业务的深入和数据的积累，代理人在全球各个全球分销系统（Global Distribution System，GDS）中的订座数据数据（Marketing Information Data Tapes，MIDT）就近2年的数据就超过 3.8 亿行，后续会同步近10年的数据，初步预估单表数据量将突破10亿条数据，并且后续每年的正常量可能会突破2亿条，如果继续使用 MySQL，必然面临着更细粒度分库、分表的难题，而且当前业界很多分表分库的中间件对 OLAP 支持的并不完美,而且很难满足复杂的 OLAP 需求，并且需要进行分表策略的额外配置。这样必然加大了开发和运维的难度和降低了开发的灵活性。
在这个过程中，我们曾经使用 HDFS + Hive + Spark + Kylin 作为大数据解决方案，但是这个方案对于实时的OLTP却满足不了。
为了满足两者的需求，我们需要把一份大数据存储两份，MySQL + 分表中间件做 OLTP 操作，HDFS + Hive + Spark + Kylin 做 OLAP 分析。
2
茅塞顿开在业务遇到不可妥协的技术瓶颈后，我们重新评估业务模型，发现对于数据库的选型必须满足：
❖ 支持业务弹性的水平扩容与缩容；
❖ 支持 MySQL 便捷稳定的迁移，不影响线上业务；
❖ 支持 SQL 和复杂的查询，尽量少的改动代码；
❖ 满足业务故障自恢复的高可用，且易维护；
❖ 强一致的分布式事务处理；
为了解决上述问题，我们发现了 TiDB、CockroachDB与oceanbase这三款分布式的数据库。由于CockroachDB是支持postgresql数据库，我们是mysql的协议，oceanbase发布在阿里云，我们的数据属于收益核心数据需要发布在集团内部，这样一来Tidb成了我们选择。TiDB 数据库完美的支持了 MySQL 的 SQL 语法，它可是让我们不改变平时用 MySQL 的操作习惯。并且能够很好的满足我们的OLTP需求和复杂的 OLAP 的需求。另外 TiSpark 是建立在 Spark 引擎之上的，Spark 在机器学习领域上还是比较成熟的。考虑到收益系统未来会涉及到一些预测分析，会需要用到机器学习。综合这些考虑，TiDB + TiSpark 成为了我们首选的技术解决方案。
后续我们了解到饿了么的80%的核心流程都跑在tidb的高性能集群上面，还有新一代的互联网代表企业摩拜、今日头条，以及机票行业的qunar都有tidb的深度应用。
那么，在解决了瓶颈之后
易建团队取得了怎样的成果呢？
TiDB项目在世界上最流行的开源代码托管平台GitHub 上共计已获得10000+ Star，项目集合了150 多位来自全球的Contributors (代码贡献者)。
TiDB是 PingCAP 公司受 Google Spanner / F1论文启发而设计的开源分布式 NewSQL 数据库。TiDB 具备如下NewSQL 核心特性：
❖ SQL 支持 （TiDB 是 MySQL 兼容的）
❖ 水平线性弹性扩展
❖ 分布式事务
❖ 跨数据中心数据强一致性保证
❖ 故障自恢复的高可用
TiDB适用于 100% 的 OLTP 场景和 80% 的 OLAP 场景。 对业务没有任何侵入性，能优雅的替换传统的数据库中间件、数据库分库分表等 Sharding 方案。同时它也让开发运维人员不用关注数据库 Scale 的细节问题，专注于业务开发，极大的提升研发的生产力。
参考：https://pingcap.github.io/docs-cn/overview
TiDB的架构
TiDB 集群主要分为三个组件：TiDB Server、TiKVServer、PD Server，整体实现架构如下：
TiDB 整体架构图
TiDB Server
TiDBServer 主要负责接收 SQL 请求，处理 SQL 相关的逻辑，并通过 PD 找到存储计算所需数据的 TiKV 地址，与 TiKV 交互获取数据，最终返回结果。 TiDB Server 是无状态的，其本身并不存储数据，只负责计算，可以无限水平扩展，可以通过负载均衡组件（如 LVS、HAProxy 或 F5）对外提供统一的接入地址。
PD Server
PlacementDriver (简称 PD) 是整个集群的管理模块，其主要工作有三个：
❖ 存储集群的元信息（某个 Key 存储在哪个 TiKV 节点）；
❖ 对TiKV 集群进行调度和负载均衡（如数据迁移、Raft group leader 迁移等）；
❖ 分配全局唯一且递增的事务 ID；
TiKV Server
TiKVServer 负责存储数据，从外部看 TiKV 是一个分布式的提供事务的 Key-Value 存储引擎。存储数据的基本单位是 Region，每个 Region 负责存储一个 Key Range 的数据，每个 TiKV 节点会负责多个 Region 。TiKV 使用 Raft 协议做复制，保持数据的一致性和容灾。副本以 Region 为单位进行管理，不同节点上的多个 Region 构成一个 Raft Group，互为副本。数据在多个 TiKV 之间的负载均衡由 PD 调度，以Region 为单位进行调度。
参考：https://pingcap.github.io/docs-cn/overview
TiDB在易建
RSS 系统的架构如下：
RSS 系统的架构图
我们的tidb集群共有5台高性能的海航云服务器来提供服务，经过测试write性能可以稳定的做到1万TPS，同时，read性能可以做到0.5万TPS，后续升级到SSD硬盘将能够提高更高的读写性能。使用了 TiDB 后，我們不需要再考虑分表分库的问题，因为数据在一起，也不用考虑数据同步的问题。近10 亿行数据都可以复用以前的 MySQL 代码，进行 OLAP 分析也比上一代收益系统提速近20倍，同时，免去了数据同步的可能存在的问题。而且也能很好的满足我们 OLTP 操作的需求，懂得 MySQL 的开发人员都可以轻松的进行大数据开发，没有学习门槛，既节省了开发成本，又降低了数据运维成本。
后记
部署tidb近3个月来，收益系统的数据量已经增长近1倍达到5亿的数据量，近10张千万级别的中间表数据，期间我们做过tidb的扩容与版本升级，这些操作对业务来讲都是完全透明的，而且扩容与升级简单。我们可以更加专注业务程序的开发与优化，无需了解数据库分片的规则，对于快速变化的业务来说是非常重要的。同时，由于tispark的整合可以再同一个集群里面分析海量的数据并将结果无缝共享，对于核心业务的应用的开发来讲是非常方便的，由于能够快速响应业务的需求对于当前激烈竞争的航空业来说，提升了航空公司自身的核心竞争力。
以上内容均由易建科技技术专家
王碧虹提供
版权所有，翻版必究！
作者介绍王碧虹, 海南易建科技股份有限公司架构师,2017年初加入易建科技，具有十年软件开发经历。主要参与了供销大集O2O商城、B2C商城等的性能调优及架构优化、航空收益系统的开发。现在专注于大数据分析、分布式系统方向。
◆ ◆ ◆ ◆
扫描上述二维码，关注最新鲜的科技资讯