披萨店猛爆 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 数据库小白，从入门到精通的学习路线与书单