生而为人

程序员的自我修养

0%

Posted on

数据处理

反压

Posted on In

怎么理解flink的有状态

Posted on

基础

初识 HBase

Hbase入门详解

一篇文章入门Hbase

原理

HBase原理（读写流程）

hbase为什么能够实现实时读写

hbase知识点及实时读写原理

Hbase原理详解

优化

hbase读写性能测试调优

优化hbase的查询提升读写速率优化案例及性能提升的几种方法

实时系统HBase读写优化–大量写入无障碍

hbase大规模数据写入的优化历程

HBase篇–HBase常用优化

hbase实时优化思路

深入学习

HBase 学习分享

面试

Hbase 基础面试题

Posted on In

[toc]

待整理

Kappa 架构是什么样的，运用在实际业务上是否合理，还有什么其他架构的选择，以及哪些公司采用了这些架构

⚙️ Kappa架构是什么样的？

Kappa架构的核心思想可以概括为一句话：一切皆为流，用一套流处理引擎处理所有数据--1。

它由Apache Kafka的创始人Jay Kreps提出，旨在解决早期Lambda架构的复杂性-1-4。

  • Lambda架构的痛点：Lambda架构为了兼顾“实时”与“准确”，维护着两套独立的处理逻辑：一套是低延迟的流处理层，产出近实时的近似结果；另一套是高准确度的批处理层，定期（如每天）重算全量数据以修正结果-10-5。这导致系统复杂、维护成本高，且实时与离线结果常对不上-10。
  • Kappa的解决思路：它砍掉了独立的批处理层，只保留一个流处理层--17。其核心是依赖一个可重放的事件日志（如Kafka）-4。所有新数据源源不断地流入这个日志，流处理引擎实时消费并计算结果。当业务逻辑变更或需要修正历史数据时，只需将日志从头开始“重放”（Replay）一遍，通过同一个流处理任务就能得到修正后的结果--1。

形象理解：Lambda像两条生产线（一条快但不精细，一条慢但精准），最后再合并产品；Kappa则是一条高度自动化的柔性生产线，需要返工时，就把原材料（日志）从头再走一遍流程-5。

🎯 运用于实际业务是否合理？

合理，但并非“银弹”。它在特定场景下优势巨大，但也有明显的局限。

✅ 优势与适用场景

Kappa架构最适合数据源是事件流（如日志、埋点、IoT数据）、对实时性要求极高，且希望简化系统的场景--17。

  • 架构极简：只需维护一套代码、一条链路，大大降低了开发和运维的复杂度和心智负担--10。
  • 逻辑一致：彻底消除了实时与离线结果对不上的“数据对账”难题-10。
  • 典型行业：
    • 金融：实时交易监控、欺诈检测--2
    • 电商/零售：实时推荐、库存管理、销售大屏--2
    • 物联网(IoT)：设备实时监控、预测性维护-2

⚠️ 挑战与局限

  • 历史数据重放成本高昂：Kafka并非无限存储-10。如需重放数月甚至一年的数据，存储成本巨大，且重放过程会大量消耗计算资源，可能导致集群不稳定-10。
  • 复杂状态计算困难：实时计算去重、多流JOIN等复杂指标时，流处理引擎需要维护庞大的状态（State）-10。这可能导致状态爆炸、内存溢出，且故障恢复极其复杂-5。
  • 对技术人员要求高：设计和实现高效的流处理逻辑，比传统的批处理SQL难度更高-2。

现实是：完全的Kappa架构在大型企业里并不常见。更普遍的做法是**“Kappa + 数据湖”的混合模式**，即用Kappa处理实时数据，同时将数据沉淀到数据湖中，用批处理引擎（如Spark）进行低成本的历史数据分析-21。

🏗️ 还有哪些其他架构选择？

除了Kappa，目前业界主流的大数据架构还有以下几种：

