查看“Doris概述”的源代码

Doris介绍

Doris 是一个基于 MPP 架构的高性能、实时的分析型数据库，亚秒级响应时间，支持高并发的点查询场景，也能支持高吞吐的复杂分析场景。满足报表分析、即席查询、统一数仓构建、数据湖联邦查询加速等使用场景，用户可以在此之上构建用户行为分析、AB 实验平台、日志检索分析、用户画像分析、订单分析等应用。
* 实时数仓 Doris
* 离线湖仓（Hive, Iceberg, Hudi）
　　Doris 高度兼容 MySQL 语法，支持标准 SQL，使用任意 MySQL 的 ODBC/JDBC 以及 MySQL 的客户端，都可以直接访问 Doris。

=== 使用场景 ===
==== 报表分析 ====
* 实时看板 （Dashboards）
* 面向企业内部分析师和管理者的报表
* 面向用户或者客户的高并发报表分析（Customer Facing Analytics）。比如面向网站主的站点分析、面向广告主的广告报表，并发通常要求成千上万的 QPS ，查询延时要求毫秒级响应。京东在广告报表中使用 Apache Doris，每天写入 100 亿行数据，查询并发 QPS 上万，99% 的查询在 150ms 内。

==== 即席查询（Ad-hoc Query） ====
　　面向分析师的自助分析，查询模式不固定，要求较高的吞吐。小米公司基于 Doris 构建了增长分析平台（Growing Analytics，GA），利用用户行为数据对业务进行增长分析，平均查询延时 10s，95% 的查询延时 30s 以内，每天的 SQL 查询量为数万条。

==== 统一数仓构建 ====
　　一个平台满足统一的数据仓库建设需求，简化繁琐的大数据软件栈。海底捞基于 Doris 构建的统一数仓，替换了原来由 Spark、Hive、Kudu、Hbase、Phoenix 组成的旧架构，架构大大简化。

==== 数据湖联邦查询 ====
　　通过外表的方式联邦分析位于 Hive、Iceberg、Hudi 中的数据，在避免数据拷贝的前提下，查询性能大幅提升。

=== 技术概述 ===
　　Doris 架构非常简单，只有两类进程：
* Frontend（FE），主要负责用户请求的接入、查询解析规划、元数据的管理、节点管理相关工作。
* Backend（BE），主要负责数据存储、查询计划的执行。
　　这两类进程都是可以横向扩展的，单集群可以支持到数百台机器，数十 PB 的存储容量。并且这两类进程通过一致性协议来保证服务的高可用和数据的高可靠。这种高度集成的架构设计极大的降低了一款分布式系统的运维成本。

==== 接口 ====
　　Doris 采用 MySQL 协议，高度兼容 MySQL 语法，支持标准 SQL，用户可以通过各类客户端工具来访问 Doris，并支持与 BI 工具的无缝对接。

==== 存储引擎 ====
　　Doris 采用列式存储，按列进行数据的编码压缩和读取，能够实现极高的压缩比，同时减少大量非相关数据的扫描，从而更加有效利用 IO 和 CPU 资源。

==== 索引结构 ====
* Sorted Compound Key Index，可以最多指定三个列组成复合排序键，通过该索引，能够有效进行数据裁剪，从而能够更好支持高并发的报表场景
* Z-order Index ：使用 Z-order 索引，可以高效对数据模型中的任意字段组合进行范围查询
* Min/Max ：有效过滤数值类型的等值和范围查询
* Bloom Filter ：对高基数列的等值过滤裁剪非常有效
* Invert Index ：能够对任意字段实现快速检索

==== 存储模型 ====
　　Doris 支持多种存储模型，针对不同的场景做了针对性的优化：
* Aggregate Key 模型：相同 Key 的 Value 列合并，通过提前聚合大幅提升性能
* Unique Key 模型：Key 唯一，相同 Key 的数据覆盖，实现行级别数据更新
* Duplicate Key 模型：明细数据模型，满足事实表的明细存储
* Doris 也支持强一致的物化视图，物化视图的更新和选择都在系统内自动进行，不需要用户手动选择，从而大幅减少了物化视图维护的代价。

==== 查询引擎 ====
　　Doris 采用 MPP 的模型，节点间和节点内都并行执行，也支持多个大表的分布式 Shuffle Join，从而能够更好应对复杂查询。
* Doris 查询引擎是向量化的查询引擎，所有的内存结构能够按照列式布局，能够达到大幅减少虚函数调用、提升 Cache 命中率，高效利用 SIMD 指令的效果。在宽表聚合场景下性能是非向量化引擎的 5-10 倍。
* Doris 采用了 Adaptive Query Execution 技术， 可以根据 Runtime Statistics 来动态调整执行计划，比如通过 Runtime Filter 技术能够在运行时生成生成 Filter 推到 Probe 侧，并且能够将 Filter 自动穿透到 Probe 侧最底层的 Scan 节点，从而大幅减少 Probe 的数据量，加速 Join 性能。Doris 的 Runtime Filter 支持 In/Min/Max/Bloom Filter。
* 在优化器方面 Doris 使用 CBO 和 RBO 结合的优化策略，RBO 支持常量折叠、子查询改写、谓词下推等，CBO 支持 Join Reorder。目前 CBO 还在持续优化中，主要集中在更加精准的统计信息收集和推导，更加精准的代价模型预估等方面。

=== 部署 ===

==== 存储 ====
* FE(FrontEnd) 的磁盘空间主要用于存储元数据，包括日志和 image。通常从几百 MB 到几个 GB 不等
* BE(BackEnd) 的磁盘空间主要用于存放用户数据，总磁盘空间按用户总数据量* 3（3副本）计算，然后再预留额外 40% 的空间用作后台 compaction 以及一些中间数据的存放
* Broker 部署是用于访问外部数据源（如 hdfs）的进程。通常，在每台 FE 机器上部署一个 broker 实例即可

==== 节点 ====
* 一台机器上可以部署多个 BE 实例，但是只能部署一个 FE
* 如果需要 3 副本数据，那么至少需要 3 台机器各部署一个 BE 实例（而不是1台机器部署3个BE实例）
* 占用端口在 8000 ~ 8100，9000 ~ 9100
* 推荐使用 priority_networks 绑定IP

==== 节点的数量 ====
* FE 角色分为 Follower 和 Observer，（Leader 为 Follower 组中选举出来的一种角色，以下统称 Follower），Observer 不会参与选举。
* FE 节点数据至少为1（1 个 Follower）。当部署 1 个 Follower 和 1 个 Observer 时，可以实现读高可用。当部署 3 个 Follower 时，可以实现读写高可用（HA）。
* 一条元数据日志需要在多数 Follower 节点写入成功。比如 3 个 FE，需要至少2 个写入成功，Follower 的数量必须为奇数，且多个 FE 实例的 http_port 相同（默认8030）。Observer 数量随意，作为观察者来同步已经成功写入的元数据日志，并且提供元数据读服务。
* 根据以往经验，当集群可用性要求很高时（比如提供在线业务），可以部署 3 个 Follower 和 1-3 个 Observer。如果是离线业务，建议部署 1 个 Follower 和 1-3 个 Observer
* 通常我们建议 10 ~ 100 台左右的机器，来充分发挥 Doris 的性能（其中 3 台部署 FE（HA），剩余的部署 BE）
* 当然，Doris的性能与节点数量及配置正相关。在最少4台机器（一台 FE，三台 BE，其中一台 BE 混部一个 Observer FE 提供元数据备份），以及较低配置的情况下，依然可以平稳的运行 Doris
[[分类:Develop]]
[[分类:DB]]