
从功能上讲,美团点评的实时计算平台主要包括运营和资源管理功能. 其中,作业部分包括作业配置,作业发布和作业状态等功能.
在资源管理方面,它为用户提供了多租户资源隔离以及资源交付和部署功能.

如前所述,当前的美团点评实时计算平台将更加注重安全性,易用性和稳定性,其中最主要的应用场景之一就是业务数据仓库. 接下来,我将与您分享一些业务数据仓库的示例.
第一个示例是流量. 交通数据仓是交通业务的基本服务. 在业务渠道中,将存在不同的埋藏点通道和不同页面的埋藏点数据. 基本细节将通过日志收集通道进行. 层级划分根据美团通道和外卖通道等业务维度划分不同的业务渠道.
将根据业务渠道进行更细粒度的划分,例如曝光日志,猜测您喜欢的内容和建议. 以上包括两种使用方法,一种是向其他下游业务方提供流媒体的使用,另一种是对流量进行实时分析.
下图的右侧是流数据仓的体系. 从下到上分为SDK层四层,包括前端,applet和APP埋入点. 在收集层上方,埋葬点日志着陆转到Nginx,并通过日志收集通道从Kafka接收它. 在计算层,流量团队基于Storm功能实现了上层SQL封装,并实现了SQL动态更新功能,而不必在SQL更改时重新启动作业.

这是基于交通数据仓库实时广告验证的另一个示例. 下图的左侧是广告的实时效果的比较图. 广告管理通常分为请求(PV)管理,SPV(服务器PV)管理,CPV(客户PV)曝光管理和CPV点击管理. 所有管理都将包括流程requestID和命中实验路径. 根据requestID和匹配的实验路径,您可以结合所有日志以获取请求中所需的所有数据,然后将数据存储在Durid中以进行分析,以支持对实际CTR,估算的CTR和其他效果.


此处列出的业务数据仓库实践的另一个示例是即时交付. 实时数据在即时交付的操作策略中起着重要作用. 以运送时间估算为例,运送时间用于衡量骑手送餐的运送难度. 整个表演时间分为多个时间段. 分发数据仓库将基于Storm清理并提取特征数据,以供算法团队进行训练. 并得到时间估计的结果. 此过程涉及多个方面,包括商人,骑手和用户. 数据的特征将非常大,并且数据量将非常大.

实时业务数据仓库大致分为三种类型的场景: 流量,业务和功能. 这三种情况是不同的.

以上内容为您介绍了实时数据仓库业务场景. 接下来,我们介绍了实时数据仓库的演进过程以及美团点评的实时数据仓库平台的构建思路.
为了更有效地组织和管理数据,数据仓库的构建通常会进行数据分层,通常从下到上分为四层: ODS(操作数据层),DWD(数据细节层),DWS(摘要)层)和应用层. 实时查询主要通过Presto,Hive和Spark实现.

实时数据仓库的分层方法通常遵循传统的数据仓库模型,并且也分为ODS操作数据集,DWD详细信息层,DWS摘要层和应用程序层. 但是,实时数据仓库模型的处理方法与传统数据仓库不同. 例如,考虑到性能问题,详细信息层和摘要层的数据通常放置在Kafka上,而维度数据通常放置在KV存储(例如HBase或Tair)中. 当场可以使用Flink进行临时查询.


除了以上两个数据仓库模型外,我们发现业务方在实践中也有一个准实时数据仓库模型,其特点是不完全基于流程,而是将详细的层数据导入OLAP存储. 在此基础上,基于OLAP的计算能力进行总结和进一步处理.

实时数据仓库与传统数据仓库之间的比较主要可以从四个方面考虑:

下图比较了实时数据仓库的两种构建方法,即准实时数据仓库和实时数据仓库. 它们的实现方法分别基于OLAP引擎和流计算引擎,实时程度分别为分钟和秒.
总而言之,基于OLAP引擎的构造方法是数据量不太大,业务流程也不太高. 为了提高及时性和开发效率,提出了一个折衷的解决方案. 从未来的发展趋势来看,基于流计算的实时数据仓库具有更大的发展前景.

在业务实践过程中,我们已经看到了业务构建实时数据仓库的共同需求,包括发现不同业务的元数据是分散的,并且业务开发还倾向于使用SQL开发离线数据仓库. 和实时数据仓库. 需要更多操作和维护工具的支持. 因此,我们计划了一个一站式解决方案,希望将整个过程联系起来.
这里的一站式解决方案主要为用户提供数据开发工作平台和元数据管理. 同时,我们考虑从生产到应用的业务问题. 我们的OLAP生产平台通过建模方法,生产任务管理和资源解决了OLAP生产问题. 左边是我们已经有一个数据安全系统,资源系统和数据治理,它们由脱机数据仓库和实时数据仓库共享.


