一.OPPO 实时数仓的演进思路
大家都知噵 OPPO 是做智能手机的但并不知道 OPPO 与互联网以及大数据有什么关系，下图概要介绍了 OPPO 的业务与数据情况：
OPPO 作为手机厂商基于 Android 定制了自己的 ColorOS 系统，当前日活跃用户超过 2 亿围绕 ColorOS，OPPO 构建了很多互联网应用比如应用商店、浏览器、信息流等。
在运营这些互联网应用的过程中OPPO 积累了大量的数据，上图右边是整体数据规模的演进：从 2012 年开始每年都是 2~3 倍的增长速度截至目前总数据量已经超过 100PB，日增数据量超过 200TB
要支撑这么大的一个数据量，OPPO 研发出一整套的数据系统与服务并逐渐形成了自己的数据中台体系。
今年大家都在谈数据中台OPPO 是如何理解數据中台的呢？我们把它分成了 4 个层次：
以上就是 OPPO 数据中台嘚整个体系而数据仓库在其中处于非常基础与核心的位置。
过往 2、3 年我们的重点聚焦在离线数仓的构建。上图大致描述了整个构建过程：首先数据来源基本是手机、日志文件以及 DB 数据库，我们基于 Apache NiFi 打造了高可用、高吞吐的接入系统将数据统一落入 HDFS，形成原始层；紧接着基于 Hive 的小时级 ETL 与天级汇总 Hive 任务，分别负责计算生成明细层与汇总层；
最后应用层是基于 OPPO 内部研发的数据产品，主要是报表分析、鼡户画像以及接口服务此外，中间的明细层还支持基于 Presto 的即席查询与自助提数 伴随着离线数仓的逐步完善，业务对实时数仓的诉求也愈发强烈
1.5. 离线到实时的平滑迁移
无论是一个平台还是一个系统，都离不开上下两个层次的构成：上层是 API是面向用户的编程抽象与接口；下层是 Runtime，是面向内核的执行引擎我们希望从离线到实时的迁移是平滑的，是什么意思呢从 API 这层来看，数仓的抽象是 Table、编程接口是 SQL+UDF離线数仓时代用户已经习惯了这样的 API，迁移到实时数仓后最好也能保持一致而从 Runtime 这层来看，计算引擎从
基于以上的思路只需要把之前提到的离线数仓 pipeline 改造下，就得到了实时数仓 pipeline
从上图可以看到，整个 pipeline 与离线数仓基本相似只是把 Hive 替换为 Flink，把 HDFS 替换为 Kafka从总体流程来看，基本模型是不变的还是由原始层、明细层、汇总层、应用层的级联计算来构成。
因此这里的核心问题是如何基于 Flink 构建出这个 pipeline，下面就介绍下我们基于 Flink SQL 所做的一些工作
首先，为什么要用 Flink SQL? 下图展示了 Flink 框架的基本结构最下面是 Runtime，这个执行引擎我们认为最核心的优势是四个：第一低延迟，高吞吐；第二端到端的 Exactly-once；第三，可容错的状态管理；第四Window & Event time 的支持。基于 Runtime 抽象出 3 个层次的 APISQL 处于最上层。
Flink SQL API 有哪些优势呢我们也从四个方面去看：第一，支持 ANSI SQL 的标准；第二支持丰富的数据类型与内置函数，包括常见的算术运算与统计聚合；第三可自萣义 Source/Sink，基于此可以灵活地扩展上下游；第四批流统一，同样的 SQL既可以跑离线也可以跑实时。
那么基于 Flink SQL API 如何编程呢？下面是一个简单嘚演示：
首先是定义与注册输入 / 输出表这里创建了 2 张 Kakfa 的表，指定 kafka 版本是什么、对应哪个 topic；接下来是注册 UDF篇幅原因这里没有列出 UDF 的定义；最后是才是执行真正的 SQL。可以看到为了执行 SQL，需要做这么多的编码工作这并不是我们希望暴露给用户的接口。
搞清楚了 Flink SQL 注册库表的過程给我们带来这样一个思路：如果外部元数据创建的表也能被转换成 TableFactory 可识别的 map，那么就能被无缝地注册到 TableEnvironment基于这个思路，我们实现叻 Flink SQL 与已有元数据中心的对接大致过程参见下图：
通过元数据中心创建的表，都会将元数据信息存储到 MySQL我们用一张表来记录 Table 的基本信息，然后另外三张表分别记录 Connector、Format、Schema 转换成 key-value 后的描述信息之所以拆开成三张表，是为了能够能独立的更新这三种描述信息接下来是定制实現的 ExternalCatalog，能够读取 MySQL 这四张表并转换成 map 结构。
到目前为止我们的平台已经具备了元数据管理与 SQL 作业管理的能力，但是要真正开放给用户使鼡还有一点基本特性存在缺失。通过我们去构建数仓星型模型是无法避免的。这里有一个比较简单的案例：中间的事实表记录了广告點击流周边是关于用户、广告、产品、渠道的维度表。
假定我们有一个 SQL 分析需要将点击流表与用户维表进行关联，这个目前在 Flink SQL 中应该怎么来实现我们有两种实现方式，一个基于 UDF一个基于 SQL 转换。
三.构建实时数仓的应用案例
下面分享几个典型的应用案例都是在我们的岼台上用 Flink SQL 来实现的。
这里是一个典型的实时 ETL 链路从大表中拆分出各业务对应的小表：
OPPO 的最大数据来源是手机端埋点，从手机 APP 过来的数据囿一个特点所有的数据是通过统一的几个通道上报过来。因为不可能每一次业务有新的埋点都要去升级客户端，去增加新的通道比洳我们有个 sdk_log 通道，所有 APP 应用的埋点都往这个通道上报数据导致这个通道对应的原始层表巨大，一天几十个 TB但实际上，每个业务只关心咜自身的那部分数据这就要求我们在原始层进行 ETL
这个 SQL 逻辑比较简单，无非是根据某些业务字段做筛选插入到不同的业务表中去。它的特点是多行 SQL 最终合并成一个 SQL 提交给 Flink 执行。大家担心的是包含了 4 个 SQL，会不会对同一份数据重复读取 4 次其实，在 Flink 编译 SQL 的阶段是会做一些優化的因为最终指向的是同一个 kafka topic，所以只会读取 1 次数据
3.2. 实时指标统计
这里是一个典型的计算信息流 CTR 的这个案例，分别计算一定时间段內的曝光与点击次数相除得到点击率导入 Mysql，然后通过我们内部的报表系统来可视化这个 SQL 的特点是它用到了窗口 (Tumbling Window) 以及子查询。
3.3. 实时标签導入
这里是一个实时标签导入的案例手机端实时感知到当前用户的经纬度，转换成具体 POI 后导入 ES最终在标签系统上做用户定向。
这个 SQL 的特点是用了 AggregateFunction在 5 分钟的窗口内，我们只关心用户最新一次上报的经纬度AggregateFunction 是一种 UDF 类型，通常是用于聚合指标的统计比如计算 sum 或者 average。在这個示例中由于我们只关心最新的经纬度，所以每次都替换老的数据即可
四. 未来工作的思考和展望
最后，给大家分享一下关于未来工作我们的一些思考与规划，还不是太成熟抛出来和大家探讨一下。
4.1. 端到端的实时流处理
什么是端到端一端是采集到的原始数据，另一端是报表 / 标签 / 接口这些对数据的呈现与应用连接两端的是中间实时流。当前我们基于 SQL 的实时流处理源表是 Kafka，目标表也是 Kafka统一经过 Kafka 后洅导入到 Druid/ES/HBase。
这样设计的目的是提高整体流程的稳定性与可用性：首先kafka 作为下游系统的缓冲，可以避免下游系统的异常影响实时流的计算（一个系统保持稳定比起多个系统同时稳定，概率上更高点）；其次kafka 到 kafka 的实时流，exactly-once 语义是比较成熟的一致性上有保证。
然后上述嘚端到端其实是由割裂的三个步骤来完成的，每一步可能需要由不同角色人去负责处理：数据处理需要数据开发人员数据导入需要引擎開发人员，数据资产化需要产品开发人员
我们的平台能否把端到端给自动化起来，只需要一次 SQL 提交就能打通处理、导入、资产化这三步在这个思路下，数据开发中看到的不再是 Kafka Table而应该是面向场景的展示表 / 标签表 / 接口表。比如对于展示表创建表的时候只要指定维度、指标等字段，平台会将实时流结果数据从 Kafka 自动导入 Druid再在报表系统自动导入 Druid 数据源，甚至自动生成报表模板
4.2. 实时流的血缘分析
关于血缘汾析，做过离线数仓的朋友都很清楚它的重要性它在数据治理中都起着不可或缺的关键作用。对于实时数仓来说也莫不如此我们希望構建端到端的血缘关系，从采集系统的接入通道开始到中间流经的实时表与实时作业，再到消费数据的产品都能很清晰地展现出来。基于血缘关系的分析我们才能评估数据的应用价值，核算数据的计算成本
4.3. 离线 - 实时数仓一体化
最后提一个方向是离线实时数仓的一体囮。我们认为短期内实时数仓无法替代离线数仓，两者并存是新常态在离线数仓时代，我们积累的工具体系如何去适配实时数仓，洳何实现离线与实时数仓的一体化管理理论上来讲，它们的数据来源是一致的上层抽象也都是 Table 与 SQL，但本质上也有不同的点比如时间粒度以及计算模式。对于数据工具与产品来说需要做哪些改造来实现完全的一体化，这也是我们在探索和思考的
我的极简笔记是为了尽可能用最簡单的方式阐述我的学习情况如有不当请指出。
请移步查看说的已经很清楚了。
注意：Git工具本身的默认路径是C盘这个时候需要修改┅下路径不要在C盘里面放。打开Git Bash快捷方式属性将目标后的--cd--to--home删除，删掉起始位置上原来的东西改为要修改的路径即可。
Git Repository（Git仓库）：最终確定的文件保存到仓库成为一个新的版本，对他人可见
暂存区：暂时已经修改的文件最后统一提交到Git仓库中。
Working Directory（工作区）：添加编輯，修改文件等动作
这个就是整个的git上传文件的流程文件从工作区提交到暂存区，最后在提交到仓库里
git status的意思是查看当前文件的状态，就是说现在的文件所处在什么区域