架构 核心思想 优点 缺点 适用场景
Lambda架构 批流协同：维护批处理和流处理两套系统，兼顾准确与实时-17。 成熟稳定，能同时保证历史数据的准确性和实时数据的低延迟--17。 架构复杂，维护两套代码，数据一致性难保证-2。 对数据准确性要求极高，且需要实时与历史分析兼顾的场景-17。
Lakehouse (湖仓一体) 统一存储：基于数据湖（如Iceberg, Hudi）构建，同时支持高效的BI分析和AI/机器学习-。 存储成本低（使用廉价存储），支持多种数据类型（结构化、非结构化），并能提供数据仓库的ACID事务能力-。 技术相对较新，数据治理和元数据管理是挑战。 希望用一个平台同时支撑BI报表、数据科学和AI分析的企业-。
Data Mesh (数据网格) 去中心化：将数据所有权和责任分散到各个业务域团队，每个团队负责输出自己的“数据产品”-。 解决了超大型组织中数据团队成为瓶颈的问题，提升了数据交付的敏捷性-。 对组织文化、数据治理和基础设施要求极高，实施难度大-。 业务线众多、组织架构复杂的大型或超大型企业-。

🏢 哪些公司采用了这些架构？

  • Kappa架构：
    • 海通证券：上线了基于Kappa架构的实时日志分析平台-。
    • 某大型零售企业：利用Kafka打通ERP、CRM、POS等系统，构建实时销售分析-。
    • 某跨境电商平台：基于Kafka+ElasticSearch搭建轻量级Kappa架构，处理日均百万级数据-。
    • 此外，不少公司将原有Lambda改造为Kappa后，实现了服务器成本降低30% 等显著收益–。
  • Lambda架构：
    • Yahoo、Netflix：是大数据领域早期Lambda架构的知名实践者-。
    • 腾讯云：在其方案中，用Lambda架构处理电商用户行为分析等场景-。
    • 注意：这里的“Lambda”指大数据处理架构，与AWS的Serverless计算服务“AWS Lambda”是不同概念-。
  • Lakehouse (湖仓一体) 架构：
    • 中国移动：在其集团大数据平台进行了湖仓一体架构的升级和落地-。
    • 京东：为解决Lambda架构痛点，在流量资产场景中引入了湖仓一体架构-。
    • 中信建投、齐鲁银行等金融机构，也纷纷建设湖仓一体数据平台-。
  • Data Mesh (数据网格) 架构：
    • 宝马集团：与AWS合作，深化其云数据中心的建设，是数据网格理念的实践者之一-。
    • 诺基亚：采用去中心化的数据网格架构，称其将机器学习运营效率提升了70%-。

字节，百度，阿里分别使用的什么架构

这三家公司的数据架构演进，清晰地勾勒出了一幅从经典的 Lambda 架构向湖仓一体架构转型的图谱。

简单来说，它们的共同趋势是：为了追求更低的数据延迟、更统一的存储和更简化的开发运维，正逐步摒弃传统的 Lambda 或 Kappa 架构，全面拥抱“湖仓一体”--20。

下面是这三家公司各自的具体实践：

🏢 字节跳动：从 Lambda 迈向自研湖仓一体

字节跳动早期为了快速支持业务，采用了经典的 Lambda 架构-。但随着业务（尤其是电商、抖音等）的精细化发展，Lambda 架构的弊端（如数据口径对齐难、维护双套代码成本高）日益凸显。

因此，字节跳动正积极向湖仓一体架构演进，其核心特点是存储层的统一：

  • 核心思路：通过引入数据湖技术（如 Apache Hudi）-，实现实时数据和离线数据的一份存储，从而解决存储翻倍和口径不一致的问题。
  • 技术方案：字节内部基于 Hudi 等开源技术，自研了高吞吐、高并发、秒级延迟可见的实时数据湖方案，并在上层构建了名为 LAS 的服务--5。
  • 应用场景：该方案已在电商流量数据-等对实时性要求极高的核心业务场景中落地。

