很可惜 T 。T 您现在还不是作者身份，不能自主发稿哦～
如有投稿需求，请把文章发送到邮箱tougao@appcpx.com，一经录用会有专人和您联系
咨询如何成为春羽作者请联系：鸟哥笔记小羽毛（ngbjxym）
场景决定一切。离线数仓的时候数据更新频率是T+1，也就是说必须隔一天才能看到结果，今天看昨天的数据。但是数据界有一个确定的结论，就是数据越新，价值越大。于是就有了推荐、风控等各种实时应用场景，让数据在最有价值的时候被利用好。在这些场景中，对数据的实时性要求就非常高，往往需要毫秒级反应，否则会影响用户体验，带来不必要的损失。
在最开始的时候，业界采用Storm进行实时数据流计算。后来有了spark streaming，现在最火热的当属Flink了。在离线数据仓库架构设计的时候，大家知道需要分层，数据得落地在数据存储介质中，一般是各种数据库。但是实时场景，数据一直是在流动的，数据怎么落地？怎么分层？以下图为例，数据从各种日志中实时读取过来，最后流向实时大屏，大屏计算结果就必须得有个地方存着啊。
上图看上去很不错，能在大屏上直接展示结果。但是一细看，就会有无数问题：大屏上需要展示多少指标？面对任性的业务，面对他们 无穷无尽 的需求，作为技术能做的是怎么能更好的服务他们？如何做到以数据驱动业务的成长，以数据驱动产业数字化？
业务的需求多变，指标可能是无穷无尽的，导致的也就是开发速度可能不尽人意。可能两天才有一个指标的产出，复杂的可能一个星期乃至更长。如果需求不能加以控制，我们将陷入无尽的任务中。如果拒绝需求，业务的需求得不到满足，数据团队存在的意义又会大大降低。我们该怎么办？
那么我们有没有可能在牺牲一些查询速度的同时，来提升我们的开发速度，我们应该都知道spark streaming 和flink都是支持sql开发的。那么flink 或者spark streaming 来进行sql 开发，时效性和灵活性会比较低，直接开放给业务方，用户体验会非常不好。这是一个很值得思考的问题。那么我们又该咋办？
我们是不是可以尝试将我们的binlog 数据以及埋点数据进行拉宽，也就是宽表化的一些操作？变成离线数仓那样的OLAP？自主化的查询呢？对，这就是实时数仓的诞生！
实时数仓在我理解中呢，可以对外进行服务，并且可以实时的进行OLAP查询，也就是在线化查询 Ad-hoc化的查询。
初始
在我刚来公司的时候，并没有实时数仓，只是一些批处理化的操作，并且是一种烟囱式的开发。数据流程是这样的，我们采用的greenplum来做的准实时数仓，每15分钟去业务库和神策系统拉取实时数据到greenplum中进行计算，如下图所示。
我们这个时候肯定可以发现，假如指标多的时候，那么对于开发速度来讲是一个十分缓慢的一个过程，并且会造成很多数据的冗余计算，有些指标并不能复用。
在对公司情况有所了解之后，我选择了Flink作为实时数仓的核心组件。在熟悉了业务之后，我选了一个线上分析的需求，简单梳理了一下数据流向：
上线之后效果还不错，业务方非常满意，领导也加以赞许。但是后来慢慢的需求多了起来，我意识到拿flink写需求肯定会陷入无尽的任务。我明白必须要避免烟囱式的开发，应该做好数据架构，把数据和业务彻底解耦！
其实实时数仓也很简单，你把实时表都想象成离线宽表一样的话，那么直接在宽表上进行计算不就好了吗。OK，咱开始实战。
按照CIF设计规范，要拉宽这些数据表，得有核心场景。我们公司是比较关心销售的，把离线的销售宽表拿实时展现出来就是很好的一个场景。
先确定数据源，我们的数据是从业务库来。但是我们的postgresql 比较老，并没有binlog这些的操作。我当初就和研发的架构探讨了一下，他们那边借助触发器来进行给我往kafka中打数据，解决数据源的问题。
然后解决数据质量问题，我对数据先进行了校验，也就是看看我要的字段是否都齐全，数据是否有问题。这两个问题都解决之后，就开始尝试用flink接入kafka的数据。
这个时候我数据是拿到了，但是我需要拉宽，我应该怎么拉宽？我选择把相关维度表放置到redis，这样比较快。这样在flink的map方法中进行查询redis中的数据来进行拉宽维度表。
这个时候就来问题了，我的维度表是会更新的啊。我也就问了我们组的业务大佬，咨询了一下，发现维度表无非就是门店维表、品类维表（一级类、二级类、三级类等）、城市维表、商品维表、主推表等。这些都是缓慢变化维，即使是更新，也会提前上线几天进行更新。并且我们在凌晨0点到2点是不进行出库操作的，我在这个时候进行维度表更新操作不就好了吗。那么也就有下面的设计，定时进行redis中的维度数据更新：
那么接下来我们就可以进行销售宽表的拉宽操作了，但是我这个时候又发现了一个问题，我拉宽之后存在哪里，这个时候我得思考的几点是。第一单表查询足够快、最好支持join。那么我开始的调研过几款 Tidb、Doris、Druid、Clickhouse。我在单机测试的表现上来看，clickhouse给我带来了无与伦比的感觉。并且考虑到当时的业务场景，也就毅然决然的采用了Clickhouse为基础的实时数仓。
然后就这样的一个架构持续了大概两个月的时间，业务也越来越复杂。比如：门店需要对导购拉新来做当日的绩效考核，因此需要接入一些用户维度表。那么我们总计有2000多万的用户，我全部都导入的redis话会有一些问题。同时还有一些实时需求，例如要在用户宽表中标记出来这个用户是不是新会员、是否是孕妇等。
另外还有一些交易回溯分摊的问题，例如一个用户购买了一个A 产品，赠了一个B产品，那么这个时候，品类间的毛利就有了一些损失。例如买一件衣服送一罐奶粉，那么这个时候就有了问题，不同品类的负责人不干了，因为赠品的KPI少了。衣服的总监愿意啊，买的人多了，但是奶粉的总监不干了，我毛利没了啊。所以就有了回溯分摊这一个事情。人生太艰难了，解决技术问题，还得解决业务问题
。
我就写了个flink程序，自定义了一个source实时的去库里面拉取数据，因为没有binlog。但是不能实时的去啊，对库的影响太大了。那么这个时候就想到了我每次间隔一分钟去拉取一次放到redis当中，然后flink join 的时候就写入到clickhouse中。
对于没有join上的，就放到kafka的另一个topic中例如 dws_sold_detail_retry 然后再开一个flink 专门消费这个。假如还没有join上 就继续放到这个topic中，在日志中追加一个重试次数，假如这个消息重试了超过5次，则认为消费失败，不再消费。为了避免此类情况影响统计结果，我增加了一个实时数据监控，每天的销售额差异不能超过百分之3，超过就报警，进行人工干预。
就这样，慢慢的加入了其他的一些宽表，例如库存、优惠券、会员宽表、促销宽表等。但是慢慢的问题也有了，那就是flink写入clickhouse的时候假如表特别宽的话，代码量是很大的。后来我就引入了waterdrop。
也就是以上的架构图。
在以上的架构中，我的核心思想就是，用flink拉宽、计算之后，交给olap引擎做多维分析，对数据和业务进行解耦。
这个架构是灵活可扩展的，部分组件是可以完美的可插拔的，例如flink可以改成spark streaming、storm。clickhouse可以根据不同的业务场景更改为tidb、drois、greenplum、kudu等。
那么上面的架构也有一些问题，例如维度表太大了怎么办，后面我又引入了二级缓存。也就是引入的hbase，并且支持对外提供查询三个月内的数据实时查询。
最终架构图：
以上就是中国好胖子吴庆志的分享，有任何问题，欢迎添加好胖子微信wuqingzhi128私聊，代价：一顿烧烤。
扩展阅读：Flink+ClickHouse+各厂实战分享案例，后台回复“实时数仓”即可下载。
配合以下文章享受更佳
本文为作者独立观点，不代表鸟哥笔记立场，未经允许不得转载。
《鸟哥笔记版权及免责申明》 如对文章、图片、字体等版权有疑问，请点击 反馈举报
Powered by QINGMOB PTE. LTD. © 2010-2022 上海青墨信息科技有限公司 沪ICP备2021034055号-6
我们致力于提供一个高质量内容的交流平台。为落实国家互联网信息办公室“依法管网、依法办网、依法上网”的要求，为完善跟帖评论自律管理，为了保护用户创造的内容、维护开放、真实、专业的平台氛围，我们团队将依据本公约中的条款对注册用户和发布在本平台的内容进行管理。平台鼓励用户创作、发布优质内容，同时也将采取必要措施管理违法、侵权或有其他不良影响的网络信息。
一、根据《网络信息内容生态治理规定》《中华人民共和国未成年人保护法》等法律法规，对以下违法、不良信息或存在危害的行为进行处理。
1. 违反法律法规的信息，主要表现为：
1)反对宪法所确定的基本原则；
2)危害国家安全，泄露国家秘密，颠覆国家政权，破坏国家统一，损害国家荣誉和利益；
3)侮辱、滥用英烈形象，歪曲、丑化、亵渎、否定英雄烈士事迹和精神，以侮辱、诽谤或者其他方式侵害英雄烈士的姓名、肖像、名誉、荣誉；
4)宣扬恐怖主义、极端主义或者煽动实施恐怖活动、极端主义活动；
5)煽动民族仇恨、民族歧视，破坏民族团结；
6)破坏国家宗教政策，宣扬邪教和封建迷信；
7)散布谣言，扰乱社会秩序，破坏社会稳定；
8)宣扬淫秽、色情、赌博、暴力、凶杀、恐怖或者教唆犯罪；
9)煽动非法集会、结社、游行、示威、聚众扰乱社会秩序；
10)侮辱或者诽谤他人，侵害他人名誉、隐私和其他合法权益；
11)通过网络以文字、图片、音视频等形式，对未成年人实施侮辱、诽谤、威胁或者恶意损害未成年人形象进行网络欺凌的；
12)危害未成年人身心健康的；
13)含有法律、行政法规禁止的其他内容；
2. 不友善：不尊重用户及其所贡献内容的信息或行为。主要表现为：
1)轻蔑：贬低、轻视他人及其劳动成果；
2)诽谤：捏造、散布虚假事实，损害他人名誉；
3)嘲讽：以比喻、夸张、侮辱性的手法对他人或其行为进行揭露或描述，以此来激怒他人；
4)挑衅：以不友好的方式激怒他人，意图使对方对自己的言论作出回应，蓄意制造事端；
5)羞辱：贬低他人的能力、行为、生理或身份特征，让对方难堪；
6)谩骂：以不文明的语言对他人进行负面评价；
7)歧视：煽动人群歧视、地域歧视等，针对他人的民族、种族、宗教、性取向、性别、年龄、地域、生理特征等身份或者归类的攻击；
8)威胁：许诺以不良的后果来迫使他人服从自己的意志；
3. 发布垃圾广告信息：以推广曝光为目的，发布影响用户体验、扰乱本网站秩序的内容，或进行相关行为。主要表现为：
1)多次发布包含售卖产品、提供服务、宣传推广内容的垃圾广告。包括但不限于以下几种形式：
2)单个帐号多次发布包含垃圾广告的内容；
3)多个广告帐号互相配合发布、传播包含垃圾广告的内容；
4)多次发布包含欺骗性外链的内容，如未注明的淘宝客链接、跳转网站等，诱骗用户点击链接
5)发布大量包含推广链接、产品、品牌等内容获取搜索引擎中的不正当曝光；
6)购买或出售帐号之间虚假地互动，发布干扰网站秩序的推广内容及相关交易。
7)发布包含欺骗性的恶意营销内容，如通过伪造经历、冒充他人等方式进行恶意营销；
8)使用特殊符号、图片等方式规避垃圾广告内容审核的广告内容。
4. 色情低俗信息，主要表现为：
1)包含自己或他人性经验的细节描述或露骨的感受描述；
2)涉及色情段子、两性笑话的低俗内容；
3)配图、头图中包含庸俗或挑逗性图片的内容；
4)带有性暗示、性挑逗等易使人产生性联想；
5)展现血腥、惊悚、残忍等致人身心不适；
6)炒作绯闻、丑闻、劣迹等；
7)宣扬低俗、庸俗、媚俗内容。
5. 不实信息，主要表现为：
1)可能存在事实性错误或者造谣等内容；
2)存在事实夸大、伪造虚假经历等误导他人的内容；
3)伪造身份、冒充他人，通过头像、用户名等个人信息暗示自己具有特定身份，或与特定机构或个人存在关联。
6. 传播封建迷信，主要表现为：
1)找人算命、测字、占卜、解梦、化解厄运、使用迷信方式治病；
2)求推荐算命看相大师；
3)针对具体风水等问题进行求助或咨询；
4)问自己或他人的八字、六爻、星盘、手相、面相、五行缺失，包括通过占卜方法问婚姻、前程、运势，东西宠物丢了能不能找回、取名改名等；
7. 文章标题党，主要表现为：
1)以各种夸张、猎奇、不合常理的表现手法等行为来诱导用户；
2)内容与标题之间存在严重不实或者原意扭曲；
3)使用夸张标题，内容与标题严重不符的。
8.「饭圈」乱象行为，主要表现为：
1)诱导未成年人应援集资、高额消费、投票打榜
2)粉丝互撕谩骂、拉踩引战、造谣攻击、人肉搜索、侵犯隐私
3)鼓动「饭圈」粉丝攀比炫富、奢靡享乐等行为
4)以号召粉丝、雇用网络水军、「养号」形式刷量控评等行为
5)通过「蹭热点」、制造话题等形式干扰舆论，影响传播秩序
9. 其他危害行为或内容，主要表现为：
1)可能引发未成年人模仿不安全行为和违反社会公德行为、诱导未成年人不良嗜好影响未成年人身心健康的；
2)不当评述自然灾害、重大事故等灾难的；
3)美化、粉饰侵略战争行为的；
4)法律、行政法规禁止，或可能对网络生态造成不良影响的其他内容。
二、违规处罚
本网站通过主动发现和接受用户举报两种方式收集违规行为信息。所有有意的降低内容质量、伤害平台氛围及欺凌未成年人或危害未成年人身心健康的行为都是不能容忍的。
当一个用户发布违规内容时，本网站将依据相关用户违规情节严重程度，对帐号进行禁言 1 天、7 天、15 天直至永久禁言或封停账号的处罚。当涉及欺凌未成年人、危害未成年人身心健康、通过作弊手段注册、使用帐号，或者滥用多个帐号发布违规内容时，本网站将加重处罚。
三、申诉
随着平台管理经验的不断丰富，本网站出于维护本网站氛围和秩序的目的，将不断完善本公约。
如果本网站用户对本网站基于本公约规定做出的处理有异议，可以通过「建议反馈」功能向本网站进行反馈。
(规则的最终解释权归属本网站所有)