Doris实战——拈花云科的数据中台实践

已于 2024-04-15 12:32:45 修改
阅读量1.9k 收藏 20
点赞数 22
分类专栏： 数仓建设 # Doris 文章标签： 数据仓库 大数据
于 2024-03-02 19:09:55 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/SHWAITME/article/details/136419217
版权

目录

前言

一、业务背景

二、数据中台1.0—Lambda

三、新架构的设计目标

四、数据中台2.0—Apache Doris

4.1 新架构数据流转

4.2 新架构收益

五、新架构的落地实践

5.1 模型选择

5.1.1 Unique模型

5.1.2 Aggregate模型

5.2 资源管理

5.3  批量建表

5.4 计算实现

5.4.1 实时计算

5.4.2 准实时计算 

通过 Java UDF 生成增量/全量数据

基于 Doris的大表优化

Doris Borker的协同计算

联邦查询在数据分析场景下的尝试

六、运维保障

6.1 守护进程

6.2 Grafana 监控报警

七、总结收益

八、未来规划

  原文大佬的这篇Doris数仓建设案例有借鉴意义，这里摘抄下来用作学习和知识沉淀。如有侵权请告知~

前言

     拈花云科NearFar X Lab 团队调研并引进 Doris作为新架构下的数据仓库选型方案。下文主要介绍了拈花云科数据中台架构从 1.0 到 2.0 的演变过程，以及Doris在交付型项目和SaaS产品中的应用实践。

一、业务背景

   拈花云科的服务对象主要是国内各个景区、景点，业务范围涵盖文旅行业的多个板块，如票务、交通、零售、住宿、餐饮、影院、KTV、租赁等。多业务线下用户对于数据使用的时效性需求差异较大，需要能够提供实时、准实时、T+1的业务支撑能力。同时由于大部分景区为国有化的特点，也需要具备能够提供私有化交付部署及SaaS化数据中台产品解决方案的双重服务支撑能力。

二、数据中台1.0—Lambda

  早期构建数据中台时，为了优先满足B端用户数据整合的需求，以稳定数据输出为出发点，因此基于行业中比较成熟的Lambda架构形成了数据中台 1.0 。

  在数据中台1.0架构中分为三层，分别为Batch Layer，Speed Layer 和 Serving Layer。其中，Batch Layer用于批量处理全部的数据，Speed Layer用于处理增量的数据，在Serving Layer中综合Batch Layer生成的Batch Views 和 Speed Layer 生成的Realtime Views，提供给用户查询最终的结果。

  Batch Layer：在早期的实施类项目中，单纯以离线T+1进行数据支持的项目占了绝大多数，但实施类项目在实现Lambda 架构的过程中也会面临很多问题。例如：由于项目本身的原因，业务系统不能开放DB 的Binlog 供数据仓库采集，因此只能以JDBC的方式完成增量或全量的数据同步，而通过该方式同步的数据，往往会由于源端系统人工补充数据、时间戳不规范等问题产生同步数据差异的情况发生，最终只能通过额外的数据对比逻辑进行校验，以保证其数据的一致性。

  Speed Layer：项目受成本约束较大，大面积基于流的实时计算对于不论是从硬件成本、部署成本还是实施成本，维护成本等角度均难以支撑。基于该原因，在实施类项目中只有部分业务会进行基于流的实时统计计算，同时满足流计算条件的业务上游系统也同时满足同步Binlog 的使用需求。

  Serving Layer：大部分的预计算结果存储在MySQL 中提供 Report 支持，部分实时场景通过Merge Query 对外提供Ad-Hoc(数据探索)的查询支持。

   随着时间的推移，大量的项目交付使用增多，架构的问题也逐渐开始显现：

  • 开发和维度成本高：该架构需要维护两套代码，即批处理和实时处理的代码，这无疑增加了开发和维护的成本。
  • 数据处理复杂度高：Lambda 架构需要处理多个层次的数据，包括原始数据、批处理数据和实时数据，需要对不同的数据进行清洗、转换和合并，数据处理的复杂度较高。
  • 实时计算支持有限：业务方对于数据时效性要求越来越高，但是该架构能力有限，无法支持更多、更高要求的的实时计算。

  • 资源利用率低：离线资源较多，但仅在凌晨后的调度时间范围内使用，资源利用率不高。

  • 受成本制约：该架构对于部分用户而言使用成本较高，难以起到降低成本提高效率的作用。