🏢 百度：Lambda 与 Kappa 的混合实践

与字节跳动激进的转型不同，百度采用了一种更为折中的 Lambda 和 Kappa 的混合架构-。

  • 核心思路：在数据清洗和数仓构建等关键环节，百度尝试融合两种架构的优势。一方面，通过流批一体的技术方案，让实时和离线任务共用一套代码，以解决 Lambda 的双代码问题-8-9；另一方面，并未完全放弃批处理层，而是让离线链路作为数据准确性的最终保障-8。
  • 技术方案：百度在技术栈上同时兼容传统（如 Hive, Spark-8）和现代（如 Flink-8）计算框架，并积极构建自己的云原生湖仓一体架构-。
  • 应用场景：这种架构被应用于其用户产品等业务的实时数仓建设中--9。

阿里巴巴因其电商业务对实时性的极致追求，在数据架构的演进上最为激进，大力推动以 Flink + Paimon + Hologres 为核心的实时湖仓一体方案-。

  • 核心思路：阿里巴巴的目标是打造一体化实时湖仓-。其演进路径清晰展示了从 Lambda 到 Kafka 分层，再到 Hologres 统一存储的历程-16。
  • 技术方案：
    1. 湖存储层：主推自研的 Paimon 数据湖格式-20。
    2. 计算引擎层：基于 Flink 实现流批一体计算-。
    3. 服务引擎层：由 Hologres 统一提供高性能的实时查询与分析服务--16。
  • 应用场景：这套方案已在阿里妈妈等核心业务中落地，实现了流批一体的开发模式，显著节省了人力和计算存储成本-20。

📈 总结：架构演进趋势

从这三家巨头的实践中，可以总结出大数据架构演进的清晰脉络：

  • 从 Lambda 到湖仓一体：为解决 Lambda 架构的双代码、双存储和口径不一致等核心痛点-8。
  • 计算层：从“批流分离”到“流批一体”：使用 Flink 等引擎，用一套代码同时处理实时和离线任务，降低开发和维护成本-20。
  • 存储层：从“双存储”到“湖仓一体”：基于数据湖技术（如 Hudi, Paimon），实现实时和离线数据的统一存储，从根本上解决数据一致性问题。

总的来说，虽然这三家公司的技术选型和演进路径各有侧重，但最终都指向了“湖仓一体”这个共同的未来方向。

湖仓一体是什么架构 请详细描述一下，包括对哪些业务场景支持比较好，解决了哪些痛点，用到的技术都有哪些，分别使用在哪些业务场景中

这些资料提供了关于湖仓一体架构的详细信息。我需要组织一个全面的回答，涵盖定义、优势、业务场景、技术组件和实际案例。回答将采用标题和段落的形式，并引用这些来源。

湖仓一体（Lakehouse）可以理解为一种数据平台新架构，它尝试融合数据湖和数据仓库的优势，旨在提供一个更统一、高效的数据底座--5。

简单来说，它希望解决一个核心问题：企业数据越来越多，格式越来越杂，传统的单一数据湖或数据仓库架构都有些力不从心了-10。

🤔 它解决了什么核心痛点？

在湖仓一体出现之前，很多公司采用的是“数据湖+数据仓库”两套并行的架构（Lambda架构），这带来了不少麻烦。湖仓一体正是为了解决这些痛点而生：

  • 存储与计算成本高昂：Lambda架构需要维护离线和实时两条独立链路，导致计算和存储资源双倍消耗。湖仓一体通过存算分离-和统一存储，一份数据只存一次，显著降低成本-。
  • 数据口径不一致：两套链路处理逻辑不同，导致离线报表和实时看板的数据经常对不上，业务人员需要花大量时间排查。湖仓一体通过流批一体，用一套代码处理所有数据，从根源上保证了数据一致性-4。
  • 数据时效性不足：传统数仓通常是T+1的批处理，无法满足实时或近实时分析需求。湖仓一体支持分钟级甚至秒级的数据延迟-1。
  • 数据治理困难：缺乏管理的数据湖容易变成“数据沼泽”，难以被有效利用-9。湖仓一体在湖上构建了元数据管理、事务、索引等能力，让数据变得可查、可信--5。
  • 无法处理多样化数据：传统数仓难以处理日志、图片等非结构化数据-。湖仓一体原生支持结构化、半结构化和非结构化数据的存储与分析--5。