之所以选择Flink来构建实时数据仓库平台,是基于以下四个方面的考虑,这也是实时数据仓库的核心问题.

实时数字仓库平台的构建思路从外到内分为四个层次. 我们认为该平台应该为用户提供抽象表达功能,包括消息表达,数据表达,计算表达以及流程和批处理. 团结起来.

如下所示,是美团点评的实时数据仓库平台架构. 从下至上,资源层和存储层重用了实时计算平台的功能运维体系 实时计算平台,并且引擎层将基于Flink Streaming实现一些扩展. 功能,包括UDF和连接器的集成. 进一步的是基于Flink SQL的独立SQL层,该层主要负责分析,验证和优化. 在此之上的是平台层,包括开发工作台,元数据,UDF平台和OLAP平台. 顶层是平台支持的实时数据仓库的应用程序,包括实时报告,实时OLAP,实时仪表板和实时功能.

在消息表达层面,由于Binlog,埋点日志,后端日志和IoT数据的数据格式不一致,美团点评的实时数据仓库平台提供了数据访问过程,可以帮助您可以将数据同步到ODS层. 这里实现了两个主要功能,即统一消息协议和屏蔽过程的详细信息.
下图的左侧是访问过程的示例. 对于Binlog类型的数据,实时数据仓库平台还提供了对子子表的支持,该子表可以划分同一业务的不同子数据. 根据业务规则收集到相同的ODS表中.

美团点评的实时数据仓库平台基于Flink扩展了DDL. 这部分工作的主要目的是建立一个元数据系统,以开放主流主流实时存储,包括KV数据和OLAP数据. 由于开发工作台和元数据系统已连接,因此无需在DDL中明确声明许多数据细节,只需声明数据名称和某些运行时设置即可,例如,最新消耗是最早的消耗或某个时间戳记的消耗,其他数据访问方法是一致的.


对于UDF平台,需要从三个层次进行考虑:
UDF实际上被广泛使用. UDF平台不仅支持实时数据仓库,还支持离线数据仓库,机器学习和查询服务. 下图的右侧显示了UDF的用例. 左侧是UDF的开发过程. 用户只需要关心注册过程. 该平台的下一次编译,打包,测试和上传均已完成;右侧是UDF的使用过程,用户只需要声明UDF,提交作业后平台将执行解析和验证,路径获取和集成.

最后介绍了实时数据仓库平台的开发工作台,该平台以Web IDE的形式集成了模型,作业和UDF的管理,并且用户可以在Web IDE上使用SQL进行开发. 该平台将管理某些版本的SQL,并支持用户退回到已成功部署的版本.

从整个实时计算的角度来看,美团实时计算平台的节点数已达到数千个,未来可能会达到数万个,因此资源优化将很快提到. 在议程上. 由于业务本身的流量高峰和低谷,对于实时任务,在高峰时间可能需要很多资源,但在低谷期间不需要那么多资源.
另一方面,波峰本身也会改变. 随着业务的增长,最初分配的资源数量可能会不够. 因此,自动资源调整具有两个含义. 一种意味着它可以适应作业高峰流量的增长,并自动适应最大值. 另一则意味着它可以使工作在高峰结束后自动适应流量的减少,并且可以迅速缩小. . 我们可以通过每个任务甚至操作员的历史操作来获得操作员,流程和资源之间的关系函数,并在流程变化时同步调整资源量.
以上是资源优化的思想. 此外,您需要考虑优化完成后如何使用资源. 为了确保可用性,通常将实时任务和脱机任务分开部署. 否则,脱机计算可能会占用带宽和IO,从而导致实时任务延迟. 从资源利用的角度来看运维体系 实时计算平台,有必要考虑实时和脱机的混合部署,或者以流方式处理一些不是很苛刻的实时任务. 这需要更细粒度的资源隔离和更快的资源发布.

实时数据仓库的构建通常分为几个步骤:
目前,美团点评的实时数据仓库平台的建设仍集中在统一表达的水平上,距离理想状态还有很长的路要走.

有关更多大数据和flink实际案例,请检查原始文本:
本文来自电脑杂谈,转载请注明本文网址:
https://www.pc-fly.com/a/jisuanjixue/article-198359-1.html
老旧个毛啊好歹伯克级比弯弯那点家当高到不知道那里去了
省的达到咱这打工