共计 6867 个字符，预计需要花费 18 分钟才能阅读完成。
作者：何启航，美团餐饮 SaaS 数据专家（文章整顿自作者在 StarRocks Summit Asia 2022 的分享）
随着社会经济的倒退，餐饮连锁商家越来越大，“万店时代”降临。对于美团餐饮 SaaS 来说，传统的 OLTP 引擎曾经无奈满足以后数据生产和查问场景，亟需一款 OLAP 数据引擎解决数据查问复杂度大幅提高、数据价值开掘能力有余等痛点。
通过多方测试比对，美团餐饮 SaaS 抉择了 StarRocks 来构建商家数据中台。通过一段时间的摸索，StarRocks 极速查问、简略部署、高效运维等特点，很好满足了美团商家数据中台的需要，查问性能晋升了 28 倍以上。本文将从业务介绍、技术选型、数据中台、建设成绩等四个方面，介绍美团餐饮 SaaS 如何基于 StarRocks 为商家构建数据中台。
业务介绍
首先，概要介绍一下美团餐饮零碎，其应用的数据产品、根本的零碎架构以及业务所面临的痛点。
美团餐饮零碎
上图左侧展现了美图餐饮零碎的性能全景图。能够看到其性能十分丰盛，toC 的局部包含扫码点餐、外卖、团购等；toB 的局部包含老板看到的一些经营剖析、财务管理、进销存等。依据场景，零碎分为线下和线上两个局部：线下，为餐饮商户提供餐厅数字化解决方案，帮餐厅实现从前厅治理、后厨生产治理、会员治理、线上经营治理，到供应链治理的整套数字化经营；线上，实现餐厅和平台的买通，帮忙餐厅链接顾客，帮忙餐饮商户理解顾客、商圈，辅助商业决策，并为顾客带来更好的生产体验。数据产品
上图展现了美团餐饮 SaaS 两大类数据产品的截图，左侧是外围报表产品，右侧是智能利用。能够看到报表品种很多，有汇总表、明细表、业务预警表、财务统计表等。智能利用的截图是一个商家选址的利用。商家能够通过地图去抉择一块区域，而后依据一些标签，比方业态、流量等去抉择适合的经营地址。
咱们数据产品的使用者包含厨师长、收银员、老板、店长、财务，业务场景包含：经营剖析：如剖析营业额、支出等。
- 智能决策：利用剖析后果进行智能决策，比方为老板举荐什么菜卖的好，该如何配置套餐等等。
- 业务预警：老板能够配置一些阈值，比方收营员一天返结多少钱、退账多少钱，一旦达到阈值就要告诉老板及财务对账。
-
财务对账：一些比拟大的商家每个月或者每个季度都有专门的财务进行对账。
以上场景决定了咱们的业务具备以下特点：数据品质高迭代效率高查问体验好数据体量大其中，数据品质高是十分重要的一个特点。美团餐饮数据产品不同于个别的大数据产品，个别的大数据产品次要是作剖析决策应用，而咱们的场景中除了剖析决策还要财务对账。财务对账是和钱挂钩的，算错一分一厘都有可能引起客诉，重大状况还会引起资损，所以咱们这里对数据品质要求十分高。这也影响咱们后续的技术架构选型，以及整体的零碎设计。零碎架构
咱们整体中台的架构和市面中台的架构基本一致，最上面是业务数据，从下往上，依据数据处理流程分为以下几层：
第一层是数据同步层，应用公司的同步组件将数据入仓，到数据生产层。
第二层是数据生产层，分为离线数仓和实时数仓两块。从上图能够看到，离线数仓和实时数仓都采纳了雷同的分层模型，这样的目标就是为了进步迭代效率。其余数据团队，实时和离线通常是两组人员来开发，离线可能应用 Apache Hive 等批计算引擎，实时可能抉择 Apache Flink、Apache Spark 等流式零碎进行烟囱式的实时指标开发。咱们为了放慢迭代效率，对立了离线和实时数仓，采纳了基于 SQL 的开发模式，让一些离线分层模型能够失去复用，从而进步了迭代效率。
第三层是数据存储层，抉择了稳定性比拟高的 MySQL 作为存储引擎，然而随着数据的持续增长，MySQL 会有性能和存储的瓶颈，因而也逐步引入了一些 HTAP 的存储引擎，如 TiDB。
第四层是数据服务层，提供一些原子的根底服务，撑持百花齐放的数据利用。
第五层就是数据应用层，包含报表和数据利用等。为了保证数据品质，在这套架构上还横向减少了监控零碎和稳定性保障系统。监控零碎次要是为了发现数据品质问题，并将其报给稳定性零碎；稳定性保障系统会辨认这些问题，而后抉择适合的形式去主动修复异样数据，进一步提高数据品质。业务痛点
随着业务倒退，连锁商家越来越大，咱们迈入了“万店时代”，大一点的连锁治理的连锁店可能有上万家，这样就带来两个痛点：
一，这些商家查问的数据量和复杂度大幅提高。具体有三个方向的挑战：数据存储量大（单表 10T 级别，数百亿数据）单次查问上千万数据量查问复杂度高，最多波及 5 张表 Join，数十字段 Group 聚合
二，这种级别的商家个别会有本人的研发和 IT 人员，所以他们也要求独立的数据价值开掘能力，本人去剖析数据集。这也带来了三个方向的挑战：异构数据源的交融，商家可能应用不同的零碎，比方收银应用美团，而供应链、财务、人力用的是其它零碎，在做数据分析时须要将不同数据交融进行对立剖析，所以须要咱们的数据中台具备异构数据源交融的能力。这种规模的商家个别会本人采办 IDC 独立进行部署，因而须要咱们整体的数据中台的部署，并且要低成本、高效地进行部署。当初咱们数据中台提供的一些业务模型和性能都是普适性的，是给个别商家应用的，但这种规模的商家个别都有本人独特的需要，心愿咱们可能提供一些大的底表，而后他们依据这些底表去做剖析。面对这些痛点，传统的 OLTP 引擎无奈满足以后数据生产和查问的场景。技术选型
接下来介绍技术选型的过程以及 StarRocks 的个性。
存储选型
前文提到 TP 引擎已无奈满足咱们的应用场景，所以须要一款 AP 的引擎来解决以上痛点。然而因为咱们是从 TP 引入到 AP，因而 查问性能好只是最根底的一个要求。咱们要依据本身业务特点，还要适配现有架构来进行选型，所以除了性能，咱们 还要思考应用老本、易用性和运维老本。
- 应用老本：咱们要求 AP 引擎要具备很好的 Join 能力，因为当初数仓沿用分层模型，主题表会波及到很多表的关联操作，如果 Join 能力不够就会须要模型的调整，改变就会比拟大。
- 易用性：查问端接口都是应用规范的 SQL 协定进行查问，因而咱们心愿新的 AP 引擎也具备规范的 SQL 协定，这样查问端就无需做太多更改。
-
运维老本：因为商家可能心愿进行独立部署，须要运维老本比拟低，这样就不须要投入过多的研发和 IT 资源。
基于以上几点咱们比照了市面上常见的 AP 引擎，Apache Druid、ClickHouse、Apache Kylin、StarRocks，最终抉择了 StarRocks。抉择 StarRocks
再来具体看一下 StarRocks 是如何满足咱们商家数据中台需要的。上图左侧列出了 StarRocks 的一些特点，包含极速查问、简略部署、高效开发这三大方面。这些特点能够帮忙咱们应答右侧所列的技术挑战，自下而上来看：
- 独立部署：因为 StarRocks 是不依赖其余任何内部零碎的，同时能够在线进行节点的扩缩容、主动故障复原，所以它能够满足咱们独立部署的要求。
- 多数据源接入：StarRocks 反对市面上大部分数据源，所以这一点也是满足的。
- 高效迭代：StarRocks 反对多种建模形式，反对多种 Join 形式，在引入的过程中整个数仓不须要做很多更改，咱们的迭代效率会很高。
- 大规模存储：StarRocks 是分布式的数据库，所以人造满足大规模存储。
- 极速查问：StarRocks 作为全新的 MPP 执行框架，绝对于其它 AP 零碎还做了很多独特的优化，比方向量化执行引擎，以及 CBO 的一些专项优化等等，因而其查问速度十分快。
-
低代码 BI：依靠极速查问，能够做一些底表，商家可能通过利落拽的简略形式实现一些即席剖析。
数据中台
这一章节将介绍咱们引入 StarRocks 之后新的数据中台架构，以及一些要害设计，会分为 5 个局部：基于 StarRocks 的数据中台架构，数据同步，虚构视图，智能分级查问，多活热备。
基于 StarRocks 的数据中台架构
新的数据中台在架构上并没有太多扭转，只是在各环节加强了能力。原始数据层，新增了异构数据源，这样能够反对商家其它产品数据的接入；数据同步层，基于 StarRocks 的导数性能扩大了数据同步的能力，让其更加高效；数据仓库层，还是沿用了以后数仓分层的模型设计，新增了 StarRocks 的数据源，整体业务采取了混合存储的模式；再往上，实现了零代码的 BI，基于 StarRocks 极速查问的能力，反对大的 KA 进行自助剖析。上面具体介绍一些技术要点。
数据同步
整个数据生产零碎采纳的是 Lambda 架构，离线数据通过 Hive 计算；实时数据通过咱们自研的实时计算零碎，将数据生产到 Kafka。基于此咱们的数据同步也拆散线和实时两个局部来设计。首先，上图中蓝色的局部是专为离线数据设计的同步性能，分为三块：全量导数、增量导数和变更导数。
全量导数和变更导数应用了 StarRocks 的 Broker-load 性能，增量导数则应用了 StarRocks 的 Stream-load 性能。全量导数，顾名思义，就是将全量的数据导入到 StarRocks。因为咱们的数据量十分大，有数十 TB，全量导数是非常消耗资源的，并且工夫也比拟长，因而咱们仅会在表的初始化，或者表呈现问题须要从新导入时才会应用全量导数。对于历史数据的变更咱们是联合增量导数和变更导数来实现的。增量导数是指只导最近一段时间的数据，数据量会比拟少，比方只导最近一个月的数据，通过分区替换的形式来更新 StarRocks 的数据。然而变更还可能是在一个月之外的数据，所以在上游还会有另外一个离线工作去计算一个月之外产生变更的数据，计算完之后就会主动触发变更导数。变更导数会拿到历史变更数据并对 StarRocks 的数据进行笼罩。通过增量导数加上变更导数的形式，咱们实现了历史数据的更新，同时这种形式也大大减少了日常的导数量。咱们进行了一个预计，10T 的数据能够管制在 100G 左右，这样能够很大水平进步咱们数据同步的效率。
上面绿色局部是实时数据的同步，实时数据的同步没有做过多的设计，间接采纳的是 StarRocks 的 Flink-Load。通过这种形式能够将数据同步到 StarRocks 中，然而咱们采纳的是混合存储的形式，也就是数据会在多个数据源中存储，那么就存在数据一致性的问题。为了解决这个问题，咱们专门设计了同步保障系统。
上图中最右侧的同步保障系统有两个模块，第一个模块是监控零碎，提供了多种监控形式，比方流式监控，实时监控 StarRocks 的变更数据，与其它数据源变更数据进行实时校验，并将异样进行记录。还提供批量监控的性能，对 StarRocks 中的数据计算一个汇总值，比方算一张表的总金额、总订单数，而后和另外一个数据源的总金额和总订单数进行比对，如果发现有问题就阐明数据在处理过程中存在问题，也会将这些数据异样记录下来。所有记录下来的异样会交给异步纠错模块，这个模块会去辨认 StarRocks 整体的负载能力，当它低峰期的时候就会异步进行修复。通过这种形式能够保证数据的最终一致性。从而进步了整体的数据品质。虚构视图
另一个要害设计是虚构视图。上图左侧是咱们现有的数仓开发模式，能够看到咱们的数仓 RD 采纳实时和离线计算平台，应用分层的数仓模型进行开发，同时离线和实时采纳雷同的分层模型，分层模型是基于血缘关系进行预计算的，每一层的数据都物化存储到了 MySQL 当中用于减速查问，最终数据利用的一个查问过去，只须要查问 ADS 层就能够将后果返回给客户，这样就能够放慢整个查问。然而这种形式在新的数据中台中无奈满足低成本、高效的独立部署，起因次要有两点：沿用现有形式，须要额定部署一套离线计算零碎和实时计算零碎，减少了部署老本。摈弃分层模型，采纳烟囱式开发，那么和外部零碎是两套逻辑，会导致迭代慢。
针对以上问题，咱们的解法是，基于 StarRocks 高效的查问能力和 Google 提出的 Shasta 实践，进行虚拟化视图。整体的分层模型不变，开发方式也是统一的，然而 DWT 层和 ADS 层是虚拟化视图，也就是数据不做物化存储。当一次查问过去时，还是会查问 ADS 层，这时零碎会判断如果 ADS 的数据是虚构视图，就会将 SQL 进行下推，下推到 DWT 层，这时零碎会发现 DWT 层同样是虚构视图，而后 SQL 还会继续下推，始终推到 DWD 层，这一层是做了物化存储的，就会生成一个实在 SQL 去查问 StarRocks，最终将后果返回给用户。
以前无奈实现虚拟化视图的起因是，下推的 SQL 会非常复杂，传统的 TP 引擎根本无法查问进去。虚构视图的劣势能够总结为以下三点：首先，沿用分层模型，对于数仓 RD 是没有感知的，依然依照分层模型来开发，无论虚构视图还是物化视图都是零碎主动判断，因而对于他们来说还是能够做到逻辑复用，进步迭代效率。第二点是去预计算，DWT 和 ADS 这种重计算的层级被咱们虚拟化了，所以不须要额定去部署离线计算零碎和实时计算零碎，由此能够达到低成本的部署。第三点是数据无状态，能够放慢迭代。依照以前的开发模式，如果数仓 RD 的逻辑呈现了 Bug，DWT 和 ADS 层的数据会呈现问题，就要进行数据重刷，在十分大的数据规模下，在保障稳定性的同时去重刷 DWT 和 ADS 层的数据，这个动作是十分重的，有可能须要几周的工夫，迭代就会十分慢。而采纳虚拟化视图的模式，所见即所得，当逻辑呈现问题时，只须要批改 DWT 和 ADS 层的 SQL 逻辑，查问时间接查问 DWD 层，就能够即时失效。DWD 层个别就是简略的数据荡涤入仓，通常不会有很多逻辑，所以问题也比拟少。通过这种形式去掉了数据状态，从而放慢了迭代效率。通过这三个劣势，保障了咱们数据中台低成本、高效的独立部署。智能分级查问
咱们的查问有如下特点：OLAP 并发能力低于 OLTP 引擎，以后场景高峰期并发查问 QPS 很高（万级别），压力很大；99%+ 的查问数据量小（数十万以内），这部分查问 OLAP 和 OLTP 性能差距不大，但如果全副放在 OLAP，收益较低，同时也会减少 OLAP 引擎的稳定性危险。所以 咱们的整体思路是缩小 OLAP 的 并发 压力，进步每次查问的 ROI。咱们设计了分级查问，智能预测查问数据量，正当路由（MySQL->TiDB->StarRocks），数据量大的去 StarRocks 查问，数据量小的就去 OLTP 查问。
上图下半局部展现了整体的零碎设计。零碎提供了一个智能查问 SDK，是嵌入到接口服务当中的，因而对上游业务是没有感知的，上游并不知道查问的是哪个数据源，但能够疾速拿到数据。智能查问 SDK 分为两个模块，一个是数据源主动切换模块，会依据咱们的分级策略主动抉择不同的数据源，去查问返回数据。外围模块是智能分级策略模块，其分级策略有两个局部，一个是实时的动静路由配置策略，这是 RD 依据教训进行配置的，比方通过教训发现商户在查问大于一个月的数据量时会很慢，这部分须要 OLAP 引擎去减速，就会配置一个到 OLAP 去查问的策略，这部分是人工配置的策略。
第二局部是机器自动识别的策略，咱们会有离线工作，每天批量地去剖析现有商户查问的数据量，比方剖析出某些商户在某些场景下的查问性能比拟差，这一部分须要减速，就会记录下来，在前面查问时，如果命中这些记录就会搁置到 OLAP 中去查问，晋升查问体验。通过这种智能分级的策略，进步了每次查问的 ROI，同时也加强了 OLAP 的稳定性。多活热备
最初一个设计要点是多活热备，也是为了加强稳定性。多活热备分为两层，第一层是 StarRocks 的主备集群的切换，第二层是 OLAP 集群和 OLTP 集群的切换。在此之上咱们还减少了数据品质监控和主动降级复原两层。其运作形式为：首先，数据品质监控零碎会实时监控数据品质，一旦发现数据品质降到了一个水位线之后，会主动触发 StarRocks 的主备切换。如果数据品质还没有复原，则会再次触发降级，从 OLAP 降到 OLTP 零碎，后面提到这种查问有可能在 OLTP 上是查不进去的，所以这种降级是有损降级，会就义查问体验，然而整体危险是可控的。当告警复原后，会主动切回到 StarRocks 主集群上进行查问。
建设成绩
咱们的摸索过程分为 4 个阶段：
第一个阶段是可行性验证，次要验证了虚构视图能够秒级出数，满足实时剖析的场景。
第二个阶段是性能压测，相比之前的 OLTP 引擎，查问性能晋升了 28 倍以上（简单场景从数十秒到亚秒级别），并发能力也有了很大晋升、吞吐在餐饮 SaaS 场景下约为 0.16qps/core。
第三个阶段是试点运行，实现了一套试点集群的搭建和对应的零碎建设，整个试运行期间未呈现事变，整体查问体验失去了较大改善（tp90 晋升 30%，tp99 晋升 500%）。
最初一个阶段是正式部署，当初还没有施行，后续会依据商家的需要进行独立部署。
通过一段时间的摸索，StarRocks 曾经有一套试点集群，其极速查问、简略部署、高效运维等特点可能很好地满足美团商家数据中台的需要。目前对 StarRocks 的应用还处于初级阶段，后续会持续摸索更多高级性能，笼罩更多业务场景，继续晋升美团 SaaS 数据中台的能力。