关于数据库:Apache-Doris-在美联物业的数据仓库应用实践助力传统行业数字化革新

导读： 传统行业面对数字化转型往往会遇到很多艰难，比方不足数据管理体系、数据需要开发流程简短、烟囱式开发、过于依赖纸质化办公等，美联物业也有遇到相似的问题。本文次要介绍美联物业基于 Apache Doris 在数据体系方面的建设，以及对数据仓库搭建教训进行的分享和介绍，旨在为数据量不大的传统企业提供一些数仓思路，实现数据驱动业务，低成本、高效的进行数仓革新。

作者|美联物业数仓负责人 谢帮桂

美联物业属于香港美联团体成员，于 1973 年成立，并于 1995 年在香港联结交易所挂牌上市 (香港联交所编号:1200)，2008 年美联工商铺于主板上市（香港联交所编号:459），成为领有两家上市公司的地产代理企业。领有 40 余载房地产销售行业教训，业务涵盖中、小型住宅、豪宅及工商铺，提供移民参谋、金融、测量、按揭转介等服务，业务遍布中国香港地区、中国澳门地区和中国边疆等多个重要城市。

本文次要介绍对于美联物业在数据体系方面的建设，以及对数据仓库搭建教训进行的分享和介绍，旨在为数据量不大的传统企业提供一些数仓思路，实现数据驱动业务，低成本、高效的进行数仓革新。

思考隐衷政策，本文不波及公司任何具体业务数据。

业务背景

美联物业早在十多年前就已深刻各城市发展房地产中介业务，数据体系的建设和倒退与大多数传统服务型公司相似，经验过几个阶段期间，如下图所示。

咱们的数据来源于大大小小的子业务零碎和部门手工报表数据等，存在历史存量数据宏大，数据结构多样简单，数据品质差等普遍性问题。此外，晚期业务逻辑解决少数是应用关系型数据库 SQL Server 的存储过程来实现，当业务流程稍作变更，就须要投入大量精力排查存储过程并进行批改，应用及保护老本都比拟高。

基于此背景，咱们面临的挑战能够大抵演绎为以下几点：

• 不足数据管理体系，统计口径对立，已有数据无奈降本复用。多部门、多零碎、多字段，命名随便、表违反范式构造凌乱；对同一业务起源数据无奈做到多份报表复用，重复在不同报表编写同一套计算逻辑。
• 海量数据下性能有余，查问响应慢。历史大多数业务数据存储在关系型数据库中，分表分库已无奈做到上亿数据秒级剖析查问。
• 数据需要开发流程简短、烟囱式开发。每当业务部门提出一个数据需要，数据开发就须要在多个零碎之间进行数据兼容编写存储过程，从而导致存储过程的可移植性和可读性都十分差。
• 部门之间重大依赖文本文档解决工作，效率低下。因为长期的手工统计，用户已造成习惯，导致对信息系统的信赖水平也比拟低。

晚期架构

针对上述的⼏个需要，咱们在平台建设的初期选⽤了 Hadoop、Hive、Spark 构建最后的离线数仓架构，也是比拟广泛、常见的架构，运作原理不进行过多赘述。

咱们数据体系次要服务对象以外部员工为主，如房产经纪人、后勤人员、行政人事、计算机部门，房产经纪在全国范畴内散布宽泛，也是咱们的次要服务对象。以后数据体系还无需面向 C 端用户，因而在数据计算和资源方面的压力并不大，晚期基于 Hadoop 的架构能够满足一部分根本的需要。然而随着业务的一直倒退、内部人员对于数据分析的复杂性、剖析的效率也越来越高，该架构的弊病日益越发的显著，次要体现为以下几点：

• 过于轻便：传统公司的计算量和数据量并不大，应用 Hadoop 过于节约。
• 效率低下：T+1 的调度时效和脚本，动辄须要破费 1 小时的计算工夫导入导出，效率低、影响数据的开发工作。
• 保护老本高：组件过多，排查故障链路过长，运维老本也很高，且部门共事之间相熟各个组件须要大量学习和沟通老本。

新数仓架构

基于上述业务需要及痛点，咱们开始了架构降级，并心愿在这次降级中实现几个指标：

