DorisDB在某二梯队互联网公司的实践_数据

DorisDB在某二梯队互联网公司的实践_kafka_02

PART1.

实时数据分析场景



为了解决实时数据分析问题，我们先后调研了TiDB、ClickHouse 和 DorisDB，总结如下：

1.1 TiDB

TiDB是一款同时支持OLTP与OLAP的融合型分布式数据库产品，具备水平扩缩容、云原生的分布式数据库、兼容 MySQL 5.7 协议和 MySQL 生态等重要特性。

1.1.1 TiDB的优点

同时支持OLTP和OLAP，支持更新和删除操作，支持Flink端到端的ExactlyOnce语义和幂等操作。

1.1.2TiDB的缺点

OLAP性能相对ClickHouse和DorisDB较弱，没有预聚合功能和预计算功能，不支持向量化执行。

1.2 ClickHouse

ClickHouse是由俄罗斯Yandex公司研发的，全称是Click Stream，Data Warehouse，简称ClickHouse，是基于页面的点击事件流，面向数据仓库进行OLAP分析的数据库。

1.2.1 ClickHouse的优点

  • 能做到毫秒级查询，高效使用CPU，同时支持按照向量进行处理数据，属于完全的列式存储系统。
  • 写入数据非常快，非常适合大批量数据更新的操作（150MB/S）。
  • 不依赖Hadoop底层复杂的生态系统，独立部署。

1.2.1ClickHouse的缺点

  • 不支持事务操作，不支持真正的数据更新/删除操作。
  • 不支持标准的SQL语言，SQL写法很个性。
  • 几乎不支持SQL的Join操作，在做OLAP分析时，只能借助宽表。
  • 难以实现高并发查询，不能通过扩容来提高并发能力。
  • 不擅长（但是能做到）按照主键粒度进行行级数据查询。

1.3 DorisDB

DorisDB是鼎石科技打造的新一代企业级MPP数据库。继承了Apache Doris项目十多年研发成果。DorisDB重新定义了MPP分布式架构，集群可扩展至数百节点，支持PB级数据规模。DorisDB还打造了全新的向量化执行引擎，单节点每秒可处理多达100亿行数据，查询速度比其他产品快10—100倍！

1.3.1 DorisDB的优点

  • DorisDB多表关联查询性能比较好，支持各种Join操作，不仅支持大宽表查询，还支持星型和雪花型数据查询。
  • 数据按列式存储，在做数据查询时，只访问查询涉及到的列，降低I/O消耗。
  • 支持标准的SQL语言，可以直接对接主流的BI系统。
  • 支持事务，可以很容易地实现数据的不丢不重。
  • 支持常用的可视化管理工具：可以使用 Prometheus、Grafana 将监控项指标列出。
  • 内部支持订阅 Kafka 数据流，实现直接对接 Kafka（可自动感知 Kafka 中 partition 变化，合理调度并发导入），支持对 Kafka 原始数据做二次处理（如转换，过滤等）。

1.3.2 DorisDB的缺点

  • DorisDB主要是用来解决PB级数据查询，如果在10PB以上建议使用Hive/Spark等工具。
  • 不支持insert overwrite操作，可以使用truncate + insert into代替。
  • 不适合做大规模的批处理，目前都是基于内存进行计算，负责的批处理计算会造成OOM。


PART2.

选择DorisDB建立实时分析系统



基于上面的调研考察，决定使用DorisDB建立一个实时分析系统。仅需亚秒级响应时间即可获得查询结果，有效地支持实时数据分析。Apache Doris的分布式架构非常简洁，易于运维，并且可以支持10PB以上的超大数据集。

Apache Doris可以满足多种数据分析需求，例如固定历史报表，实时数据分析，交互式数据分析和探索式数据分析等。令您的数据分析工作更加简单高效！

DorisDB在某二梯队互联网公司的实践_sql_03

2.1 MySQL数据同步

DorisDB在某二梯队互联网公司的实践_sql_04

可以使用Canal+Kafka的方式实时将MySQL数据同步到DorisDB。Canal是阿里开源的一款MySQL binlog同步工具，通过Canal将MySQL的数据同步到Kafka，然后通过DorisDB的Routine Load方式消费Kafka数据到DorisDB。

2.2 实时数据仓库的总体架构

DorisDB在某二梯队互联网公司的实践_kafka_05

基于DorisDB的实时数据仓库总体架构如下，主要分成3个部分：

2.2.1 数据源

业务DB数据（主要是MySQL，可以使用Canal+Kafka的方式将MySQL数据实时同步到DorisDB）、日志数据（APP、Web和H5小程序等埋点数据，通过Flume写入到Kafka）

2.2.2 数据计算层

  1. 采用DorisDB的Routine Load直接消费Kafka中的binlog数据。
  2. 通过Flink等流式处理工具，将日志数据写入DorisDB。
  3. 在DorisDB中按照下面的方式创建数据仓库表。

2.2.3 数据应用层

  • DorisDB完全兼容MySQL协议，BI或者业务系统可以直接使用MySQL Connector直接连接DorisDB进行使用。
  • 使用DorisDB的Export将DorisDB中的数据导出到HDFS中。

2.3 实时数据仓库建设流程

DorisDB在某二梯队互联网公司的实践_sql_06


  • DWD明细层：明细事实表、维度表和明显宽表
  • DWS汇总层：公共汇总、通用视图、聚合宽表
  • ADS应用层：业务指标、汇总结果、物化视图
  • BI层：通过自研的一个指标定义工具，分析人员可以快速的基于DWS构建报表，也可以衍生出一些复合指标进行二次加工。分析师也可以将取数口径中的SQL做临时修改，生成一个复杂跨主题查询SQL，来应对一些Adhoc需求场景。


