万字干货还原美团Flink实时数仓建设一、实时数仓建设目的1、解决传统数仓

一、实时数仓建设目的
1、解决传统数仓的问题
实时数仓是一个很容易让人产生混淆的概念。实时数仓本身似乎和把 PPT 黑色的背景变得更白一样，从传统的经验来讲，我们认为数仓有一个很重要的功能，即能够记录历史。通常，数仓都是希望从业务上线的第一天开始有数据，然后一直记录到现在。
但实时处理技术，又是强调当前处理状态的一门技术，所以我们认为这两个相对对立的方案重叠在一起的时候，它注定不是用来解决一个比较广泛问题的一种方案。于是，我们把实时数仓建设的目的定位为解决由于传统数据仓库数据时效性低解决不了的问题。
由于这个特点，我们给定了两个原则：

传统数仓能解决的问题，实时数仓就不解决了。比如上个月的一些历史的统计，这些数据是不会用实时数仓来建设的。
问题本身就不太适合用数仓来解决，也不用实时数仓解决。比如业务性很强的需求，或者是对时效性要求特别高的需求。这些需求我们也不建议通过实时数仓这种方式来进行解决。

当然为了让我们整个系统看起来像是一个数仓，我们还是给自己提了一些要求的。这个要求其实跟我们建立离线数仓的要求是一样的，首先实时的数仓是需要面向主题的，然后具有集成性，并且保证相对稳定。
离线数仓和实时数仓的区别在于离线数据仓库是一个保存历史累积的数据，而我们在建设实时数仓的时候，我们只保留上一次批处理到当前的数据。这个说法非常的拗口，但是实际上操作起来还是蛮轻松的。
通常来讲解决方案是保留大概三天的数据，因为保留三天的数据的话，可以稳定地保证两天完整的数据，这样就能保证，在批处理流程还没有处理完昨天的数据的这段间隙，依然能够提供一个完整的数据服务。
2、实时数仓的应用场景

文章插图
1）实时 OLAP 分析
OLAP 分析本身就非常适合用数仓去解决的一类问题，我们通过实时数仓的扩展，把数仓的时效性能力进行提升。甚至可能在分析层面上都不用再做太多改造，就可以使原有的 OLAP 分析工具具有分析实时数据的能力。
2）实时数据看板
这种场景比较容易接受，比如天猫双11的实时大屏滚动展示核心数据的变化。实际上对于美团来讲，不光有促销上的业务，还有一些主要的门店业务。对于门店的老板而言，他们可能在日常的每一天中也会很关心自己当天各个业务线上的销售额。
3）实时特征
实时特征指通过汇总指标的运算来对商户或者用户标记上一些特征。比如多次购买商品的用户后台会判定为优质用户。另外，商户销售额稿，后台会认为该商户商的热度更高。然后，在做实时精准运营动作时可能会优先考虑类似的门店或者商户。
4）实时业务监控
美团点评也会对一些核心业务指标进行监控，比如说当线上出现一些问题的时候，可能会导致某些业务指标下降，我们可以通过监控尽早发现这些问题，进而来减少损失。
二、如何建设实时数仓
1、实时数仓概念映射
我们通过离线数仓开发和实时数仓开发的对应关系表，帮助大家快速清晰的理解实时数仓的一些概念。

文章插图
1）编程方式
离线开发最常见的方案就是采用 Hive SQL 进行开发，然后加上一些扩展的 udf。映射到实时数仓里来，我们会使用 Flink SQL，同样也是配合 udf 来进行开发。
2）作业执行层面
离线处理的执行层面一般是 MapReduce 或者 Spark Job，对应到实时数仓就是一个持续不断运行的 Flink Streaming 的程序。