• 初步建设数据管理体系，搭建数据仓库。
• 搭建报表平台和报表疾速开发流程体系。
• 实现数据需要可能快速反应和交付（1 小时内），查问提早不超过 10s。
• 最小老本准则构建架构，反对滚动扩容。

技术选型

通过调研理解以及敌人举荐，咱们理解到了 Apache Doris，并很快与社区获得了分割，Apache Doris 的几大劣势吸引了咱们：

足够简略

美联物业及大部分传统公司的数据人员除了须要实现数据开发工作之外，还须要兼顾运维和架构布局的工作。因而咱们抉择数仓组件的第一准则就是 ” 简略 ”，简略次要包含两个方面：

• 应用简略：Apache Doris 兼容 MySQL 协定，反对规范 SQL，有利于开发效率和共识对立，此外，Doris 的 ETL 编写脚本次要应用 SQL 进行开发，应用 MySQL 协定登陆应用，兼容少数 MySQL 语法，提供丰盛的数据分析函数，省去了 UDF 开发工作。
• 架构简略：Doris 的组件架构由 FE+BE 两类过程组成，不依赖其余零碎，降级扩容十分不便，故障排查链路十分清晰，有利于运维老本的升高。

极速性能

Doris 依靠于列式存储引擎、主动分辨别桶、向量计算、多方面 Join 优化和物化视图等性能的实现，能够笼罩泛滥场景的查问优化，海量数据也能能够保障低提早查问，实现分钟级或秒级响应。

极低成本

降本提效曾经成为现如今企业倒退的常态，收费的开源软件就比拟满足咱们的条件，另外基于 Doris 极简的架构、语言的兼容、丰盛的生态等，为咱们节俭了不少的资源和人力的投入。并且 Doris 反对 PB 级别的存储和剖析，对于存量历史数据较大、增量数据较少的公司来说，仅用 5-8 个节点就足以撑持上线应用。

社区沉闷

截止目前，Apache Doris 已开源数年，并已反对全国超 1500 企业生产应用，其健壮性、稳定性不可否认。另外社区十分沉闷，SelectDB 为社区组建了专职的技术支持团队，任何问题均能疾速反馈，提供无偿技术支持，应用起来没有后顾之忧。

运行架构

在对 Apache Doris 进一步测试验证之后，咱们齐全摒弃了之前应用 Hadoop、Hive、Spark 体系建设的数仓，决定基于 Doris 对架构进行重构，以 Apache Doris 作为数仓主体进行开发：

• 数据集成：利用 DataX、Flink CDC 和 Apache Doris 的 Multi Catalog 性能等进行数据集成。
• 数据管理：利用 Apache Dolphinscheduler 进行脚本开发的生命周期治理、多租户人员的权限治理、数据品质监察等。
• 监控告警：采纳 Grafana + Prometheus + Loki 进行监控告警，Doris 的各项监控指标能够在下面运行，解决了对组件资源和日志的监控问题。
• 数据服务：应用帆软 Report 为用户提供数据查问和剖析服务，帆软反对表单制作和数据填报等性能，反对自助取数和自助剖析。

数据模型

1）纵向分域

房地产中介行业的大数据主题大抵如下，个别会依据这些主题进行数仓建模。建模主题域外围围绕 ” 企业用户 ”、” 客户 ”、” 房源 ”、” 组织 ” 等几个业务实体开展，进行维度表和事实表的创立。

咱们从火线到后勤，对业务数据总线进行了梳理，旨在整顿业务实体和业务流动相干数据，如多个零碎之间存在同一个业务实体，应对立为一个字段。梳理业务总线有助于把握公司整体数据结构，便于维度建模等工作。

下图为咱们简略的梳理局部房地产中介行业的业务总线：

2）横向分层

数据分层是最常见的 5 层构造次要是利用 Apache Doris + Apache DolphinScheduler 进行层级数据之间 DAG 脚本调度。

存储策略： 咱们在 8 点到 24 点之间采纳增量策略，0 点到 8 点执行全量策略。采纳增量 + 全量的形式是为了在 ODS 表因为记录的历史状态字段变更或者 CDC 呈现数据未齐全同步的状况下，能够及时进行全量补数修改。

3）增量策略

1. where >= “ 业务工夫 - 1 天或 - 1 小时 ”