🧱 湖仓一体的核心架构与关键技术

湖仓一体并不是一个单一的产品，而是一套技术组合，其架构大致可以分为以下几个层面：

  1. 统一的存储层 (Storage Layer)：这是湖仓一体的基石，通常基于对象存储（如AWS S3、阿里云OSS）或分布式文件系统（如HDFS）构建-5。关键在于使用了开放的表格式（Open Table Formats），如 Apache Iceberg-5、Apache Hudi、Delta Lake-和 Apache Paimon-1。它们为数据湖带来了数据仓库才有的ACID事务、时间旅行（Time Travel）和高效更新删除等能力-。
  2. 强大的计算层 (Compute Layer)：在统一存储之上，湖仓一体支持多种计算引擎，让不同的工具做最擅长的事-9。
    • 批处理：如 Apache Spark，用于处理大规模历史数据的ETL-1。
    • 流处理：如 Apache Flink，用于处理实时数据，实现“流批一体”-1。
    • 交互式查询：如 StarRocks-1、Apache Doris-、Hologres-4，用于提供高性能的BI报表和Ad-hoc查询。
  3. 统一的元数据层 (Metadata Layer)：这是“一体”的关键。通过统一的数据目录（如Hive Metastore或AWS Glue），让所有计算引擎都能访问到相同的数据集，避免了数据孤岛-9。
  4. 完善的数据治理层 (Governance Layer)：提供数据血缘、数据质量、权限管理等能力，确保数据的安全与合规--5。例如，Microsoft Purview-就是这方面的工具。

💡 哪些业务场景支持比较好？

湖仓一体的架构特性使其在以下场景中表现突出：

  • 实时/准实时BI与决策：这是最典型的场景。例如京东将流量数据接入湖仓，将数据时效从T+1提升到分钟级，支撑了搜索推荐等核心业务。vivo也利用此架构将数据处理从小时级缩短到十分钟以内-1。
  • AI与机器学习：AI模型训练需要海量且多样的数据（文本、图片、日志）。湖仓一体能作为统一的“数据食堂”，高效地为模型提供特征数据，并支持特征工程的反复迭代--5。
  • 数据中台与统一数据服务：湖仓一体非常适合作为企业的数据中台底座-10。云南红塔银行-和长城人寿-等机构，都基于湖仓一体构建了新一代数据中台，以统一对外提供服务。
  • 日志与物联网（IoT）数据分析：面对IoT设备或服务器产生的海量、格式不一的日志数据，湖仓一体的存储和分析能力是天然的优势-10。
  • 金融行业实时风控与监管：金融行业对数据时效性和一致性要求极高。农业银行用其弥补了传统数仓实时处理能力的不足-，齐鲁银行则通过湖仓一体使存储成本直降50%，计算速度提升70%-，中信建投也以此为基础推动数字化转型-。

🏢 哪些公司在使用？

湖仓一体已成为各行业头部企业的共同选择：

  • 互联网巨头：字节、百度、阿里、京东、快手、vivo、淘天集团都在积极实践湖仓一体架构-。
  • 金融机构：农业银行、交通银行、中信建投、齐鲁银行、长城人寿、云南红塔银行等，都在利用湖仓一体构建新一代数据底座-。
  • 其他行业：中国电财等大型集团也在采用“流批湖仓”的融合架构-。

💎 总结