三、新架构的设计目标

   基于以上架构问题，希望实现一套更加灵活的架构方案，同时希望新的架构可以满足日益增高的数据时效性要求。在新方案实现之前，先对当前的业务应用场景和项目类型进行分析。业务应用场景分为以下四类，这四类场景的特点和需求分别是：

  • 看板类Reporting：包括 Web/移动端数据看板和大屏可视化，用于展示景区重要场所的数据，如业务播报（实时在园人数监控、车船调度管理等）、应急管理监控（客流密度监控、景区消防预警、景区能耗监控等）。其组成特点一般是业务汇总指标和监控指标报警，对数据时效性要求较高。
  • 报表类：数据报表以图表形式展示，主要服务于各业务部门的一线业务人员。会更多关注垂直业务的数据覆盖程度，会有钻取需求（也可能通过不同报表来体现不同数据粒度）。一般以景区的业务部门为单位构建报表栏目和分析主题，除财务结算类报表外，一般可接受 T+1 的报表时效。
  • 分析类：自助分析基于较好的数据模型表（数据宽表）实现，对分析人员有一定的数据理解和操作需求，基于提供的BI分析平台，业务人员可基于此数据范围通过拖拽的方式组合出自己的数据结果，灵活度较高。该场景对数据时效性要求不高，更多关注业务数据沉淀和与往期历史数据的对比分析，侧重架构的OLAP能力。
  • 服务类：一般对接三方系统，由数据中台提供数据计算的结果。如画像标签等数据，通过数据接口控制权限，提供对外数据服务与其他业务系统集成，需要新架构能够提供稳定的数据服务

     对项目类型的特点和需求进行分析，并确定新架构需要同时提供实施类项目和 SaaS产品的数据中台支撑能力：

四、数据中台2.0—Apache Doris

   结合以上需求，计划对原有架构进行升级，并对新架构的OLAP引擎进行选型。在对比了ClickHouse等OLAP引擎后，最终选择了Doris 作为数据中台 2.0 的基座。同时，在数据的同步、集成即计算环节，也构建了多套方案来适配以Doris 为核心的计算链路，以应对不同类型的实施类项目及SaaS产品需求。

   

      数据中台 2.0的核心思路是将Doris作为核心的数据仓库，并将其作为实时数据同步中心，核心数据计算中心。数据集成环节将专注于数据同步，而计算交由Doris 完成或由 Doris 辅助计算引擎完成。同时，将在提供多种数据同步至Doris 的方案以应对不同的项目需求。在这个架构下，支持实现实时、准实时、T+1的计算场景支持，以满足不同业务场景的需求。

4.1 新架构数据流转

 1）数据同步集成：架构 2.0 有多种数据同步方式，主要借助Doris Unique Key模型完成数据的同步更新。

2）数据分层计算：根据项目资源情况分View/实体表单来构建后面的数据层级（DWD，DWS，ADS）。业务较轻或时效性很高的，通过View方式来实现逻辑层面的DWD，通过这种方式为下游Ad-hoc（数据探索）提供宽表查询支持，Doris的谓词下推及View优化的能力，为使用视图查询带来了便利。而当业务较重时，通过实体表单+微批任务进行实现，按照调度依赖关系逐层完成计算，针对使用场景对表单进行优化。

3）数据计算时效：新架构下的数据时效受具体数据计算链路中三个方面限制，分别是数据采集时效、批次计算时效、数据查询耗时。在不考虑网络吞吐、消息积压、资源抢占的情况下：

（实施类项目经常会遇到第三方不提供 Binlog 的情况，所以这里把通过批次采集数据也作为一个 case 列出来）

    在Doris中为了达到更好的计算时效，基于Doris的数据计算流程相比在Hive中的计算流程可以进行一定的简化，这样可避免过多的冗余计算设计，以此提高计算产出效率。

4）补充架构能力：

  Hadoop：根据不同的项目资源及数据情况来决定是否引入Hadoop 补充大规模离线计算场景。以实施类项目为例，Doris可以涵盖大部分核心业务数据计算场景。

  MySQL：基于预计算的结果数据可以推送到下游MySQL 中以供Report查询，从而分散 Doris 计算查询的资源消耗，这样可以将资源充分留给核心且时效性要求高的应用或高频批次任务。如果计算资源充足，Doris也可以直接作为应用层的加速查询DB，而无须引入其它 DB。

4.2 新架构收益

    通过引入Doris，成功构建了高时效、低成本的数据中台2.0，并成功满足了交付型项目和 SaaS 产品两种需求场景下的使用需求。新架构的收益如下：

  • 数据时效性提升：架构1.0中大部分业务为 T+1 的支持方式，而在新架构下大部分业务都可实现实时或小时级的计算支持
  • 资源利用率提高：在架构1.0中，离线资源在白天大部分时间处于闲置状态。而在新架构下，数据同步，计算（增量/全量）和查询均在同一集群下完成，从而提高了资源利用率。相较于部署一套 CDH，同等资源成本下，部署一套Doris可以带来更多的收益。
  • 运维管理成本降低：在原有架构下，实时统计需求需要维护非常长的计算链路。而在新架构下，所有计算仅需在一个数据库中完成，更加简单、高效且易于维护。
  • 易于业务扩展：Doris的节点扩展操作便捷，这对于业务的增量支持友好。

五、新架构的落地实践

    在2022年底首次在测试环境中部署了Doris 1.1.5 版本，并进行了一些业务数据的导入测试和新架构的可行性验证。在测试后，决定在生产环境中落地实践 Doris。目前，新项目升级到1.2.4版本并使用。Doris作为新架构下的核心系统，在整个架构中发挥着重要的作用。下面从模型选择、资源规划、表架构同步、计算场景实现、运维保障等几个角度分享基于Doris 的项目落地经验。

5.1 模型选择

