开发者学堂课程【互联网技术实战营·数据智能专题：《实时数仓助力互联网实时决策和精准营销》】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/915/detail/14471
《实时数仓助力互联网实时决策和精准营销》
目录：
一、业务在线化、运营精细化推动
二、数仓实时化、交互化
一、业务在线化、运营精细化推动
怎样处理数量规模：
例如：对这个数据产生并分析，当天的事，当天分析，当下的事，当下分析，所以整个要求提高了。
实际上，业务在线驱动整个数据流程的实时化，那我们整个数据流程，从最开始使的处理规模问题检查到逐渐向交互分析，像流式处理的方式的建议，会发现分析的频率要求越来越高，消费者体验要求越来越好，是因为在线分析越来越深入，老板、领导，不仅要看增长还是下滑，还需要看这种经济的合体。
数仓场景：
业务在线化、运营精细化推动数仓实时化、交互化
阿里巴巴典型实时数仓场景
实时 GMV 大屏
实时精细化运营
实时数据中台、用户画像
监控预警
例如：
网上分析产品卖到什么渠道代表，其实这是做精细化分析去关键的部分，最重要的是第二部分和精细化分析，要知道数据要用下面的基础上，把这些这些数据特征，开始作为中台做模型做画像，成为数据。用做支撑你的业务系统，做流量的分发广告的投递应用的推荐等等。另外，做监控的场景，包括订单监控，网络监控，机器人事件监控，这些都是场景。
数仓体系：架构复杂、数据同步难、资源消耗大、数据孤岛、人才培养难、开发成本高、不敏捷
如:
大数据为主会如个发动机群，对外提供应用服务去访问，这时候就变成小数据。要反复权衡计算有多少到阶段。另外不能总数据产生注册的讨论，就断定交量。要说能承受多少的含量。
计算开始出现通过事件驱动的方式，像股票交易。这意味着主力进入，那这就是典型的事件驱动的程序。
事件驱动，实际上让整个加工的流程变得很短，因为事件产生的地方做分析，有一定的局限。
交易量和同行业这条规则描述场景，会把多的延迟变短，但灵活性这个局面就要选择产品的使用。
数据化平台数据经过不同的加工渠道，会存在不同的系统数据。使数据开始不一致。最开始数据不一致还比较小，随着时间的推移会增大。往这三个基本上不相同，随着时间各个渠道之间数据的一致性非常难保证。
即使一致性能想办法保证之后，数据掌握在各个地方上，分析时，要求应用个人去了解，做查询，提供统一的数据接口，屏蔽不同接口，对外方言上的不同，提供市场尝试和提供统一的授权认证等等。所以会看到很多表现。
画架构图是第二部，里面哪一条箭头都意味着一次数据的传递，数据的移动，如：教育，意味着以后上线新的业务，每个阶段改变了，意味着中间每条线都要改进。业务场景上做一个新的报表，可能意味着每一条线主要要找到。
实时数仓业务的核心需求：
时效性：分为实时和准时
实时：端到端延时问题
准时：决策时取数问题
计算前置和计算后置：实时加工，写入，查询,海量数据灵活分析，自助分析
数据质量：多久发现质量问题、多久修正质量问题
记录明细和汇总数据，简化数据重刷，减少属于完全不一致
成本：分为开发成本、运维成本、人力成本
开发成本：上线新业务
运维成本：集群资源
人力成本：学习和上线新业务
业务与技术解耦，数据资产可复用，更少的集群和运维，接口业务标准SQL优先
如：
数据产生就能分析，比较不准确。这里面有两个概念，一个叫实时，一个准时。
一般把实时当真的事件产生，但是绝大部需要的数据分析是看的，希望看到这个数据之后产生决策，判断设投诉机制。
如果为了这个机制，可能要很大的精力，把很多数据提前加工好就可以考虑，做决策就够。但有些像机器的场景需要在线的在线的实时角色，比如：在线推荐。第二个考虑系统，修正数据质量的问题。要多少成本，多长时间。发现数据表出现问题，是哪个组件模块，调整，谁写的。
文件出问题是一件事，发现问题之后，要花费多少成本修正问题。是纠正一个模块，修正一条记录，还是要把整个链路每个环节都得修正的修正。
成本分很多方面，不仅是花钱购买的成本还有上线一个新业务花多长时间。
核心需求，实施方式分两个环节：实时计算，知道福利和基本成为行业的标准和变相程序一个 kpi
实时计算 ：Flink - Powered By Ververica
开发平台：Vorverlca Platlorm
计算引肇：Varvarlem Ruintimo
平台底康：Cloud Natlvo
Analytics : 大规模数据扫描、过滤、汇总、语义层、分布式、列示存储、面向分析
Transaction : 计算机读写、支持事务 ACID、锁向 DBA
Serving : 查询简单、快速、面向在线应用 toC
数据产生从三个开始：待会出错问题，一旦真正用时候负载会影响负载分析。往往不影响稳定性。分析的时候会出现问题，但是提供业务这么多没问题。
如果给客户提供一个报告、系统，往往会找到一个固定的数据。
系统数据会系统之间反复传递，如：数据创新了，最简单的是减少，和数据的一个传递和永聚一块。
Hybrid：Transtion/Analytics、Processing(HTAP)
适合的模型简单，简单分析场景，以TP模型解决 AP 的问题。
HDAP：一般不能放一个系统里面会很难隔离。不需要分析。应该是会科学观：支持一些功能就必须付出一些成本，所以这类系统追求高频词，追求极致的话不太需要。基本上不可能做到每次都生成，基本上是业务问题。
Hybrid：Serving/Analytics、Processing(HSAP)
以数仓模型：（抽象，复用，标准）解决数据服务的问题、事务开销（同步）
基本上都有很多地方，通过技术的创新有可能实现。有时候很多选择方式，业务上的需求例如：处理模型的灵活性啊，这样啊。
常见实时数仓架构选型参考：数据模型灵活度、自助分析体检、分析可扩展性、数据刷新&修正、远相能力、应用开发接口
灵活的数据结构：在灵活性上就会比较弱，但有数据结构会较好，第二个自主体意味着系统数据，系统数据会较快。
高场景：一般来讲高的更厉害。分布式的情况是更高。但特殊情况时：高 QPS 检查这点很难做到。
数据修正：数据出错了能不能修改。可从 HSAP 里尝试
下一代大数据仓理念 HSAP：分析、服务一体化
HSAP: Hybrid Serving & Analytical Processing
MaxCompute Hologres(交互式分析）
HTAP(简写）：适合模型简单、简单分析场景以TP模型解决AP的问题
HSAP(简写）：以数仓模型抽象、复用、标准来解决数据服务的问题
Hologres=Better OLAP+Better Serving+Cost Reduced
Hologres，属自研大数据品牌 MaxCompute,云原生分布式分析引擎，支持对 PB 级数据进行高并发、低延时的 SQL 查询，支持实时数仓，大数据交互式分析等场景。
分析服务一体化、以实时为中心设计、计算存储分离、丰富生态
通过一个架构同时支撑两个场景，最让你的运维团队开发团队开发成本变得简单。
Hologres：支持对 P8 级数据进行高并发。低延时的 SQL 查询，支持实时数仓，大数据交互式分析等。
二、数仓实时化、交互化
人、货、场实时数据，赋能商业及运营决策
人：用户分层、人群洞察
场分为：线上、线下
线上：搜索、频道、店铺、详情 ，个人导购：中心，线下：门店、终端、天猫精灵
货（广义）：商品、品类、品牌、权益、内容、服务
人群洞察，实现目标流量引入，精准触达
什么渠道跟什么样的商品的服务匹配，很多的数据分析里做各种大屏渠道，不同的转化率不同，还有输出各种报表。
搜索推荐：从 N 到 1，Hologres 简化大数据架构
业务敏捷响应，数据自助分析，避免数据割裂，赋能数据服务，简化运维管理
画架构图：最好画从左往右的箭头。在新的架构里面，都写到一个地方进，在一个地方出，所以数据其实并不会在系统之间反复，很多的调度任务反复，会让你整个开发运维调错都会变得更简单一些。
CCO 数仓实时化改造：数字化运行能力决定了消费者和商家的服务体验
如：客服系统里的客服，客户系统里会实时了解所有的行为信息订单信息投诉信息，占比率达90%以上，如果订单出问题出现问题，系统就很复杂；要一会儿了解这个用户行为。从过去的采购行为，还要了解实：实时和离线架构，相互倒数据反复，报表也不够灵活，因为并不只是一个商家，还要支持几百上千个商家。
财务有财务的角度，每个报表有不同的需求。只给最基础的数据，所以业务口径频繁变化，就可能对弹性要求比较高。因为很多促销当天的流量会高十倍十倍，百倍，所以临时申通的比较高。
怎么解决这个问题：会收藏建设，分三个阶段。
第一个阶段是数据库阶段，一样的大数据，加工后到买 cpu。基本上是这种方式。
一个业务需求，从数据源找到数据源的表，再协调分析到做报表。但报表和另外的报表往往可能80%部分是重叠，20%不一样。不同的开发、共享，会发现大量数据资产，但大量数据加工重复低效。
第二个阶段怎么解决问题，从第一个阶段到第二阶段就是加个书仓，夹道出仓的阶段，公共的逻辑沉淀下来，做公共表，做报表，都不供表数据。这个是相对比较健康的状态，会发现这个时候：一部分数据在收藏里；一部分数据，在可支持在线高手的场景里，其他的MP收藏里面，真正对外提供服务保障是QPS。放在数据库会割裂。
第三类阶段是：实数放一个阶段，一个成本下降，需要采购很多的服务器资源。现在更少集群，更少集群做事。简化电路面向公共财产公共，开发真正限制公司发展。最终是效率的问题。花多长时间为平台花费的支撑业务上线业务，都是最关键的指标。
电商营销分析：就是成交的构成分析，实时的统计排名、商品的库存计算，在活动后的各种简报，活动策略的分析等。营销基本有时效性，特别要求严格。所以很多决策、调整，必须当天做不能加工等第二天再做营销场景。
Flink+HBase/OLAP 方案：资源消耗、开发效率、运维成本
第一阶段和第二阶段基本都是把所有业务逻辑从明细到消息，意思是：给加工几个指标，提前一个月开始做加工厂一组报表。需要几十个报表。然后生成很多中间表。会导致资源消耗过高，因为业务分析角度太灵活。
如果分析维度有多个：维度渠道、购买类型、购买能力、人的角度、渠道的角度都有几十个维度，任何维度组合都是一个分析的角度。但如果把维度组合之间的角度都提前预算，资源消耗会非常大。
想上线一个新的分析角度，上线资源开发高，开发效率低，成本更高。这套方式短期刚上线的新业务是可以使用的。
多个任务会发现数据实际上是落盘做到一张表里，不存在卡与不卡，想发现明细数据有没有变化，有没有异常一般情况下是没办法查询的。所以会把明细数据存在一张表里，如果觉得明细有问题，可在表里直接查询。
实时数仓：即席查询、分钟级准实时、增量数据实时统计
云原生实时数仓解决方案：Flink+Hologres
Hologres : 为分析服务一体化设计的实时数仓
Benchmarks - OLAP 交互式多维分析：开发简单、响应极速、运维友好
如：
查的快，才有机会支持更高的GPS，才有机会说明明细数据也可以提供服务。希望这个系统服务的简单，选择数据不需要执行很多 ATF，需要学习来 PK。
其次表结构，不仅是速度快，操作也可以保证长期加速的效果。让运维更简单。
把更多精力用在数据挖掘，数据的洞察上，全托管服务。不管扩容，升级，都是分钟完成比较方便。
