笔者并没有专业的实时数仓的开发经验，只是从别人经验和网上资料综合整理而来，仅供参考。
实时数据开发步骤：1、需求分析；2、确定Source、Sink、Dim；3、任务创建；4、任务开发和修改；5、参数与资源配置；6、任务发布；7、任务运维
1、需求分析
根据业务需求评估复杂结果，有一些例子：
| 场景 | 需求特点 | 实现方案 |
|---|---|---|
| 直播引导成交 | 蓄水引导成交（15d） | 双流JOIN+维表JOIN |
| 业务实时中间层 | 口径定义+降低成本 | 指标达标+去args |
| 营销活动实时行业 | 1.回刷多；2.累计曲线：指标累计增长 | 流批一体+高性能UDF |
| 直播指标配置平台 | 管理指标+统一运维 | 维度打标+高表转化 |
| 实时OLAP分析 | 业务迭代快，固定报表使用频率较低 | 基于Hologres实时数仓开发 |
2、确定中间件
中间件包含Source(源)、Sink(目标端)、Dim维表这三个。另外明确中间件，还需要尽量避免跨机房读写，包含source实时流、Sink端数据库/实时流、dim表中间件以及Flink集群所在位置
2.1 Source端
主流source端分类
| 中间件 | 特性 | 用途 |
|---|---|---|
| TimeTunnel | 消息队列，处理数据量大；默认存储三天，shard人工调整 | 实时公共层，复用性(ETL复杂逻辑收口) |
| MetaQ | 存储默认1.5天，shard分片数自动调整 | 承接服务端变更消息 |
| Holo Binlog | 基于实时数仓holo作为明细表的选型 | - |
2.2 Sink端选型
| 中间件 | 特性 | 用途 |
|---|---|---|
| TimeTunnel (TT) | 默认存储三天，shard人工调整 | 实时公共层，复用性(ETL复杂逻辑收口) |
| Lindom | 面向列族的NoSQL数据库，海量数据KV高效查询支持点查+特定场景范围查询 | 大屏场景如商家、或者主播视角 |
| Holo Binlog | 支持海量数据实时写入、实时更新、实时分析，支持PB级数据多维分析（OLAP）与即席分析（Ad Hoc） | 实时公共层；复用性（ETL复杂逻辑收口）；方便排查问题；对接B报表系统；生态：Holo主要服务于小二，无缝对接问大部分场景 |
| Adb | 支持高吞吐的数据实时增删改、低延时的实时分析和复杂ETL | 用途同Holo，生态：ADB服务于外部企业，需要更高的稳定因而成本也会更高一些 |
| IGraph | 在线图存储系统；数据存在主key，查询围绕key展开；查询rt有高要求；数据一致性、持久性要求不高、更新生效时间要求不高 | 算法实时特征 |
2.3 Dim表选型
| 维表存储选择 | 根据量级/更新频率 建议选型 |
|---|---|
| ODPS | 量级<5000w/T+1更新 |
| Lindom | 量级>1000w/实时更新 |
| Hologres | 如果量级>1000w，使用bhclient方式优化 |
3、任务创建
保证任务的可读性、可维护性和可扩展性，有助于提高开发效率和代码质量。
4、任务开发
高质量的实时任务开发可大幅提高任务的性能、稳定性与准确性，从而使得任务能够更好地服务于实际业务需求。
5、参数与资源配置
参数与资源配置在实时开发中至关重。
6、任务发布
分为:数据验证、数据回归、发布管控
7、实时运维
日常运维：单任务报警设置、基线保障
大促保障：①促前：容量评估-＞资源上报-大促资源快上->业务单压->全链路验收（压测/预案）；②促中：大促值班保障；③促后：大促资源快下。
)