5.1.1 Unique模型

  对于ODS层的表单来说，需要Doris Table与源系统数据保持实时同步。为了保证数据同步的一致性，采用了Unique模型，该模型会根据主键来对数据进行合并。在1.2.0 版本推出之后，采用了新的 Merge On Write的数据更新方式，在 Unique Key 写入过程中，Doris会对新写入的数据和存量数据进行Merge操作，从而大幅优化查询性能。因此在使用 1.2 版本中，建议打开 Doris BE 的 Page Cache（在be.conf文件中增加配置项disable_storage_page_cache = false）。另外在很多情况洗，Unique 模型支持多种谓词的下推，这样表单也可以支持从源表直接建立视图的查询方式。

5.1.2 Aggregate模型

    在某些场景下（如维度列和指标列固定的报表查询），用户只关心最终按维度聚合后的结果，而不需要明细数据的信息。针对这种情况，建议使用Aggregate模型来创建表，该模型以维度列作为 Aggregate Key 建表。在导入数据时，Key列相同的行会聚合成一行（目前Doris支持 SUM、REPLACE、MIN、MAX 四种聚合方式）

   Doris 会在三个阶段对数据进行聚合：

  • 数据导入的ETL阶段，在每一批次导入的数据内部进行聚合；
  • 底层BE进行数据Compaction合并阶段；

  • 数据查询阶段

     聚合完成之后，Doris 最终只会存储聚合后的数据，这种明细表单数据的预聚合处理大大减少了需要存储和管理的数据量。当新的明细数据导入时，它们会和表单中存储的聚合后的数据再进行聚合，以提供实时更新的聚合结果供用户查询。

5.2 资源管理

    在生产环境中，使用一套 Doris 数据仓库支撑了多个下游数据应用系统的使用。这些应用系统对数据访问的资源消耗能力不同，对应的业务重要等级也不相同。为了能够更好管理应用资源的使用，避免资源冲突，需要对应用账号进行划分和资源规划，以保证多用户在同一 Doris集群内进行数据操作时减少相互干扰。而Doris的多租户和资源隔离功能，可以帮助更合理地分配集群资源。Doris 对于资源隔离控制有两种方式，一是集群内节点级别的资源组划分，二是针对单个查询的资源限制。这里主要介绍下方式一的集群内节点级别的资源组划分过程。

1）第一步：需要梳理规划各场景的用途、重要等级及资源需求等，举例说明：

2）第二步：对节点资源进行划分、给节点打上 tag标签：

alter system modify backend "10.10.101.1:9050" set ("tag.location" = "group_a");
alter system modify backend "10.10.101.2:9050" set ("tag.location" = "group_a");
alter system modify backend "10.10.101.3:9050" set ("tag.location" = "group_b");
alter system modify backend "10.10.101.4:9050" set ("tag.location" = "group_b");
alter system modify backend "10.10.101.5:9050" set ("tag.location" = "group_c");
alter system modify backend "10.10.101.6:9050" set ("tag.location" = "group_c");

3）第三步：给应用下的表单指定资源组分布，将用户数据的不同副本分布在不同资源组内:

create table flume_etl<table>
(k1 int, k2 int)
distributed by hash(k1) buckets 1
properties(
    "replication_allocation"="tag.location.group_a:2, tag.location.group_b:1"
)

create table cdc_etl<table>
```   
    "replication_allocation"="tag.location.group_b:2, tag.location.group_c:1"

create table etl<table>
```
    "replication_allocation"="tag.location.group_a:1, tag.location.group_c:2"

create table mkui_readonly<table>
```
    "replication_allocation"="tag.location.group_a:2, tag.location.group_c:1"

create table SaaS_readonly<table>
```
    "replication_allocation"="tag.location.group_a:1, tag.location.group_b:1, tag.location.group_c:1"