湖仓一体并非凭空创造的新概念，而是为了解决大数据领域长期存在的“数据孤岛”和“架构复杂”等问题，将数据湖的灵活性、低成本与数据仓库的性能、规范性相结合的必然产物-。它通过开放的表格式和存算分离等核心技术，为企业提供了一个能同时支撑BI、AI和实时分析等多种负载的统一数据平台-10。

当然，湖仓一体也并非“银弹”，其技术栈相对较新，对团队的技术能力要求较高，且在数据治理和元数据管理方面仍有挑战-。但不可否认的是，它代表了数据平台架构演进的一个重要方向-。

Posted on In

1. 复制表

1.1 复制表结构

1.2 复制表数据

Posted on In

[toc]

git wiki地址

编译与部署

安装与部署

软硬件需求

  • FE（前端）和BE（后端）存储数据的区别，以及所需机器配置
  • FE与BE端口、网络需求
  • ip绑定

集群部署

  • 手动部署

    • FE部署
    • BE部署
    • FS_Broker部署

扩容缩容

  • FE扩容和缩容

    • 增加FE节点
    • 删除FE节点

  • BE扩容和缩容

    • 增加BE节点
    • 删除BE节点

  • Broker扩容缩容

常见问题

开始使用

基础使用指南

1.创建用户

  • Root用户登陆与密码修改
  • 创建新用户

2.数据表的创建与数据导入

  • 创建数据库

  • 账户授权

  • 建表

    • 单分区
    • 复合分区

  • 导入数据

    • 流式导入
    • Broker导入

3.数据的查询

  • 简单查询
  • Join查询
  • 子查询

高级使用指南

1. 表结构变更

2. Rollup

3. 数据表的查询

  • 内存限制
  • 查询超时
  • Broadcast/Shuffle Join
  • 查询重试和高可用

最佳实践

1. 建表

  • 数据模型选择

    • AGGREGATE KEY
    • UNIQUE KEY
    • DUPLICATE KEY

  • 大宽表与Star Schema

  • 分区和分桶

    • Range分区(partition)
    • HASH分桶(bucket)

  • 稀疏索引和Bloom Filter

  • 物化视图(rollup)

    • Base Table中数据聚合度不高
    • Base Table中的前缀索引无法命中

2. Schema Change

  • Sorted Schema Change
  • Direct Schema Change: 无需重新排序，但需要对数据做一次转换。例如修改列的类型，在稀疏索引中加一列等
  • Linked Schema Change: 无需转换数据，直接完成。例如加列操作

数据划分

1. 基本概念

  • Row & Column
  • Tablet & Partition

2. 数据划分

  • 列定义

    • 列定义建议

  • 分区与分桶

Doris支持两层的数据划分。第一层是Partition，仅支持Range的划分方式。第二层是Bucket（Tablet），仅支持Hash的划分方式。也可以仅使用一层分区

    • Partition
    • Bucket
    • 关于Partition和Bucket的数量和数据量的建议
    • 多列分区

  • PROPERTIES

    • replication_num
    • storage_medium & storage_cooldown_time

  • ENGINE

3. 常见问题

  • 建表操作常见问题

    • 如果在较长的建表语句中出现语法错误，可能会出现语法错误提示不全的现象。这里罗列可能的语法错误供手动纠错：
    • Failed to create partition [xxx] . Timeout
    • 建表命令长时间不返回结果。

数据模型、ROLLUP及前缀索引

github wiki

1. 基本概念

  • Row

  • Column

    • Key
    • Value

2. Aggregate模型

  • 示例1: 导入数据聚合
  • 示例2: 保留明细数据
  • 示例3: 导入数据与已有数据聚合

3. Uniq模型

4. Duplicate模型(冗余模型)

5. ROLLUP

  • 基本概念

    • Aggregate和Uniq模型中的ROLLUP

      • 示例1: 获得每个用户的总消费
      • 示例2: 获得不同城市，不同年龄段用户的总消费、最长和最短页面驻留时间

    • Duplicate模型中的ROLLUP

  • 前缀索引与ROLLUP

    • 前缀索引

