共计 4279 个字符，预计需要花费 11 分钟才能阅读完成。
作者：向伟靖，37 手游大数据开发工程师
37 手游应用 StarRocks 已有半年多，在此期间非常感谢 StarRocks 团队的踊跃帮助，感触到了服务速度和产品速度一样快，辅导咱们解决了产品应用上的一些问题。
首先介绍下 37 手游的背景。37 手游次要专一于挪动端游戏发行和游戏经营，胜利发行经营了《斗罗大陆：魂师对决》、《云上城之歌》等游戏。数据是游戏经营的基石，查问效率对业务人员的体验感触十分重要，因而晋升查问效率是咱们团队始终致力的指标。
本次分享次要内容蕴含：37 手游的数据架构、StarRocks 对数据架构产生的影响，以及 StarRocks 在用户画像实际上的利用。
01
业务和技术的痛点
—
在业务上，咱们遇到了以下几个次要痛点：
第一，数据分析性能有余。因为咱们游戏用户维度指标特地多，数据须要简单关联查问，能力失去相应的剖析指标。有时候甚至还须要传说中的 SQL Boy 帮忙取数。还有就是高并发查问工夫周期特地长的数据，响应特地慢，例如 LTV 这些剖析指标，就须要查问数据周期特地长。这些也是业务常常反馈比拟多的问题。
第二，实时剖析场景有余。次要体现在经营推广等数据实时荡涤呈现提早，影响到游戏经营和广告投放的策略。
同时，咱们还面临几项次要的技术难点：
第一，大数据产品简单组件多，运维老本高。
第二，实时同步 MySQL 数据到 OLAP 查问引擎秒级查问。以后局部业务数据存储在 MySQL 上须要同步到 OLAP 进行提速查问，所以技术须要保障业务数据一致性、时效性和查问性能。
第三，千万级维表数据关联查问性能低下。
第四，业务倒退使数据疾速收缩，线性扩容老本高。
02
旧数据架构和 OLAP 选型
—
首先，咱们先看看以下 37 手游的数据架构。这是一个比拟经典的实时离线架构。从下往上看，离线传统的 Apache Hadoop（以下简称 Hadoop）集群加上了数据湖 Apache Hudi（以下简称 Hudi）组件和 Apache Kafka（以下简称 Kafka）音讯队列组成存储层，Apache Hive（以下简称 Hive）和 Apache Flink（以下简称 Flink）组件组成实时离线解决引擎层，剖析层就是泛滥且简单的 OLAP 组件，业务层更多是提供接口、BI 报表展现等性能。其中剖析层 OLAP 组件泛滥且数据分析绝对扩散，就意味着应用这些组件老本高。
以下是咱们用过的 OLAP 组件，各有优缺点：
1）Apache Kylin（以下简称 Kylin）：作为国产第一个 Apache 顶级我的项目，过后让国内泛滥开发者看到了原来咱们能够来到源我的项目这么近。现在国内泛滥优质开源我的项目百花齐放，比方咱们应用的海豚调度零碎、StarRocks 等。Kylin 利用空间换取工夫的形式，提前预构建好数据进行疾速查找。这就使得构建数据须要耗费大量计算资源和存储资源，时效性也比拟差，缓缓变得不太实用 37 手游的场景。
2）ClickHouse：这匹俄罗斯黑马的单表查问性能特地强悍，然而随着业务的深刻应用，从单机到集群构建，发现其运维简单，且稳定性和数据一致性也有问题。这个时候就要依据咱们的业务诉求开始调研其余 OLAP 组件。
3）StarRocks：咱们是从技术博客上发现了 StarRocks。随着对 StarRocks 的零碎架构和产品个性深刻理解后发现，其产品能力根本解决了咱们的痛点。次要体现在以下四点：部署监控运维简略，兼容 MySQL 协定和规范 SQL 语法，大表多表关联查问性能优异，反对不同数据起源高效导入和反对数据实时更新。
通过业务数据导入进行测试，StarRocks 根本满足咱们的测试性能基准。当火线上部署了 3 台 FE 和 5 台 BE，FE 的硬件配置单台 8 核 32G，BE 的硬件配置单台 32 核 128G。以后集群绝对较小，前面随着业务迁徙会逐步申请扩容。
这里有一张简短的数据流程图，能够看出旧架构数据流向和应用的两头组件，这里应用 ElasticSearch 存储用户画像数据来提供服务利用查问，两头的 Kafka 作为音讯队列通过 Logstash 生产到 ElasticSearch。
为什么历史数据会推到 Kafka 上呢？
次要在于 ElasticSearch 读写性能瓶颈。开始咱们尝试了将离线的 Hive 表，通过内部表的形式间接同步到 ElasticSearch。在这种形式下，十亿级别历史数据初始化到 ElasticSearch，会导致其服务负载高、同步工夫特地长。因而才把历史数据推到 Kafka 利用其削峰填谷的能力，加重 ElasticSearch 的局部压力。然而实践证明减缓不了多少压力，另外业务读取和实时离线写入也会呈现因负载高导致业务查问超时的状况。
此外，ElasticSearch 不能满足简单关联聚合查问的需要，不同维度索引无奈关联并且没有弱小的 SQL 查问能力。ElasticSearch 的限度导致了在简单查问场景下不能满足需要。
简略总结一下画像选型的变更工夫线：
ElasticSearch 在用户画像利用应用工夫周期是比拟长的。因为 ElasticSearch 单索引能疾速满足简略的圈选人群需要。然而随着业务倒退，须要索引间简单关联剖析，此时 ElasticSearch 反对不了。
ClickHouse 会呈现大表关联查问性能低、数据一致性等问题。
最终 StarRocks 测试体现性能相当优异，千万级维表关联查问秒级返回，数据实时同步提早低等。
从上图能够看到，测试事实表数据量两亿多，维表数据量四千多万。ClickHouse 的关联查问工夫大略 50s 左右，StarRocks 关联查问在 1s 内，性能差别显著。ClickHouse 的关联查问是间接把维表数据全副读取进去进行匹配关联查问，而 StarRocks 对这块做了关联优化下推，这也体现了 StarRocks 大表关联查问性能优异。
03
替换 StarRocks 后的用户画像架构
—
替换为 StarRocks 后的数据架构新增了应用 FlinkCDC 实时同步 MySQL 数据到 OLAP 引擎上，这样就减少了关联数据的多样性。
读写性能大幅度晋升：1）满足 ElasticSearch 旧架构读写性能；2）内置多种导入形式，性能高效，测试应用 Broker load 导入 Hive 十亿级数据，120 分钟就能实现解决，资源占用低，也解决了旧架构读写的问题；3）减少了联邦查问性能，提供内部表连贯 Hive 等异构数据源查问减速。
关联查问性能优异：1）满足了画像不同维度数据的简单关联；2）测试 ClickHouse 关联查问千万级维度表，查问时长为 1min，而 StarRocks 是在 5s 内；3）画像时能够利用 Bitmap 位图技术对简单人群圈选进行提速。
上图是一个简略数据开发流向图，从 Hive 离线荡涤出用户画像纵表、宽表和根底维表。纵表就是一个用户、一个标签、一个值。例如，一条记录是，用户小明，标签 age，标签值 18。另外一条记录是，用户小明，标签 sex，标签值 man。
这在纵表中存有两条记录，在宽表外面构建，就只有一条记录，两列别离存取年龄和性别的标签值。而后把开发好的纵表同步到 StarRocks 上用于构建 Bitmap 表，宽表同步到 StarRocks 的主键表，维表应用 StarRocks 内部表连贯。实时数据同步到对应的根底数据表上用于关联查问。
1、用户画像 Bitmap 表的开发设计
基于数据流向，这里首先论述下 Bitmap 数据表的开发设计。上图展现了 Hive 明细纵表推送到 StarRocks 后的更新模型表。在 StarRocks 聚合模型的 Bitmap 表中，就有构建 Bitmap 表的一个 SQL 语句，到此 Bitmap 表构建设计已实现。
咱们在明细数据聚合表设计上遇到过一些性能问题。一开始，咱们依据 Hive 间接设计 StarRocks 更新表 Key 和桶程序别离是 uid，tag_type 这样的程序的。然而咱们构建 Bitmap 表的时候根本是应用 where tag_type in 的形式来查问构建的，导致每次读取 IO 根本打满，影响实时数据写入。起初，咱们从新设计表的 Key 值程序，把 tag_type 提到 uid 前，批改之后读取 IO 只占用 20% 以下了。
2、用户画像查问性能比照
再看下简略查问性能比照，以后明细纵表数据靠近六百亿数据，100 多个标签值，构建完 Bitmap 表后数据量在四十万左右。上图简略查问比照了 Apache Impala（以下简称 Impala）和 StarRocks 的 Bitmap 表的圈选速度，应用 StarRocks 后晋升了靠近 26 倍。
上图左是一个 Bitmap 表应用的 SQL 示例，左边是画像业务实现的 SQL 逻辑。右边示例中，应该填写其余维度画像的 Bitmap 表，或者填写其它根底数据表进行简单关联查问圈选，这样可能会更好地展示 StarRocks 劣势。
3、用户画像提供的根底查问服务
在基于 Bitmap 表实现的人群圈选的功能模块中，当初反对按规定或非规定创立人群包，自定义上传人群包，自由组合创立人群包。将来会反对外联更多数据。
咱们还间接应用了 StarRocks 提供的监控模版间接应用配置相干监控告警。下图是 StarRocks 实时生产 Kafka 监控面板。
04
瞻望
—
接下来咱们会有更多业务接入 StarRocks，替换原有 OLAP 查问引擎；使用更多的业务场景，积攒教训，进步集群稳定性。将来心愿 StarRocks 优化晋升主键模型内存占用，反对更灵便的局部列更新形式，继续优化晋升 Bitmap 查问性能，同时优化多租户资源隔离。
今后咱们也会持续积极参与 StarRocks 的社区探讨，反馈业务场景。之前我常常加入社区群进行探讨，在社区群里取得过很多技术上的反对和答疑。在此，感激流木大佬、颖婷等 StarRocks 社区搭档在技术上的急躁领导！
本文整顿自 37 手游 Meetup 直播
收看视频回顾请至：
https://www.bilibili.com/vide…
如需完整版讲师 PPT，请增加小助手微信 StarRocks-1，报暗号“37”
对于 StarRocks
StarRocks 创建两年多来，始终专一打造世界顶级的新一代极速全场景 MPP 数据库，帮忙企业建设“极速对立”的数据分析新范式，助力企业全面数字化经营。
以后曾经帮忙腾讯、携程、顺丰、Airbnb、滴滴、京东、众安保险等超过 110 家大型用户构建了全新的数据分析能力，生产环境中稳固运行的 StarRocks 服务器数目达数千台。
2021 年 9 月，StarRocks 源代码凋谢，在 Github 上的星数已超过 3000 个。StarRocks 的寰球社区飞速成长，至今已有超百位贡献者，社群用户冲破 5000 人，吸引几十家国内外行业头部企业参加共建。
