作者：周涛 同程旅行数据中心大数据研发工程师
同程旅行是中国在线游览行业的创新者和市场领导者。作为一家一站式平台，同程旅行致力于满足用户游览需要，秉持 “ 让旅行更简略、更高兴 ” 的使命，次要通过包含微信小程序、APP、轻利用及其他渠道在内的线上平台，为用户提供简直涵盖游览所有方面的全面翻新产品和服务抉择，涵盖交通、住宿、景点门票预订及各种配套增值游览产品及服务，旨在满足用户在整个旅途中一直变动的游览须要。目前，同程旅行的月沉闷用户已达到 2 亿多人。
为了晋升数据分析查问性能，同时升高人力和硬件老本，公司的出行、住宿和公共等多个业务线都已接入并应用了 StarRocks 技术。
同程旅行有多年的 OLAP 应用教训，随着业务增长和变动，促使咱们须要一直摸索更适合的组件来满足需要。在这方面，StarRocks 作为一款优良的数据库，在同程旅行的生产环境中失去了广泛应用，涵盖实时、离线和 Customer Data Platform（顾客数据平台，以下简称 CDP）等多个利用场景。
本文将从同程旅行 OLAP 平台演进、业务痛点和 StarRocks 是如何解决以后业务痛点这几个局部具体介绍 StarRocks 在同程旅行的生产落地实际。
同程旅行的 OLAP 平台演进
随着公司的业务变动和用户量的减少，数据量也在一直减少。数据分析场景变得越来越多样化，对实时剖析的时效性要求也更高了。为了更好地满足这些需要，同程旅行的 OLAP 平台也在一直演进，整体的倒退过程大抵分为三个阶段：
第一阶段：以 Druid+Kylin 为根底构建的数据分析体系，满足了过后对于离线数据分析减速的需要，但在应用过程中也逐步暴露出 SQL 剖析、联邦查问、BI 兼容等方面能力有余与 CUBE 运维老本较低等一系列问题；
第二阶段（引入 StarRocks 前）：在这一阶段，咱们采纳 ClickHouse+Greenplum 撑持实时、离线业务的剖析解决，在肯定水平上解决了上一阶段存在的问题；
第三阶段：由 StarRocks 作为对立的 OLAP 组件，缩小多组件的保护压力。同时重视在企业外部与相干数据平台的集成，晋升用户应用体验，升高用户组件应用和切换老本。
在阐明咱们为什么抉择 StarRocks 作为咱们新一代的 OLAP 组件前，咱们须要先理解原有平台架构的有余：
ClickHouse：次要用于用户行为轨迹和订单实时数据存储和剖析
Greenplum：次要用于公司外部的灵动剖析看板，做剖析报表应用
如上图所示，在原始架构中，对于实时场景，业务数据通过 Kafka 传入 Flink，在 Flink 中进行荡涤、打宽表等逻辑解决，之后将后果数据导入 ClickHouse 中；对于离线场景，数据对立存储在 HDFS 中，通过 Hive+Spark 进行荡涤解决后，将后果数据传入 Greenplum 中。
实时场景
次要波及业务订单数据，数据能够通过前端用户埋点到 Kafka，或者订阅业务订单数据库 Binlog，实时写入到 MQ，而后应用 Flink SQL，关联维度表，将数据打宽，最初写入到 ClickHouse 中。
离线场景
将实时的用户埋点数据或订单库离线同步数据写入到 HDFS 中，而后通过离线调度做 ETL 数据荡涤，再搬运到 ClickHouse 或 Greenplum 中。然而，在应用过程中，咱们发现实时和离线拆散架构存在一些问题：
拆散架构导致开发应用极度不不便，且节约计算存储资源；
组件技术栈不对立，导致业务人员须要相熟多种语法；
多组件造成了极高的运维老本。
为解决在应用 ClickHouse、Greenplum 过程中遇到的性能、运维和老本等各方面的问题，咱们进行了一些调研，开始比照和理解一些新的 OLAP 组件。接下来，咱们将进一步阐明应用 ClickHouse 和 Greenplum 架构所带来的业务痛点。通过这些问题的论述，咱们能够更好地了解为何须要寻找新的解决方案。
01 ClickHouse + Greenplum 架构带来的业务痛点
目前，同程 OLAP 组件被宽泛应用，并已集成到实时开发平台、离线开发平台、灵动剖析、数据地图和疾速取数等多个平台零碎中。在业务方面，次要波及以下三类场景：
1.1 实时数据分析
在应用实时数据分析的业务场景，咱们次要针对用户行为埋点、用户实时订单等数据进行冷热存储。实时热数据须要存储 30 天至一年不等的工夫数据，用于高性能要求的实时统计分析；历史离线数据存储在 HDFS。在查问实时数据时，如果波及多表关联或者关联历史数据时，以后组件性能无奈满足，须要提前离线荡涤，导致数据时效性较低。
1.2 灵动数据报表
在应用灵动数据报表的业务场景，用户在离线数仓中荡涤出 DWD 或 ADS 层表，通过离线开发平台导入到 Greenplum 中，而后在灵动剖析中配置数据集，以利落拽的模式生成看板，提供给剖析决策应用。然而，在顶峰期间，咱们常常遇到查问速度慢甚至查问超时等问题，这给业务带来了困扰。
1.3 用户画像 & CDP
在用户画像和 CDP 的场景中，咱们会依据用户根本信息、生产数据和行为数据等生成对应标签数据，以创立用户画像，并进行人群圈选和漏斗剖析等。
之前咱们应用了 ClickHouse 作为存储剖析引擎，但随着 CDP 需要的变动，业务场景更加简单，波及到多表关联场景以及宽表和 BitMap 关联场景，用户对实时剖析的查问性能提出了更高的要求。通过测试，ClickHouse 已无奈很好的满足。
针对以后 ClickHouse+Greenplum 体系存在的各种问题，咱们开始了基于 StarRocks 构建剖析体系 3.0 阶段的降级演变。
StarRocks 在同程旅行的利用与实际
01 抉择 StarRocks 的起因
为了解决上述问题，咱们谋求在新的 OLAP 组件中实现简略、高速和对立的特点（包含反对联邦剖析）。为此，咱们进行了 StarRocks、ClickHouse、Greenplum 和 Presto 等 OLAP 组件的比拟。咱们比拟了数据摄入速度、查问性能、内存占用率、保护老本和易用性等指标。通过这些比拟，咱们心愿找到最适宜咱们业务需要的 OLAP 组件。
下图展现了这些组件的具体比拟后果：
- 查问性能优异：
StarRocks 是一款分布式列式存储剖析数据库，它具备十分高的查问性能，尤其实用于实时数据分析和查问场景。与 ClickHouse 相比，StarRocks 在多表联结查问方面体现更杰出，尤其在 Primary Key 模型方面，其在实时动静更新和查问性能方面都体现优异。 - 保护难度低：
StarRocks 由 FE 和 BE 两类组件组成，不依赖于第三方组件，能够开箱即用。而且，StarRocks 具备良好的可扩展性，集群扩缩容不便，能够依据需要动静扩大集群规模，灵便进步零碎性能。此外，数据能够在节点之间主动平衡，无需人为干涉。
- 不便易用：
StarRocks 采纳规范 SQL 协定且兼容 MySQL 协定，能够轻松集成到现有零碎中。此外，在实时写入方面，官网也提供了 flink-connector-starrocks，写入可实现 exactly-once。另外，StarRocks 还具备不便的联邦查问性能，防止了数据搬运带来的资源耗费，从而进步了零碎性能。通过多方比拟，咱们最终抉择了 StarRocks 作为对立的 OLAP 组件，并预计在将来逐渐实现对立 OLAP 层的工作。
02 StarRocks 的引入
同程旅行次要在以下三个场景中应用 StarRocks：实时数据分析、离线报表和 CDP 零碎。随着 StarRocks 的接入，新的数据利用流程架构如下：
2.1 应用 StarRocks 解决以后痛点
1）实时数据分析的整体时效性晋升
在实时利用场景中，业务数据进入到 Kafka 或者 TurboMQ，而后通过 Flink 工作或 Flink SQL 工作进行业务计算转换，最终通过 flink-starrocks-connector 实时写入到 StarRocks，进行实时指标统计或者实时数据分析。实时链路中不再波及关联打宽，缩短了链路，晋升了整体的时效性。同时，StarRocks 采纳星型模型组织数据，缩小数据冗余存储。
以下是咱们理论中的一个 Flink SQL 案例：
通过将 StarRocks 集成到实时开发平台，用户能够轻松疾速地将实时数据导入 StarRocks 并进行应用。
2）离线报表查问性能大幅晋升
咱们曾经胜利将 StarRocks 数据源集成到灵动剖析零碎中。当初能够将 StarRocks 中的表创立为灵动中的数据集，进行剖析看板配置，并实时写入数据。此外，无需反复荡涤，还能够间接进行报表配置。因为 StarRocks 反对规范 SQL 并兼容 MySQL 协定，因而系统集成 StarRocks 数据源十分便捷。切换引擎后，与 Presto 和 Greenplum 相比，报表查问性能大幅晋升（在某些理论场景中，相较于 Greenplum，查问性能晋升近一倍）。
下图是对 14 个 SQL 耗时进行统计比照：
3）CDP 零碎查问效率进步
CDP 是一种数据管理平台，它能够集成多方数据，帮忙企业更好地理解用户行为、爱好和需要，从而制订更加精准的经营策略。CDP 零碎上线后，能够服务于公司各个事业部，对用户进行分层或保留人群进行经营，从而极大地晋升了经营效率并升高了经营老本。
CDP 零碎的具体工作流程如下：
1）数据导入：
以后先知零碎有 1000 多个历史人群须要作为人群圈选的条件，而这 1000 多个人群数据的导入耗时较高，存在性能瓶颈。通过调研，应用以下办法能够很好的解决这个问题：
- 将 String 类型的用户 ID 转换成 Long 类型的 oneId；
- 而后通过 Spark 工作将 oneId 转换成 Java 代码的 BitmapValue 对象；
- 在所有的雷同 key 的 BitMap 合并后，转换成 Base64string，这样将雷同的 key 的数据合并成一条数据，导入到 StarRocks 中。
通过验证，采纳以上办法能够大大提高数据导入性能，将 1.5 亿条数据的 10 个工作同时导入的耗时从 10 分钟以上降落到 10s 以内，并且能够缩小导明细数据的集群资源耗费。
如上图所示，依据数据监控显示，红框内时间段是明细导入的网络传输量，而其余时间段为 BitMap 合并 Base64 后的传输量。这两者之间的传输量相差约 10 倍。针对这个问题，咱们正在致力优化导入代码，并将其整顿成 Demo，以便提交给社区供大家参考应用。
2）人群圈选：
接下来咱们须要通过 BitMap 的函数操作，对用户抉择的条件进行人群圈选。通过将条件组合成 StarRocks 对应的 BitMap 的 and、or、union 等函数，简略的查问能够在 3 秒以内得出后果。即便是简单的（例如波及宽表与多个 BitMap 表的关联查问）且数据量大的查问，也都能够在 10 秒以内失去后果。
3）人群保留：
这一步将圈选的后果人群 BitMap 转换成一个明细表，而后再通过 export 语句形式，将表的数据导入 HDFS 进行输入利用。下述是理论利用中的人群分层迁徙桑基图的 SQL 示例：
对应后果图：
该 SQL 中蕴含了 BitMap 与一般宽表的关联操作，以及三个亿级别大表的关联操作，整体能够在 5 至 10 秒内计算实现。
将来布局
更多业务场景推广落地
在公司内，咱们将持续扩充和推广 StarRocks 的应用，以替换其余业务中遗留的 ClickHouse 和 Greenplum 组件，缩小多组件的保护压力。同时重视在企业外部与相干数据平台的集成，晋升用户应用体验，升高用户组件应用和切换老本。
上云
将 StarRocks 部署在公司的 Kubernetes 公有云中，以进步集群的扩展性和灵活性，并且能够依赖于 Kubernetes 的容错机制，主动监测和替换故障节点，晋升集群可靠性和稳定性。目前，咱们曾经实现了开发，进行到了测试验证阶段。后续咱们也将继续跟进测试 StarRocks 提供的云原生能力。
存算拆散个性的应用
在离线报表利用中，咱们打算测试应用行将推出的 3.x 版本。依据其存算拆散的能力，在不升高查问性能的条件下，能够大大减少离线数据同步的工作量。
与社区共赢
咱们将持续保持与社区的沟通，踊跃地将应用体验和性能测试反馈社区。通过与社区的单干，实现双赢的指标。