我们将一行数据的前 36 个字节 作为这行数据的前缀索引。当遇到 VARCHAR 类型时，前缀索引会直接截断。

    • ROLLUP调整前缀索引

  • ROLLUP的几点说明

    • 根本作用是提高某些查询的查询效率（无论是通过聚合来减少数据量，还是修改列顺序以匹配前缀索引）。因此 ROLLUP 的含义已经超出了 “上卷” 的范围。这也是为什么我们在源代码中，将其命名为 Materized Index（物化索引）的原因。
    • ROLLUP是附属于Base表的，可以看作是Base表的一种辅助数据结构。用户可以在 Base 表的基础上，创建或删除 ROLLUP，但是不能在查询中显式的指定查询某 ROLLUP。是否命中 ROLLUP 完全由 Doris 系统自动决定。
    • ROLLUP 的数据是独立物理存储的。因此，创建的 ROLLUP 越多，占用的磁盘空间也就越大。同时对导入速度也会有影响（导入的ETL阶段会自动产生所有 ROLLUP 的数据），但是不会降低查询效率（只会更好）。
    • ROLLUP 的数据更新与 Base 表示完全同步的。用户无需关心这个问题。
    • ROLLUP 中列的聚合方式，与 Base 表完全相同。在创建 ROLLUP 无需指定，也不能修改。
    • 查询能否命中 ROLLUP 的一个必要条件（非充分条件）是，查询所涉及的所有列（包括 select list 和 where 中的查询条件列等）都存在于该 ROLLUP 的列中。否则，查询只能命中 Base 表。
    • 某些类型的查询（如 count(*)）在任何条件下，都无法命中 ROLLUP。具体参见接下来的 聚合模型的局限性 一节。
    • 可以通过 EXPLAIN your_sql; 命令获得查询执行计划，在执行计划中，查看是否命中 ROLLUP。
    • 可以通过 DESC tbl_name ALL; 语句显示 Base 表和所有已创建完成的 ROLLUP。
    • 查询如何命中ROLLUP

6. 聚合模型的局限性

  • Aggregate 模型（包括 Uniq 模型）

在聚合模型中，模型对外展现的，是最终聚合后的数据。也就是说，任何还未聚合的数据（比如说两个不同导入批次的数据），必须通过某种方式，以保证对外展示的一致性。

  • Duplicate 模型

Duplicate 模型没有聚合模型的这个局限性。因为该模型不涉及聚合语意，在做 count(*) 查询时，任意选择一列查询，即可得到语意正确的结果。

7. 数据模型的选择建议

因为数据模型在建表时就已经确定，且无法修改。所以，选择一个合适的数据模型非常重要。

  1. Aggregate 模型可以通过预聚合，极大地降低聚合查询时所需扫描的数据量和查询的计算量，非常适合有固定模式的报表类查询场景。但是该模型对 count(*) 查询很不友好。同时因为固定了 Value 列上的聚合方式，在进行其他类型的聚合查询时，需要考虑语意正确性。
  2. Uniq 模型针对需要唯一主键约束的场景，可以保证主键唯一性约束。但是无法利用 ROLLUP 等预聚合带来的查询优势（因为本质是 REPLACE，没有 SUM 这种聚合方式）。
  3. Duplicate 适合任意维度的 Ad-hoc 查询。虽然同样无法利用预聚合的特性，但是不受聚合模型的约束，可以发挥列存模型的优势（只读取相关列，而不需要读取所有 Key 列）。

Rollup与查询

在 Doris 里 Rollup 作为一份聚合物化视图，其在查询中可以起到两个作用：

  • 索引
  • 聚合数据（仅用于聚合模型，即aggregate key）