增量的 SQL 语句不应用 where="业务工夫当天" 的起因是为了防止数据漂移状况产生，换言之，调度脚本之间存在时间差，如 23:58:00 执行了脚本，脚本的执行周期是 10 分钟 / 次，然而源库最初一条数据 23:59:00 才进来，这时候 where="业务工夫当天" 就会将该数据漏掉。

2. 每次跑增量脚本前获取表中最大的主键 ID 存入辅助表，where >= "辅助表记录 ID"

如果 Doris 表应用的是 Unique Key 模型，且恰好为组合主键，当主键组合在源表产生了变动，这时候 where >="业务工夫 - 1 天" 会记录该变动，把主键发生变化的数据 Load 进来，从而造成数据反复。而应用这种自增策略可无效防止该状况产生，且自增策略只实用于源表自带业务自增主键的状况。

3. 表分区

如面对日志表等基于工夫的自增数据，且历史数据和状态根本不会变更，数据量十分大，全量或快照计算压力十分大的场景，这种场景须要对 Doris 表进行建表分区，每次增量进行分区替换操作即可，同时须要留神数据漂移状况。

4）全量策略

1. Truncate Table 清空表插入

先清空表格后再把源表数据全量导入，该形式实用于数据量较小的表格和凌晨没有用户应用零碎的场景。

2. ALTER TABLE tbl1 REPLACE WITH TABLE tbl2 表替换

这种形式是一种原子操作，适宜数据量大的全量表。每次执行脚本前先 Create 一张数据结构雷同的长期表，把全量数据 Load 到长期表，再执行表替换操作，能够进行无缝连接。

利用实际

业务模型

• 业务模型是分钟级调度 ETL
• 首次部署倡议配置：8 节点 2FE * 8BE 混合部署
• 节点配置：32C 60GB 2TB SSD
• 对于存量数据 TB 级、增量数据 GB 级的场景齐全够用，如有须要能够进行滚动扩容。

具体利用

1. 离线数据和日志数据集成利用 DataX 进行增量和全量调度，Datax 反对 CSV 格局和多种关系型数据库的 Redear，而 Doris 在很早之前就提供了 DataX Doris writer 连接器。

2. 实时统计局部借助了 Flink CDC 对源表进行实时同步，利用 Doris 的物化视图或者 Aggregate 模型表进行实时指标的汇总解决，因咱们只有局部指标须要实时处理，不心愿产生过多的数据库连贯和 Flink Job，因而咱们应用 Dinky 的多源合并和整库同步性能，也能够本人简略实现一个 Flink DataStream 多源合并工作，只通过一个 Job 可对多个 CDC 源表进行保护。值得一提的是，Flink CDC 和 Apache Doris 新版本反对 Schema Change 实时同步，在老本容许的前提下，可齐全应用 CDC 的形式对 ODS 层进行革新。

EXECUTE CDCSOURCE demo_doris WITH (
  'connector' = 'mysql-cdc',
  'hostname' = '127.0.0.1',
  'port' = '3306',
  'username' = 'root',
  'password' = '123456',
  'checkpoint' = '10000',
  'scan.startup.mode' = 'initial',
  'parallelism' = '1',
  'table-name' = 'ods.ods_*,ods.ods_*',
  'sink.connector' = 'doris',
  'sink.fenodes' = '127.0.0.1:8030',
  'sink.username' = 'root',
  'sink.password' = '123456',
  'sink.doris.batch.size' = '1000',
  'sink.sink.max-retries' = '1',
  'sink.sink.batch.interval' = '60000',
  'sink.sink.db' = 'test',
  'sink.sink.properties.format' ='json',
  'sink.sink.properties.read_json_by_line' ='true',
  'sink.table.identifier' = '${schemaName}.${tableName}',
  'sink.sink.label-prefix' = '${schemaName}_${tableName}_1'
);

3. 脚本语言采纳 Shell + SQL 或纯 SQL 的模式，咱们在 Apache DolphinScheduler 上进行脚本生命周期治理和公布，如 ODS 层，能够编写通用的 DataX Job 文件，通过传参的形式将 DataX Job 文件传参执行源表导入，无需在每一个源表编写不同的 DataX Job，反对对立配置参数和代码内容，保护起来十分不便。另外咱们在 DolphinsSheduler 上对 Doris 的 ETL 脚本进行治理，还能够进行版本控制，能无效管制生产环境谬误的产生，进行及时回滚。

