披萨店猛爆 900 万外卖订单,数据技术人瑟瑟发抖

点击蓝色“有关SQL”关注我哟

加个“星标”,天天与10000人一起快乐成长

2014年,德国。

平和的街道上,行人步履从容。新开张的披萨店,传来幽香的烤肠味道。人们沉浸在一派祥和之中,享用着美食,享受着天伦。

10点多,彭波意式披萨店门口,停下12辆哈雷。花胳膊大叔们齐溜地下车,每人端走8盒披萨。如果说哈雷,花胳膊不稀奇,那么同时出现12辆,12个花胳膊猛汉,大家还是颇有微词。

一阵飞灰过后,花胳膊连同他们的哈雷消失在视野里。

次日,德煤《Wirtschaftswoche》报道,“本市破获一起重大洗钱案,犯罪团伙确认来自意大利黑手党,该团伙利用黑市,互联网保险,甚至披萨外卖店,涉嫌大资金量洗钱活动。据头目透露,仅披萨店一天就提供了900万的洗钱规模”

人们再次来到新开的披萨店,只见店名已更改,门口公告牌称其CEO经营管理不善,导致集团公司声誉受损,连同数据中心团队,一起开除!

这家披萨店,开门营业不到10天,除了开门做些散客生意,对外还提供外卖服务。但,接近10万一张的披萨,莫不是里面镶金了不成。

没错,这就是传说中的洗黑钱。

在投资银行这几年,类似这样洗钱的操作非常频繁。每次看到这样的报道,再想想这些犯罪份子,我总是发笑。这帮蠢贼,难道不知道现在银行都有风控系统了么,如果有连续大批量小额资金汇入同一个账户,银行BOSS早就接到风控电话了。

所以,今天我就想说说,类似银行的这类实时风控,是怎么完成的。当然,银行业务属于高度机密,我不能把算法,策略都讲出来,只能说说技术框架上的实现。

打开百度搜索【披萨店 洗钱】,真实案例一堆。为什么在信息技术这么发达的今天,还有人用这么Low的方式。大概他们没把大数据当回事,也不知道实时计算能有这么精准的风险控制能力。

前两天在看《美团外卖实时数仓实践》,非常有启发。如果这些披萨店,也知道有这么高科技的东西,他们会变得聪明很多。

如果大家对实时数仓感兴趣,我准备了篇论文,后台回复【实时数仓】,便可下载。

我这篇文,也是基于美团这篇文章,并综合其他材料,展开来写。写作帮我整理了思路,更加深入地探索了未知的领域,如果不写出来,大概有些地方,也只能留下模糊的印象,而不是去深入地思考。

通读《美团外卖实时数仓实践》大约花了我周末的两个半天。这个时间,包括了中途查找其他资料,消化和反刍。有两个知识点,是从这篇文中可以学到并升华的。一是技术架构选型,二是平台建设。

实时架构选型

外卖行业中对于实时数据的反馈,要求很多:

  • 运营:活动影响,峰时成交率等

  • 生产:生产力实时监控,异常

  • 风控:潜在的异常行为,恶意刷单等

  • 用户:搜索,推荐以及投诉

这些实时场景的出现,也应运催生出与传统数据仓库不一样的架构。其中最有名,落地最多的便是 Lambda 架构:

image

要做互联网数据仓库的人,肯定要熟知 Lambda 架构,双路计算引擎。完成业务的不同延时需求。

Kafka在这里扮演的角色非常重要。缺少 Kafka 多路分发,Batch Processing 批量处理就会丢失实时流数据,造成数据的不一致性。

美团在文中,也提出自己转型时的一些矛盾。
在 Storm, Flink的切换过程中,出现很多争抢资源的情况。谁接到任务,谁写代码,谁负责的情况,造成资源成本急剧扩展,且达不到有效整合的情况。那么怎么办?靠整体规划!

image

美团外卖的这份数据仓库业务架构图,非常清晰。可以拿来作为数据仓库建立实时链路和离线链路的标准。一旦业务架构图清晰明了于纸上,架构选型也就好做很多。

实时分析引擎

从美团的实时架构来看,使用了实时计算与实时分析(带存储)

实时计算,比如大屏,包含T+0 的处理,即当天时间节点的统计。比如活动当天有多少利润,用户参与等等。所以实时计算又多了一项实时分析,需要引入外部存储将当天各类数据存储起来。

MPP 就能顺应这个需求趋势。Storm,Flink,Spark Streaming 等实时处理的数据一般都是用完即丢,exactly once. 但实时分析需要write once, read more times,所以外部存储是必须的。

image

同样,美团在选型这类技术架构时,也采用了业务架构分层:

image

这个框架图已经完全细化了美团的业务数据。针对这些业务数据,使用什么样的技术栈去处理,变成了我们要思考的方向。

浅层的数据聚合,使用Kylin完全可以解决。但Kylin不能解决的是,维度中维数更改。如果维数更改,则增量计算就失去作用,必须经过 cube 的迭代设计,重新计算 cube,那样耗时巨大。怎样提高 cube 的计算时间,还能支撑维度自定义增加或减少,目前所有的cube技术都难以做到。

而MPP则可以。

比如业务回撤。电商类的退单,可以说非常普遍。想要计算每个单子的成交与否,将未来发生的退单,也回撤到订单创建的时刻,方能计算准确。因此,这样的回撤计算,需要的是带计算,带存储的OLAP的引擎,流式计算并不合适。

美团采用 Doris 的架构,只管接入新的事实表,就可以快速完成聚合计算,Doris 的数据上游,还是以ROLAP作为存储。

https://www.infoq.cn/article/c0XcLuCsYHygbjTF9kFA

以上这篇文章,是美团技术团队对Doris的详细解释

从为什么选择Doris一路讲到怎么使用Doris.可见很多团队选型时的思考

平台的建设

作为后后端开发,数仓团队的服务,总被前端应用包裹起来。老板看到的,都是一个个表格,一幅幅图表。第一印象很难想到,这背后到底有哪些人付出了努力。最简单,对数仓团队也是最致命的想法,“这个界面很漂亮,做得不错”。当数仓,最害怕听到这话,“完了,又遇到一个外行”

所以,为了扭转这样的局面。数据仓库团队应该交付一个平台,而不是数据。这又是另外一个有趣且有用的话题。

--完--

往期精彩:

本号精华合集(三)

如何写好 5000 行的 SQL 代码

如何提高阅读 SQL 源代码的快感

我在面试数据库工程师候选人时,常问的一些题

零基础 SQL 数据库小白,从入门到精通的学习路线与书单

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

dbLenis

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值