但是为了命中 Rollup 需要满足一定的条件，并且可以通过执行计划中 ScanNdoe 节点的 PreAggregation 的值来判断是否可以命中 Rollup，以及 Rollup 字段来判断命中的是哪一张 Rollup 表。

1. 名词解释

  • Base： 基表
  • Rollup： 一般指基于 Base 表创建的 Rollup 表，但在一些场景包括 Base 以及 Rollup 表。

2. 索引

3. 聚合数据

操作手册

数据导入

1. 导入总览

1.1 基本概念

  1. Frontend（FE）：Doris 系统的元数据和调度节点。在导入流程中主要负责导入规划生成和导入任务的调度工作。
  2. Backend（BE）：Doris 系统的计算和存储节点。在导入流程中主要负责数据的 ETL 和存储。
  3. Broker：Broker 为一个独立的无状态进程。封装了文件系统接口，提供 Doris 读取远端存储系统中文件的能力。
  4. 导入作业（Load job）：导入作业读取用户提交的源数据，转换或清洗后，将数据导入到 Doris 系统中。导入完成后，数据即可被用户查询到。
  5. Label：所有导入作业都有一个 Label。Label 在一个数据库内唯一，可由用户指定或系统自动生成，用于标识一个导入作业。相同的 Label 仅可用于一个成功的导入作业。
  6. MySQL 协议/HTTP 协议：Doris 提供两种访问协议接口。 MySQL 协议和 HTTP 协议。部分导入方式使用 MySQL 协议接口提交作业，部分导入方式使用 HTTP 协议接口提交作业。

1.2 导入方式

  1. Broker load
  2. Stream load
  3. Insert
  4. Multi load
  5. Routine load

1.3 基本原理

1.3.1 导入执行流程
  1. PENDING（非必须）
  2. ETL（非必须）
  3. LOADING
  4. FINISHED
  5. CANCELLED
1.3.2 Label和原子性

1.4 同步和异步

1.4.1 同步
1.4.2 异步
1.4.3 注意事项

1.5 内存限制

1.6 最佳实践

1.7 通用系统配置

1.7.1 FE配置
1.7.2 BE配置
1.7.3 列映射

2.Broker Load

一种异步导入方式

2.1 适用场景

2.2 名词解释

2.3 基本原理

2.4 基本操作

2.4.1 创建导入
2.4.2 查看导入
2.4.3 取消导入

2.5 相关系统配置

2.5.1 FE 配置

2.6 最佳实践

2.6.1 应用场景

使用 Broker load 最适合的场景就是原始数据在文件系统（HDFS，BOS，AFS）中的场景。其次，由于 Broker load 是单次导入中唯一的一种异步导入的方式，所以如果用户在导入大文件中，需要使用异步接入，也可以考虑使用 Broker load。

2.6.2 数据量

这里仅讨论单个 BE 的情况，如果用户集群有多个 BE 则下面标题中的数据量应该乘以 BE 个数来计算。比如：如果用户有3个 BE，则 3G 以下（包含）则应该乘以 3，也就是 9G 以下（包含）。

2.6.3 性能分析
2.6.4 完整例子

2.7 常见问题

3. Stream load

Stream load 是一个同步的导入方式，用户通过发送 HTTP 协议发送请求将本地文件或数据流导入到 Doris 中。Stream load 同步执行导入并返回导入结果。用户可直接通过请求的返回体判断本次导入是否成功。

Stream load 主要适用于导入本地文件，或通过程序导入数据流中的数据。

3.1 基本原理

3.2 基本操作

3.3 相关系统配置

3.4 最佳实践

3.4.1 应用场景

使用 Stream load 的最合适场景就是原始文件在内存中，或者在磁盘中。其次，由于 Stream load 是一种同步的导入方式，所以用户如果希望用同步方式获取导入结果，也可以使用这种导入。

3.4.2 数据量
3.4.3 完整例子

3.5 常见问题

4. Routine Load

