万字干货还原美团Flink实时数仓建设( 三 )
这里面我主要想讲两点 ， 一个这么多数据源我怎么选？我们认为以数仓的经验来看：
首先就是数据源的来源尽可能要统一 。 这个统一有两层含义：
第一个统一就是实时的数据源本身要跟自己统一 ， 比如你选择从某个系统接入某一种数据 ， 要么都从binlog来接 ， 要么都从系统日志来接 ， 最好不要混着接 。 在不知道数据生产的流程的情况下 ， 一部分通过binlog接入一部分通过系统日志接入 ， 容易出现数据乱序的问题 。
第二个统一是指实时和离线的统一 ， 这个统一可能更重要一点 。 虽然我们是建设实时数仓 ， 但是本质上还是数仓 ， 作为一个团队来讲 ， 仓库里的指标的计算逻辑和数据来源应该完全一致 ， 不能让使用数据的人产生误解 。 如果一个数据两个团队都能为你提供 ， 我们建议选择跟离线同学一致的数据来源 。 包括我们公司本身也在做一些保证离线和实时采用的数据源一致的工作 。
第二个要点就是数据乱序的问题 ， 我们在采集数据的时候会有一个比较大的问题 ， 可能同一条数据 ， 由于分区的存在 ， 这条数据先发生的状态后消费到 ， 后发生的状态先消费到 。 我们在解决这一问题的时候采用的是美团内部的一个数据组件 。
其实 ， 保证数据有序的主要思路就是利用 kafka 的分区来保证数据在分区内的局部有序 。 至于具体如何操作 ， 可以参考《美团点评基于 Flink 的实时数仓建设实践》 。 这是我们美团数据同步部门做的一套方案 ， 可以提供非常丰富的策略来保证同一条数据是按照生产顺序进行保序消费的 ， 实现在源头解决数据乱序的问题 。
2）DW 层的建设
解决原始数据中数据存在噪声、不完整和数据形式不统一的情况 。 形成规范 ， 统一的数据源 。 如果可能的话尽可能和离线保持一致 。
明细层的建设思路其实跟离线数仓的基本一致 ， 主要在于如何解决 ODS 层的数据可能存在的数据噪声、不完整和形式不统一的问题 ， 让它在仓库内是一套满足规范的统一的数据源 。 我们的建议是如果有可能的话 ， 最好入什么仓怎么入仓 ， 这个过程和离线保持一致 。
尤其是一些数据来源比较统一 ， 但是开发的逻辑经常变化的系统 ， 这种情况下 ， 我们可能采用的其实是一套基于配置的入仓规则 。 可能离线的同学有一套入仓的系统 ， 他们配置好规则就知道哪些数据表上数据要进入实时数仓 ， 以及要录入哪些字段 ， 然后实时和离线是采用同一套配置进行入仓 ， 这样就可以保证我们的离线数仓和实时数仓在 DW 层长期保持一个一致的状态 。
实际上建设 DW 层其实主要的工作主要是以下4部分：
文章插图
唯一标红的就是模型的规范化 ， 其实模型的规范化 ， 是一个老生常谈的问题 ， 可能每个团队在建设数仓之前 ， 都会先把自己的规范化写出来 。 但实际的结果是我们会看到其实并不是每一个团队最终都能把规范落地 。
在实时的数仓建设当中 ， 我们要特别强调模型的规范化 ， 是因为实施数仓有一个特点 ， 就是本身实时作业是一个7×24 小时调度的状态 ， 所以当修改一个字段的时候 ， 可能要付出的运维代价会很高 。 在离线数仓中 ， 可能改了某一个表 ， 只要一天之内把下游的作业也改了 ， 就不会出什么问题 。 但是实时数仓就不一样了 ， 只要改了上游的表结构 ， 下游作业必须是能够正确解析上游数据的情况下才可以 。
另外使用像 kafka 这样的系统 ， 它本身并不是结构化的存储 ， 没有元数据的概念 ， 也不可能像改表一样 ， 直接把之前不规范的表名、表类型改规范 。 要在事后进行规范代价会很大 。 所以建议一定要在建设之初就尽快把这些模型的规范化落地 ， 避免后续要投入非常大的代价进行治理 。
3）重复数据处理
推荐阅读
- 广色域还不够 投影如何实现精准色彩还原？
- 对话五位英伟达技术专家：解析GTC China大会不容错过的技术干货
- AI从业必看！英伟达GTC China大会最新干货
- 渗透测试干货 | 横向渗透的常见方法
- 又一篇干货文章——德生PL990收音机的频率显示校准方法
- Python中字符串有哪些常用操作？纯干货超详细
- GPU|干货|基于 CPU 的深度学习推理部署优化实践
- 激光雷达、相机…万字长文带你入门无人驾驶车硬件
- 干货 | 特斯拉时代的线束发展趋势
- 收藏：Win10完美快速去掉快捷方式箭头和还原快捷箭头的方法