1 使用Apache Doris构建实时数据仓库
1.1 数据模型选择
Apache Doris使用三种数据模型来组织数据，这些模型之间的主要区别在于是否以及如何聚合数据。
- Duplicate Key模型：用于详细数据查询。支持任意维度的即席查询。
- Unique Key模型：用于存在数据唯一性约束的用例。支持精确去重、多流Upsert和部分列更新。
- Aggregate Key模型：用于数据报表。通过预聚合数据，加速数据报表生成。
金融用户在不同的数据仓库层中采用不同的数据模型：
- ODS（原始数据层）- Duplicate Key模型：作为支付服务提供商，用户每天收到一百万笔结算数据。由于结算周期可能跨越一整年，相关数据需要保存一年。因此，合适的方式是将其放入Duplicate Key模型，该模型不执行任何数据聚合。唯一的例外是一些容易变动的数据，比如来自零售商的订单状态。这些数据应该放入Unique Key模型，以便同一零售商ID或订单ID的新记录始终替换旧记录。
- DWD（数据仓库层）和DWS（数据服务层）- Unique Key模型：DWD和DWS层的数据进一步抽象，但仍然放在Unique Key模型中，以便结算数据可以自动更新。
- ADS（分析数据层）- Aggregate Key模型：该层中的数据高度抽象。通过预聚合数据，减轻下游分析的计算负载。
1.2 分区和桶化策略
分区和桶化的思想是将数据“切割”成较小的部分，以增加数据处理速度。关键是设置适当数量的数据分区和桶。根据使用情况，根据每个表自定义桶化字段和桶的数量。例如，经常需要从零售商扁平表查询不同零售商的维度数据，因此可以将零售商ID列指定为桶化字段，并列出各种数据大小的推荐桶数量。
图片
2 多源数据迁移
在采用Apache Doris时，需要将所有分支机构的本地数据迁移到Doris中，但会发现分支机构使用了不同的数据库，并且具有非常不同的数据文件格式，所以迁移可能会很混乱。
图片
幸运的是，Apache Doris支持丰富的数据集成方法，既支持实时数据流式处理，又支持离线数据导入。
- 实时数据流处理：Apache Doris实时获取MySQL Binlog。其中一部分通过Flink CDC直接写入Doris，而高容量的数据则通过Kafka同步，然后通过Flink-Doris-Connector写入Doris。
- 离线数据导入：包括更多种类的数据源和数据格式。历史数据和增量数据从S3和HDFS导入Doris使用经纪人加载方法，来自Hive或JDBC的数据通过Insert Into方法同步到Doris，文件通过Flink-Doris-Connector和Flink FTP Connector加载到Doris。（FTP是用户在系统之间传输文件的方式，所以他们开发了Flink-FTP-Connector以支持复杂的数据格式和多个换行符的数据。）
3 全量数据摄取和增量数据摄取
为了确保业务连续性和数据准确性，可用以下摄取全量数据和增量数据的方法：
- 全量数据摄取：在Doris中创建目标模式的临时表，将全量数据导入临时表，然后使用
ALTER TABLE t1 REPLACE WITH TABLE t2语句原子替换常规表为临时表。这种方法可以避免对前面的查询产生影响。
alter table ${DB_NAME}.${TBL_NAME} drop partition IF EXISTS p${P_DOWN_DATE};
ALTER TABLE ${DB_NAME}.${TBL_NAME} ADD PARTITION IF NOT EXISTS p${P_DOWN_DATE} VALUES[('${P_DOWN_DATE}'), ('${P_UP_DATE}'));
LOAD LABEL ${TBL_NAME}_${load_timestamp} ...- 增量数据导入：创建新的数据分区以容纳增量数据。
4 离线数据处理
已经将部分离线数据处理工作迁移到Apache Doris，并把执行速度提高了5倍。
图片
- 之前：旧的基于Hive的离线数据仓库使用TEZ执行引擎每天处理3000万条新数据记录。使用2TB计算资源，整个流程需要2.5小时。
- 现在：Apache Doris在仅30分钟内完成相同的任务，仅消耗1TB。脚本执行仅需要10秒，而不是8分钟。
5 面向金融机构的企业功能
多租户资源隔离
这是必需的，因为经常会发生多个团队或业务系统请求同一数据的情况。这些任务可能导致资源抢占，从而降低性能和系统的稳定性。
5.1 不同工作负载的资源限制
这里把分析工作负载分为四类，并为每个类别设置了资源限制。特别是拥有四种不同类型的Doris账户，并为每种类型的账户设置了CPU和内存资源的限制。
图片
通过这种方式，当一个租户需要过多的资源时，它只会影响自己的效率，而不会影响其他租户。
5.2 基于资源标签的隔离
为了满足母子公司层级的数据安全性，这里为子公司设置隔离的资源组。每个子公司的数据存储在其自己的资源组中，并具有三个副本，而母公司的数据则存储在四个副本中：三个在母公司资源组中，另一个在子公司资源组中。因此，当子公司的员工请求母公司的数据时，查询只会在子公司资源组中执行。具体而言，采取以下步骤：
图片
5.3 工作负载组
基于资源标签的隔离方案确保了物理级别的隔离，但作为Apache Doris开发人员，希望进一步优化资源利用率并追求更细粒度的资源隔离。为此，在Apache Doris 2.0中推出了工作负载组功能。
工作负载组机制将查询与工作负载组相关联，限制了查询可以使用的后端节点的CPU和内存资源的共享。当集群资源短缺时，最大的查询将停止执行。相反，当集群资源充足且工作负载组需要的资源超过限制时，它将按比例分配空闲资源。
5.4 细粒度用户权限管理
出于规章制度和合规性原因，有的提供商实施严格的权限控制，以确保每个人只能访问他们应该访问的内容。参考做法如下：
- 用户权限设置：不同子公司或具有不同业务需求的系统用户被分配不同的数据访问权限。
- 对数据库、表和行的权限控制：Apache Doris的ROW POLICY机制使这些操作变得容易。
- 对列的权限控制：通过创建视图来实现。
图片
6 集群稳定性保证
- 断路器机制：偶尔，系统用户可能输入有误的SQL，导致资源消耗过多。为此，设置了断路器机制。它将及时停止这些消耗资源的查询，防止对系统的干扰。
- 数据摄取并发控制：例如经常需要将历史数据整合到数据平台中。这涉及大量的数据修改任务，可能会对集群造成压力。为解决这个问题，可在唯一键模型中启用写入合并模式，启用垂直压缩和段压缩，并调整数据压缩参数以控制数据摄取并发性。
- 网络流量控制：若有在不同城市的两个集群，可采用针对不同场景的服务质量（QoS）策略，以实现精确的网络隔离，确保网络质量和稳定性。
- 监控和警报：将Doris与内部监控和警报平台集成，任何检测到的问题都将通过消息软件和电子邮件及时通知。