例行导入（Routine Load）功能为用户提供了一种自动从指定数据源进行数据导入的功能。

本文档主要介绍该功能的实现原理、使用方式以及最佳实践。

5. insert into

Insert Into 语句的使用方式和 MySQL 等数据库中 Insert Into 语句的使用方式类似。但在 Doris 中，所有的数据写入都是一个独立的导入作业。所以这里将 Insert Into 也作为一种导入方式介绍。

主要的 Insert Into 命令包含以下两种；

  • INSERT INTO tbl SELECT …
  • INSERT INTO tbl (col1, col2, …) VALUES (1, 2, …), (1,3, …);

其中第二种命令仅用于 Demo，不要使用在测试或生产环境中。

6. spark Load

Spark load 通过外部的 Spark 资源实现对导入数据的预处理，提高 Doris 大数据量的导入性能并且节省 Doris 集群的计算资源。主要用于初次迁移，大数据量导入 Doris 的场景。

Spark load 是一种异步导入方式，用户需要通过 MySQL 协议创建 Spark 类型导入任务，并通过 SHOW LOAD 查看导入结果。

6.1 适用场景

  • 源数据在 Spark 可以访问的存储系统中，如 HDFS。
  • 数据量在 几十 GB 到 TB 级别。

7. delete

Delete不同于其他导入方式，它是一个同步过程。和Insert into相似，所有的Delete操作在Doris中是一个独立的导入作业，一般Delete语句需要指定表和分区以及删除的条件来筛选要删除的数据，并将会同时删除base表和rollup表的数据。

表结构变更

常用参考

数据模型、ROLLUP 及前缀索引

ALTER TABLE

Posted on

id:{} truncate partitions fail!

alter table topic_flow_user_group_detail add partition IF NOT EXISTS p29 values [(“29”), (“30”));
SQL 错误 [1064] [42000]: errCode = 2, detailMessage = Failed to create partition[p29]. Timeout. Unfinished mark: 73448=53902647, 73448=53902643, 73448=53902655

不知道是不是因为数据在写入导致的

doris： tablet 99392436 has few replicas

Posted on In

doris的分区规则

为什么表结构的分区与分区字段里去重值数量不一样？

Posted on In

1.1 Can not alter table when there are temp partitions in table

原因是之前进行过改表操作，还没有完成

可以通过SHOW ALTER TABLE COLUMN; 查看改表的进度

1.2 timeout

1
set query_timeout=60;

1.3 Memory exceed limit. Hash join doris

1
SET exec_mem_limit = 8589934592;

1.4 Unexpected exception: No value present

1.5 there is no scanNode Backend doris

1.6 bitmap_union_int cause ‘be’ node hang

1.7 Failed to get scan range, no queryable replica found in tablet

2.1 分区报错

注意：

  1. 已经划分好的区间分区，不能在被切分，即分区（1，3），不能被拆分为(1,2)和(2,3)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
alter table topic_smart_user_group_detail_2 add partition IF NOT EXISTS p2 values less than (3);
insert into topic_smart_user_group_detail_2 VALUES (2, 1, '1004230612'),(2, 1, '1047296444'),(2, 1, '1053250666');

org.jkiss.dbeaver.model.sql.DBSQLException: SQL 错误 [1064] [42000]: errCode = 2, detailMessage = Syntax error in line 1:
...ISTS p2 values less than (3)
                             ^
Encountered: INTEGER LITERAL
Expected: COMMA

less than () 括号中必须是字符串

alter table topic_smart_user_group_detail_2 add partition IF NOT EXISTS p2 values less than ("3");
insert into topic_smart_user_group_detail_2 VALUES (5, 1, '1004230612'),(5, 1, '1047296444'),(5, 1, '1053250666');

all partitions have no load data
表示没有创建需要的分区

参考资料

  1. Doris建表 FAQ
  2. Hive To Doris 数据同步事故
  3. Doris使用FAQ(持续更新中)