关键词：
更多技术交流、求职机会，欢迎关注字节跳动数据平台微信公众号，回复【1】进入官方交流群
Doris简介
Doris是一种MPP架构的分析型数据库，主要面向多维分析，数据报表，用户画像分析等场景。自带分析引擎和存储引擎，支持向量化执行引擎，不依赖其他组件，兼容MySQL协议。
Apache Doris具备以下几个特点：
- 良好的架构设计，支持高并发低延时的查询服务，支持高吞吐量的交互式分析。多FE均可对外提供服务，并发增加时，线性扩充FE和BE即可支持高并发的查询请求。
- 支持批量数据load和流式数据load，支持数据更新。支持Update/Delete语法，unique/aggregate数据模型，支持动态更新数据，实时更新聚合指标。
- 提供了高可用，容错处理，高扩展的企业级特性。FE Leader错误异常，FE Follower秒级切换为新Leader继续对外提供服务。
- 支持聚合表和物化视图。多种数据模型，支持aggregate，replace等多种数据模型，支持创建rollup表，支持创建物化视图。rollup表和物化视图支持动态更新，无需用户手动处理。
- MySQL协议兼容，支持直接使用MySQL客户端连接，非常易用的数据应用对接。
Doris由Frontend（以下简称FE）和Backend（以下简称BE）组成，其中FE负责接受用户请求，编译，优化，分发执行计划，元数据管理，BE节点的管理等功能，BE负责执行由FE下发的执行计划，存储和管理用户数据。
数据湖格式Hudi简介
Hudi是下一代流式数据湖平台，为数据湖提供了表格式管理的能力，提供事务，ACID，MVCC，数据更新删除，增量数据读取等功能。支持Spark，Flink，Presto，Trino等多种计算引擎。
Hudi根据数据更新时行为不同分为两种表类型：
针对Hudi的两种表格式，存在3种不同的查询类型：
Doris分析Hudi数据的技术背景
在数仓业务中，随着业务对数据实时性的要求越来越高，T+1数仓业务逐渐往小时级，分钟级，甚至秒级演进。实时数仓的应用也越来越广，也经历了多个发展阶段。目前存在着多种解决方案。
Lambda架构
Lambda将数据处理流分为在线分析和离线分析分为两条不同的处理路径，两条路径互相独立，互不影响。
离线分析处理T+1数据，使用Hive/Spark处理大数据量，不可变数据，数据一般存储在HDFS等系统上。如果遇到数据更新，需要overwrite整张表或整个分区，成本比较高。
在线分析处理实时数据，使用Flink/Spark Streaming处理流式数据，分析处理秒级或分钟级流式数据，数据保存在Kafka或定期（分钟级）保存到HDFS中。
该套方案存在以下缺点：
- 同一套指标可能需要开发两份代码来进行在线分析和离线分析，维护复杂
- 数据应用查询指标时可能需要同时查询离线数据和在线数据，开发复杂
- 同时部署批处理和流式计算两套引擎，运维复杂
- 数据更新需要overwrite整张表或分区，成本高
Kappa架构
随着在线分析业务越来越多，Lambda架构的弊端就越来越明显，增加一个指标需要在线离线分别开发，维护困难，离线指标可能和在线指标对不齐，部署复杂，组件繁多。于是Kappa架构应运而生。
Kappa架构使用一套架构处理在线数据和离线数据，使用同一套引擎同时处理在线和离线数据，数据存储在消息队列上。
Kappa架构也有一定的局限：
- 流式计算引擎批处理能力较弱，处理大数据量性能较弱
- 数据存储使用消息队列，消息队列对数据存储有有效性限制，历史数据无法回溯
- 数据时序可能乱序，可能对部分对时序要求比较严格的应用造成数据错误
- 数据应用需要从消息队列中取数，需要开发适配接口，开发复杂
基于数据湖的实时数仓
针对Lambda架构和Kappa架构的缺陷，业界基于数据湖开发了Iceberg, Hudi, DeltaLake这些数据湖技术，使得数仓支持ACID, Update/Delete, 数据Time Travel, Schema Evolution等特性，使得数仓的时效性从小时级提升到分钟级，数据更新也支持部分更新，大大提高了数据更新的性能。兼具流式计算的实时性和批计算的吞吐量，支持的是近实时的场景。
以上方案中其中基于数据湖的应用最广，但数据湖模式无法支撑更高的秒级实时性，也无法直接对外提供数据服务，需要搭建其他的数据服务组件，系统较为复杂。基于此背景下，部分业务开始使用Doris来服务，业务数据分析师需要对Doris与Hudi中的数据进行联邦分析，此外在Doris对外提供数据服务时既要能查询Doris中数据，也要能加速查询离线业务中的数据湖数据，因此我们开发了Doris访问数据湖Hudi中数据的特性。
Doris分析Hudi数据的设计原理
基于以上背景，我们设计了Apache Doris中查询数据湖格式Hudi数据，因Hudi生态为java语言，而Apache Doris的执行节点BE为C++环境，而C++ 无法直接调用Hudi java SDK，针对这一点，我们有四种解决方案：
- 实现Hudi C++ client，在BE中直接调用Hudi C++ client去读写Hudi表。
该方案需要完整实现一套Hudi C++ client，开发周期较长，后期Hudi行为变更需要同步修改Hudi C++ client，维护较为困难。
- BE通过thrift协议发送读写请求至Broker，由Broker调用Hudi java client读取Hudi表。
该方案需要在Broker中增加读写Hudi数据的功能，目前Broker定位仅为fs的操作接口，引入Hudi打破了Broker的定位。第二，数据需要在BE和Broker之间传输，性能较低。
- 在BE中使用JNI创建JVM，加载Hudi java client去读写Hudi表。
该方案需要在BE进程中维护JVM，有JVM调用Hudi java client对Hudi进行读写。读写逻辑使用Hudi社区java实现，可以维护与社区同步；同时数据在同一个进程中进行处理，性能较高。但需要在BE维护一个JVM，管理较为复杂。
- 使用BE arrow parquet c++ api读取hudi parquet base file，hudi表中的delta file暂不处理。
该方案可以由BE直接读取hudi表的parquet文件，性能最高。但当前不支持base file和delta file的合并读取，因此仅支持COW表Snapshot Queries和MOR表的Read Optimized Queries，不支持Incremental Queries。
综上，我们选择方案四，第一期实现了COW表Snapshot Queries和MOR表的Read Optimized Queries，后面联合Hudi社区开发base file和delta file合并读取的C++接口。
Doris分析Hudi数据的技术实现
Doris中查询分析Hudi外表使用步骤非常简单。
创建Hudi外表
建表时指定engine为Hudi，同时指定Hudi外表的相关信息，如hive metastore uri，在hive metastore中的database和table名字等。
建表仅仅在Doris的元数据中增加一张表，无任何数据移动。
建表时支持指定全部或部分hudi schema，也支持不指定schema创建hudi外表。指定schema时必须与hiveMetaStore中hudi表的列名，类型一致。
Example：
CREATE TABLE example_db.t_hudi
ENGINE=HUDI
PROPERTIES (
"hudi.database" = "hudi_db",
"hudi.table" = "hudi_table",
"hudi.hive.metastore.uris" = "thrift://127.0.0.1:9083"
);
CREATE TABLE example_db.t_hudi (
column1 int,
column2 string)
ENGINE=HUDI
PROPERTIES (
"hudi.database" = "hudi_db",
"hudi.table" = "hudi_table",
"hudi.hive.metastore.uris" = "thrift://127.0.0.1:9083"
);
查询Hudi外表
- 查询Hudi数据表时，FE在analazy阶段会查询元数据获取到Hudi外表的的hive metastore地址，从Hive metastore中获取hudi表的schema信息与文件路径。
- 获取hudi表的数据地址
- FE规划fragment增加HudiScanNode。HudiScanNode中获取Hudi table对应的data file文件列表。
- 根据Hudi table获取的data file列表生成scanRange
- 下发HudiScan 任务至BE节点
- BE节点根据HudiScanNode指定的Hudi外表文件路径调用native parquet reader进行数据读取。
后期规划
目前Apche Doris查询Hudi表已合入社区，当前已支持COW表的Snapshot Query，支持MOR表的Read Optimized Query。对MOR表的Snapshot Query暂时还未支持，流式场景中的Incremental Query也没有支持。
后续还有几项工作需要处理，我们和社区也在积极合作进行中：
- MOR表的Snapshot Query。MOR表实时读需要合并读取Data file与对应的Delta file，BE需要支持Delta file AVRO格式的读取，需要增加avro的native读取方式。
- COW/MOR表的Incremental Query。支持实时业务中的增量读取。
- BE读取Hudi base file和delta file的native接口。目前BE读取Hudi数据时，仅能读取data file，使用的是parquet的C++ SDK。后期我们和联合Hudi社区提供Huid base file和delta file的C++/Rust等语言的读取接口，在Doris BE中直接使用native接口来查询Hudi数据。
本文为字节跳动数据平台研发工程师在DataFunSummit大会演讲实录，关注字节跳动数据平台微信公众号，回复【0929】，领取本次分享PPT。
立即跳转火山引擎E-MapReduce官网了解更多信息
汽车之家基于flink+iceberg的湖仓一体架构实践
...计算平台负责人邸星星在4月17日上海站Meetup分享的，基于Flink+Iceberg的湖仓一体架构实践，内容包括：数据仓库架构升级的背景基于Iceberg的湖仓一体架构实践总结与收益后续规划Tips：点击文末「阅读原文」即可... 查看详情
基于iceberg的湖仓一体架构在b站的实践
背景在B站，每天都有PB级的数据注入到大数据平台，经过离线或实时的ETL建模后，提供给下游的分析、推荐及预测等场景使用。面对如此大规模的数据，如何高效低成本地满足下游数据的分析需求，一直是我... 查看详情
基于iceberg的湖仓一体架构在b站的实践
背景在B站，每天都有PB级的数据注入到大数据平台，经过离线或实时的ETL建模后，提供给下游的分析、推荐及预测等场景使用。面对如此大规模的数据，如何高效低成本地满足下游数据的分析需求，一直是我... 查看详情
基于deltalakehudi格式的湖仓一体方案
...播视频请点击直播观看一、最佳实践背景整个最佳实践是基于MaxCompute的湖仓一体架构，模拟公司使用场景。比如公司A使用云上关系型数据库RDS作为自己的业务库，同时使用阿里云EMR系统做日志数据采集。将数据汇集到云... 查看详情
基于deltalakehudi格式的湖仓一体方案
...播视频请点击直播观看一、最佳实践背景整个最佳实践是基于MaxCompute的湖仓一体架构，模拟公司使用场景。比如公司A使用云上关系型数据库RDS作为自己的业务库，同时使用阿里云EMR系统做日志数据采集。将数据汇集到云... 查看详情
37手游基于flinkcdc+hudi湖仓一体方案实践(代码片段)
...f1a; 介绍了37手游为何选择Flink作为计算引擎，并如何基于FlinkCDC+Hudi构建新的湖仓一体方案。本文作者是37手游大数据开发徐润柏，介绍了37手游为何选择Flink作为计算引擎，并如何基于FlinkCDC+Hudi构建新的湖仓一... 查看详情
基于deltalakehudi格式的湖仓一体方案(代码片段)
简介： DeltaLake和Hudi是流行的开放格式的存储层，为数据湖同时提供流式和批处理的操作，这允许我们在数据湖上直接运行BI等应用，让数据分析师可以即时查询新的实时数据，从而对您的业务产生即时的洞察... 查看详情
偶数科技：基于oushudb的新一代云原生湖仓一体为企业助力
...。在国外有两种流行的实现数据湖仓的技术，他们分别是基于数据仓库和基于数据湖的解决方案，他们的代表分别是Snowflake和Databricks。去年11月，双方曾就两者性能差异吵得不可开交，作为大数据分析赛道的代表性厂商，不论是... 查看详情
alluxio2022技术干货年终大赏
...网易】《网易Impala+Alluxio稳定性保障和调优实践》4-【字节跳动】《数据湖在字节跳动的服务化实践》5-【MOMO】《Alluxio数据加速在MOMO的实践与应用》6-【腾讯】《腾讯Alluxio(DOP)在金融场景的落地与优化实践》7-【百度】《从Apac... 查看详情
b站基于iceberg+alluxio助力湖仓一体项目落地实践
...微直播间】，2min纵览大咖观点本期分享的题目是B站基于Iceberg+Alluxio助力湖仓一体项目落地实践，内容包含诸多技术细节，主要从以下4个维度进行分享：摘要01.B站湖仓一体项目的背景介绍当前B站每天会有pb级... 查看详情
b站基于iceberg+alluxio助力湖仓一体项目落地实践
...微直播间】，2min纵览大咖观点本期分享的题目是B站基于Iceberg+Alluxio助力湖仓一体项目落地实践，内容包含诸多技术细节，主要从以下4个维度进行分享：摘要01.B站湖仓一体项目的背景介绍当前B站每天会有pb级... 查看详情
字节跳动：基于h.266/vvc的移动平台8k超高清实时解码实践|qcon
网络视听服务的发展已经度过野蛮生长期，业界对音视频技术的探索也逐渐进入深水区。目前来看，视频化及高清视频化的大趋势已势不可挡，在成本、体验、计算、传输等多个层面上给业界提出了日益增长的巨大挑... 查看详情
字节跳动嵌入式数据分析最佳实践
更多技术交流、求职机会，欢迎关注字节跳动数据平台微信公众号，回复【1】进入官方交流群商业智能(BI)已经广泛被应用到用户实际业务过程中，如果BI作为独立应用平台应用，那么用户在日常使用业务系统（比如CRM/ERP/OA等）... 查看详情
从clickhouse到bytehouse：实时数据分析场景下的优化实践
近日，字节跳动旗下的企业级技术服务平台火山引擎正式对外发布了ByteHouse。在打造ClickHouse企业版ByteHouse的过程中，我们经过了多年的探索与沉淀，今天和大家分享字节跳动过去使用ClickHouse的两个典型应用于优化案... 查看详情
现在的湖仓一体像是个伪命题
...一类问题，借以达到使用简单高效的目标。现在很热的湖仓一体（Lakehouse）也一样， 查看详情
presto在字节跳动的内部实践与优化
引言在字节跳动内部，Presto主要支撑了Ad-hoc查询、BI可视化分析、近实时查询分析等场景，日查询量接近100万条。功能性方面完全兼容SparkSQL语法，可以实现用户从SparkSQL到Presto的无感迁移；性能方面实现JoinReorder&#... 查看详情
基于apachehudi极致查询优化的探索实践(代码片段)
...引信息来加速点查性能。本文分享自华为云社区《华为云基于ApacheHudi极致查询优化的探索实践!》，作者：FI_mengtao。背景湖仓一体（LakeHouse）是一种新的开放式架构，它结合了数据湖和数据仓库的最佳元素ÿ... 查看详情
字节跳动埋点数据流建设与治理实践
本文将介绍字节跳动在埋点数据流业务场景遇到的需求和挑战以及具体实践。文|石伟 来自字节跳动数据平台开发套件团队出品| 字节跳动数据平台埋点数据流埋点数据流在字节跳动埋点数据流主要处理的数据是埋点，埋点... 查看详情