PART3.

数据链路监控



我们目前使用Prometheus+Grafana框架来监控 DorisDB 实时数据仓库。其中 Node Exporter 负责采集机器层面的指标，DorisDB 也会自动以 Prometheus格式吐出 FE、BE 的服务层面的指标。另外，部署了OLAP Exporter 服务用于采集 Routine Load 相关的指标，旨在第一时间发现实时数据流导入的情况，确保实时数据的时效性。

DorisDB在某二梯队互联网公司的实践_数据_07

实时生产数据预警

为了监控DorisDB的实时数据产出情况，我们设置了三种预警：

  • 检查DorisDB 消费Kafka 的任务，是否挂掉了，如果停掉自动重启，重启3次依然失败，再发通知，人为干预。
  • 检查常规任务的执行，如果执行报错，就发通知。
  • 检查数据源与DorisDB实时数仓ods层表，schema的对比，如果出现schema变更，就发通知人为干预。这样我们就能在白天实时了解schema的变更情况，不必要等到调度报错才发现，而且不影响线上数据产出。


PART4.

总结和展望



在业务使用中也遇到了例如任务调度相关的、导入任务配置相关的和查询相关等问题，这也在推动我们的OLAP团队更深入的了解DorisDB。我们机会在以下方面做优化处理：

  • 推广使用物化视图来进一步提升查询的效率；
  • 使用bitmap来支持UV等指标的精确去重操作；
  • 使用审计日志，更方便的统计大查询、慢查询，便于驱动OLAP用户修改不合理的逻辑写法；
  • 我们会加速更多业务向OLAP平台靠拢，以提升应用的影响力。


PART5.

DorisDB介绍



5.1 DorisDB的架构

5.1.1 FE

FE主要负责元数据的管理、存储，以及查询解析等。

  • 管理元数据：执行SQL DDL命令，用Catalog记录库，表，分区，tablet副本等信息。
  • FE高可用部署：使用复制协议选主和主从同步元数据，所有的元数据修改操作，由FE leader节点完成，FE follower节点可执行读操作。元数据的读写满足顺序一致性。FE的节点数目采用2n+1，可容忍n个节点故障。当FE leader故障时，从现有的follower节点重新选主，完成故障切换。
  • FE的SQL layer对用户提交的SQL进行解析, 分析, 改写, 语义分析和关系代数优化, 生产逻辑执行计划。
  • FE的Planner负责把逻辑计划转化为可分布式执行的物理计划, 分发给一组BE。
  • FE监督BE, 管理BE的上下线, 根据BE的存活和健康状态, 维持tablet副本的数量。
  • FE协调数据导入, 保证数据导入的一致性。

5.1.2 BE

  • BE管理tablet副本, tablet是table经过分区分桶形成的子表, 采用列式存储。
  • BE受FE指导, 创建或删除子表。
  • BE接收FE分发的物理执行计划并指定BE coordinator节点, 在BE coordinator的调度下, 与其他BE worker共同协作完成执行。
  • BE读本地的列存储引擎获取数据,并通过索引和谓词下沉快速过滤数据。
  • BE后台执行compact任务, 减少查询时的读放大。
  • 数据导入时, 由FE指定BE coordinator, 将数据以fanout的形式写入到tablet多副本所在的BE上。

DorisDB在某二梯队互联网公司的实践_sql_08

5.2 智能CBO查询优化器

在执行 SQL 查询时，需要依次经过查询解析器、分析器、优化器、查询执行层和存储层。查询优化器的输入是逻辑的抽象语法树，输出是“最优的” 物理执行计划。查询越复杂，数据量越大，物理执行计划的好坏对查询性能影响越大，所以成熟的商业数据库都需要一个强大的、成熟的查询优化器。

CBO 优化器完整地支持了 TPC-DS 99条SQL，支持了更复杂的相关子查询；在性能上，CBO 优化器支持了更多的启发式优化规则，可以基于统计信息进行 Cost 估算，可以更准确地进行 Join 左右表调整、Join 多表 Reorder、Join 分布式方式选择，TPC-H 执行总时间是旧优化器的1/3，部分 TPC-DS 复杂查询有30到50倍的提升。

这部分说明来源于官网。

5.3 DorisDB的分区分桶机制

DorisDB支持两级分区和动态分区。首先，第一级分区对数据做Range划分，用户可以把分区作为管理目标，动态增删分区。其次，为了解决分区内的数据倾斜问题，对分区做第二级分桶，对分区内的数据做Hash划分。这种分区分桶的设计方法，可以灵活管理用户数据，比如可以设置分区的存储介质，副本数，分区的生存周期和分桶数量等等。用户可以利用分区分桶的机制实现冷热数据分离等功能。

PART6.

总结




DorisDB在某二梯队互联网公司的实践_数据_09



DorisDB在某二梯队互联网公司的实践_数据_10

你好，我是梦想家，一名不甘平庸，心怀梦想的 21 世纪后浪，在上海搬砖，希望通过自己的努力，在30岁前实现时间+财富自由。

我喜欢参加各种线下技术峰会，同时也在用心打造一个真正的技术社群「大数据梦想家」，群里都是一群正能量，热情的小伙伴，如果你也希望能够加入我们，记得在公众号后台回复 “进群” 通过我们的审核之后即可加入学习。

同时，我也是个社交达人，喜欢结交各个领域优秀的朋友，人脉资源广泛，如果你也喜欢阅读，烘焙，喜欢美食，喜欢户外运动，欢迎来撩~