4. 公布 ETL 脚本后导入数据，可间接在帆软 Report 进行页面制作，基于登陆账号来管制页面权限，如需管制行级别、字段级别权限，能够制作全局字典，利用 SQL 形式进行管制。Doris 齐全反对对账号的库表权限管制，这一点和 MySQL 的设置齐全一样，应用起来十分便捷。

除以上之外，在容灾复原、集群监控、数据安全等方面也有利用，比方利用 Doris 备份实现容灾复原、Grafana+Loki 对集群进行指标规定告警、Supervisor 对节点组件进行守护过程监控，开启 Doris 审计日志对执行 SQL 效率进行监控等，因篇幅限度，此处不进行具体阐明。

优化教训

1. 数据导入

咱们应用 DataX 进行离线数据导入，DataX 采纳的是 Stream Load 形式导入，该形式能够通过参数管制导入批次流量，DataX 导入不须要借助计算引擎，开箱即用的特点十分不便。另外，Stream Load 导入是同步返回后果的，其余导入形式个别是异步返回后果，针对咱们的架构来说，在 Dolphinscheduler 上执行异步导入数据会误以为该脚本曾经执行胜利，影响其失常运行。如采纳其余异步导入形式，倡议在 Shell 脚本中 执行 show load 再利用正则过滤状态进行判断。

2. 数据模型

咱们所有层级的表模型大部分采纳 Unique Key 模型，该模型可无效保证数据脚本的后果幂等性，Unique Key 模型能够完满解决上游数据反复的问题，大家能够依据业务模式来抉择不同的模型建表。

3. 内部数据源读取

Catalog 形式能够应用 JDBC 表面连贯，还能够对 Doris 生产集群数据进行读取，便于生产数据间接 Load 进测试服务器进行测试。另外，新版反对多数据源的 Catalog，能够基于 Catalog 对 ODS 层进行革新，无需应用 DataX 对 ODS 层进行导入。

4. 查问优化

尽量把非字符类型（如 int 类型、where 条件）中最罕用的字段放在前排 36 个字节内，在点查表过程中能够疾速过滤这些字段（毫秒级别），能够充分利用该个性进行数据表输入。

5. 数据字典

利用 Doris 自带的 information_schema 元数据制作简略的数据字典，这在还未建设数据治理体系前十分重要，当部门人数较多的时候，沟通老本成为倒退过程中最大的“拦路虎”，利用数据字典可疾速对表格和字段的全局查找和释义，最低老本造成数仓人员的数据标准，缩小人员沟通老本，进步开发效率。

架构收益

• 主动取数导数：数据仓库的明细表能够定时进行取数、导数，自助组合维度进行剖析。
• 效率晋升：T+1 的离线时效从小时计升高至分钟级
• 查问提早升高：面对上亿行数据的表，利用 Doris 在索引和点查方面的能力，实现即席查问 1 秒内响应，简单查问 5 秒内响应。
• 运维老本升高：从数据集成到数据服务，只需保护多数组件就能够实现整体链路高效治理。
• 数据管理体系：Doris 数仓的搭建，使得数据管理体系初步造成，数据资产得以规范化的积淀。
• 资源节俭：只用了多数服务器，疾速搭建起一套数据仓库，胜利实现降本赋能。同时 Doris 超高的压缩比，将数据压缩了 70%，相较于 Hadoop 来说，存储资源的耗费大幅升高。

总结与布局

目前咱们曾经实现数仓建设的初期指标，将来咱们有打算基于 Apache Doris 进行中台化的革新，同时 Apache Doris 在用户画像和人群圈选场景的能力非常强悍，反对 Bitmap 等格局进行导入和转换，提供了丰盛的 Bitmap 剖析函数等，后续咱们也将利用这部分能力进行客户群体剖析，放慢数字化转型。

最初，感激 Apache Doris 社区和 SelectDB 团队对美联物业的疾速响应和无偿反对，心愿 Doris 倒退越来越好，也心愿更多的企业能够尝试应用 Apache Doris。