网站开发与数据库,手机wap网站 分页,局部装修改造找哪家装修公司,有哪些做兼职的设计网站有哪些数据驱动未来。在大数据生态中#xff0c;数据分析系统在数据创造价值过程中起着非常关键的作用#xff0c;直接影响业务决策效率以及决策质量。Apache Doris作为一款支持对海量大数据进行快速分析的MPP数据库#xff0c;在数据分析领域有着简单易用、高性能等优点。9月20日… 数据驱动未来。在大数据生态中数据分析系统在数据创造价值过程中起着非常关键的作用直接影响业务决策效率以及决策质量。Apache Doris作为一款支持对海量大数据进行快速分析的MPP数据库在数据分析领域有着简单易用、高性能等优点。9月20日Apache Doris组织了一场线上Meetup作业帮受邀参加并带来了一场《Doris在作业帮实时数仓中的应用实践》的主题分享。现场分享精华大家下午好。下面我来介绍下Doris在作业帮实时数仓中的应用与实践。这次的分享主要分三个主题1、首先是所在团队的业务与背景介绍2、其次会介绍下基于Doris作业帮的查询系统是如何构建的以及主要解决的问题3、未来的规划我所在团队是作业帮大数据团队主要负责建设公司级数仓向各个产品线提供面向业务的数据信息如到课时长、答题情况等业务数据以及如pv、uv、活跃等流量类数据服务于拉新、教学、BI等多个重要业务线。在数仓体系中大数据团队主要负责到ODS-DWS的建设从DWS到ADS一般是数仓系统和业务线系统的边界。在过去由于缺失有效、统一的查询系统我们探索了很多模式来支持各个业务线发展。有些业务线对大数据相关技术比较了解熟悉spark等计算系统可以自己处理计算。因此会选用kafka 接收数据后使用spark计算的模式来对接大数据团队但是其他业务线不一定熟悉这套技术栈因此这种方案的主要问题无法复制到其他业务线。且Spark集群跨越多个业务线使用本身就给业务线带来了额外的维护成本。既然KafkaSpark的模式无法大范围推广我们又探索了基于ES的方案即大数据将数据写入ES中然后业务先直接访问ES来获取数据但是发现一方面高性能的使用ES本身就具有很高的成本对ES得非常熟悉这对于业务线来说很难有精力去做其次由于使用ES的系统质量参差不齐偶会还发生将ES集群打垮的问题稳定性也不可控最后ES-Sql语法完备性不足如不支持join、多列group by6.3版本等。因此我们又探索开发API接口希望在稳定性上可以有更好的解决方案。虽然API可以可控但是由于API不提供Sql功能基于需求场景不断case by case的API开发反而成了影响交付效率的主要瓶颈点。上述多是支持查询明细数据一旦涉及到大规模的流量类查询如pv、uv只好引入druid类系统但是duird的接口和其他系统的接口不一致用户往往又得学习且Druid不支持明细一旦需要明细就需要到ES去查询由于涉及两套系统有时候还得处理明细数据和聚合数据不一致的问题。随着需求越来越多系统也越来越难以维护交付效率也特别低需求排队非常严重。因此提供有效而统一的查询系统对于实时数仓建设在提高业务支持效率、降低维护成本上都具有非常重大的意义。 经过过去数月的探索与实践我们确立了以Doris为基础的实时查询系统。同时也对整个实时数仓的数据计算系统做了一次大的重构最终整体的架构图如下如图所示从下到上原始业务层日志经数据摄入系统进入数仓在数据清洗计算层我们将原来基Spark系统升级到了Flink并且基于Flink-Sql提供了统一的数据开发框架从原有的代码开发升级到Sql开发来提升数据的研发效率。其后查询系统将Kafka的数据实时同步到查询引擎内并通过OpenAPI的统一接口对外提供查询服务。 基于Doris的查询系统上线后我们面对一个需求不用像过去一样做方案调研、开发接口、联调测试现在只要把数据写入业务层就可以基于sql自己完成数据查询、业务开发交付效率数据计算好到提供可读服务从过去的数人周加快到小时级。 在性能方面过去基于ES或者mysql来做当查询的数据量较大时我们只能忍受数十个小时到数分钟的延迟基于Doris的方案加快到分钟级甚至秒级。Doris的整体架构非常简单不依赖任何第三方组件社区支持度也非常好从上线到今我们只需做一些轻量级的运维规范即可保证高稳定性。 所以说通过引入Doris解决了作业帮内实时数仓查询交付慢、查询慢的痛点问题对于后续数仓的系统发展起到了非常关键的作用。 接下来重点讲下查询系统的工作。分两部分查询系统的架构选型以及原理以及应用实践在讲查询引擎之前先讲下业务场景。 作业帮内业务场景主要分两种一种是 传统的流量类比如算pv、uv、活跃……作业帮内很多时候还需要看进一步的明细。比如 作业帮主App 在每天各个小时的活跃用户数还要看 作业帮主App每个小时内各个版本的活跃用户数。 第二种是 面向我们业务线的工作台比如教学的老师。比如我们的老师上完课后会看下自己班内的同学们的出勤数据、课堂测验数据等。 这两种场景下这块考虑到调研成本、团队技术生态、维护成本等多种因素我们最后选择了Doris 作为我们的查询引擎。主要是Doris可在上述两种场景下都可以统一的满足业务的需求。 首先介绍下Doris。Doris是 mpp架构的查询引擎。整体架构非常简单只有FE、BE两个服务FE负责Sql解析、规划以及元数据存储BE负责Sql-Plan的执行以及数据的存储整体运行不依赖任何第三方系统功能也非常丰富如支持丰富的数据更新模型、Mysql协议、智能路由等。对于业务线部署运维到使用都非常友好。接下来讲下用Doris如何解决我们前面提到的业务场景下的问题。 Doris有多种数据模型流量类场景常用的是聚合模型。比如对于前面提到的场景我们会吧作业帮主App各个版本的明细数据存到base表中如果直接从base表中读取跨天级的聚合数据由于数据行比较多可能会出现查询延迟的问题因此我们会对常用的天级数据做一次rollup这样通过预聚合来减少查询的数据量可以加快查询的延迟。 要高效的使用Doris的聚合模型前提都是基于key列做数据行筛选如果使用value列Doris需要把相关的行全部聚合计算后方可决策是否属于结果集因此效率比较低。而对于教研工作台前面提到的都是基于value的筛选因此使用了Doris on ES的模型。主要是考虑到 可以发挥ES的任意列检索的能力来加快查询速度。在我们的实践中发现Doris on ES相比直接裸用ES或社区的其他方案如Presto on ES在性能上有很大的提升接下来介绍下Doris on ES高性能的设计原理。Doris on ES整体的架构如图FE负责查询ES的元数据信息如location、shard等BE负责从ES数据节点扫描数据。 Doris on ES高性能相比裸用ES有几个优化点裸用ES时ES采用的是Query then Fetch的模式比如请求1000条文档ES有10个分片这时候每个分片都会给协调返回1000个doc id然后 协调节点其实拿到了10 * 1000个doc id然后选择1000个。这样其实每个分片多返回了900个.Doris on ES则绕过了协调节点直接去操作datanode。它会在每个datanode上查询符合预期的docid这样不会有过多的docid返回。 其次Doris从ES扫描数据时也做了很多优化。比如在扫描速度上采用了顺序扫描、列存优化、谓词下推等在数据从ES传输到Doris时采用就近原则如BE会优先访问本机的datanode、source filter来过滤不用的字段等来加速传输速度。在我们的调研中Doris on ES的性能比Presto on ES快了有数十倍。在作业帮内除了上面介绍的基于Doris的数据模型做的基础应用要完整的支持业务、保证稳定性、提高效率还需要其他周边的系统建设。接下来介绍下基于Doris作业帮查询系统架构的整体设计以及工作模式。 这是作业帮查询系统的总体架构。从上往下首先是我们平台包括各个报表平台、元数据管理平台等主要来提高各个场景的人效。其下红色部分为我们统一的api接口层这里我们主要是制定了api的规范比如请求响应方式、返回码等来减少系统之间对接的成本。基于api除了提供了主要的读写接口外也包含了周边的服务建设比如元数据管理、调度系统等。 接下来就基于一个完整的流程来介绍下各部分系统。 首先是元数据。Doris基于mysql语法建表已经有元数据我们这里做元数据有几个额外的考虑首先是保障查询性能方面如果一个表在建表时配置写错那么查询性能会非常差比如ES的index mapping中关闭了docvalue或者Doris表未启动列存模式那么查询就会退化成行存模式性能会比较低因此为了最大化性能就需要将建表的过程全部自动化且规范化。这是其一。Doris自身存储是有强Schema约束的比如一个字符串的长度。但是ES并没有明确的长度约束对于一个keyword类型的字段写入128B或者256B都可以成功但这会导致一个问题当把一张es表同步到Doris表时同步的成功率无法保障。另外一旦Doris表声明的类型如bigint和ES index的类型不一致如keyword时也会导致Sql运行失败。因此需要构建统一的数据模型来避免这类问题。第三使用效率。我们在使用过程中建表、删除表、修改表是一个常见的操作为了让各个业务线的同学不管是否了解Doris都可以快速的建表这也是要做统一元数据、统一模型的基础。最后前面也提到了我们整个计算系统也在重构为flink-sql。flink-sql则会强依赖元数据比如table on kafka、table on redis…… 要统一元数据统一数据模型就得抽象整个数据表的结构来管理好不同存储上的表我们基于env、db、table为基本单位来管理表database、table大家相对熟悉env是我们引入的新namespace主要用于提供不同集群/业务线的定义如百度云的数仓集群、腾讯云的数仓集群表单元下主要包含field列类型、值域、index如rollup、bitmap索引等、storage存储属性。关于列属性主要是规范化类型系统考虑到json-schema由于其校验规则丰富、描述能力强因此对于列值的约束统一使用json-schema来做。对于数据类型我们设计了公共数据类型以及私有数据类型。公共类如varchar、int等这些在不同的存储系统都有对应的实现也支持私有类型如Doris::bitmap方便私有系统的兼容和扩展。通过这个模式可以将基于各个存储系统的表做了统一的管理 这是我们线上的真实的一张表。里面包含了列信息以及对应的存储配置。左图中的纵向红框是json-schema的描述来规范化值域。横向红框为ES表的一些meta字段比如docid、数据更新时间。这些字段可以方便追查数据问题、以及用作数据筛选。因为我们统一了数据模型因此可以很方便的对所有表统一设置要增加这些meta字段。 通过元数据的统一管理构建的表质量都非常高。所有的表都在最大化性能的提供查询服务且由于数据导致的查询不可用case为0。且对于任何业务线的同学不管是否了解Doris都可以分钟级构建出这样一张高质量的表。 建好表后就是数据的写以及读。统一基于openapi来做。做api接口其实本质上也是为了在提供系统能力的前提下进一步保障系统的稳定性和易用性。比如要控制业务线的误用如连接数打满提供统一的入口方便写es、Doris且控制数据质量……。 首先介绍下数据写接口。由于统一了表模型因此可以很方便的提供统一的写入接口协议。用户也无须关注实际表的存储是es还是Doris以及处理异构系统的系统。第二统一了写接口就可以统一的对写入的数据会做校验检查如数据的大小、类型等这样可以保证数据写入的质量与准确性。这样对于数据的二次加工非常重要。第三接入协议中还增加了关键词如数据的版本。可以解决数据的乱序问题以及建立统一的写入监控。如下图是我们整个写入数据流的qps以及端到端数据写入存储时间以及数据生产时间的延迟分位值这样可以让系统提高可观测性、白盒化。 接下来讲一个具体的场景写入端是如何解决乱序问题的。 常态下我们的实时数据流是经过flink或spark计算后写入kafka然后由查询系统同步到Doris/es中。当需要修数时如果直接写入会导致同一个key的数据被互相覆盖因此为了避免数据被乱序覆盖就得必须停掉实时流这个会导致数据时效性式受损。 因此我们基于写入端做了改进实时数据流、离线修复数据流各自写入不同的topic同步服务对每个topic做限速消费如实时流时效性要求高可以配额调的大些保证配额离线时效性则允许配额小点或者在业务低峰期将配额调大并基于数据key列版本存储做了过滤。这样可以保证时效性的前提下修数也可以按照预期进行。 最后是读的部分。在提供sql能力的前提下我们也做了一些额外的方案比如缓存、统一的系统配置。对于系统延迟、稳定性提升都有很大的改进。并且由于统一了读接口上述的这些改造对于业务线来说都是透明的。 除了常规下面向低延迟的读还有一类场景面向吞吐的读。介绍下场景比如 要统计统计某个学部下各个老师的学生上课情况上课人数、上课时长等。在过去我们是基于spark/flink来处理这类问题如spark消费kafka中的课中数据对于每一条数据会去redis中查询教师信息来补全维度。 常态下当课中数据到达的时候教师信息是就绪的因此没有什么问题。可是在异常下如维度流迟到、存储查询失败等会导致课中流到达时无法获取对应的教师信息也就无法计算相关维度如学部的统计。过去面临这种情况时只能遇到这种异常如重试如果无法解决只能丢弃或者紧急人工干预比如在尾标就绪后再重新回刷课中表一旦遇到上游kafka数据过期就只能从ods层或者离线修复效率特别低用户体验也非常差。 基于Doris模式下我们使用微批调度的模式。调度系统会定期分钟级执行一个调度任务基于sql join完成数据的选取。这样哪怕在异常下课中流查不到教师数据这样join的结果只是包含了可以查到教师数据的信息待教师数据就绪后即可自动补全这部分课中数据的维度。整个过程全部自动化来容错。效率非常高。因此这个模式的主要好处业务端延迟可控、稳定性好。整个过程主要取决于调度的周期和Sql执行时长。调度周期可控且由于Doris on ES的高性能Sql执行时长几乎都可以在分钟内完成。数据修复成本低、维护方便。一旦数据有异常可以自动触发对应的数据窗口进行重新计算。最后讲下其他方面的建议实践这些相对简单但是在实际的应用中非常容易忽视。ADS层表尤其是面向平台侧的应用慎用join。Doris的join策略比较多如broadcast、shuffer等如果使用需要了解原理属于高级用户的使用范畴。对于强调快速迭代的场景下可以使用微批模式来略降低数据更新的延迟提高数据查询的效率。使用Doris on ES时尤其是在ES集群负载很高的情况下在延迟允许的情况下建议将es的扫描超时时间设置大一点如30s甚至更久。Batch size不是越大越好。我们实践中发现4096下最好可以最高达到每秒30w的扫描速度。Doris使用bitmap做精确去重时有时候会发现Sql延迟比较高但是系统cpu利用率低可以通过调大fragment_instance_num的值。运维Doris时建议使用supervisor可以帮助避免很多服务异常挂掉的问题机器全部开启ulimit –c避免出core时无法高效定位当前我们在使用master版本主要是考虑到bugfix很及时但是也要避免新代码、feature的bug引入因此我们会关注社区的issue、并做好case回归、固化使用模式等一系列手段来保障master在实际生产中的稳定性。 最后讲下规划。Doris 在作业帮实时数仓的建设中发挥了很关键的作用。在实际的应用中我们也发现了一些当前的一些不足。 如Doris on ES在面对大表的join查询时目前延迟还比较大因此需要进一步的优化解决Doris自身的olap表可以做动态分区对于ES表目前可控性还不足其次当ES修改表后如增加字段只能删除Doris表重建可能会有短暂的表不可用需要自动化同步或者支持在线热修改最后Doris on ES可以支持更多的谓词下推如count等。我们也希望可以和社区一起把Doris建设的越来越好。好的。我的分享到此结束。谢谢大家。 精彩问答QA问题1Doris on ES V.S. sparksql on ES在功能上和性能上咱们调研过吗对于使用哪个您这边有什么建议吗答SparkSql on ES和Doris on ES 虽然都是Sql但是在实际的生产环境中使用差异还是比较大的。功能上来说SparkSql和Doris-Sql需要考虑语法的兼容性问题毕竟是两个系统语法兼容其实很难。一旦不一致就需要用户端面向不同的系统做适配。性能上SparkSql或者Doris on ES虽然访问ES的原理都差不多但是实现上可能会有diff这些diff会导致性能上差异比较大如SparkSql的connector是不支持列存模式的。场景上如果使用SparkSql建议可以使用在流计算场景更多的是解决吞吐的问题类似的系统应该是Flink-Sql。可以吧数据按照行扫出来后基于Spark的分布式计算能力、yarn的资源管理走流计算的模式。Doris on ES更适合走低延迟的场景。问题2Doris 支持Hive Metastore和Flink SQL是什么关系刚才讲的太快有点没听懂答Doris其实是不支持Hive MetaStore的。只是可以从HDFS上load文件然后在Doris的load语法中指定对应的列。FlinkSql和这块关系不大。不过我理解你说的应该是我们的元数据这部分背景是因为Flink-Sql运行时需要设置ddl语句比如一张基于redis的表都有哪些列类型是什么这些需要统一的管理起来目前是存储到了我们的元数据系统中。通过接口和Flink系统完成对接。问题3_version字段是一个内部字段需要用户端写入的时候指定还是系统自动创建和HBase的version的应用场景有区别吗答_version是我们数据流的一个内置协议字段。在数流转过程中用户只要设置值即可不需要显示创建。具体的值可以根据数据字段的写入服务来设置比如在ods层应该是采集侧服务来写入如果在中间的flink清洗环节应该是flink系统来设置尽量让架构服务统一设置保证稳定性。_version字段最终会映射到存储系统中的UpdateTime字段这个也是架构负责写入的。不需要业务侧关注。HBase的version更多是用于多版本的管理比如数据的回滚等。这里查询系统的_version更多是为了保证数据的时鲜性即用户从查询系统读到的数据始终是最新的。这么做的前提主要是因为查询系统比如ES对于数据列多版本支持不太好对于数据流更新时如果没有版本管理容易导致乱序覆盖。和HBase的version场景还不同。ES内部也有一个_version但是这个_version一般是ES内部使用用于高并发下乐观锁的实现。和当前的场景都不一样。更多阅读推荐还不懂Redis看完这个故事就明白了2020职场人裸辞三大原因不开心、工资低、没有盼头云原生安全模型与实践Swift、Flutter 共同瞄准 WindowsPINGPONG技术文档数据分析三剑客MySQL可视化套餐量化分析Hadoop仓库
