美团餐饮SaaS选择StarRocks构建数据中台，查询性能提升28倍
作者：何启航，美团餐饮SaaS数据专家（文章整理自作者亚洲2022分享）随着社会经济的发展，餐饮连锁商户规模越来越大，“千店时代”即将到来。对于美团餐饮SaaS来说，传统的OLTP引擎已经不能满足当前的数据生产和查询场景，迫切需要OLAP数据引擎来解决数据查询复杂度大幅增加、数据价值挖掘能力不足的痛点。经过多次测试和比较，美团餐饮SaaS选择搭建商户数据中台。
经过一段时间的摸索，查询极快、部署简单、运维高效的特点很好地满足了美团商户数据中心的需求，查询性能提升了28倍以上。本文将从业务介绍、技术选型、数据中台、建设成果四个方面介绍美团餐饮SaaS如何为商家搭建数据中台。
业务介绍
首先简单介绍一下美团餐饮系统、使用的数据产品、基本系统架构以及业务面临的痛点。
美团餐饮系统
上图左侧为美图餐饮系统的功能全景。可见其功能非常丰富。 toC部分包括扫描二维码点餐、外卖、团购等； toB部分包括老板可以看到的一些业务分析、财务管理、进货、销售、库存等。
系统根据场景分为线下和线上两部分：线下为餐饮商户提供餐厅数字化解决方案，帮助餐厅实现从前厅管理、后厨生产管理、会员管理、线上运营管理、到供应连锁管理的一整套数字化运营；在线上，连接餐厅与平台，帮助餐厅与顾客对接，帮助餐饮商家了解顾客、了解商圈，辅助经营决策，为顾客带来更好的消费体验。
数据产品
上图为美团餐饮SaaS两大类数据产品截图。左侧为核心报表产品，右侧为智能应用。可以看到报表种类很多，包括汇总表、明细表、业务预警表、财务统计表等。智能应用截图是一个业务选址的应用。商家可以通过地图选择一个区域，然后根据一些标签，如商家类型、流量等，选择合适的商家地址。
我们数据产品的用户包括厨师、收银员、老板、店长和财务。业务场景包括：
上述场景决定了我们的业务具有以下特点：
其中，高数据质量是一个非常重要的特点。美团餐饮数据产品不同于一般的大数据产品。一般大数据产品主要用于分析和决策。在我们的场景中，除了分析和决策之外，还需要财务对账。财务对账与金钱挂钩，任何失算都可能导致客户投诉。严重的时候还可能造成资金损失，所以我们这里对数据质量的要求非常高。这也影响了我们后续的技术架构选择和整体系统设计。
系统架构
我们整体中台的架构与市场上其他中台的架构基本相同。最下面是业务数据。从下到上，按照数据处理流程分为以下几层：
为了保证数据质量，该架构中增加了监控系统和稳定性保障系统。监控系统主要是发现数据质量问题并报告给稳定性系统；稳定性保障系统会识别这些问题，然后选择合适的方法自动修复异常数据，进一步提高数据质量。
业务痛点
随着商业的发展，连锁商户越来越大，我们已经进入了“千店时代”。较大的连锁店可能管理着数万家连锁店，这带来了两个痛点：
首先，这些商户查询的数据量和复杂度显着增加。具体挑战体现在三个方面：
其次，这一级别的商家一般都有自己的研发和IT人员，因此也需要独立的数据价值挖掘能力，自己对数据集进行分析。这也带来了三个方向的挑战：
https://img1.baidu.com/it/u=2846720792,1676373867&fm=253&fmt=JPEG&app=138&f=JPEG?w=889&h=500
面对这些痛点，传统的OLTP引擎无法满足当前的数据生产和查询场景。
技术选型
接下来介绍技术选型的过程及其特点。
存储选择
前面提到，TP引擎已经不能满足我们的使用场景，所以需要AP引擎来解决上述痛点。但既然我们是从TP引入到AP，良好的查询性能只是最基本的要求。我们需要根据自己的业务特点，适应现有的架构来进行选择。因此，除了性能之外，我们还需要考虑使用成本、易用性、运维成本。
基于以上几点，我们对比了市面上常见的AP引擎Druid、Kylin，最终选择了它们。
选择
让我们仔细看看如何满足我们的商家数据中心需求。
上图左侧列出的一些特性包括极快的查询、简单的部署和高效的开发。
这些特征可以帮助我们解决右侧列出的从下往上看的技术挑战：
数据中心
本章将介绍我们介绍完之后的新的数据中心架构，以及一些关键设计，分为5个部分：
基于数据中心架构
新的数据中心在架构上并没有太多变化，只是在各方面增强了能力。原有数据层新增异构数据源，可支持商户其他产品数据的接入；数据同步层基于导数函数，扩展了数据同步能力，提高了数据同步效率；数据仓库层依然采用目前数据仓库的分层模型设计，增加了新的数据源，整体业务采用混合存储模型；并且实现了零代码BI，基于极速查询能力，支持大型KA自助分析。
下面详细介绍一些技术点。
数据同步
整个数据生产系统采用架构。离线数据通过Hive计算；实时数据通过我们自主研发的实时计算系统产生到Kafka。基于此，我们的数据同步也是采用线路和实时部分分离的方式来设计的。
首先，上图中蓝色部分是专门针对离线数据设计的同步功能，分为全导数、增量导数和变化导数三个部分。全导数和变化导数使用-load函数，增量导数使用-load函数。
全量导数，顾名思义，就是将全量数据导入进去。由于我们的数据量非常大，有几十TB，所以完整的导数非常消耗资源并且需要很长的时间。因此，我们只有在初始化表或者表出现问题需要重新导入时才会使用全导数。对于历史数据的变化，我们通过增量导数和变化导数相结合的方式来实现。
增量导数是指只导入最近一段时间的数据，数据量会比较小。例如，只导入最近一个月的数据，通过分区替换来更新数据。但变化的也可能是一个月后的数据，所以上游会另外有一个离线任务来计算一个月后的变化数据。计算完成后，会自动触发变化导数。
变化导数将获取历史变化数据并覆盖该数据。通过添加增量衍生品和更改衍生品，我们可以更新历史数据。同时，这种方法也大大减少了每日衍生品的数量。我们做了估算，10T的数据可以控制在100G左右，这样可以大大提高我们数据同步的效率。
下面绿色部分是实时数据的同步。实时数据的同步并没有设计太多，直接使用Flink-Load。这样就可以将数据同步到中国，但是我们采用的是混合存储方式，即数据会存储在多个数据源中，所以存在数据一致性的问题。为了解决这个问题，我们专门设计了同步保证系统。
https://img0.baidu.com/it/u=1593103591,364690461&fm=253&fmt=JPEG&app=138&f=JPEG?w=889&h=500
上图最右边的同步保证系统有两个模块。第一个模块是监控系统，提供多种监控方式，如流式监控、变化数据实时监控、与其他数据源的变化数据实时校准等。检查并记录异常情况。它还提供批量监控功能来计算数据的汇总值，例如计算表中的总金额和订单总数，然后将其与另一个数据源的总金额和订单总数进行比较。如果发现任何问题，就意味着数据处理过程中出现了问题，这些数据异常也会被记录下来。所有记录的异常都会交给异步纠错模块。该模块将识别整体负载能力并在低峰时段异步修复。这样就保证了数据的最终一致性。这提高了整体数据质量。
虚拟视图
另一个关键的设计元素是虚拟视图。上图左边是我们现有的数据仓库开发模型。大家可以看到我们的数据仓库RD采用实时离线计算平台，采用分层数据仓库模型进行开发。同时，离线和实时采用相同的层次模型。等级模型是根据血缘关系预先计算出来的。每层的数据都被物化并存储在MySQL中以加快查询速度。当对最终数据进行查询时，只需查询ADS层即可将结果返回给客户。这样就会加快整个查询的速度。
但这种方式无法满足新建数据中心低成本、高效独立部署的需求。主要原因有两个：
针对上述问题，我们的解决方案是基于高效的查询能力和提出的理论来执行虚拟化视图。整体层次模型不变，开发方法也相同，但DWT层和ADS层是虚拟化视图，即数据没有实体化存储。当查询到来时，ADS层仍然会被查询。这时系统会判断如果ADS数据是虚拟视图，就会将SQL下推到DWT层。这时系统会发现DWT层也是一个虚拟视图。 ，然后SQL会继续下推到DWD层。这一层是物化存储，会生成一条真实的SQL进行查询，最终将结果返回给用户。
之前之所以无法实现虚拟化视图，是因为下推的SQL会非常复杂，传统的TP引擎根本无法查询。
虚拟视图的优点可以概括为以下三点：
通过这三大优势，保证了我们数据中心的低成本、高效的独立部署。
智能分层查询
我们的查询有以下特点：
所以我们总体的思路是降低OLAP的并发压力，提高每次查询的ROI。我们设计了分层查询、智能预测查询数据量、合理路由（MySQL->TiDB->）。如果数据量大，我们可以查询，如果数据量小，我们可以查询OLTP。
上图的下半部分展示了整个系统的设计。系统提供智能查询SDK，内嵌于接口服务中，对上游业务无感知。上游并不知道正在查询哪个数据源，但可以快速获取数据。智能查询SDK分为两个模块。一是数据源自动切换模块，它会根据我们的分级策略自动选择不同的数据源来查询和返回数据。
核心模块是智能评分策略模块。其分级策略有两部分。一是实时动态路由配置策略，由RD根据经验进行配置。例如，通过经验发现，查询大于1个月的数据量时，商家会很困惑。慢，这部分需要OLAP引擎加速，会配置查询OLAP的策略。这部分是手动配置的策略。第二部分是机器自动识别策略。我们会有线下任务，每天批量分析现有商户查询的数据量。例如，分析发现部分商户在某些场景下的查询性能比较差。这部分需要加速。 ，将被记录。在后续查询中，如果命中这些记录，就会放到OLAP中进行查询，提高查询体验。通过这种智能分级策略，提高了每次查询的ROI，同时也增强了OLAP的稳定性。
多活热备
最后一个设计点是多活热备，也是为了增强稳定性。
多活热备分为两层。第一层是主备集群的切换，第二层是OLAP集群和OLTP集群的切换。除此之外，我们还增加了两层数据质量监控和自动降级恢复。
它的工作方式是：
施工成果
我们的探索过程分为4个阶段：
经过一段时间的探索，试点集群已经建立。其查询极快、部署简单、运维高效等特点可以很好地满足美团商户数据中心的需求。目前美团的使用还处于起步阶段，我们将继续探索更高级的功能，覆盖更多的业务场景，不断完善美团SaaS数据中心的能力。
页:
[1]