关于 Apache 孵化器 Apache 孵化器是希望成为 Apache 软件基金会工作一部分的项目和代码库的主要进入途径。
目前国内越来越多的开源项目通过 Apache 孵化器进入 Apache 软件基金会孵化。
小米广告平台服务于MIUI系统之中各个产品线，包括浏览器，Feed信息流，视频流媒体。平台致力于为每个广告主提供高效、实时的统计分析。自2018年接入Doris以来，Doris以其卓越的性能和易用性得到了小米广告团的一致认可。 背景及需求 小米广告业务，从流量方看，主要在小米的各个生态产品中进行包括投屏、横幅、锁屏画报、视频广告等形式的广告展示。从广告主的角度来说，需要监测广告的定向投放效果，比如按地域、设备、时间、人群等等，并且需要根据投放的效果进行定制化的策略调整。这些使用需求，映射到OLAP场景，就是转化为不同的维度和指标，进行各种多维分析。 小米广告服务平台作为公司统一的内部平台，每天需要接收超过2TB的数据，每秒产生超过50K的事件。 Why Doris 支持星型模型(Star Schema)，方便用户建模。 兼容Mysql协议，无缝适配各类BI系统，迁移学习成本低 支持窗口函数，UDF。 运维部署简单，支持滚动升级。 支持物化视图(Materialized View)，平衡了效率和存储空间。 支持online schema change，适合业务的变更。 主要应用场景 广告数据从时效上可分为两类，批量和实时。批量数据存储在HDFS中，通过Doris提供的Broker Load功能进入Doris中，进行分析，数据延迟维持在分钟级别。 实时的数据，如CTR相关数据，则由Kafka经Streaming Load进入Doris，为广告主提供实时分析。为广告效果的评估、广告预算的分配提供实时性指导。
What’s Doris? Doris是一款基于Mesa模型的MPP、列式数据仓库，具有兼容MySQL协议，方便用户使用，在线运维等特点。 Doris的架构中主要包含两个模块：FE和BE。 FE模块主要用来进行元数据管理、事务管理、查询规划和任务调度，Doris支持多个FE，实现了在线的高可用；BE负责数据的存储、查询计划的执行。BE能够按需进行动态的伸缩，在线扩展，方便部署和运维。 我们已经发布了0.11.0版本，在下一个版本0.12.0中，主要包含Segment v2这个新的功能，用新的存储格式来解决原来的一些问题。 What’s Segment? Doris之前的存储格式被称为Segment V1，如下图所示，BE中的存储引擎会将数据存成Segment文件。Segment V1是一种跟orcfile类似的存储文件，实现了纯列式的存储，并且加上short key index，在其中还支持了zone map/bloom filter索引，并支持了谓词下推和向量化执行等优化。 但V1版本的Segment中，存在以下问题 1、按照字节流的方式进行读取和解析，效率不高 2、存在随机Seek的问题，在解析流的时候，需要先读8字节的头部信息，然后在读取一个压缩块信息 3、String类型按照Plain方式存储，效率比较低 4、对Cache不友好，只有Column Stream粒度的Cache 5、只缓存压缩之后的数据，对数据的多次读取，会解压多次数据 6、难以扩展新的索引，比如Bitmap索引 7、读取的逻辑比较复杂，难以理解 Segment V2，存储效率性能提升 由于Segment V1的种种问题，Doris设计了Segment V2以提升存储的效率和性能。 如上图所示，Segment V2也是一种纯列存的存储格式，分为三个部分：数据区，索引区和元数据区。数据是按照Page为粒度进行组织的，能够解决原来按照字节处理的问题。Page是编码和压缩的单位，并且我们在Page粒度实现了Cache，Cache解压缩之后的数据，对同一份数据的反复读取，只会解压缩一遍。 并且，我们实现了原来的Short Key、Bloom Filter、Zone Map的索引，同时我们增加了行号索引和Bitmap索引。在优化方面，我们实现了谓词下推和向量化执行，延迟物化的优化目前也在开发之中。 Segment V2——Page 首先来介绍一下最基本的概念：Page。在V2上，Page是编码和压缩的基本单位，而且索引的粒度基本也都是Page的，也是Cache的基本单位。 Page的格式分为头部信息，数据信息和Checksum。其中头部信息包含Page的第一行行号及Page中包含的行数。如果Column是Nullable，则还会存储NullBitmap的长度和NullBitmap信息。Data就是经过编码和压缩的数据信息。最后会在Page的末位存储Page的Checksum信息，用于校验数据的正确性。 Segment V2——Index Page 除了Data Page，我们还引入了另外一个概念：Index Page，用来存储索引信息，支持行号索引和Value索引，主要用于带索引数据列的实现，比如Bitmap索引和Bloom Filter索引。具体内容就是存储行号到Page Pointer的信息或者Value到Page Pointer的信息。 Segment V2——Index 上图是V2中索引的实现大概示意图。目前我们实现了Shortkey索引、行号索引、Zonemap索引、Bloomfilter索引和Bitmap索引，其中Short Key索引是构建在Row Block粒度的；行号、Zonemap、Bloomfilter索引是构建在Page粒度的，Bitmap索引是在行号上的。我们实现行号索引，能够比较简单的将各种索引组合在一起，以提升查询的性能；并且能够方便扩展新的二级索引。 Segment V2——Write 关于V2的写入流程： 1、Add Row，数据是一行一行添加在Segment中，但是是保存在内存中 2、当Segment文件大小达到阈值，就会将Segment文件刷到磁盘，整个刷数据的顺序就是按照前面Segment图中描述的顺序写入的，先写数据，然后写索引，然后再写Footer 3、如果segment文件大小没有满，就会将数据添加到当前的Page中，进行编码；如果Page满了就会进行压缩，将Page添加Page List中，保存在内存中。 整个过程具有以下的特点： 1、Segment文件是缓存在内存中，等到阈值时一次性写入到磁盘。一方面是为了实现控制文件的组织结构，另外一方面是为了顺序I/O 2、Segment Size阈值可以配置 3、各个列的同一种类型的索引是写到一起的。 Segment V2——Read 下面是Segment读取的流程 1、在Doris中，数据是按照Batch方式读取的，不是一条一条读取。调用next_batch读取下一个批次的数据，Batch大小是1024行，在调用这个接口的时候会传入Predicate信息。 2、获取要读取的行号范围，该过程会利用Predicate信息和索引信息，过滤掉一些不需要的行号范围 3、将行号范围映射到各个列的Page Ids范围 4、在各个列中查询该列的Page是否被缓存，如果缓存在内存中，就Decode Page信息，填充到返回结果的Batch内存中 5、如果该列的该Page没有被缓存，就会进行I/O操作，将Page加载到内存中，进行解压缩，然后加到Page Cache中，然后Decode该Page的数据，填充到Batch中 6、最后会拼装各个列的数据，进行向量化执行Predicate过滤，之后返回给调用方。 Segment V2——Predicate Pushdown 这里大概介绍一下，在读取过程中谓词下推是怎么实现的。在V2中，暂时支持的Predicate还比较简单，后续打算会进行扩展。下图是一个例子，如果用户查询age = 35 and phone in 的语句，那么在Zone Map和Bloomfilter索引过滤之后，就会只剩下红框中的数据需要读取，降低读取的数据量 Segment V2——Encoding Compression Framework 在V2中，为了实现高效的在Page粒度的编码，我们目前已经支持了多种方式的编码： Run Length Encoding Bitshuffle encoding Plain encoding Frame of reference encoding Dict encoding Prefix encoding 未来也会在此基础上增加新的编码，如PageBuilder/PageDecoder以及EncodingInfo Factory 现在也支持了多种压缩的框架： Zlib Snappy Lz4 lz4f 未来也会支持更多压缩框架，如BlockCompressionCodec，Compression Codec Factory等 Segment V2——String Encoding 相对V1做了字典压缩的功能，原有V1版本中用的是Plain Encoding的方式，效率比较低。Dict Encoding主要是用来解决低基列的字符串类型的存储。最终实现的例子如下：会建一份词典，并存储词典对应的编码来对应原始数据。同时Prefix Encoding也已经实现了，后续会进行一些优化。 性能数据 下面是一些性能测试。用随机构造的不同基数下的数据进行测试，V2的词典压缩效果在低基数要明显优于v1。用TPCH的Part表进行测试，效果会更加明。同时，从业务数据上看，词典压缩效果也比较明显，能够节省达50%的存储空间。 数据导入在不同的情况下也有不同程度的提升。 我们使用TPCDS catalog_sales进行了测试，从上面的数据来看，目前相对于v1，v2的性能有所提升，但是有进一步的优化空间，我们正在努力进一步提升v2的效率和性能。 RoadMap 未来Doris的主要工作包括：继续优化Segment V2，并在下一个版本中发布Bitmap索引的功能，并持续探索复杂类型的支持和云原生的设计。
文章来源于京东零售技术 ，作者技数中心李海波 背景介绍 Apache Doris是由百度贡献的开源MPP分析型数据库产品，亚秒级查询响应时间，支持实时数据分析；分布式架构简洁，易于运维，可以支持10PB
分享者：马骎 微博平台研发部资深系统研发 前言 微博的工程业务团队是来自微博平台研发的feed组，微博平台的关注流和转评赞互动都来自工程业务团队的技术支持。 基于对业务数据关注的希望，微博从17年初开始做数据方面的建设。目前系统已经应用了Kafka、HDFS、Spark等，同时，Doris也在其中起到了重要的作用。 1.背景介绍 微博团队在2018年1月开始调研Doris，进行功能、性能方面的评估；2019年初正式引入生产环境。微博目前总共部署两个Doris集群，部署规模在40+节点。上图展示了Doris在微博部署的具体规模，可以看到服务器除了磁盘容量上的差别外，配置基本同构。 部署方法上，微博团队采用Docker容器的方式部署Doris，同时也给Doris建立了服务池，保持其他业务运维管理的一致。 Doris目前在微博主要承接了阅读互动相关方面的数据支持的需求，单天写入规模大致维持在4~5亿条这个量级。 2.Doris应用场景 Doris在微博的应用场景主要分为3类。 首先存储微博阅读数等历史数据。微博上实时展示的阅读数据，经常面临来自不同媒体的质疑。为消除质疑，需按分钟存储各条微博的互动状态以及阅读量等数据，以便查询审计之用。引入Doris存储此类数据，可大大提高查询效率。 应用于多维分析和监控。之前的业务监控使用graphite，但是想做一些多维分析的时候比较困难。后来应用Doris做存储，可以实时看到数据上的刷新和变化，对掌握业务的情况有许多的帮助。 热点内容的实时统计。每分钟导入评论最多的2000条微博进入Doris，实时统计一段时间区间内的微博热点。 微博数据流可以分为实时和离线两条处理方向。实时和离线数据流的起点皆是Kafka，实时数据流经过Spark/Flink的流处理，实时灌入Doris，以供查询；离线数据流经Spark/Flink计算之后，写入分布式文件系统HDFS，再以例行任务的形式经Spark写入Doris。 至于A/B Test的计算数据也可以通过类似方式随时导入Doris中，为后续评估提供数据。 2.1微博阅读数 微博互动日志以分钟粒度现在Spark中进行计算，而后以Mini Load任务的方式推送到Doris中，进行实时的微博阅读数据展示。这种追踪粒度也可以为热点应对提供数据支持。 2.2多维分析 在业务中需要支持多维分析，恰巧这也是Doris最擅长的。于是微博团队开发了一个基于Doris的多维分析工具。把日志导入到Doris，定义一个表，将多个维度作为key并预留多个value列，应对不同维度数量需求，然后在外部维护。通过这个工具，不论是离线分析的还是实时的分析都非常方便，这都依赖于Doris快速查询的性能。 2.3简单计算 想了解当前一段时间区间内，评论互动最多的微博，就需要倚赖此项计算功能。图中的事例就是5分钟内，受到评论最多的微博列表。每分钟将评论最多的2000条微博导入Doris中，再辅以SQL查询，即可轻松得到相关信息。分钟级别时效性分析也能有效帮助平台方监控微博的实时流量动态。 3.Mini Load队列机 Mini Load队列机的由来 微博引入Doris的时间比较早了，之前版本在导入时总会遇到一些问题，稳定性差、主要任务卡死、不便于导入太多任务，因此便开发了Mini Load队列机来增强导入性能。 Doris 0.9的开源版本中提供Broker Load和Mini Load两种导入方式。Broker Load用以解决大批量离线文件的导入，Mini Load针对小批量文件的快速加载需求。微博数据分析对时效性比较敏感，数据写入都采用Mini Load方式予以进行。 微博平台计算采用的Spark/Flink都是纯流式接口，为了弥补Spark/Flink的streaming和Doris Mini Batch之间的差异，平台方特别提供了Mini Load队列机的机制。通过Mini Load队列机，大幅减少Doris的扇入扇出，提高整体吞吐。 微博数据先落到Kakfa中，随后Flink逐段读取kakfa，并写入到HDFS中。当文件按分钟粒度进行合并之后，写入相应任务到队列机中，进行调度、消费数据。 Doris在0.10.0版本中，会发布Streaming Load的功能，届时即可使用此功能接收Spark/Flink的数据流。
分享者：康凯森 美团点评资深大数据工程师 / Apache Doris Contributor 前言 美团点评是Doris开源以来最早的用户之一，至今，Doris已在美团外卖业务上成功落地，并逐渐扩张至酒旅
并且已经进入Apache基金会孵化，未来可期，并且后续开发维护有保障。 完善的功能支持，标准MySQL协议。
分享者： 搜狐智能媒体研发中心资深研发 翟东波 / Apache Doris Contributor 前言 搜狐智能媒体研发中心支撑了整个搜狐主站文章的底层数据管理，包括庞大繁杂的数据整理、分析、挖掘、
Apache软件基金会（Apache Software Foundation, ASF）是世界上最大的开源软件基金会，Apache目前拥有超过350个开源项目。
