- 数据分析
- 数据治理
- 产品解决方案
- 行业解决方案
- 案例
- 数据资产入表
- 赋能中心
- 伙伴
- 关于
时间：2022-01-02来源：小镇姑娘浏览数：443次
我不喜欢搞什么花里胡哨的词汇，让粉丝听着挠头，我就想用大白话分享我自己的建设思路和方案。
在开始分享之前，我想给兄弟们说一下数仓建设的方法论：“因地制宜，以业务为中心”。
我们需要思考：业务需求是什么？你该如何用最优的方式去支持？
我们需要明白：你的架构的好坏，不是你自己认为好就是好，也不是你同事认为好就是好，而是要经得起业务的考验，这点认知就是年薪30万的sqlboy（自嗨）和年薪100万+（业务口碑）的sqlboy的认知差别。尤其是到了互联网大仓。一个公司高p前100名，20%是技术，80%是业务，为什么会出现这种情况？大家自己思考，业务才是爸爸，一定要认清现实，越往高p走，技术越菜，大部分走向了管理岗位，所以不管你做什么事情都要往业务的角度上思考，业务都不赚钱了，要你技术有啥用。
下面我就开始拿离线数仓和实时数仓的架构做个对比讲解，方便大家易懂。（所有的分层都是为了更高效的解决业务问题，不能说不这么玩就不合理，看业务场景吧）
离线数仓架构图
For业务实时数仓架构图
ODS层属于操作数据层，是直接从业务系统采集过来的最原始的数据，包含了所有业务的变更过程，数据粒度也是最细的。
离线：hive
实时：kafka（实时数仓，要求时效性，基本上都是读取kafka）
数据明细详情，去除空值，脏数据，超过极限范围的明细解析。是在ODS层基础上，根据业务过程建模出来的实时事实明细层，对于访问日志这种数据，会回流到离线系统供下游使用，最大程度地保证实时和离线数据ODS层和DWD层一致。对ODS层数据进行清洗（去除空值，脏数据，超过极限范围的数据，行式存储改为列存储，改压缩格式）
DWD层创建基础明细表
明细表用于存储ODS层原始表转换过来的明细数据。
离线：hive
实时：kafka（实时数仓，复杂的计算逻辑和脏数据提前在flink内部完成，还有纬度退化能在flink内完成尽量在flink内实现，当然也可以把纬度数据同步到doris内，在doris内部做实时join也可以，都可以，根据不同情况制定方案，比如：这个纬度多个报表都需要查询，个人建议同步到doris内，如果纬度不经常用到，可以直接通过flink关联。还有一种业务场景就是给算法同学提供模型训练数据：如果要求的指标就是简单的sum，count可以直接在flink内产出，关联纬度信息写入到kv，复杂的模型训练指标，可以直接从doris实时查询结果数据，然后再传输给模型，根据sla的要求制定技术方案。）
服务层—留存-转化-GMV-复购率-日活 、点赞、评论、收藏;轻度聚合对DWD订阅明细层数据后，会在实时计算任务中计算各个维度的汇总指标。如果维度是各个垂直业务线通用的，则会放在实时通用汇总层，作为通用的数据模型使用。目标：统计当日、当周、当月活动的每个设备明细
离线：hive
实时：doris（一般都是在doris内创建聚合表，创建rollup表或者物化视图，这样做的好处是在doris内部提前预聚合，查询的时候直接命中结果数据，提高实时查询性能，如果设置本地join，两个表按照join的字段提前创建colocate join，这样做的好处是相同的uuid分桶在一起，在join的时候可以减少网络传输，相同的key直接在本地磁盘拉取就可以了。）
下图就是本地colocate join vs shuffle join的性能测试报表
实时维表层的数据基本上都是从离线维表层导出来的，抽取到在线系统中供实时应用调用。
离线：hive
实时：doris/kv（个人建议doris和kv根据业务情况选择，如果你们的纬度数据只是你们本地业务报表使用，可以存在Doris内，因为方便制作报表数据，如果你们的纬度数据其他合作团队也想用，建议写入到kv中，或者给他们binlog日志，让他们自己解析也可以。）
做分析处理同步到RDS数据库里边个性化维度汇总层，对于不是特别通用的统计维度数据会放在这一层中，这里计算只有自身业务才会关注的维度和指标。目标：当日、当周、当月活跃设备数
离线：hive/mysql
实时：doris （目前我接触的实时的场景，80%都是直接查询dws层，多个表join产出数据，基本3s内就可以产出结果，如果时间太长，我们在dws层做一个分钟级别调度，比如5分钟做个结果表，也就是ads层，实时查询的时候直接查询ads层，这样的好处是提升业务体验，不好的地方就是你要确保调度的稳定性还有就是数据的时效性问题。）
