历程与实践思考。 数据架构 1.0 2 如图所示为数据架构 1.0 架构图，分为数仓层、加速层、应用层三部分，数据架构 1.0 是 一个相对主流的架构，简单介绍一下各层的作用及工作原理：  数仓层：通过 ODS-DWD-DWS 三层将数据整合为不同主题的标签和指标体系， DWM 集市层围绕内容对象构建大宽表，从不同主题域 DWS 表中抽取字段。  加速层：在 对于数据分析师来说，可统一在语义层定义和创建衍生的指标和标签，解决了定义 口径不一致、管理和使用难度较高的问题。  对于业务来说，无需耗费过长时间考虑什么场景应选择哪个数据集使用，语义层对 标签和指标透明统一的定义提升了工作效率、降低了使用成本。 存在的问题： 从架构图可知，标签和指标等数据均处于下游位置，虽然标签与指标在语义层被显式定义， 但仍然无法影响上游链路，数仓层有自己的语义逻辑，加速层有自己的导入配置，这样就造 表导致整个数据链路延迟增大。  开发成本较高，该方案只能作为离线方式，若想实现实时方式则需要投入开发资源 进行额外的开发。 而在 Flink 中生成宽表，链路简单、成本低也容易实现，主要流程是：首先用 Spark 将相 关 Source 表最新数据离线导入到 Kafka 中， 接着使用 Flink 来消费 Kafka，并通过主键 ID 构建出一张大宽表，最后将大宽表导入到 Doris

导入方式为同步或异步。 确定导入方式的类型 • 每一批次数据唯一且固定，保证 At-Most-Once 制定 Label 生成策略 • 外部系统需要保证自身的 At-Least-Once，这样就可以保证 导入流程的 Exactly-Once。 程序自身保证 At-Least-Once 多表原子性导入 • 每个表拆分多个任务，并下发BE • BE执行后汇报FE • FE 判断导入多数完成 publish

在某些情况下，用户的 HTTP 连接可能会异常断开导致无法获取最终的返回结果。此时可以使用相同的 Label 重新提交导入 任务，重新提交的任务可能有如下结果： 1. 状态为 ， 或者 。此时按照正常的流程处理即可。 2. 状态为 。则此时需继续查看 字段。如果该字段值为 ，则表 示这个 Label 对应的导入任务已经成功，无需在重试。如果为 ，则表示这个 Label 对应的导入任务依然在 100 个文件。 CREATE-RESOURCE CREATE RESOURCE CREATE RESOURCE Description Description 用于创建一种资源。资源可以被其他流程引用。 目前支持的资源类型： 1. ODBC 用于设置 ODBC 连接信息。 ：资源类型。固定填写： 。 ：数据源连接目标。 ：数据源连接用户名密码。 ：数据源中的数据库和表名称。 FINISHED，当 Load job 处于这两个阶段时，导入完成。其中 CANCELLED 为导 入失败，FINISHED 为导入成功。 导入任务的进度描述。分为两种进度：ETL 和 LOAD，对应了导入流程的两个阶段 ETL 和 LOADING。目前 Broker load 由于 只有 LOADING 阶段，所以 ETL 则会永远显示为 LOAD 的进度范围为：0~100%。 如果所有导入表均完成导入，此时

如果使用最 新商家类型回溯商家近三个月的表现，需要重新计算三个月的Cube，需花费几个小时，来计算近 TB的历史数据。另外，应对非预设维度分析，MOLAP模型需要重新进行适配计算，也需要一定的 迭代工作。 明细数据的交互 业务分析除了宏观数据之外，对明细数据查询也是一种刚需。通常大家会选择MySQL等关系型DB 作为明细数据的快速检索查询，但当业务成长较快时，很快就会遇到性能瓶颈，并且运维成本也 历史数据每日刷新，失去了增量的意义。 每日回溯历史数据量大，10亿+的历史数据回溯。 数据计算耗时3小时+，存储1TB+，消耗大量计算存储资源，同时严重影响SLA的稳定性。 预计算的大量历史数据实际使用率低下，实际工作中对历史的回溯80%集中在近1个月左 右，但为了应对所有需求场景，业务要求计算近半年以上的历史。 不支持明细数据的查询。 解决方案：引入MPP引擎，数据现用现算 既然变化维的历史数据预计算成本巨