create table dev<table>
`` `
    "replication_allocation"="tag.location.group_a:1, tag.location.group_b:1, tag.location.group_c:1"

 4）第四步：设置用户的资源使用权限，来限制某一用户的查询只能使用其指定资源组中的节点来执行。

set property for 'flume_etl' 'resource_tags.location' = 'group_a';
set property for 'cdc_etl' 'resource_tags.location' = 'group_b';
set property for 'etl' 'resource_tags.location' = 'group_c';
set property for 'mkui_readonly' 'resource_tags.location' = 'group_a';
set property for 'SaaS_readonly' 'resource_tags.location' = 'group_a, group_b, group_c';
set property for 'dev' 'resource_tags.location' = 'group_b';

      在Doris 2.0 版本中基于Pipeline执行引擎增加了 Workload Group 能力。 通过对Workload 进行分组管理，以保证内存和CPU资源的精细化管控。

    通过将 Query 与 Workload Group 相关联，可以限制单个 Query （查询）在BE节点上的CPU 和内存资源的百分比，并可以配置开启资源组的内存软限制。当集群资源紧张时，将自动 Kill 组内占用内存最大的若干个查询任务以减缓集群压力。当集群资源空闲时，一旦 Workload Group 使用资源超过预设值时，多个 Workload 将共享集群可用空闲资源并自动突破阙值，继续使用系统内存以保证查询任务的稳定执行。更详细的Workload Group 介绍可以参考：

WORKLOAD GROUP - Apache Doris

5.3  批量建表

     初始化完成Doris的建表映射往往需要构建很多表单，而单独建表低效且易出错。为此，根据官方文档的建议使用Cloudcanal 进行表结构同步来批量建表，大大提高了数据初始化的效率。

    建表时需要注意的是：以 MySQL为例，MySQL数据源映射到Doris表结构的过程中需进行一定的表结构调整。在 MySQL 中varchar(n) 类型的字段长度是以字符个数来计算的，而 Doris 是以字节个数计算的。因此，在建表时需要将Doris varchar 类型字段的长度调整到MySQL 对应字段长度的 3 倍。在使用Unique 模型时需要注意建表时UNIQUE KEY 列要放在 Value 列前面声明，且保证有序排列和设置多副本配置。

     除了以上方式， Doris-Flink-Connector 1.4.0 版本中集成了 Flink CDC、实现从 MySQL 等关系型数据库到Doris 的一键整库同步功能。用户无需提前在 Doris 中建表、可以直接使用Connector 快速将多个上游业务库的表结构及数据接入到Doris 中。

5.4 计算实现

    根据对架构 2.0的规划，将所有计算转移在 Doris 中完成。然而在支撑实时和准实时的场景下，具体的技术实现会有所不同，主要区别如下：

5.4.1 实时计算

    如上文提到会以实时数据采集 + Doris视图模型的方式提供实时计算结果，而为了在计算过程中达到更高的数据时效支持，应该尽量减少不必要的数据冗余设计。如传统数据仓库会按照ODS-->DWD-->DWS-->ADS等分层逐层计算落表。而在实时计算场景下可以适当进行裁剪，裁剪的依据为整体查询时效的满足情况。此外，在实际的业务场景中也会有多层视图嵌套调用的情况。

5.4.2 准实时计算 

    在业务能接受的准实时场景下（10分钟、30分钟、小时级），可以通过实体表单 + 微批任务实现计算，计算过程按照调度层级依赖关系逐层完成。

  • 通过 Java UDF 生成增量/全量数据

    在实际业务中，存在增量/全量的日、月、年等不同时间频度数据生成需求。通过Doris的Java UDF 功能(1.2 版本后支持) +调度系统传参的方式实现了一套脚本动态的生成增量/全量及日、月、年等不同的指标汇总。实现思路：

  • period_type计算频度 D/W/M/Y 代表计算日、周、月、年
  • run_type：INC（增量）/ DF（全量）是通过传递begin_date,end_datel来筛选business_date数据进行汇总。

1）增量满足：begin_date(对应计算频度开始日期) <= business_date <= end_date （对应计算频度结束日期）

2）全量满足：begin_date(写死一个业务最小日期) <= business_date <= end_date （对应计算频度结束日期）

    基于以上思路实现etlbegindate 函数（UDF函数开发）来返回不同计算频度下增量、全量的 begin_date

etlbegindate(run_type,period_type,end_date)

    为了在统计不同频度时能够生成对应频度的识别id字段，我们还需要实现一个periodid函数

periodid(period_type,business_date)

    该函数的主要功能为：

  • period_type = 'D' 返回 business_date 所在日， 'YYYYMMDD' 格式的 period_id 字段
  • period_type = 'W' 返回 business_date 所在周的起始日期， 'YYYYMMDDYYYYMMDD' 格式的 period_id 字段
  • period_type = 'M' 返回 business_date 所在月，'YYYYMM' 格式的 period_id 字段
  • period_type = 'Y' 返回 business_date 所在年，'YYYY' 格式的 period_id 字段

     结合etlbegindate与 periodid 两个函数，假定当前时间为 2023 年 6 月16 日，则相应的实现如下：

    SQL 脚本使用函数示例：

  -- 示例Demo
  select ${period_type}                          as period_type -- 统计频度 D/W/M/Y
        ,period_id(${period_type},business_date) as period_id   -- 时间频度ID
        ,count(goods_id)                         as goods_cnt   -- 商品数
   where business_date >= etlbegindate(${run_type},${period_type},${end_date})
     and business_date <= ${end_date}
group by period_id

    运行调度前参数配置：

   任务运行结果示例：W/M/Y 是的实现方式一致，只是数据返回的period_id 格式会按照上文描述的格式输出。

  基于以上方法，高效地为公司SaaS 产品构建了相应的数据指标库应用。

基于 Doris的大表优化

   业务涉及基于用户页面访问和景区设备日志信息的统计分析业务，这类指标计算需要处理大量日志数据。接下来将介绍如何利用 Doris 提供的功能对数据进行优化处理。

   数据分区分桶：Doris 支持两级分区，第一级叫做 Partition，支持 Range Partitioning 和 List Partitioning 两种分区策略。第二级分区叫做 Bucket，支持 Hash Partitioning分区策略。

   对于用户浏览行为的埋点事件表，按照时间做为分区（Range Partitioning）：

   在实际应用中，业务的历史冷数据可以按年进行分区，而近期的热数据可以根据数据量增幅按照日、周、月等进行分区。另外，Doris 自 1.2.0 版本后支持批量创建Range分区，语法简洁灵活。

  从 Doris1.2.2 版本开始，Doris支持了自动分桶功能，免去了分桶上面的投入，一个分桶在物理层面为一个 Tablet，官方文档建议 Tablet 大小在1GB - 10GB 之内，因此对于小数据量分桶数不应太多。自动分桶的开启只需要建表时新增一个属性配置：

  DISTRIBUTED BY HASH(openid) BUCKETS AUTO PROPERTIES ("estimate_partition_size" = "1G"）
Doris Borker的协同计算

  业务中存在部分大数据量的历史数据统计需求，针对这部分需求进行了协同计算处理

  • FlinkCDC 读取 Binglog 实时同步数据到 Doris明细表
  • Doris明细表会存储近30日热数据（需要进行TTL管理）
  • Doris每日通过Borker Export 同步一份日增量数据至HDFS，并加载至 Hive 中
  • Hive 中储存所有明细数据，数据初始化生成计算结果在Hive中完成 Borker Load 至 Doris
  • Doris 在生成结果数据时仅生成当前日期数据，每天的增量生成沉淀为历史结果
  • 当业务有需要时通过 Borker Export 加载Hive全量计算结果刷新Doris 结果表
  • 当业务有基于此明细数据的新开发需求时，可在Hive中计算完成初始化结果至 Doris

   数据导出（Export）：Export 是 Doris 提供的一种将数据导出的功能。该功能可以将用户指定的表或分区的数据以文本的格式，通过 Broker 进程导出到远端存储上，如 HDFS 或对象存储（支持 S3 协议） 等。用户提交一个 Export 作业后，Doris 会统计这个作业涉及的所有 Tablet，然后对这些 Tablet 进行分组，每组生成一个特殊的查询计划。这些查询计划会读取所包含的 Tablet 上的数据，然后通过 Broker 将数据写到远端存储指定的路径中。

    数据导入（Broker load）：Broker Load 是 Doris 的一种异步数据导入方式，可以导入 Hive、HDFS 等数据文件。Doris 在执行 Broker Load 时占用的集群资源比较大，一般适合数据量在几十到几百 GB 级别下使用。同时需要注意的是单个导入 BE 最大的处理量为 3G，如果超过 3G 的导入需求就需要通过调整Broker Load 的导入参数来实现大文件的导入。

联邦查询在数据分析场景下的尝试

  由于上游数据源较多，我们仅对常用的数据表单进行了数据仓库采集建模，以便更好地进行管理和使用。对于不常用到的数据表单，我们没有进行入仓，但业务方有时会临时提出未入仓数据的统计需求，针对这种情况，我们可以通过 Doris的Multi-Catalog（多源目录）进行快速响应、完成数据分析 ，待需求常态化后再转换成采集建模的处理方式。

    Multi-Catalog 是 Doris 1.2.0 版本中推出的重要功能。该功能支持将多种异构数据源快速的接入Doris，包括Hive、Iceberg、Hudi、MySQL、Elasticsearch 和 Greenplum 等。使用 Catalog 功能，可以在Doris中统一的完成异构数据源之间的关联计算。Doris1.2.0 以后的版本官方推荐通过 Resource 来创建 Catalog，这样在多个使用场景下可以复用相同的 Resource。下面是Doris本地表与通过Multi-Catalog映射的远程表单组合完成关联计算的场景示例。

     Multi-Catalog带来的收益：

  • 更高的灵活性：通过Multi-Catalog，用户可以灵活地管理不同数据源的数据，并在不同的数据源之间进行数据交换和共享。这可以提高数据应用的可扩展性和灵活性，使其更适应不同的业务需求。
  • 高效的多源管理：由于 Multi-Catalog可以管理多个数据源，用户可以使用多个 Catalog 来查询和处理数据，解决了用户跨库访问不便的问题，从而提高数据应用的效率。

    社区中已经有非常多的伙伴基于 Multi-Catalog 功能落地了应用场景。另外如果要深度使用该功能，建议建立专门用于联邦计算的BE 节点角色，当查询使用 Multi-Catalog 功能时，查询会优先调度到计算节点。

六、运维保障

6.1 守护进程

     为了保障 Doris 进程的持续运行，按照 Doris 官网的建议在生产环境中将所有实例都的守护进程启动，以保证进程退出后自动拉起，安装部署了Supervisor 来进行进程管理，Supervisor 是用 Python 开发的一套通用的进程管理程序，可以将一个普通的命令行进程变为后台 Daemon 并监控进程状态，当进程异常退出时自动重启。使用守护进程后，Doris 的进程变成了 Supervisor 的子进程，Supervisor 以子进程的 PID 来管理子进程，并可以在异常退出时收到相应的信号量。

   配置Supervisor 时的注意事项：

  • 通过supervisorctl status查询出来的进程 id不是 Fe、Be、Broker 的进程 ID，而是启动它们的 Shell 进程 ID。在start_xxx.sh中会启动真正的Doris 进程，因此才有了进程树的说法。

  • stopasgroup=true; 是否停止子进程、killasgroup=true ;是否杀死子进程，需要保证这两个参数为true，否则通过supervisorctl控制 Doris 的后台进程是无效的，这也是通过 Supervisor 守护 Doris 进程的关键。

   配置完 Supervisor 后则通过守护进程的方式来管理 FE、BE、Borker……

    由于 Superviosr 自带的 Web UI 不支持跨机器管理，当多节点时管理非常不便，这里可以使用 Cesi 来对Supervisor 进行合并管理：

6.2 Grafana 监控报警

   关于 Doris 的运行监控，按照官网相关内容部署了Prometheus 和 Grafana ，并进行监控项的采集。同时对于一些关键指标进行了预报警，利用企微Bot完成信息推送。

  以下为测试环境示例图：

  集群CPU空闲情况:

   集群内存使用情况:之前发现集群存在内存泄露

   开始调度运行的Tablet 数量：正常情况该值基本为 0 或个位数，出现波动的Tablet 说明可能在进行 Recovery 或 Balance。

   除此之外，还使用 QPC/99th Latency……等指标来查看监测集群服务能力，建议可以在 Doris 监控的基础上额外加入集群机器的监控，因为机器部署在VM中，曾经出现过硬盘问题、内存问题、网络波动、专线异常等情况，多一层报警机制就多一份稳定性保障。

七、总结收益

   通过新架构的成功搭建，实现了以 Doris为核心数据仓库 + OLAP引擎的使用方式（All in One），有效缩减了数据处理流程，大大降低了投递型项目的实施成本。在旧架构下，需要部署、适配、维护非常多的组件，无论是实施还是运维都会比较繁重。相比之下，新架构下的Doris 易于部署、扩展和维护，组合方案也灵活多变。在近半年的使用时间内，Doris 运行非常稳定，为项目交付提供了强有力的计算服务保障能力。

    此外，基于Doris 丰富的功能、完善的文档，可以针对离线和在线场景进行高效且细致的数据开发和优化。通过引入 Doris ，在数据服务时效性方面也有了大幅提高，当前已经成功地落地了多个数据项目，并孵化出了一个基于 Doris 的 SaaS 产品

八、未来规划

    结合 Doris 的功能特性提炼基于Doris 的数仓方法论，优化开发过程。Doris 是一个包容性非常好的存储计算引擎，而想要将原有的数据仓库开发内容全部适配在 Doris 上还需要不断的学习、优化与调整，以充分发挥 Doris 的优势，同时我们也将在此基础上沉淀一套与之相匹配的开发规范。

参考文章：

Apache Doris 在的统一数据中台实践，One Size Fits All

吵吵叭火
关注
  • 22
    点赞
  • 踩
  • 20
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
基于Apache Doris的数据中台建设思路规划
03-06
基于Apache Doris的数据中台建设思路规划
CDH 部署 Elasticsearch
Kafka_yx的博客
03-27 618
制作Elasticsearch的Parcel包和csd文件制作Elasticsearch的Parcel包和csd文件将Parcel包和manifest.json文件部署到httpd服务中 制作Elasticsearch的Parcel包和csd文件 借鉴地址：https://www.cnblogs.com/zhangrui153169/p/11447423.html 配置java，maven等环...
大数据最全架构设计之大数据架构（Lambda架构、Kappa架构），2024年最新不可多得的干货
最新发布
2401_84160041的博客
05-11 1404
分布式、面向列的开源数据库，适合于非结构化数据存储。【实时数据和离线数据均支持】。: 高可用/可靠，分布式海量日志采集、聚合和传输的系统，Flume支持在日志系统中定制各类数据发送方，用于收集数据;同时，Flume提供对数据进行简单处理，并写到各种数据接受方(可定制)的能力。：一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者在网站中的所有动作流数据。：开放源码的分布式应用程序协调服务，是Hadoop和Hbase的重要组件。
CDH6.3.2安装包全+Flink+Doris2.0 都是CDH适配的，采用阿里网盘的方式
07-08
CDH6.3.2安装包全+Flink1.17+Phonex+Doris2.0 都是CDH适配的
海量数据分析引擎Apache Doris入门及实战
01-25
本门课程主要讲解百度开源海量数据分析引擎Apache Doris的从概念、编译、安装到编程实战。第一部分我会讲解Doris的基本概念，告诉大家Doris的使用场景，明白我们为什么使用Doris，另外有哪些公司在使用Doris；第二部分会学习Doris的手动编译、单机部署和集群部署以及可视化的工具；第三部分我们介绍Doris的基本操作；第四部分会介绍Doris的账号和权限；最后会带着大家进行SpringBoot操作Doris的实战开发。
大数据架构之-- Lambda架构
热门推荐
一锅粥
12-14 2万+
一、什么是Lambda架构 Lambda架构由Storm 的作者 [Nathan Marz] 提出， 根据维基百科的定义，Lambda 架构的设计是为了在处理大规模数据时，同时发挥流处理和批处理的优势。通过批处理提供全面、准确的数据，通过流处理提供低延迟的数据，从而达到平衡延迟、吞吐量和容错性的目的。为了满足下游的即席查询，批处理和流处理的结果会进行合并。 二、Lambda架构组成 Lambda 架构包含三层，Batch Layer、Speed Layer 和 Serving Layer。架.
基于Flink+Doris构建亿级全端电商实时数据分析平台
05-07
上层应用业务对实时数据的需求，主要包含两部分内容：1、 整体数据的实时分析。2、 AB实验效果的实时监控。这几部分数据需求，都需要进行的下钻分析支持，我们希望能够建立统一的实时OLAP数据仓库，并提供一套安全、可靠的、灵活的实时数据服务。目前每日新增的曝光日志达到几亿条记录，再细拆到AB实验更细维度时，数据量则多达上百亿记录，多维数据组合下的聚合查询要求秒级响应时间，这样的数据量也给团队带来了不小的挑战。OLAP层的技术选型，需要满足以下几点：1：数据延迟在分钟级，查询响应时间在秒级2：标准SQL交互引擎，降低使用成本3：支持join操作，方便维度增加属性信息4：流量数据可以近似去重，但订单行要精准去重5：高吞吐，每分钟数据量在千W级记录，每天数百亿条新增记录6：前端业务较多，查询并发度不能太低通过对比开源的几款实时OLAP引擎，可以发现Doris和ClickHouse能够满足上面的需求，但是ClickHouse的并发度太低是个潜在的风险，而且ClickHouse的数据导入没有事务支持，无法实现exactly once语义，对标准SQL的支持也是有限的。所以针对以上需求Doris完全能解决我们的问题，DorisDB是一个性能非常高的分布式、面向交互式查询的分布式数据库，非常的强大，随着互联网发展，数据量会越来越大，实时查询需求也会要求越来越高，DorisDB人才需求也会越来越大，越早掌握DorisDB，以后就会有更大的机遇。本课程基于真实热门的互联网电商业务场景为案例讲解，具体分析指标包含：AB版本分析，下砖分析，营销分析，订单分析，终端分析等，能承载海量数据的实时分析，数据分析涵盖全端（PC、移动、小程序）应用。整个课程，会带大家实践一个完整系统，大家可以根据自己的公司业务修改，既可以用到项目中去，价值是非常高的。本课程包含的技术：开发工具为：IDEA、WebStormFlink1.9.0DorisDBHadoop2.7.5Hbase2.2.6Kafka2.1.0Hive2.2.0HDFS、MapReduceFlume、ZookeeperBinlog、Canal、MySQLSpringBoot2.0.8.RELEASESpringCloud Finchley.SR2Vue.js、Nodejs、Highcharts、ElementUILinux Shell编程等课程亮点：1.与企业接轨、真实工业界产品2.DorisDB高性能分布式数据库3.大数据热门技术Flink4.支持ABtest版本实时监控分析5.支持下砖分析6.数据分析涵盖全端（PC、移动、小程序）应用7.主流微服务后端系统8.天级别与小时级别多时间方位分析9.数据库实时同步解决方案10.涵盖主流前端技术VUE+jQuery+Ajax+NodeJS+ElementUI11.集成SpringCloud实现统一整合方案12.互联网大数据企业热门技术栈13.支持海量数据的实时分析14.支持全端实时数据分析15.全程代码实操，提供全部代码和资料16.提供答疑和提供企业技术方案咨询企业一线架构师讲授，代码在老师的指导下企业可以复用，提供企业解决方案。  版权归作者所有，盗版将进行法律维权。 
基于Flink+Doris构建高性能高扩展的全端实时数据仓库教程
06-15
课程总体架构请观看89讲。数据仓库是一个面向主题的、集成的、随时间变化的、但信息本身相对稳定的数据集合，用于对管理决策过程的支持。数据仓库的应用有：1.数据分析、数据挖掘、人工智能、机器学习、风险控制、无人驾驶。2.数据化运营、精准运营。3.广告精准、智能投放等等。数据仓库是伴随着企业信息化发展起来的，在企业信息化的过程中，随着信息化工具的升级和新工具的应用，数据量变的越来越大，数据格式越来越多，决策要求越来越苛刻，数据仓库技术也在不停的发展。数据仓库有两个环节：数据仓库的构建与数据仓库的应用。随着IT技术走向互联网、移动化，数据源变得越来越丰富，在原来业  务数据库的基础上出现了非结构化数据，比如网站log，IoT设备数据，APP埋点数据等，这些数据量比以往结构化的数据大了几个量级，对ETL过程、存储都提出了更高的要求。互联网的在线特性也将业务需求推向了实时化 ，随时根据当前客户行为而调整策略变得越来越常见，比如大促过程中库存管理，运营管理等（即既有中远期策略型，也有短期操作型）。同时公司业务互联网化之后导致同时服务的客户剧增，有些情况人工难以完全处理，这就需要机器 自动决策 。比如欺诈检测和用户审核。总结来看，对数据仓库的需求可以抽象成两方面： 实时产生结果、处理和保存大量异构数据。本课程基于真实热门的互联网电商业务场景为案例讲解，结合分层理论和实战对数仓设计进行详尽的讲解，基于Flink+DorisDB实现真正的实时数仓,数据来及分析,实时报表应用。具体数仓报表应用指标包括：实时大屏分析、流量分析、订单分析、商品分析、商家分析等，数据涵盖全端（PC、移动、小程序）应用，与互联网企业大数据技术同步，让大家能够学到大数据企业级实时数据仓库的实战经验。本课程包含的技术： 开发工具为：IDEA、WebStorm Flink 1.11.3Hadoop 2.7.5Hive 2.2.0ZookeeperKafka 2.1.0、Spring boot 2.0.8.RELEASESpring Cloud Finchley.SR2Flume 、Hbase 2.2.6DorisDB 0.13.9、RedisVUE+jQuery+Ajax+NodeJS+ElementUI+Echarts+Datav等课程亮点： 1.与企业接轨、真实工业界产品2.DorisDB高性能分布式数据库3.大数据热门技术Flink最新版4.真正的实时数仓以及分层设计5.海量数据大屏实时报表6.数据分析涵盖全端（PC、移动、小程序）应用7.主流微服务后端系统8.数据库实时同步解决方案9.涵盖主流前端技术VUE+jQuery+Ajax+NodeJS+ElementUI+Echarts+Datav10.集成SpringCloud实现统一整合方案11.互联网大数据企业热门技术栈12.支持海量数据的实时数仓报表分析13.支持全端实时实时数仓报表分析14.全程代码实操，提供全部代码和资料 15.提供答疑和提供企业技术方案咨询企业一线架构师讲授，代码在老师的指导下企业可以复用，提供企业解决方案。  版权归作者所有，盗版将进行法律维权。 
数据中台，用户画像的技术和方法论
03-21
用户画像和商品画像作为数据中台的重要组成部分，是实现精细化运营的关键工具。通过全面理解和运用这两者，企业可以更深入地理解用户，提升用户满意度，同时优化商品策略，促进业务发展。在实际操作中，应持续探索和...
数据中台产品介绍+联邦学习
02-28
数据中台产品是一种现代化的数据管理解决方案，旨在帮助企业管理和利用数据，以驱动业务创新和提高数据资产的价值。 UltraInsight 数字中台 V1.0030201 是一个基于隐私计算的平台，它集成了多种功能，包括数据资产化...
Apache Doris数据分析综合案例实战
05-07
Apache Doris数据分析综合案例实战
Doris在数仓中的实践.pdf
09-19
本文将详细介绍 Doris 在数仓中的应用和实践，包括业务背景、技术选型、系统架构、实时查询系统、数据模型等方面的内容。 业务背景 在数仓中，数据查询是非常重要的一步，需要能够快速、实时地返回结果。但是，...
Doris集成cloudera Manager
wm_1002的博客
09-02 2466
doris集成cm管理，实现自动化部署，参数变更
Doris动态表使用快速入门实战
wangleigiser的博客
06-08 1695
半结构化数据，是介于结构化和非结构化之间的数据。和普通纯文本相比，半结构化数据具有一定的结构性。和结构化数据相比，其结构变化复杂，我们又不能方便的使用结构化的方式去描述它。半结构的数据中通常即包括数据本身，也包括数据结构的描述。数据结构自描述：结构与数据相融合在一起，一条数据即包括“元数据”也包括“数据”。数据结构复：数据结构难以纳入现有的各种描述框架，实际应用中不易进行清晰的理解与把握。数据结构描述的动态性：数据变化通常会导致结构模式变化，整体上具有动态的结构模式。
Doris实战——网易互娱的应用实践
爱吃辣条的博客
03-03 1083
Doris实战——网易互娱的应用实践
架构设计之大数据架构（Lambda架构、Kappa架构）
Elaine的博客
10-31 4991
Lambda、Kappa大数据架构介绍
Doris实战——金融壹账通指标中台的应用实践
爱吃辣条的博客
03-01 1034
Doris实战——金融壹账通指标中台的应用实践
大数据Lambda架构详解
null的专栏
03-11 1万+
Lambda架构是Nathan Marz提出的一个实时大数据处理框架。Nathan Marz是著名的实时大数据处理框架Storm的作者，Lambda架构就是其根据多年分布式大数据系统的经验总结提炼而成。 Nathan Marz 在Big Data:Principles and best practices of scalable real-time data systems一书中提到了很多实时大数据系统的关键特性，包括容错性，健壮性，低延迟，可扩展，通用性，方便查询等，Lambda就是其根据这些特性设计的一
Mysql+ETLCloud CDC+Doris实时数仓同步实战
渡江客涂鸦板
06-29 1160
通常情况下我们使用CDC实时监听表销售或订单表数据的LOG时会形成流式的数据，CDC每次传入的数据有可能是一条也可能是多条，监听到的流式数据都是订单表的单条数据，但在业务上单表的数据在业务价值上可能缺少一些关键的维度业务数据字段，例如要计算毛利合并客户及产品数据等。Flink CDC安装和使用难度比较大，没有可视化的CDC配置和监控界面对于不熟的用户安装相对比较麻烦，对于实时数据的加工和处理还需要写代码，没一点技术的用户根本搞不定，对于数据工程师来说难度太大。id=0600024。
doris用 curl将文件中的数据导入doris样例
12-13
以下是使用curl将文件中的数据导入Doris的示例： ```shell curl --location-trusted -u user:passwd -T data.file -XPUT http://fe_host:http_port/api/{db}/{table}/_stream_load ``` 其中，`user`和`passwd`是Doris的用户名和密码，`data.file`是要导入的本地文件路径，`db`和`table`是要导入的数据库和表名，`fe_host`和`http_port`是Doris前端的主机名和端口号。 该命令将会把本地文件中的数据导入到Doris中。需要注意的是，该命令只适用于导入本地文件，如果要导入数据流中的数据，需要使用其他方式。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值