共计 5442 个字符，预计需要花费 14 分钟才能阅读完成。
简介： 本文次要介绍一种通用的实时数仓构建的办法与实际。实时数仓以端到端低提早、SQL 标准化、疾速响应变动、数据对立为指标。
作者：朱良
本文次要介绍一种通用的实时数仓构建的办法与实际。实时数仓以端到端低提早、SQL 标准化、疾速响应变动、数据对立为指标。
在实践中，咱们总结的最佳实际是：一个通用的实时生产平台 + 一个通用交互式实时剖析引擎相互配合同时满足实时和准实时业务场景。两者正当分工，相互补充，造成易于开发、易于保护、效率最高的流水线，兼顾开发效率与生产成本，以较好的投入产出比满足业务多样需要。
01 实时场景
实时数据在美团外卖的场景是十分多的，次要有以下几点：
- 经营层面：比方实时业务变动，实时营销成果，当日营业状况以及当日实时业务趋势剖析等。
- 生产层面：比方实时零碎是否牢靠，零碎是否稳固，实时监控零碎的健康状况等。
- C 端用户：比方搜寻举荐排序，须要实时理解用户的想法，行为、特点，给用户举荐更加关注的内容。
- 风控侧：在外卖以及金融科技用的是十分多的，实时危险辨认，反欺诈，异样交易等，都是大量利用实时数据的场景
02 实时技术及架构
1. 实时计算技术选型
目前开源的实时技术比拟多，比拟通用的是 Storm、Spark Streaming 以及 Flink，具体要依据不同公司的业务状况进行选型。
美团外卖是依靠美团整体的根底数据体系建设，从技术成熟度来讲，前几年用的是 Storm，Storm 过后在性能稳定性、可靠性以及扩展性上是无可替代的，随着 Flink 越来越成熟，从技术性能上以及框架设计劣势上曾经超过 Storm，从趋势来讲就像 Spark 代替 MR 一样，Storm 也会缓缓被 Flink 代替，当然从 Storm 迁徙到 Flink 会有一个过程，咱们目前有一些老的工作依然在 Storm 上，也在一直推动工作迁徙。
具体 Storm 和 Flink 的比照能够参考上图表格。
2. 实时架构
① Lambda 架构
Lambda 架构是比拟经典的架构，以前实时的场景不是很多，以离线为主，当附加了实时场景后，因为离线和实时的时效性不同，导致技术生态是不一样的。Lambda 架构相当于附加了一条实时生产链路，在利用层面进行一个整合，双路生产，各自独立。这在业务利用中也是牵强附会采纳的一种形式。
双路生产会存在一些问题，比方加工逻辑 double，开发运维也会 double，资源同样会变成两个资源链路。因为存在以上问题，所以又演进了一个 Kappa 架构。
② Kappa 架构
Kappa 架构从架构设计来讲比较简单，生产对立，一套逻辑同时生产离线和实时。然而在理论利用场景有比拟大的局限性，在业内间接用 Kappa 架构生产落地的案例不多见，且场景比拟繁多。这些问题在咱们这边同样会遇到，咱们也会有本人的一些思考，在前面会讲到。
03 业务痛点
在外卖业务上，咱们也遇到了一些问题。
业务晚期，为了满足业务须要，个别是拿到需要后 case by case 的先把需要实现，业务对于实时性要求是很高的，从时效性来说，没有进行中间层积淀的机会，在这种场景下，个别是拿到业务逻辑间接嵌入，这是能想到的简略无效的办法，在业务倒退初期这种开发模式比拟常见。
如上图所示，拿到数据源后，会通过数据荡涤，扩维，通过 Storm 或 Flink 进行业务逻辑解决，最初间接进行业务输入。把这个环节拆开来看，数据源端会反复援用雷同的数据源，前面进行荡涤、过滤、扩维等操作，都要反复做一遍，惟一不同的是业务的代码逻辑是不一样的，如果业务较少，这种模式还能够承受，但当后续业务量下来后，会呈现谁开发谁运维的状况，保护工作量会越来越大，作业无奈造成对立治理。而且所有人都在申请资源，导致资源老本急速收缩，资源不能粗放无效利用，因而要思考如何从整体来进行实时数据的建设。
04 数据特点与利用场景
那么如何来构建实时数仓呢？
首先要进行拆解，有哪些数据，有哪些场景，这些场景有哪些独特特点，对于外卖场景来说一共有两大类，日志类和业务类。
- 日志类：数据量特地大，半结构化，嵌套比拟深。日志类的数据有个很大的特点，日志流一旦造成是不会变的，通过埋点的形式收集平台所有的日志，对立进行采集散发，就像一颗树，树根十分大，推到前端利用的时候，相当于从树根到树枝分叉的过程（从 1 到 n 的合成过程），如果所有的业务都从根上找数据，看起来门路最短，但包袱太重，数据检索效率低。日志类数据个别用于生产监控和用户行为剖析，时效性要求比拟高，工夫窗口个别是 5min 或 10min 或截止到以后的一个状态，次要的利用是实时大屏和实时特色，例如用户每一次点击行为都可能立即感知到等需要。
- 业务类：次要是业务交易数据，业务零碎个别是自成体系的，以 Binlog 日志的模式往下散发，业务零碎都是事务型的，次要采纳范式建模形式，特点是结构化的，主体十分清晰，但数据表较多，须要多表关联能力表白残缺业务，因而是一个 n 到 1 的集成加工过程。
业务类实时处理面临的几个难点：
- 业务的多状态性：业务过程从开始到完结是一直变动的，比方从下单 -> 领取 -> 配送，业务库是在原始根底上进行变更的，binlog 会产生很多变动的日志。而业务剖析更加关注最终状态，由此产生数据回撤计算的问题，例如 10 点下单，13 点勾销，但心愿在 10 点减掉勾销单。
- 业务集成：业务剖析数据个别无奈通过繁多主体表白，往往是很多表进行关联，能力失去想要的信息，在实时流中进行数据的合流对齐，往往须要较大的缓存解决且简单。
- 剖析是批量的，处理过程是流式的：对繁多数据，无奈造成剖析，因而剖析对象肯定是批量的，而数据加工是逐条的。
日志类和业务类的场景个别是同时存在的，交错在一起，无论是 Lambda 架构还是 Kappa 架构，繁多的利用都会有一些问题。因而针对场景来抉择架构与实际才更有意义。
05 实时数仓架构设计
1. 实时架构：流批联合的摸索
基于以上问题，咱们有本人的思考。通过流批联合的形式来应答不同的业务场景。
如上图所示，数据从日志对立采集到音讯队列，再到数据流的 ETL 过程，作为根底数据流的建设是对立的。之后对于日志类实时特色，实时大屏类利用走实时流计算。对于 Binlog 类业务剖析走实时 OLAP 批处理。
流式解决剖析业务的痛点？对于范式业务，Storm 和 Flink 都须要很大的外存，来实现数据流之间的业务对齐，须要大量的计算资源。且因为外存的限度，必须进行窗口的限定策略，最终可能放弃一些数据。计算之后，个别是存到 Redis 里做查问撑持，且 KV 存储在应答剖析类查问场景中也有较多局限。
实时 OLAP 怎么实现？有没有一种自带存储的实时计算引擎，当实时数据来了之后，能够灵便的在肯定范畴内自在计算，并且有肯定的数据承载能力，同时反对剖析查问响应呢？随着技术的倒退，目前 MPP 引擎倒退十分迅速，性能也在飞快晋升，所以在这种场景下就有了一种新的可能。这里咱们应用的是 Doris 引擎。
这种想法在业内也曾经有实际，且成为一个重要摸索方向。阿里基于 ADB 的实时 OLAP 计划等。
2. 实时数仓架构设计
从整个实时数仓架构来看，首先思考的是如何治理所有的实时数据，资源如何无效整合，数据如何进行建设。
从方法论来讲，实时和离线是十分类似的，离线数仓晚期的时候也是 case by case，当数据规模涨到一定量的时候才会思考如何治理。分层是一种十分无效的数据治理形式，所以在实时数仓如何进行治理的问题上，首先思考的也是分层的解决逻辑，具体如下：
- 数据源：在数据源的层面，离线和实时在数据源是统一的，次要分为日志类和业务类，日志类又包含用户日志，DB 日志以及服务器日志等。
- 实时明细层：在明细层，为了解决反复建设的问题，要进行对立构建，利用离线数仓的模式，建设对立的根底明细数据层，依照主题进行治理，明细层的目标是给上游提供间接可用的数据，因而要对根底层进行对立的加工，比方荡涤、过滤、扩维等。
- 汇总层：汇总层通过 Flink 或 Storm 的简洁算子间接能够算出后果，并且造成汇总指标池，所有的指标都对立在汇总层加工，所有人依照对立的标准治理建设，造成可复用的汇总后果。
总结起来，从整个实时数仓的建设角度来讲，首先数据建设的层次化要先建进去，先搭框架，而后定标准，每一层加工到什么水平，每一层用什么样的形式，当标准定义进去后，便于在生产上进行标准化的加工。因为要保障时效性，设计的时候，档次不能太多，对于实时性要求比拟高的场景，根本能够走上图左侧的数据流，对于批量解决的需要，能够从实时明细层导入到实时 OLAP 引擎里，基于 OLAP 引擎本身的计算和查问能力进行疾速的回撤计算，如上图右侧的数据流。
06 实时平台化建设
架构确定之后，前面思考的是如何进行平台化的建设，实时平台化建设齐全附加于实时数仓治理之上进行的。
首先进行性能的形象，把性能形象成组件，这样就能够达到标准化的生产，系统化的保障就能够更深刻的建设，对于根底加工层的荡涤、过滤、合流、扩维、转换、加密、筛选等性能都能够形象进去，根底层通过这种组件化的形式构建间接可用的数据后果流。这其中会有一个问题，用户的需要多样，满足了这个用户，如何兼容其余的用户，因而可能会呈现冗余加工的状况，从存储来讲，实时数据不存历史，不会耗费过多的存储，这种冗余是能够承受的，通过冗余的形式能够进步生产效率，是一种空间换工夫的思维利用。
通过根底层的加工，数据全副积淀到 IDL 层，同时写到 OLAP 引擎的根底层，再往上是实时汇总层计算，基于 Storm、Flink 或 Doris，生产多维度的汇总指标，造成对立的汇总层，进行对立的存储散发。
当这些性能都有了当前，元数据管理，指标治理，数据安全性、SLA、数据品质等零碎能力也会逐步构建起来。
1. 实时根底层性能
实时根底层的建设要解决一些问题。
首先是一条流反复读的问题，一条 Binlog 打过去，是以 DB 包的模式存在的，用户可能只用其中一张表，如果大家都要用，可能存在所有人都要接这个流的问题。解决方案是能够依照不同的业务解构进去，还原到根底数据流层，依据业务的须要做成范式构造，依照数仓的建模形式进行集成化的主题建设。
其次要进行组件的封装，比方根底层的荡涤、过滤、扩维等性能，通过一个很简略的表白入口，让用户将逻辑写进去。trans 环节是比拟灵便的，比方从一个值转换成另外一个值，对于这种自定义逻辑表白，咱们也凋谢了自定义组件，能够通过 Java 或 Python 开发自定义脚本，进行数据加工。
2. 实时特色生产性能
特色生产能够通过 SQL 语法进行逻辑表白，底层进行逻辑的适配，透传到计算引擎，屏蔽用户对计算引擎的依赖。就像对于离线场景，目前大公司很少通过代码的形式开发，除非一些特地的 case，所以基本上能够通过 SQL 化的形式表白。
在性能层面，把指标治理的思维交融进去，原子指标、派生指标，规范计算口径，维度抉择，窗口设置等操作都能够通过配置化的形式，这样能够对立解析生产逻辑，进行对立封装。
还有一个问题，同一个源，写了很多 SQL，每一次提交都会起一个数据流，比拟浪费资源，咱们的解决方案是，通过同一条流实现动静指标的生产，在不停服务的状况下能够动静增加指标。
所以在实时平台建设过程中，更多思考的是如何更无效的利用资源，在哪些环节更能节约化的应用资源，这是在工程方面更多思考的事件。
3. SLA 建设
SLA 次要解决两个问题，一个是端到端的 SLA，一个是作业生产效率的 SLA，咱们采纳埋点 + 上报的形式，因为实时流比拟大，埋点要尽量简略，不能埋太多的货色，能表白业务即可，每个作业的输入对立上报到 SLA 监控平台，通过对立接口的模式，在每一个作业点上报所须要的信息，最初可能统计到端到端的 SLA。
在实时生产中，因为链路十分长，无法控制所有链路，然而能够管制本人作业的效率，所以作业 SLA 也是必不可少的。
4. 实时 OLAP 计划
问题：
- Binlog 业务还原简单：业务变动很多，须要某个工夫点的变动，因而须要进行排序，并且数据要存起来，这对于内存和 CPU 的资源耗费都是十分大的。
- Binlog 业务关联简单：流式计算里，流和流之间的关联，对于业务逻辑的表白是十分艰难的。
解决方案：
通过带计算能力的 OLAP 引擎来解决，不须要把一个流进行逻辑化映射，只须要解决数据实时稳固的入库问题。
咱们这边采纳的是 Doris 作为高性能的 OLAP 引擎，因为业务数据产生的后果和后果之间还须要进行衍生计算，Doris 能够利用 unique 模型或聚合模型疾速还原业务，还原业务的同时还能够进行汇总层的聚合，也是为了复用而设计。应用层能够是物理的，也能够是逻辑化视图。
这种模式重在解决业务回撤计算，比方业务状态扭转，须要在历史的某个点将值变更，这种场景用流计算的老本十分大，OLAP 模式能够很好的解决这个问题。
07 实时利用案例
最初通过一个案例阐明，比方商家要依据用户历史下复数给用户优惠，商家须要看到历史下了多少单，历史 T+1 的数据要有，明天实时的数据也要有，这种场景是典型的 Lambda 架构，能够在 Doris 里设计一个分区表，一个是历史分区，一个是今日分区，历史分区能够通过离线的形式生产，今日指标能够通过实时的形式计算，写到今日分区里，查问的时候进行一个简略的汇总。
这种场景看起来比较简单，难点在于商家的量上来之后，很多简略的问题都会变的简单，因而前面咱们也会通过更多的业务输出，积淀出更多的业务场景，形象进去造成对立的生产计划和性能，以最小化的实时计算资源撑持多样化的业务需要，这也是将来须要达到的目标。
原文链接
本文为阿里云原创内容，未经容许不得转载。
