扬流
扬流_个人页
扬流
文章
64
问答
0
视频
0
个人介绍
致力于阿里云开源大数据商业化
擅长的技术
- 数据建模
- 数据可视化
- 数据采集
- 搜索推荐
- 数据挖掘
- 决策智能
- 知识图谱
- 自然语言处理
- 机器学习/深度学习
获得更多能力
通用技术能力：
-
Python
初级
能力说明：
了解Python语言的基本特性、编程环境的搭建、语法基础、算法基础等，了解Python的基本数据结构，对Python的网络编程与Web开发技术具备初步的知识，了解常用开发框架的基本特性，以及Python爬虫的基础知识。
-
前端开发
初级
能力说明：
基本的计算机知识与操作能力，具备Web基础知识，掌握Web的常见标准、常用浏览器的不同特性，掌握HTML与CSS的入门知识，可进行静态网页的制作与发布。
云产品技术能力：
-
ACA
-
阿里云大数据助理工程师认证（ACA）
获得于2021-04-16 00:02:53
-
阿里云大数据助理工程师认证（ACA）
阿里云技能认证
详细说明-
发表了文章 2023-05-23
猿辅导基于 EMR StarRocks 的 OLAP 演进之路
摘要：猿辅导大数据平台团队负责人申阳分享了猿辅导基于 StarRocks 的 OLAP 演进之路。主要包括以下几大部分：数据需求产生OLAP 选型StarRocks 的优势业务场景和技术方案基础建设点击查看直播回放一、数据需求产生猿辅导成立多年，早期是基于关系型的 MySQL 数据库来做数据的需求。随着业务的发展，多个服务在一个 DB 去做数据的汇总，以及一些微服务架构的产生，使得数据逐渐走向分裂，很难在 MySQL 里完成统一的数仓。 因此在 2014 年，公司开始了统一数仓的建设，采用的是比较成熟的 Hadoop体系。虽然是用 Hive、MapReduce 做离线的批量的 ETL，但是为了保证用户交互足够快、延迟足够短，还是会把最终的应用层的数据放在 MySQL 里来做。包括现在很多离线需求也仍是这样一个链路。 随着公司业务的快速增长，以及一些新的业务形态的出现，以 MySQL 作为 BI 存储底座的瓶颈愈发明显。2020 年，新冠疫情爆发，公司业务出现了爆发式的增长，原本的离线T+1 的链路已无法满足业务上的数据需求。当时，我们做了很多实时的需求，有一条离线链路，一条实时链路，在应用层的存储上完成实时和离线的统一。为了应对不同的业务场景，又引入了很多新的 OLAP 引擎来做不同的需求。我们希望能够有一个引擎，可以完成在 AP 场景下的统一，这时就发现了 StarRocks。目前，除了自建的 一些 StarRocks 集群，我们也在跟阿里云团队合作，使用云上 EMR 的集群，是一个混合云多集群的的模式。 二、OLAP 选型接下来介绍在 OLAP 选型时，我们考虑的一些点。 猿辅导 OLAP 支撑的场景，包括商业分析、广告转化、业务监控、还有一些用户触达等等，很多 BI 应用还是在用 MySQL 来做底座。所以需要去兼容原本 MySQL 的协议，也需要兼顾到查询的性能。我们的需求主要有八点： 亚秒级的数据查询延迟； 支持大宽表以及多表 join； 具备高并发的能力； 支持数据的流式和批式摄入； 支持标准化的SQL； 具备高性能的精准去重能力； 低的运维成本； 能够灵活地横向扩缩容，并且对于业务是无感知的。 开源 OLAP 引擎分为 MOLAP 和 ROLAP，前者属于预计算方式，后者是关系型的模型，ROLAP 又可以分为基于 MPP 的和 DAG 的基于 Hadoop 底座的这部分。 我们对比了不同引擎的优缺点。可以看到 Spark、 Presto 、Trino 引擎，更适合去做批处理，做一些查询的加速，但是在并发的场景下，支撑的能力是不够的。Druid、Kylin 引擎，因为是构建于预计算的物化的能力，数据的重放的成本会非常高，同时对数据开发人员的要求也会相对较高。而 Doris 和 Clickhouse 的 MPP 架构的引擎，相比较下更能够满足当时的 BI 需求。考虑到运维的成本以及多样化的模型，当时选择了 Doris。随后又发现 Doris 跟 StarRocks 相比，性能上还是会有一些差别。 下图是我们当时做的一个Benchmark，主要是拿猿辅导内部的一些 BI 场景的SQL 来做了一个对比。可以发现当时 StarRocks 借助于它本身优秀的向量化引擎的能力，能够在大部分场景下比 Doris有 2 到 3 倍的性能提升（这里的性能主要指查询的延迟）。因此我们决定将更多的场景基于 StarRocks 来做。 三、StarRocks 的优势StarRocks 最大的优势就是极致性能。主要得益于列存，高效的 IO，高效的编码的存储，丰富的索引加速（包括前缀索引、Bitmap倒排索引），物化视图的加速查询，全面的向量化，以及它的 MPP 的架构，通过并行执行中间结果不落盘的方式，能够让结果更快地跑出来，并且能够在集群规模扩大的时候带来性能的线性提升。 第二个优势是模型丰富。在猿辅导主要用到的是更新模型，目前在做的是把更多的场景逐渐往主键模型上过渡，因为我们的很多场景依赖于实时 CDC 的数据，它对 CDC 流有着更好的实时更新性能。另外，它原生的分区分桶设计架构，能够利用到数据的冷热的存储，能够利用分区裁剪的性能去更好地提升查询性能。 另外 StarRocks 也在快速迭代，经常能给我们带来很多新的特性。比如 CBO，对比原本在之前的查询优化和 CPU 的优化器，在一些的场景下，可以看到3 到 5 倍的性能提升。第二个是 Catalog，因为数据底层存在很多不同的数据引擎，所以希望在 Catalog 这一层能够去融合更多的数据，包括 Hive、MySQL、ES，以及 StarRocks 的其他集群，都可以在 Catalog 这层去做统一。第三是资源管理，可以用到 StarRocks 的资源管理的能力，做不同场景的大小查询的一个隔离，可以做到查询的熔断，可以在 CPU 、内存包括并发上做一些限制。另外一个是异步多表物化视图，这也是最近想去尝试的一个特性，跟现在一些场景下的演进有关系，希望把更多的逻辑通过物化视图来实现。 四、业务场景和技术方案下面介绍一些在公司内落地的场景。 首先来介绍一下整体的数据架构。 我们比较少用 StarRocks 来做数据计算，更多的还是将其作为数据应用的存储底座。 现在 StarRocks 最重要的一个场景，就是 BI 报表、多维分析的场景。 它还是一个 Lambada 架构，会有一些原始数据，比如业务 DB，有一些业务的日志埋点数据，实时这部分链路是 Kafka 到 Flink，最终到 StarRocks，是分钟级的数据；离线部分是 Hive 架构，主要是以天级和小时级的数据放到 StarRocks，上层去对接报表的应用。 上图是一个多维分析报表，它是基于后台写的一个 SQL，在前台的报表进行多维的分析。原本是用 MySQL 做 BI 报表的底座，但是在数据规模超到超过百万，遇到一些高技术维度、多维度的数据的时候，查询性能就会比较慢。所以用 StarRocks 替代 MySQL 来做多维分析，带来的提升非常明显。 上图也是一个 BI 的场景，是完全基于 StarRocks 做的一个指标平台。它是一个 NOSQL 的方案，会由数仓的同学首先去预先定义好一些维度和指标，用户在使用的时候，会先定义一个数据源，选择一些维度，选择一些指标，基于数据源再去生成一些单图，再把它做成看板。当用户自助地去生成一些图表的时，后台会转化成一个 SQL 来执行。 上图是一个简单的例子，上图左上角是定义一些维度表，左下角是指标的定义，包括其查询条件和计算方式。右边可以看到在实际执行的 SQL。这里的数据还是以离线数仓为主，因为需要对模型有一个明确的定义。上图是一个用户的行为分析。主要是基于客户端的用户行为埋点数据。最早的时候，是通过 Druid 来做的， Druid 在时序化数据方面的性能还是非常不错的。但是有一些事情它做不了，比如对于一些复杂的查询，它本身能提供的算子是比较有限的。另外希望对维度数据能做一些组合，Druid 也是无法实现。所以我们用 StarRocks 把用户行为分析进行了重构。利用到 StarRocks 查询加速的能力，去给用户提供事件的聚合数据，能提供UserTrack 的一个能力。 它的链路也比较简单，会把埋点数据往 Kafka 里放一份，在 Flink 这一层去增加一些维度的信息，包括产品线、埋点的元数据。在 StarRocks 里会先尝试做一层明细表，按照天做分区，按照用户 ID 去做分桶。在 UserTrack 场景下，以用户维度去看这部分数据的时候，主要利用到分区分桶的能力，利用它的前缀索引和 Bloomfilter 过滤器，去实现快速地点查，以及高并发查询的要求。在事件分析的场景，主要是用到了小时的物化视图，去加速查询，利用 Bitmap 做精准的用户的去重计算，用 HLL 来做设备维度的模糊去重。上图展示的是研发的一个监控看板，场景是实时采集引擎指标，进行数据分析，也有一些主题化定制的报表。数仓的粒度分得比较粗放，会放一层明细，有一些维度的数据，再做一些聚合。 值得一提的是，这套架构相对较复杂，因为有一部分数据是通过湖式的数据来做第一层数据接入，会先往 Iceberge 里存一次，中间通过 Spark 、 Flink 的引擎去计算，再往 StarRocks 里放，并且会在 Hive 和 StarRocks 去做数据的双写。 另外，互联网教育直播课堂有一个特点是它的波峰波谷特别明显，因为孩子们大部分是在同一个时间段上课，比如在周五下午上课，在上课的这两三个小时里面的数据量是非常爆炸的，平时的时候就没有什么流量。它带来的一个问题是，StarRocks 的表都是按照天、小时去做分区的，波峰时段的单个分区的数据就会非常多，分区里的 template 会非常大，那么在这个时候做compaction，对集群的性能消耗就会非常严重。所以这里做了一个自适应的处理，会去动态调整partition 的bucket，保证整个的查询性能能够保持在一个比较平稳的水平上。 上面是一个B端的业务后台，主要是给老师的一些数据看板，叫斑马数据看板。它主要是做督学看板、学情沟通，帮助老师去做学生上课情况的一些追踪，去做一些反馈。 它的特点主要是以小时的数据为主，也会有一些实时的用户行为的数据。这也是一个比较经典的链路，数仓的数据会放到 Hive 里，以小时级放到 StarRocks，直接透到业务的后台去查询。它几乎涵盖了目前斑马所有的业务场景，包括课程的体验、电商的增长，以及一些辅导的服务等等。上面是猿辅导的一个 B 端的场景，是辅导老师工作台。它的特点是重度依赖于数仓的加工数据，大部分的数据源是由数仓同学先加工好的比较标准的数据，并且指标和维度都是经过明确定义的。 链路中，上面有一部分用到离线数仓的数据，也有一部分用到实时数仓的数据，这些数据还是通过天级、小时级、分钟级的粒度同步到 StarRocks 里。这里用到了 Catalog 做外表，因为对于分区裁剪的性能没有很高要求，数据量不大的情况下，通过 Catalog 外表能够更敏捷、更快速地在业务上使用仓库的数据。 上图中下边这条链路，叫 EtLT 的架构。第一个小 t 的 transform 里面做一些字段的裁剪、数据的过滤等非常轻的数据清洗和同步。把更多的数据计算逻辑放到 StarRocks 的下游，在 SQL 里是通过物化视图方式来做。它可以把业务的数据，主要是 MySQL 的数据，通过 CDC 数据同步到 StarRocks ，把更多的逻辑放到业务的后台。这样做的好处是可以在数据加工上大幅节省人力成本，能够让业务更快地去实验，更快地跑起来。 飞象星球是公司一个比较新的产品线，它是给学校以及政府教育相关部门提供的教育产品，飞象 BI 产品主要是把抽象化的数据通过可视化的报表提供给客户，它也是完全基于StarRocks 的底座来实现的。图中可以看到，除了一些可视化的能力以外，它还支持用户按照表和字段去定义后台的数据源模型，通过 NOSQL 的方式，让大家自己去配置数据看板。 它的链路相对来讲也比较简单，主要是业务 DB，先同步到 Hive 里，再同步到 StarRocks ，最近也在推动 CDC 同步的事情，希望未来能够完全实现从业务 DB 直接到StarRocks 的同步的方式，减少中间的链路。 最后一个案例是比较新的一个链路，它是一个电商场景，做用户支付成功率的监控，帮助电商的同学去做问题的排查。特点是实时性要求比较高，原本的业务 DB 的数据量非常大，业务的 DB 会做一些分库分表的架构，也有一些多表 Join 的需求，所以业务的数据是没有办法直接来做分析的。所以我们把它通过 CDC 的方式同步到 StarRocks 里，统一用 StarRocks 去处理。目前来看跑的效果非常好，由业务的研发同学直接来主导，不需要数据开发同学来介入。 五、基础建设再简单介绍一下我们做的基础建设。 我们有一些平台化的工具，比如统一的元数据、权限管理平台。还有一套 adHoc 平台，帮助用户做数据的分析和数据的提取。 DDL 工单系统，主要是帮用户去做数据的规范和权限的约束。另外，还有基于原生的系统去做监控大盘和告警，基于审计日志去做慢查询的监控，帮助用户持续优化查询性能。 目前正在推进中的工作包括，首先是从 UNIQ 模型去往 PRI 模型演进；第二是希望把 MySQL 到 StarRocks 同步的链路做得更轻、更快，通过一个平台化的工具把这条链路打通，能够实现离线的快照，也能够实现实时的同步；另外，因为整个 StarRocks 的集群非常多，大概有七八个集群，新的业务将会开更多的集群，所以需要有一些跨集群的数据同步的能力。 再来讨论一下自建和上云。如果仅从从机器层面来考虑，那么自建集群的成本是更低的。但如果结合人力和机器成本来看的话，阿里云EMR 则有一些优势。公司本身在大数据上的团队规模不是很大，大家要维护的组件和服务非常多， EMR 就能够提供一个比较好的协助和补充。首先是弹性的能力，当一些业务需要快速地去开一个集群，需要快速地去扩缩容的时候，可以利用到弹性的能力去实现，并且可以随时地去释放；另外，StarRocks 社区迭代非常快，我们在快速跟进和学习的过程中，难免会遇到一些问题，可能没有办法很快地得到社区的反馈，这时与阿里云的团队合作，就能够得到一个比较好的专家支持服务。现在我们是以自建和 EMR 集群混合云的模式，去支撑业务需求。对于一些业务上跑得比较快，尤其是一些 B 端的，隔离性要求非常高的场景，更倾向于在阿里云上直接开 EMR 的集群。 最近也在跟阿里云 EMR 合作去测试 Serverless- StarRocks 的产品。在新的产品形态下面能够提供给用户的，首先是诊断分析的能力，能够帮助用户可视化地去检索到慢 SQL，从而可以对 SQL 进行针对性优化。第二是它能够提供一个比较好的用户管理和权限管理的的能力，提升运维同学的工作效率。另外，也希望借助未来 StarRocks 3.0 以上存储分离的架构，节省更多的成本。 以上就是本次分享的内容，谢谢大家。 EMR Serverless StarRocks 公测： 点此了解详情我们会在钉钉群定期推送精彩文章，邀请技术大牛直播分享。欢迎钉钉扫码加入产品交流群一起参与讨论~
-
发表了文章 2023-05-10
阿里云E-MapReduce产品新动态及开源大数据前沿技术 2023-4月刊
重磅：阿里云智能数据湖入选第六届数字中国建设峰会“十大硬核科技”4月27日，第六届数字中国建设峰会在福建福州举办，阿里云首创并推动的智能数据湖方案因“引领业界技术上创新”入选本届峰会的“十大硬核科技"，这也是历届峰会中首次有数据湖产品入选。阿里云在2019年推出了云原生智能数据湖方案，融合了E-MapReduce、DLF、OSS、Flink、PAI等产品，致力于帮助客户提升单位数据的智能化价值。阿里云智能数据湖打破过多项世界纪录。在CloudSort 100TB竞赛和 TPC-DS 10TB竞赛中，阿里云分别打破世界纪录，TCO成本远低于第二名，降低近100%。在中国信通院的专项评测中，拿下“云原生数据湖基础能力专项评测证书”满分评测，国内第一。2020年至今有上万家客户在阿里云上构建数据湖，覆盖智能汽车、在线教育、互联网广告、新媒体、网络游戏等行业。例如基于智能数据湖方案，小鹏汽车实现了大批量自动驾驶采集数据快速入湖、处理、标注和存储高效对接智能算力，多种模型同步训练。E-MapReduce&DLF产品新进展1、支持控制台可视化管理YARN分区适用客户：EMR全量用户发布功能：EMR支持在控制台上通过可视化UI管理YARN分区，同时可以批量建立节点组与分区的映射，方便操作。您可以直接在节点组上配置分区属性，扩容和弹性伸缩后，EMR会自动为新增节点打上Node Label，无需重新配置新节点。相关文档：https://help.aliyun.com/document_detail/613506.html2、EMR Doctor智能运维系统集群日报计算部分增加任务长尾检测集群日报计算部分数据倾斜诊断到Stage更细粒度的分析集群日报计算部分任务明细增加作业IO和Shuffle信息集群日报存储部分优化内存使用和分析时间实时分析增加Spark任务异常分析相关文档：https://help.aliyun.com/document_detail/442435.htmlEMR产品活动1、阿里云EMR Serverless StarRocks免费公测版发布EMR Serverless StarRocks是由阿里云EMR全新推出的Serverless StarRocks服务，StarRocks是一款高性能分析型数据仓库，使用向量化、MPP 架构、可实时更新的列式存储引擎等技术实现多维、实时、高并发的数据分析。可广泛应用于BI报表分析、OLAP 报表、数据湖分析、实时数据接入及分析等场景。 EMR Serverless StarRocks 相较于开源StarRocks产品特性包括：提供免运维，全托管的StarRocks实例管理服务，提升服务的稳定性，可运维性，降低您的运维成本。 提供可视化，高效率的实例管理，监控告警，配置管理能力。 专业的StarRocks Manager，为StarRocks管理提供便捷的，可视化的元数据管理，诊断与优化，以及用户管理和授权能力。 阿里云 EMR Serverless StarRocks免费公测入口： https://help.aliyun.com/document_detail/608380.html2、阿里云 × StarRocks 云上StarRocks极速湖仓—北京站数据价值是一个老生常谈的话题，随着公司技术和业务的发展，数据的种类愈发繁多，数据分析的需求愈发复杂。当公司经营中产生的数据是海量的，同时数据类型和结构复杂且多元，传统的数据仓库就无法满足分析性能的需求，湖仓一体的技术架构应需而生。为了能够满足更多用户对于极速湖仓分析的需求，StarRocks 2.5 版本进一步增强数据湖能力，在数据源生态、查询速度、使用体验上都做了大量优化。在物化视图构建、刷新机制优化上也取得了新的进展。作为合作伙伴，阿里云积极参与社区建设，深度参与到 StarRocks 数据湖分析能力的打造中。阿里云 EMR StarRocks 产品发布已过去近一年的时间，同时随着 StarRocks 3.0 RC01 版本的面世，双方携手共同举办线下 Meetup。4月19日（周三）下午，水滴筹、猿辅导、阿里云 EMR 团队和 StarRocks 社区的技术专家，针对开源 OLAP 技术架构、 StarRocks 产品硬核技术及 EMR StarRocks 实战经验等一系列超干货内容，为大家带来诚意满满的技术盛宴。视频回放：https://developer.aliyun.com/live/251764最佳技术实践1、水滴筹基于阿里云 EMR StarRocks 实战分享本篇文章由水滴筹大数据部门的数据开发工程师韩园园老师为大家带来水滴筹基于阿里云EMR StarRocks的实战经验分享。文章详情：https://developer.aliyun.com/article/1207836钉钉扫码进群，欢迎咨询与交流前沿开源大数据
-
发表了文章 2023-05-09
水滴筹基于阿里云 EMR StarRocks 实战分享
摘要：水滴筹大数据部门的数据开发工程师韩园园老师为大家分享水滴筹基于阿里云EMR StarRocks的实战经验。本篇内容将会围绕以下五个方面展开：公司介绍StarRocks 概览场景实战最佳实践未来规划点击查看直播回放一、公司介绍水滴创立于2016年，业务包括水滴筹、水滴保险商城等，于2021年5月7日上市。水滴以“用互联网科技助推广大人民群众有保可医，保障亿万家庭”为使命，致力于为用户提供健康保障解决方案。希望联合合作伙伴打造中国版联合健康集团，让用户以更低的费用享受到更好的诊疗。自2016年7月至2022年末，水滴筹平台的捐款人达到了4.3亿，有超过277万的大病患者得到了帮助，总计筹集医疗资金达到569亿元，并提供了755个保险产品。二、StarRocks 概览使用历程首先来梳理一下水滴筹在OLAP方面的发展历程。2018年，引入ClickHouse，主要用于监控报警和用户相关的行为分析工作，包括漏斗、留存等。2020年，引入TiDB，主要用于OLAP分析和报表展示。2021年，针对当时组件的一些痛点，也为了探索更多的OLAP引擎，引入StarRocks v1.17.8（DorisDB）版本，自建StarRocks集群，用于OLAP分析。2022年2月，升级StarRocks集群到v1.19.5版本，用于报表展示。2022年10月，迁移自建StarRocks集群至阿里云EMR StarRocks，并将大数据的TiDB所有的服务迁移到StarRocks上，版本为v2.3.2。2023年3月，参加阿里云EMR Serverless StarRocks集群公测，并将集群新功能尝试应用于新业务中。水滴现状从上表可以看到水滴对各个组件的使用场景，以前以TiDB作为主要组件进行OLAP分析和OLTP，少部分服务使用StarRocks；实时监控、用户行为分析还在ClickHouse中。随着近几年业务的发展、实验的沉淀， OLAP组织架构也存在一些问题，如组件维护困难，数据冗余存储，数据收口和出口不统一等情况。水滴大数据希望引入一款实时OLAP数据库，统一数据的监控和查询，用于解决各业务线对数据高效实时数据查询和数据统计分析的需求。水滴OLAP组件技术选型水滴对OLAP引擎最关注的有四点，分别是：并发能力，物化视图，join能力和写入实时。上表是基于水滴通过近几年的实践得到的结论，可以看出：StarRocks在并发能力、物化视图、join能力和写入实时方面整体都是比较优秀的。ClickHouse的并发能力和join能力相对较弱。TiDB的并发能力和join能力中等，但是不支持物化视图，导致用户体验不是很好。基于几个组件的使用和综合考虑，水滴最后决定将StarRocks作为最终的OLAP引擎，将TiDB的服务迁移到StarRocks中，开始实施组件的统一。三、场景实战概览水滴OLAP整体架构如上图所示。主要分为如下几个部分：数据源、数据同步、OLAP引擎、应用场景和数据管理平台。数据源又分为离线数据和实时数据。离线数据主要存储在MaxCompute，通过BrokerLoad、SparkLoad两种同步方式，同步到StarRocks中，时效性是T+1或者小时级别。实时数据主要是一些业务和埋点数据，存储在MySQL、TiDB和Kafka中，通过Flink-CDC、Flink-SQL以及自研Galaxy平台进行实时同步。数据进入OLAP引擎后，水滴主要用到三种表模型，分别是：明细模型，聚合模型和主键模型。明细模型用于存储明细数据和业务统计完成之后的数据。聚合模型用于存储根据业务场景预聚合的数据。主键模型用于存储业务的实时数据。数据模型主要用到宽表、星型模型和雪花模型三种。数据管理平台主要包括：元数据管理，稳定性保障，质量管理，以及数据安全。目前水滴的集群规模为，包含3台FE和7台BE，每日查询量300万次。数据写入方面，有1500多个离线任务，每日实时更新行数100万行以上，每日写入数据量1T以上。下面以两个具体的场景为例来介绍水滴的StarRocks实战。场景一：报表平台OLAP引擎统一第一个场景是报表平台OLAP引擎统一。水滴报表平台之前主要使用TiDB作为存储和查询引擎，后来又引入了StarRocks，由多个组件构成了我们的OLAP引擎。这样的架构存在如下三个痛点：组件多，维护不便；成本高；TiDB的并发限制和慢SQL的问题，导致客户体验不佳。报表查询面对三大挑战：查询高并发响应低延迟大数据量多表Join在水滴报表平台之前的流程中，无论是离线数据还是实时数据，都会写入到TiDB和StarRocks中，然后提供报表平台或者业务系统进行使用。经过一段时间的测试和使用，评估StarRocks可以作为水滴报表平台的主要引擎，后续会将TiDB迁移到StarRocks中。切换之前，水滴对两个平台做了压测对比。上图中，左边是两个集群的详细参数。首先将TiDB的所有数据同步到StarRocks中，保证压测的数据是完全一致的；然后，使用报表平台的所有SQL查询，在相同数据、相同SQL、相同并发的情况下，同时在TiDB和StarRocks中循环遍历执行这些SQL，经过一段时间的测试，基于水滴的使用场景和水滴数据针对两个引擎的查询性能得到了如下的结论，下面以TiDB中SQL的响应时间分成三部分进行对比，因为大部分响应时间都在这三个分段内：在TiDB中，执行时间在400ms以内的SQL在StarRocks中执行时间为200ms以内在TiDB中，执行时间在400ms到1.5s的SQL在StarRocks中执行时间在184ms到300ms以内在TiDB中，执行时间在1.5s到4s的SQL在StarRocks中执行时间为198ms到500ms以内水滴大数据部门经过架构优化后，统一了OLAP引擎为StarRocks，将离线和实时数据写到StarRocks之中，提供给业务系统以及报表平台使用。新架构的优点是结构比较清晰，也维护了统一的数据口径。上图从三方面展示了架构迁移后的效果：通过将TiDB迁移到StarRocks，实现了组件统一，系统的运营成本得到了一定程度的降低。平台整体成本降低了58%，整体性能提升了40%。观测TiDB和StarRocks响应时间的tp99，可以看到TiDB响应时间的tp99在3秒左右，而StarRocks响应时间的tp99基本是几百毫秒，在1秒以内。数据离线同步耗时以及慢SQL，StarRocks都有一定程度的提升。在迁移StarRocks的过程中也遇到一些问题：StarRocks的DDL和DML与TiDB/MySQL相比虽然兼容90%场景，还是存在一些不兼容问题，上表中列举了一些不兼容的情况以及相应的解决方案。数据没办法直接从MaxCompute同步到StarRocks，必须中间有一层OSS的中转。场景二：数据服务遇到问题场景二是公司的财务推帐系统。财务推帐系统使用TiDB作为数据存储查询引擎，面临的核心挑战是：数据实时性要求高；数据一致性要求高；数据的计算逻辑复杂；数据分析需求灵活。财务推帐系统所需的数据涉及多张表，每张标的数据量都是上亿级别，推帐需要多张上亿级别的表相互Join才能实现。因为TiDB的并发和内存的限制，目前没办法对这些表多表关联直接聚合处理，所以水滴先根据ID进行分段聚合，然后通过代码的聚合方式，写到中间表中。因为推帐是分场景的，处理时间最长的场景需要30分钟的时间，所有300多个场景并发处理，最终也需要4-5小时的时间。对财务同学的工作效率，有一定的影响。改造之后的流程为：数据首先实时写入TiDB中，然后从TiDB实时写入StarRocks中，因为中间聚合的数据进行反推，因此需要先进行快照数据留存后，StarRocks中的数据可以直接分场景聚合处理，单场景的最大耗时为30秒左右。架构升级后，性能直接提升60倍，TiDB只参与存储不再参与计算，其引擎压力降低了70%，但是由于数据同时留存在TiDB和StarRocks中，存储成本有一定程度的增加。四、最佳实践表设计方面绝大部分表都按照时间字段进行了分区，使用常用的查询列以及关联的关键列作为分桶；将经常过滤和group by的列作为排序键，优先使用整型作为排序键；对于明细数据，由于数据量比较大，用动态分区做数据过期的设置；建表时尽量使用精确的字段类型，例如：数字类型数据不用字符串类型，INT能满足的不用BIGINT，知道字符串长度范围的数据不用String类型；数字列尽量放到字符串的列之前。数据同步方面离线写入主要用的是BrokerLoad和SparkLoad两种同步方式；实时写入采用Flink-CDC和自研Galaxy平台同步方式；实时写入需要控制数据写入的频率，降低后台合并的频率，保证程序稳定和数据的一致性；使用UniqueKey的replace_if_not_null对部分列进行更新，PrimaryKey直接支持部分列更新。运维和监控方面对FE进行四层的负载均衡，保证查询请求的高可用，同时也保证查询请求的负载均衡；优化集群参数，来提高集群的查询性能：提高StarRocks的查询并发(parallel_fragment_exec_instance_num)提高单个查询内存限制(exec_mem_limit)使用Prometheus+Grafana进行集群监控告警；对查询历史进行分析，统计和监控慢SQL、大SQL，及时告警和优化。权限与资源方面细分账户，避免混用，实现更好的监控和维护，方便将大SQL、慢SQL准确定位用户；根据业务和实际使用场景来划分资源组，对查询进行资源隔离，保证业务之间不互相影响；DDL操作权限收敛到统一平台，增加数据的安全和集中控制。数据管理与质量方面根据查询记录定期分析使用情况，做好表生命周期管理；离线同步数据T+1进行数据质量校验；实时同步小时和天级别进行数据质量校验。当前问题业务需要但是目前没有支持AUTO_INCREMENT和CURRENT_TIMESTAMP；String类型的数据长度有限制，对于某些长度较大的字段智能过滤或者无法适用；现有日志格式对于错误日志分析不是很友好;实时数据的写入频率不好把控，写入太快会造成版本合并的问题，写入太慢又有数据延迟问题；时间字段不支持毫秒；CPU无法完全隔离；表权限目前还不能控制到行级别。五、未来规划水滴大数据部门的未来规划主要从三方面入手，分别是用户画像、监控报警和用户行为分析。用户画像当前组件：HBase+ES业务场景：消息推送、用户圈选场景特点：更新频繁，每天20-30亿的数据更新量，数据量大，列动态更新当前痛点：因为业务主要通过ES进行用户圈选，查询效率比较低，无法实现多表Join；切换难点：如果要切换StarRocks，重点考虑的问题是，一张1000亿+的列，14亿数据的大宽表，需要频繁动态更新列，平台是否能够支持。监控报警当前组件：埋点上报+ClickHouse业务场景：实时监控场景特点：实时性要求高，查询可物化当前痛点：并发收到受限，读会影响数据写入切换难点：切换到StarRocks的难点在于，监控需要分钟级或者更短的时间，对数据的准实时性要求高用户行为分析当前组件：ClickHouse业务场景：漏斗，留存，路径分析场景特点：数据量大，单表1000亿+数据，每天增量数亿；查询周期长，用户需要查一个月、三个月、半年以上的数据；大表join，需要将用户行为表与用户画像进行关联分析，实现数据的圈选或者查询操作当前痛点：两个以上的大表join性能不佳切换难点：切换到StarRocks的难点在于，当前系统使用了大量的ClickHouse内置窗口函数和数组函数，在StarRocks对应的替代函数的准确率和适配度等有待验证。水滴大数据部门对2023年StarRocks相关的计划包括：2023年上半年，将更多业务场景接入StarRocks中，实现更全面的权限控制和资源隔离；2023年7月，升级StarRocks到2.5以上版本，使用嵌套物化视图探索更多业务场景，将StarRocks应用于数据画像，尝试替代ES；2023年10月，将埋点数据和Binlog数据实时写入StarRocks中，探索StarRocks在漏斗、留存、行为分析场景的使用，尝试替代ClickHouse；2023年底，水滴大数据部门的规划目标是实现OLAP引擎统一，探索更多新功能、新场景。六、致谢在分享的最后，感谢阿里云StarRocks团队对我们的技术支持，使得我们更快更好地将StarRocks应用于各种场景中。水滴也会跟紧社区的步伐，更好地解决场景需求。最后祝阿里云StarRocks发展得越来越好。EMR Serverless StarRocks 正式公测： 了解详情我们会在钉钉群定期推送精彩文章，邀请技术大牛直播分享。欢迎钉钉扫码加入产品交流群一起参与讨论~
-
发表了文章 2023-05-04
阿里云智能数据湖入选第六届数字中国建设峰会“十大硬核科技”
4月27日，第六届数字中国建设峰会在福建福州举办，阿里云首创并推动的智能数据湖解决方案因“引领业界技术上创新”入选本届峰会的“十大硬核科技”，这也是历届峰会中首次有数据湖产品入选。本届数字中国峰会以“加快数字中国建设，推进中国式现代化”为主题，设置了“1+3+N”等系列活动。其中“十大硬核科技”奖项，聚焦高端芯片、操作系统、人工智能关键算法、传感器等技术领域，推动关键基础技术的创新应用，让人触摸科技力量，充分感受数字中国强劲的时代脉动。峰会颁奖评语写到：智能数据湖是阿里云在大数据和AI融合的时代背景下推出，底层融合存储和计算全新技术体系，业务侧融合多元计算，对接数据科学计算引擎。支撑在线教育、互联网广告、新媒体、网络游戏等近万家行业用户在快速发展过程中的业务需求，为企业数字化转型提供源动力。据悉，阿里云是智能数据湖发展的推动者，在技术上引领业界创新，基于阿里云自研的盘古存储引擎搭建底座，百节点扩容只需2分钟，故障节点智能自动补偿；支持毫秒级原子10亿级目录重命名，AI场景可以降低95%计算等待时间，大幅提升训练效率；最高可降低数据湖存储成本降低95%，湖计算性能提升3倍以上。随着新一波人工智能技术浪潮来袭，将机器学习、深度学习、NLP自然语言处理等AI关键技术与大数据技术深度融合能为各行各业提供更精准的决策，智能数据湖因此而生。阿里云在2019年推出了云原生智能数据湖方案，融合了E-MapReduce、OSS、Flink、PAI等产品，致力于帮助客户提升单位数据的智能化价值。据悉，阿里云智能数据湖拥有全球领先的技术实力，打破过多项世界纪录。在CloudSort 100TB竞赛和 TPC-DS 10TB竞赛中，阿里云分别打破世界纪录，TCO成本远低于第二名，降低近100%。在中国信通院的专项评测中，拿下“云原生数据湖基础能力专项评测证书”满分评测，国内第一。据悉，2020年至今有上万家客户在阿里云上构建数据湖，覆盖智能汽车、在线教育、互联网广告、新媒体、网络游戏等行业。例如基于智能数据湖方案，小鹏汽车实现了大批量自动驾驶采集数据快速入湖、处理、标注和存储高效对接智能算力，多种模型同步训练。未来，阿里云希望与伙伴一起，将云原生智能数据湖渗透到各行各业，推动更多企业实现数字创新。欢迎钉钉扫码加入数据湖交流群一起参与讨论~
-
发表了文章 2023-04-12
免费公测｜阿里云EMR Serverless StarRocks 公测正式开启！
EMR Serverless StarRocks 免费公测：点击体验《云上StarRocks极速湖仓Meetup》邀请到水滴筹、猿辅导、阿里云 EMR 团队和 StarRocks 社区的技术专家，针对开源 OLAP 技术架构、 StarRocks 产品硬核技术及 EMR StarRocks 实战经验 等一系列超干货内容进行分享。：点击观看视频让算力更普惠，让 AI 更普及！未来十年，阿里云将全面拥抱智能化时代。随着 Serverless 化逐渐成为全新的软件研发范式，阿里云正坚定推进核心产品全面 Serverless 化。其中，开源大数据产品 阿里云E-MapReduce 率先推出 EMR Serverless StarRocks 服务。StarRocks 是一款高性能分析型数据仓库，使用向量化、MPP 架构、可实时更新的列式存储引擎等技术实现多维、实时、高并发的数据分析。可广泛应用于BI报表分析、OLAP 报表、数据湖分析、实时数据接入及分析等场景。EMR Serverless StarRocks 相较于开源 StarRocks 产品特性包括： 提供免运维，全托管的StarRocks实例管理服务，提升服务的稳定性，可运维性，降低您的运维成本。提供可视化，高效率的实例管理，监控告警，配置管理能力。专业的StarRocks Manager，为StarRocks管理提供便捷的，可视化的元数据管理，诊断与优化，以及用户管理和授权能力。 EMR Serverless StarRocks 开启公测EMR Serverless StarRocks 已于2023年4月10日开启，预计于2023年05月31日结束。公测面向所有用户开放，可以直接通过EMR控制台创建入门版实例，进行测试。立即体验 ->公测说明公测期间您可以免费试用StarRocks服务，免费试用结束后，您可以续费或释放实例。* E-MapReduce Serverless StarRocks实例创建时，依赖ASCM和CLB产品，开通实例会额外产生少量ASCM和CLB费用。 公测期间，您可以创建实例系列为入门版的实例，如果您需要更高规格，需要单独申请，请参见如何申请使用标准版。公测期间不保障服务等级协议SLA，但服务不降级。如果遇到任何疑问，可加入钉钉群24010016636咨询。操作流程公测面向所有用户开放入门版实例，您可以参见以下文档快速使用EMR Serverless StarRocks实例。快速使用EMR Serverless StarRocks快速使用EMR StarRocks Manager如何申请使用标准版目前针对大部分客户免费提供入门版，如果您的业务场景需要使用更高规格的标准版，可以联系我们单独评估，申请流程如下：填写阿里云 E-MapReduce Serverless StarRocks 公测标准版申请。加入钉钉群24010016636，联系EMR团队进行业务评估，评估合理后添加白名单。开通白名单后，您可以在E-MapReduce控制台创建EMR Serverless StarRocks 标准版实例。
-
发表了文章 2023-04-10
北京 Meetup 邀你来｜阿里云 × StarRocks 云上StarRocks极速湖仓
时间：4月19日 13：30-17：30地点：北京市朝阳区曙光西里甲5号院18号 动境COFFICE立即报名->数据价值是一个老生常谈的话题，随着公司技术和业务的发展，数据的种类愈发繁多，数据分析的需求愈发复杂。当公司经营中产生的数据是海量的，同时数据类型和结构复杂且多元，传统的数据仓库就无法满足分析性能的需求，湖仓一体的技术架构应需而生。为了能够满足更多用户对于极速湖仓分析的需求，StarRocks 2.5 版本进一步增强数据湖能力，在数据源生态、查询速度、使用体验上都做了大量优化。在物化视图构建、刷新机制优化上也取得了新的进展。作为合作伙伴，阿里云积极参与社区建设，深度参与到 StarRocks 数据湖分析能力的打造中（可浏览本篇文章 阿里云EMR StarRocks 极速数据湖分析 ）。阿里云 EMR StarRocks 产品发布已过去近一年的时间，同时随着 StarRocks 3.0 RC01 版本的面世，双方携手共同举办线下 Meetup。4月19日（周三）下午，水滴筹、猿辅导、阿里云 EMR 团队和 StarRocks 社区的技术专家，将针对开源 OLAP 技术架构、 StarRocks 产品硬核技术及 EMR StarRocks 实战经验等一系列超干货内容，为大家带来诚意满满的技术盛宴，分享内容详见下方海报。立即报名->
-
发表了文章 2023-04-04
阿里云E-MapReduce产品新动态及开源大数据前沿技术 2023-3月刊
E-MapReduce & DLF 产品新进展一、EMR&DLF 新平台功能发布1、EMR 发布 Spark Native EngineEMR 发布 Spark Native Engine 对外公测版（EMR-3.45.1和EMR-5.11.1），Spark3 服务可一键开启 Native Engine，支持 SparkSQL、DataFrame 和 PySpark 等应用程序，在标准化测试集 TPC-DS 中， Spark Native Engine 相对于 Java Engine 可提升30%以上。2、支持默认创建存算分离集群适用客户：希望使用存算分离集群的客户。发布功能：创建集群时，可以选择 Hive 存储模式和 Hive 数据仓库路径。相关文档：https://help.aliyun.com/document_detail/343457.html3、按负载弹性伸缩规则支持设置多指标触发条件适用客户：希望使用EMR弹性伸缩功能的客户发布功能：用户配置按负载弹性伸缩规则时，可以选择多个系统定义的负载指标。通过多个负载指标衡量集群负载情况，可以降低节点数量变化频率，增加硬件资源利用率。相关文档：https://help.aliyun.com/document_detail/445658.htm4、数据湖构建（DLF）生命周期支持 OSS-HDFS适用客户：使用 OSS-HDFS 作为大数据存储，有自动存储降本等需求。通过生命周期管理对数据湖中的数据库、数据表配置数据管理规则，对数据定期进行存储类型转换，从而节省数据存储成本。发布功能：数据湖构建（DLF）生命周期支持OSS-HDFS相关文档：https://help.aliyun.com/document_detail/426233.html5、数据湖构建（DLF）增加Flink入湖、EMR统一权限最佳实践适用客户：所有DLF用户发布功能：数据湖构建（DLF）增加Flink入湖、EMR统一权限最佳实践。相关文档：Flink VVP+DLF数据入湖与分析实践https://help.aliyun.com/document_detail/477803.html DLF+EMR之统一权限最佳实践https://help.aliyun.com/document_detail/479417.html 二、E-MapReduce&DLF国际站1、数据湖构建（DLF）支持印尼Region适用客户：国际站印尼客户发布功能：数据湖构建（DLF）产品在印尼正式发布上线。三、EMR Doctor 智能运维系统1、EMR Doctor 新增三处地域发布适用客户：所有 EMR Doctor 用户发布功能：EMR Doctor 产品在印尼Region、张家口Region，弗吉尼亚 Region正式发布上线。 E-MapReduce 产品活动1、阿里云 E-MapReduce Serverless StarRocks 开启全面公测EMR Serverless StarRocks 是由阿里云EMR全新推出的 Serverless StarRocks 服务，StarRocks 是一款高性能分析型数据仓库，使用向量化、MPP 架构、可实时更新的列式存储引擎等技术实现多维、实时、高并发的数据分析。可广泛应用于BI报表分析、OLAP 报表、数据湖分析、实时数据接入及分析等场景。 EMR Serverless StarRocks 相较于开源 StarRocks 产品特性包括：提供免运维，全托管的 StarRocks 实例管理服务，提升服务的稳定性，可运维性，降低您的运维成本。 提供可视化，高效率的实例管理，监控告警，配置管理能力。 专业的 StarRocks Manager，为 StarRocks 管理提供便捷的，可视化的元数据管理，诊断与优化，以及用户管理和授权能力。 阿里云 EMR Serverless StarRocks 公测入口： https://help.aliyun.com/document_detail/475867.htm最佳技术实践1、阿里云EMR 2.0：定义下一代云原生智能数据湖本次分享主要介绍了阿里云云原生数据湖分析解决方案的三个核心要素：全托管，湖存储；一站式，湖管理；多模态，湖计算。文章详情：https://developer.aliyun.com/article/11740632、基于阿里云 CloudMonitor云监控自定义监控大盘对 EMR 自定义监控实践本文旨在分享 EMR 平台大数据服务基于阿里云 CloudMonitor 的监控实践，给客户提供除了 EMR 平台默认监控以外，自建监控方式，适用于统一多个阿里云服务的监控监控场景。文章详情：https://developer.aliyun.com/article/11747793、数据湖存储的安全写入之道本文以 Hadoop 社区中的 S3A Connector 的实现为切入，分析了数据湖写入路径的安全性。文章详情：https://developer.aliyun.com/article/11753394、通过云监控CloudMonitor实时捕获EMR集群的状态变化通过结合CloudMonitor以及FC，可以实时捕获EMR集群的生命周期变化，如集群的创建和停止，扩容和缩容以及其他类型的集群状态变更等。文章详情：https://developer.aliyun.com/article/11797965、阿里云EMR自定义日志投递与使用实践分享 EMR目前支持了日志管理，即日志客户SLS投递的功能，基于此功能，客户可以将需要的各种大数据组件日志收集到自身SLS中，做查询和分析。基于此功能，客户可以自定义日志路径、规则，对集群设备上的日志自行接收和消费。本文以采集指标文件为例，帮助您快速上手自定义日志投递与使用。文章详情：https://developer.aliyun.com/article/1181210钉钉扫码进群，欢迎咨询与交流前沿开源大数据
-
发表了文章 2023-03-28
阿里云EMR自定义日志投递与使用实践分享
作者：锦琛@阿里云引言开源大数据平台 E-MapReduce（简称“EMR”）是云原生开源大数据平台，向客户提供简单易集成的Hadoop、Hive、Spark、Flink、Presto、ClickHouse、StarRocks、Delta、Hudi等开源大数据计算和存储引擎。EMR目前支持了日志管理，即日志客户SLS投递的功能，基于此功能，客户可以将需要的各种大数据组件日志收集到自身SLS中，做查询和分析。基于此功能，客户可以自定义日志路径、规则，对集群设备上的日志自行接收和消费。本文以采集指标文件为例，帮助您快速上手自定义日志投递与使用。关键字E-MapReduce，日志管理，日志投递，日志消费前提条件已有阿里云EMR集群，且已开启日志查询功能。更多信息，请参见管理日志。步骤1：配置采集登陆E-MapReduce服务控制台。选择前往日志服务控制台，点击右上角前往日志服务控制台。创建日志库，选择合适的数据保存时间。在新建日志库下点开logtail配置，选择json文件日志。若开启日志投递，会看到已有的机器组，应用该机器组。配置Logtail设置日志路径/mnt/disk1/log/taihao_exporter/**/metrics.log*然后点击下一步至完成。索引配置(可选)也可以配置索引方便对其做搜索，如图所示自动生成索引。步骤2：查询指标配置完毕后，就可以在sls上看到指标了。您可以在Logstore的查询和分析页面，输入查询语句，选择时间范围，单击查找/分析，进行日志查询操作。查询指标名为yarn_nodemanager_jvm_GcTimeMillis的值。* and name: yarn_nodemanager_jvm_GcTimeMillis查询指标名为yarn_nodemanager_jvm_GcTimeMillis且value>200的值。* and name: yarn_nodemanager_jvm_GcTimeMillis and value > 200查询header节点的yarn_timelineserver_jvm_GcTimeMillis指标。* and hostname: "emr-header-1.cluster-500202362" and name: yarn_timelineserver_jvm_GcTimeMillis 步骤3：分析日志您可以在Logstore的查询和分析页面，输入查询和分析语句，选择时间范围，单击查找/分析，进行日志分析操作。统计不同指标的数量。* | SELECT "name", COUNT(*) AS PV GROUP BY "name"计算不同时刻对应的指标数量，并按照时刻进行升序排序。* | SELECT "timestamp", COUNT(*) AS count GROUP BY "timestamp" ORDER BY "timestamp"参考信息：日志样例钉钉扫码进群，了解更多详情
-
发表了文章 2023-03-23
通过云监控CloudMonitor实时捕获EMR集群的状态变化
作者：锦琛@阿里云引言开源大数据平台 E-MapReduce（简称“EMR”）是云原生开源大数据平台，向客户提供简单易集成的Hadoop、Hive、Spark、Flink、Presto、ClickHouse、StarRocks、Delta、Hudi等开源大数据计算和存储引擎。云监控（简称“CloudMonitor”）是一项针对阿里云资源和互联网应用进行监控的服务，为云上用户提供开箱即用的企业级开放型一站式监控解决方案。函数计算（简称“FC”）是事件驱动的全托管计算服务。使用函数计算，您无需采购与管理服务器等基础设施，只需编写并上传代码或镜像。函数计算为您准备好计算资源，弹性地、可靠地运行任务，并提供日志查询、性能监控和报警等功能。通过结合CloudMonitor以及FC，可以实时捕获EMR集群的生命周期变化，如集群的创建和停止，扩容和缩容以及其他类型的集群状态变更等。本文演示如何捕获EMR集群状态变更（我们以杭州区域为例）并发送到当前常用的“钉钉”手机客户端，其他服务场景请酌情参考。关键字E-MapReduce，CloudMonitor，函数计算，事件通知，钉钉处理流程这是我们设计的EMR实时状态在各个产品之间传递链路图，从图上可以看出，当EMR发生状态变更时（如启动集群，停止集群，创建节点组，对节点组进行扩缩容操作等）系统会产生事件，事件消息送到CMS后会触发告警，CMS支持函数计算FC，告警触发后会触发我们准备好的FC函数，从而解析JSON格式的消息内容并发送给“钉钉”手机客户端（客户也可以基于公司内部的聊天工具进行集成，或者定义下一步的操作，从而实现基于事件的自动化告警处理和运维等，关于这一块，本文章暂不做延展说明）。钉钉配置配置钉钉群机器人必须使用电脑版的钉钉，登录电脑版钉钉创建钉钉群（此过程略，例如创建后的群名为!!!APM告警），然后点击群右上角的“设置”，然后点击“智能群助手”，如下图所示：然后选择“添加机器人”，如下图所示：添加关键字“E-MapR”，其他关键字可自行添加，如下图所示：在接下来的页面中会出现一个Webhook调用的URL，点击“复制”，类似如下https://oapi.dingtalk.com/robot/send?access_token=aabbccdd后面我们设置环境变量的时候将用到这一串aabbccdd函数计算配置打开函数计算FC的控制台（点击这里）,选择左侧菜单的“服务与函数”，然后在右边的窗口中选择“创建服务”，如下图所示：创建后点击进入服务，随后点击右侧窗口“创建函数”，如下图所示：选择“通过zip包上传代码”，其中代码的详细地址如下（也可以手工下载此文件，然后从本地上传）：https://emr.oss-cn-hangzhou.aliyuncs.com/best_practice/cms/function_ding.zip上传后，在代码TOKEN处填写创建的钉钉机器人token，如下图所示：保存后点击部署代码，如果没有报错，表示部署成功。云监控配置打开云监控的控制台（点击这里）,选择左侧菜单的“系统事件”，然后在右边的窗口中选择“创建报警规则”，如下图所示：弹出创建窗口后，在产品类型处填写“E-MapReduce”，事件名称填写“节点组扩缩容成功、集群创建成功、集群释放成功、节点组升配成功”为例，资源范围选择“全部资源”(也可以选择应用分组选择您想要监控的集群id)，选择函数计算并选择之前配置的服务和函数名，如下图所示：点击确认后，完成配置，并确保规则生效，如图所示：测试验证打开EMR的控制台（点击这里），部署一个DataLake的EMR集群即可（过程略）。正确返回因为订阅了创建事件，我们的手机客户端就可以收到类似如下的消息提醒（集群状态 STARTING-> RUNNING），如下图所示：错误诊断如果启动集群过程中并没有收到对应的提醒，请首先确认对应的环境，查看函数计算中函数调用日志有没有错误，如下图所示：扩展经过上面的文档指引和动手实验，我们基于EMR集群的生命周期管理（如集群创建，停止，集群扩缩，缩容等）都会有对应提醒，其实只需要修改文件“function_ding.zip”里面对应的解析的JSON文件的内容，这个流程可以复制到别的场景，例如ECS的相关操作。除了钉钉告警之外，还有更多的用法，比如将数据写入oss，写入数据库等等，期待您的使用。钉钉扫码进群，了解更多详情
-
发表了文章 2023-03-09
数据湖存储的安全写入之道
作者：焱冰@阿里云焱冰背景数据湖的兴起，给数据存储带来了一轮新的革命。越来越多的公司选择将存储切换到云上对象存储。因为云上对象存储往往意味着大容量、低成本、易扩容。说到对象存储，必然涉及到 S3 协议，S3 协议已经事实上成为对象存储的通用协议。不过，市面上不少数据平台公司，也会选择基于 S3 协议又兼顾 Hadoop 使用习惯的 S3A Connector，比如 Databricks 在对象存储上提供的表数据结构 Delta Lake。我们就以 Hadoop 社区中的 S3A Connector 的实现为切入，来分析一下数据湖写入路径的安全性。Hadoop S3 的写入支持因为 S3 协议本身不支持增量写入，因此 S3A 实现时默认的写入方式是先通过缓存到本地，最后在文件 close 后再上传到对象存储。但是，这种默认的方式并不一定高效，对大文件来说，在 close 被调用前，本地已经缓存大量的数据，这样会造成 close 操作非常耗时，文件写入整体看也不高效。从 Hadoop 2.8.5 版本开始，可以通过设置 fs.s3a.fast.upload 为 true，打开快速上传来优化写入路径。打开后，可以边写本地缓存块，边将满足大小的块异步上传（默认 100M 一个块）。这样也满足了对象存储中分阶段上传接口的一些限制，比如单个块不能小于 5M，分块总数不能大于 10000。通过阅读 Hadoop 2.8.5 相关源码，我们可以发现打开 fs.s3a.fast.upload 后，S3AFileSystem 在创建文件时会打开 S3ABlockOutputStream（Hadoop 3.x 也有类似的 S3AFastOutputStream）随后，S3ABlockOutputStream 在处理 write、flush 等操作时，则会调用一个抽象的 S3ADataBlock 来执行。而 S3ADataBlock 则可由三种工厂方法来创建，分别创建基于堆内存的 ArrayBlock、基于磁盘的 DiskBlock，或者基于堆外内存的 ByteBufferBlock。选择哪种工厂，由 fs.s3a.fast.upload.buffer 这个配置项控制，默认为磁盘（disk）。其他两种可选配置为堆内存（array）和 堆外内存（bytebuffer）。磁盘的问题通过了解 Hadoop 社区中 S3A 的实现，我们发现借助磁盘缓存数据是常见甚至默认的行为。因为这样可以减少内存占用，缓存更多的数据。但是，这样也带来了磁盘本身的阿喀琉斯之踵 -- 磁盘的稳定性问题。在数据存储领域，磁盘的问题往往非常令人头疼。比如磁盘写满，磁盘坏道问题，还有偶现的磁盘数据比特反转导致的数据安全性问题。哪怕单块磁盘的可靠性非常高，但由于磁盘出现问题的概率会随着磁盘数的提升而变大，这会使数据安全性蒙上一层阴影。对于R个副本的情况，设磁盘的年故障率为P，磁盘数为N，则整个机群有C ( N, R ) = N! / ( R! * ( N- R )! ) 种 R 副本的组合方式。机群数据总量为 M，分片大小为 T，那么有 R 个磁盘同时损坏造成数据丢失的概率是：* 引用于《磁盘故障与存储系统的年失效率估算》因此，要保证写路径的数据安全型，我们不能完全依赖底层存储介质的保证。仍需要我们在数据写入时就做一些努力。我们先来做一些实验来看看 S3AFileSystem 在这些问题上的表现。模拟磁盘 IO 问题修改 core-sites.xml 中的 fs.s3a.buffer.dir 指向 /dev/vdc 所在的路径，比如我机器上的 /data2/ <property> <name>fs.s3a.fast.upload</name> <value>true</value> </property> <property> <!-- 本地 buffer 缓存目录，不存在会创建 --> <name>fs.s3a.buffer.dir</name> <value>/data2/tmp/</value> </property>创建并运行 stap 脚本，对所有在 /dev/vdc 上写操作的返回 IO Error#!/usr/bin/stap probe vfs.write.return { if (devname == "vdc") { $return = -5 } } $ stap -g io_errno.stp执行写入程序 demo，验证 stap 脚本有效$ dd if=/dev/zero of=test-1G-stap bs=1G count=1 $ hadoop fs -put test-1G s3a://<your-bucket>/返回结果：put: 输入/输出错误可以发现相关操作能正确抛出 IO 错误。模拟磁盘比特反转魔改 libfuse passthrough 中的 write 方法，并将 /data2/ 通过 fuse 挂载到 /mnt/passthrough$ mkdir -p /mnt/passthrough/ $ ./passthrough /mnt/passthrough/ -omodules=subdir -osubdir=/data2/ -oauto_unmount修改 core-sites.xml 中的 hadoop.tmp.dir 指向 /mnt/passthrough<property> <name>fs.s3a.fast.upload</name> <value>true</value> </property> <property> <!-- 本地 buffer 缓存目录，不存在会创建 --> <name>fs.s3a.buffer.dir</name> <value>/mnt/passthrough/</value> </property>执行写入程序 demo，验证上传内容的正确性。$ mkdir -p input output $ dd if=/dev/zero of=input/test-1G-fuse bs=1G count=1 $ hadoop fs -put input/test-1G-fuse s3a://<your-bucket>/ $ hadoop fs -get s3a://<your-bucket>/test-1G-fuse output/ $ md5sum input/test-1G-fuse output/test-1G-fuse返回结果：cd573cfaace07e7949bc0c46028904ff input/test-1G-fuse 37eb6e664e706ea48281acbd4676569e output/test-1G-fuse可以发现，输入和输出的数据并不一致。综上，通过 Hadoop S3AFileSystem 写入可以发现磁盘 IO 问题并正确抛出异常，但无法发现磁盘比特反转问题。网络的问题既然磁盘写入有问题，那我们使用内存写入是否就一定可以避免踩坑呢？答案是不能，还可能有网络问题。Amazon S3 在 2008 年就曾因为网络问题导致的比特位反转引发过重大事故。后来，大家分析这种问题多发生于两端间隔多个路由器的情况，路由器可能因为硬件/内存故障导致单/多比特位反转或双字节交换，这种反转如果发生在 payload 区，则无法通过链路层、网络层、传输层的 checksum 检查出来。因此 Amazon S3 在这次事故中吸取的教训是，要通过在应用层给所有东西都添加 checksum 来保证数据正确性。让我们来做一个实验，来看看 S3 是怎么做到 Checksum all of the things的，又是否能防止网络比特反转或者网络丢包呢？模拟网络比特反转安装 mitmproxy$ pip3 install mitmproxy $ mitmproxy --version Mitmproxy: 5.3.0 Python: 3.6.8 OpenSSL: OpenSSL 1.1.1h 22 Sep 2020 Platform: Linux-3.10.0-1160.71.1.el7.x86_64-x86_64-with-centos-7.9.2009-Core利用 mitmdump 反向代理 s3a endpoint，并篡改其中的写请求。编写 addons.pyfrom mitmproxy import ctx, http import json import time import os class HookOssRequest: def request(self, flow: http.HTTPFlow): print("") print("="*50) print("FOR: " + flow.request.url) print(flow.request.method + " " + flow.request.path + " " + flow.request.http_version) print("-"*50 + "request headers:") for k, v in flow.request.headers.items(): print("%-20s: %s" % (k.upper(), v)) if flow.request.host == "<your-bucket>.oss-cn-shanghai-internal.aliyuncs.com" and flow.request.method == "PUT": clen = len(flow.request.content) rbit = ord('a') clist = list(flow.request.content) origin = clist[clen - 1] clist[clen - 1] = rbit updated = clist[clen - 1] flow.request.content = bytes(clist) ctx.log.info("updated requesting content pos(" + str(clen - 1) + ") from " + str(chr(origin)) + " to " + str(chr(updated))) def response(self, flow: http.HTTPFlow): pass addons = [ HookOssRequest() ]反向代理 http://.oss-cn-shanghai-internal.aliyuncs.com 到 http://localhost:8765$ mitmdump -s addons.py -p 8765 --set block_global=false --mode reverse:http://<your-bucket>.oss-cn-shanghai-internal.aliyuncs.com修改 core-sites.xml 中的 fs.s3a.endpoint 指向 localhost:8765，并关闭ssl。<property> <name>fs.s3a.connection.ssl.enabled</name> <value>false</value> </property> <property> <name>fs.s3a.fast.upload</name> <value>true</value> </property>执行写入程序 demo，验证上传内容的正确性$ mkdir -p input output $ dd if=/dev/zero of=input/test-100M-proxy bs=$(( 100*1024*1024 + 1 )) count=1 $ hadoop fs -put input/test-100M-proxy s3a://<your-bucket>/返回结果：xx/xx/xx xx:xx:xx WARN s3a.S3ABlockOutputStream: Transfer failure of block FileBlock{index=2, destFile=/data/hadoop/hadoop-2.8.5/tmp/s3a/s3ablock-0002-6832685202941984333.tmp, state=Upload, dataSize=1, limit=104857600} xx/xx/xx xx:xx:xx WARN s3a.S3ABlockOutputStream: Transfer failure of block FileBlock{index=1, destFile=/data/hadoop/hadoop-2.8.5/tmp/s3a/s3ablock-0001-635596269039598032.tmp, state=Closed, dataSize=104857600, limit=104857600} put: Multi-part upload with id '14ABE04E57114D0D9D8DBCFE4CB9366E' to test-100M-proxy._COPYING_ on test-100M-proxy._COPYING_: com.amazonaws.AmazonClientException: Unable to verify integrity of data upload. Client calculated content hash (contentMD5: 93B885ADFE0DA089CDF634904FD59F71 in hex) didn't match hash (etag: 0CC175B9C0F1B6A831C399E269772661 in hex) calculated by Amazon S3. You may need to delete the data stored in Amazon S3. (bucketName: <your-bucket>, key: test-100M-proxy._COPYING_, uploadId: 14ABE04E57114D0D9D8DBCFE4CB9366E, partNumber: 2, partSize: 1): Unable to verify integrity of data upload. Client calculated content hash (contentMD5: 93B885ADFE0DA089CDF634904FD59F71 in hex) didn't match hash (etag: 0CC175B9C0F1B6A831C399E269772661 in hex) calculated by Amazon S3. You may need to delete the data stored in Amazon S3. (bucketName: <your-bucket>, key: test-100M-proxy._COPYING_, uploadId: 14ABE04E57114D0D9D8DBCFE4CB9366E, partNumber: 2, partSize: 1)可见，Amazon S3 在 header 签名中强制对每个 upload part 的 payload 做了 Content-MD5 的校验，能够有效检测出网络比特反转。模拟网络丢包之前的测试验证了， S3 使用 Content-MD5 的校验可以保证单个请求的正确性，但在写一些大文件，或是涉及 JobCommitter 的作业中，往往会使用 multipart upload 来进行并发上传。而网络丢包也是一种常见的问题。于是，接下来我们来验证下，如果上传过程中其中一个 part 丢失，是否会给上传结果造成影响。同样使用 mitmproxy 来模拟丢包利用 mitmdump 反向代理 s3a endpoint，并丢弃其中 part2 的请求。编写 addons.pyfrom mitmproxy import ctx, http import json import time import os class HookOssRequest: def request(self, flow: http.HTTPFlow): print("") print("="*50) print("FOR: " + flow.request.url) print(flow.request.method + " " + flow.request.path + " " + flow.request.http_version) print("-"*50 + "request headers:") for k, v in flow.request.headers.items(): print("%-20s: %s" % (k.upper(), v)) if flow.request.host == "<your-bucket>.oss-cn-shanghai-internal.aliyuncs.com" and flow.request.method == "PUT": if "partNumber=2" in flow.request.path: flow.response = http.HTTPResponse.make( 200, # (optional) status code b"Hello World", # (optional) content {"Content-Type": "text/html"}, # (optional) headers ) ctx.log.info("drop part-2 request!") ctx.log.info("requesting length:" + str(len(flow.request.content))) def response(self, flow: http.HTTPFlow): pass addons = [ HookOssRequest() ]反向代理 http://.oss-cn-shanghai-internal.aliyuncs.com 到 http://localhost:8765$ mitmdump -s addons.py -p 8765 --set block_global=false --mode reverse:http://<your-bucket>.oss-cn-shanghai-internal.aliyuncs.com同样修改 core-sites.xml 中的 fs.s3a.endpoint 指向 localhost:8765，并关闭ssl。<property> <name>fs.s3a.connection.ssl.enabled</name> <value>false</value> </property> <property> <name>fs.s3a.fast.upload</name> <value>true</value> </property>执行写入程序 demo，验证上传内容的正确性$ mkdir -p input output $ dd if=/dev/zero of=input/test-100M-proxy bs=$(( 100*1024*1024 + 1 )) count=1 $ hadoop fs -put input/test-100M-proxy s3a://<your-bucket>/ xx/xx/xx xx:xx:x WARN s3a.S3ABlockOutputStream: Transfer failure of block FileBlock{index=2, destFile=/data/hadoop/hadoop-2.8.5/tmp/s3a/s3ablock-0002-2063629354855241099.tmp, state=Upload, dataSize=1, limit=104857600} put: Multi-part upload with id 'D58303E74A5F4E6D8A27DD112297D0BE' to test-100M-proxy._COPYING_ on test-100M-proxy._COPYING_: com.amazonaws.AmazonClientException: Unable to verify integrity of data upload. Client calculated content hash (contentMD5: 93B885ADFE0DA089CDF634904FD59F71 in hex) didn't match hash (etag: null in hex) calculated by Amazon S3. You may need to delete the data stored in Amazon S3. (bucketName: <your-bucket>, key: test-100M-proxy._COPYING_, uploadId: D58303E74A5F4E6D8A27DD112297D0BE, partNumber: 2, partSize: 1): Unable to verify integrity of data upload. Client calculated content hash (contentMD5: 93B885ADFE0DA089CDF634904FD59F71 in hex) didn't match hash (etag: null in hex) calculated by Amazon S3. You may need to delete the data stored in Amazon S3. (bucketName: <your-bucket>, key: test-100M-proxy._COPYING_, uploadId: D58303E74A5F4E6D8A27DD112297D0BE, partNumber: 2, partSize: 1)可见，Amazon S3 在 close 请求中通过 CompleteMultipartUpload 对每个上传的 Part 做了检查，能够发现丢失的请求。校验算法的选择上文已经证明了校验码的不可或缺性，而且可以看到 Amazon S3 默认采用了 MD5 作为校验码。那就是最优的选择了吗？让我们来看看还有没有别的选择。数据摘要算法MD5、SHA-1、SHA-256、SHA-512都是数据摘要算法，均被广泛作为密码的散列函数。但由于MD5、SHA-1已经被证明为不安全的算法，目前建议使用较新的SHA-256和SHA-512。所有算法的输入均可以是不定长的数据。MD5输出是16字节（128位），SHA-1输出为20字节（160位），SHA-256为32字节（256位），SHA-512为64字节（512位）。可以看到，SHA算法的输出长度更长，因此更难发生碰撞，数据也更为安全。但运算速度与MD5相比，也更慢。循环冗余校验循环冗余校验又称 CRC（Cyclic redundancy check），将待发送的比特串看做是系数为 0 或者 1 的多项式。M = 1001010M(x) = 1*x^6 + 0*x^5 + 0*x^4 + 1*x^3 + 0*x^2 + 1*x^1 + 0*x^0M(x) = x^6 + x^3 + xCRC 编码时，发送方和接收方必须预先商定一个生成多项式 G(x)。发送方将比特串和生成多项式 G(x) 进行运算得到校验码，在比特串尾附加校验码，使得带校验码的比特串的多项式能被 G(x) 整除。接收方接收到后，除以 G(x)，若有余数，则传输有错。校验算法的开销CRC算法的优点是算法实现相对简单、运算速度较快。而且错误检错能力很强，因此被广泛应用于通信数据校验。我们做了一些简单的benchmark以供参考：CRC32 > CRC64 > MD5 > SHA-1 > SHA-512 > SHA-256校验算法单次操作耗时BenchmarkMD5_100MB-8175423280 ns/opBenchmarkSHA1_100MB-8176478051 ns/opBenchmarkSHA256_100MB-8344191216 ns/opBenchmarkSHA512_100MB-8226938072 ns/opBenchmarkCRC32IEEE_100MB-810500107 ns/opBenchmarkCRC32Castagnoli_100MB-812991050 ns/opBenchmarkCRC64_100MB-8 86377178 ns/op而 OSS 支持的校验算法有 MD5 和 CRC64，那么同样的场景下，我们会优先选择 CRC64 替代 MD5。阿里云EMR JindoSDK 的最佳实践在总结了 S3AFileSystem 做法中的优缺点，并结合 OSS 自身提供的一些功能取长补短后，阿里云EMR JindoSDK 得出了自己的最佳实践。JindoSDK 实现的 JindoOutputStream 支持了两种校验方式，一种是请求级别的校验，一种是文件块级别的校验。请求级别的校验，默认关闭。需要打开时，配置 fs.oss.checksum.md5.enable 为 true 即可。配置好之后，客户端会在块级别的请求（PutObject/MultipartUpload）Header 中添加 Payload 的 Content-MD5。如果服务端计算 Payload 的 md5 与 客户端提供的不符，则客户端会重试。文件块级别的校验，默认打开。需要关闭时，需要配置 fs.oss.checksum.crc64.enable 为 false。则是在写入流一开始就在内存中同步计算传入 Buffer 的 CRC64，并在文件块落盘时和服务端计算返回的 CRC64 进行比较。使用最新的 jindosdk-4.6.2 版本与 S3AFileSystem 在数据湖写入路径上，综合对比的结果如下：场景S3AFileSystemJindoOssFileSystem磁盘 IO 问题抛出异常java.io.IOException抛出异常java.io.IOException磁盘比特反转未抛出异常抛出异常java.io.IOException网络比特反转抛出异常org.apache.hadoop.fs.s3a.AWSClientIOException抛出异常java.io.IOException 网络丢包抛出异常org.apache.hadoop.fs.s3a.AWSClientIOException抛出异常java.io.IOException写一个 5G 文件的耗时13.375s6.849s可以看到 EMR JindoSDK 在写 OSS 时，不仅有着相比 S3AFileSystem 更完善的错误检查，性能也更为优异。总结与展望数据湖存储的安全写入，必须要能考虑到内存、磁盘、网络的不可靠性。同时，也要结合存储介质本身的特性，选择合适的校验算法。熟悉数据写入完整链路，全面地考虑各种可能遇到的问题，并提供完善的测试方案验证可行性，才算有始有终。阿里云EMR JindoSDK 通过以上方式形成了自己的最佳实践，不仅保证了对象存储写入链路的安全性，同样也支持了EMR JindoFS服务（OSS-HDFS）的写入链路。虽然 OSS-HDFS 中的一个文件可以对应 OSS 上的多个对象，但是在写入 OSS 时，底层复用了同一套实现。因此，在使用时也不需要做额外的适配，完全可以共用相同的配置项。未来我们还将结合 OSS-HDFS，提供在数据随机读场景的安全性校验，而这是对象存储本身目前无法做到的。附录一：测试 S3A 的配置方式core-sites.xml<property> <name>fs.s3a.impl</name> <value>org.apache.hadoop.fs.s3a.S3AFileSystem</value> </property> <property> <name>fs.AbstractFileSystem.s3a.impl</name> <value>org.apache.hadoop.fs.s3a.S3A</value> </property> <property> <name>fs.s3a.access.key</name> <value>xxx</value> </property> <property> <name>fs.s3a.secret.key</name> <value>xx</value> </property> <property> <name>fs.s3a.endpoint</name> <value>localhost:8765</value> </property> <property> <name>fs.s3a.connection.ssl.enabled</name> <value>false</value> </property> <property> <name>fs.s3a.fast.upload</name> <value>true</value> </property> <property> <!-- 本地 buffer 缓存目录，不存在会创建 --> <name>fs.s3a.buffer.dir</name> <value>/mnt/passthrough/</value> </property>附录二：测试EMR JindoSDK 的配置方式core-sites.xml<property> <name>fs.AbstractFileSystem.oss.impl</name> <value>com.aliyun.jindodata.oss.OSS</value> </property> <property> <name>fs.oss.impl</name> <value>com.aliyun.jindodata.oss.JindoOssFileSystem</value> </property> <property> <name>fs.oss.accessKeyId</name> <value>xxx</value> </property> <property> <name>fs.oss.accessKeySecret</name> <value>xxx</value> </property> <property> <name>fs.oss.endpoint</name> <!-- 阿里云 ECS 环境下推荐使用内网 OSS Endpoint，即 oss-cn-xxx-internal.aliyuncs.com --> <value>oss-cn-xxx.aliyuncs.com</value> </property> <property> <!-- 客户端写入时的临时文件目录，可配置多个（逗号隔开），会轮流写入，多用户环境需配置可读写权限 --> <name>fs.oss.tmp.data.dirs</name> <value>/data2/tmp/</value> </property> <property> <!-- 是否使用二级域名写入 打开后 <your-bucket>.oss-cn-xxx-internal.aliyuncs.com/<your-dir> 会变为 oss-cn-xxx-internal.aliyuncs.com/<your-bucket>/<your-dir> --> <name>fs.oss.second.level.domain.enable</name> <value>true</value> </property>log4j.propertieslog4j.logger.com.aliyun.jindodata=INFO log4j.logger.com.aliyun.jindodata.common.FsStats=INFOmitmproxy获取 endpoint ipping oss-cn-shanghai-internal.aliyuncs.com 64 bytes from xxx.xxx.xxx.xx (xxx.xxx.xxx.xx): icmp_seq=1 ttl=102 time=0.937 ms将 addons.py 中使用 ip 代替 .oss-cn-shanghai-internal.aliyuncs.com if flow.request.host == "xxx.xxx.xxx.xx" and flow.request.method == "PUT":反向代理时也使用 ip 代替 .oss-cn-shanghai-internal.aliyuncs.commitmdump -s addons.py -p 8765 --set block_global=false --mode reverse:http://xxx.xxx.xxx.xx:80欢迎感兴趣的朋友加入钉钉交流群（钉钉搜索群号33413498 或 钉钉扫描下方二维码）
-
发表了文章 2023-03-07
基于阿里云 CloudMonitor云监控自定义监控大盘对 EMR 自定义监控实践
作者：锦琛引言开源大数据平台 E-MapReduce（简称“EMR”）是云原生开源大数据平台，向客户提供简单易集成的 Hadoop、Hive、Spark、Flink、Presto、ClickHouse、StarRocks、Delta、Hudi 等开源大数据计算和存储引擎。云监控（简称“CloudMonitor”）是一项针对阿里云资源和互联网应用进行监控的服务，为云上用户提供开箱即用的企业级开放型一站式监控解决方案。本文旨在分享 EMR 平台大数据服务基于阿里云CloudMonitor 的监控实践，给客户提供除了 EMR 平台默认监控以外，自建监控方式，适用于统一多个阿里云服务的监控场景。关键字E-MapReduce，云监控前提条件已有阿里云EMR 集群自定义监控大盘配置步骤1：跳转云监控管控登陆 E-MapReduce服务控制台。选择前往集群监控-指标监控控制台，点击右上角查看更多指标。跳转至云监控指标大盘可以在顶栏切换多个分类，目前支持host,hdfs,yarn,hbase,kafka。步骤2：自定义大盘配置当云监控上默认指标大盘不满足您需求时，可以自定义配置云监控大盘满足监控需求。点击左侧Dashboard，添加一个大盘进入上一步创建的大盘，选择需要自定义监控的指标，各指标大盘中指标含义可以参考E-MapReduce官网的帮助文档，此链接。监控实例选择您需要监控的集群id，支持多个指标配置，完成后点击确定。完成一个图表配置。告警配置如果对某个指标需要告警，可以直接在云监控大盘上配置点击下图按钮可以配置告警，具体请参考云监控官网文档。钉钉扫码进群，了解更多详情
-
发表了文章 2023-03-03
阿里云EMR 2.0：定义下一代云原生智能数据湖
摘要：本文整理自阿里云高级技术专家/数据湖存储负责人郑锴(铁杰)；阿里云高级技术专家/开源大数据OLAP负责人范振(辰繁)在 阿里云EMR2.0线上发布会 的分享。本篇内容主要介绍了阿里云云原生数据湖分析解决方案的三个核心要素：全托管，湖存储；一站式，湖管理；多模态，湖计算点击查看直播回放阿里云云原生数据湖分析解决方案全面重磅升级，经中国信通院评测，它是目前国内唯一满分的数据湖方案。它有三个核心要素构成：全托管，湖存储：全面兼容支持 HDFS/POSIX 协议，无缝对接大数据和AI一体化生态；一站式，湖管理：提供全面的数据库存储管理能力；多模态，湖计算：基于一湖多架构，能够同时实现离线湖、实时湖、湖仓分析。一、全托管 - 湖存储（OSS-HDFS）1、第三代数据湖存储 OSS-HDFS第一代数据湖存储是开源的 HDFS；标准对象存储如阿里云OSS，被认为是第二代数据库存储；阿里云融合前两代数据湖存储上的优势，推出第三代数据湖存储：OSS-HDFS。2、OSS-HDFS 生态支持新的数据湖存储解决方案 OSS-HDFS，通过 HDFS API 和 POSIX API，实现对数据湖存储之上丰富的大数据和AI计算场景的完整支持，这是第三代数据湖存储的核心命题。通过提供充分的、完全的 HDFS 接口兼容，充分对接 Hadoop、Spark 这类大数据生态；同时，对新兴的湖仓分析计算场景也提供了充分的支持；对于蓬勃发展的AI生态，通过 POSIX 提供兼容支持。3、性能优势在存储服务的核心能力方面，如性能、规模和成本上，阿里云云原生数据湖分析解决方案具备显著的优势。性能：高原子性和毫秒级目录操作 rename、delete超大目录 du/count 毫秒级返回规模：大热文件（10 亿）+ 温冷（40亿）vs 4亿OSS 带宽水平扩展成本：低标准（30%）+ 低频（30%）+ 归档（40%）免运维几十PB甚至上百PB的数据库，按照二八定律，20%的数据是热数据，80%的数据是温数据或者冷数据，利用 OSS 的分层存储和归档能力，OSS-HDFS 实现了 HDFS 的分层存储管理策略，可以将20%的热数据实施标准存储策略，80%的温数据和冷数据分别按照低频和归档的存储策略来存储，整体降低了存储成本。OSS-HDFS 作为全托管的存储服务，相比较开源自建的 HDFS，具备免运维、低人工的维护成本，在性能、规模、成本上具备显著的性能优势。对于用户自建的 HDFS 集群，阿里云云原生数据湖分析解决方案在业界首次提供了"三不"平滑迁移方案，不改业务代码，不改文件路径，不停存储服务。对于用户已经在 OSS 上面的数据，支持快速导入，方便用户享受 OSS-HDFS 提供的对于计算访问加速的优势。二、一站式 - 数据湖管理（DLF）阿里云云原生数据湖分析解决方案，通过 Data Lake Formation 这个全托管的数据湖管理产品，提供一站式数据湖管理能力。Data Lake Formation 能够对众多的计算产品提供统一的元数据访问，具有全景的、完整的数据访问统计视图，提供诸多存储分析和成本优化方案，如智能识别温数据、冷数据和热数据，提供分层存储管理策略；如针对 Deltalake 提供自动优化策略等。1、统一元数据服务全托管、高可用、高性能、可扩展、免运维；兼容开源 HMS 协议，无缝对接和兼容开源；支持 Multi-Catalog、多版本管理；2、权限与安全支持库、表、列、函数级别细粒度权限控制；支持和兼容 Apache Ranger 鉴权；支持数据访问日志审计；3、存储成本优化存储分析与成本优化；湖格式自动优化策略；数据生命周期管理；4、存储访问加速全场景：大数据分析加速、AI 海量小文件训练加速；策略全：读缓存、写缓存、元数据缓存、分层缓存；同时支持计算透明和数据编排。三、多模态 - 湖计算EMR2.0遵循的是一湖多架构的计算模式，然后通过开源引擎引入组合成不同的用户场景。接下来介绍几种典型的场景：离线湖，实时湖，湖仓分析。1、离线湖离线湖即 Hadoop 场景，主要解决的是数仓的分层模式，一般用在T+1场景。 （离线湖）OSS-HDFS：通过提供 HDFS 接口，以及 OSS 对象存储，能够做到分层存储和智能存储，可扩展性高，成本低；引入全托管的 DLF：解决了 HIVE+MySQL 这种传统元数据模式的一些痛点，包括稳定性，可扩展性等；数据湖三剑客：DELTA LAKE、HUDI、ICEBERG，这三种引擎近年来发展得非常好，在后面实时湖的部分重点介绍；计算资源层：这里一般分为 ECS 和 ACK，经过 EMR2.0 引入的这个全新开发的底座，对 ECS 和 ACK 的支持都非常好，在弹性的速度、可靠性、免运维等方面，对比上一个版本有了质的提升，计算引擎：计算引擎逐渐由 Hive on MR、Hive on Tez 迁移到 Spark。Spark 作为近十年来的一个明星产品，阿里云对 Spark 进行了深度的自研优化，在性能上比开源提升了100%。在此基础上，阿里云自研了 Remote Shuffle Service，并把它捐献到了 Apache 社区（名字为 Celeborn），Remote Shuffle Service 把所有的 Shuffle 数据放在一个 Service 上而不是依赖于本地盘，解决了 Spark 常见的 Stage 不稳定、大作业的加速等问题。离线大数据经过十多年的发展，目前仍经久不衰，T+1的场景被用户大规模使用，这主要是因为以下几点：离线数仓的模型理论基础已经非常的完善；固定的、有界的数据对于计算引擎的复杂度要求没有那么高，可以比较方便的进行数据重跑；Spark 被市场广泛接受，是一个非常稳定的产品。2、实时湖离线数据湖虽然被大规模使用，但它解决不了一些问题，如实时和准实时的问题，这就引出了实时湖。 （实时湖）OSS-HDFS 和 DLF（见离线湖部分）；数据湖的增量存储部分：数据湖三剑客 DELTA LAKE、HUDI、ICEBERG，这三种引擎近年来发展得非常好，这种表格式慢慢的也会演化成不同的方向，但它们着重解决的是同一类问题；第一，要解决的是增量模式，需要做 ACID 的事务保证，由于引入了 ACID 事务保证，实际上每一个 commit 就是一个 version，那么可以在同一套系统里去做批、做流的处理；第二，引入了自闭环元数据的结构，实际上解决的问题是大规模的元数据的扩展性以及性能问题。它所依赖的是对象存储，而不是类似Hive这种体系，所以在可扩展性上是有非常大的提高；第三，一旦引入 ACID，就可以做 update 这种场景，而要反映到大数据里面，可以通过增量表格式的研发来解决，包括常见的订单系统、对于数据回溯等状态变化的场景，也包括一些高级的特性如 Schema Evolution，Time Travel 等，对整个业务会有非常大的提升，这是增量数据湖带给我们的一些好处和能解决的一些业务痛点。计算引擎：Flink：Flink 是流引擎的最明星产品，所有客户涉及到实时的产品都在用，最近主打的理念就是批流一体；Presto和Trino也在往不同的方向走，比如Presto，它目前推出了一些能够进行native计算的领域，包括Velox，包括对ETL的一些补充，以及一些容错的方向，它可以做一些原先Spark才能做的工作，很多客户也在用Presto或Trino来做一些简单的ETL加工，虽然它原来标榜的是纯内存计算；Trino主要的处理的方向是做connector，进行所谓的联盟查询，而且它对细粒度的优化做得非常不错。Presto和Trino主要解决的是湖数据的准实时的处理，即在几十秒或者分钟级别的查询。实时湖通过表格式的方式去解决一些问题和痛点，其业务的可拓展性和可发展性非常强。3、湖仓分析一般在纯实时的场景下引入湖仓分析。（湖仓分析）数据湖里的数据链路，如果想被 OLAP 系统查询到，或者说被秒级的 Ad-hoc 查询，或者说被高并发查询，目前没有一种引擎可以非常完美解决。但可以把它放到一种仓里，比如常见 StarRocks，Doris，ClickHouse，可以解决实时报表，实时数仓，大屏展示等。湖仓直接分析是因为如果把数据全部导入到 StarRocks，会有数据重复，也会增加存储成本。为了平衡成本与性能，通过 StarRocks 统一技术栈，既可以做仓内的查询，也可以做仓外的湖查询，通过缓存机制，能够使得仓外的查询，也就是说 connector 查询，能够达到几乎和仓内查询一样的速度。StarRocks 看起来像是现代化的云 Lakehouse，自从开源以来，从2.X版本执行引擎的性能提升，全面的向量化，查询规划优化，全新 CBO 优化，主键模型，雾物化视图等等，都是在打造仓内部，后续 StarRocks 兼容轻量的 ETL，在仓内去做分层数仓模型。从2.4、2.5版本开始，StarRocks 逐渐转化为对于湖上数据的优化，包括提供对 DELTA LAKE、HUDI、ICEBERG 的全面支持，通过统一的技术栈，即去查询仓内数据，又去查询仓外数据，这样整个架构就会非常顺滑，客户用起来也非常轻松。4、ServerlessServerless StarRocks产品已开启邀测，预计3月底公测，后续还会推出 Serverless Spark、Serverless Presto/Trino；通过 Serverless 进行存算分离架构演进，计算资源可以按需扩展，具备极致的弹性和极致的成本压缩；通过 OSS-HDFS，DLF，Serverless，实现免运维，99.9% SLA保障，NoteBook/Dataworks 对接等，为用户提供端到端的全托管体验。EMR Serverless StarRocks邀测申请：https://survey.aliyun.com/apps/zhiliao/EEb00jXa7欢迎对 EMR 感兴趣的朋友加入 EMR 钉钉交流群，一起交流和学习。
-
发表了文章 2023-03-01
阿里云开源大数据平台E-MapReduce 产品新动态及开源大数据前沿技术分享 2023-2月刊
开源大数据平台E-MapReduce 上新啦一、EMR 新平台功能发布1、EMR 新平台新增 Terraform 管理能力适用客户：所有 EMR 发布地域用户发布功能：新增 Terraform Resource ：alicloud_emrv2_cluster。用户可以通过 Terraform 创建和管理 DataLake、OLAP、Dataflow、DataServing、Custom 等 EMR2.0 集群相关文档：https://registry.terraform.io/providers/aliyun/alicloud/latest/docs/resources/emrv2_cluster2、EMR 集群支持数据盘加密适用客户：所有 EMR 发布地域用户发布功能：用户可以在创建集群时选择开启数据盘加密，支持加密的数据盘类型有 ESSD 云盘、SSD 云盘和高效云盘。加密数据盘后，数据盘上的动态数据传输以及静态数据都会被加密，可以满足用户安全合规要求。相关文档：https://help.aliyun.com/document_detail/450560.html3、新增应用配置导出功能适用客户：所有 EMR 发布地域用户发布功能：支持将当前集群应用配置通过 xml 或 JSON 格式进行导出。用户可以使用该功能导出旧集群配置并在新建集群时使用，从而加速集群的升级和重建工作。相关文档：https://help.aliyun.com/document_detail/607697.html?spm=a2c4g.11186623.0.0.1abf48a5vWrlQf4、事件中心新增系统事件适用客户：所有 EMR 发布地域用户发布功能：事件中心新增系统事件 System:PreemptibleInstanceReplace:Successful（抢占式实例自动补偿通知）。用户可以在开启抢占式实例补偿功能时，使用该事件跟踪抢占式实例补偿过程。相关文档：https://help.aliyun.com/document_detail/465463.html5、访问链接与端口功能升级适用客户：所有 EMR 发布地域用户发布功能：访问链接与端口新增服务原生 UI 地址，并在原 Knox 地址新增支持外网/内网多种链接形式，用户在不同集群环境下均可通过该模块访问服务 UI。相关文档：https://help.aliyun.com/document_detail/389055.html6、日志管理新增支持投递服务适用客户：所有 EMR 发布地域用户发布功能：新增 yarn-application 日志投递功能，支持用户将 YARN 任务运行日志投递至 SLS 进行后续分析。相关文档：https://help.aliyun.com/document_detail/465660.html7、弹性伸缩规则新增配置参数适用客户：所有 EMR 发布地域用户发布功能：弹性伸缩按负载伸缩规则新增时间约束参数。用户可以配置该参数控制台按负载弹性伸缩规则生效时间，适用于同时使用按时间和按负载两种规则的弹性伸缩场景。相关文档：https://help.aliyun.com/document_detail/445658.html二、E-MapReduce 国际站1、EMR 新平台在马来西亚（吉隆坡）正式开服适用客户：吉隆坡地区用户发布功能：EMR 新平台在马来西亚（吉隆坡）正式开服，用户可以在该 region 创建和管理 DataLake、OLAP、Dataflow、Dataserving、Custom 等 新集群。2、EMR Doctor 在德国（法兰克福）正式开服适用客户：德国（法兰克福）用户发布功能：EMR Doctor 开服法兰克福 region。3、集群监控新增国际化英文版本适用客户：所有 EMR 发布地域用户发布功能：集群监控模块（事件中心、指标监控）新增英文版本支持。支持国际用户英文环境下使用 EMR 集群监控功能。相关文档：https://www.alibabacloud.com/help/en/e-mapreduce/latest/new-evenment三、EMR Doctor 智能运维系统1、EMR Doctor 日报内容更新适用客户：北京/上海/杭州/深圳 Region 用户发布功能：HDFS/Hive 日报更新：新增冷热数据占比趋势图：反映近七天 HDFS/Hive 存储的冷热数据量占比各自的变化趋势，帮助您更好的了解集群冷热数据走向。新增大小文件占比趋势图：反映近七天 HDFS/Hive 存储的大小文件数量占比各自的变化趋势，帮助您及时发现小文件增长趋势以及直观感受优化效果。Compute 日报更新：新增基础信息展示：包括计算任务数量，Failed/Killed 任务数量，Mapreduce 任务数量，Spark 任务数量，Tez 任务数量，内存时，CPU 时。新增任务分数分布图：展示各分数区间（0-60，60-70，70-80，80-90，90-100）的任务数量分布。新增队列分析：与用户信息分析合并为用户和队列信息分析，新增以下图表信息。新增提交任务队列算力内存时分布：展示各队列上每日提交运行的任务的算力内存时占比。新增提交任务队列算力 CPU 时分布：展示各队列上每日提交运行的任务的算力 CPU 时占比。新增提交任务队列评分排名：展示健康度评分最差的10个队列以及评分。新增提交任务队列任务数量分布：展示各队列的任务数量。新增队列内存时 Top 详细信息：展示内存时最大的20个队列的详细信息，包括评分，内存时，CPU 时以及日环比。新增任务的队列信息：计算任务各 Top 表中任务的详细信息增加任务的队列。新增任务当前配置信息：计算任务各 Top 表中的任务的详细信息增加任务的当前配置展示。相关文档：https://help.aliyun.com/document_detail/430095.html2、EMR Doctor 实时检测内容更新适用客户：北京/上海/杭州/深圳 Region 用户发布功能：● 新增任务的队列信息：Spark，MapReduce,Tez 任务各 Top 表中任务的详细信息增加任务的队列。● 新增任务当前配置信息：Spark，MapReduce,Tez 任务各 Top 表中的任务的详细信息增加任务的当前配置展示。相关文档：https://help.aliyun.com/document_detail/464156.htmlEMR 产品活动1、阿里云 E-MapReduce Serverless StarRocks 免费测试申请EMR Serverless StarRocks 是由阿里云 EMR 全新推出的 Serverless StarRocks 服务，StarRocks 是一款高性能分析型数据仓库，使用向量化、MPP 架构、可实时更新的列式存储引擎等技术实现多维、实时、高并发的数据分析。可广泛应用于 BI 报表分析、OLAP 报表、数据湖分析、实时数据接入及分析等场景。 EMR Serverless StarRocks 相较于开源 StarRocks 产品特性包括： 提供免运维，全托管的 StarRocks 实例管理服务，提升服务的稳定性，可运维性，降低您的运维成本。 提供可视化，高效率的实例管理，监控告警，配置管理能力。 专业的 StarRocks Manager，为 StarRocks 管理提供便捷的，可视化的元数据管理，诊断与优化，以及用户管理和授权能力。 邀请测试期间 EMR Serverless StarRocks 均为免费（注意：会额外开通 SLB/ARMS，会产生少量费用，会随实例释放） 邀测申请： https://survey.aliyun.com/apps/zhiliao/EEb00jXa72、阿里云 E-MapReduce Notebook 免费试用邀请EMR Notebook 是云原生的大数据开发环境，为数据工程师、数据分析师和数据科学家提供了可视化的协同应用程序开发环境。基于Jupyter 的 EMR Notebook 可自动适配 EMR 的计算引擎，支持 Python、Scala、PySpark 和 R 等多种语言。参与本次试用活动，您将获得：100% 兼容 Jupyter 的免费 Notebook 服务，体验更优 。 可自动适配连接 EMR 集群，编辑和运行代码。 试用资格申请：https://survey.aliyun.com/apps/zhiliao/SGC7QcG6e?spm=a2cug.25127996.0.0.75f81060WMyLnc3、阿里云 E-MapReduce Workflow 免费试用邀请阿里云EMR Workflow 是基于 Apache Dolphinscheduler 的全托管 Serverless 的工作流调度服务，是 EMR 2.0 数据开发解决方案的重要组成部分。EMR WorkFlow 具有以下特点：安全稳定托管的 Workflow 服务，极大地降低了用户的运维成本，为任务运行提供了安全稳定的环境操作便捷延续了 Apache Dolphinscheduler 可视化 DAG 操作方式，可以通过拖拽的方式轻松定义工作流生态丰富支持 Shell、Hive、Spark、Sqoop 等多种任务类型，自动适配 EMR 多种集群类型。参与本次活动，您将获得：1. 免费试用 EMR Workflow 服务的资格 2. 自动适配您的 EMR 集群，开箱即用 试用资格申请：https://survey.aliyun.com/apps/zhiliao/AMO_oRU8D?accounttraceid=4118c5ca19d54f69a5a836193c682437cpzg最佳技术实践1、基于数据湖格式构建流式增量数仓—CDC本文整理自阿里云开源大数据平台技术专家毕岩(寻径)在 Apache Con ASIA 的分享。本篇内容主要分为四个部分：1. 湖格式& Hudi & CDC2. 湖格式设计实现 CDC 的思考3. Hudi CDC 实现4. 湖格式 Streaming 的优化文章详情：https://developer.aliyun.com/article/1164177?spm=a2c6h.13148508.setting.16.549c4f0ezN5x4B2、开源大数据可观测性方案实践 - 助力集群运维智能化、便捷化在本篇文章中，我们将介绍大数据集群领域所需的可观测性，实践大数据集群可观测所需要的条件和面临的挑战，以及阿里云EMR 产品如何通过 EMR Doctor 实现大数据可观测并向用户提供相关能力。文章详情：https://developer.aliyun.com/article/1167786?spm=a2c6h.13148508.setting.14.549c4f0ezN5x4B3、阿里云EMR 2.0：重新定义新一代开源大数据平台本次分享主要介绍了阿里云E-MapReduce 的开发历程，EMR 2.0 的新特性、产品架构，以及EMR 2.0 在平台体验、数据开发、资源形态及分析场景等方面的全面突破与创新，重新定义新一代开源大数据平台。文章详情：https://developer.aliyun.com/article/1150890?spm=a2c6h.13148508.setting.20.549c4f0ezN5x4B4、阿里云EMR 2.0 平台：让大数据更简单作为国内开源大数据领域的引领者，EMR2.0 在平台体验、数据开发、产品形态及数据分析等方面做了全面突破与创新，重新定义了新一代开源大数据平台。本文介绍如何利用EMR新平台实现更加低成本、高效率、智能化的大数据集群管控和应用开发。文章详情：https://developer.aliyun.com/article/1150890?spm=a2c6h.13148508.setting.20.549c4f0ezN5x4B5、阿里云EMR 2.0：兼容开源，贡献开源，超越开源本文整理自阿里云资深技术专家吴威(无谓)在 阿里云EMR2.0 线上发布会的分享。本文从开源的角度出发，分享了阿里云EMR 团队的工作。文章详情：https://developer.aliyun.com/article/1166381?spm=a2c6h.13148508.setting.15.549c4f0ezN5x4B开源技术前沿动态1、StarRocks 2.5 LTS 版本新特性介绍StarRocks 2.5 LTS 版本于近期发布，阿里云 EMR Serverless StarRocks 也在火热邀测中。本文将重点介绍 StarRocks 2.5版本核心功能以及阿里云 EMR Serverless StarRocks 特性。文章详情：https://developer.aliyun.com/article/1153610?spm=a2c6h.13148508.setting.18.549c4f0ezN5x4B2、Spark+Celeborn：更快，更稳，更弹性本文整理自阿里云 EMR Spark 团队的周克勇（一锤），在 Spark&DS Meetup 的分享。本篇内容主要分为三个部分：1. 传统 Shuffle 的问题2. Apache Celeborn （Incubating）简介3. Celeborn 在性能、稳定性、弹性上的设计文章详情：https://developer.aliyun.com/article/1153123?spm=a2c6h.13148508.setting.19.549c4f0ezN5x4B钉钉扫码进群，欢迎咨询与交流前沿开源大数据
-
发表了文章 2023-02-22
开源大数据可观测性方案实践 - 助力集群运维智能化、便捷化
作者：燕回@阿里云前言在过去的20年时间，大数据技术蓬勃发展，从最开始大公司内部的秘密武器，到现在广泛作用于几乎所有行业。通过使用大数据技术分析存量和实时的数据，能够更加全面清晰地洞察商业的本质。在商业节奏日益加快和发展越来越迅猛的今天，越来越多的企业意识到大数据分析的价值，并投入了大量的时间人力等资源。与此同时，从早期的简单报表，到搜广推（搜索广告推荐）的个性化需求，再到最近异常火爆的人机智能交互技术 ChatGPT，大数据应用对算力的要求呈指数级增长。如何以更低的成本、更加稳定地提供更高的算力，成为大数据行业需要探索和解决的核心问题。另一方面，为了满足企业不断增长的大数据处理需求，从早期的 Hadoop、Hive，到 Spark、Presto、Flink，再到近几年火爆的数据湖、OLAP，涌现出了多种多样的大数据技术。虽然很多大数据技术都是开源的，可以通过网络获取到一些技术指南、最佳实践等，但是依旧缺乏从集群整体维度和数据处理全链路来分析和提升大数据栈“效能”的有效方法。可观测性最早起源于应用服务，旨在随时了解整个应用栈中发生的情况。通过在网络、基础设施和应用程序中收集、关联、聚合和分析数据，以便深入了解系统的行为、性能和运行状况。可观测性可以用“观测-判断-优化-再观测”这一闭环来简单解释。可观测性是提升应用效率的基础和关键，但在大数据集群方面一直缺乏实践，这主要是由前述大数据技术的多样性和复杂性导致的。在本篇文章中，我们将介绍大数据集群领域所需的可观测性，实践大数据集群可观测所需要的条件和面临的挑战，以及阿里云EMR 产品如何通过 EMR Doctor 实现大数据可观测并向用户提供相关能力。大数据可观测性介绍当我们提及大数据的时候，脑中会浮现出各种技术，从 Kafka 到 HDFS、OSS，再到 YARN 和目前发展更好的 Kubernetes，还有上层的各种计算引擎如 Spark，Flink 和 Tez 等，甚至是深度学习和 OLAP 等业务相关技术。尽管大数据技术纷繁复杂，我们可以把大数据各种技术自顶向下分为如下几层：计算引擎，资源调度层，存储等几个维度。由这些相互独立又互相关联的子系统一起构建了整体的大数据系统，为企业的大数据平台提供基础设施。大数据的可观测性指的就是通过指标采集，元数据采集等技术获取到上述各个系统的洞察数据，而不是简单的指标罗列。大数据可观测的结果能够为企业带来如下价值：通过资源分析与建议，辅助用户不断的优化，带来更合理的资源利用和更健康的集群使用通过问题提示和异常提醒，减轻开发与运维人员的工作量，为企业大数据开发带来更高的效率通过及时的规则分析、根因分析等，快速的定位大数据集群问题，减少集群因为故障带来的恢复时间大数据可观测性场景分析尽快前面提到，大数据可观测性可以为我们带来诸多好处，但现实情况是，很少有企业能够在大数据领域做好可观测性，甚至大部分企业还没有涉足这一领域。我们简单地分析一下大数据可观测性的使用场景。我们先看一下企业中使用大数据应用的一个基本构成，通常企业中使用大数据的人群可以被分为如下几类：数据分析师，数据科学家以及数据工程师，可以被统称为集群用户。数据团队，包括运维团队等可以被统称为集群管理员。CIO/CTO/CEO 等可以被统称为管理层。将集群中的角色细分后，我们其实可以看到，这三种不同的角色对大数据集群需求是不一样的，下面分别介绍一下这三种角色对于可观测性的不同要求。大数据可观测性的用户画像集群用户的需求集群用户直接使用集群，提交各种任务到集群中，并产出数据，是为企业获取直接价值的群体。集群用户提交的任务多种多样，从批处理的 Hive on MR, SparkSQL 到流式的 Flink 任务以及 Ad-hoc 的 Presto 任务等。集群用户通过这些计算框架等直接构建上层的应用，如用户大盘，营销热点等。对于集群用户来说，最关心的是任务的运行情况以及优化方法，集群用户常见的需求如下：能否将我的任务更快的完成？任务失败了，究竟是什么导致的？我的任务今天跑不出来，但是之前都能跑，是什么导致的？今天的日报比昨天晚出了2个小时，是哪个流程造成的？集群管理员的需求集群管理员负责维护大数据集群的稳定性，包含大数据集群软件设施，甚至包括底层的 IaaS 资源的稳定运行。在企业中虽然集群管理员不直接产出具体产品，但是通过对集群的稳定性提升以及整体的效率提升，会直接的提升整个集群的使用效率，从而提升企业的竞争力。对于集群管理员来说，他需要了解集群整体的运行状态，集群潜在的风险以及对于风险能够找到对应的负责方进行处理。集群管理员常见的需求如下：HDFS中产生了大量的小文件，能否找到对应的使用方进行清理？昨天集群中占用最多计算资源的使用方是哪些，这些是否合理，能够进行多大程度的优化？哪些任务运行了最长的时间，占用最多的资源？集群现在感觉有问题，到底是什么原因导致的？是由于任务导致的，还是 HDFS 出现瓶颈？管理层的需求管理层不太关注大数据使用的具体技术，更关注大数据能够给企业带来的价值以及整体的投资回报比，对于成本也有着较强的需求，包括资源优化，成本分摊等。常见的管理层的需求如下：现有的集群在扩容前是否已经运行在较高的水位，是否还有优化空间？集群从哪个方面能够进行资源优化，优化的效果如何？现在集群的花费中，不同业务的占比如何，是否与产出成正比？分析完三种角色对于大数据可观测性的不同需求，我们可以总结出，不同的角色对于大数据可观测性都有非常强的需求。但是现阶段，大数据可观测并不是大数据集群的标配，无法满足各个角色的需求。而造成这一现象的原因由于首先大数据软件栈太过繁杂，能够全部了解各个框架的人才屈指可数，而这些知识是大数据可观测性的一个前提条件。另一个原因是成本考虑，构建一整套大数据可观测系统需要多种技术，较长的链路以及复杂的技术，这对于一般的企业来说负担较重且很难量化产出。大数据可观测性技术初探大数据可观测性发展历程在实践大数据可观测的过程中，需要经历四个阶段，每一个阶段的都是下一个阶段的必要组成，并为用户提供越来越多的业务价值。第一阶段，主要根据各个大数据组件提供的接口采集各个组建的 metrics 信息等，在这一阶段需要有大数据平台经验的人才来对这些 metrics 进行分析，能够得到基础的组件健康状态、组件压力状态等信息，在出现问题的时候需要分析历史的 metrics 信息进行推断，得到潜在可能的问题。第二阶段，除了采集各个组件的基础 metrics 外，还对集群中的任务，cpu 资源，调度的队列信息等进行全面的采集，除了采集外，还需要对这些信息进行关联，获取到出现问题的根本原因。在这一阶段，除了采集更多的信息外，更重要的是对采集的信息进行关联，得到问题的本质原因。第三阶段，在第二阶段的基础上，根据规则等把相应的处理方案反馈给用户，用户根据提示进行自运维操作，甚至发展到更高级的阶段，在底层的自愈系统能够自动化的对问题进行处理，减少股长时间。第四阶段，基于前面个阶段的积累，根据多种问题产生的规律总结，或者基于规则，或者基于火热的 AI 技术，能够在故障处理之前能够及时预警，及早的排除隐患，将故障消灭在发生前。从这四个阶段说明来看，每一个阶段都是在前一个阶段完成的基础上再进行数据在加工，产生更高质量的服务，当然了，随着要求的提升，技术难度和广度也愈加复杂。大数据可观测性的技术要求前面提到大数据可观测性在整体技术上要求很高，普通用户对于构建这一流程存在难度，这里仔细探讨一下这方面的原因。首先在实践大数据可观测性的过程中，需要对多种组件、引擎、调度系统都要了解。比如对于 Hive on Tez 需要了解 Tez 的状态机转换，在不同的阶段需要获取不同的 metrics 和 events；对于 Spark 需要了解各个 stage 阶段采集不同的数据；对于 HDFS 需要了解元数据 Image 解析流程；对于 ResourceManager 需要了解不同的队列在各个优先级不同的情况下的调度策略。如果想做好全链路的大数据可观测系统，需要对整个集群中使用的各个组件，各个引擎等有着比较深入的了解，并且不像 web 应用监测形成标准化，各个大数据组件和引擎采集等互不相同，没有一个统一的标准能够进行采集，但是彼此之间却相互关联，比如一个 Hive 的任务有一个 session id，在 YARN上 是一个 ApplicationID，相互之间需要做映射处理。其次，除了采集以为，整个的大数据可观测系统还有一个复杂的链路，如下图：在采集系统，需要有足够的经验能够获取所需要的必要数据。入仓阶段，需要对采集的数据进行统一收集管理，方便后面的分析。分析阶段，根据收集方式的不同，可以采用实时分析或者批处理分析等。展示阶段，将分析的结果全面有效的反馈给客户，并且能够快速的迭代。在这几个阶段中，都需要一个全链路的监控系统，保证了整个系统的稳定性和有效性。在这个链路过程中，涉及到了大数据各个组建的内核分析，jvm 使用分析，采集链路，收集链路、流式处理分析，批处理分析，前后端技术等等，可以说相当复杂。这也是为什么大数据可观测性没有广泛的成为业界标准的原因。阿里云EMR 在大数据可观测性的实践自2016年阿里云推出 EMR 以来，阿里云EMR 团队一直致力于为客户提供高附加值产品，解决大数据集群的痛点，如提升性能，降低资源成本，提升运维效率等能力。发展至今，我们已经为大量客户提供了完善的半托管服务，依托于社区专家的人才积累，场景的丰富多样，我们在大数据可观测性以及大数据管理方面积累了大量的经验，为我们的大数据可观测性实践提供了坚实的基础。在2022年12月，阿里云EMR正式发布了云原生开源大数据平台EMR 2.0，升级后的开源大数据平台在成本持平的情况下，扩缩容性能最高可提升6倍。EMR 2.0为客户提供了完善的大数据可观测性能力，通过集群监控，我们提供了完备的监控指标以及巡检项，及时的提醒用户集群中目前出现的问题。通过 EMR Doctor 健康检查，我们为客户提供全面的大数据可观测能力，提供了从存储、计算的多方面，集群维度的健康评估，为客户提供开箱即用的大数据可观测平台，辅助提升客户整体的集群使用效率，解决潜在的问题。EMR Doctor 为阿里云EMR 客户提供较为完备的大数据可观测产品，我们提供实时和日报两种方式，为集群用户提供不同角度的可观测方案。EMR Doctor 提供的功能包括如下：EMR Doctor 提供集群的日报功能，并提供量化打分、智能建议，用户可以清晰到获取到集群的健康状态以及改进建议EMR Doctor 提供集群的实时检测功能，实时的对集群任务进行分析，异常检测，对组件状态进行检查分析，找到潜在的问题和改进建议EMR Doctor 对多数据源进行采集、融合分析，并根据智能算法进行智能诊断分析，减少大数据平台繁重和重复的劳动EMR Doctor 功能介绍EMR Doctor 提供日报和实时检测两种形态的功能，从两个维度辅助客户在大数据可观测性上进行实践。日报功能在日报中，我们会保存30天的集群日报分析，以分数的形式定量的给客户集群打分，在日报具体报告中，我们会给客户客户具体的分析，分析到客户不同组件，不同维度的一些实际问题。除了打分之外，我们在每个模块还提供用户对现有问题可操作的解决方案，如下图计算资源分析中，我们列举出内存利用率低的问题，并建议用户根据我们提供的作业数据进行优化。EMR Doctor 不仅在集群维度进行打分、分析，对 metrics 数据，元数据进行分析，对于具体的细节数据，比如任务运行等，也给出了分析数据，满足使用方的需求。比如对于计算任务，我们会给出Top 50算力使用的详细说明，如 appid，sql 语句，引擎类型，算力使用，配置信息以及评分和健康状态，并根据问题进行建议。此外，我们根据不同组大数据组件的需求，提供多种的看板，如在 hive 中我们可以对库、表问题进行分析，Hive表的一些详细信息分析如下图。实时功能在实时功能中，EMR Doctor 为用户提供最近5分钟粒度的集群分析，着重于集群的问题排查，尤其是多种因素引起的问题汇总，获得潜在的根因。目前，实时分析之前多种计算引擎和YARN的分析。如下图，通过对5分钟数据的汇总，能够获得用户的一些任务问题，如数据倾斜、长尾，资源不足风险等，并且给出建议。总结整体产品上，EMR Doctor 为大数据客户提供一个集群维度的健康状态，让大数据集群可观测、可量化，为管理层，集群管理员以及用户提供不同的视角去了解现有集群的健康情况，满足各方的需求，从而推动大数据集群更健康的发展。此外，EMR 平台在不断的发展演进，对于大数据可观测性的实践会越发深入，更多的组件，更多的细化分析都会随着产品迭代不断加入，期望带给 EMR 客户更好的高附加值体验。EMR Doctor 官网链接 https://help.aliyun.com/document_detail/442435.html 欢迎感兴趣的朋友加入钉钉交流群（钉钉搜索群号44846846 或 钉钉扫描下方二维码）
-
发表了文章 2023-02-21
阿里云EMR 2.0：兼容开源，贡献开源，超越开源
摘要：本文整理自阿里云资深技术专家吴威(无谓)在 阿里云EMR2.0线上发布会 的分享。本篇内容主要分为三个部分：兼容开源阶段贡献开源阶段超越开源阶段点击查看直播回放兼容开源阶段开源这个词在最近这几年异常的火爆，各行各业的各个厂商纷纷宣布拥抱开源并且支持开源生态。尤其在大数据这个领域，开源技术已经成为了推动整个大数据技术演进和行业发展的最重要的一股力量，同时开源技术栈也成为大数据行业的一个技术标准。阿里云EMR 作为开源大数据平台，集成了众多主流开源引擎比如 Spark、Flink、 StarRocks 等，这些引擎共同基于 EMR 计算资源底座以及数据湖存储底座，在适配阿里云生态技术栈的同时，兼容开源是 EMR 团队的一项重要工作。 事实上，阿里巴巴集团在十三年前就开始投资开源大数据领域，经过十几年的发展和进步，现在我们的开源大数据平台已经成为阿里巴巴大数据技术体系中的中坚力量。 接下去我简单分享一下阿里开源大数据技术的演进路线。 2008和2009年，阿里巴巴最主力的业务线是淘宝和天猫，其上的电商业务爆发式增长，同时业务数据也出现了大爆发，我们需要大数据技术去处理海量的业务数据，当时一度出现技术跟不上业务发展的节奏。我们在2009年选择了 Apache Hadoop 技术去支撑大数据分析业务，上线的第一个集群就达到200台规模，并且在一年内快速增长到1000台，在2014年具备跨数据中心的集群管理能力，单个开源 Hadoop 集群达到过万台的规模。开源大数据技术对阿里巴巴核心业务的发展起到了非常关键的支撑作用。这个阶段阿里巴巴是开源的受益者。 贡献开源阶段2014年之后，因为我们在内部业务上积累了大量开源使用经验，做了不少最佳实践沉淀，我们的开源团队也转到了云上，并于2016年在阿里云推出了 EMR 产品，发现云上有更加旺盛的开源大数据的需求。 与此同时，2015年在阿里巴巴搜索推荐广告业务线上，数据实时化的需求非常强烈，我们希望搜索引擎能够搜索到实时更新的宝贝并根据用户的实时行为进行推荐，当时我们选择了 Apache Flink 作为新一代的实时计算引擎，在2016年将其上线并得到了非常好的效果。在2018年的时候，Flink 和 EMR 一样开始上云。2019年我们不仅收购了 Flink 在欧洲的创始公司，还把阿里巴巴积累多年的 Flink 分支 Blink 完全贡献给了 Apache 社区。同时我们也不断地对 Flink 进行了技术创新，推出了 Flink CDC、Flink Table Store 等新的开源技术项目。 回过头再看 EMR，自2016年在公有云上线之后，已经服务了数千家中小企业，支持他们在云上更好地使用开源大数据。目前 EMR 也经过了技术升级， 从经典的 Hadoop 架构升级到了数据湖存算分离的架构。与此同时我们也保持了整个开源大数据平台的开放性，跟国内外知名的开源大数据厂商比如 Elasticsearch、Cloudera、Databricks 等建立了密切的合作伙伴关系，并且联合推出了开源大数据的产品，在云上共建开源大数据生态。 以 Apache Celeborn 项目为例，可以看到阿里巴巴从2009年开始使用开源大数据技术，经历了十数年回馈和共建，最终希望进入到一个引领开源，推动开源发展的阶段。2022年10月份阿里巴巴向 Apache 孵化器捐赠了 Celeborn 项目（也就是原来的 EMR Remote Shuffle Service 项目 ），这是在阿里云上诞生的第一个 Apache 孵化项目。随着大数据上云趋势越来越明显，云原生架构和理念也在不断强化和推行，比如存算分离架构等都是云上特有的架构属性。在此技术背景之下，我们发现在 Spark、Hive 、Flink 等都有数据 Shuffle 的需求，并且因为云原生架构上没有 Hadoop YARN NodeManager 等服务，无法很好的支持 Shuffle 场景，也无法实现动态资源伸缩等核心功能。因此，阿里云EMR 率先提供了 Remote Shuffle Service，用一套数据 Shuffle 服务支持所有大数据计算引擎。Remote Shuffle Service 项目诞生后，又吸引了以小米为代表的多家阿里云上公司的兴趣。在2021年12月，我们和这些阿里云客户一起将这个项目开源，之后吸引了更多如 Shopee、网易等企业的开发者加入，这就是云带来的变化，云与开源结合后产生了化学反应。为了让更多公司参与共建，让项目产生更大的影响力，我们决定将这个项目捐献给 Apache 基金会，并且正式命名为 Celeborn，从孵化器项目起步，也希望 Celeborn 能够成为 Apache 的顶级项目。 超越开源阶段在兼容开源和贡献开源之外，EMR团队也在基于开源技术打造超越开源的企业级计算引擎，下面我以EMR Spark为例介绍他的企业级功能。首先是性能，EMR Spark 多次打破大数据领域的行业记录。比如在 Sortbenchmark 组织的 CloudSort 竞赛中，需要完成 100TB 数据排序的同时，花费的成本要尽可能的少，EMR Spark 在阿里云上实现了每 TB 仅花费 1.44美元的成绩，比之前在海外云平台上的最好成绩提升了3倍以上。 在另外一个大数据知名 Benchmark TPC-DS 中，EMR 同样多次刷新最好成绩，并且是通过 TPC 官方 Benchmark 认证的第一个公共云产品，EMR Spark 结合 JindoFS 实现的存算分离架构在性能和性价比上都有极大的提升，并且在功能上覆盖了 TPC-DS benchmark 数据加载、数据更新、串行查询、并行查询、数据可靠性测试等全流程，SparkSQL 的数据正确性通过 TPC 组织的审计。在数据规模上，EMR Spark 是首个通过官方认证的支持最大规格 100TB 数据集的系统。 接下去展开看一下 EMR Spark 的性能优化点。我们对计算引擎涉及到的几乎所有方面都有改进。比如在 SQL Runtime 方面，EMR Spark 从2019年就开始调研 Native codegen 以及向量化技术，通过将 Spark SQL 的执行流程或算子换成 Native engine，相对于 Spark 原生的 Java Codegen 引擎性能提升非常明显，Native engine 可以支持 TPC-DS 所有 SQL，有着非常高的 Spark SQL 算子覆盖度。 Spark Native engine 将在明年初通过内测版的形式开放给更多的客户。另外在 JSON 解析上，EMR Spark 通过 SIMDJSON 技术可以将复杂 Json 解析速度提升5倍以上，可以极大的加速 JSON 日志类数据的清理和 ETL 流程。 在 SQL 优化器上，我们实现了全新的 Join Reorder 算法 ，在超过10张表 Join 的场景 SQL Planner 效率有数倍提升，我们在动态分区裁剪的基础上实现了基于 BloomFilter 的过滤特性，进一步减少了大表的数据扫描量；另外，优化器还支持 Hive 表的分区统计信息和主外键约束信息，可以提供更加精细化的优化规则。 EMR Spark 针对数据湖存储在读写上都有深度优化，配合 JindoSDK 解决对象存储在大数据场景下的痛点。 在数据 Shuffle 的场景，配合前面提到的阿里巴巴开源项目 Celeborn，EMR Spark 支持 Push Based Shuffle，将 Shuffle 数据推送到远端的 Remote Shuffle Service 上，通过服务端的数据聚合可以极大的减少磁盘的 IO 数量，这项能力对大数据常用的 SATA 盘构建的集群特别友好，对于 Shuffle 数据量超过百TB的巨型作业，Shuffle read 时间可以降低数倍。同时 EMR Spark 还支持列式 Shuffle 能力，配合数据压缩功能可以将 Shuffle 数据量减少一倍以上，这样可以进一步降低 Shuffle 的网络 IO 开销，提升集群的整体性能和吞吐量。 在性能提升之外，EMR Spark 提供了企业级的诊断和调优能力。EMR 2.0 推出了 EMR Doctor 产品，它的功能就包括 Spark 作业的智能诊断，Doctor 使用 Java 探针技术，可以对 Spark 作业做异步数据采集，并将采集到的 Spark job、stage、task、sql 等信息统一汇总到 EMR 元数据仓库进行离线数据分析。Doctor 提供了集群的计算健康分，对每个作业健康状态做打分，并提供优化建议。基于 EMR 的这套机制，我们还为 Spark 提供了基于历史信息的优化能力（也就是 HBO）。针对 Spark 作业常用的内存、partition 数和 AQE Shuffle 参数，HBO 首先会采集每天作业执行过程中的各项指标，并在元数据仓库里进行分析，在应用特定的优化规则后产出更优的作业参数。假设每天的作业数据量变化不大，那么同样的 SQL 通过历史信息调优后可以做精确的 Planner。在典型的1TB TPC-DS Workload 中，使用 HBO 优化规则后可以将 SQL 查询性能提升 28%。 针对前面提到过很多次的云原生架构，在阿里云上的K8S服务主要由 ACK 和 ECI 两个产品提供，EMR Spark 支持 on ACK 形态，并且实际解决了非常多的架构适配问题，落地了不少生产型客户。EMR 采用虚拟集群的方式，直接在用户已有的 ACK 集群安装 Spark 相关组件。同时也提供独立的 RSS（Apache Celeborn）集群类型，可以优化容器环境下的 Shuffle 场景。Spark on ACK 支持常驻节点，可以运行 Spark operator 或者 Spark History Server 等常驻服务，也支持 ECI 实例部署方式，将 Spark 的 Executor 调度到 ECI 弹性实例上，可以进一步降低资源使用成本。 在 ACK 场景下 Spark 和 Celeborn 的集成可以让 Spark 具备传统 Hadoop YARN 集群里常用的动态资源伸缩能力，提升资源利用效率。异步非阻塞和高性能的列式 Shuffle 可以提升作业性能。使用高性能的本地化多副本存储以及多层存储方案可以提升 Spark 作业的稳定性。所以 EMR Spark 的云原生解决方案在功能、性能、稳定性以及成本和效率上都有考虑，是一套成熟的方案。 EMR Spark 是数据湖架构下的核心计算引擎，和多个模块有着深度整合。Spark 支持阿里云全托管的 HDFS 服务 OSS-HDFS，并在数据读写接口上有非常多的优化，包括前面提到的 parquet 和 orc 等格式的 native reader，以及在数据提交阶段的 job comitter 优化。另外，对于大数据中经常遇到的小文件问题，EMR Spark 提供了小文件合并能力，可以降低对存储系统的压力，同时提高读表的性能。 Emr Spark 还支持了数据湖构建也就是 DLF 产品，集成了 DLF 统一数据湖元数据和权限控制功能，借助 DLF 可以对 Spark 表进行存储分析和生命周期管理，对湖表格式进行自动化管理，比如小文件合并、排序、索引等功能。 在数据湖格式的集成上，EMR Spark 扩展了对 Delta lake 和 Hudi 的支持。在 Delta Lake 上我们实现了基于固定力度的缓慢变化维功能，借助 Delta Lake 的 checkpoint 和 Time travel 的能力，通过一些特殊的标记保留维度表的历史快照，并且不需要增加额外的冗余数据，通过 Spark 查询这些维度表，同时可以提升查询效率。 针对 Hudi，我们实现了一个全托管的 Hudi Metastore 服务，可以将分散的 Hudi 元数据进行集中管理，在解决了元数据一致性问题之后，EMR Spark 可以基于 Hudi Metastore 进行查询加速；除此之外，EMR 团队也是 Hudi 社区 CDC 功能的贡献者，在 EMR Spark 版本里已经提前支持了 Hudi CDC 能力。 以上就是 EMR Spark 在开源软件之上提供的企业级能力。阿里云EMR 团队将继续沿着兼容开源、贡献开源以及超越开源道路前进，为云上客户提供最佳的开源大数据解决方案。 欢迎对 EMR 感兴趣的朋友加入 EMR 钉钉交流群，一起交流和学习。
-
发表了文章 2023-02-17
基于数据湖格式构建流式增量数仓—CDC
摘要：本文整理自阿里云开源大数据平台技术专家毕岩(寻径)在 Apache Con ASIA 的分享。本篇内容主要分为四个部分：湖格式& Hudi & CDC湖格式设计实现 CDC 的思考Hudi CDC 实现湖格式 Streaming 的优化2021年中 Databricks 发布了一篇基于 Delta Lake 实现 CDC 场景的介绍文档，2022年初我们在阿里云EMR 内部 Delta Lake 版本实现的 CDC 的能力，同期在 Apache Hudi 提案了 Hudi 基于 Spark 实现 CDC 的设计文档和实现代码。结合这些经验，今天以 Apache Hudi 为主，分享一下数据湖格式上实现 CDC 的一些思考和注意点，以及一些流式 streaming 通用的优化点，和 Hudi CDC 的后续规划。湖格式 & Hudi & CDC 该部分主要介绍下此次分享涉及到的一些概念，包括湖仓、数据湖格式、Apache Hudi，以及 Change Data Capture（CDC）的一些需要了解的东西。湖仓 & 湖格式相信大家对于数据仓库，数据湖，进而到两者结合的湖仓的演变有了一些了解，这里就不过多介绍了。湖仓（LakeHouse）有以下一些关键特性。介绍几个关键特性：ACID 事务：同一张表经常会同时有多个工作流来读写，事务保证了我们能够读、写到正确的数据；Schema Enforcement 和数据管理：可以加上 Schema Evolution。Enforcement 在 Databicks 相关文章解释上等同于 Valication，在写入数据时，严格检测 schema 并要求和目标表定义的一致。Schema Evolution 允许修改表的字段信息（如增删字段，修改字段类型和描述等）。另外，湖仓还应提供健壮的湖表治理和审计的能力；支持结构/非结构数据，支持多类API：湖仓架构能够支持半/非结构化数据（如JSON，图像，语音等）的存储，以及提供除了基本SQL之外丰富的API来处理数据，应用在如机器学习等场景；批流一体：数据湖提出之初，很重要的就是替代 Lambda 架构，批流一体能够有效的简化流式和离线两条数据链路的开发和运维成本；存算分离：成本是各个公司都需要关注的。如果存储和计算都能按需伸缩，会更便于精细化控制成本。我们发现大部分的湖仓关键特性是需要由底层存储之上的数据组织方式，即数据湖格式来提供的，我认为这也是 DeltaLake、Apache Hudi，Apache Iceberg 近两年兴起的主要背景和原因吧。Apache HudiApache Hudi 是一个构建于自管理数据库层之上的，使用增量数据流来构建数据湖的一个功能丰富的平台。相对于其他湖格式，Hudi具备更细粒度的数据布局（FileGroup），支持多种索引提升 Upsert 性能，以及在开源版本上较为丰富的自动化湖表管理能力。CDCChange Data Capture：定义了一种场景，即识别并捕获数据库表中数据的变更，并交付给下游进一步处理。CDC是对针对行级数据记录的。其中数据的变更信息，即 CDC 的数据结构，包括变更是什么样的操作（有三类：insert，update，delete），变更发生的时间点，以及变更前后的数据。显然对于insert操作该记录的变更信息中是没有旧值的，对于 delete 操作该记录的变更信息中是没有新值（当前值）的。CDC 典型方法CDC 不是数据湖格式特有的概念和场景，它存在已久。并且在传统数据库有些一些典型的方法：时间戳/版本号：是在表上添加一个类似于 created_time 和 last_modified_time 这样的字段，标识记录的创建时间和最新修改时间，查询时根据 modified_time 做过滤，得到变化的数据。这个方法有几个明显的缺点:不能感知到delete的变化。不能直接获取得到update的旧值，因此这类方案仅适用于没有delete操作，且不关注旧值的业务场景。由于没有快照或者版本的概念，不能准确的捕捉每次变更。表Diff：通过对比表的前后两个状态或者快照的数据来获取 CDC 数据。由于要做Diff，就会有快照间 Join 操作，该方法查询性能较差，且占用更多的计算资源。数据库的触发器：有些数据库如 Oracel 等支持为 insert，update，delete 操作创建触发器。在执行 insert/update/delete 操作时，自动将旧值和新值，以及操作类型，和时间戳等信息写入另外一张影子表。由于直接将变更的数据写入到了另外一张表，可以直接使用 sql 查询得到，查询性能和语法支持都较好。但这个方法增加了写入时开销。事务日志：目前数据库会保留了表的操作事务日志，用于备份和系统恢复。我们可以从这里面提取出 CDC 数据，像 MySQL，RDS 等这类数据库都支持。该方法不会增加写入的开销，但获取 CDC 数据需要从事务日志解析出来，同时由于事务日志会定期归档，不会永久保存，需要及时读取出来，这也就是我们通常会对接 Kafka 来消费 binlog 的场景。CDC 场景示例上图定义了一个通用的数仓场景，user_city_tbl 和 user_name_tbl 维表做 Join 操作将打宽后的数据更新到 user_name_city_tbl中（类似于 ODS 到 DWD 的链路）。user_name_city_tbl 按 city 聚合统计出城市的常驻人口后同步成 city_population_tbl（类似 DWD 到 DWS 的链路）。在没有实际 CDC 功能的场景下，传统数仓的解决方案一般是基于 Kafka 里的流式数据生成 ODS、DWD、DWS 的各层数据，便于查询实时的数据，同时小时/天粒度做离线的全表/分区的ETL修复数据用于历史查询使用。如上例离线方式，user_city_tbl 每次更新后，需要全表和 user_name_tbl 做 Join，然后 overwrite 到 user_name_city_tbl，后续也需要全表按 city 聚合 overwrite 到完整的 city_population 表中。很难兼得增量数据处理、实时性、低管理运维成本这几个方面。在具备 CDC 的场景下，只需要一个流式 workflow 即可。如 user_city 表变更后得到change data，仅将这部分数据和 user_name 表做 Join，就可以针对 user1 更新 city 信息，将新数据 user5 对应的记录通过 upsert 语法（Merge Into）同步至 user_name_city_tbl 中。同时得到 user_name_city_tbl 的变更数据（user1的 city 从 bj 变更为 hz，新增 user5 记录及对应的 name 和 city 的值），实现对 bj city 的人口数减一，对 hz 和 wh 两个 city 字段加一。仅使用一条流式 workflow，能够实时的将增量变更信息同步更新至下游。举例补充另外一个场景：银行通过获取当天凌晨和前一天凌晨之间的账户金额变更来检测账户的健康程度。若有两个账户，A全天账户没任何操作，而账户B全天操作上百次，但最终金额也没有变化。如果单纯的比较前一天凌晨和当天的账户金额是否变化是没办法判断账户的健康指标的。对于类似场景，CDC 的解决方案中需要具备追溯每一次的变更的能力。综合这些场景，梳理了 CDC 这个场景应该具备以下能力：变更信息中应该包含所有的表字段，不能仅包括主键的；对于 delete/update 操作，应该包括操作前的旧值；能追溯每一次的变更。CDC 输出格式最后，我们来看下 CDC 的输出格式。关于 CDC 的输出格式，我认为只要包含了全局的变更信息，包括操作类型，操作时间或对应版本，以及前后值就足够。这里列出了典型的 debezium 的格式，和上面场景示例中使用的格式，也是 deltalake 所采用的。debezium 是一个较为通用的格式，便于集成到已有系统中，而在部分场景 deltalake 自定义的格式对SQL查询更友好。湖格式设计实现 CDC 的思考CDC 设计前面介绍了在数据库中典型的 CDC 方法，但数据湖格式较数据库、传统基于 Hive 的数仓还是有很大不同的。湖格式的特点：支持多版本/多快照。基于这个特性，至少可以使用表 Diff 的方法来获取 CDC 数据。每个版本准确的映射到一组有效数据文件，且单次操作会在文件元数据层面记录数据文件的变更，即每次操作（如insert，merge into等）会将新增数据文件标记为有效的，历史部分数据文件在当前版本被标记为无效。没有常驻服务，操作依赖现有的计算引擎 Spark 或者 Flink。没有后台处理进程，那类似于数据库触发器的方法，是没办法由后台执行，如果需要只能在当前操作时间内完成，增加部分写开销。在设计湖格式支持 CDC 需要考虑到：CDC 各场景能力的覆盖，包括上述提到的较为复杂的。至于提供的信息是否被需要由下游场景决定，但湖格式本身要能将需要的 CDC 相关信息都交付给下游。读写性能。类似于触发器或者事务日志的方式，需要记录额外的信息，要考虑到对写入性能的影响；同样对于表 Diff 这样的方式，要考虑到查询读取性能。约定输出格式。传统数据库的 CDC 方法中，时间戳或者版本号的方法在场景支持上的缺陷；湖格式没有自己常驻服务，不存在事务日志，因此我们先来看下表 Diff 的实现方式。其原理就是基于湖格式本身的 time-travel 查询历史版本的能力，和后续的版本逐一做 Diff 得到 CDC 数据。优点是不会增加写入开销，缺点是查询性能差。如果我们想要进一步优化查询性能，可能的思路就是降低 Diff 或 Join 的粒度，从最差做全表的 Diff，到仅做当前 commit 涉及到的分区级 Diff，再进一步按桶等等。DeltaLake 可以通过当前 commit 内新增文件和被标记无效的文件之间来做。Hudi 本身具备分区级更小的 FileGroup 文件组的概念，也可以减少 Diff 的数据量。再看一下 DeltaLake 在 CDC 场景的实现方案 CDF，Change Data Feed。其核心在于数据写入时直接持久化 CDC 数据。类似于数据库 trigger 的方式，直接保存 CDC 需要的所有信息，查询时直接加载这部分数据。优点是查询性能最好，缺点是增加了写开销。如果继续在这个方案下做一些优化：根据不同的操作，避免每次commit都持久化。比如数据首次写入表，那么所有的数据本身一定都是insert操作类型的。这种就不需要再额外双写一份CDC数据。如果表有主键，那可以仅持久化主键，然后将前后两个版本含主键的数据加载成两个map结构，分别以点查的方式获取旧值和当前值。若前值为空，该变更为insert操作，若新值为空，该操作为delete操作，否则即为update操作；这样减少持久化的数据量，也就减少了写时开销；当然也可以同时持久化记录的操作类型，来更准确的获取旧值和当前值。我们结合以下两个场景来考虑这两个方案：上游数据完成一次 commit，下游何时消费是不确定的，很可能一次性消费几个 commit 的 CDC，采用表 Diff 的方式，需要 Diff 每两个相邻版本，性能随 commit 的数量成倍下降；实际的 streaming 场景，每 batch 更新全表数据量占比很小，我接触的场景占比小于0.0003。当然不同场景占比是不同的，但显然较低的占比，使得写入时增加的开销是可以接受的。基于以上考虑，Databricks 和阿里云EMR 在 DeltaLake 的实现都采用了 CDF 的方案，同时阿里云EMR 团队贡献到 Apache Hudi 社区的也是基于此实现。CDC 实现确定了以 Change Data Feed 作为设计方案后，就需要考虑是具体实现上的注意事项了。首先是写入。针对不同湖格式各类写操作，明确涉及到的文件元数据变化。CDF 方案下可优化的第一点是根据不同的操作，判断是否需要持久化 CDC 数据。也就是一部分操作的变更信息直接读取 CDC 文件，而另一部分操作的表更信息就从普通的数据文件中提取转换。但是不同的湖格式对不同的操作有自己的定义，因此要具体湖格式具体分析。比如 DeltaLake 的 Insert Into/Insert Overwrite、Update，Delete，Merge 等操作就是我们正常认知的。而 hudi 由于引入了主键 recordKey 和比较建 preCombineField 的概念，即使是简单的 Insert Into 的 SQL 语法可能对应实际逻辑是 Update 操作。针对 CDC 场景涉及到的写操作，明确需要拓展 CDF 能力的场景。湖格式内置很多湖表管理操作，如 DeltaLake 的 vacuum 和 Hudi 的 Clean 用于清理历史数据， DeltaLake 的 optimize 和 Hudi 的 clustering 用于合并小文件和做 zorder，Hudi 的 compaction 针对 mor 表合并增量数据文件等，这些操作都不会涉及到实际表的数据文件，仅仅是清理文件或者对数据重分布而已，是不需要关注和处理的，在查询时遇到这些操作，可直接忽略。而其他 DML 操作是直接修改表的数据，需要感知并处理的。这里举例说明下：对于 Insert Into 操作，DeltaLake 不会读取任何其他已有文件，仅新增数据文件。因此 DeltaLake 实现 CDF 方案执行 Insert Into 不需额外再持久化，而仅需查询时加载到这批文件，将数据转换成约定的输出格式。但在 Hudi 内由于有数据 combine 的逻辑或者将数据写入现存的小文件的优化，会读取已有文件再重写，因此就需要持久化 CDC 数据。对于 drop partition 操作，DeltaLake（社区版本不支持 drop partition，阿里云EMR 版本支持）和 Hudi 都直接将该分区的所有数据文件都标记为删除。这样也不需要持久化任何信息，查询时找到这些文件，加载并将每条记录标记为delete的操作类型，添加上其他如时间戳信息即可。对于 update 操作，最底层的操作一定是加载满足 where 条件记录的数据文件，更新满足 where 条件的那部分数据，然后连同未修改的数据直接一起写入到新文件。这样的情况下，就需要拓展 CDF 能力。最后在具体实现上，我们还要注意以下几点：持久化的 cdc 数据需要保存到文件系统中，可能会改变原本的表的文件布局，这样的改变可能会对其他操作语义，如湖管理功能造成影响，必要时需要联动调整；额外的 cdc 写入操作依然要保证 ACID 的语义。基于 CDF 方案的实现了写操作后，查询变更数据时就会遇到这三类文件：持久化的cdc数据文件。在正常情况下，CDC 数据文件记录了完全的 cdc 数据信息，包括变化数据的操作类型，旧值和新值，可以直接加载读取返回。全为新数据的文件。如 Insert Into 操作引起的，查询时对每条来自这样文件的数据添加上值为insert的操作类型字段，和其他信息。全为被删除的文件。如 drop partition 操作引起的，查询时对每条来自这样文件的数据添加上值为delete的操作类型字段，和其他信息。上图右侧为抽象的一个数据结构 CDCFileSplit，主要的字段是 cdcFileType 和 filePath：filePath 为 CDC 查询时涉及到的数据文件，可能为 CDC 数据文件或者普通的数据文件。cdcFileType 标识 filePath 是哪类文件，也因此决定了如何从该文件中抽取解析 cdc 数据的具体逻辑。在讨论 CDF 方案可优化点时提到，对于有主键概念的表可以仅持久化主键（和操作类型）来减少写时开销。那么就需要另外两个包含了该主键对应的旧值和当前值的数据文件 preImageFilePath 和 postImageFilePath，来平衡对写时开销较为在意的场景。Hudi CDC 实现结合 Apache Hudi 我们来看下具体实现。Hudi CDC Write 实现由于引入了主键和比较键的概念，Hudi 抽象了自己的写操作类型，如上图左侧所示。其中有普通 Insert/Upsert/Insert Overwrite 等常规写操作，也有 Cluster/Cmpact 等这样的湖管理操作。同上面提到写时优化的一些思考，我们仅需要关注标红的普通写操作，而可以直接忽略湖表管理操作。同样由于有了自己的写操作语义，Hudi 抽象了两类写处理方式：其中HoodieWriteHandle（上图中有笔误）的子类 HoodieMergeHandler 是数据执行 upsert 的核心逻辑，将新数据和同一个主键的老数据（如果存在）合并，最终写入数据文件。而 HoodieWriteHandle 的其他子类处理的是非合并场景下的写入操作，如 bulk_insert 等。因此 HoodieMergeHandle 也就是我们之前提到的在必要的场景下要拓展 CDF 能力的地方。DeltaLake 和 Hudi 的 CDC 查询流程基本一致，但由于数据布局的不同，在实现细节上也有不同。以 Hudi 为例来看一下湖格式上完整的 cdc 查询流程：根据请求指定的 start，end 区间，获取关联到的 commit 信息，然后根据 commit 中的写操作过滤掉湖表管理这些不影响数据的 commit；根据每个 commit 的写操作，或是读取 cdc 数据文件，或是加载当前版本的数据文件，或是加载前一个版本的数据文件，得到一个类似于前面提到的 CDCFileSplit 的对象列表（对应到 Hudi 代码中的 HoodieCDCFileSplit）。按 CDCFileSplit 中的 cdcFileType 定义的加载策略，从文件中提取、解析成 cdc 数据，直接 union 返回。Hudi CDC 使用示例Hudi 端开启 CDC 的方式也是很简单的。建表 SQL 时或者 Spark DataFrame 写入时开启 hoodie.table.cdc.enabled 参数即可。这样数据写入时会自动持久化必要的 CDC 数据。查询时指定 cdc 的查询类型，及 start 和 end 的区间。补充说明：按当前实现查询时需要将 query.type 的配置调整为：hoodie.datasource.query.type = incremental hoodie.datasource.query.incremental.format = cdc同时支持 CDC 持久化选择持久化的类型，参数为：hoodie.table.cdc.supplemental.logging.name默认值为 data_before_after，会持久化所有 CDC 数据，查询时不再需要加载其他数据文件，利用提高 CDC 查询效率。其他可选值为 op_key_only 和 data_before，仅持久化操作类型和主键，或者额外多持久化旧值，这样写入时减少了一点 overhead，但查询时需要加载其他数据文件来获取确实的旧值当前值。Hudi CDC 后续规划目前 Hudi 已经完整支持了 Flink 和 Spark 两个引擎的 CDC 读写功能。后续将会继续拓展 Spark SQL 语法，便于查询 CDC 数据；同时支持类似 DeltaLake 的扁平化的 CDC 输出格式，给 Hudi 用户另外一种选择集成到自己的数仓场景中。目前 Hudi 已经完整支持了 Flink 和 Spark 两个引擎的 CDC 读写功能。后续将会继续拓展 Spark SQL 语法，便于查询 CDC 数据；同时支持类似 DeltaLake 的扁平化的 CDC 输出格式，给 Hudi 用户另外一种选择集成到自己的数仓场景中。湖格式Streaming 的优化CDC 大多还是用于 streaming 场景，构建增量实时数仓，遇到的问题也是 streaming 通用的。这里列举两类。Apache Hudi 或者阿里云EMR 版本的 DeltaLake 等湖格式都具备表的自管理能力，如定期清理历史数据文件的 vacuum（DeltaLake）和 clean（Hudi）操作，和合并小文件做 Zorder 优化的 optimize（DeltaLake）和 clustering（Hudi）操作。但这些如果放到 streaming 任务中某次 batch提交后操作，会占用当前 batch 的执行时间，影响写入性能，甚至有些场景直接导致任务失败，影响正常的写入流程。Streaming 任务实现复杂：基于 Spark Streaming 开发流式任务目前需要通过 dataframe 的 API 来实现，没有像离线场景的 SQL 语法那样简单。针对这两类问题，介绍以下阿里云EMR 团队的解决方案。应对第一类问题，阿里云EMR 在 Data Lake Formation 数据湖构建产品上支持了自动化湖表管理。在实际生产使用中，我们可以在流式 workflow 中关闭 DeltaLake 或者 Hudi 的定期执行表管理的功能，推送 commit 信息到 DLF 服务端。DLF 会结合我们定义的策略，结合表的实时指标，来判断和采取相应的湖表管理操作。不同于定期执行的无脑式执行，DLF 可以精细化的感知湖格式表的状态，比如实时分析历史过期数据的占比，根据对应策略中的阈值判断是否提交 clean 或 vacuum 任务来清理，再比如自动感知以时间分区的表的分区状态，自动对刚完成写入的分区执行小文件合并类的任务。另外，DLF 执行的湖管理任务是单独启动，不在当前的流式任务中，不影响正常的写入和性能。应对第二类 Streaming 任务实现复杂问题，阿里云EMR 拓展了 Spark 的 SQL 语法，实现了 StreamingSQL。如上述示例，左侧分别创建了 Hudi 目标表，和一张 Kafka 的源表。右侧是拓展的 StreamingSQL 语法，CREATE SCAN 创建一个关联到 Kafka 源表的流式视图；CREATE STREAM 语法创建流，消费 Kafka 数据并按用户给定的 SQL（示例中位 Merge Into 语法）完成写入操作。这样，我们可以极大的简化任务的开发和运维成本。欢迎对 EMR 感兴趣的朋友加入 EMR 钉钉交流群，一起交流和学习。
-
发表了文章 2023-02-15
阿里云EMR2.0平台：让大数据更简单
摘要：本文整理自阿里云资深技术专家李钰(绝顶)在 阿里云EMR2.0线上发布会 的分享。本篇内容主要分为三个部分：EMR 平台概述EMR2.0 新平台核心能力总结点击查看直播回放一、EMR 平台概述 EMR 平台是开源大数据的云原生运行环境，阿里云EMR 根据云原生的特点，在弹性伸缩、稳定性、智能化和研发效能四个方面进行了大量的功能优化：Elasticity 弹性伸缩，算力按需申请释放，突破IDC物理限制； Stability 稳定性，故障节点自动替换补偿，关键事件自动告警； Intelligence 智能化，智能探查资源浪费，预警集群潜在风险； Efficiency 研发效能，业务高效开发调试，作业一键调度上线。 二、EMR2.0 新平台核心能力 Elasticity 弹性 基于时间的弹性伸缩能力 弹性规则：定时增加或者减少 ECS 实例数量； 适用场景：业务负载变化存在时间周期性； 成本节省：通过采取这种策略，与预置固定资源相比可以节省大量资源；使用抢占式实例可以进一步降低成本； 使用方式：在节点组上设置扩容规则的时候，选择按时间扩容；支持以下设置：执行频率和执行时间；规则的有效期；重试过期时间；单次扩容的节点数等。 基于指标的弹性伸缩能力 弹性规则：通过预设的基于负载指标的规则，动态调整 ECS 实例数量；适用场景：业务负载动态变化，无固定时间周期性；成本节省：通过采取这种策略，可以动态的适应业务负载的变化；使用抢占式实例可以进一步降低成本；使用方式：在节点组上设置扩容规则的时候，选择按负载扩容；支持以下设置：集群负载指标（比如“YARN 资源队列 pending 应用数”）；指标统计周期和统计规则；重复几次后扩容；单次扩容的节点数；冷却时间等。支持抢占式实例 能力：支持实例规格筛选，单节点组可选择多达10种不同规格；成本优化策略支持自动选取低价实例规格出价；效果：生产实证可降低80%+成本；典型客户案例支撑；使用方式：创建抢占式实例节点组：在集群创建完成后，新增抢占式实例的节点组； 选择实例规格： 节点组的配置中选择抢占式实例规格，最多可以选择十种规格，可以根据每种规格的释放率和折扣率进行取舍； 同时也支持按照资源筛选规格，比如：4核16G； 支持两种不同的策略： 优先级策略，节点组所有实例都必须使用抢占式实例，然后按照设定的优先级顺序申请抢占式实例； 优势：最大化的降低成本； 劣势：抢占式实例库存不足时，业务无法及时获取到所需资源； 成本优化策略，会智能的优先使用抢占式实例，在抢占式实例库存不足时会补充按量实例； 优势：在及时响应业务资源需求和综合成本上达到较好的平衡。 性能大幅提升 EMR新平台相比于老平台在性能上得到了大幅提升，主要体现在以下三个方面：a. 高并行能力 节点组内和多节点组间均支持并行扩容支持缩容期间并行扩容，支持突发业务变化 b. 快速响应能力更高的弹性速度，100节点扩容时间<2分钟更快的感应速度，指标检测周期<30秒； c. 大规模服务能力单次支持扩容节点数>1000； 下图中右边的柱状图显示了 EMR1.0 和 EMR2.0 平台弹性扩容速度的对比，可以看到，EMR2.0 新平台对于不同规模的弹性扩容速度都可以稳定的控制在两分钟之内，扩容时间不会随扩容节点数增加线性增长。Stability 稳定性支持节点故障容忍和补偿EMR新平台支持节点故障容忍和补偿，主要体现在两个方面： a. 故障节点不影响扩容Core/Task 节点 CPU 打满不影响扩容；Core/Task 节点 OS Hang 不影响扩容；Core/Task 节点宕机不影响扩容； b. 计算节点故障自动替换补偿Task 节点 OS Hang 支持自动补偿；Task 节点磁盘满支持自动补偿；Task 节点网络问题支持自动补偿； 节点故障容忍和补偿需要手动开启。根据后台统计，在开启后，集群全场景稳定性可提升1个9。更加全面的服务巡检和事件通知 a. 服务巡检在集群服务页面可以看到所有的大数据引擎服务，以及每个引擎组件的健康状态；针对不同组件的健康检查项进行持续巡检，并实时上报；帮助用户及时发现和解决问题； b. 事件通知在集群监控页面，增加了事件中心，事件可按时间/类型/等级进行筛选；比如：在下图右下的截图中显示Critical等级事件“Spark_HistoryServer组件健康状态异常”，用户可以筛选Critical级别事件，并进行针对性的处理；关键性事件可订阅实时告警，从而更及时的发现问题并进行处理； Intelligence 智能化 EMR 新平台智能化能力主要体现在 EMR 新产品 EMR Doctor 的能力。EMR Doctor 致力于帮助用户更好的进行大数据集群的管理和运维。 EMR Doctor 通过集群日报和实时检测的功能达到避免资源浪费、风险提前预警和实时分析建议的核心效果。 EMR Doctor 避免资源浪费 a. 通过健康检查服务的集群日报功能查看集群是否存在资源浪费；针对集群日报中不健康的报告可以点击“查看报告”；比如：在下图左下的截图中显示“内存利用率较低”； b. 通过任务评分倒排 Top N，找到资源浪费最多的作业进行优化；在发现“内存利用率较低”的问题后进入详情页面找到资源浪费最多的作业；点击进入作业详情页面，根据提供的优化建议对这些作业进行优化； c. 通过持续优化，最大化利用资源，避免浪费。EMR Doctor 风险提前预警集群日报功能的另一个核心效果是风险提前预警。 a. 可能影响集群健康的问题小文件或者冷数据占比过大；数据本地化率低；计算任务激增导致资源消耗过快； b. 可能的解决方案：小文件数量过多：提前进行整合处理；冷数据占比过大：进行数据分层，将冷数据分层放置到低成本存储（例如 OSS）上，降低整体成本；数据本地化率低：进行提前提升，避免业务访问延迟计算任务激增导致资源消耗过快：提前增加资源，避免资源不足导致的业务等待和受损； 总体来说，针对集群出现的健康问题，集群日报能够给出预警，实现提前发现、提前处理。 EMR Doctor 实时分析建议 通过健康检查服务的实时检测功能，触发实时分析并查看建议；实时检测功能覆盖 Yarn 队列实时资源用量，当前资源浪费作业 Top N，存储数据实时本地化率等；集群整体变慢或者业务无法提交时，可以触发实时检测辅助诊断和运维。 Efficiency 研发效能 EMR 新平台推出全新 EMR Studio 的 Serverless 服务，主要包括两方面：全托管 Notebook 服务和全托管 Workflow 服务，通过这两个服务实现交互式大数据开发和调式，以及一键式作业调度上线的功能。 EMR Studio 交互式大数据开发和调试 EMR Studio 全托管 Notebook 服务：支持多种大数据引擎，包括：Spark、Hive、Trino、Impala、ClickHouse、StarRocks 等；即开即用，没有集群创建流程，无需额外购买云资源；兼容 Jupyter 使用习惯，无缝对接 EMR 各计算/存储引擎，方便用户通过 Notebook 提交作业到 EMR 资源集群，进行运行和验证。 EMR Studio 一键式大数据作业调度和上线 EMR Studio 全托管 Workflow 服务；即开即用，没有集群创建流程，无需额外购买云资源；兼容 Apache DolphinScheduler，无缝对接 EMR 集群；方便用户在工作流定义中加入 EMR Notebook 上面已经开发和调试完的作业，进行调度和上线； 同时，EMR Studio Workflow 还计划支持调度其他云产品创建的作业，比如阿里云VVP 等。 EMR Notebook 和 Workflow 产品目前均处于邀测状态，欢迎有兴趣的朋友联系我们申请试用。 总结：EMR 新平台的“黑科技” 最后，让我们一起回顾一下EMR新平台的“黑科技”。 a. Elasticity 降本增效快速灵活的弹性伸缩能力；全方位支持抢占式实例； b. Stability 稳定便捷故障节点自动发现和补偿；自动实时巡检；事件告警通知； c. Intelligence 智能辅助避免资源浪费；风险提前预警；实时分析建议； d. Efficiency 高效开发交互式开发调试；一键调度上线； 以上是 EMR 2.0 新平台的核心能力，欢迎大家使用和反馈。 欢迎对 EMR 感兴趣的朋友加入 EMR 钉钉交流群，一起交流和学习。
-
发表了文章 2023-02-08
StarRocks 2.5 LTS 版本新特性介绍及阿里云EMR Serverless StarRocks火热邀测中
🎉 StarRocks 2.5 版本发布啦！核心功能有：Catalog 支持 Delta Lake、支持 Apache Hudi MOR 表、支持查询湖上 MAP及STRUCT 数据类型、提供 Local Cache；多表物化视图支持基于外表、物化视图创建，并支持查询改写；支持 Query Cache；支持 Lambda 表达式和高阶函数；主键模型表支持条件更新等。2.5 版本也将是 StarRocks 的 LTS（Long Term Support）版本，欢迎伙伴们使用体验。✨ StaRocks GitHub 地址：https://github.com/StarRocks/starrocksStarRocks 2.5版本介绍StarRocks 是新一代极速全场景MPP（Massively Parallel Processing）数据平台，致力于让用户无需经过复杂的预处理，就可以支持多种数据分析场景的极速分析。StarRocks 相信数据科学的创新将全面驱动业务发展，希望能帮助企业建立“极速统一”的湖仓新范式，助力企业全面数字化经营。2.5 版本是 3.0 之前的最后一个版本，囊括了很多重要功能。在 2.5 版本中：数据湖进一步增强，在数据源生态、查询速度、使用体验上都做了大量优化，让您可以更加方便、快捷地进行数据湖分析。多表物化视图进一步完善，在物化视图构建、刷新机制优化上都取得了新的进展，并且支持了透明加速，让您可以更加方便地基于物化视图来简化数据建模流程。Query Cache 让“语意等价”的查询性能更上一层楼。Lambda 表达式和高阶函数让您的查询分析更加灵活。主键模型的条件更新能够解决乱序数据更新问题。2.5 版本的功能较多，下文挑选了几个重要功能进行详细介绍。新增核心功能介绍1、Data Lake Analytics2.5 版本对数据湖进行了大量增强，具体包括：更多数据源生态对接支持 Delta Lake Catalog：使您无需数据迁移，即可分析 Delta Lake 当中的数据。支持 Apache Hudi 的 MOR 表：借助该特性，在数据实时入湖场景（例如上游 Apache Flink CDC 到 Hudi），StarRocks 就可以更好地支持用户对实时落盘数据的分析需求。支持 Parquet/ORC 文件外表：您无需借助 Metastore 也可以直接对 DFS/对象存储的文件直接进行分析。支持集成AWS Glue作为湖分析的 Metastore（支持 Apache Hive / Apache Hudi / Apache Iceberg / Deltalake），更好的对接 AWS 公有云生态。更快的查询性能支持 Local Cache：通过对切分后的原始文件进行本地缓存（支持本地磁盘和内存作为混合存储介质），在热点查询场景下大幅度提升从对象存储的数据拉取效率，进一步提升数据湖分析的性能，测试结果接近 StarRocks 内部表。优化 Apache Hive, Apache Hudi, Apache Iceberg 在查询规划阶段的元数据访问效率。更好的查询体验开箱即用的 Meta Cache Policy：借助该特性，Adhoc 场景里的业务团队无需关心和感知具体的分区数据更新，也可以在 StarRocks 访问到保证正确性的数据结果。湖分析支持 Map/Struct 数据类型：Hive Catalog 完整支持分析 Parquet/ORC 文件格式中的 Map 和 Struct 数据类型，让您的数据分析更加流畅。2、物化视图在 2.4 版本中，StarRocks 支持了异步刷新的多表物化视图。在2.5 版本中，物化视图的能力进行了进一步增强，具体包括：提供多种构建方式，完善建模能力支持基于外部 Catalog 构建物化视图，并且支持各类复杂查询和内外 Catalog 的关联，使您可以更加方便地在 StarRocks 内直接基于湖中原始数据进行建模，并构建查询加速层。支持基于物化视图来创建物化视图，简化了多层建模流程。支持独立的物化视图生命周期管理，完善了数据管控。提供多种刷新策略，降低不必要的刷新开销可以设置单次刷新的最大分区数，以保证大的刷新任务可以分批、稳定完成。可以设置刷新排除表，以避免不必要的历史数据重刷。可以定义自动刷新范围，仅刷新最近数据。实现透明查询改写，享受无缝查询加速支持 Select / Projection / Join / Group by 的查询改写。支持部分分区、谓词的 Union 改写。支持嵌套物化视图的查询改写。通过上述功能的加强，相较 2.4 版本，物化视图真正具备了数据建模的基础能力。未来，StarRocks 会继续对多表物化视图进行增强，包括支持增量更新、支持主键模型的物化视图等。3、Query CacheQuery Cache 在 BE 的内存中缓存了查询的中间计算结果，给那些“语意等价”的查询进行复用，来降低延迟，提高 QPS 。目前，SELECT，GROUP BY，ORDER BY 以及 WHERE 中谓词的重排等操作均可以对 Cache 进行复用，并且也可以充分利用 WHERE 中谓词的分区 Cache，从而提升查询性能。Query Cache 在如下的几个场景中更能发挥作用：宽表模型下的单表聚合查询。聚合查询以非 GROUP BY 聚合和低基数 GROUP BY 聚合为主。查询的数据以按时间分区追加的形式导入，并且在不同时间分区上的访问表现出冷热性。未来，StarRocks 也会继续对 Query Cache 进行优化，包括支持多表 join 聚合查询的复用等。4、Lambda 表达式及高阶函数StarRocks 致力于为用户提供灵活好用的分析引擎，2.5 版本中 StarRocks 发布了 Lambda 表达式和数组类型的高阶函数。目前支持了 4 个高阶函数：array_map, array_filter, array_sum, array_sortby。通过这些函数，用户可以方便的对 array 内的元素进行计算、筛选、排序等操作，在变量捕捉、用户行为分析等场景都起到了重要作用。未来，StarRocks 也会继续补充更多高阶函数，致力于为用户提供更加灵活、方便的数据分析体验。5、主键模型主键模型支持条件更新，通过条件更新您可以指定某一非主键列为更新条件，只有当导入的数据中该列的值大于当前值的时候，更新才会生效，从而保证新的数据不被老的数据覆盖，保证数据的正确性。优化主键模型表导入数据时的内存占用，峰值内存占用降低 50%。未来 ，StarRocks 将持续在主键模型更新能力上进行优化，包括更全面的 upate 能力支持、更高的 partial update 执行效率。6、数据导入StarRocks 在 2.5 版本中对数据导入进行了诸多优化，包括：支持通过资源组对导入计算进行资源隔离，从而间接控制导入任务对集群资源的消耗。支持按物理存储进行数据复制的模式，整体性能提升 1 倍。Broker Load 支持定义导入作业的优先级。无需部署 Broker 即可从对象存储（S3、OSS 等） 或 HDFS 里进行数据导入。优化 Broker Load 在大量 ORC 小文件场景下的导入性能。7、备份恢复StarRocks 历史版本中，备份恢复仅支持表级别，并且对表的类型也有一定限制。在 2.5 版本中，备份恢复的功能全面覆盖所有模型，新增主键模型的备份恢复支持。同时也支持数据库级别的备份恢复，简化备份恢复管理。8、其他特性支持在建表时自动设置适当的分桶数，用户无需显式指定分桶数。支持用户自定义变量，您可以自行设置变量，并在后续 SQL 中使用，以简化 SQL 语句的编写并避免重复计算。新增 zstd、snappy、zlib 数据压缩的支持，用户可在建表时指定压缩算法。建表时支持指定 uuid() 或 uuid_numeric() 函数返回的结果作为列默认值。优化 information_schema 数据库中的 tables 表和 columns 表数据信息；新增 table_config 表，用于访问表的配置属性等信息。函数新增/优化：窗口函数支持使用 QUALIFY 来筛选查询结果；新增 map_size、map_keys、map_values、max_by、sub_bitmap、bitmap_to_base64、host_name、date_slice ；unnest 函数支持变参；window_funnel 函数支持严格递增模式，防止计算重复的时间戳；array_agg，array_sort，array_concat，array_slice，reverse 函数支持 JSON 数据类型。✨ 官方发布记录：https://docs.starrocks.io/zh-cn/main/release_notes/release-2.5 。EMR StarRocks开源大数据平台 E-MapReduce（简称“EMR”）是云原生开源大数据平台，向客户提供简单易集成的Hadoop、Hive、Spark、Flink、Presto、Clickhouse、StarRocks、Delta、Hudi、HBase 等开源大数据计算和存储引擎。随着数据分析需求的发展，数据湖成为大数据架构领域新趋势。为了满足更多用户对于极速分析数据的需求，同时让 StarRocks 强大的分析能力应用在更加广泛的数据集上，阿里云EMR 联合StarRocks社区一起增强了 StarRocks的数据湖分析能力，并推出了首款 StarRocks 云上产品。使其不仅能够分析存储在 StarRocks 本地的数据，还能够以同样出色的表现分析存储在 Apache Hive、Apache Iceberg 和 Apache Hudi 等开源数据湖或数据仓库的数据。 阿里云EMR StarRocks 整体架构在存储层，有阿里云的对象存储 OSS 作为数据湖的统一存储，可以存储常见的 Parquet/ORC/CSV 等文件格式。 在湖管理与优化层，EMR 会通过数据湖构建（DLF），去进行整体数据湖的元数据管理和一体化构建。同时在数据湖分析实践过程中，对象存储相对于传统的 Apache Hadoop（以下简称 Hadoop），HDFS 会存在一些性能问题。为了解决这个问题，在阿里云EMR，我们自研了 Jindo FS 系统，以便对数据湖存储层访问进行加速和优化。同时针对常见的数据湖存储格式，包括 Parquet、ORC 的格式。比如像 Hudi、Iceberg，在索引统计版本信息、版本维护、小文件合并以及生命周期等方面，都做了优化和增强。有了存储以及针对数据湖管理的优化等工作，就可以在此之上构建分析层，也就是数据开发与治理层。在数据开发与治理层，StarRocks 在阿里云EMR 分为两个角色，一部分是固定节点，一部分是弹性节点。有了 StarRocks 数据湖分析引擎之后，就可以对接 EMR 上开源的 Apache Airflow以及 Jupyter 等，也可以对接阿里云的 Dataworks 做数据开发和调度。阿里云EMR StarRocks 架构图✨ EMR StarRocks 详细信息：https://help.aliyun.com/document_detail/404790.htmlEMR Serverless StarRocks EMR Serverless StarRocks 是开源 StarRocks 在阿里云上的全托管服务，您可以通过 EMR Serverless StarRocks 灵活的创建和使用 StarRocks 服务。EMR Serverless StarRocks 架构的核心为FE（Frontend）和BE（Backend）两类进程，不依赖任何外部组件，方便部署与维护。FE和BE都可以在线水平扩展，元数据和业务数据都有副本机制，确保整个系统无单点。StarRocks提供MySQL协议接口，支持标准的SQL语法，您可以通过MySQL客户端方便地查询和分析StarRocks中的数据。EMR Serverless StarRocks主要在企业级功能方面做了以下增强：可视化的StarRocks实例管理控制台，使得实例的整体运维和管理更方便。可视化的监控及运维能力。支持小版本自动升级，方便StarRocks进行版本升级管理。增加EMR StarRocks Manager，提供了企业级的StarRocks管理能力：安全能力：支持用户及权限管理。诊断分析：支持可视化慢SQL，及SQL查询分析能力。数据管理：提供数据库、表、分区、分片、任务的查询能力，方便运维管理。目前阿里云EMR Serverless StarRocks正处于邀测阶段，如果您感兴趣可以加入钉钉群 24010016636 参与交流。✨ EMR Serverless StarRocks 邀测申请表：https://survey.aliyun.com/apps/zhiliao/EEb00jXa7
-
发表了文章 2023-02-07
Spark+Celeborn：更快，更稳，更弹性
摘要：本文整理自阿里云 EMR Spark 团队的周克勇（一锤），在 Spark&DS Meetup 的分享。本篇内容主要分为三个部分： 传统 Shuffle 的问题 Apache Celeborn （Incubating）简介 Celeborn 在性能、稳定性、弹性上的设计 点击查看直播回放一、传统 Shuffle 的问题Apache Spark 是广为流行的大数据处理引擎，它有很多使用场景: Spark SQL、批处理、流处理、MLLIB、GraphX 等。在所有组件下是统一的 RDD 抽象，RDD 血缘通过两种依赖关系描述，窄依赖和宽依赖。其中宽依赖是支撑复杂算子（Join, Agg 等）的关键，而宽依赖实现机制就是 Shuffle。传统的 Shuffle 实现如上图中间部分所示，每个 Mapper 对 Shuffle Output 的数据，根据 Partition ID 做排序，然后把排序好的数据和索引写入本地盘。Shuffle Read 阶段，Reducer 从所有 Mapper 的 Shuffle 文件里读取属于自己的 Partition 数据。但这种实现有如下几个缺陷：第一，依赖大容量的本地盘或云盘存储 Shuffle 数据，数据需要驻留直至消费完成。这就限制了存算分离，因为存算分离架构下，计算节点通常不希望有大容量的本地盘，希望计算结束就可以释放节点。 第二，Mapper 做排序会占用较大内存，甚至触发堆外排序，引入额外的磁盘 IO。 第三，Shuffle Read 有大量的网络连接，逻辑连接数是 m×n。 第四，存在大量的随机读盘。假设一个 Mapper 的 Shuffle 数据是 128M，Reducer 的并发是 2000，那么每个文件将会被读 2000 次，每次只随机读 64k，这就很容易达到磁盘 IOPS 的瓶颈。 第五，数据单副本，容错性不高。 以上五点缺陷最终导致不够高效、不够稳定以及不够弹性。二、Apache Celeborn (Incubating)Apache Celeborn （Incubating）是我们团队早期为了解决上述问题开发的 Remote Shuffle Service，已经于2022 年 10 月捐赠给了 Apache 基金会。Celeborn 的定位是大数据引擎统一中间数据服务，它是引擎无关的，并且除了支持 Shuffle，未来还会支持 Spilled data，这样计算节点就能真正解除对大容量本地盘的依赖。在正式介绍 Celeborn 设计之前，简单介绍一些历史。Celeborn 最早诞生于 2020 年，当时的名字是 Remote Shuffle Service，主要为了满足客户需求，2021 年 12 月正式对外开源。开源之后我们吸引了来自小米、Shopee、网易等开发者共建，其中很多人已经成为了核心贡献者。2022 年 10 月正式进入 Apache 孵化器，截至目前我们积累了 600+的 commits， 32 个 contributor，330+的 star，也希望更多感兴趣的开发者参与共建。三、Celeborn 的性能、稳定性、弹性Celeborn 针对性能提升的设计，主要包括核心设计、如何对接 Spark AQE、列式 Shuffle、多层存储。1. 性能Celeborn 采用了 Push Shuffle + Partition 数据聚合的核心设计。简单来讲，每个 Mapper 的内部维护一个 Buffer 来缓存 Shuffle 数据，当 Buffer 超过阈值之后会触发推送，Mapper 把属于同一个 Partition 的数据推给预先分配好的 Worker。如上图所示，Partition1 和 Partition2 的数据推给 Worker1，Partition3 的数据推给 Worker2，每个 Partition 最终会生成一个文件。在 Shuffle Read 阶段 Reducer 只需从一个 Worker 上读取属于自己的数据。在这个设计下 Shuffle 数据不落盘，也不需要做排序。同时 Shuffle Read 从随机读转换成了顺序读，网络的连接数也从乘数关系变成了线性关系。这就解决了传统 Shuffle 的主要缺陷。Partition 切分的设计动机是，对于大作业或者存在数据倾斜的数据，一个 Partition 的文件会变得非常大。我们遇到单 Partition 超过百 G 的情况，很容易把磁盘打爆，也会导致磁盘负载不均衡。针对这种情况，Celeborn 实现了 Partition 切分。具体来讲，Worker 会动态监测每个 Partition 文件的大小，当超过阈值的时候会返回给 Client 一个 Split 标记。Client 收到 Split 标记后，会异步申请新的 Worker，等新的 Worker Ready 后，Client 会往新的 Worker 推送数据。这样就可以保证单个 Partition 的 Split 文件不会过大，在Shuffle Read 的时候会读取这两个 Split 文件。接下来介绍 Celeborn 如何支持 Spark AQE。AQE 是近几年 Apache Spark 最重要的优化，它主要有三个场景，Partition 合并、Join Strategy 切换、Skew Join 优化。AQE 对 Shuffle 模块的要求是要能够按 Partition 的范围和 Mapper 的范围去读，按 Partition 的范围读会比较自然，如上图中右上角所示，Reducer1 直接读取 Partition2、3、4 的数据。而根据 Mapper 的范围读，实现起来稍微复杂，可以分为以下三个步骤：第一步，Split 切分。Skew Join 意味着数据有倾斜，大概率会触发 Partition 切分，例如 Partition1 切分成了 Split1 和 Split2。 第二步，Sort On Read。在首次 Read 某个 Partition Split 文件的时候，会触发 Sort On Read，Worker 会根据 Partition ID 对这个文件做排序。排序之后，Mapper 的范围读就会从排序之前的随机读变成顺序读。比如我要读 Mapper1 到 Mapper2 的数据，如果是排序之前的文件，我需要对这个文件 seek 四次，但如果是排序之后我只需要 seek 一次。 第三步，Range Read。Sub Reducer 从这两个 Partition 里顺序读取属于自己的 Mapper 范围的数据。同时，Split 文件会记录自己的 Mapper 列表，这样就可以裁剪掉不必要的 Split 文件。 接下来介绍 Celeborn 的列式 Shuffle。众所周知，行存和列存是两种常见的数据布局方式。列存的好处是相同类型的数据放在一起，易于编码，如字典编码、行程编码、Delta 编码、前缀编码等，可以非常大程度降低数据量。以往列存主要用于存储源表数据，而计算引擎算子内的中间数据大多用行存，因为以往算子的实现大多基于行存数据。但近几年向量化引擎越来越流行，包括 Velox、ClickHouse、DuckDB 等，他们都使用了向量化的算子实现，因此算子的中间数据也使用了列存。虽然 Databricks 的 photon 引擎使用了向量化技术，但 Apache Spark 依然是基于行存的引擎。为了在 Apache Spark 中实现列式 Shuffle，Celeborn 引入了行列转换和代码生成，在 Shuffle Write 的时候把行存的数据转化成列存，在 Shuffle Read 的时候把列转化为行存。同时为了提升行列转换的效率，Celeborn 引入了代码生成的技术来消除解释执行的开销。在 3T TPCDS 的测试中开启列式 Shuffle 后，整体的 Shuffle Size 可以减少 40%，行列转换的开销低于 5%。接下来介绍 Celeborn 的多层存储。多层存储的设计目标是让 Celeborn 能够灵活适配多种硬件环境，并尽可能让数据存放在更快的存储层。Celeborn 定义了三种存储介质：内存、本地盘、分布式存储（OSS/HDFS）。用户可以任意选择 1-3 种存储，比如可以只用本地盘，也可以只用内存和 OSS。上图展示了同时选择三种介质的存储机制，首先内存会被划分为两个逻辑区域，Push Data Region 和 Cache Region。Map 推送的数据会先落在 Push Data Region，当某个 Partition 的数据超过预设阈值会触发 Flush，这个时候 Celeborn 会去判断 Partition 的目标存储层，如果是本地盘（P3），这部分数据将被刷到本地；如果是内存 Cache（p4），这部分数据会被逻辑划分给 Cache Region(不会有真正的内存拷贝)。当 Cache Region 满了时，Celeborn 会把最大的 Partition Evict 到下一层存储，例如 P4 会被刷到本地盘。一旦某个 Partition 的数据被刷盘，它后续的数据将不会被移到 Cache Region。当本地盘满了时，我们有两种策略，第一种是把本地文件 Evict 到 OSS。第二种不用动本地文件，数据直接从内存 Flush 到 OSS。多层存储既可以通过内存提升小 Shuffle 的性能，也可以利用 OSS 的海量存储空间，支持超大的 Shuffle，还还可以让 Celeborn 不依赖本地盘，比如只选择内存和 OSS，那么 Celeborn 就没有本地盘，这样就可以更好的对 Celeborn 服务本身实现弹性。2. 稳定性Celeborn 针对服务本身稳定性的设计，主要包括绍原地升级、拥塞控制、负载均衡。首先介绍原地升级。可用性是服务必须满足的要求，蓝绿切换的方式虽然可以满足大部分场景，但需要较多人工介入和临时资源扩张。Celeborn 通过协议向前兼容和优雅重启实现了应用无感的原地升级。向前兼容我们通过协议的 PB 化实现，而优雅重启我们利用了 Partition 主动切分的特性，上图展示了优雅重启的过程。首先，外部系统触发优雅重启，Worker 收到信号后，把自己标记为 graceful shutdown 状态，并上报给Master，此后 Master 将不会向 Worker 分配新的 slots。然后 Worker 给 PushData 的返回打上 HardSplit 的标，Client 收到这个标记后将不会继续向这个 Worker 推送数据，同时向该 Worker 会发起 CommitFile 的消息，当 Worker 上所有缓存在内存中的 Partition 数据完成 CommitFile 后，Worker 会把内存的状态序列化并存到本地的 LevelDB，然后重启。之后从 LevelDB 里读取并恢复状态，最后向Master重新注册。从这个流程我们可以看到，由于有主动 Split 机制的存在，Celeborn 的优雅重启比起其他系统要更加高效，基本上可以在秒级别完成，且完全不影响作业运行。接下来介绍 Celeborn 在 Shuffle Write 阶段的拥塞控制。为了避免瞬时的大作业把 Worker 内存打爆，Celeborn 参考了 TCP 的拥塞控制机制，包括慢启动、拥塞避免、拥塞控制三个环节。Pusher 初始的时候处于慢启动状态，推送数据的速率很慢，但这个速率会以指数级上涨，当它到达某个阈值后会进入拥塞避免阶段。这时推送速率的上涨速度会变慢，变成固定的斜率。而这时如果 Worker 内存达到警戒线，会触发拥塞控制，给每个 Client 发一条标记。Client 收到之后会回到一开始的慢启动状态，Pusher 的速率也相应降到非常低。流量控制的另一种常见设计是 Credit Based 的流控，简单来说就是每当我推送数据之前，要先向 Worker 拿到一定的 Credit，这意味着 Worker 会为我预留一部分内存，我只能推送不超过我手里的 Credit 的数据。这种机制可以保证对内存的精准控制，但它的 Tradeoff 是增加了控制流，对性能有一定的影响。Celeborn 在 Shuffle Write 阶段采用的类 TCP 的拥塞控制，能同时兼顾瞬时流量的高峰和稳定态的性能。同时，Celeborn 在支持 Flink 的 Shuffle Read 阶段采用了 Credit Based 的设计。接下来介绍 Celeborn 的负载均衡设计。当前 Celeborn 关注的负载均衡主要集中在磁盘，设计目标是隔离坏盘，并尽量把负载分配给更快的、空间更足的盘。具体来说，Worker 会监控本地每块可用盘的状态，包括健康度、刷盘速率、预测未来的用量，这些状态信息随心跳发给 Master。Master 维护了整个集群所有可用盘的状态信息，并根据某个算法模型对磁盘进行分组。级别高的组会分配更多的工作负载，如果属于同一个组，会尽量分配给可用容量更大的盘。Celeborn 这种负载均衡的设计在异构环境下有更稳定的表现。3. 弹性Celeborn 针对弹性的设计，主要包括 Spark on K8s + Celeborn 方案。在 Yarn 的场景，External Shuffle Service 是 Spark 开启动态资源伸缩的前提，Shuffle 数据托管给 ESS 后，Executor 就可以释放。但 Spark on K8s 场景不存在 ESS，为了服务后续的 Shuffle Read，Pod 即使处于空闲状态也无法释放。开源方案为了优化这个场景，加了一个参数 spark.dynamicAllocation.shuffleTracking.enabled，通过跟踪 Shuffle 文件是否被读取来决定是否释放。但根据我们的测试，这个参数的效果有限。集成 Celeborn 之后，Shuffle 数据托管给 Celeborn 集群，Pod 就可以在空闲后立即释放，从而做到真正的弹性。4. 典型场景Celeborn 有以下三种典型的场景。第一种是完全混部。也就是 HDFS、Yarn、Celeborn 分布在同一个集群，它的主要收益是可以提升性能和稳定性。 第二种是 Celeborn 独立部署，HDFS 和 Yarn 混部。它除了能提升性能和稳定性，还能隔离源表数据的 IO 和 Shuffle 数据的 IO 对磁盘的抢占，提供了一定的资源隔离，以及 Celeborn 集群的部分弹性。 第三种是存算分离。源表的数据存在对象存储，计算节点运行在 K8s 或者 Yarn 集群，Celeborn 的集群也独立部署，这种场景下计算集群和 Celeborn 集群都可以享用完整的弹性。 5. Evaluation接下来分享两个案例，第一个是混部的案例。一位用户把 Celeborn 混部在计算集群中，Celeborn 部署的整体规模达到 1000 台以上，但每个 Worker 给的资源比较有限。这位用户每天的 Shuffle 数据量在经过压缩后可以达到 4PB，对大数据稳定性的提升也非常的明显。从上图可以看到，存在 8 万多并发，单个 Shuffle 有 16T 规模的作业，在 HDD 环境下也可以稳定的运行，在上 Celeborn 之前这个作业是跑不过的。第二个是一个存算分离的案例。一位用户采用了完全存算分离的架构，它的计算节点跑在 K8s 上，源表数据存在OSS，Celeborn 集群独立部署。他们的计算节点每天 Pod 的数量有好几万，默认开启 Spark 的动态资源伸缩功能，有非常好的弹性，除此之外，性能和稳定性也有显著提升。上图是我们在标准测试集 TPCDS 3T 的混部环境的测试结果。Celeborn 在不额外消耗机器资源的情况下，单副本比 External Shuffle Service 性能提升 20%，双副本有 13% 的提升。Celeborn 用户交流钉群
-
发表了文章 2023-02-03
阿里云EMR 2.0：重新定义新一代开源大数据平台
摘要：本文整理自阿里云高级产品专家何源(荆杭)在 阿里云EMR2.0线上发布会 的分享。本篇内容主要分为三个部分：开源大数据的痛点及EMR产品历程EMR2.0 新特征总结点击查看直播回放一、开源大数据的痛点及EMR产品历程 开源大数据的痛点 如何提升性能，降低资源成本 全面的性能优化需要大量的研发投入且门槛较高；大数据资源使用量大，广大用户都在不断探索降本方案。 如何降低运维成本 开源大数据组件众多，开发上手相对容易，但是一旦业务规模和业务复杂度上升以后，所带来的运维难度和开销也随之急剧上升。 如何保障数据和任务的可靠性 数据是公司的无形资产，数据的丢失往往是灾难性的，尽管有多副本，但是动辄几十台，甚至上百台、上千台的服务器在机器故障、集群升级、迁移过程中要保障数据的可靠性是一件不容易的事，而成千上万的任务实时或周期性的运行，也会消耗大量的运维投入。 如何管理数据开发和治理 实现团队协同开发、安全合规的使用数据以及治理数据，也需要有方法论的支撑和产品支持。 EMR产品历程 如下图所示，自2016年阿里云推出EMR以来，阿里云EMR团队一直致力于解决以上痛点。 通过一系列的性能优化，阿里云在 CloudSort 和 TPC-DS 上取得了世界第一的成绩，推出了全托管的元数据和数据湖产品，大大降低了运维难度和运维成本。 通过 DataWorks on EMR 以及 EMR Studio 等产品，大大简化了数据开发以及数据治理的接入门槛。二、EMR2.0 新特征 概述 基于云原生的理念和阿里云上日益成熟的设施，阿里云推出 EMR 2.0，构建新一代开源大数据的基础设施。 EMR 2.0的新特征包括： 全新平台体验 集群创建速度2倍以上优化； 集群扩容速度3倍以上提升； 弹性规模支持千台以上； 故障节点迁移； 集群诊断工具； 全新数据开发 全托管EMR Notebook (Jupyter)； Workflow (Dolphinscheduler)； 数据开发治理平台Dataworks on EMR； 全新资源形态 EMR on ECS，支持倚天g8，性价比提升超过40%； EMR on ACK(K8s)； EMR Serverless； 全新分析场景 新版数据湖 数据分析 数据服务 实时数据流 数据科学 EMR 2.0产品架构 如下图所示，EMR 2.0产品架构自下而上包括： 硬件资源 EMR 2.0支持ECS（Intel, AMD, 倚天）/神龙/ECI； 存储资源 在存储资源上，数据湖架构已经已经逐步成为业界的共识，阿里云在对象存储OSS 技术上升级为 OSS-HDFS 兼容 HDFS API； 调度资源 支持 EMR on ECS、EMR on ACK、EMR Serverless 管控平台 监控告警； 弹性调度； 集群诊断； 故障补偿； 权限&安全； 组件管理； 分析场景 新版数据湖 Datalake； 数据分析 OLAP； 实时数据流 Dataflow； 数据服务 DataServing； 数据科学 DataScience； 开发工具 开源解决方案 EMR Studio (Notebook, Workflow) ； 企业级开发平台 DataWorks on EMR 元数据管理和湖管理 在原有的数据湖构建DLF上 新增了权限生命周期管理、湖管理等新特性。 全新平台体验 阿里云EMR2.0 围绕弹性、稳定性、智能、效率四个方面对 EMR 进行了全面升级。 Elasticity 弹性 集群创建，弹性性能大幅提升； 异构实例，竞价实例满足个性化弹性需求； Stability 稳定性 节点迁移，故障节点自动补偿； 组件状态巡检，事件通知； Intelligence 智能 集群资源诊断； 风险预警； 实时检测； Efficiency 效率 交互式数据开发； 一键任务提交； 配置导出&集群克隆。 全新数据开发 EMR 2.0提供两套解决方案供不同用户选择，分别是：基于 Jupyter 和 DolphinScheduler 的 EMR Studio 开源解决方案，和阿里云自研的企业级数据开发与治理 DataWorks on EMR。 EMR Studio (Notebook, Workflow) 基于 Jupyter 的全托管SaaS化的 Notebook 直接在EMR管控台页面创建一个 notebook 并快速与EMR集群进行关联，几分钟内就可以开始对数据进行分析，无需担心代码的保存以及计算资源维护； 对 Jupyter Notebook 进行了优化：如支持 StarRocks 快速指定引擎类型； 基于 Apache DolphinScheduler 的全托管SaaS化的 Workflow 开箱即用，一键关联集群； EMR Studio 提供了全新的开源数据开发体验，在EMR服务费之外，不收取额外费用。DataWorks on EMR，企业级数据开发与治理 DataWorks 是一套在阿里内部历经几万用户十几年打磨的产品，能够满足企业一站式数据开发和数据治理的诉求。DataWorks 支持数据集成、数据开发调度、数据建模、数据质量、数据地图、数据安全、数据分析、数据服务以及开放的API等能力：数据集成：基于DataX，支持几十种数据源作为 source 和 sink 进行数据同步； 数据开发：线上的 IDE，支持 Spark、Hive、Presto、ClickHouse 的开发； 数据质量：根据任务配置的规则，对任务的产出结果进行正确性验证； 数据地图：采集字段级粒度的数据血缘； 数据安全：提供表和字段级别的权限管理； 数据分析：提供快速交互式的分析和可视化分析能力； 数据服务：简化数据查询服务的开发，通过写 SQL 就可以提供数据查询的接口； 开发平台：提供一系列的 API 供用户进行二次开发。 全新资源形态 随着云原生技术越来越成熟，EMR 也提供了各种资源管理形态。 EMR on ECS 支持组件最全，自定义能力最强； 跟传统模式最接近，便于快速迁移； EMR on ACK 完全兼容 K8S，10秒级资源调度； 支持 Spark, Flink, Presto, RSS 组件； 配合 ECI，自动弹性，秒级扩容； 完整的任务提交、管理、监控能力； EMR Serverless 首先推出的是 StarRocks； 全托管，最小化的运维成本； 高可用，SLA 99.99%； 开箱即用，对接 EMR Notebook； 成本低，按需扩容资源。 新硬件，倚天性价比提升40%以上在2022年云栖大会上，阿里云推出了中国首个云上大规模应用自研CPU倚天710，EMR2.0 也将推出倚天机型。倚天采用最先进的ARM架构和生产工艺，在通用智能性能提升的基础上，降低了整体的资源成本：在ECS价格方面，倚天G8系列较X86的机器系列价格降低20%以上，计算型系列价格降低超过30%，大幅降低企业成本； 在性能方面，物理核的倚天机型性能更高，CPU占用率更低；在EMR对倚天机型适配后，进行了 TPC-DS 的 Benchmark 测试，在G8Y与G7的对比中，同样采用了六台8core 32G的机型，倚天的TPC-DS耗时减少25%。 全新分析场景 EMR结合自身的技术优势和实践经验，对大数据场景进行了分类，方便用户快速构建适合业务的大数据集群： 数据湖 数据湖集群包含 Spark、Hive、Yarn、Presto、Hudi、Deltalake、RSS、Kyuubi 等组件； 支持用户构建数据仓库，进行数据 ETL 以及数据湖分析； 实时数据流 实时数据流包含 Flink、Kafka 等组件； 支持用户进行实时计算，构建在线决策、实时监控、实时计算等系统； 数据分析 数据分析主要包含 StarRocks、Doris、ClickHouse 等组件； 广泛应用于用户画像分析，交互式分析，构建BI报表系统和对接业务系统； 数据服务 数据服务主要包含 Hbase、Phoenix 组件； 支持时序数据分析、feeds流推送和用户行为收集； 数据科学 数据科学主要包含 Tensorflow、PyTorch 组件； 面向机器学习、数据挖掘、特征建模等场景； 对于部分客户出于成本控制的考虑，希望将多种业务混部在一个集群，EMR 还支持自定义集群，可以将多种场景下的组件混合部署在一起。 以用户使用最多的数据湖场景为例，EMR 在计算、存储和治理方面都做了大量的优化。 在存储层面，EMR 推出 OSS-HDFS，可完全兼容 HDFS API，用户可以平滑的将 HDFS 迁移到 OSS 上； 在计算层面，计算任务无需二次开发，可以直接运行在存算分离的数据湖架构上；在1PB的场景下测算，经过合理的冷热分层，可以节省40%的资源成本，同时计算资源也可以实现按需或者按负载弹性使用，大大降低了资源消耗； 在计算引擎层面，EMR 对 Spark/Hive/Trino/StarRocks 等引擎进行优化，ETL 和分析场景下性能有明显提升； 在数据湖管理层面，DLF湖管理实现湖数据生命周期管理，包括：元数管理与服务、权限控制与审计、数据质量控制、湖表管理与优化、存储管理与优化、全新数据迁移入湖。 总结 EMR2.0 从管控到引擎，从资源形态到应用场景都在积极创新，希望更好的解决用户在开源大数据遇到的痛点问题。 EMR2.0 的控制台入口也升级到了emr-next，欢迎前往使用新版EMR：https://emr-next.console.aliyun.com/ 欢迎对EMR感兴趣的朋友加入EMR钉钉交流群，一起交流和学习。
-
发表了文章 2023-01-05
Apache Spark + 海豚调度：PB 级数据调度挑战，教你如何构建高效离线工作流
点击预约直播2010 年，我国进入移动互联网，数据规模成几何式增长。在大数据开源技术领域，以 Hadoop 为核心的大数据生态系统面对海量数据也不断发展与迭代，大数据处理流程中的各个开源组件，也一起开启了狂飙突进的大数据时代，推动了整个行业开启了数字化变革之路。近年来，大数据行业的开发者都在感慨：技术迭代更新速度的太快了，今年还在流行，明年就可能被雪藏！其实我们非常清楚，技术永远是在“更新”或“替换”中得到发展。经过十余年发展，曾经的一些老牌开源项目已风光不在，大数据三驾马车（分布式文件系统 GFS、计算引擎 MapReduce、分布式数据库 BigTable），其中的计算引擎经历了多重演进，计算引擎 MapReduce 逐渐发展到 Spark 时代，对于大数据调度新星 Apache DolphinScheduler 来说，集成优秀的开源项目之后，如何打破数据孤岛，如何降本增效，如何应对大规模的数据离线调度也成为了新的挑战！众所周知，由于各种原因， 遇到 Apache Spark 应用程序的失败是不可避免的。最常见的故障之一是 OOM（驱动程序或执行程序级别的内存不足）。可以通过管理（调度、重试、警报等）Spark 应用程序以及 Apache DolphinScheduler 中的其他类型的任务，这不会让工程师头疼，也不需要 Apache DolphinScheduler 生态系统之外的任何代码，并且还支持拖拉拽 Spark 任务解决一些问题。Apache Spark 是用于大规模数据处理的统一分析引擎。是一个强大的开源工具，它提供了 Java、Python、Scala 和 R 的高级 API，以及一个优化的引擎，支持用于数据分析和不同工作负载的通用计算图。Spark 另一个有趣的特性是它的快速处理能力和容错能力，您可以放心，在出现资源故障的情况下，您的部署可以保持一致。Apache DolphinScheduler 是一个分布式和可扩展的开源工作流协调平台，能够在各种任务类别中提供具有可视化的任务调度，去中心化的设计保证了调度系统的高稳定性和可用性，可支持百万级数据和任务同时运行。为了让两个社区的共同用户既有地方反馈，还有地方学习，我们联合 Apache DolphinScheduler 社区推出的这个主题活动：洞悉 Spark 任务调度新能力｜Apache Spark + DolphinScheduler Meetup，如果你也是接触开源“计算引擎+调度”的用户，想了解最新 Spark 迷人的特性，那这次的分享你一定不要错过了，特邀- 阿里云 EMR 数据开发平台团队负责人孙一凡、BIGO 大数据研发工程师许名勇、阿里云 EMR Spark 引擎负责人周克勇 ，通过他们的分享让用户能更快更好更便捷的使用 Apache Spark + Apache DolphinScheduler。无论你是热衷于钻研开源技术的开发者，还是关注大数据最新技术动态的小伙伴，我都建议你来听听，从中获得全新的灵感。我相信社区花费精力筹备的活动，你一定能听到一手的分享，得到一手的收获！议程介绍欢迎大家参加 1 月 11 日 Apache Spark 联合 Apache DolphinScheduler 举办的 Meetup 活动，下午 14:00，我们不见不散！报名通道Apache Spark Meetup | 1 月线上直播报名通道已开启，赶快报名预约吧！时间：2023 年 1 月 11 日 14:00-16:20PC 端：https://developer.aliyun.com/live/251090移动端：建议扫码预约👇点击预约直播
-
发表了文章 2023-01-05
Apache Spark + 海豚调度：PB 级数据调度挑战，教你如何构建高效离线工作流
点击预约直播2010 年，我国进入移动互联网，数据规模成几何式增长。在大数据开源技术领域，以 Hadoop 为核心的大数据生态系统面对海量数据也不断发展与迭代，大数据处理流程中的各个开源组件，也一起开启了狂飙突进的大数据时代，推动了整个行业开启了数字化变革之路。近年来，大数据行业的开发者都在感慨：技术迭代更新速度的太快了，今年还在流行，明年就可能被雪藏！其实我们非常清楚，技术永远是在“更新”或“替换”中得到发展。经过十余年发展，曾经的一些老牌开源项目已风光不在，大数据三驾马车（分布式文件系统 GFS、计算引擎 MapReduce、分布式数据库 BigTable），其中的计算引擎经历了多重演进，计算引擎 MapReduce 逐渐发展到 Spark 时代，对于大数据调度新星 Apache DolphinScheduler 来说，集成优秀的开源项目之后，如何打破数据孤岛，如何降本增效，如何应对大规模的数据离线调度也成为了新的挑战！众所周知，由于各种原因， 遇到 Apache Spark 应用程序的失败是不可避免的。最常见的故障之一是 OOM（驱动程序或执行程序级别的内存不足）。可以通过管理（调度、重试、警报等）Spark 应用程序以及 Apache DolphinScheduler 中的其他类型的任务，这不会让工程师头疼，也不需要 Apache DolphinScheduler 生态系统之外的任何代码，并且还支持拖拉拽 Spark 任务解决一些问题。Apache Spark 是用于大规模数据处理的统一分析引擎。是一个强大的开源工具，它提供了 Java、Python、Scala 和 R 的高级 API，以及一个优化的引擎，支持用于数据分析和不同工作负载的通用计算图。Spark 另一个有趣的特性是它的快速处理能力和容错能力，您可以放心，在出现资源故障的情况下，您的部署可以保持一致。Apache DolphinScheduler 是一个分布式和可扩展的开源工作流协调平台，能够在各种任务类别中提供具有可视化的任务调度，去中心化的设计保证了调度系统的高稳定性和可用性，可支持百万级数据和任务同时运行。为了让两个社区的共同用户既有地方反馈，还有地方学习，我们联合 Apache DolphinScheduler 社区推出的这个主题活动：洞悉 Spark 任务调度新能力｜Apache Spark + DolphinScheduler Meetup，如果你也是接触开源“计算引擎+调度”的用户，想了解最新 Spark 迷人的特性，那这次的分享你一定不要错过了，特邀- 阿里云 EMR 数据开发平台团队负责人孙一凡、BIGO 大数据研发工程师许名勇、阿里云 EMR Spark 引擎负责人周克勇 ，通过他们的分享让用户能更快更好更便捷的使用 Apache Spark + Apache DolphinScheduler。无论你是热衷于钻研开源技术的开发者，还是关注大数据最新技术动态的小伙伴，我都建议你来听听，从中获得全新的灵感。我相信社区花费精力筹备的活动，你一定能听到一手的分享，得到一手的收获！议程介绍欢迎大家参加 1 月 11 日 Apache Spark 联合 Apache DolphinScheduler 举办的 Meetup 活动，下午 14:00，我们不见不散！报名通道Apache Spark Meetup | 1 月线上直播报名通道已开启，赶快报名预约吧！时间：2023 年 1 月 11 日 14:00-16:20PC 端：https://developer.aliyun.com/live/251090移动端：建议扫码预约👇点击预约直播
-
发表了文章 2022-12-28
阿里云开源大数据平台EMR全面升级 性能最高可提升6倍
12月27日,阿里云正式发布云原生开源大数据平台EMR 2.0，升级后的开源大数据平台在成本持平的情况下，扩缩容性能最高可提升6倍。据悉，阿里云EMR2.0为用户提供了全新的平台、开发、资源形态、分析场景等更优的产品体验，通过EMR Doctor健康检查、全面的服务巡检和事件通知、节点故障补偿等运维能力的升级，预估运维成本可降低20%-30%。新平台致力于为客户快速构建高性价比、安全可靠、兼容生态的开源大数据平台。EMR2.0与EMR1.0弹性扩容速度对比云原生趋势下，开源大数据处于重构之中，以 Hadoop 为核心的开源大数据体系，开始转变为多元化技术并行发展。阿里云EMR产品负责人何源介绍， 阿里云EMR于2009年开始服务阿里巴巴集团内部客户，2016年将过往的技术能力产品化开放，为客户提供商业化服务。作为开源大数据领域的引领产品，EMR 2.0通过云原生能力重构平台层、数据层、计算层，满足数千客户流处理、数据可视化、交互式分析、数据湖等多场景需求，重新定义了新一代开源大数据平台。为客户构建新一代开源大数据基础设施。EMR 2.0产品架构图客户基于EMR2.0平台可实现更加低成本、高效率、智能化的大数据集群管控和应用开发。通过使用抢占式实例，生产实证最多可降低百分之八十以上的成本。开启故障实例自动补偿，在全场景集群下，稳定性可以提高1个9。全新发布的EMR Doctor，通过健康检查服务的集群日报功能，查看集群是否存在资源浪费；通过任务评分倒排Top N，找到资源浪费最多的作业进行优化；通过持续优化，帮助客户最大化利用资源，避免浪费。同时，还可以帮助客户提前发现一些风险并进行处理。EMR Studio，提供Notebook和Workflow服务。全托管Notebook，兼容 用户Jupyter使用习惯，可以无缝对接EMR各计算、存储引擎，进行交互式的大数据开发和调试，已经开发和调试完的作业可以加入Workflow工作流里进行调度和上线。此外EMR Studio的Workflow服务也还支持Flink等的作业。2022年6月，阿里云EMR联合 OSS、 DLF、DataWorks等构建的云原生数据湖产品方案通过信通院评测认证，是国内首批且唯一满分的产品方案，该方案为用户提供“全托管湖存储、全面湖加速、统一湖管理、多模态湖计算和智能湖治理”等全面数据湖能力。（国内首批！阿里云云原生数据湖产品通过信通院评测认证）国内知名广告营销服务商汇量科技已使用EMR产品4年。在业务快速增长的大好形势下，汇量科技面临越来越多的困扰：如数据来源复杂、数据量大、数据维度多、实时运营业务秒级数据新鲜度需求等业务需求；本次升级后，汇量科技在素材平台、热力引擎等业务的大数据平台搭建上，数据同步和及查询效率有数倍提升，系统稳定性显著提升，未再出现之前cpu、mem、io负载高等情况。随着阿里云EMR2.0的发布，阿里云EMR将技术引领优势，转化为云上产品服务能力。重新定义的新一代 EMR 产品，将为各行业广大客户构建开源大数据平台提供最扎实的基座保障。
-
发表了文章 2022-12-19
直播预约｜阿里云EMR 2.0 重磅发布
面向未来，构建新一代开源大数据基础设施！阿里云EMR 2.0 发布会 将于12月27日14点在线上举办。发布会官网：https://developer.aliyun.com/topic/emr2云原生趋势下，开源大数据处于重构之中，以 Hadoop 为核心的开源大数据体系，从 2015 年开始转变为多元化技术并行发展。一方面，原有 Hadoop 体系的产品迭代趋于稳定；另一方面，「流处理」、「数据可视化」、「交互式分析」、「数据湖」等技术领域成为热点。阿里云开源大数据平台E-MapReduce ( 简称：阿里云EMR ) 作为开源大数据领域的引领者，迎来重磅升级，通过云原生能力重构平台层、数据层、计算层，满足万千客户流处理、数据可视化、交互式分析、数据湖等多场景需求，为客户构建新一代开源大数据基础设施！本次 阿里云EMR 2.0 线上发布会 邀请到来自阿里云和汇量科技的资深产品技术专家，聚焦开源大数据基础设施建设，基于 EMR2.0 全新平台体验、全新数据开发、全新资源形态、全新分析场景，多维度解读新一代开源大数据平台。全面介绍如何利用 EMR 新平台在提升性能、降本增效的同时，保证数据和任务可靠性，实现企业级数据开发和治理。点击【 阿里云EMR 2.0 发布会】立即预约发布会议程
-
发表了文章 2022-12-12
技术内幕 | 阿里云EMR StarRocks 极速数据湖分析
作者：阿里云智能技术专家 - 周康StarRocks Active Contributor - 郑志铨为了能够满足更多用户对于极速分析数据的需求，同时让 StarRocks 强大的分析能力应用在更加广泛的数据集上，阿里云EMR OLAP 团队与 StarRocks 社区在 2021 年就开始合作。双方联手增强 StarRocks 的数据湖分析能力，使其不仅能够分析存储在 StarRocks 本地的数据，还能够以同样出色的表现分析存储在 Apache Hive（以下简称 Hive）、Apache Iceberg（以下简称 Iceberg）和 Apache Hudi（以下简称 Hudi）等开源数据湖或数据仓库的数据。阿里云EMR StarRocks 正是 StarRocks 授权阿里云的一款开源 OLAP 产品，致力于构建极速统一分析体验，满足企业用户的多种数据分析场景。本文将主要阐释阿里云EMR StarRocks 在数据湖方向已经做过的工作、实际的效果体现，以及 StarRocks 在数据湖分析方向的规划。阿里云EMR StarRocks 整体架构在存储层，有阿里云的对象存储 OSS 作为数据湖的统一存储，可以存储常见的 Parquet/ORC/CSV 等文件格式。 在湖管理与优化层，EMR 会通过数据湖构建（DLF），去进行整体数据湖的元数据管理和一体化构建。同时在数据湖分析实践过程中，对象存储相对于传统的 Apache Hadoop（以下简称 Hadoop），HDFS 会存在一些性能问题。为了解决这个问题，在阿里云EMR，我们自研了 Jindo FS 系统，以便对数据湖存储层访问进行加速和优化。同时针对常见的数据湖存储格式，包括 Parquet、ORC 的格式。比如像 Hudi、Iceberg，在索引统计版本信息、版本维护、小文件合并以及生命周期等方面，都做了优化和增强。有了存储以及针对数据库管理的优化等工作，就可以在这之上去构建分析层，也就是数据开发与治理层。在数据开发与治理层，StarRocks 在阿里云EMR 分为两个角色，一部分是固定节点，一部分是弹性节点。有了 StarRocks 数据湖分析引擎之后，就可以去对接 EMR 上开源的 Apache Airflow（以下简称 Airflow）以及 Jupyter 等，也可以对接阿里云的 Dataworks，来做数据开发和调度。StarRocks 在 Iceberg 的实现StarRocks 主要包含 FE 和 BE 两个组件，两者之间再通过 RPC 进行通信，以实现查询的调度和分发、结果汇总等一系列工作。为了支持 Iceberg 的数据湖分析，我们在 FE 侧以及 BE 侧都做了大量的改造。首先是 FE 侧，增加了外表类型 IcebergTable；在执行计划生成之后，通过修改 RPC 协议（Thrift 协议），把执行计划相关信息发送给 BE；在 BE 侧，再通过通过 HDFS scanner 来支持实际的数据扫描。在做了上面这一系列的研发工作之后，我们基于 TPCH 和 Trino 做了性能对比测试。可以看到，StarRocks 相对于 Trino 性能表现非常突出。那么为什么 StarRocks 相比 Trino 的性能要好这么多？StarRocks 的性能分析借助 StarRocks 已有的全面向量化执行引擎、全新的 CBO 优化器等，这些能力能够极大地提升我们在单表以及多表层面的性能表现。在这个基础之上，针对数据湖分析的场景，我们也增加了新的优化规则。 首先在优化规则的方面，举几个简单的例子，比如常见的谓词下推，通过支持谓词下推，能够把 col_a>x 等谓词条件下推到 scan 算子。这样实际在扫描数据时，就能够减少扫描的数据量。如果没有做谓词下推（如上图左上角），通过整体扫描，会把数据先扫上来，然后再通过引擎本身上游的一些 Filter 算子去做数据的过滤。这会带来很大的 IO 开销。为了进一步减少扫描数据量，我们也支持了分区裁剪，详见上图中间区域。在没有做优化之前，需要去扫描三个分区。通过分区裁剪的优化，在 FE 侧就可以把不需要的两个分区裁剪掉。只需要告诉 BE 扫剩余一个分区的数据。在 BE 我们也支持了 Global Runtime Filter，针对 Join 这种场景，能够有比较大的性能提升。借助于 StarRocks 优异的执行引擎，就能够在 CPU 密集型的数据湖分析场景下有很好的性能表现。但在一些实际场景落地过程中，基于 FE 侧的一些优化规则，或者是前面提到的全局 Runtime Filter 还不能够完全减少 IO开销。如何降低 IO 开销非常关键。在大部分情况下，数据湖中需要分析的数据和计算节点，基本上不会在同一台物理机器上。那么在分析过程中，我们就面临着非常大的网络 IO 挑战，为此 StarRocks 社区针对 IO 方面做了非常多的优化，包括延迟物化、IO 合并、支持 Native Parquet/Orc Reader、针对对象存储的 SDK 优化等工作。接下来，我通过两个例子展开介绍实际的优化细节是怎么实现的。IO 合并在没有 IO 合并以前，若要读取一个 Parquet 文件相关的数据，首先需要基于 FE 侧发给 BE 的扫描数据路径去构建针对文件级别的 File Reader，在 FE 侧规划的时候，也能告知实际扫哪几列数据。在实际客户落地过程中遇到小文件导致 IO 耗时高的问题。针对于 ColumnReader，假设一个 SQL 同时要读取三列，有可能有两列的数据量会比较小。这个时候可以对这两列 IO 合并。比如以前要通过两次的网络 IO，现在可以一次就把这两列的数据读取。针对于 Row Group ，也可以对小的 Row Group 做 IO 的合并，从而减少 IO 的次数。对于文件本身，如果这个文件特别小，我们也支持一次把文件加载到内存中。实际在测试过程中，在这种小 IO 特别多的场景下，会有一个非常明显的提升。延迟物化什么是延迟物化？延迟物化需要解决什么问题？在没有延迟物化之前，回到 Parquet 的实现原理，比如要读取三列，就需要把这三列同时给读上来，然后再去运用一些谓词，再返回给上游算子。这里可以看到一个明显的问题，就是假设没有针对第三列的谓词，那其实第三列不需要把所有数据都读进来。可以看上图左边部分，因为 SQL 针对于前两列 c0 和 c1 是有谓词的。这个时候会先把这两列数据读取到内存。然后基于这两列构建 Selection mask，这两个 Mask 叫标记数组。有了这两个标记数组之后，会把第三列定义为一个 Lazy column。拿到了前两列的标记数组之后，基于这两个标记数组去构建一个新的过滤标记数组。然后再基于这个新的过滤标记数组读取 Lazy column。那在实际使用过程中，Lazy column 里边可能会有多列，这样能够极大地减少很多不必要的 IO 读取。因为有了前面的引擎赋能，包括全面向量化、CBO 优化器以及针对 IO 本身的优化数据湖分析，在测试和实际落地的过程中已经有一个很好的性能表现。在实践过程中，另外一个问题就是元数据访问。在数据湖场景之下，对文件的 List 操作可能会成为整个网络访问的瓶颈。为了解决这个问题，在 StarRocks 的 FE 侧设计了一套完整的细粒度智能缓存方案，能够缓存 Hive 的分区信息，以及文件信息。在设计缓存中，缓存更新是一个比较大的挑战。基于事件驱动的模式，能够解决缓存更新的问题，在保证用户查询的性能基础之上，也能够有非常好的使用体验，而不需要手动更新缓存。同时，为了加速查询的规划和调度，也支持了统计信息的缓存。StarRocks的生态分析早期版本中，如果要支持新的数据源需要做很多冗余的开发，开发者需要对很多其他模块有深入的理解，用于使用的时候也需要去创建外表。如何解决这个问题呢？我们的解决思路是设计一套全新的 Connector 框架。在以前的版本中，假设用户有一个库包含一两百张表，需要在 StarRocks 上去分析，那么他需要手动创建 100 多张的外表，然后通过 FE 管理元数据，再让用户去使用。如果说用户做了一些 Schema change，外表可能又得重建，就极大增加了使用负担。在 Connector 框架设计中我们引入了 Catalog 的概念，用户不在需要手动创建外表。比如说现在有 Hive Catalog、Iceberg Catalog，用户不需要去创建外表，只需要创建一个 Catalog，就能实时地获取到表的元数据信息。我们已经对 Hive、Iceberg、Hudi 做了完整的支持。同时在 EMR 产品生态里也已经集成好了前面提到的元数据管理的 DLF 以及 OSS、 Max Compute 等产品。StarRocks的弹性分析前面在做产品整体介绍的时候，提到了我们有一个比较关键的产品特性是弹性。弹性是怎么实现的呢？其实最核心的解决方案就是在 StarRocks 支持了 Compute Node（以下简称 CN）。下图左边部分就是一个固定的 StarRocks 集群，这些固定的 BE 节点都有实际的 SSD 存储。绿色部分是 CN。CN 和 BE 共享同一套执行引擎代码，是一个无状态的节点。CN 可以部署在 K8S 上，数据可以存储在对象存储或 HDFS 上。通过 K8S HPA 的能力，在集群负载高的时候动态扩容 CN，在集群负载低的时候缩容。经过上面的改造，EMR StarRocks 能够支持弹性伸缩，从而支持最大程度地降本。有了弹性之后，我们还需要解决另一个问题，那就是资源隔离。数据湖上的查询 workload 通常多种多样，有直接对接 BI 出报表的，也有分析师查询明细的 Ad-Hoc 等等。通常用户都希望通过软性的隔离，而不是物理隔离，来实现小租户资源的弹性隔离。例如在集群资源空闲的时候，允许查询充分利用集群资源，但是当集群资源紧张时，各个租户按照自己的资源限制使用资源。因此 StarRocks 还实现了基于 ResourceGroup 的资源隔离，这样用户可以从用户、查询和 IP 等层面，限制其对 CPU/MEM/IO 等资源的使用。通过对性能优化、生态整合弹性等几方面的介绍，我们知道阿里云EMR StarRocks 在数据湖分析场景具体是怎么做的、做到了什么程度。归纳起来，阿里云EMR StarRocks 数据分析的核心就是“极速”、“统一”两个关键词。极速：相对于 Trino 有数倍的性能提升，上图这一页的测试数据是针对于 Hudi。统一：支持多种多样的数据源，包括上图没有提到的 JDBC 数据源。目前从 Trino 迁移到 StarRocks 已经有不少落地实践，基本可以实现无痛的迁移。阿里云EMR StarRocks数据湖规划通过不断与用户交流探讨，我们认为，数据湖分析至少达到以下四点要求，才能成为一项大众化的数据分析技术：Single Source of Truth 。只有一份数据，用户无需显示地进行数据流转。高性能。接近秒级别，甚至亚秒级的查询延时。弹性。分解存储和计算架构。经济高效。按需扩展和扩展。当前阻碍数据湖分析达到上述四点要求的情况有以下三种：数据湖存储系统普遍存在 IO 性能差的问题，无法满足用户对于低延迟查询的要求。数据湖、数据仓界限分明。通常为了加速数据湖查询，我们还需要在其上去搭一层数据仓，破坏了 Single Source of Truth 的原则。复杂的数据栈结构使我们无法保证弹性、高性价比以及易用性。经过多次思考、开放讨论以及仔细论证，我们提出了数据湖分析的新方式，希望通过数据湖分析的新方式攻克以上难题、达到理想的数据湖分析状态。我们认为，数据湖分析的新方式等于缓存+物化视图。由于数据湖存储系统包括 OSS 等，通常 IO 性能都比较差，导致数据湖分析的瓶颈通常落在 Scan 数据上。为了能够进一步提升数据湖分析的性能，我们希望能够利用本地磁盘或内存缓存这些数据加速 IO 性能，使远端存储不再成为性能的瓶颈。引入缓存对于用户来说是透明的，用户无需额外的运维工作就能够享受到缓存加速的好处。相比于远端存储，本地磁盘或内存的价格一般都比较昂贵。我们希望好钢用在刀刃上：只有用户分析所需要用到的列数据才会进入到缓存当中来，并且对于逐渐变冷的数据，我们会将其自动淘汰掉，从而提高缓存的空间利用率。类似于 CPU 的缓存架构，我们也采用分级缓存的策略。第一级是内存，第二级是本地磁盘，对于缓存到内存的极热数据，所有的读取都能够直接引用缓存本身的内存，无需进行内存拷贝，在数据不断更新的场景下，新增数据通常会导致 Cache miss，从而导致查询延迟出现抖动。目前我们已经做了一些 POC。POC 显示，在 SSB 多表性能测试的情况下，缓存的性能比不缓存快了三倍以上，并且已经基本接近 StarRocks 本地表。缓存帮助我们保证 Single Source of Truth 的同时达到高性能，由于缓存的特性，用户可以真正做到弹性伸缩、cost effective。对于延迟敏感的场景，提高缓存空间来降低查询延迟。对于延迟不敏感的场景，减少或不使用缓存，从而节约成本。用户通常希望对数据进一步加工、预聚合或建模，使其进一步满足业务对数据分析的性能和质量要求，同时也能够节省重复计算的开销。然而不管是 Lambda 架构还是 Kappa 架构，用户都需要搭建复杂的数据栈，用于进一步加工数据湖上的数据。同时用户还需要分别维护元数据和加工后的多份数据，处理数据之间的一致性问题。为了满足用户对数据加工、建模的需求，进一步融合湖和仓，我们将为用户带来更加强大的物化视图能力解决上述问题。首先，物化视图通过 SQL 定义，数据的加工和建模变得极其简单。其次，物化视图能够融合不同数据的元数据，对外提供一个统一的视图，用户无需改写查询 SQL 即可做到查询自动路由透明加速。StarRocks 的视图支持实时增量更新，为用户提供更实时的分析能力。最后，物化视图作为 StarRocks 的原生能力，极大地降低了运维成本。通过物化视图，数据湖能够真正做到 Single Source of Truth，帮助用户更加简单地在数据湖上进行数据的加工建模，打破了湖和仓的次元壁，简化整个数据栈的架构。总结和展望—StarRocks 数据湖分析的核心是：极速、统一、简单、易用。通过 Connector、数据 Catalogs，数据源的接入变得极其简单。通过缓存，数据湖存储系统的 IO 性能将不再成为瓶颈。通过物化视图，湖、仓数据的流转更加自然，湖、仓视图一致，查询可以透明加速，数据栈的架构变得更加简约。最后借助云上和 K8S 的弹性能力，StarRocks 数据湖分析能够做到真正的弹性、cost effective。
-
发表了文章 2022-12-07
直播预告｜数据仓库？数据湖？停止纠结，流批融合的极速 Lakehouse来了！
直播信息：直播时间：2022年12月8日 19:00-21:10直播地址：https://developer.aliyun.com/live/250891点击【 StarRocks Lakehouse Meetup 】立即预约万物皆数据的时代，各行各业对数据分析架构的要求日益拔高，打破传统的数据湖应需而生。企业得以用更低廉的成本、更完善的 ACID 支持、更实时的方式，导入并存储所有结构化、半结构化和非结构化数据。得益于数据湖良好的伸缩性和灵活性，企业还可适应数据的任何变化，无需对基础设施进行重大更改。然而，数据湖架构在数据分析上仍面临着许多挑战，于是解决数据湖限制、结合了数据湖和数据仓库优势的新系统——Lakehouse开始出现，直接在数据湖的低成本存储上实现与传统数据仓库中类似的数据结构和数据管理功能。 自 2.0 版本，StarRocks 就已积极投入新一代流批融合的极速 Lakehouse 的建设。如今，用户可通过 StarRocks 进行数据湖分析，享受存算分离、弹性伸缩等前沿技术带来的降本增效。同时，通过 localcache、外表物化视图等特性，用户无需数据导入即可享受到堪比数仓分析的极速性能体验，更加敏捷地从数据湖中获取灵感和洞见，驱动业务增长。这个冬天，StarRocks 社区推出极速湖仓分析技术专场 StarRocks Lakehouse Meetup，旨在帮助开发者深入了解数据湖分析的前沿技术与最佳实践，和开发者共同探讨大数据领域的前沿技术。12 月 8 日（周四）19:00 ，StarRocks Lakehouse Meetup 第一期将在线上开讲，届时，来自阿里云 EMR 团队、Apache Ozone 社区、腾讯实时湖仓团队、小红书数据引擎团队的技术大咖将现身直播，以 Apache Iceberg 为主线，并对 Apache Ozone 、流批统一存储等技术展开探讨。阿里云高级产品研发工程师王日宇，将在Meetup分享阿里云EMR StarRocks整体架构和产品特点，介绍EMR Starrocks在数据湖方向做的研发工作以及支持读取Iceberg格式的背后的实现原理，最后会介绍阿里云EMR StarRocks产品未来的规划。更多议程及活动细节可参见下方海报，赶快扫码预约直播吧！技术交流群
-
发表了文章 2022-11-24
EMR-StarRocks 与 Flink 在汇量实时写入场景的最佳实践
作者：刘腾飞 汇量后端开发工程师阿里云开源OLAP研发团队EMR-StarRocks介绍阿里云EMR在年初推出了StarRocks服务，StarRocks是新一代极速全场景MPP（Massively Parallel Processing）数据仓库，致力于构建极速和统一分析体验。EMR StarRocks具备如下特点:兼容MySQL协议，可使用MySQL客户端和常用BI工具对接StarRocks来分析数据采用分布式架构：对数据表进行水平划分并以多副本存储集群规模可以灵活伸缩，支持10 PB级别的数据分析支持MPP框架，并行加速计算支持多副本，具有弹性容错能力支持向量化引擎和CBO支持弹性扩缩容支持明细模型、聚合模型、主键模型和更新模型更多详细信息可以参考https://help.aliyun.com/document_detail/405463.htmlFlink-CDC概念介绍CDC的全称是Change Data Capture，面向的场景包括数据同步、数据分发、数据采集，Flink CDC 主要面向数据库的变更，可以将上游数据和Schema的变更同步到下游数据湖和数据仓库中。2020年7月，Flink CDC项目提交了第一个Commit，去年8月，Flink社区发布了CDC2.0，经过两年时间的打磨，在商业化使用上已经非常成熟。本文主要以Mysql CDC为例，介绍StarRocks+Flink CDC实时入仓中用户遇到的痛点，以及在Flink和StarRocks层面进行的对应优化和解决方案。使用CDC将一张Mysql表中的数据导入到StarRocks的表中，首先需要在StarRocks上建立用来承接Mysql数据的目标表，然后在Flink上分别创建Mysql表和StarRocks表在Flink中Sink和Source表的映射，然后执行一条insert into sink_table from source_table语句。执行完Insert into之后，会生成一个CDC任务，CDC任务首先向目标表同步源表的全量数据，完成后继续基于Binlog进行增量数据的同步。通过一个任务，完成数据的全量+增量同步，对于用户来讲是非常友好的。但是在使用的过程中，依然发现了一些痛点。实时写入场景的用户痛点SQL开发工作量大对于一些还没有完成数仓建设的新业务，或是刚刚开始依托StarRocks进行OLAP平台建设的用户而言，在StarRocks中建表以承载Mysql同步过来的数据是第一步。在一些复杂的业务中，Mysql中的表往往有几十上百张，每张表又有数十个字段，要把它们对应的StarRocks表的建表语句全部编写出来是一个很大的工作量。第一个痛点StarRocks建表的工作量大。Flink字段的数据类型映射关系复杂易错在StarRocks中建表是第一步，建表完成之后，为了启动CDC任务，还需要在Flink中建立Mysql对应的Source表，以及StarRocks对应的Sink表，其中Flink建表时，每个字段的字段类型与Mysql、与StarRocks的映射关系需要严格注意，对于动辄几十上百个需要字段的表，每个字段都需要查找对应在Flink的类型映射关系，尤其令开发人员痛苦。因此，第二个痛点是上下游表与Flink字段的数据类型映射关系复杂，容易出错。Schema变更操作繁琐第三个痛点来自于业务数据Schema的变化，据Fivetran公司调查，约有60%的公司数据Schema每个月都会发生变化，30%的公司数据Schema每周都会发生变化。对于Mysql表中字段的增删改，用户希望在不影响CDC任务的情况下，将Schema变化同步到下游的StarRocks。目前常用的方案，是在手动停止任务后，更改StarRocks和Mysql的Schema，更改Flink侧的Sink和Source表结构，通过指定savepoints的方式再次启动任务。Schema变更的操作繁琐，无法自动化是第三个痛点。数据同步任务占用资源多第四个痛点，是在表的数量多、实时增量数据量大的场景下，CDC任务占用的内存和cpu资源较高，出于节省成本的考虑，用户希望尽可能的在资源利用方面进行优化。接下来，我们来看针对这些痛点，EMR-StarRocks在与Flink深度结合方面做了哪些优化，提供了什么样的解决方案。CTAS&CDASEMR-StarRocks与Flink团队推出的CTAS&CDAS功能主要是针对前三个痛点研发的一个解决方案。通过CTAS&CDAS，可以使用一条SQL语句，完成StarRocks建表、Flink-CDC任务创建、实时同步Schema变更等原本需要多项繁杂操作的任务，令开发和运维的工作量大大降低。CTAS介绍CTAS的全称是create table as，语法结构如下：CREATE TABLE IF NOT EXISTS runoob_tbl1 with ( 'starrocks.create.table.properties'=' engine = olap primary key(runoob_id) distributed by hash(runoob_id ) buckets 8', 'database-name'='test_cdc', 'jdbc-url'='jdbc:mysql://172.16.**.**:9030', 'load-url'='172.16.**.**:8030', 'table-name'='runoob_tbl_sr', 'username'='test', 'password' = '123456', 'sink.buffer-flush.interval-ms' = '5000' ) as table mysql.test_cdc.runoob_tbl /*+ OPTIONS ( 'connector' = 'mysql-cdc', 'hostname' = 'rm-2zepd6e20u3od****.mysql.rds.aliyuncs.com', 'port' = '3306', 'username' = 'test', 'password' = '123456', 'database-name' = 'test_cdc', 'table-name' = 'runoob_tbl' )*/;通过CTAS的语法结构可以看到，除了集群信息和DataBase信息外，还有一个特殊配置“starrocks.create.table.properties”，这是由于Mysql与StarRocks的表结构有一些不同，如Key Type、分区、Bucket Number等特殊配置，因此用它来承接StarRocks建表语句中字段定义后面的内容。为了方便用户更快的建表，还设置了一个Simple Mode，配置方式如下：CREATE TABLE IF NOT EXISTS runoob_tbl1 with ( 'starrocks.create.table.properties'=' buckets 8', 'starrocks.create.table.mode'='simple', 'database-name'='test_cdc', 'jdbc-url'='jdbc:mysql://172.16.**.**:9030', 'load-url'='172.16.**.**:8030', 'table-name'='runoob_tbl_sr', 'username'='test', 'password' = '123456', 'sink.buffer-flush.interval-ms' = '5000' ) as table mysql.test_cdc.runoob_tbl /*+ OPTIONS ( 'connector' = 'mysql-cdc', 'hostname' = 'rm-2zepd6e20u3od****.mysql.rds.aliyuncs.com', 'port' = '3306', 'username' = 'test', 'password' = '123456', 'database-name' = 'test_cdc', 'table-name' = 'runoob_tbl' )*/;开启Simple Mode之后，将默认使用Primary Key模型，默认使用Mysql中的主键作为Primary Key，默认使用哈希(主键)进行分桶，这样，用户在启动Simple Mode对表使用CTAS语句时，就完全不需要关心Mysql中原表有哪些字段，字段名称是什么，主键是什么，只需要知道表名，就可以高效的完成SQL编写。CTAS的原理如图所示，在执行了CTAS语句后，首先Flink会自动在StarRocks中创建一个与Mysql源表的Schema相同的目标表，然后建立Mysql与StarRocks表在Flink中的Sink和Source映射，接下来启动一个CDC任务，该任务将同步源表数据到目标表，并在运行时监测Mysql源表发送过来的数据发生的Schema变更，自动将Schema变更同步到StarRocks目标表中。CTAS功能实际上是用一个SQL，完成了原本需要手动编写SQL和执行的多项操作。 接下来介绍CTAS的实现原理。CTAS的实现主要依赖了Flink CDC、Flink Catalog和Schema Evolution。Flink的CDC功能前面已经介绍过了。其中的Catalog功能，使Flink可以感知到StarRocks中所有的DataBase和所有table的Schema，并对它们进行DDL操作。而Schema Evolution功能，是通过对数据的Schema变化进行检测和记录实现的，例如，当Mysql发生增列操作时，CTAS任务并不会根据Mysql的DDL变化，立刻对下游StarRocks进行添加列的操作，而是当第一条使用了新Schema的数据被处理时，才会通过对比新旧数据Schema的区别，生成对应的Alter Table Add Column语句，对StarRocks进行增列操作，在等待StarRocks的Schema变更完成之后，新的数据才会被推送到下游。CDAS介绍CDAS是CTAS的一个语法糖。通过CDAS语句，可以实现Mysql中的整库同步，即生成一个Flink Job，Source是Mysql中的database，目标表是StarRocks中对应的多张表。CREATE DATABASE IF NOT EXISTS sr_db with ( 'starrocks.create.table.properties'=' buckets 8', 'starrocks.create.table.mode'='simple', 'database-name'='test_cdc', 'jdbc-url'='jdbc:mysql://172.16.**.**:9030', 'load-url'='172.16.**.**:8030', 'username'='test', 'password' = '123456', 'sink.buffer-flush.interval-ms' = '5000' ) as table mysql.test_cdc.runoob_tbl including table 'tabl1','tbl2','tbl3' /*+ OPTIONS ( 'connector' = 'mysql-cdc', 'hostname' = 'rm-2zepd6e20u3od****.mysql.rds.aliyuncs.com', 'port' = '3306', 'username' = 'test', 'password' = '123456', 'database-name' = 'test_cdc' )*/;由于我们期望使用一条SQL生成多张表的Schema和CDC任务，因此需要统一使用Simple模式。在实际使用过程中，一个DataBase中可能有些表不需要同步、有些表需要自定义配置，因此我们可以使用Including Table语法，只选择一个DataBase中的部分表进行CDAS操作，对于需要自定义属性配置的表，则使用CTAS语句进行操作。重要特性CTAS&CDAS的几个重要特性包括：支持将多个CDC任务使用同一个Job执行，节省了大量的内存和CPU资源。支持Source合并，在使用CDAS进行数据同步时，会使用一个Job管理所有表的同步任务，并自动将所有表的Source合并为一个，减少Mysql侧并发读取的压力。支持的Schema Change类型包括增加列、删除列和修改列名。这里需要注意的是，当前所支持的删除列操作，是通过将对应字段的值置空来实现的，例如上游Mysql表删除了一个字段，在Flink检测到数据Schema变更后，并不会将StarRocks中对应的列删除，而是在将数据写入到StarRocks时，把对应的字段的值填为空值。而修改列名的操作，也是通过增加一个新列，并把新数据中原来的列的值置空来实现的。Connector-V2介绍Connector-V2是为了解决第四个痛点而研发的，可以帮助用户降低通过Flink导入StarRocks时的内存消耗，提升任务的稳定性。如图所示，在V1版本中，为了保证Exactly-Once，我们需要将一次Checkpoint期间的所有数据都憋在Flink的Sink算子的内存中，由于Checkpoint时间不能设置的太短，且无法预测单位时间内数据的流量，因此不仅造成了内存资源的严重消耗，还经常因OOM带来稳定性问题。V2版本通过两阶段提交的特性解决了这个问题，两阶段提交指的是，数据的提交分为两个阶段，第一阶段提交数据写入任务，在数据写入阶段数据都是不可见的，并且可以分批多次写入，第二阶段是提交阶段，通过Commit请求将之前多批次写入的数据同时置为可见。StarRocks侧提供了Begin、Prepare、Commit等接口，支持将多次数据写入请求作为同一个事务提交，保证了同一事务内数据的一致性。通过显示的调用Transaction接口的方式，可以由原来在Flink侧积攒大批数据、一次性发送数据的方式，改进为连续小批量提交数据，在保证Exactly-Once的同时，大大降低了Flink侧用于存储数据Buffer的内存消耗问题，也提高了Flink任务的稳定性。StarRocks + Flink在汇量的实践在汇量的广告投放分析业务中，使用了CDAS特性来完成Mysql到Flink数据的实时变更。此前，该业务主要依托某闭源数据仓库进行OLAP分析，随着数据量的增长，在单表查询和多表Join场景都出现了较大的瓶颈，查询耗时达到无法容忍的分钟级，因此重新选型采用了StarRocks进行数据分析，在对应场景下表现十分优异。在汇量的业务场景下，StarRocks中有几十张涉及操作元数据的小表是使用CDAS进行实时同步的，另外几张数据量较大的明细表是以离线导入的形式按天更新的。使用CDAS的主要是数据更新和Schema变化较为频繁的小表和维度表，进行业务查询时，将这些实时更新的表与离线的数据表进行Join，通过小表实时更新、大表离线更新、大小表联合查询的方式，实现了实时性、成本以及导入与查询性能的取舍均衡。由于业务对数据的准确性要求较高，因此使用了Exactly-once语义，通过Flink的Checkpoint机制来保证数据的不丢不重。我们会在钉钉群定期推送精彩文章，邀请技术大牛直播分享。欢迎钉钉扫码加入产品交流群一起参与讨论~
-
发表了文章 2022-09-23
基于EMR的新一代数据湖存储加速技术详解
摘要：本文整理自阿里云开源大数据平台数据湖存储团队孙大鹏在7月17日阿里云数据湖技术专场交流会的分享。本篇内容主要分为两个部分：背景介绍JindoData 数据湖存储解决方案点击查看直播回放背景介绍大数据行业蓬勃发展，主要源自于通讯技术的发展，全球数据规模，预计2025年将增长到163ZB，相当于全球60亿人，平均每人27TB数据。数据量爆发式增长，使得企业拥有了更多数据资源。更多数据意味着需要更大的存储。此外，数据本身极具价值，因此要挖掘数据价值并进行充分利用，以此反向推动业务的发展和改造。大数据技术的发展趋势是云化、轻量化、服务化。数据湖、与云融合、实时计算已经成为大数据领域的关键词。存算分离概念在云计算早期已被提出。存储与计算耦合的自建平台会造成额外成本，且受限于本地网络带宽。有了云计算以后，网络带宽得到了很大缓解。可以按量收费，提供服务化、容器化的能力，更好地做运维开发。业界存储架构演进早期的大数据基于 HDFS 构建数仓。 HDFS 是非常好的分布式存储选型，单集群可稳定支撑到 4-6 亿文件规模，数据量可达 100 PB 。但是 HDFS 运维成本比较高，存储作为基础组件，一旦存储出现问题，则意味着整个业务被中断。此外，达到4-6亿文件规模，100PB数据量后，再进行扩展则会出现问题。因此，社区提出了 HDFS Federation 方案。将 HDFS 集群进行扩展，并将业务进行拆分，大业务可以独立使用一组 NameNode，可突破单组 NameNode JVM 的限制，实现了HDFS 元数据和容量的横向扩展。此外，社区开发了 NS Router 组件，帮助更好地使用 HDFS 元数据。随着 HDFS 的扩展，其运维成本也成倍增加。业界开始选择利用对象存储的高可用、高吞吐，基于云上对象存储构建数据湖。每个云厂商都会从设计到运维上投入大量人力、物力保证对象存储可靠、稳定、高效。从存算一体到云原生数据湖开源大数据平台经历了几次大的演进。第一代开源大数据平台EMR，为更好地将 Hadoop 搬到云上提供了基础运维。在线下使用物理机，在云上使用 ECS 本地盘机型，即可实现与物理机近似的存储能力和成本。其特点为将线下 IDC 集群搬上云，可以通过云简化集群部署和扩容，但不解决 HDFS 的上线、运维等问题。第二代开源大数据平台EMR 将 OSS 和 S3 对象存储作为 storage connector 引入集群。当存储集群达到一定规模后，温数据、冷数据可以转存到 OSS 或 S3 对象存储，进一步降低存储成本。第三代开源大数据平台的特点为本地集群基本不保留任何元数据，而是保留在云上。DLF使用 Table 替代了 Hive Metastore 元数据方案，表的元数据通过云服务托管，利用 OSS 做存储，使集群基本实现无状态。因此，用户只需创建好集群即可使用资源，体验极佳。且可以对接更多存储引擎，互相之间能够实现隔离，比如离线、在线可以利用云上元数据和存储实现集群分离。数据湖存储演进之路数据湖存储的演进主要也分为三个阶段：数据湖1.0：存算分离架构，冷热分层，以Hadoop生态为主。数据湖2.0：以对象存储为中心，统一存储承载生产业务、大规模、高性能。数据湖3.0：以对象存储为中心，构建企业数据湖全兼容、多协议、统一元数据。JindoData 数据湖存储解决方案经过不断演化，最终实现了 JindoData 数据湖存储解决方案。JindoData 是存储加速项目。JindoFS 存储系统构建在 OSS 之上，提供了文件元数据功能和目录功能，可以和 NameNode 进行比对，解决了对象存储在模拟文件系统时的操作比如 rename 等问题。Jindo FSx 是存储加速系统，负责解决带宽问题。客户端或计算集群侧有存储资源，如果都通过网络，则延时、效率与 HDFS 存在差距，经过不断地放大后，用户会逐渐感受到性能差距。因此需要 Jindo FSx 存储加速系统来解决带宽和延时问题。基于以上两大核心系统，我们对上层提供了 HDFS API 和 POSIX API ，两个 API 基本可以满足大数据平台上对存储的使用需求，Flink 、Hadoop 、Spark 等大数据相关组件可以直接通过相关 API 方便地接入。比如当前新兴的 AI 训练可以将中间结果、TFRecord等通过 POSIX API 存到对象存储系统里。JindoSDK 生态工具解决了和生态对接问题，比如与计算对接、本地 POSIX 挂载。JindoDistCP 解决从 OSS 和 HDFS 之间的数据迁移，JindoTable 能够以表粒度做迁移，JindoShell 能够帮助我们更好地使用对象存储。底层数据源可以对接 HDFS、对象存储、NAS以及阿里云OSS。JindoSDK：超级数据湖SDKJindoSDK 是对接生态的重要 SDK，上层可以对接各种引擎，下层对接各种存储。通常，很多组件和存储都是基于烟囱式开发，导致 SDK 能力规格存在很大偏差。因此我们重点打造了 Native Core 层，使用 C++ 语言开发，对上层抽象出了 ObjectStore API 、DataStream API 和 FileSystem API。 通过 Cython 对接 Python SDK， 通过 JNI 对接 Hadoop SDK，通过 C SDK 对接 Jindo Fuse，使上层所有计算引擎都可以使用相同的一套原生 SDK。因此，SDK 层面改进后，上层全链路都可以享受 SDK 改进带来的收益，比如文件系统元数据操作优化、IO 路径的读写优化、安全、灵活的 STS 配置策略等。ObjectStore是对象存储的接口，OSS、S3 都可以归结到 ObjectStore 内部API。上图左下角为 Jindo Native SDK 和 OSS Java SDK 的性能对比，可以看到 Jindo SDK 性能平均提升 2.2 倍。Hadoop SDK 访问 OSS ，性能也可以得到全面提升。几个 SDK 广泛应用在 EMR 生产集群，其稳定性等性能都已经过阿里云上的产品验证。JindoFS：构建在OSS上的高性能存储系统JindoFS 重点解决了超大规模 HDFS 存储集群的挑战，比如单组 NameNode 架构存在容量限制，如果想突破容量限制，必须投入极高的运维成本，需要运维十多个服务包括NameNode、ZKFC 、ZK、JN；同时，元数据运维重启时间可高达几个小时，参数调优、JVM GC、全局锁等问题也存在挑战。除此之外，DataNode 做节点上下线、集群节点替换、HDFS 内部 balancer 等都需要解决。早期，受限于当时的技术，使用 QJM 架构来解决上述痛点。而随着 Raft 在业界广泛推广和使用，JindoFS 选择基于 Raft 架构建元数据，内部只需三个 NamespaceService 节点，避免了 HDFS 大量服务部署。运维成本上，实现了分钟级重启。通过C++语言开发，性能非常好。基于 OSS 存储，可以大大简化顶层设计，服务也更高效，且本地 block 可以用作缓存。半托管的 JindoFS 通过这套元数据可以解决 HDFS 的运维复杂度以及 OSS 接口的损耗，满足用户“对系统稳定可靠、运维简单、节省成本；对象存储数据湖和 HDFS 相比性能只好不差”的需求。随着 JindoFS 半托管的深入使用，我们发现即使运维简单，但因为需要为用户在半托管上部署一套服务，也会给用户带来一定的运维成本。因此我们实现了基于云原生容器化和存储服务化的JindoFS数据湖3.0架构，数据层面， OSS 服务可以提供两层 API ，分别是对象 API 和目录 API，通过两套 API 组合使用，可以基本满足所有高性能元数据和存储需求。客户实际部署时，可以将 SDK 以及 JindoFSx加速等组件部署在线下、容器或 ECS 里，使容器上的组件也可以更好地使用云上服务。JindoFS 使用了对象存储作为底层存储，因此可以实现冷热分层，可以根据对象文件生命周期的不同，选择标准型、低频型、归档型和冷归档型四种模式，最大程度地节省成本。归档类型适合长期存储但可能很长时间不读的数据，低频适合读得比较少的数据。JindoFSx：高性能/性价比的存储加速系统JindoFSx 缓存加速系统部署在 worker 上。很多对象存储远端有一定的网络开销，而如果全走网络请求，会导致延时增加。IO 越短，GPU 机器成本也可以发挥到最大。JindoFSx 可以在内部进行分层，能够对本地存储资源进行管理。通过 JindoSDK 对上层对接了各种 ETL、交互式分析、实时计算、机器学习等组件，底层可以对接不同数据源。比如阿里云上可能要访问其他云的对象存储，带宽性能上可能无法满足高性能查询的需求。但部署 JindoFSx 以后，对数据进行缓存、预热即可基本满足存储需求。JindoFSx 实现了分布式缓存架构，包括 Namespace、Storage，上层有一套 NameSpaceService 服务做文件元数据层面的加速，通过文件系统接口暴露给 JindoSDK，供上层应用使用，以此解决 IO 密集、带宽受限、远端数据访问的问题。生态工具和场景上图为数据湖存储对接计算引擎的大图，通过 OSS 可以方便地对接各种服务和存储。我们在数据流层面做了异步数据预读、复用，使得读取 Parquet/ORC 格式时可以实现高效寻址，利用缓存使数据读取更高效。对象存储上的 rename 操作比较重，因此我们设计了JindoCommitter，基于对象存储系统的 Multiple Upload，结合 OSS 文件系统层面的定制支持，可以实现在保证数据一致性前提下无需 rename 操作的 Job Committer。在 OSS 上运行作业时，只要加上Jindocommitter ，即可同时保证 Hadoop V1 版本的事务性和 Hadoop V2 版本的高性能。 目录 rename 的优化提供了针对 EMR 优化前缀重命名接口，目录 rename 降低到毫秒级并保证原子性。另外，我们支持了 fast copy，对比大部分对象存储对于 object 的copy 操作需要将数据进行真实拷贝， fast copy只需在内部做一次索引转换，避免了数据真实拷贝。 很多数据湖引擎是基于文件系统原子 rename 特性设计的，即对象如果已经存在，则不能被二次覆盖。对于这个重要特性，我们在 OSS 上做了重点支持。首先，OSS 是一个强一致性存储，比如向 bucket 里写入 object，如果没有强一致的保证，在 list 时可能无法获取到最新的对象。其次，对象存储的 rename是 Key 覆盖， Key 级别对象不会检查文件是否存在。而数据湖场景下，原子 rename 特性，我们实现了两种方案：在 SDK 层面基于 OTS 构建原子 Rename 的能力。同时进行深度优化后，已经可以实现 OSS 原生原子性 rename 支持，不依赖任何外部服务，可以在文件做 copy 时进行强一致的检测。对象存储是不支持 Flush 的，而像 Flink、Flume 这类引擎对 Flush 的依赖是比较重的，我们在对象存储上也做了深度优化，虽然不能保证完整的 Flush 语义，即数据 Flush 以后立刻可见，但是可以保证 Flush 以后数据不丢，对于 Flume 层面来说已经完全满足实际使用需求。 Flink 里使用了 MPU 接口，实现了 recoverable writer 的可恢复写入。数据湖生态的 JindoTable 是专门为结构化数据设计一套工具集，可以帮助降低存储成本和维护成本。JindoTable 可以以表维度做数据冷热转换。比如表存在 OSS 或 HDFS 上，可以通过JindoTable 操作 Hive MetaStore 等的数据，可以按照 DB 级别、表级别、前缀级别做生命周期转换，可以很方便地进行冷热数据统计，并按特点进行数据分层操作。Hadoop 原生 DistCP 在对象存储和 HDFS 同步数据会存在一些问题，比如拷贝策略、存储类型、数据校验等支持。JindoDistCP 重点解决这类问题：JindoDistCP 上实现了异构 checksum 比对，HDFS 和对象存储的 checksum 算法是不同的，传统的做法无法将HDFS 和对象直接做 checksum 比对，在 JindoDistCP 里进行了透明的 checksum 转换，保证了写入和传输过程中的数据准确性。此外，我们对 JindoDistCP 的内核也进行了重新优化，实现了动态拷贝，类似抢占式拷贝的方式，大文件和小文件可以快速同时并行，带宽利用率大幅提高。问答Q：JindoFS 和 HDFS 性能数据对比如何？A：后续会逐步发布测试数据，JindoFS 本身设计上有一定优势。在 HDFS 里做 rename、delete 等操作，特别是对大目录进行操作时，会存在大量的加锁和检查操作。随着文件数量变大，时间也会递增；这些操作在 JindoFS 上的时间是稳定的。Q：JindoFS 只有三个节点，最大能够支持多大文件数量？A：早期版本是一般是三节点组 raft，这种模式可以稳定支持十亿级别，相比于 HDFS 有两倍的提升。现在的 3.0 云原生架构下，用户通过 endpoint 访问，元数据服务可以在内部进行横向扩展。Q：JindoFS 和 Alluxio 的对比？A：JindoFS 是元数据的管理和优化，Alluxio 是一套开源分布式缓存加速服务，其功能定位与 JindoFSx 比较接近。Alluxio 主打开源，Jindo 在对象存储上做了较多优化，加上 Native 底层，理论上性能会有一定优势。Q：HDFS 上 k8s 场景是否有具体的实践？A：HDFS 是一个存储引擎，每个存储节点是有状态的。HDFS 部署在 k8s 节点也需要重度的运维，比如释放需要首先进行 HDFS Decommission 操作，要日常对节点进行 balance 等，k8s 部署 HDFS 无明显优势。更多信息：产品官网[1] 数据湖构建Data Lake Formation：https://www.aliyun.com/product/bigdata/dlf[2] 开源大数据平台EMR： https://www.aliyun.com/product/emapreduce[3] 大数据知识图谱： https://developer.aliyun.com/learning/topic/bigdata数据湖系列[1] 数据湖揭秘—Delta Lake： https://developer.aliyun.com/article/909818[2] 数据湖构建—如何构建湖上统一的数据权限： https://developer.aliyun.com/article/918403[3] 关于 Data Lake 的概念、架构与应用场景介绍：https://developer.aliyun.com/article/944650[4] 数据湖架构及概念简介：https://developer.aliyun.com/article/1004847[5] 数据湖统一元数据和权限https://developer.aliyun.com/article/1008235[6] 数据湖管理及优化https://developer.aliyun.com/article/1023298更多 数据湖 相关技术问题，可扫码加入钉钉交流群~
-
发表了文章 2022-09-16
数据湖管理及优化
摘要：本文整理自阿里云开源大数据高级开发工程师杨庆苇在7月17日阿里云数据湖技术专场交流会的分享。本篇内容主要分为两个部分：数据湖元数据仓库介绍阿里云DLF数据湖管理与优化点击查看直播回放数据湖元数据仓库介绍数据湖的实践过程中，我们面临了诸多挑战：第一，数据难以识别和查找。数据湖内存在大量未被有效识别的数据，可能是历史遗留或未被管理的数据，比如通过文件拷贝上传或其他工具引擎写入湖内的数据。其次，传统元数据服务里缺乏有效的检索服务，数据增长到一定规模时，很难从大量元数据中搜索和定位到特定场景下的数据。第二，数据资产管理能力弱，湖上缺乏有效的数据资产分析和优化工具，难以精细化掌握库、表分区级别的数据明细。对 schema 维度存储分层方案落地困难，数据冷热难以辨别，无法在库、表分区维度实现分层。第三，湖格式优化缺乏系统的解决方案。比如小文件合并操作需要用户对湖格式有一定的了解，能主动发现部分 schema 存在不合理的小文件，且利用计算引擎运行小文件合并任务，存在一定的使用门槛。此外，需要用户能够识别无效的历史数据以对其进行清理。为了解决数据湖实践过程中遇到的挑战，综合湖上数据特点以及计算引擎特点，阿里云提出了基于元仓数据底座，以云原生资源池的海量计算能力为基础，结合管控的在线服务能力，为用户提供全托管的湖管理和优化的解决方案。数据湖元数据仓库架构元仓组成湖上元数据以及分析和计算数据，为湖管理和优化提供了参考指标。经过数据采集、ETL、数据分析、计算等过程，将湖上分布在各处的数据进行整合，提取出有意义的指标，构建出分析库、指标库和索引库，为上层应用提供数据支撑。上图右侧是云原生计算池，通过 Spark 引擎利用云上的可伸缩资源运行 Analyze、Indexing、Compaction、Tiering 等分析和优化任务，并实时将计算结果写回元仓，参与指标库与索引库的建设，丰富和扩展元仓的指标资产，如在计算池内运行 stats 任务、获取表行数大小等指标，并回写到元仓指标库，用户可在第一时间查看表的基础信息，并以此为参考做数据质量分析等操作。管控层提供用了在线服务能力，如在线目录、检索服务、指标服务等，优化引擎负责分析元仓上的指标，并依据规则生成优化任务提交给云原生计算池进行计算。在此之上延伸出了很多湖管理优化的能力：①元数据能力：解决了数据难以识别和操作的问题。比如针对元数据检索，通过建立检索库，快速搜索元数据以及相关的 schema 明细。元数据发现通过云原生池计算运行任务提取元数据信息，有效识别湖内未知数据。②存储优化能力：解决了数据资产管理能力弱的痛点。比如存储统计分析，通过元仓的指标库分析库、表分区级别的数据明细、冷热分层，通过指标库提供的表分区，最近访问时间、访问频率、冷热指标对表分区自动分层。③查询优化能力：如小文件合并，通过指标库提取出小文件表和分区信息，根据规则在云原生资源池上运行小文件合并任务。此为全托管过程，用户侧无感知。④湖格式管理优化：实现了元数据加速和自动优化。以上方案解决了数据湖管理与优化的部分问题，帮助用户更好地使用和管理数据湖。数据湖元数据仓库建设湖上元仓的原始数据由三类数据构成：①存储数据：文件级别的OSS存储数据信息，包括大小、存储路径、存储类型、最近更新时间等，均来自存储访问日志和明细清单，这些基础数据构成存储属性的元数据，是分析和管理对象存储的基础。②元数据：描述目录、库、表、分区、函数等的数据，包括索引、属性、存储以及 stats的统计数据。主要来自于引擎元数据服务存储以及 stats的计算扩充，是大表治理、小文件合并等优化操作的基础数据。③引擎行为数据：包括血缘数据、引擎任务执行数据，比如文件大小、文件数、任务上下游依赖信息数据。这些数据在引擎计算时产生，是建设数据地图、生命周期管理的基础数据。以上数据经过日志服务消费、Spark 批任务、离线同步、Spark Structured Streaming、流任务实时消费等方式集成到元仓，作为元仓的原始数据。元仓选择 Hologres 作为存储库，因为Hologres对于海量数据的实时写入、实时更新、实时分析能提供较好的支持。对于实时性要求不高，但有较大数据量分析的场景，比如库表存储分析，可以通过 MaxCompute 离线数据加工的方式，将原始数据转换成明细数据，并提供离线指标给管控层；对于有较高实时性要求的场景，比如获取表分区行数、执行更新时间等，通过 Hologres 实时分析能力，实时计算出分析指标，并提供给 DLF 管控。元仓包含了实时和离线场景，为数据湖管理和优化提供了稳定、高质量的数据基础。阿里云DLF数据湖管理与优化元数据检索元数据检索解决了数据湖上数据难以查找的痛点。主要提供了两种搜索方式，一是全文检索，通过对元数据所有列属性建立索引，满足对任意单词的搜索都能在毫秒级别内做出响应；二是提供了多列精确查询，满足在特定条件场景下的搜索，比如按库名、表名、列名、Location地址、创建时间、最后修改时间等特殊属性精确匹配搜索。索引库选择了阿里云Elasticsearch方案。 ES 是实时分布式的搜索与分析引擎，可以近乎准实时地存储、查询和分析超大数据集，非常适合元数据的实时搜索场景。为了达到搜索结果秒级延迟的效果，我们选用 Spark Streaming 流技术，实时同步和解析引擎生产的 DML 日志写入 ES 库。但消费日志存在着两个天然的问题：一是消息的顺序性，无法保证顺序产生的 DML 事件能被顺序地消费并写入 ES 库；二是消息的可靠性，日志服务无法保证集群日志能够百分百被捕捉并写入到 hub。 为了解决上述痛点，一方面会通过消息内的最近更新时间做判断，逻辑上保证了消息的顺序性；另一方面，通过每日的离线任务同步元数据库做索引补偿，保证了每日元数据信息的可靠性。通过流技术、离线补偿技术、ES检索能力，实现了湖内从大量元数据中快速搜索和定位的能力。数据资产分析分析维度：湖上资产分析能力能够更高效、简洁地帮助用户分析和管理湖上资产，包含了资源统计、趋势变化、存储排名、存储分层。资源统计提供了总存储量、总库表数量、 API 访问信息总量，为用户提供了直观的数据感受，对湖上资产进行全局把握。趋势变化反映了上述统计指标近 7 天、30天和 1 年的增减变化。通过数据波动能够发现业务的发展状态，比如判断某业务近期的发展态势，并根据态势调整资源投入。存储排名反映了库表在一定范围内的排序情况，用户可以根据这一排名发现表的数据成本问题，比如 80% 的存储集中在 20% 表里。存储分层描述了对象存储上存储类型的分布情况、存储格式分布情况以及大小文件分布情况。通过分布情况判断当前数据分层是否合理。以上分析数据一方面能够帮助用户更好地理解和掌握湖上资产，另一方面为用户管理和优化湖数据提供了事实依据。数据模型：资产分析的模型建立遵循数仓的分层范式，从下至上分别为源数据层、数据公共层、数据应用层。 OSS存储的日志、明细数据、元数据和审计数据通过离线任务同步至元仓 ODS 层，然后通过离线加工计算出公共层数据，包括元数据、维表、文件存储、明细表、库表汇总等，然后根据业务需求将公共数据加入到应用数据并输出给管控，最后进行报表展示。库表维度精细化分析-DataProfileDataProfile 模块在库表元素之上，增加扩展了 stats 指标。stats 是引擎对于表的统计信息，包括表的记录数、表大小、文件数量等基础数据。在此基础上做了 stats 扩展，包括小文件数据、小文件占比、冷热度、分层信息指标等。由于数据湖对接多种引擎，Spark、 Hive 等。每种引擎 stats 计算结果都无法保证全面准确，且触发条件不一致，指标的覆盖度较低。默认情况下，如果分区表的记录数、大小文件指标覆盖度不足20%，则无法直接使用元数据 stats 指标。因此，我们通过主动提交 stats 分析任务，帮助用户计算表的 stats 数据。首先，引擎做 DML 任务后会产生一个事件，元仓记录这一事件， stats 集群实时消费 DML 事件，并拉起对应的 stats 分析任务，同时扩展了 analyze 命令，支持小文件数量、数据分层占比等分析指标。整个 stats 集群运行在云原生资源池内，为避免元数据服务与业务库的冲突，任务运行完成后会实时写入指标库。上述方案补充了云原生计算引擎 stats 数据覆盖准确度不高的问题，为表分析和优化提供了基础数据。Stats 能为管控页面提供库、表分区级别的明细数据，也能为其他优化引擎提供数据支持，比如分析表的小文件数量指标进行小文件合并，同时也能服务多种引擎做 CBO 优化。生命周期管理生命周期管理模块能够对 schema 维度存储分层，有效地帮助用户降低存储成本。 OSS 对象存储提供了文件级别的分层能力，OSS 不同存储类型价格不同，由热到冷分别为标准、低频、归档、冷归档，成本依次递减。基于此能力，可以将不常使用的数据冷冻，待使用时再解冻，以此降低存储成本。基于 OSS 的分层能力，结合引擎元数据，提供库表分区粒度的生命周期管理能力，根据规则对表和分区进行冷冻或解冻，以此降低用户对数据湖内冷热分层的使用门槛。规则中心通过元仓提供的指标制定，包括最近修改时间、创建时间、分区值、访问频率等指标，其中访问频率由分析引擎任务明细产生，通过 hook 的方式采集 Spark 或 Hive 执行任务时的任务明细，经过计算加工提取访问频率和最近访问的时间冷热信息。最近修改时间、创建时间分区值等基础指标由元仓计算而来。决策中心定期触发规则判断，在满足规则的情况下会产生归档任务，由任务中心实行。整个任务中心通过分布式调度，定时或手动执行解冻或归档任务，利用 JindoSDK 的高并发、高稳定特性，执行目录级别的文件归档操作。生命周期管理过程对于用户而言十分便捷，用户无需操作 OSS 文件，极大提高了用户对湖上数据的分层管理能力。以上为阿里云数据湖团队在数据湖管理优化过程中的实践，在实际应用过程中，帮助客户优化存储成本的同时，提高了数据的使用效率。更多信息：产品官网[1] 数据湖构建Data Lake Formation：https://www.aliyun.com/product/bigdata/dlf[2] 开源大数据平台EMR： https://www.aliyun.com/product/emapreduce[3] 大数据知识图谱： https://developer.aliyun.com/learning/topic/bigdata数据湖系列[1] 数据湖揭秘—Delta Lake： https://developer.aliyun.com/article/909818[2] 数据湖构建—如何构建湖上统一的数据权限： https://developer.aliyun.com/article/918403[3] 关于 Data Lake 的概念、架构与应用场景介绍：https://developer.aliyun.com/article/944650[4] 数据湖架构及概念简介：https://developer.aliyun.com/article/1004847[5] 数据湖统一元数据和权限https://developer.aliyun.com/article/1008235更多 数据湖 相关技术问题，可扫码加入钉钉交流群第一时间获取最新技术文章和社区动态，请关注公众号～
-
发表了文章 2022-09-13
EMR重磅发布智能运维诊断系统(EMR Doctor)——开源大数据平台运维利器
大数据运维的挑战—如何保证集群稳定与运行效率企业级大数据集群通常拥有海量的数据存储、日常运算成干上万的计算任务，需要满足各类上层业务的计算需求。对于这类集群的运维往往充满着挑战：海量的数据、庞杂的组件以及组件之间复杂的依赖关系、对于时效要求的的运算任务，都会提升运维难度。作为支撑平台，大数据集群的稳定性和运行效率，会直接影响到公司业务的正常运作和发展。集群管理员往往对整体集群做好了监控运维体系，对于大数据集群，简单的监控运维体系能够帮助管理员在遇到故障的时候定位问题。但对于整体集群的运行效率，集群的状态，通过单纯的监控指标很难给出一个全面的解答。对于大数据集群，管理员以及 CIO 等更关注以下的内容：集群内的节点的运行状态和资源使用状况；运行在集群上的服务组件的状态监控和异常处理，包括 YARN、HDFS、Hive 和 Spark 等；计算任务运行情况和执行效率；整体集群的健康程度和如何改进。面对运维挑战，EMR重磅推出：智能运维诊断系统(EMR Doctor)为了提升大数据集群运维效率，辅助 EMR 用户完善集群监控体系。E-MapReduce 推出面向开源大数据集群的智能运维诊断系统 E-MapReduce Doctor（简称EMR Doctor）。 EMR Doctor 作为开源大数据集群的管家，会自动每日巡检集群。集群管理员只需要定期查看健康检查报告，并且根据报告中的建议对集群做相应的优化调整，即可全局了解集群的健康状况和动态走势，并保持集群的健康度。如何使用 EMR Doctor进入 EMR 控制台健康检查页面。登录 EMR on ECS 控制台。在顶部菜单栏处，根据实际情况选择地域和资源组。在集群管理页面，单击目标集群的集群ID。单击上方的健康检查页签。在健康检查页面，您可以看到当前集群的健康检查报告（T+1）。健康状态列显示了该集群的健康度，您可以点击查看报告进入检查报告页面。健康检查报告中包含集群计算资源的总体分析健康检查报告中包含计算任务从各个维度的排名并给出任务调优建议健康检查报告中包含对集群存储的总体分析，以及大小文件和冷热数据的详细分析健康检查报告主要分析内容如下，更详细说明请参见查看健康检查状态和报告计算资源分析概述状态概述需要关注的问题计算基础信息集群计算评分集群算力内存时集群算力CPU时计算引擎内存算力时计算任务信息计算任务算力内存时分析计算任务评分排行榜SparkSpark任务算力分析及调优建议TezTez任务算力分析及调优建议MapReduceMapReduce任务算力分析及调优建议HDFS存储资源分析（需开启存储资源信息采集开关）概述状态概述需要关注的问题HDFS基础信息HDFS存储资源使用趋势文件总数随时间变化趋势评分趋势HDFS文件大小分布HDFS文件大小比例一级目录空文件个数Top10一级目录极小文件个数Top10一级目录小文件个数Top10一级目录中等文件个数Top10一级目录大文件个数Top10HDFS冷热数据分布HDFS冷热数据一级目录极冷数据大小Top10一级目录冷数据大小Top10一级目录温数据大小Top10一级目录热数据大小Top10HIVE存储资源分析（需开启存储资源信息采集开关）概述状态概述需要关注的问题Hive基础信息存储趋势文件数量趋势评分趋势Hive库信息库存储排名库文件总数排名库评分Hive表文件大小分布Hive表文件大小分布比例Hive表空文件个数Top10Hive表极小文件个数Top10Hive表小文件个数Top10Hive中等文件个数Top10Hive大文件个数Top10Hive冷热数据分布Hive冷热数据分布Hive表极冷数据大小Top10Hive表冷数据大小Top10Hive表温数据大小Top10Hive表热数据大小Top10Hive表存储格式分布Hive表存储格式分布Hive表TextFile/Parquet/ORC格式文件分析如何开通EMR Doctor开通及使用咨询问题请见 EMR Doctor常见问题EMR-3.39.0之前版本、EMR-5.5.0之前版本，EMR-4.10之前版本需要手动开通健康检查功能，请参见开通指南EMR-3.39.0及更高版本，EMR-5.5.0及更高版本，EMR-4.10及更高版本默认提供健康检查功能，无需手动开通。欢迎钉钉扫码加入EMR Doctor用户技术交流群获取集群运维最新功能和最佳行业实践~
-
发表了文章 2022-09-06
数据湖统一元数据与权限
摘要：本文整理自阿里云数据湖构建与分析研发熊佳树在7月17日阿里云数据湖技术专场交流会的分享。本篇内容主要分为两个部分：元数据与权限背景介绍阿里云数据湖统一元数据服务阿里云数据湖统一权限服务数据湖元数据与权限展望点击查看直播回放一、元数据与权限背景介绍开源元数据体系由来、演进及问题开源大数据体系是指以 Hadoop 为中心的生态系统，而目前 Hive 是开源数仓的事实标准。关于大数据的由来和发展，要追溯到谷歌在2003 年发表的论文，论文中提出了 HDFS 和 MapReduce 两个组件。HDFS 组件最早用于解决网页存储问题，它可以部署在大量廉价的机器上，提供极佳的硬件容错能力以及存储的扩展性。MapReduce 的初衷是解决搜索引擎中大规模网页数据的并行化处理问题。同时它也是比较通用的并行处理框架，可用于处理很多大数据场景。虽然 HDFS 和 MapReduce 很好地解决了大数据存储和大规模数据并行处理的问题，但依然存在几个缺点：第一，编程门槛较高。传统的数仓工程师接触的编程接口一般是 SQL ，但 MapReduce 框架有一定的编程能力要求。第二，HDFS 上存储的是文件和目录，并没有存储元数据，也无法进行查询。因此即使知道文件的结构，也无法对文件的内容方式变化进行管理，导致程序本身可能丧失稳定性。基于以上痛点，以雅虎为代表的公司提出了 Apache Pig，提供 SQL-like 语言，该语言的编译器会把类 SQL 的数据分析请求转换为一系列经过优化处理的 MapReduce 运算，屏蔽了 MapReduce 细节，可以很轻松高效地处理数据；而以 Facebook 为代表的公司提出 Hive 的解决方案，在 HDFS 上提供了一层数据抽象，屏蔽了文件系统及编程模型的细节，极大降低了数仓开发人员的门槛。通过对数据及文件系统到元数据的抽象，能够非常方便地进行数据共享、检索以及查看数据变更历史。这一层的元数据抽象即如今大家所熟知的 Database、Table 、Partition和 Function ，同时在元数据上又衍生出了非常接近 SQL 语言的 HiveQL。同时后续的 Hive3.0 版本新增了 catalog 的功能，Hive4.0版本新增了 Connectors 功能。依托于元数据, 计算引擎可以很好地进行历史的追溯。除了追溯历史 schema 变更外，元数据还有一个重要功能是保护数据（不做不兼容的变更）。Hive3.0实现的 catalog 功能，主要基于以下两个场景：① 多个系统之间可能需要 MetaStore 元数据的 Namespace，期望能够达到一定的隔离。比如 Spark 有自己的 catalog ，Hive 也有自己的 catalog，不同的 catalog 上可以有不同的鉴权、运营策略。② 可以对接外部系统的 catalog。Hive4.0的 Connectors 主要是定义数据 DataSource，其他引擎对接 Hive 元数据后，即可通过该接口识别 DataSource 的信息，方便其他引擎做查询。目前 Hive上几乎已经支持了 Hadoop 生态的所有计算引擎，因此它也已经成为开源数仓的事实标准。但它依然存在一些问题，比如虽然支持了 schema 的衍变，但是并不能通过 Time-Travel 的方式查询数据变化的历史快照，虽然有 ACID 新特性，但与 Hive 引擎的深度绑定导致无法很好地移植到其他引擎上。另外， ACID 特性主要使用 rename 的方式做 isolation 隔离，在做文件 Compaction 及在存储分离等场景容易出现问题，比如 rename 过程在云存储上的性能问题。开源社区针对这些点衍化出了一些数据湖的格式，在不同程度上解决了 ACID 的问题。数据湖格式拥有自己的元数据，同时会将自身的元数据注册到 Hive Metastore中。数据湖格式的元数据与 Hive 元数据形成补充，并没有脱离整体 Hive 元数据的视图，其他引擎依然可以通过 Hive Metastore 这一套元数据管理体系访问数据湖格式上的数据。但 Hive Metastore 上并没有多租户的能力，同时受限于单个元数据库的能力瓶颈，有些公司会部署多套 Metastore，这很容易形成数据孤岛，所以也有一些公司提出了解决方案，比如 Waggle-Dance 及 Multiple Hive Metastore 方案等。 另外因为 HiveMetaStore 使用 Thrift 协议的接口，所以内部引擎和自研引擎对接 Hive Metastore 时，必须对接 Metastore 的协议以及依赖相应的客户端 ，这种依赖还是比较重的。另外，Metastore 在设计元数据存储时高度去冗余，因此会带来一些 Metadata Fetch 的性能问题。开源的 Waggle-Dance 方案后端有多个 Metastore，每个 Metastore 有自己的 Database 存储。Waggle-Dance 模块实现了 Hive Metastore 后端完整的 Thrift 协议，能够无缝对接到其它引擎，解决现有的 Metastore 瓶颈问题，比如单个 DB 存储量、单个 Metastore 性能问题等。但是 Waggle-Dance 解决多租户的方案存在命名冲突问题，需要提前做 Database 和 Metastore 的命名规划。因为 Waggle-Dance 路由的模块有一个 Database 到后端 Metastore 路由表。如果是 Hive 3.0，可以通过 catalog 这一层路由的映射设计来解决。另外，Waggle-Dance 可能会带来 Thrift 接口协议的冲突，比如后端可能存在多个 Hive Metastore 的版本或有多个不同 client 的版本。因此中间层的路由组件可能需要兼容不同的版本，就可能会出现协议的兼容性问题。权限控制体系介绍除了元数据外，元数据和数据访问的安全性也非常重要 。企业的数据安全性必须依赖于完善的权限体系。权限的基本三要素包括主体、客体和操作。ACL 建立在基础三要素之上，对应到元数据上为：某个人对某个表有什么样的操作权限。ACL 存在一定的缺陷，比如后续如果权限比较多会难以管理，因此又发展出 RBAC 和 PBAC 权限。以入住酒店为例解释 ACL、RBAC 和 PBAC 三者的区别：比如住客入住酒店后会得到一把房门钥匙，得到进入某个房间的权限，即相当于 ACL ；而针对某一楼层有一个楼层管理员，可以管理所有房间，即相当于 RBAC，在 ACL 上面增加了一层用户的角色到权限的映射，有了角色之后很显然降低了权限管理成本；但是如果有比较特殊的需求，比如需要限制某一层的管理员只能在上午 7 点后才有权限进入房间，即需要 PBAC，它是基于策略的模型，在普通权限模型的基础之上支持了权限条件。Hive 0.13 提出了 Hive Storage-Based Authorization，它是基于底层存储的鉴权。该权限策略的优点在于无论是 meta 操作还是底层文件存储操作，都可以获得统一的权限视图。但它是基于目录和底层文件的权限体系，因此无法很好地映射到 SQL 层面权限操作。同时，因为底层的权限是文件，所以无法在数据层面或字段级别做更细粒度的鉴权，因此它并不支持 Fine-grain control。基于以上问题，社区提出了 Hive SQL-Standard Based Authorization，即基于 SQL 的标准化鉴权模型，能够在 SQL 层面支持 Grant 和 Revoke 控制指令。同时可以做相对细粒度的权限控制，比如可以将搜索上的很多操作映射到权限模型上。该模型实现了列级的访问控制，但没有实现行级的权限。另外，Hive SQL-Standard Based Authorization 虽然具有 SQL 层面的权限，但并不包含存储系统的权限。因此做存储系统的访问或实操层面访问时，无法获得统一的权限视图。且该模式不支持数据湖格式。后来，某商业公司推出了 Apache Ranger(Sentry)，面向所有大数据开源生态组件，对底层的文件系统 YARN、Hive、Spark、Kafka 提供了中心化的权限控制方案。同时支持在 SQL 层面进行 Grant、Revoke，比此前的模型增加了更细粒度的权限，比如行级过滤、列级权限控制，同时在权限上还具备 exception policy 及其他能力。但 Apache Ranger 也存在一些问题。因为 PBAC 模型的权限是事先定好的，不依赖对象的存在与否。比如用户对某表有 select 权限，表被删除后又被重新建出，而该用户仍然拥有权限，这并不合理。另外，虽然 ranger 可以使用在很多大数据组件之上，但仅限于 Hive 的 HiveServer，而 Hive Metastore 上并没有权限控制，所以它面临的问题在于 Hive Metastore 提供的元数据访问接口和在之上提供的权限接口存在分离。因此，总结来看，数据湖管理面临的挑战包含以下几个方面： 在元数据服务层面，开源版本没有多租户的能力，扩展性、稳定性以及性能方面都存在问题，对接多个计算引擎难度大。数据安全层面，权限控制方案复杂，成熟度低，无法覆盖所有计算引擎，且为开放存储，权限难以控制。数据治理层面，开源社区目前没有非常好的数据管理工具。无法很好地根据元数据分析现有的存储成本，也无法做很好的生命周期管理。虽然Hive4.0已经增加了一些特性，比如可以做 partition 的自动发现 以及对 partition 做一定的生命周期管理，但整体上依然没有很好的治理手段。查询性能层面，存储计算分离架构的读写性能受带宽控制，原始数据未经过优化因而查询性能低，且缺少索引、统计等加速手段。阿里云针对上述问题和挑战，实现了一套面向数据湖领域的元数据、安全、治理、加速的解决方案：全托管免运维的统一元数据中心统一元数据中心脱胎于阿里云内部久经考验的元数据底座，无缝对接多种开源计算引擎和自研的内部引擎，同时依托于阿里云的数据湖构建与管理DLF产品提供了元数据的发现、迁移、备份的能力。企业级权限控制数据安全方面，支持阿里云账号系统，也可以兼容开源的 LDAP 账号体系；提供字段级别的读写权限控制和 Location 权限托管。引擎和应用甚至可以对接元数据 API 和权限 API ，实现自己的权限集成或元数据集成，从而使所有引擎及应用都可以实现对权限的统一控制。智能数据管理与优化精细化存储统计与分析自动化数据冷热判断与分层多重数据湖加速JindoFS 提供数据缓存加速自动小文件合并、数据清理自动Stats计算、查询优化湖格式元数据服务化二、阿里云数据湖统一元数据服务阿里云上数据湖统一元数据服务架构阿里云上数据湖统一元数据服务（DLF）提供了多租户、统一数据目录，支持多引擎的扩展与切换。兼容了 Hive2.X 与 Hive3.X 协议，能够实现无缝对接开源与自研的所有计算引擎。同时，所有 API 、SDK 和对接开源引擎的客户端已经在阿里云上开源，支持客户自研引擎、应用或系统集成。另外，依托于底层存储的表格存储，面向海量结构化提供的 service 服务有着非常优秀的弹性伸缩能力，无需担心扩展问题。同时提供了高可用、免运维的能力。此外，提供统一的权限控制，用户只需依靠权限的配置，无论在 EMR 引擎上、阿里云的自研引擎上，还是在 DataWorks 等数据开发平台上，都可以实现多引擎、多管理平台或多应用的统一权限管控。能够支持阿里云 RAM 以及开源 LDAP 账号体系。统一元数据服务的最下层是数据湖存储，目前支持对象存储和文件存储。数据服务层提供了两个基础服务：第一层是 catalog ，负责管理元数据，包括 Catalog、Database、Function 和 Table；第二层是权限服务，包括 ACL 体系、RBAC 和 PBAC，TBAC 正在计划中（主要针对资源包）。再上层对接阿里云网关认证体系，支持 RAM 的子账号鉴权以及权限策略，可以实现底层元数据 API 和权限 API ，之上提供了 SDK 插件体系。有的云厂商保留了所有组件，在 Hive Metastore 内部进行封装来实现开源的无缝对接。其优点在于只需改动 Hive Metastore，其他的引擎都能自动对接到 Hive Metastore 上。而阿里云没有选择 Hive Metastore 方案，主要出于以下几个考量：首先， 保留 Hive Metastore 会带来一定的成本，所有请求都需要进行转发，会导致性能损耗。同时， Hive Metastore 本身的稳定性会影响整体元数据服务的稳定性，而且随着用户集群流量的增大，Metastore 也需要扩容。因此阿里云选择了在轻量级 SDK 上实现 client 接口并直接嵌入到引擎中，实现开源引擎到 DLF 服务的对接。阿里云自研的引擎 MaxCompute、Hologres 以及全托管的 OLAP 引擎也已经完全对接DLF。另外，用户的元数据管理应用或开发平台也可以对接 API。很多用户内部的元数据管理应用通过 JDBC 的方式连接底层的 MySQL ，而这也可能存在问题。比如底层元数据结构的升级会导致应用也需要改动。另一方面，直接对接JDBC接口查询底层数据，完全没有权限控制。但是如果对接 DLF API ，无论是 API 访问还是 EMR 访问，都会经过一层权限的控制体系，不会泄露权限。阿里云上数据湖统一元数据基本功能及优化阿里云提供了多租户和统一的数据目录，是以阿里云账号进行租户之间隔离的一种机制。阿里云账号下可以创建多个 catalog，提供了 table 级别的 schema 多版本，可以根据版本数据查询 table schema 的演变过程。同时阿里云内部各引擎通过支持 DLF，也同时实现了 Iceberg、Hudi、Delta 数据湖格式打通。此外，在 catalog 上会按租户的元数据做分区，用户的存储不会打在同一个后端存储的热点分区上。同时，我们实现了 ID 化，方便后续进行软删除、异步删除等优化。同时，在很多请求上实现了异步化。IO 方面也进行了部分优化。比如做 List partition 时，返回的是同一个表 partition 的所有元数据，而在大多数场景上 partition 元数据的 SD 都相同，因此完全可以基于相同的 SD 做共享，进行 partition SD 压缩，减少网络层的 IO 。阿里云上数据湖统一元数据之稳定性机制稳定性是另一个比较关键的问题。在云上需要对接所有租户，因此元数据服务的升级、灰度、自动恢复能力非常重要。自动恢复能力和弹性伸缩是云上的标配，都是基于资源调度系统实现。稳定性机制的底层是阿里云 Table Store，上层是元数据服务。元数据服务有两个常驻集群A和B，互为主备关系。在做升级时，将备服务配置为灰度状态，前端网关根据服务的配置策略以及租户分桶策略采集流量，然后发到灰度服务上，观察灰度流量是否正常，如果正常则升级到主服务；如果出现问题，则根据配置回滚即可。升级对用户侧、引擎侧完全无感知。即使是服务下线，也会等到主服务的流量归零才下线，这一层依赖于元数据自己的网关，因此可以实现得更为轻量，比如可以通过切断心跳的方式实现下线。三、阿里云数据湖统一权限服务实现数据湖统一权限服务，首先要解决两个问题：身份的问题、API 和引擎的访问权限一致性问题。上图为数据湖统一权限架构图。底层为湖上数据及元数据，上层为数据湖统一鉴权服务，包括网关、用户模型转换、引擎的鉴权插件体系和 DLF 数据访问服务端鉴权。最上层是已经实现以及进行中的数据湖格式、开源引擎、数仓、数据湖构建平台以及应用。目前，我们提供了 ACL 和 RBAC 和 PBAC 三种权限控制相结合的方式，ACL 和 Policy 互相补充。其中 ACL 模式依赖于授权的主体和客体，因此主客体必须存在，支持白名单授权。Policy 同时支持白名单和黑名单。引擎侧与 API 侧如何实现统一的鉴权？如果是用户持有 AK 或在外部操作上使用管理平台，则该层级全部通过 DLF SDK/API，在服务端元数据访问时会调用底下的鉴权引擎。如果是 EMR 开源集群，用户通过 beeline 接口方式、通过 LDAP 认证，再通过 Spark ThriftServer 获取元数据。引擎会持有可信的身份，经过可信身份校验后引擎可以获取所有元数据，再由引擎负责用户模型的转换，获取用户的操作与身份，代理用户鉴权，将相应的鉴权请求发到服务端，调用同样的服务端鉴权逻辑，最终实现引擎侧和 API 层的统一鉴权。四、数据湖元数据与权限展望未来，数据湖元数据与权限将在统一、一致性和性能三个方面持续演进。①统一元数据、权限、生态：云上的元数据目录及集中式权限管理将会成为标配，引擎、格式和各生态组件、开发平台对于元数据、权限的支持具备一致性。此外，支持非结构化、机器学习场景元数据模型自定义，这样其他类型的元数据也可通过自定义的方式接入到统一的元数据体系中。②元数据加速：比如针对数据湖格式推出定制元数据 API，为计算层提供给更多面向性能优化的方案。③更灵活的权限控制及更安全的数据访问：用户可以自定义角色权限、操作权限。另外数据存储也可以实现加密，当然这一切都会管理在统一元数据服务侧。问答Q：connection 任务与业务任务解耦导致元数据冲突的问题如何解决？A：湖格式普遍提供了 MVCC 版本控制体系，通过多版本控制和最后的 commit 能够解决该问题。Q：关于半结构化和非结构化的元数据管理是否有相关实践经验？A：半结构的数据，主要利用 JSON 或一些复杂的数据结构来解决数据存取问题。非结构化的数据大多与机器学习场景相关，后续我们计划将机器学习的模型对接到元数据上。Q：Hive Warehouse Connector 的原理是什么？A：Hive Warehouse Connector 是一层外部数据源的定义。引擎可以通过 Connector 去链接外部数据源。Q：如何让 Spark SQL 利用 Hive 本身的权限？A：目前开源社区暂无解决方案。但在阿里云上，Hive 和 Spark SQL 有一致的鉴权。Q：湖和仓的元数据能在一个视图里查看吗？A：目前，阿里云上还未开发此功能，但在一些数据开发平台上可以，比如 DataWorks。Q：元数据服务是每个租户有独立的服务实例还是大家共享元数据服务？A：是多个租户共享元数据服务，包括底层存储使用同一个 table store 实例，只是存储在不同的 table store 分区上。在同一个租户内使用 catalog 做 namespace 隔离，每一个 catalog 可以有自己的权限。 Q：DLF与数据湖格式如何配合的？数据多版本在哪一层实现？A：数据湖格式更多的是以注册或 meta 同步的方式将元数据向DLF元数据同步。数据多版本主要依赖底层的数据湖格式本身的能力。Q： Hologres的实时指标，如果计算频率很高，是否会导致压力过大？A：Hologres支持高并发的数据服务场景和数据分析场景，不同的场景会选择通过行存或列存来解决问题。Q：元数据消费过程中，为什么选择了StructStreaming 而不是Flink？A：两者时效性相差不大，选择StructStreaming主要基于技术栈考虑。Q：元数据性能方面是否有benchmark 的指标？A：目前官网暂未透出。由于存储有良好的scale能力及计算是无状态的，因此理论上来说整体QPS也能够很好的scale out。但是针对单个 table 分区数依然存在一定的上限。Q：生命周期管理中，触发解冻的因素是什么？A：目前还未实现自动触发，仅支持用户手动解冻。用户使用之前，会提供一个入口供选择是否进行解冻。了解更多：[1] 数据湖构建Data Lake Formation：https://www.aliyun.com/product/bigdata/dlf[2] 开源大数据平台EMR： https://www.aliyun.com/product/emapreduce[3] 数据湖揭秘—Delta Lake： https://developer.aliyun.com/article/909818[4] 数据湖构建—如何构建湖上统一的数据权限： https://developer.aliyun.com/article/918403[5] 关于 Data Lake 的概念、架构与应用场景介绍：https://developer.aliyun.com/article/944650[6] 数据湖架构及概念简介：https://developer.aliyun.com/article/1004847更多 数据湖 相关技术问题，可扫码加入钉钉交流群第一时间获取最新技术文章和社区动态，请关注公众号～
-
发表了文章 2022-08-30
数据湖架构及概念简介
摘要：本文整理自阿里云开源大数据技术专家陈鑫伟在7月17日阿里云数据湖技术专场交流会的分享。本篇内容主要分为两个部分：数据湖演进历程云原生数据湖架构点击查看直播回放一、数据湖演进历程什么是数据湖？数据湖概念于 2010 年提出，其目的是解决传统数据仓库和数据集市所面临的两个问题：其一，希望通过统一的元数据存储解决数据集市之间的数据孤岛问题；其二，希望存储原始数据，而非存储数据集市建设过程中经过裁剪后的数据，以避免数据原始信息的丢失。当时，开源的 Hadoop 是数据湖的主要代表。随着云计算的发展， 2015 年，各个云厂商开始围绕云上的对象存储重新解读和推广数据湖。云上对象存储具有大规模、高可用和低成本的优势，逐步替代了 HDFS 成为云上统一存储的主流选择。云上的对象存储支持结构化、半结构化和非结构化的数据类型，同时以存算分离的架构和更开放的数据访问方式支持多种计算引擎的分析，主要代表有 AWS S3 和阿里云的OSS。2019年，随着 Databricks 公司和 Uber 公司陆续推出Delta Lake、Hudi 和 Iceberg 数据湖格式，通过在数据湖的原始数据之上再构建一层元数据层、索引层的方式，解决数据湖上数据的可靠性、一致性和性能等问题。同时，流式计算技术如Flink、AI 技术等也开始在数据湖上有了更广泛的应用。同年，AWS 和阿里云也相继推出了 Data Lake Formation 等数据湖构建和管理的产品，能够帮助用户更快速地构建和管理云上数据湖。数据湖架构的不断演进和成熟也得到了更多客户的关注和选择。数据湖架构演进早期，用户基本在 IDC 机房里基于服务器或虚拟机建设 Hadoop 集群,主要的存储为 HDFS ，主流的计算引擎为 Hive 和 Spark 等。随着云计算的发展，很多用户为了解决 IDC 机房在资源扩缩容和运维方面的困难，开始选择在云上构建自己的数据湖平台。可以选择云上提供的大数据构建平台，比如EMR，来帮助快速建设和部署多个集群。但大部分早期用户选择直接将云下的架构搬到云上，依然以 HDFS为主要的存储，因此 HDFS 的问题依然存在，比如 NameNode 的扩展性问题、稳定性问题；比如计算资源和存储资源的耦合问题等；数据也存储于集群内部，跨集群、跨引擎的数据访问也会存在问题。而现在更主流的选择是数据湖架构，基于云上对象存储如OSS做统一存储。在存储之上，有一套管控平台进行统一的元数据管理、权限管理、数据的治理。再上层会对接更丰富的计算引擎或计算产品，除了 Hadoop、Hive、Spark 等离线分析引擎，也可以对接流式的引擎比如 Flink，Olap引擎如 ClickHouse、Doris、StarRocks 等。二、云原生数据湖架构阿里云数据湖发展历程阿里云在数据湖方向已经经过了很多年的发展。最早期的 OSS 发布于2011年，彼时数据湖的应用场景还很少。直到 2015 年，阿里云发布了云上 EMR 产品，开始将 Hive 和Spark 放至 EMR 集群，再将数据放至OSS，存算分离的架构开始流行。2018年和 2019 年，阿里云相继推出了数据湖分析DLA和数据湖构建DLF两款专门面向数据湖的产品。 2022 年推出的数据湖存储（OSS-HDFS）以及 EMR Data Lake 集群，数据湖解决方案的产品矩阵逐步形成。整个历程中，有三个标志性事件：2019年，阿里云发布了《阿里云云原生数据湖白皮书》，很多业内伙伴都基于这份白皮书开始研究学习和建设自己的数据湖；同年阿里云也打通数据湖和自研的 MaxCompute 云原生数仓，推出了湖仓一体架构； 2022 年，阿里云成为首批通过通信院的云原生数据湖测评认证的企业。数据湖建设思路及挑战经过多年沉淀，阿里云在数据湖的建设上也积累了一定的经验和思路。我们认为数据湖的建设主要包括四个阶段。第一阶段：数据入湖。通过各种各样的入湖方式将数据导入数据湖。入湖方式可以根据自己的业务需求和场景进行选择，比如全量入湖、CDC更新入湖、实时追加写入以及整个 Hadoop 集群搬迁上云等。第二阶段：数据湖存储与管理。帮助用户更好地管理发现和高效使用数据湖里的数据。此阶段主要包括以下几个方面：① 数据目录与检索：一方面能够提供元数据的服务，另一方面能够提供数据的快速检索能力。② 权限控制与审计：因为数据湖本身是相对开放和松散的体系，需要有比较强的权限管控的能力来保证企业数据的安全性。③ 数据质量控制：避免数据湖发展成数据沼泽的关键手段。④ 湖表管理与优化：管理优化数据湖格式。⑤ 存储管理与优化：对象存储提供了数据冷热分层的特性，但这些特性落地时还需要辅以自动化的手段以进行存储管理优化。第三阶段：数据处理与分析。可以根据实际场景选择多种数据处理和分析方式，比如做离线分析、实时计算、交互式分析、AI训练等。第四阶段：数据服务与应用。数据湖较为开放，因此可以直接用 BI 系统、可视化系统连接数据湖上的引擎，进行实时分析或可视化的数据展示等。另一方面，数据湖里的数据也可以再进一步同步或 Sink 到更专业的数据系统中，比如到 ES 里进行进一步数据检索，比如到ClickHouse/Doris/StarRocks等做更丰富的多元分析。阿里云云原生数据湖解决方案经历了多年的摸索后，阿里云推出了一个较为完整的云原生数据湖解决方案，整体架构如上图所示：底层是存储层：统一存储各类数据，并对外提供文件访问的接口和协议。第二层是管控层：可以理解为服务化的管控与优化，一方面提供统一的元数据、统一权限管控，另一方面提供智能化数据湖管理、快速数据检索等能力。第三层是多元的计算与分析层：可以通过很多开源或阿里云自研的分析引擎对湖内数据进行加工和处理。最上层是数据开发治理层：提供了面向湖和仓完善的数据开发体系以及数据治理平台。 由此可见，数据湖的建设不仅仅是大数据相关技术的集成和应用，同时也是一个复杂的系统工程，需要有成熟的方法论以及平台型的基础设施做支撑，才能建设出安全可靠、功能完善、成本可控的企业级数据湖。了解更多：[1] 数据湖构建Data Lake Formation：https://www.aliyun.com/product/bigdata/dlf[2] 开源大数据平台EMR： https://www.aliyun.com/product/emapreduce[3] 数据湖揭秘—Delta Lake： https://developer.aliyun.com/article/909818[4] 数据湖构建—如何构建湖上统一的数据权限： https://developer.aliyun.com/article/918403[5] 关于 Data Lake 的概念、架构与应用场景介绍：https://developer.aliyun.com/article/944650欢迎钉钉扫码加入数据湖交流群获取数据湖最新资讯和最佳行业实践~
-
发表了文章 2022-08-16
重磅发布！阿里云全链路数据湖开发治理解决方案
阿里云重磅发布全链路数据湖解决方案，主要包含开源大数据平台 E-MapReduce(EMR) + 一站式大数据数据开发治理平台DataWorks + 数据湖构建DLF + 对象存储OSS 等核心产品。近日，阿里云EMR重磅推出新版数据湖Datalake，100%兼容社区大数据开源组件，具备极强的弹性能力，支持数据湖构建DLF，数据湖存储OSS和OSS-HDFS，支持 Delta Lake、Hudi、Iceberg 三种湖格式。同时新版本 Datalake 对接阿里云一站式大数据开发治理平台DataWorks，沉淀阿里巴巴十多年大数据建设方法论，为客户完成从入湖、建模、开发、调度、治理、安全等全链路数据湖开发治理能力，帮助客户提升数据的应用效率。另外，解决方案提供了“统一元数据管理、数据入湖、数据存储、缓存加速、弹性计算、容器、数据分析、任务编排、运维管理，以及安全”等全面数据湖能力。通过了工业和信息化部中国信息通信研究院大数据能力专项评测，荣获“云原生数据湖基础能力专项评测证书”。阿里云全链路数据湖开发治理解决方案架构阿里云全链路数据湖开发治理解决方案使用 OSS/OSS–HDFS 作为数据湖存储，DLF 作为数据湖构建和管理工具，JindoFS 进行湖缓存加速，EMR 作为弹性计算引擎进行湖计算，DataWorks 进行数据开发和治理。DataWorks 各模块与 DataLake 深度集成，从而实现一站式数据湖开发治理。EMR新版数据湖集群核心运维管控能力介绍弹性能力弹性伸缩支持按集群负载和按时间2种模式弹性伸缩组支持多种实例规格支持抢占式实例（相较按量付费成本降低80%以上）支持成本优化模式（弹性比例的按量付费+包年包月）集群管控能力分钟级别创建和扩容集群，无需手动部署和启动服务完善的集群监控和告警体系，覆盖硬件和引擎服务，支持配置告警模板新版数据湖对比Hadoop集群优势性能更优速度加快新版数据湖集群节点组扩容速度得到明显提升，单批次大规模节点扩容速度提升80%HadoopDataLake弹性扩容 10 节点4分钟1分10秒弹性扩容 50 节点8分钟1分30秒弹性扩容 100节点10分钟1分50秒支持并发支持任务节点（task节点类型）多节点组并行扩缩容，能够覆盖多种使用场景，业务效率成倍提升。功能更全伸缩能力更强大可以同时配置按时间伸缩和按负载伸缩。支持优先下线负载低的节点。配置规则不依赖于是否运行弹性伸缩活动，可灵活修改配置（仅影响下一次触发）。执行逻辑更贴近使用场景多方位调研用户真实使用场景，功能执行逻辑设计更贴近业务实际。如：1）弹性伸缩扩容策略支持多实例选择并按顺序弹出（兜底库存不足场景），弹性伸缩缩容支持配置优雅下线并默认按负载选择目标节点下线（减少缩容时对集群任务影响）2）同一节点组多个弹性规则同时触发时，默认按照用户规则排序依次生效（灵活应对多种使用场景）操作体验优化更丰富的配置提示和操作引导，并新增配置项预校验逻辑，降低用户学习成本和操作失败概率。成本更省弹性伸缩性能更优，功能覆盖更广泛的场景弹性伸缩生效更快，支持功能更全。可以帮助用户更快更好地对硬件资源进行敏捷管理，根据业务需要设置相关策略，自动变更集群规模，减少硬件资源浪费。通过灵活配置抢占式实例进一步压缩成本在新增节点组时，提供完善的抢占式实例配置策略和兜底策略供用户配置，用户可以根据其业务诉求灵活配置，通过配置抢占式实例能够进一步压缩成本。与Hadoop集群全面对比模块功能项新版数据湖集群Hadoop集群集群集群创建时间平均时间小于5分钟。平均时间小于10分钟。集群节点组新增节点平均时间小于3.5分钟。平均时间小于10分钟。开放API支持。支持。域名支持Private Zone。hosts地址映射。磁盘扩容支持热扩容，无需重启集群服务。不支持热扩容，需重启集群服务生效。节点组交换机可以在新建节点组时选择交换机。仅支持在集群创建时选择，集群创建后不可更改。挂载公网可以在创建集群的硬件配置页面的实例区域，选择是否为节点组开启公网。没有节点组类型的限制。仅支持在集群创建时选择是否开启公网，创建后如果您需要使用公网IP地址访问，请在ECS上申请开通公网IP地址，详情请参见弹性公网IP中的申请EIP的内容。仅支持Master节点组挂载公网。附加安全组支持。不支持。部署集可以在创建集群硬件配置页面的实例区域，选择是否开启部署集开关。可以在新增Core节点组时，选择是否开启部署集开关。功能受限。节点组状态支持。不支持。混合节点支持同规格的不同机型混合。仅支持同规格机型。弹性伸缩节点支持混合节点。弹性伸缩弹性伸缩弹性伸缩与节点组解耦，从独立的功能模块转为节点组操作，使用更加便捷。需要专用的弹性伸缩组，该节点组不可进行手动扩缩容。伸缩规则配置规则不依赖于是否运行弹性伸缩活动，可灵活修改配置（仅影响下一次触发）。同一节点组多个规则同时触发时，会按照用户规则排序依次生效。配置规则受到弹性伸缩状态限制，修改后无法立即生效。同一节点组多个规则同时触发时，随机生效。伸缩记录丰富了弹性伸缩记录信息。在查看详情页面新增了触发规则快照和执行结果参数，能够快速查看触发原因和变更节点信息。提供基础的伸缩记录列表。指标采集频繁每30秒采集一次。每30秒采集一次。伸缩活动生效时间规则应用后1~30秒。规则应用后1~2分钟。扩缩容扩缩容活动弹性伸缩活动与手动扩缩容活动运行机制相同。区别仅在于触发条件不同：弹性伸缩需要弹性伸缩规则触发。手动扩缩容需要人为触发。支持暂停弹性伸缩活动。多个Task节点组的扩缩容活动彼此独立，互不影响。弹性缩容根据节点负载和创建时间，智能选中目标节点，减少业务影响。弹性伸缩活动和手动扩缩容活动是两套机制，互不兼容。弹性伸缩活动不支持暂停状态。同时仅支持一个节点组进行（弹性）扩缩容。弹性缩容节点选择具有随机性。高可用与软件应用高可用不再支持本地MySQL作为Hive Metastore数据库。支持本地MySQL作为Hive Metastore数据库。支持部署集，3台Master分布在不同底层硬件以降低硬件风险。默认不支持部署集。NameNode与Resource Manager部署于3节点，并不再支持2 Master模式。Namenode与Resource Manager仅部署于2节点，支持2 Master模式。集群应用组件支持可选必选 + 可选。Spark2与Hadoop3组合支持。不支持。Spark3与Hadoop2组合支持。EMR-3.38.0之后版本支持同时部署。DataWorks全链路开发治理能力介绍DataWorks 基于 EMR-Datalake、EMR-ClickHouse、CDP 等大数据引擎，为数据湖/数据仓库/湖仓一体等解决方案提供统一的全链路大数据开发治理平台。作为阿里巴巴数据中台的建设者，DataWorks 从2009年起不断沉淀阿里巴巴大数据建设方法论，通过智能数据建模、全域数据集成、高效数据开发、主动数据治理（数据质量、数据地图等）、全面数据安全、快速分析服务六大全链路数据治理的能力，与数万名政务/金融/零售/互联网/能源/制造等客户携手，助力产业数字化升级。智能数据建模DataWorks智能数据建模沉淀阿里巴巴数据中台建模方法论，以维度建模为基础，从数仓规划、数据标准、维度建模、数据指标四个方面，以业务视角对业务的数据进行诠释，让数据仓库的建设向规范化，可持续发展方向演进。针对 Datalake 的智能数据建模能力将在2022年8月份正式发布。全域数据集成DataWorks数据集成是开源 DataX 的商业化团队，在数据湖场景下支持50+种数据源之间的离线同步，包含数据湖常见的HDFS、Hive、HBase、OSS、Kafka等数据源，MySql、Oracle、SQLServer等数据库。同时，针对IDC>>云上、云厂商>>云厂商、云产品>>云产品、云账号>>云账号等各种同步场景，提供网络连通的解决方案，让客户在复杂网络环境、丰富的异构数据源之间，依旧保持高速稳定的数据移动能力。高效数据开发DataWorks数据开发（DataStudio）与运维中心面向EMR-Datalake、EMR-CK、CDH等引擎，提供可视化开发的主界面，赋予用户智能代码开发、多引擎混编工作流、规范化任务发布的强大能力，帮助用户轻松构建数据湖、离线数仓、实时数仓与即席分析系统，保证数据生产的高效与稳定。数据开发-核心开发调度能力支持EMR Hive、EMR MR、EMR Spark SQL、EMR Spark、EMR shell、EMR Presto、EMR Impala、EMR Spark Streaming共八种节点。远超开源的超大规模调度稳定能力（双11单日千万级任务实例）分钟/小时/天/周/月多种调度周期业务流程全局参数/节点上下文传参数据开发-多种可视化数据对象管理及控制节点可视化资源文件上传（HDFS/OSS）可视化管理UDF（Java）可视化建表（支持HDFS/OSS）归并、赋值、顺序、循环、分支等控制节点。多种调度周期混合编排可视化业务流程编排数据开发-智能SQL编辑器语法高亮关键词自动补全表/字段信息提示函数信息提示任务运维-运行诊断运行诊断可帮助用户快速定位任务出错原因，例如上游依赖未完成调度资源不足数据质量规则拦截基线破线同时拥有补数据相关能力，方便用户快速处理运维情况。在告警方面，运维中心支持多种告警方式支持Webhook（钉钉、微信、飞书）、电话、短信、邮件等多渠道告警支持基于值班表配置告警人员，任务运维-智能基线智能基线是DataWorks独创的监控技术，具备国家专利，用户无需配置每个任务的告警时间，仅需配置最终产出节点的告警时间，智能基线会基于历史的任务运行情况，在核心任务可能无法准时产出时，做提前告警，保障核心任务的生产稳定。主动数据治理DataWorks数据治理包含数据治理中心、数据质量、数据地图等多个产品，覆盖事前、事中、事后的数据生命周期，通过数据治理健康分、质量规则、数据大血缘等能力，将书面的数据治理规范落地成平台化的产品能力，让数据治理不再一个 “阶段性项目”，而是一个“可持续的运营项目”。数据质量EMR HIVE节点支持DataWorks数据质量规则，内置37种数据质量规则模板，可以进行可视化、批量数据质量规则配置，提高数据质量规则配置效率。同时该模块与数据开发调度深度集成，可通过调度触发规则运行，节省计算资源，及时发现问题。支持37种内置数据质量模板规则支持批量配置规则、规则模板支持绑定调度引擎并在质量报警时阻塞业务流程支持动态阈值（顶会论文技术，算法自动判定告警阈值）支持SQL自定义规则支持短信、邮件、钉钉告警支持自定义数据质量报告支持质量问题处理记录同时，数据质量支持强弱规则设置，进行灵活的运维控制。强规则，直接阻塞下游任务运行，防止问题数据污染下游，浪费下游执行的计算资源弱规则，只告警，不阻塞任务运行，针对一些非核心任务。数据地图数据地图支持完整的EMR-Datalake元数据体系，可以针对表名、字段名进行快速搜索，基于表、字段血缘浏览上下游关系快速找表，包括：支持表基础信息、业务描述信息、产出信息等支持分区、字段的明细信息与变更记录支持表的产出信息解析（包括对表写入数据 或者 创建分区的调度任务）支持表、字段的血缘信息解析（实时解析）支持对表进行分级分类、收藏等操作支持全局检索、按类目导航检索、按类目过滤表基础信息：表血缘信息：全面数据安全在数据安全方面，DataWorks支持Datalake引擎数据全生命周期的安全管理。包括以下5个方面：数据传输安全数据源访问控制数据存储安全存储加密数据备份数据处理安全Ranger精细化数据授权管控规范化开发流程，开发环境、生产环境执行身份独立管理数据交换安全数据脱敏通用数据安全RBAC权限模型操作行为审计LDAP认证管理快速分析服务SQL查询：完善的SQL查询编辑器，支持即席查询Hive、SparkSQL、Impala电子表格：即席分析数据，Web类型的Excel数据服务：低代码快速搭建ClickHouse API开通购买快速开通使用快速入门：https://help.aliyun.com/document_detail/445672.html使用须知：https://help.aliyun.com/document_detail/441120.html快速绑定DataWorks on EMR：https://dataworks.console.aliyun.com/emrGuide迁移助手调度任务迁移为了帮助客户快速将原有的调度任务迁移到DataWorks上使用，我们提供了迁移助手，支持以下任务迁移能力：支持Airflow，Oozie，Azkaban工作流迁移支持EMR数据开发一键迁移至DataWorks工作空间之间各种数据对象迁移欢迎钉钉扫码加入EMR产品交流群
-
发表了文章 2022-06-29
国内首批！阿里云云原生数据湖产品通过信通院评测认证
近日，中国信息通信研究院 (以下简称“信通院”) 正式公布了第十四批“大数据产品能力评测”结果，阿里云云原生数据湖产品，包括云原生开源大数据平台 E-MapReduce、数据湖构建 DLF（Data Lake Formation）、对象存储 OSS 以及 DataWorks等产品。整个产品体系提供“统一元数据管理、数据入湖、数据存储、缓存加速、弹性计算、容器、数据分析、任务编排、运维管理，以及安全”等全面数据湖能力。通过了工业和信息化部中国信息通信研究院大数据能力专项评测，荣获“云原生数据湖基础能力专项评测证书”。本次的数据湖评测，是信通院推进的国内首家数据湖标准评测，共涉及存储能力、计算能力、安全能力、数据管理能力、兼容能力、运维能力、湖应用能力、高可用能力八个能力域。阿里云及国内友商等都参与标准设计，最终阿里云以得分排名第一的标准考核荣获云原生数据湖专项评测证书。国内首批！得分排名第一！随着各行业数字化转型不断深入，基于数据驱动的业务场景不断涌现，企业开始产生“多样数据源统一存储、数据统一管理、业务高低峰资源动态调配”等需求。而数据湖是一个统一存储池，支持结构化、半结构化、非结构化等多种格式存储海量数据，同时具有低成本、可拓展性强、灵活高效等特性，越来越多企业选择数据湖作为企业数据存储、管理的解决方案。近年来Hudi、Iceberg、Delta Lake三大开源数据湖的面世推动数据湖整体进入产品化阶段。与此同时，与容器、Serverless等云原生技术的深度融合，引领数据湖产品开始走向云原生。云原生数据湖支持异构数据灵活存储、计算资源弹性伸缩，能够帮助企业应对当前数据结构愈发复杂、数据处理分析时效性要求不断提高的业务环境。2022年3月29日-3月31日，在中国信通院组织的第十四批“可信大数据”产品能力评测中，阿里云计算有限公司顺利完成了首个云原生数据湖评测。参与此次评测的是阿里云云原生数据湖产品，包括云原生开源大数据平台 E-MapReduce、数据湖构建 DLF（Data Lake Formation）、对象存储 OSS 以及 DataWorks等产品。整个产品体系提供“统一元数据管理、数据入湖、数据存储、缓存加速、弹性计算、容器、数据分析、任务编排、运维管理，以及安全”等全面数据湖能力。E-MapReduce开源大数据平台 E-MapReduce（简称“EMR”）是云原生开源大数据平台，向客户提供简单易集成的Hadoop、Hive、Spark、Flink、Presto、Clickhouse、StarRocks、Delta、Hudi、HBase 等开源大数据计算和存储引擎。EMR 计算资源可以根据业务的负载情况做动态调整，EMR可以部署在阿里云 ECS 和 ACK 上。数据湖构建 DLF数据湖构建（Data Lake Formation，DLF）作为云原生数据湖架构核心组成部分，帮助用户快速构建云原生数据湖解决方案。数据湖构建DLF提供数据入湖、湖上元数据统一管理、企业级权限控制，并无缝对接多种计算引擎，打破数据孤岛，洞察业务价值。对象存储OSS阿里云对象存储OSS（Object Storage Service）提供海量、安全、低成本、高可靠的云存储服务，提供99.9999999999%(12个9)的数据持久性，99.995%的数据可用性。多种存储类型供选择，全面优化存储成本。DataWorks DataWorks 提供智能数据建模、全域数据集成、高效数据开发、主动数据管理、全面数据安全、快速数据服务六大全链路大数据开发治理能力，帮助企业快速构建数据中台。企业可以基于 DataWorks + E-MapReduce + DLF + OSS 在云上轻松构建一套完整的数据湖解决方案，目前阿里云已经与互娱、游戏、金融和在线教育等行业客户携手，通过数据湖解决方案加速企业内部数据应用的创新。欢迎钉钉扫码加入数据湖交流群获取数据湖最新资讯和最佳行业实践~
-
发表了文章 2022-06-01
关于 Data Lake 的概念、架构与应用场景介绍
数据湖(Data Lake)概念介绍什么是数据湖（Data Lake）？数据湖的起源，应该追溯到2010年10月，由 Pentaho 的创始人兼 CTO， James Dixon 所提出，他提出的目的就当时历史背景来看，其实是为了推广自家产品 Pentaho。当时核心要解决的问题是传统数据仓库报表分析面临的两个问题：只使用一部分属性，这些数据只能回答预先定义好（pre-determined）的问题。数据被聚合了，最低层级的细节丢失了，能回答的问题被限制了。技术概念的提出，本质都是为了业务场景服务的，是为解决某类特定场景的问题。而我们当前所讨论的数据湖，已经远远超过了当初 James Dixon 所定义的数据湖，各厂商之间也对数据湖有了更多的不同定义。Wikipedia A data lake is a system or repository of data stored in its natural/raw format, usually object blobs or files. A data lake is usually a single store of data including raw copies of source system data, sensor data, social data etc., and transformed data used for tasks such as reporting, visualization, advanced analytics and machine learning. A data lake can include structured data from relational databases (rows and columns), semi-structured data (CSV, logs, XML, JSON), unstructured data (emails, documents, PDFs) and binary data (images, audio, video). A data lake can be established "on premises" (within an organization's data centers) or "in the cloud" (using cloud services from vendors such as Amazon, Microsoft, or Google).“数据湖是一类存储数据自然/原始格式的系统或存储，通常是对象块或者文件。数据湖通常是企业中全量数据的单一存储。全量数据包括原始系统所产生的原始数据拷贝以及为了各类任务而产生的转换数据，各类任务包括报表、可视化、高级分析和机器学习。数据湖中包括来自于关系型数据库中的结构化数据（行和列）、半结构化数据（如CSV、日志、XML、JSON）、非结构化数据（如 email、文档、PDF 等）和 二进制数据（如图像、音频、视频）。数据湖可以构建在企业本地数据中心，也可以构建在云上。”AWSA data lake is a centralized repository that allows you to store all your structured and unstructured data at any scale. You can store your data as-is, without having to first structure the data, and run different types of analytics—from dashboards and visualizations to big data processing, real-time analytics, and machine learning to guide better decisions.“数据湖是一个集中式存储库，允许您以任意规模存储所有结构化和非结构化数据。您可以按原样存储数据（无需先对数据进行结构化处理），并运行不同类型的分析 – 从控制面板和可视化到大数据处理、实时分析和机器学习，以指导做出更好的决策。”微软Azure Data Lake includes all the capabilities required to make it easy for developers, data scientists, and analysts to store data of any size, shape, and speed, and do all types of processing and analytics across platforms and languages. It removes the complexities of ingesting and storing all of your data while making it faster to get up and running with batch, streaming, and interactive analytics. “Azure 的数据湖包括一切使得开发者、数据科学家、分析师能更简单的存储、处理数据的能力，这些能力使得用户可以存储任意规模、任意类型、任意产生速度的数据，并且可以跨平台、跨语言的做所有类型的分析和处理。数据湖在能帮助用户加速应用数据的同时，消除了数据采集和存储的复杂性，同时也能支持批处理、流式计算、交互式分析等。”阿里云“数据湖是统一存储池，可对接多种数据输入方式，您可以存储任意规模的结构化、半结构化、非结构化数据。数据湖可无缝对接多种计算分析平台，根据业务场景不同，可以选择相应的计算引擎对数据湖中存储的数据进行数据处理与分析，从而打破孤岛，挖掘业务价值。”综上所述，不同厂商对数据湖都有不同的一些描述和理解，但从上面我们可以看到，大家也有一些共通点：统一的数据存储，存放原始的数据。支持任意结构的数据存储，包括结构化、半结构化、非结构化。支持多种计算分析，适用多种应用场景。支持任意规模的数据存储与计算能力。目标都是为了更好，更快的发现数据价值。关于 Data Lake 每个人都有自己不同的理解，它是一套解决问题的理念，从根本上解决了业务场景所遇到的一些问题，在解决问题的过程中，技术实现上会有一定的差异与不同。数据湖应该具备哪些能力数据湖本身其实是一套解决方案，它是为企业的业务诉求服务的，是为发现数据价值提供的一套数据解决方案，那么在这套解决方案里它应该具备怎么样的一些能力，才能满足业务需求呢？数据存储统一存储系统数据需要集中存储在一个存储系统中支持海量数据存储系统需要支持海量数据的存储，并且需要具备可扩展的特性，以支持海量数据的存储及性能要求。如 HDFS、AWS S3、Aliyun OSS 等。任意类型数据可以支持任意数据类型的存储，包括结构化、半结构化、非结构化的数据。原始数据不变数据应该在整个数据湖中保持最原始的一份数据，它与原始数据完全一模一样。数据分析支持多种分析引擎可以通过多种引擎对湖上数据进行分析计算，例如离线分析、实时分析、交互式分析、机器学习等多种数据分析场景。计算可扩展性计算引擎需要具备可扩展的能力，具备随数据量不断变大、业务不断增长的弹性数据分析的能力。存储与计算分离（云上）在云上，大家现在都实现了存算分离的数据湖架构，它让存储和计算分别插上了翅膀，可以灵活的进行资源伸缩，大大节省了成本。但在云下 HDFS 架构下，它并不是一个必备能力，因为硬件成本是相对固定的。数据湖管理上述的数据存储和数据分析是数据湖必须具备的基本能力，但是就一个解决方案来说，如果要实际解决业务问题，仅仅是基础能力，并不足以将其应用落地，甚至会变为可怕的数据沼泽。所以在数据湖解决方案中，还需要结合一系列的数据湖上的管理能力，帮助大家管理和识别数据湖中的数据。这些能力包括：多样化的数据入湖需要具备把各种数据源接入集成到数据湖中的能力，作为数据湖构建的第一步，其意义不言而喻。元数据管理提供统一的元数据能力，可以快速发现数据湖上的元数据，并可对元数据进行管理和优化，避免数据湖成为数据沼泽。数据安全对数据可以进行细粒度的权限管控，为企业的数据湖加上安全的锁。更丰富的能力还应该支持敏感数据脱敏，数据加密，标签权限，操作审计等能力。数据质量数据质量是对湖内数据正确性、合理性监控的一种能力，及时发现数据湖中数据质量的问题。为有效的数据探索提供保障。数据探索可提供在线的数据探索能力，可以满足日常对湖内数据进行快速探索和简单查看的能力，便于更好的管理湖内的数据。数据湖能解决哪类问题数据分散，存储散乱，形成数据孤岛，无法联合数据发现更多价值这方面来讲，其实数据湖要解决的与数据仓库是类似的问题，但又有所不同，因为它的定义里支持对半结构化、非结构化数据的管理。而传统数据仓库仅能解决结构化数据的统一管理。在这个万物互联的时代，数据的来源多种多样，随着不同应用场景，产出的数据格式也是越来越丰富，不能再仅仅局限于结构化数据。如何统一存储这些数据，就是迫切需要解决的问题。存储成本问题数据库或数据仓库的存储受限于实现原理及硬件条件，导致存储海量数据时成本过高，而为了解决这类问题就有了HDFS/对象存储这类技术方案。数据湖场景下如果使用这类存储成本较低的技术架构，将会为企业大大节省成本。结合生命周期管理的能力，可以更好的为湖内数据分层，不用纠结在是保留数据还是删除数据节省成本的问题。SQL 无法满足的分析需求越来越多种类的数据，意味着越来越多的分析方式，传统的 SQL 方式已经无法满足分析的需求，如何通过各种语言自定义贴近自己业务的代码，如何通过机器学习挖掘更多的数据价值。存储/计算扩展性不足传统数据库等在海量数据下，如规模到 PB 级别，因为技术架构的原因，已经无法满足扩展的要求或者扩展成本极高，而这种情况下通过数据湖架构下的扩展技术能力，实现成本为0，硬件成本也可控。业务模型不定，无法预先建模传统数据库和数据仓库，都是 Schema-on-Write 的模式，需要提前定义 Schema 信息。而在数据湖场景下，可以先保存数据，后续待分析时，再发现 Schema，也就是 Schema-on-Read。LakeHouse 与数据湖Lakehouse 概念由 Databricks 公司提出，更多内容大家可以阅读：https://databricks.com/blog/2020/01/30/what-is-a-data-lakehouse.htmlLakehouse 是一种新的数据技术架构，它在数据湖的基础之上，吸收了数据仓库，数据库的一些特性。这些特性最核心的一个特性是对 ACID 的支持。Lakehouse 方案简化了整个数据链路，并提高了数据链路的实时性。它从原来的 Lambda 架构，升级到了 Kappa 架构：从上述 gartner 报告来看，无论是开源社区还是云厂商之间，对于 Delta Lake 都已经有了成熟的解决方案，但 Lakehouse，目前一些技术还是初步应用阶段，但从去年开始已经很多公司将其逐步应用到了各自的业务系统中，并为业务带来了更多价值。从后续我们的应用场景案例中大家也可以看到关于开源的湖格式 Delta Lake/Hudi/Iceberg 的一些具体应用。湖格式为大家带来了更多的可能，更多人愿意尝试，相关技术讲解可参考我们后续的系列文章。DataWarehouse & Data Lake & LakeHouse 不同维度对比下图是从各个维度对三种架构的对比，方便我们更好的理解他们的差异以及解决的问题。基于阿里云体系的云原生数据湖架构数据湖存储基于阿里云OSS 产品，可以为数据湖提供稳定的存储底座，它具备高可靠、可扩展、已维护、高安全、低成本、高性能等特点。并提供了版本控制，生命周期等能力。数据湖计算阿里云的大数据分析引擎都支持 OSS 对象存储，如果您使用开源体系，可以使用 E-MapReduce 产品，它为您提供了开源 Spark/Hive/Trino/Flink 等计算能力。如果您喜欢全托管的服务，可以使用 MaxCompute/Databricks/Hologres/Flink 等计算产品。JindoData 是阿里云开源大数据团队自研的数据湖存储加速套件，面向大数据和 AI 生态，为阿里云和业界主要数据湖存储系统提供全方位访问加速解决方案。JindoData 套件基于统一架构和内核实现，主要包括 JindoFS 存储系统（原 JindoFS Block 模式），JindoFSx 存储加速系统（原 JindoFS Cache 模式），JindoSDK 大数据万能 SDK 和全面兼容的生态工具（JindoFuse、JindoDistCp）、插件支持。数据构建与管理阿里云数据湖构建（Data Lake Formation，DLF）是一款全托管的快速帮助用户构建云上数据湖的服务，产品为云原生数据湖提供了统一的元数据管理、统一的权限与安全管理、便捷的数据入湖能力以及一键式数据探索能力。用户可以通过快速完成云原始数据湖方案的构建与管理，并可无缝对接多种计算引擎，打破数据孤岛，洞察业务价值。结合访问控制与云监控两款产品，可以为数据湖提供用户管理、权限控制、监控审计等能力。数据集成可以通过 Dataworks 的数据集成能力，DLF 的数据入湖，以及 Flink 产品的 CDC，完成数据的全链路入湖，支持多种数据源的数据入湖能力。离线作业的数据开发、任务调度可以使用 Dataworks 产品实现，也可以使用开源系列方案如 airflow+zeppelin/jupyter 等实现。实时作业的数据开发、任务调度管理可以通过 Flink 产品实现。数据质量、数据治理等功能可以通过 Dataworks 产品实现。数据湖的构建、管理与应用过程数据湖的应用场景传统大数据平台升级为数据湖架构传统IDC机房的大数据平台存在以下的问题：物理机自建集群，日常运维成本较高业务发展迅速, 流量压力, 计算压力不断增加，资源不足，补货周期长数据分散，不同项目之间标准混乱数据定义模糊，没有有效分层,分析使用困难解决方案存量数据通过 Jindofs 迁移到阿里云的OSS基于 EMR+DLF 构建整个数据平台的基础服务使用 EMR 弹性伸缩满足计算量需求使用 DLF 快速构建数据湖所需服务接入 Druid、Hologres、Impala 为上层数据应用提供有力的支持业务价值极大的减少了运维成本, 运维人员减少30%使用 EMR 弹性伸缩大大缩减了计算成本，减少10%-20%通过 Jindofs+OSS 归档存储，减少10%-20%存储成本构建统一的数据标准, 对数据进行分层, 极大的提升了业务方使用效率新零售公司全托管数据湖业务难点：线下 Hadoop，组件多，平台运维困难、成本高数据开发、运维难度大，任务稳定性差缺乏健全的安全体系解决方案与业务价值：统一存储：对象存储 OSS，可存储任意规模的数据，可对接业务应用、各类计算分析平台数据湖构建与管理：数据湖构建 DLF，解决数据入湖、统一元数据管理、统一权限控制等关键问题数据湖格式：Deltalake，该格式支持数据的增量更新和消费，从而避免了使用 Lamda 架构的两条链路来支持离线和实时的数据计算数据分析计算引擎：DDI 数据洞察+EMR-Presto 交互式分析，在保证软件产品功能和性能领先的基础上，提供了全托管免运维的服务，同时有极高的 SLA 保证数据开发与调度：EMR Studio 是 E-MapReduce 用于开源大数据开发场景的集群类型，提供交互式开发、作业提交、作业调试和工作流一站式数据开发体验数据流程：整体架构图如下：广告行业应用业务难点存算不分离，无法进行灵活指的组件升级，很多新的组件特性没法使用存储在本地盘上，运维难度搞，有坏盘的经历。存储成本高，没法做冷热分层元数据管理在单一的集群上，快集群使用不便，集群稳定性直接影响元数据服务稳定性流批不分离，相互干扰，带来作业稳定性问题解决方案与业务价值存算分离，简化了价格，随时可以升级最新版本，使用Flink, Hudi的最新特性对存储在 OSS 上的数据进行冷热分层，节约成本使用 DLF，进行元数据管理，同时管理数据权限。同时快速支持Flink, Hudi等新特性Hbase 使用 Jindo Block 模式，方便扩容Flink 和 Hbase 等业务分离，提高了业务的稳定性使用 Hudi 的数据湖格式，实现了数据的快速插入，支持了快速的元数据变更，也能支持业务的准实时分析场景互联网金融公司湖与仓的融合，湖仓一体业务难点公司的第一代数据湖是基于 Hadoop + OSS 搭建的，同时引入的数据中台的执行引擎和存储是 Maxcompute，两套异构的执行引擎带来存储冗余、元数据不统一、权限不统一、湖仓计算不能自由流动解决方案如图架构 MaxCompute 和 EMR 不同引擎用于不同的业务场景，使用阿里云数据湖构建 DLF 统一做元数据管理和统一用户权限管理。通过 DataWorks 进行全链路数据治理，提升数据质量与应用能力业务价值将 EMR 的元数据统一到DLF，底层使用 OSS 作统一存储，并通过湖仓一体打通EMR数据湖和 MaxCompute 数仓两套体系，让数据和计算在湖和仓之间自由流动实现湖仓数据分层存储。数据中台对数据湖数据进行维度建模的中间表存储在 MaxCompute上，EMR 或其他引擎消费 ADS 层更多关于数据湖方案及技术的解析，请参考我们后续文章。数据湖揭秘—Delta Lake数据湖构建—如何构建湖上统一的数据权限欢迎钉钉扫码加入数据湖交流群一起参与讨论~
-
发表了文章 2022-05-26
StarRocks X Flink CDC，打造端到端实时链路
作者：王天宜 - StarRocks 解决方案架构师周康 - 阿里云开源大数据OLAP团队 实时数仓建设背景实时数仓需求 随着互联网行业的飞速发展，企业业务种类变得越来越多，数据量也变得越来越大。以 Apache Hadoop 生态为核心的数据看板业务一般只能实现离线的业务。在部分领域，数据实时处理的能力已经成为限制企业数据变现的重要瓶颈之一。搭建数据看板快节奏地进行数据分析，已经成为了一种必然的选择。 实时数仓发展 实时数仓有三个著名的分水岭：第一个分水岭是从无到有，Apache Storm 的出现打破了 MapReduce 的单一计算方式，让业务能够处理 T+0 的数据；第二个分水岭是从有到全，Lambda 与 Kappa 架构的出现，使离线数仓向实时数仓迈进了一步，而 Lambda 架构到 Kappa 架构的演进，实现了离线数仓模型和实时数仓模型的紧密结合；第三个分水岭是从繁到简，Flink 技术栈的落地使实时数仓架构变得精简，并且是现在公认的流批一体最佳解决方案。 以 Flink 作为实时计算引擎实现的实时数仓，将一部分复杂的计算转嫁给 OLAP 分析引擎上，使得应用层的分析需求更加灵活。但仍然无法改变数据仓库变更数据的排斥。下一代的实时数仓平台，不仅要提供更为优秀的性能，同时也需要更为完善的功能以匹配不同的业务。 作为一款全平台极速 MPP 架构，StarRocks 提供了多种性能优化手段与灵活的建模方式，在预聚合、宽表和星型/雪花等多种模型上，都可以获得极致的性能体验。通过 StarRocks 结合 Flink 构建开源实时数仓的方案，可以同时提供秒级数据同步和极速分析查询的能力。同时，通过 StarRocks 主键模型，也可以更好地支持实时和频繁更新等场景。 基于 Flink 的开源实时数仓痛点 原有基于 Flink 构建实施数仓的方案中，由于数据源的多样性，需要使用不同的采集工具，如 Flume、Canal、Logstash。对于不同的业务，我们通常会采用不同的分析引擎。比如，对于固定报表业务，根据已知的查询语句可以预先将事实表与维度表打平成宽表，充分利用 ClickHouse 强大的单表查询能力；对于高并发的查询请求，可以使用 Apache Druid 承受大量用户高峰时期集中使用带来的并发压力。通过技术栈堆叠的方式确实可以满足业务要求，但也会让分析层变得臃肿，增加开发与运维的成本。 一般来说，StarRocks X Flink 构建开源实时数仓生态架构分为五层： 第一层是数据源。数据源可以是多种多样的，比如说 MySQL Binlog、爬虫数据或者是平面文件； 第二层是数据采集层。用户使用多种不同的 CDC 工具，比如 Canal、Debezium 拉取上游的增量数据，通常会将数据写入到 Kafka 中，而后在通过 Flink 消费 Kafka 中的数据； 第三层是实时计算层。可以通过 Flink 的实时计算能力完成轻量级的 ETL 工作，如拼宽表或数据清洗等； 第四层是数据存储层。Flink 相比其他的实时技术栈更加依赖 OLAP 引擎； 最后一层是后端应用层。可以是实时监控系统，实时报表系统，实时推荐系统以及实时数据接口服务。 我们常说，天下武功，唯快不破。以 Flink 为计算引擎构建的实时数仓系统，最关心的就是数据摄入速度足够快，延迟足够低。 在这样一套架构中，数据从数据源到 OLAP 分析系统途径采集工具层，消息队列层，实时计算层。冗长的链路给开发和运维带来了极大的风险，任何一个模块的阻塞都会对实时性产生影响。同时，在数据存储层上，我们也会选择不同的存储引擎适配不同的业务。对于上面的数据链路，我们也面临着诸多的挑战，需要从时效性、功能性及可维护性上做更多的探索，由此可以总结归纳出多个方面尚待优化： CDC 组件不统一，链路过长，任何组件出现瓶颈都会对时效性产生影响，组件过多，需要多部门协作维护，学习成本与维护成本成倍增长； 部分同步组件，如 Debezium 在保证数据一致性时，需要对读取的表加锁，可能会影响业务更新； 分析层使用多种数据存储产品适应不同的业务类型，难以有一种产品能够适应大部分的业务； 去重操作对应逻辑复杂，需要在 flink 里面增加 MapStat 逻辑。 Flink CDC，打通端到端链路 Flink CDC 是由 Flink 社区开发的集数据采集、数据转换、数据装载一体的组件，可以直接从 MySQL、PostgreSQL、Oracle 等数据源直接读取全量或增量数据并写入下游的 OLAP 数据存储系统。使用 Flink CDC 后，可以简单高效的抓取上游的数据变更，同步到下游的 OLAP 数据仓库中。 构建一体化数据传输链路 在传统的实时数仓建设中，数据采集工具是不可或缺的。由于上游的数据源不一致，通常来说我们可能会在数据采集层接入不同的同步与采集工具，比如采集 Oracle 中的数据时，我们通常选择 GoldenGate，而对于 MySQL，我们可能会选择 Canal 或 Debezium。有些采集工具支持全量数据同步，有些支持增量数据同步。数据经过采集层后，会传输到消息队列中如 Kafka，然后通过 Flink 消费 Kafka 中的增量数据再写入下游的 OLAP 数据仓库或者数据湖中。 在业务开发中，上游的数据源、消息中间件、Flink 以及下游的分析性数据仓库通常在不同的部门进行维护。遇到业务变更或者故障调试时，可能需要多个部门协作处理，增加了业务开发与测试的难度。通过使用 Flink CDC 替换上图中的数据采集组件与消息队列，将虚线框中的采集组件与消息队列合并到计算层 Flink 中，从而简化分析链路，降低维护成本。同时更少的组件也意味着更少的故障与传输瓶颈，数据实效性会进一步的提高。 在使用 Flink CDC 之后，数据链路中的组件变得更少，架构变得清晰简单，维护变得更方便。如在上面的例子中，我们使用 Flink CDC 拉取 MySQL 中的增量数据，通过 Flink SQL 创建事实与维度的 MySQL CDC 表，并在 Flink 中进行打宽操作，将结果写入到下游的 StarRocks 中。通过一个 Flink CDC 作业就可以完成抓取，转换，装载的全过程。 全量 + 增量数据同步 在传统的数据同步框架中，我们通常会分为两个阶段： 全量数据同步阶段：通过全量同步工具，如 DataX 或 sqoop 等，进行快照级别的表同步。 增量数据同步阶段：通过增量同步工具，如 Canal 或 GoldenGate 等，实时拉取快照之后的增量数据进行同步。 在全量数据同步时，为了加快导入的速度，我们可以选择多线程的导入模式。在多线程模型下进行全量数据同步时，在对数据进行切分后，通过启动多个并发任务完成数据的同步。由于多个并发业务之间可能不属于同一个读事务，并且存在一定的时间间隔，所以不能严格的保证数据的一致性。为了保证数据的一致性，从工程学与技术实现的角度做平衡，我们有两种方案： 停止数据的写入操作，通过锁表等方式保证快照数据的静态性。但这将影响在线的业务。 采用单线程同步的方式，不再对数据进行切片。但导入性能无法保证。 通过 Flink CDC，可以统一全量 + 增量的数据同步工作。Flink CDC 1.x 版本中，采用 Debezium 作为底层的采集工具，在全量的数据读取过程中，为了保证数据的一致性，也需要对库或表进行加锁操作。为了解决这个问题，Flink 2.0 中引入了 Chunk 切分算法保证数据的无锁读取。Chunk 的切分算法类似分库分表原理，通过表的主键对数据进行分片操作。 在经过 Chunk 数据分片后，每个 Chunk 只负责自己主键范围内的数据，只要保证每个 Chunk 的读取一致性，这也是无锁算法的基本原理。 StarRocks，实时数据更新新方案 StarRocks 是一款极速全场景 MPP 企业级数据仓库产品，具备水平在线扩缩容能力，金融级高可用，兼容 MySQL 协议和 MySQL 生态，提供全面向量化引擎与多种数据源联邦查询等重要特性。作为一款 MPP 架构的分析性数据仓库，StarRocks 能够支撑 PB 级别的数据量，拥有灵活的建模方式，可以通过物化视图、位图索引、稀疏索引等优化手段构建极速统一的分析层数据存储系统。 StarRocks 在 1.19 版本推出了主键模型（Primary Key model）。相较更新模型，主键模型可以更好地支持实时和频繁更新等场景。主键模型要求表有唯一的主键（传统数据仓库中的 primary key），支持对表中的行按主键进行更新和删除操作。 主键模型对实时数据变更的优化 在 OLAP 数据仓库中，可变数据通常是不受欢迎的。在传统数仓中，一般我们会使用批量更新的方式处理大量数据变更的场景。对于数据的变更我们有两种方法处理： 在新的分区中插入修改后的数据，通过分区交换完成数据变更。 部分 OLAP 数据仓库产品提供了基于 Merge on Read 模型的更新功能，完成数据变更。 分区交换数据更新模式对于大部分的 OLAP 数据仓库产品，我们可以通过操作分区的方式，将原有的分区删除掉，然后用新的分区代替，从而实现对大量数据的变更操作。一般来说需要经历三个步骤： 创建一张新的分区表，根据业务变更，将新的数据存储到新表中； 卸载并删除原有的分区； 将新表中的分区装载到目标表中。 通过交换分区来实现大规模数据变更是一个相对较重的操作，适用于低频的批量数据更新。由于涉及到了表定义的变更，一般来说开发人员无法通过该方案独立完成数据变更。 Merge on Read 数据更新模式部分的 OLAP 数据仓库提供了基于 Merge on Read 的数据变更模型，如 ClickHouse 提供了 MergeTree 引擎， 可以完成异步更新，但无法做到数据实时同步。在指定 FINAL 关键字后，ClickHouse 会在返回结果之前完成合并，从而实现准实时的数据更新同步操作。但由于 FINAL 操作高昂的代价，不足以支撑实时数仓带来的频繁维度更新需求。同时，即便是在低频的更新场景中，也无法将 ClickHouse Merge Tree 的方案复制到其他存储系统中。 StarRocks 提供了与 ClickHouse Merge Tree 类似的更新模型（Unique Key model），通过 Merge on Read 的模式完成数据的更新操作。在更新模型中，StarRocks 内部会给每一个批次导入的数据分配一个版本号，同一主键可能存在多个版本，在查询时进行版本合并，返回最新版本的记录。 Merge on Read 模式在写入时简单高效，但读取时会消耗大量的资源在版本合并上，同时由于 merge 算子的存在，使得谓词无法下推、索引无法使用，严重的影响了查询的性能。StarRocks 提供了基于 Delete and Insert 模式的主键模型，避免了因为版本合并导致的算子无法下推的问题。主键模型适合需要对数据进行实时更新的场景，可以更好的解决行级别的更新操作，支撑百万级别的 TPS，特别适合 MySQL 或其他业务库同步到 StarRocks 的场景。 在 TPCH 标准测试集中，我们选取了部分的查询进行对比，基于 Delete and Insert 模式的主键模型相较于基于 Merge on Read 的 Unique Key 模型，性能有明显的提高： Query 数据量 Primary Key (Delete and Insert) Unique Key (Merge on Read) 性能提升 导入过程中 SELECT COUNT(*) FROM orders; 8000 万 0.24 sec 1.15 sec 6.29x SELECT COUNT(*) FROM orders; 1.6 亿 0.31 sec 3.4 sec 10.97x SELECT COUNT(*), SUM(quantify) FROM orders WHERE revenue < 2000; 1000 万 0.23 sec 3.49 sec 15.17x 导入后 SELECT COUNT(*) FROM orders; 2 亿 0.32 sec 1.17 sec 3.66x SELECT COUNT(*), SUM(quantify) FROM orders WHERE revenue < 2000; 1200 万 0.34 sec 1.52 sec 4.47x 主键模型对去重操作的支持 消除重复数据是实际业务中经常遇到的难题。在数据仓库中，重复数据的删除有助于减少存储所消耗的容量。在一些特定的场景中，重复数据也是不可接受的，比如在客群圈选与精准营销业务场景中，为了避免重复推送营销信息，一般会根据用户 ID 进行去重操作。在传统的离线计算中，可以通过 distinct 函数完成去重操作。在实时计算业务中，去重是一个增量和长期的过程，我们可以在 Flink 中通过添加 MapState 逻辑进行去重操作。但通过 MapStat，多数情况下只能保证一定的时间窗口内数据去重，很难实现增量数据与 OLAP 库中的存量数据进行去重。随着时间窗口的增加，Flink 中的去重操作会占用大量的内存资源，同时也会使计算层变得臃肿复杂。 主键模型要求表拥有唯一的主键，支持表中的行按照主键进行更新和删除操作。主键的唯一性与去重操作的需求高度匹配，在数据导入时，主键模型就已经完成了去重操作，避免了手动去重带来的资源消耗。通过对业务逻辑的拆解，我们可以选取合适去重列作为主键，在数据导入时通过 Delete and Insert 的方式完成“数据根据唯一主键进行去重”的需求。相比于在 Flink 中实现去重，StarRocks 主键模型可以节省大量的硬件资源，操作更为简单，并且可以实现增量数据加存量数据的去重操作。 主键模型对宽表数据变更优化 在固定报表业务场景中，通常会根据固定的查询，在 Flink 中对数据进行简单的业务清洗后打平成宽表，借用宽表极佳的多维分析性能，助力查询提速，同时也简化了分析师使用的数据模型。但由于宽表需要预聚合的属性，在遇到维度数据变更的情况，需要通过重跑宽表以实现数据更新。StarRocks 的主键模型不仅可以应用于数据变更场景，同时部分列更新的功能，也高度契合多种业务对宽表中不同字段进行部分更新的需求。 在宽表模型中，一般会有几十上百甚至上千列。这给通过 UPSERT 方式完成数据更新的主键模型带了一定的挑战。我们需要获得变更行的所有信息后，才能后完成宽表的数据更新。这使得变更操作会附带上回表读取的操作，需要从 StarRocks 中拉取变更的数据行，然后拼出插入的语句完成数据更新。这给 StarRocks 带来了极大的查询压力。部分列更新的功能（partical update）极大程度的简化 upsert 操作。在开启参数 partial_update 后，我们可以根据主键，只修改部分指定的列，原有的 value 列保持不变。 如下面的例子中，我们可以通过 Routine Load 导入方式来消费 Kafka 中的数据。在 properties 中需要设置 "partial_update" = "true"，指定开启部分列更新模式，并指定需要更新的列名 COLUMN(id, name)。 CREATE ROUTINE LOAD routine_load_patical_update_demo on example_table COLUMNS (id, name), COLUMNS TERMINATED BY ',' PROPERTIES ( "partial_update" = "true" ) FROM KAFKA ( "kafka_broker_list" = "broker1:9092,broker2:9092,broker3:9092", "kafka_topic" = "my_topic", "kafka_partitions" = "0,1,2,3", "kafka_offsets" = "101.0.0.200" ); StarRocks X Flink CDC，打造极速统一的开源实时数仓平台 Flink CDC 解决了数据链路冗长的问题，而 StarRocks 在 OLAP 分析层提供了极致的性能与一体化的数据存储方案以匹配不同的业务场景。通过 StarRocks 结合 Flink CDC 构建的实时数仓平台的方案，能够极大程度的减少开发与运维的成本。 StarRocks X Flink CDC，宽表实时数仓架构 使用 StarRocks 与 Flink CDC 的联合解决方案，我们可以较为清晰的将实时数仓规划成为四层结构： 数据源层，实时应用层，与原有架构相同，未做调整 数据传输与计算层，通过引入 Flink CDC，将数据采集层，消息队列与事实计算层都放置在 Flink CDC 中，简化了数据链路，减少了开发与运维成本。 数据分析与存储层，StarRocks 中作为分析层数据存储引擎，能够提供不同的数据模型支撑不同类型的业务，简化了分析层数据存储复杂的技术栈。 在 ETL 不复杂的场景，我们可以将大部分 ETL 的操作放在 Flink 中实现。在某些场景下，业务模型相对简单，事实数据与维度数据利用 Flink 多流 join 的能力打平成宽表，在 Flink 中完成了 DWD，DWS 与 ADS 层模型划分。同时对于非结构化的数据，也可以增量写入到 Iceberg、Hudi 或 Hive 中，利用 StarRocks 的外表功能完成湖仓一体的架构。 当 ETL 的过程中引入较为复杂的业务逻辑是，可能会在 Flink 计算层占用大量的内存资源。同时，宽表的模式无法应对查询不固定的多维度分析场景。我们可以选择使用星型模型来替换宽表模型，将数据清洗与建模的操作放到 StarRocks 中完成。 StarRocks X Flink CDC，实时数据变更架构 在某些复杂的业务，如自助 BI 报表，运营分析等场景中，分析师往往会从不同的维度进行数据探查。查询的随机性与灵活性要求 OLAP 分析引擎对性能和多种建模方式都有良好的支持，以满足使用者近乎“随意”的在页面上拉去指标和维度，下钻、上卷和关联查询。 对于 StarRocks 而言，可以使用更为灵活的星型模型代替大宽表。为了增强多表实时关联能力，StarRocks 提供了不同的 join 方式，如 Boardcast Join、Shuffle Join、Bucket Join、Replica Shuffle Join、Colocation Join。CBO 会根据表的统计信息选择 join reorder 与 join 的类型。同时也提供了多种优化手段，如谓词下推、limit 下推、延迟物化等功能，进行多表关联的查询加速。 基于 StarRocks 的实时 join 能力，我们可以将 ETL 操作后置到 StarRocks 中，在 StarRocks 通过实时 join 的方式完成数据建模。同时通过 Primary Key 模型对于数据变更的支持，可以在 StarRocks 中创建缓慢变化维实现维度数据变更。 通过星型/雪花模型构建的实时数仓，可以将计算层 Flink 的建模操作后置到 StarRocks 引擎中。在 Flink 中，只需要做 ODS 层数据的清洗工作，维度表与事实表会通过 Flink CDC 同步写入到 StarRocks 中。StarRocks 中会在 ODS 层进行事实数据与维度数据的落地，通过聚合模型或物化视图完成与聚合操作。利用 StarRocks 的实时多表关联能力，配合智能 CBO 优化器，稀疏索引及向量化引擎等多种优化手段，能够快速计算查询结果，保证业务的在不同模型层的数据高度同源一致。 在现实生活中，维度的属性并非是静止的，会随着时间的流逝发生缓慢的变化。星型模型可以将事实表与维度表独立存储，将维度数据从宽表中解藕，从而利用 StarRocks 的主键模型处理缓慢变化维的问题。一般来说，我们有三种方案处理缓慢变化维的问题： 使用主键模型，直接根据主键覆盖原有的维度值。这种方式较为容易实现，但是没有保留历史数据，无法分析历史维度变化信息； 使用明细模型，直接添加维度行，通过 version 列来管理不同的维度属性版本，改种方案在查询是需要根据业务条件筛选出合适的维度 version 使用主键模型，在主键中引入 version 信息，混合使用直接修改与新添加维度行的方法，该方法较为复杂，但也能更全面的处理复杂的维度变化需求 StarRocks X Flink CDC 用户案例 在某知名电商平台业务中，通过使用 StarRocks 与 Flink CDC 极大程度的简化聊数据链路的复杂度。用户通过 StarRocks 构建实时数据看板平台，实现了多维度数据筛选、灵活漏斗分析、不同维度上卷下钻的灵活分析。 困难与挑战 在电商数据看板平台中，最初选择了 ClickHouse 作为数据分析层的存储引擎。但随着业务的发展，ClickHouse 在部分场景中无法有效的支撑，主要体现在以下几个方面： 根据用户下单的操作，部分订单的状态会发生变化。但一般来说，超过两周的订单状态基本不会发生变化； 部分变化的数据不适合通过宽表的形式存储，部分的业务需求迭代较为频繁，宽表 + 星型模型的建模方式可以更好的服务于业务变更； ClickHouse 扩缩容操作复杂，无法自动对表进行 rebalance 操作，需要较长的业务维护窗口。 为了解决以上的问题，该电商平台重新做了技术选型。经过不断的对比与压测，最终选择使用 StarRocks 作为分析层的数据存储引擎。 系统架构 在实时看板业务中，主要可以划分成五个部分： 数据源层：数据源注意有两种，来自 Web 端与客户端的埋点日志，以及业务库中的订单数据； Flink CDC：Flink CDC 抓取上游的埋点日志与业务数据，在 Flink CDC 中进行数据的清洗与转换，写入到 StarRocks 中； 数据存储层：根据业务的需求，将 DWD 层中的事实数据联合维度数据拼成宽表，通过视图的方式写入到 DWS 层，在 ADS 层划分出不同的主题域； 数据服务层：包含了数据指标平台和漏斗分析平台两部分，根据内部的指标、漏斗定义进行逻辑计算，最终生成报表供分析师查看； 数据中台：围绕大数据分析平台，提供稳定性保障、数据资产管理、数据服务体系等基础服务； 选型收益 数据传输层：通过 Flink CDC 可以直接拉取上游的埋点数据与 MySQL 订单库中的增量数据。相比于 MySQL -> Canal -> Kakfa -> Flink 的链路，架构更加清晰简单。特别是对于上游的 MySQL 分库分表订单交易库，可以在 Flink CDC 中通过 Mapping 的方式，将不同的库中的表和合并，经过清洗后统一写入到下游的 StarRocks 中。省略了 Canal 与 Kafka 组件，减少了硬件资源成本与人力维护成本。 数据存储层：通过 StarRocks 替换 ClickHouse，可以在业务建模时，不必限制于宽表的业务模型，通过更为灵活的星型模型拓展复杂的业务。主键模型可以适配 MySQL 业务库中的订单数据变更，根据订单 ID 实时修改 StarRocks 中的存量数据。同时，在节点扩容时，StarRocks 更为简单，对业务没有侵入性，可以完成自动的数据重分布。 性能方面：单表 400 亿与四张百万维度表关联，平均查询时间 400ms，TP99 在 800ms 左右，相较于原有架构有大幅的性能提升。替换 StarRocks 后，业务高峰期 CPU 使用从 70% 下降到 40%。节省了硬件成本。 在极速统一上更进一步 一款优秀的产品，只提供极致的性能是不够的。还需要丰富的功能适配用户多样的需求。未来我们也会对产品的功能进行进一步的拓展，同时也会在稳定性与易用性上做进一步的提升。 日前，阿里云 E-MapReduce 与 StarRocks 社区合作，推出了首款 StarRocks 云上产品。我们也可以在 EMR 上选择相应规格的 Flink 与 StarRocks。为了提供更好的使用体验，阿里云 E-MapReduce 团队与 StarRocks 也在不断的对产品进行优化，在未来的几个月会提供以下的功能： 多表物化视图：StarRocks 将推出多表关联物化视图功能，进一步加强 StarRocks 的实时建模能力； 湖仓一体架构：StarRocks 进一步 Apache Iceberg 与 Apache Hudi 外表功能，打造 StarRocks 湖仓一体架构； 表结构变更同步：在实时同步数据的同时，还支持将源表的表结构变更（增加列信息等）实时同步到目标表中； 分库分表合并同步：支持使用正则表达式定义库名和表名，匹配数据源的多张分库分表，合并后同步到下游的一张表中； 自定义计算列同步：支持在源表上新增计算列，以支持您对源表的某些列进行转换计算； 一款优秀的产品也离不开社区的生态，欢迎大家参与 StarRocks 与 Flink 社区的共建，也欢迎大家测试 StarRocks Primary Key X Flink CDC 的端到端实时数仓链路方案。我们会在钉钉群定期推送精彩文章，邀请技术大牛直播分享。欢迎钉钉扫码加入技术交流群参与讨论~
-
发表了文章 2022-05-13
EMR-StarRocks 白皮书来啦！
阿里云EMR StarRocks 产品发布会正式结束拉！本次发布会受到了同学们热情的关注！错过直播的同学可以点击链接回顾精彩内容：发布会视频：https://yqh.aliyun.com/live/emr-starrocks2022此外，为了帮助大家更加深入了解EMR StarRocks,我们推出了EMR StarRocks 白皮书，供各位小伙伴学习参考，免费下载！白皮书下载：https://developer.aliyun.com/ebook/7585内容一览表：StarRocks 新⼀代极速全场景 MPP 数据仓库StarRocks 简介 StarRocks 架构 StarRocks 特性StarRocks ⽣态与⼯具数据迁移 数据摄⼊ 湖仓⼀体 StarRocks X Flink ⽣态 StarRocks 场景解决⽅案固定报表业务 实时看板业务 实时⻛控业务 末端运营业务 ⽤户画像业务 自主BI业务专业服务躬行实践：看完白皮书后跃跃欲试的小伙伴，可以参与EMR StarRocks 首月99元限时体验：https://survey.aliyun.com/apps/zhiliao/Yns9d9Xxz更多精彩推荐：电子书：阿里云 JindoFS+OSS 数据上云实战：https://developer.aliyun.com/ebook/7512EMR OLAP 交流群：钉钉搜索群号31448725，或扫描下方二维码进群
-
发表了文章 2022-05-13
数据湖构建—如何构建湖上统一的数据权限
背景信息阿里云数据湖构建产品（DLF）提供的统一元数据服务，通过完善各种引擎/表格式生态解决了数据湖场景下多引擎面临的数据孤岛和元数据一致性问题，实现了开源大数据引擎及数据湖格式元数据的统一视图，避免了各引擎访问湖上数据其中额外的ETL成本并降低了业务处理链路的延时。但同时另一个问题随之产生即不同的引擎可能有不同的权限模型和用户模型，这导致在不同的引擎上用户和权限无法真正做到互通，如果能够在统一元数据的基础上实现集中式的权限校验，一次权限配置多引擎生效，实现引擎级的权限互通，将极大的提高湖上数据访问的安全性，同时将降低权限管理的复杂性。实现数据湖统一权限服务方案的要点因为不同的引擎/表格式在权限方案上/用户模型上存在着差异，例如在用户模型上EMR Hive/Spark 等开源引擎的用户模型可能是 LDAP，但阿里云的其他产品如MaxCompute、Holo 等是阿里云账号/RAM体系，又比如在权限方案上 EMR Hive/Spark/Presto 等或没有自己的安全体系或借助其他平台实现、特别是一些开源体系的表格式 Hudi/iceberg/delta 等目前完全没有权限控制，而在 Maxcompute/Holo 则有自己的一套权限控制体系，即使开源引擎都能够进行权限控制，但权限的数据、模型和权限校验的行为也根本不可能做到一致，所以在统一的元数据视图的基础上，实现统一的权限服务，需要解决四个重要问题不同引擎的用户体系互通问题实现不同引擎的不同的用户体系能够进行互转不同引擎的权限体系互通问题各引擎和格式使用同一套权限校验体系通过元数据 API 访问/引擎访问，鉴权一致性的问题元数据 API 访问也要使用同样的鉴权体系保持不同引擎能够在现有使用方式上在解决上述两个问题的基础上，能够保持现有用户使用方式、产生的元数据不变数据湖构建之统一权限服务方案介绍数据湖构建统一权限服务方案依托于数据湖统一元数据，是整个数据湖构建基础服务的一部分。整体方案一方面通过将不同引擎的用户体系映射至同一套用户体系来解决用户识别问题，另一方面通过将数据湖统一权限校验机制与开源体系的 EMR hive/spark/Presto/Databricks 等引擎、数据湖格式 Hudi/Delta 等以及与 MaxCompute/Holo（进行中）等引擎集成来解决不同引擎权限数据一致性和互通问题，从而开源引擎访问湖上数据时有了统一的元数据视图及权限校验机制。开源引擎/数据湖格式代理鉴权机制数据湖构建产品是采用类 Ranger Pugin 方案来支持引擎侧鉴权，其方式首先是通过将引擎访问的账号在RAM平台授予 AliyunDLFFullAccess 权限同时将引擎账号添加至 DLF 互信权限名单中（互信权限可通过 Setting API 添加），实现引擎与 DLF 元数据产品的互信，这样当各引擎接受到用户的请求时，这些 Plugin 将拦截该请求并可在引擎侧发起该用户的代理鉴权调用，同时在引擎侧将进行用户模型转换，例如在数据湖构建平台上使用阿里云账号/Ram子账号机制，在引擎侧将 LDAP 用户与云账号进行映射（可采用 LDAP 账号与 RAM 账号同名映射方式简化），鉴权请求在服务端鉴权之后，引擎将鉴权结果返回给用户，此种模式下用户需要具备元数据资源的访问权限即可，权限获取可以通过数据湖构建产品-数据权限页面进行授权获取。引擎侧整体鉴权流程如下：DLF 元数据访问鉴权机制对于直接访问 DLF 元数据的用户将采用双层鉴权模型，亦即用户需要同时具备 DLF 元数据 API 访问权限（在 RAM 上配置）及元数据资源访问权限。前者需要在 Ram平台进行授权（如下图所示），后者跟引擎代理鉴权模式相同需要通过数据湖构建产品-数据权限页面进行授权获取。在 Ram 访问控制平台上可选择用户添加权限，如果用户只读元数据可以授予 AliyunDLFReadOnlyAccess 权限。元数据访问整体鉴权流程如下：数据湖构建之统一权限服务实践前提条件 已开通数据湖构建产品，目前统一权限服务已在所有数据湖构建产品所在region上线。已开通EMR 3.40/5.60及以上版本的集群，如已有其他低版本的EMR请提交工单联系阿里云工程师进行咨询解决。已开启数据湖权限服务端鉴权，可通过如下方式开通需提交工单联系阿里云工程师进行咨询解决通过Settings API（调用 Settings API 需要 DLF Ram Api "dlf:UpdateCatalogSettings"及 DLF admin 角色的权限）未来页面将开放 Settings 配置给用户自行配置具体内容及操作步骤采用阿里云主账号对阿里云Ram子账号(也可对Ram角色)进行admin/super_administrator 角色授权，以进行分权管理。对其他业务阿里云 Ram 子账（Ram角色）在数据湖构建平台集中实施 database及 table 权限的管理对其他业务阿里云 Ram 子账（Ram 角色）通过角色在数据湖构建平台集中实施 database 及 table 权限的管理在数据湖构建平台、EMR引擎中分别访问有权限的表和没有权限的表数据湖构建平台提供丰富的权限 api 供应用产品集成，用户可以加入自己的权限申请、审批流程1. 采用阿里云主账号对阿里云 Ram 子账号进行admin/super_administrator 角色授权，以进行分权管理。导航至数据湖构建-数据权限-角色页面，点击右侧添加用户按钮，选择待授权的 RAM 子账号，点击确定，进行子账号 admin 角色授权，如图：完成后，子账号 test1 将拥有 admin 角色权限，test1 将从 admin 角色获得所有资源的访问和授权权限。后续可以通过 test1账号进行其他账号权限的管理。2.使用 test1 账号登录，对子账号直接授权导航至数据湖构建-数据权限-数据授权页面，点击新增授权，对子账号 data 授权 db1 的 Describe、CreateTable 权限，并授予该 db1 下所有除 Drop 外的表权限，在授权页面选择 data 用户并完成如下授权完成后，data 将具备上述权限。3.使用test1账号登录，创建角色，对角色授权，并将角色授予用户 创建数据湖构建角色test，并将该角色授予给子账号 datamigrator，同时给角色test 授权 db1 的 Describe 权限，并授予该 db1 下所有除 Select 外的表权限此时各账户具备如下权限：账号拥有角色权限test1admin拥有所有资源的访问和授权权限data拥有db1的 Describe、CreateTable、List拥有db1下所有表除 Drop 外的权限（默认拥有自己创建的表权限）datamigratortest拥有db1的Describe、List权限拥有db1下所有表除Select外的权限4.在数据湖平台上进行权限验证在数据湖构建平台上使用 data 子账号访问相关元数据进行权限的验证，例如创建表，删除表，查询表.1) 可正常创建表 test_create_table_from_data2) 可正常删除自己创建的表 test_create_table_from_data3) 删除其他用户创建的表 test_table，将报权限错误4) 使用数据探索访问另一个db下的表，将报权限错误5）用户可自行完成 datamigrator 权限的测试，此处不再过多演示。5.在 EMR 集群进行权限的验证1) 通过 Settings API（近期实现自动化），将EMR集群角色（可在 EMR 集群基础信息页面-ECS应用角色部分找到），添加为互信账号(修改之前通过 GetCatalogSettingsAPI 查看 Settings 内容，避免误修改):{ "Config": { "auth.super.principal": "acs:ram::[aliyunAccountId]:role/AliyunECSInstanceForEMRRole" } }2）在 EMR 集群上，选择 DLF-Auth 组件并按下图所示，启用 hive/Presto/Spark 的鉴权3）对鉴权进行验证使用 data 用户通过 beeline 访问 Hiveserver 执行元数据操作，用户可自行进行其他语句的测试6.其他应用及平台与数据湖元数据/权限 API 集成 数据湖构建平台提供丰富的权限 API 供应用产品集成，用户可以加入自己的权限申请、审批流程权限 API 列表见链接， 用户可选择将元数据 API 及权限 API 集成至自有权限审批平台，以完成自己的业务诉求。总结 目前权限能力陆续在生态上进行集成，能够满足一部分场景需求，但还有一些局限，比如授权操作仅 admin 角色可进行资源授权，基于此我们将在近期推出 Grantable 权限，届时可以将资源的 Grant 权限授予给其他角色和用户，进一步实现权限分治，降低管理压力。另外数据湖构建产品未来将继续在多引擎生态、数据安全上发力，让数据湖构建产品具备更完善的生态和企业级的特性！欢迎钉钉扫码加入数据湖交流群一起参与讨论~
-
发表了文章 2022-05-10
Delta Lake基础介绍（开源版）【Databricks 数据洞察公开课】
作者：王晓龙（筱龙），阿里云开源大数据平台技术专家一、Delta Lake背景回顾1. 大数据平台架构演进大数据平台经历了三种架构的演进：a.第一代：数仓架构支持的场景有限，不适用于高阶复杂的查询分析场景，比如data science和ML场景；scale-out扩展能力差。b.第二代：数据湖+数仓架构可支持多场景应用；多轮ETL，增加了延迟和出错概率，缺乏数据可靠性；支持的workload依然有限；数据冗余带来的存储开销更大。c.第三代：Lakehouse 架构支持所有结构的数据类型同时，也能针对各种分析场景提供支持；中间的元数据管理层尤为重要，它提供可靠的ACID事务，同时可以针对数据库操作提供性能优化。2. Delta Lake - 运行在数据湖之上的可靠存储层Delta Lake作为可靠的数据存储中间层，为构建Lakehouse提供了核心支撑。3. Delta Lake核心特性Delta Lake的核心特性是对ACID事务支持，并且基于事务日志机制，实现可串行化的隔离级别，提供ACID事务，保证读写数据的一致性。Delta Lake 围绕 ACID 底层事务日志，提供了以下能力：时间回溯；可扩展元数据处理；Upserts；Schema约束及演化；缓存及索引优化；数据布局优化；批流一体。二、详解事务日志及ACID事务实现机制1. 示例：Delta Lake表操作首先通过一个示例，来简单了解Delta Lake的基本语法。使用PySpark创建 Delta Lake表，并执行表读写操作。示例版本：PySpark 3.2.1Delta Lake 1.1.0a.Delta Lake Starter - 启动 PySpark启动PySpark并加载 Delta相关依赖：# Using Spark Packages ./bin/pyspark --packages io.delta:delta-core_2.12:1.1.0 --conf "spark.databricks.delta.retentionDurationCheck.enabled=false" --conf "spark.sql.extensions=io.delta.sql.DeltaSparkSessionExtension"b.Delta Lake Starter - DML准备创建表并执行若干 Update/Delete/Merge操作。通过PySpark Datafram API创建一张Delta 表，表的名称是random_num，表中只包含一列数字：>>> data = spark.range(0, 5) >>> data.write.format("delta").save("/tmp/delta_course/delta_table") >>> spark.sql("CREATE TABLE random_num USING DELTA location \"{}\"”.format('/tmp/delta_course/delta_table')接下来往表中执行几条简单的修改操作语句：>>> spark.sql("insert into random_num values(5)").show() >>> spark.sql("update random_num set id = '10' where id = 1").show() >>> spark.sql("delete from random_num where id = 3 ").show()c.Delta Lake文件系统目录结构Delta Lake 表的物理存储目录下, 既包括自身的表数据文件,也包括记录表Schema及表变化的 Delta Logs:Delta数据文件：Parquet文件；Delta事务日志 _delta_log：包含 Meta Data 以及事务操作历史；2. Transaction Log概念Transaction Log（事务日志，也称 Delta Log）是一种有序记录集，顺序记录了Delta Lake表从初始创建以来的所有事务操作。3. Transaction Log设计目标a.Transaction Log的整体设计目标,是实现单一信息源（Single Source of Truth），通过跟踪记录用户所有的表操作，从而为用户提供在任意时刻准确的数据视图。b.同时，因为Delta Lake是基于Apache Spark构建的，依托Spark来管理维护事务日志，所以相比通过Metastore使用单一的数据库管理元数据，Delta Lake具备高可扩展的元数据处理能力，能够支持上百PB的Delta表读写访问。c.除此之外，Delta Lake的事务日志也是其它重要数据管理特性实现的基础，比如数据版本回溯（Time Travel）等。4. Transaction Log实现机制a.Commit在Delta Lake中，Transaction被称为Commit。每个Commit代表一个事务操作，同时也代表了一个数据版本，对应_delta_log目录下的一个json文件。示例：一条Update语句关联的Commit内容>>> spark.sql("update random_num set id = '10' where id = 1").show()上图中的Update语句关联的事务日志中，会包含诸如remove/add这样的动作，后面包含了文件的路径，从路径看都是delta 表的parquet数据文件。事务日志的最后一行是关于commit的详细信息，包括了时间戳、操作名等元数据。在每个Commit里都包含若干更细粒度的动作（Action）。Delta Lake 当前定义的 Action 动作包括：涉及数据文件增加和删除（Add file/Remove file）、元数据更新语义（Update metadata）、事务及协议相关的变更操作（Set transaction、Change protocol）等。通过Spark获取到表的最新状态Delta Lake定义的Commit维护的是变更操作的过程记录，当针对Delta表执行查询语句时，可以通过Spark获取到表的最新状态。Spark会对事务日志做聚合，检查事务日志经历了哪些事务操作，并基于事务日志构建出可靠准确的Delta表状态。小文件问题在变更操作较多的场景，比如CDC，delta log下会生成大量json小文件，对处理性能会造成较大影响。b.Checkpoint为了解决上文提到的小文件问题，Delta Log引入Checkpoint机制。Checkpoints：保存了从 version 0开始到当前时刻所有变更记录（默认每 10 次 Commit创建一个Checkpoint文件）。Checkpoint文件给 Spark 提供了一种捷径来重构表状态，避免低效地处理可能上千条的json格式的小文件。示例：查看checkpoint文件内容>>> chkpt0 = spark.read.parquet( "/tmp/delta_course/delta_table/_delta_log/00000000000000000010.checkpoint.parquet") >>> chkpt0.select("*").show()图中包括从第一版本至今所有变更的历史借助checkpoint，Spark可以快速构建表的状态。Spark通过执行ListFrom 操作，查看所有事务日志文件，快速跳转到最新的checkpoint文件，因此只需处理checkpoint之后的commits即可。示例：ListForm的实现在这个示例中，假设Spark里维护了版本7时刻下表的状态。在版本7之后，Delta表又有若干次的提交。当要查看表的最新状态时，Spark 首先通过ListFrom接口获取版本7之后的所有变更文件，发现版本号10关联的checkpoint文件是最新的checkpoint , Spark只需要基于版本10及随后的11和12两次commit构建表的状态，从而大大提升了元数据操作的性能。因此，借助事物日志及spark，Delta Lake真正实现可扩展的元数据处理支持。c.乐观并发控制并发控制主要解决 ACID 中多个并发事务间的隔离性（Isolation）问题， 即：多个事务同一时间触发，系统应该如何决定事务之间的顺序。在传统数据库领域，有两种典型的实现机制：乐观并发控制和悲观并发控制。乐观并发控制 vs 悲观并发控制悲观并发控制（Pressimistic Concurrency Control，简称PCC），即用锁串行化执行事务；乐观并发控制（Optimistic Concurrency Control，简称OCC），即在只有当冲突发生的时候才采取措施；传统数据库的锁机制其实都是基于悲观并发控制的观点进行实现的；对比悲观并发控制，乐观并发控制可以提供更好的性能；由于大数据场景本身是典型的读多写少场景，因此更适合采用乐观并发控制方式。Delta Lake的设计者们选择了乐观并发控制，并且在发生冲突时采用排他锁实现。排他锁Delta Lake处理并发事务场景下的冲突问题时使用排他锁，包括以下五个步骤：Record the starting table version.Record reads/writes.Attempt a commit.If someone else wins, check whether anything you read has changed.Repeat.示例：并发写入事务示例 - 演示OCC协议实现方式示例中，用户A和用户B都拿到版本号为0的commit，排他锁（mutual exclusion）决定了只能有一个用户能够创建版本号为1的commit，假设接受了User A的commit，就要拒绝User B。Delta Lake为了更好的处理User B的commit，采取了乐观并发控制处理方式，基于操作语义，在版本1基础上完成User B的写入。5. Delta Lake ACID事务实现ACID事务具有四个特性：原子性、一致性、隔离性和持久性。a.原子性 Atomicity如上文介绍，Transaction Log将事务抽象成一个个Commit（文件），Commits里可以包含不同类型的Action，但是每个 Commit 是原子的。Martin Kleppman在DDIA书中对原子性的定义：“ACID atomicity describes what happens if a client wants to make several writes, but a fault occurs after some of the writes have been processed. If the writes are grouped together into an atomic transaction, and the transaction cannot be completed (committed) due to a fault, then the transaction is aborted and the database must discard or undo any writes it has made so far in that transaction. ” —— Martin Kleppmann - Designing Data-Intensive Applicationsb.隔离性 Isolation隔离性是针对并发事务的处理方式，并发事务不应该相互干扰。在Delta Lake中，隔离性是通过OCC+排他锁方式实现的，并且实现了读写的串行化。Martin Kleppman在DDIA书中对隔离性的定义：“Isolation in the sense of ACID means that concurrently executing transactions are isolated from each other: they cannot step on each other’s toes.”c.持久性 DurabilityTransaction Log写入分布式磁盘中，在事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。Martin Kleppman在DDIA书中对持久性的定义“Durability is the promise that once a transaction has committed successfully, any data it has written will not be forgotten, even if there is a hardware fault or the database crashes.”d.一致性 Consistency从Martin Kleppman在DDIA书中对一致性的定义可以看出，原子性、隔离性和持久性是数据库的属性，应用程序可能依赖数据库的原子性和隔离属性来实现一致性，但这并不取决于数据库本身，但一致性是由应用来决定的。Martin Kleppman在DDIA书中对一致性的定义“Atomicity, isolation, and durability are properties of the database, whereas consistency (in the ACID sense) is a property of the application. The application may rely on the database’s atomicity and isolation properties in order to achieve consistency, but it’s not up to the database alone. Thus, the letter C doesn’t really belong in ACID”三、Delta Lake核心特征总结如上文介绍，Delta Lake基于事务日志，具有能够实现Time Travel/Upserts以及支持可扩展的元数据处理等特性。除此之外，像Schema约束及演化等特性，在社区版本的Delta Lake里也都做了支持。在后面的公开课中还会针对基于Delta Lake构建批流一体Lake house架构做分享。除了社区版本的Detla Lake, Databricks商业版提供了商业版的Spark及 Delta Lake引擎，并有一些专有的企业级性能优化特性。下期Delta Lake公开课我们会介绍商业版 Delta Lake 的特性，敬请关注。参考资料Delta Lake Introduction： https://docs.delta.io/latest/delta-intro.htmlDiving Into Delta Lake: DML Internals (Update, Delete, Merge) ：https://databricks.com/blog/2020/09/29/diving-into-delta-lake-dml-internals-update-delete-merge.htmlDiving Into Delta Lake: Unpacking The Transaction Log： https://databricks.com/blog/2019/08/21/diving-into-delta-lake-unpacking-the-transaction-log.htmlDelta Transaction Log Protocol： https://github.com/delta-io/delta/blob/master/PROTOCOL.mdDelta Lake: The Definitive Guide by O’Reilly： https://databricks.com/p/ebook/delta-lake-the-definitive-guide-by-oreilly产品技术咨询https://survey.aliyun.com/apps/zhiliao/VArMPrZOR加入技术交流群
-
发表了文章 2022-05-10
深度解析数据湖存储方案Lakehouse架构【Databricks 数据洞察公开课】
作者：张泊Databricks 软件工程师Lakehouse由lake和house两个词组合而成，其中lake代表Delta Lake（数据湖），house代表data warehouse（数据仓库）。因此，Lakehouse架构就是数据湖和数据仓库的结合。数据仓库和数据湖各自都存在着很多不足，而Lakehouse的出现综合了两者的优势，弥补了它们的不足。数据仓库从上世纪 80 年代开始发展和兴起，它的初衷是为了支持BI系统和报表系统，而它的优势也就在于此。结构化的数据可以通过ETL来导入数据仓库，用户可以方便地接入报表系统以及BI系统。同时，它的数据管控能力也比较强。数据仓库对于数据 schema 的要求非常严格，很多数据仓库甚至也实现了 acid 事务等能力。但是数据仓库对于半结构化数据比如时序数据和日志，以及非结构化数据比如图片、文档等的支持是非常有限的，因此它不适用于类似于机器学习的应用场景。而且一般情况下，数据仓库都是专有系统，使用成本比较高，数据迁移和同步的灵活性比较低。因此，为了解决上述问题，数据湖的架构应运而生。数据湖架构的基础是将原始数据以文件的形式存储在像阿里云OSS、AWS S3 和 Azure blob storage 等对象存储系统上。相比于数据仓库使用的专有系统，使用这些对象存储的成本比较低。数据湖的另一个优势是能够对半结构化和非结构化的数据提供非常好的支持。因为数据可以以文件的形式直接存储在数据湖之中，所以数据湖在机器学习等场景中的应用就比较广泛。但是它对于 BI 和报表系统的支持比较差，通常情况下需要通过ETL将数据转存到实时数据库或数据仓库中，才能支持 BI 和报表系统，而这对于数据的实时性和可靠性都会产生负面的影响。综上，不论是数据仓库还是数据湖，都无法完全满足用户的需求。因此，在很多实际使用场景中，用户会将两者组合起来使用，但是这导致需要构建很多不同的技术栈来支持所有场景。比如对于数据分析，需要将结构化的数据输入到数据仓库，然后建立数据市场，对数据分析和 BI 提供支持；对于数据科学和机器学习的场景，需要把不同的数据比如结构化、半结构化以及非结构化的数据存储到数据湖中，经过数据清理，用来支持机器学习和数据科学等场景；而对于流式数据源，需要通过流式数据引擎存储到实时数据库中，同时还需要对数据湖里的数据进行 ETL 提取、转换和加载，来保证数据的质量。这导致需要很多不同的系统、不同的工具来支持各种架构，同时为了数据的互通（上图红线），还需要处理不同的专有数据格式之间的差异，以上流程都会大大影响整个系统的效率。而且，由于所有技术栈都是互相独立的，导致了维护和使用这些系统的团队也是分散的。比如，数据分析师主要使用数据仓库系统，而数据科学家主要使用数据湖系统，同时数据工程师也需要维护整个系统的不同团队，沟通成本比较高。此外，系统中维护了很多不同格式的数据副本，没有统一的管理数据模型，不同团队的数据很有可能会产生差异。因此，这种复杂的组合型数据系统不是一个好的解决方案。基于此，databricks提出了Lakehouse。Lakehouse的设计基于一个原则：实现一个适用于所有场景的统一平台。解决的办法是综合数据湖与数据仓库的能力——基于数据湖使用的对象存储，构建数据仓库拥有的数据管控能力。而这一切的关键就是其中的结构化事务层。此前，数据湖主要存在以下几个痛点：读写并行，就算是追加写的模式也会产生很多问题。用户的期望是所有写操作能够事务性地被同时读到或者同时没有读到，而这是难以实现的，因为在分布式的对象存储上写多个文件，设置一个文件，数据的一致性都是不能完全被保证的。数据的修改。由于安全合规等原因，用户会有强制性地修改已有数据的需求，特别是有时候需要根据过滤结果细粒度地修改某些数据。由于数据湖在数据管控能力上的不足，在数据湖上实现此需求往往需要使用全部扫描再重写的方式，成本比较高，速度也比较慢。如果一个作业中途失败，而它产生的部分数据已经存入到数据库中，这也会导致数据的损坏。批流混合输入。由于数据在批和流系统中都存在，可能会造成数据在两套系统中不一致，导致读取结果不一致。存数据历史。有些用户需要保证数据查询的可重复性，方案之一是为了这个需求做很多重复的数据快照，但这会导致数据的存储和计算成本都大幅上升。处理海量的元数据。大型数据湖元数据的数据量非常大，经常能够达到大数据的级别。很多数据湖采用的数据目录系统无法支持如此大量的元数据，这也限制了数据湖的扩展性。大量小文件的问题。在数据不断输入的过程中，数据湖内会产生大量小文件，随着时间的推移，小文件的数量可能会越来越多，这会严重影响数据湖的读取性能。性能问题。在数据湖上达到高性能不是一件容易的事。有的时候为了达到一定的性能要求，用户需要手动做一些性能的优化，比如数据分区等，而这些手动的操作又比较容易出错。数据的查询管控。由于数据湖的开放性，确保查询权限合规也是需要解决的问题。质量问题。前面很多点都会导致数据质量的问题。在大数据场景下，如何确保数据的正确性也是一个普遍的问题。而Delta Lake能够为Lakehouse带来数据质量、可靠性以及查询性能的提升。上述前五个问题都是关于数据可靠性，它们都可以通过Delta Lake的 acid 事务能力来解决。在Delta Lake上，每一个操作都是事务的，即每一个操作都是一个整体，要么整体成功，要么整体失败。如果 一个操作在中途失败，Delta Lake会负责将其写入的不完整数据清理干净。具体的实现方式是Delta Lake维护了包含所有操作的一个事务日志，能够保证数据与事务日志的一致性。如上图，某次写操作在某个表中添加了很多数据，这些数据被转换成了parquet格式的两个文件file1和file2。有了事务日志，读操作的时候就能够保证要么读不到这条日志，要么同时读到这两条记录，这样就保证了读取的一致性，解决了读写并行的问题。此外，有了事务日志后也可以对已有数据做细粒度的修改。比如下一次写操作对表中的某些数据进行修改，在事务日志中就会出现删除原有文件file1和添加修改后文件file3这样两条记录。同样，在读取的时候，这两条记录也会被同时读到或者忽略，使读取的一致性得到保证。针对第三点中途失败的作业，Delta Lake写入的事务性能够保证不完整的数据不会被成功写入。对于批流混合的输入数据，由于Spark天然支持批流一体，在写入时可以将批和流的数据写入到同一张表，避免了数据冗余及不一致性。由于事务日志保存了所有操作的历史记录，我们可以对之前某个时间点的历史数据进行查询。具体实现方法是：Delta Lake可以查到历史某个时间点对应的事务日志，并且根据历史的事务日志进行数据重放，得到该时间点的数据状态。这个能力被称为“时间旅行”。那么，Delta Lake是怎样处理海量元数据的呢？答案很简单，使用 Spark 来处理。所有Delta Lake的元数据均以开源parquet的格式存储，数据与元数据总是相伴相生，无需进行同步。使用 Spark 处理元数据，使得Delta Lake的元数据可以在理论上进行无限的扩展。Delta Lake还采用索引的机制来优化性能，它采用分区和不同过滤器等的机制，可以跳过数据的扫描。还采用了Z-ordering的机制，可以在对某个列进行优化的同时，使其他列性能牺牲最小化。为了解决大量小文件的问题，Delta Lake还可以在后台定期对数据布局进行自动优化。如果存储的小文件过多，会自动的将他们合并成大文件，这解决了数据湖中小文件越来越多的问题。对于数据查询的管控，Delta Lake实现了表级别的权限控制，也提供了权限设置 API，可以根据用户的权限动态对视图进行脱敏。最后，Delta Lake实现了schema的验证功能来保证数据质量。存在Delta Lake表中的所有数据都必须严格符合其对应的schema，它还支持在数据写入时做schema 的合并演化。当输入数据的 schema 发生变化的时候，Delta Lake可以自动对表的schema进行相应的演化。总的来说，Delta Lake是在数据湖存储之上，实现了数据仓库拥有的ACID事务特性、高性能数据治理能力以及数据质量保证。同时它是基于开放的存储格式，其本身也是开源的。此外，Delta Lake在架构设计上采用了多层的数据模型来简化设计，一层层逐步提高数据质量。刚刚进入Delta Lake的数据表，完全对应着数据的原始输入，数据质量比较低的，被称为Bronze表。Bronze表的数据保留也可以设置得长一些，以便从这些表中回溯历史数据。Bronze表中的数据经过过滤清理，就可以得到下一层的Silver表，可以使其与其他表或者维度表进行创意操作，进行数据的扩展。再往下一层，可以根据业务的需求对已经清理过滤好的数据进行聚合，得到Gold表，可以直接支持业务分析、报表等应用。可以看到，在Delta Lake架构中，数据质量是在不断提升的。相比于lambda 架构，它的设计优势在于在每一层都可以使用PDO统一的数据管道，以事务性的操作对表进行更新，还可以减少数据冗余，从而优化存储和计算的开销。总体而言，Lakehouse的架构优势有以下几个方面：Delta Lake的计算和存储天然分离，用户可以进行更灵活的资源调度。Lakehouse依赖于可以无限扩容的对象存储服务，其元数据的处理也依赖于高扩展性的 Spark 作业，用户无须关心存储容量的问题。开放的数据格式可以让数据在不同系统之间的迁移更加顺畅。与数据湖相同，Lakehouse同时支持结构化、半结构化与非结构化的数据。批流一体。与 lambda 架构不同，Lakehouse能够做到真正的批流一体，从而简化数据的架构。Databricks公司与阿里云联手打造了全新的产品 databricks 数据洞察，简称DDI。Databricks 独家优化了databricks runtime引擎，也可以理解为Apache Spark的加强版，它与Delta Lake 融合进阿里云的整套生态系统中，与ECS、OSS、JindoFS进行了很好的结合，提供了全托管高性能的企业级 Spark平台，能够同时支持企业的商业洞察分析以及机器学习训练等。产品技术咨询https://survey.aliyun.com/apps/zhiliao/VArMPrZOR加入技术交流群
-
发表了文章 2022-05-10
Databricks 企业版 Spark&Delta Lake 引擎助力 Lakehouse 高效访问
作者：李锦桂（锦犀） 阿里云开源大数据平台开发工程师王晓龙（筱龙） 阿里云开源大数据平台技术专家背景介绍Databricks是全球领先的Data+AI企业，是Apache Spark的创始公司，也是Spark的最大代码贡献者，核心围绕Spark、Delta Lake、MLFlow等开源生态打造企业级Lakehouse产品。2020年，Databricks 和阿里云联手打造了基于Apache Spark的云上全托管大数据分析&AI平台——Databricks数据洞察(DDI，Databricks DataInsight)，为用户提供数据分析、数据工程、数据科学和人工智能等方面的服务，构建一体化的Lakehouse架构。Delta Lake是Databricks从2016年开始在内部研发的一款支持事务的数据湖产品，于2019年正式开源。除了社区主导的开源版Delta Lake OSS，Databricks商业产品里也提供了企业版Spark&Detla Lake引擎，本文将介绍企业版提供的产品特性如何优化性能，助力高效访问Lakehouse。针对小文件问题的优化解法在Delta Lake中频繁执行merge, update, insert操作，或者在流处理场景下不断往Delta表中插入数据，会导致Delta表中产生大量的小文件。小文件数量的增加一方面会使得Spark每次串行读取的数据量变少，降低读取效率，另一方面，使得Delta表的元数据增加，元数据获取变慢，从另一个维度降低表的读取效率。为了解决小文件问题，Databricks提供了三个优化特性，从避免小文件的产生和自动/手动合并小文件两个维度来解决Delta Lake的小文件问题。特性1：优化Delta表的写入，避免小文件产生在开源版Spark中，每个executor向partition中写入数据时，都会创建一个表文件进行写入，最终会导致一个partition中产生很多的小文件。Databricks对Delta表的写入过程进行了优化，对每个partition，使用一个专门的executor合并其他executor对该partition的写入，从而避免了小文件的产生。该特性由表属性delta.autoOptimize.optimizeWrite来控制：可以在创建表时指定CREATE TABLE student (id INT, name STRING) TBLPROPERTIES (delta.autoOptimize.optimizeWrite = true);也可以修改表属性ALTER TABLE table_name SET TBLPROPERTIES (delta.autoOptimize.optimizeWrite = true);该特性有两个优点：通过减少被写入的表文件数量，提高写数据的吞吐量；避免小文件的产生，提升查询性能。其缺点也是显而易见的，由于使用了一个executor来合并表文件的写入，从而降低了表文件写入的并行度，此外，多引入的一层executor需要对写入的数据进行shuffle，带来额外的开销。因此，在使用该特性时，需要对场景进行评估：该特性适用的场景：频繁使用MERGE，UPDATE，DELETE，INSERT INTO，CREATE TABLE AS SELECT等SQL语句的场景；该特性不适用的场景：写入TB级以上数据。特性2：自动合并小文件在流处理场景中，比如流式数据入湖场景下，需要持续的将到达的数据插入到Delta表中，每次插入都会创建一个新的表文件用于存储新到达的数据，假设每10s触发一次，那么这样的流处理作业一天产生的表文件数量将达到8640个，且由于流处理作业通常是long-running的，运行该流处理作业100天将产生上百万个表文件。这样的Delta表，仅元数据的维护就是一个很大的挑战，查询性能更是急剧恶化。为了解决上述问题，Databricks提供了小文件自动合并功能，在每次向Delta表中写入数据之后，会检查Delta表中的表文件数量，如果Delta表中的小文件（size < 128MB的视为小文件）数量达到阈值，则会执行一次小文件合并，将Delta表中的小文件合并为一个新的大文件。该特性由表属性delta.autoOptimize.autoCompact控制，和特性delta.autoOptimize.optimizeWrite相同，可以在创建表时指定，也可以对已创建的表进行修改。自动合并的阈值由spark.databricks.delta.autoCompact.minNumFiles控制，默认为50，即小文件数量达到50会执行表文件合并；合并后产生的文件最大为128MB，如果需要调整合并后的目标文件大小，可以通过调整配置spark.databricks.delta.autoCompact.maxFileSize实现。特性3：手动合并小文件自动小文件合并会在对Delta表进行写入，且写入后表中小文件达到阈值时被触发。除了自动合并之外，Databricks还提供了Optimize命令使用户可以手动合并小文件，优化表结构，使得表文件的结构更加紧凑。在实现上Optimize使用bin-packing算法，该算法不但会合并表中的小文件，且合并后生成的表文件也更均衡（表文件大小相近）。例如，我们要对Delta表student的表文件进行优化，仅需执行如下命令即可实现：OPTIMIZE student;Optimize命令不但支持全表小文件的合并，还支持特定的分区的表文件的合并，例如，我们可以仅对date大于2017-01-01的分区中的小文件进行合并：OPTIMIZE student WHERE date >= '2017-01-01'从Databricks数据洞察产品上的试验数据看，Optimize能使查询性能达到8x以上的提升。媲美企业级数据库的查询优化技术Databricks在数据查询方面也做了诸多优化，包括：特性1：Data Skipping在数据查询系统中，有两种经典的查询优化 技术：一种是以更快的速度处理数据，另一种是通过跳过不相关的数据，减少需要扫描的数据量。Data Skipping属于后一种优化技术，通过表文件的统计信息跳过不相关的表文件，从而提升查询性能。在向Delta表中新增表文件时，Delta Lake会在Delta表的元数据中存储该表文件中的数据前32列的统计信息，包括数据列的最大最小值，以及为null的行的数量，在查询时，Databricks会利用这些统计信息提升查询性能。例如：对于一张Delta表的x列，假设该表的一个表文件x列的最小值为5，最大值为10，如果查询条件为 where x < 3，则根据表文件的统计信息，我们可以得出结论：该表文件中一定不包含我们需要的数据，因此我们可以直接跳过该表文件，减少扫描的数据量，进而提升查询性能。Data Skipping的实现原理和布隆过滤器类似，通过查询条件判断表文件中是否可能存在需要查询的数据，从而减少需要扫描的数据量。如果表文件不可能存在查询的数据，则可以直接跳过，如果表文件可能存在被查询的数据，则需要扫描表文件。为了能尽可能多的跳过和查询无关的表文件，我们需要缩小表文件的min-max的差距，使得相近的数据尽可能在文件中聚集。举一个简单的例子，假设一张表包含10个表文件，对于表中的x列，它的取值为[1, 10]，如果每个表文件的x列的分布均为[1, 10]，则对于查询条件：where x < 3，无法跳过任何一个表文件，因此，也无法实现性能提升，而如果每个表文件的min-max均为0，即在表文件1的x列分布为[1, 1]，表文件2的x列分布为[2, 2]...，则对于查询条件：where x < 3，可以跳过80%的表文件。受该思想的启发，Databricks支持使用Z-Ordering来对数据进行聚集，缩小表文件的min-max差距，提升查询性能。下面我们介绍Z-Ordering优化的原理和使用。特性2：Z-Ordering优化如上一节所解释的，为了能尽可能多的跳过无关的表文件，表文件中作为查询条件的列应该尽可能紧凑（即min-max的差距尽可能小）。Z-Ordering就可以实现该功能，它可以在多个维度上将关联的信息存储到同一组文件中，因此确切来说，Z-Ordering实际是一种数据布局优化算法，但结合Data Skipping，它可以显著提升查询性能。Z-Ordering的使用非常简单，对于表events，如果经常使用列eventType和generateTime作为查询条件，那么执行命令：OPTIMIZE events ZORDER BY (eventType, generateTime)Delta表会使用列eventType和generateTime调整数据布局，使得表文件中eventType和generateTime尽可能紧凑。根据我们在Databricks DataInsight上的试验，使用Z-Ordering优化能达到40倍的性能提升，具体的试验案例参考文末Databricks数据洞察的官方文档。特性3：布隆过滤器索引布隆过滤器也是一项非常有用的Data-skipping技术。该技术可以快速判断表文件中是否包含要查询的数据，如果不包含就及时跳过该文件，从而减少扫描的数据量，提升查询性能。如果在表的某列上创建了布隆过滤器索引，并且使用where col = "something"作为查询条件，那么在扫描表中文件时，我们可以使用布隆过滤器索引得出两种结论：文件中肯定不包含col = "something"的行，或者文件有可能包含col = "something"的行。当得出文件中肯定不包含col = "something"的行的结论时，就可以跳过该文件，从而减少扫描的数据量，提升查询性能。当得出文件中可能包含col = "something"的行的结论时，引擎才会去处理该文件。注意，这里仅仅是判断该文件中可能包含目标数据。布隆过滤器定义了一个指标，用于描述出现判断失误的概率，即判断文件中包含需要查询的数据，而实际上该文件并不包含目标数据的概率，并称之为FPP（False Positive Probability: 假阳性概率）。Databricks支持文件级Bloom过滤器，如果在表的某些列创建了布隆过滤器索引，那么该表的每个表文件都会关联一个 Bloom 筛选器索引文件，索引文件存储在表文件同级目录下的 _delta_index 子目录中。在读取表文文件之前，Databricks会检查索引文件，根据上面的步骤判断表文件中是否包含需要查询的数据，如果不包含则直接跳过，否则再进行处理。布隆过滤器索引的创建和传统数据库索引的创建类似，但需要指定假阳性概率和该列可能出现的值的数量：CREATE BLOOMFILTER INDEX ON TABLE table_name FOR COLUMNS(col_name OPTIONS (fpp=0.1, numItems=50000000))根据我们在Databricks DataInsight上的试验，使用布隆过滤器索引能达到3倍以上的性能提升，试验案例参考文末Databricks数据洞察的官方文档。特性4：动态文件剪枝动态文件剪枝（Dynamic File Pruning, DFP）和动态分区剪枝（Dynamic Partition Pruning）相似，都是在维表和事实表的Join执行阶段进行剪枝，减少扫描的数据量，提升查询效率。下面我们以一个简单的查询为例来介绍DFP的原理：SELECT sum(ss_quantity) FROM store_sales JOIN item ON ss_item_sk = i_item_sk WHERE i_item_id = 'AAAAAAAAICAAAAAA'在该查询中，item为维表（数据量很少），store_sales为事实表（数据量非常大），where查询条件作用于维表上。如果不开启DFP，那么该查询的逻辑执行计划如下：从上图可以看出，先对store_sales进行全表扫描，然后再和过滤后的item表的行进行join，虽然结果仅有4万多条数据，但却扫描了表store_sales中的80多亿条数据。针对该查询，很直观的优化是：先查询出表item中i_item_id = 'AAAAAAAAICAAAAAA'数据行，然后将这些数据行的i_item_sk值作为表store_sales的ss_item_sk的查询条件在表store_sales的SCAN阶段进行过滤，结合我们在上面介绍的Data Skipping技术，可以大幅减少表文件的扫描。这一思路正是DFP的根本原理，启动DFP后的逻辑执行计划如下图所示：可以看到，在启用DFP之后，过滤条件被下推到SCAN操作中，仅扫描了600多万条store_sales中的数据，从结果上看，启动DFP后，该条查询实现了10倍的性能提升，此外，Databricks还针对该特性对TPC-DS测试，测试发现启用DFP后，TPC-DS的第15条查询达到了8倍的性能提升，有36条查询实现了2倍及以上的性能提升。总结前文概括介绍了Databricks企业版Delta Lake的性能优势，借助这些特性能够大幅提升Spark SQL的查询性能，加快Delta表的查询速度。Databricks基于企业版Lakehouse架构为众多企业提供了价值，现599元即可试用阿里云Databricks数据洞察，体验企业版Spark&Delta Lake引擎的极致性能。https://www.aliyun.com/product/bigdata/spark加入我们阿里云计算平台事业部开源大数据生态企业团队负责阿里云上大数据开源生态方向的商业化产品接入，合作伙伴包括Databricks、Confluent、Cloudera、Starburst等开源领域的明星级企业，目前团队在火热招聘中，期待你的加入，邮箱请联系zongze.hzz@alibaba-inc.com参考文档和试验数据Databricks数据洞察官方文档 https://help.aliyun.com/document_detail/190745.html产品技术咨询https://survey.aliyun.com/apps/zhiliao/VArMPrZOR加入技术交流群
-
发表了文章 2022-05-10
Delta Lake的演进历史及现状【Databricks 数据洞察公开课】
作者：王晓龙 阿里云开源大数据平台技术专家一、Delta Lake介绍大数据平台架构发展至今，已经经历了三个阶段的技术演进：从最早的数仓，到数据湖+数仓的架构，再到最近两年的Lakehouse架构。最早的数仓架构是Schema-on-write的设计。如上图，数据首先由关系型数据库经过ETL导入数据仓库里，可以做一些BI分析以及报表分析。它的底层是数据库技术，因此能够提供比较好的数据管理能力，比如能够支持 ACID事务，能够基于Schema-on-write在上游数据写入的时候提供比较强的Schema约束，以此保证数据的质量。同时，基于它自身的诸多优化特性，数仓架构对分析型场景能够提供非常好的支持。但是支持的场景比较有限，基本局限于常用的分析场景。而在大数据时代，随着数据规模的逐渐增加，企业对于数据分析的场景要求越来越多，逐渐产生了一些高级的分析场景需求，比如数据科学类或者机器学习类的场景，而数据仓库对此类需求难以支持。另外，数据仓库也无法支持半结构化以及非结构化的数据。2003年前后，Hadoop面市。伴随着数据规模体量的爆炸式增长，我们对低成本存储的需求也愈发迫切。于是第二代大数据平台架构雏形初现。它以数据湖为基础，能够支持对结构化、非结构化以及半结构化数据的存储。与数据仓库相比，它是一种Schema-on-read的设计，数据能够比较高效地存入数据湖，但是会给下游的分析提供较高的负担。因为数据在写入之前没有做校验，随着时间的推移，数据湖里的数据会变得越来越脏乱，数据治理的复杂度非常高。同时因为数据湖底层是以开放的数据格式存储在云对象存储上，云对象存储的一些特性会导致数据湖架构缺少像数仓一样的数据管理特性。另外因为云对象存储在大数据查询场景上的性能上不足，导致很多场景下都无法很好地体现数据湖的优势。于是第三代大数据平台架构——Lakehouse应运而生。它在数据湖之上抽象出了事务管理层，能够提供传统数仓的一些数据管理特性，还可以针对云对象存储中的数据做一些数据的性能优化。从而能够针对大数据时代各种复杂的分析场景提供支持，且对于流批两种场景也能够提供统一的处理方式。有了Lakehouse架构的背景之后，Delta Lake也应运而生，它是由Databricks开源的一个数据库解决方案，架构清晰简洁，能够提供比较可靠的保障。上图呈现了Delta lake的Multi-hop Medallion架构，即通过多个表结构来提供不同分析场景的支持。数据可以通过streaming的方式流入Delta Lake，也可以使用batch方式导入。Delta Lake里的表可以分为三类：第一类：数据最先导入的表称为bronze table。direct事务的特性能够保证在bronze table中数据的可靠性，因此它是整个数据湖的source of truth（事实表）。某些场景可以直接读取bronze table。第二类：如果对数据有更高的要求，希望对数据做一些清洗，可以通过silver表来实现。它的结构更清晰也更规范，能够支持一些机器学习或其他简单的分析场景。第三类：如果分析对数据的质量要求非常严格，可以在Gold table的基础之上做进一步演进，特征抽取和聚合之后生成Gold table，可以做更高级别的分析。Delta lake底层提供了一种基于事务日志的机制来实现ACID的事务特性，能够实现读写数据的一致性，同时提供较高质量的数据保证。在ACID事务的基础之上，Delta lake提供了更多的数据管理及性能优化特性，比如时间回溯、数据版本等，能够基于它的事务日志回溯到某个时间或某个版本的数据；同时还可以实现数据的高效upsert和delete，以及可扩展的元数据管理的能力。在大数据的场景下，元数据管理本身可能会成为一种负担，因为对于较大的表来说，元数据本身就能成为大数据。所以如何高效地支持元数据管理，也是对架构挑战。Delta lake事务日志场景下，元数据是以文件形式存储在事务log里，因此可以借助Spark这种大数据引擎，来实现数据元数据的扩展性。同时Delta lake还能够提供统一的流批方式，可以以统一的方式对数据的注入提供支持，上述实现的前提是说因为Delta lake能够支持可串行化的隔离级别，实现一些典型的流式需求，比如CDC。同时，为了保证数据湖中的数据质量，Delta lake也提供了Schema的强制约束以及自动演化的能力。此外，在Delta lake的商业版本里，还提供了数据库中的数据布局自动优化的能力，同时实现了传统数仓数据库一系列性能优化特性，比如缓存、索引等优化能力。二、发展回顾Delta lake项目最早开源在2019年4月，事务、流批一体等最核心的功能在0.1版本都已实现。此后，Delta Lake便致力于易用性和开放性的方向在不断努力，Lakehouse也开放了更多技术在开源社区。0.2-0.4版本：提供了对不同云对象存储的支持；0.3版本在API层面的能力也逐渐增强，同时支持了一些常见的DML操作；0.4版本支持了将parquet表格式直接转换成Delta。0.5版本：Delta lake开始尝试对Spark之外的查询引擎提供读场景的支持，这也是社区第一次在Spark之外提供引擎的支持，也是Delta lake开放性目标的一部分；同时0，5版本还提供了一些优化的特性，以及通过SQL的方式直接将parque转成Delta 。0.6版本：Delta Lake做了一些Schema的演化性支持，同时对merge性能也提供了进一步优化，对比如describe history的命令提供了更多metrics信息。0.7版本：随着Spark3.0的开源，Delta lake提供了Spark3.0的兼容。并且基于Spark3.0提供了更多特性：在元数据层面，支持读取Hive metastore元数据，因为元数据本身是 transaction log事务日志的一部分，所以有了Hive metastore的支持，就能够与其他引擎比如presto去共享元数据；在易用性方面，从SQL层面提供了对dml的支持。0.8版本：Delta lake主要贡献是在merge操作上提供了更多性能增强的特性，同时支持了VACUUM的并发删除能力。2021年5月，Delta lake1.0版本正式发布。纵观Delta lake的发展历程，可以清晰地看出，它一直坚定地朝着Everywhere——支持更多元、更开放的生态发展。三、Delta Lake1.0+上图展示了Delta lake 1.0的一些核心特性。首先是Generated Columns特性，这里将以一个示例对特性做介绍。大数据开发场景里有一个比较典型需求：对数据表做分区。比如对日期字段做分区，但是在写入表之前的原始数据里可能并没有日期字段，而是时间戳字段。如上图，eventTime本身是时间戳，但是数据中并没有eventDate的类型。那么应该如何做分区？方案1：直接使用时间戳的字段做分区。时间戳是一个比较细粒度的字段，使用它来做会产生大量的分区，对于查询性能会造成非常大的影响。因此，此方案被排除。方案2：数据写入表之前手动维护额外字段。比如从eventTime字段中抽取得到eventDate。但这需要人工维护字段，而但凡涉及到人工，就容易引入错误，尤其是多种数据源同时写入的情况，要求对多种数据源同时做转换，极易出现差错。因此Delta Lake1.0提供了generated columns，它是一种特殊类型的列，它的值可以根据用户指定的函数自动生成。可以通过如上图简单的SQL语法，将eventTime转换成date类型，从而生成 eventDate字段。整个过程自动完成的，用户只需要在最开始创建表的时候提供这个语法即可。Delta lake1.0提供的第二个重要特性是Standalone。它的目标是可以在Spark之外对接更多引擎，但是诸如Presto、Flink等引擎本身并不需要依赖Spark，如果Delta lake只能强绑定Spark就违背了Delta lake开放性的目标。于是社区推出了Standalone，它在jvm层面实现了对Delta lake事务协议的处理。有了Standalone，后面会有更多引擎接入进来。Standalone最早版本只提供了Reader，随着今年年初Delta Connector 0.3.0版本的发布，Standalone也正式开始支持写操作。此外，社区对Flink Sink/Source、Hive以及Presto的支持也正在开发中。此外，Delta Lake1.0还提供了Delta-rs Rust库。目标也是希望通过Delta-rs库实现对更多高层编程语言的支持，使Delta Lake更加开放。有了Delta-rs库，更多的编程语言，比如Python、Ruby语言可以直接访问Delta Lake table。 依赖Delta-rs Rust库，Delta Lake1.0版本提供了两种Python库的安装选项，可以直接使用pip install的方式安装；此外，如果不想依赖于Spark，也可以简单地使用pip install Deltalake命令行完成对Delta Lake的安装。安装完之后，即可直接使用 Python读取Delta表的数据。最早的Delta Lake是Spark的一个子项目，因此Delta Lake对Spark引擎的兼容性做得非常好。同时，由于Spark社区发展迅速，能够第一时间兼容Spark也是Delta Lake社区的首要目标。所以在1.0版本，Delta Lake首先兼容了Spark 3.1，并对其提供的一些特性进行优化，以便第一时间在Delta Lake里投入使用。很多企业在使用 Delta Lake的时候，一个常用场景是使用单一集群去访问/关联一个存储系统。有Delta Lake1.0对此提供了delegating log store功能，通过log store的方式来支持不同云厂商的对象存储系统，以便能够支持混合云部署的场景，同时也可以避免对单一云服务商产生locking绑定的情况。四、未来展望未来，Delta Lake社区会朝着一个更加开放的方向发展。除了借助于前文提到的核心功能，Delta Lake还能够连接Spark之外的引擎类产品。上图展示了相关功能的上线计划。社区版的Delta Lake里，目前有两个特性的呼声比较高，分别是Optimize和Z-Ordering。这两个特性在Databricks目前开源的Delta Lake版本里面并没有提供，但是在商业版本里已经做了很好的支持。目前阿里云已经推出了基于Databricks商业版本引擎的全托管Spark产品 – Databricks数据洞察，除了此处列出的Optimize及Z-Ordering，可以在上面体验到更多商业版Spark及Delta引擎特性。除此之外，阿里云E-MapReduce产品上也对Optimize和Z-Ordering提供了阿里云自研的实现。Databricks数据洞察产品是基Databricks的引擎提供的全托管数据平台，它最核心的部分是Databricks引擎，Databricks RunTime提供了商业版的Delta Engine以及 Spark引擎。相比于开源的Spark和Delta，商业版在性能上有非常大的提升。最后，看一下Delta Lake当前在全球范围内的应用情况，越来越多的企业已经开始使用Delta Lake来构建Lakehouse。从Databricks给的数据看，目前已有超过3000+客户在生产环境中部署了Delta Lake，每天处理Exabytes级别数据量，其中超过75%的数据已采用Delta格式。
-
发表了文章 2022-05-07
数据湖揭秘—Delta Lake
DeltaLake简介Delta Lake 是 DataBricks 公司开源的、用于构建湖仓架构的存储框架。能够支持 Spark，Flink，Hive，PrestoDB，Trino 等查询/计算引擎。作为一个开放格式的存储层，它在提供了批流一体的同时，为湖仓架构提供可靠的，安全的，高性能的保证。Delta Lake 关键特性：ACID事务：通过不同等级的隔离策略，Delta Lake 支持多个 pipeline 的并发读写；数据版本管理：Delta Lake 通过 Snapshot 等来管理、审计数据及元数据的版本，并进而支持 time-travel 的方式查询历史版本数据或回溯到历史版本；开源文件格式：Delta Lake 通过 parquet 格式来存储数据，以此来实现高性能的压缩等特性；批流一体：Delta Lake 支持数据的批量和流式读写；元数据演化：Delta Lake 允许用户合并 schema 或重写 schema，以适应不同时期数据结构的变更；丰富的DML：Delta Lake 支持 Upsert，Delete 及 Merge 来适应不同场景下用户的使用需求，比如 CDC 场景；文件结构湖表较于普通 Hive 表一个很大的不同点在于：湖表的元数据是自管理的，存储于文件系统。下图为 Delta Lake 表的文件结构。Delta Lake 的文件结构主要有两部分组成：_delta_log目录：存储 deltalake 表的所有元数据信息，其中：每次对表的操作称一次 commit，包括数据操作（Insert/Update/Delete/Merge）和元数据操作（添加新列/修改表配置），每次 commit 都会生成一个新的 json 格式的 log 文件，记录本次 commit 对表产生的行为（action），如新增文件，删除文件，更新后的元数据信息等；默认情况下，每10次 commit 会自动合并成一个 parquet 格式的 checkpoint 文件，用于加速元数据的解析，及支持定期清理历史的元数据文件；数据目录/文件：除 _delta_log 目录之外的即为实际存储表数据的文件；需要注意：DeltaLake 对分区表的数据组织形式同普通的 Hive 表，分区字段及其对应值作为实际数据路径的一部分；并非所有可见的数据文件均为有效的；DeltaLake 是以 snapshot 的形式组织表，最新 snopshot 所对应的有效数据文件在 _delta_log 元数据中管理；元数据机制Delta Lake 通过 snapshot 来管理表的多个版本，并且支持对历史版本的 Time-Travel 查询。不管是查询当前最新的 snapshot 还是历史某版本的 snapshot 信息，都需要先解析得到对应 snapshot 的元数据信息，主要涉及到：当前 DeltaLake 的读写版本协议（Protocol）；表的字段信息和配置信息（Metadata）;有效的数据文件列表；这一点通过一组新增文件（AddFile）和删除文件（RemoveFile）来描述；那在加载具体 snopshot 时，为了加速加载流程，先尝试找到小于或等于该版本的 checkpoint 文件，然后结合其后直到当前版本的 log 文件，共同解析得到元数据信息。EMR DeltaLake阿里云EMR团队从19年就开始跟进 DeltaLake 社区，并将其落地在 EMR 的商业产品中的。期间，在迭代功能，优化性能，融合生态，降低易用性，场景落地等方面，不断打磨升级 DeltaLake，使之更好的融入 EMR 产品，方便客户使用。以下表格汇总了 EMR DeltaLake 较开源 DeltaLake（社区1.1.0）对比的主要自研特性。EMR DeltaLake功能迭代DML语法增强：VERSION/Timestamp AS OF的 time-travel SQL 语法；show partitions、drop partition 语法；动态分区 overwrite 语法；元数据同步 metastore：各种场景的元数据表更同步 DLF/Hive metastore；自动化湖表管理：支持多种策略的自动合并小文件功能（auto-optimize）；支持自动清理过期数据文件（auto-vacuum）；支持永久保存指定版本（savepoint）；支持回退到执行版本（rollback）；支持根据表实际大小自动调整平均文件大小；性能优化支持 min-max 统计和 dataskipping；支持动态分区裁剪（DPP）；支持动态文件裁剪（Runtime Filter）；支持自定义的 manifest，加速 Hive/Presto/Trino/Impala 查询；生态集成支持 Presto/Trino/Impala/阿里云MaxCompute/阿里云Hologres查询；支持阿里云OSS 和 JindoData；与阿里云DLF 深度集成；场景落地实现缓慢变化维SCD Type2的解决方案；实现以 DeltaLake 构建完整增量湖仓架构的 CDC 解决方案；特别说明：DeltaLake1.x 版本仅支持 Spark3，且绑定具体 Spark 版本，导致部分新功能/优化不能在老的版本及 Spark2 上使用，而 EMR DeltaLake 保持 Spark2 的 DeltaLake（0.6）和 Spark3 的 DeltaLake（1.x）的功能特性同步；与 DLF 的深度集成DLF（Data Lake Formation）是一款全托管的快速帮助用户构建云上数据湖及 LakeHouse 的服务，为客户提供了统一的元数据管理、统一的权限与安全、便捷的数据入湖能力以及一键式数据探索能力，无缝对接多种计算引擎，打破数据孤岛，洞察业务价值。EMR DeltaLake 与 DLF 深度集成，使 DeltaLake 表创建写入后自动完成元数据同步到 DLF 的 metastore，避免了像开源版本那样，需要用户再自行建立 Hive 外表关联 DeltaLake 表的操作。同步后，用户可以直接通过 Hive、Presto、Impala，甚至阿里云MaxCompute 及 Hologres 查询，无需任何其他额外操作。同样 DLF 具备成熟的入湖能力，用户可以通过产品端的配置将 Mysql、RDS、Kafka 的数据直接同步生成 DeltaLake 表。在 DLF 的产品侧，湖格式 DeltaLake 作为第一公民，DLF 也将在接下来的迭代中针对性的提供易用的可视化展示，和湖表管理的能力，帮助用户更好的维护湖表。G-SCD 解决方案Slowly Changing Dimension（SCD）即缓慢变化维，被认为是跟踪维度变化的关键ETL任务之一。在数仓场景下，通常使用星型模型来关联事实表和维度表。如果维度表中的某些维度随时间更新，那么如何存储和管理当前和历史的维度值呢？是直接忽略，还是直接覆盖，亦或者其他的处理方式，如永久保存历史所有的维度值。根据不同的处理方式，SCD 定义了多种类型，其中 SCD Type2 通过增加新记录的方式保留所有的历史值。在实际的生产环境中，我们可能不需要关注所有的历史维度值，而关注在固定的时间段内最新的值，比如以天或者小时为粒度，关注在每一天或者小时内某个维度的值。因此实际的场景可以转化为基于固定粒度（或业务快照）的缓慢变化维（Based-Granularity Slowly Changing Dimension，G-SCD）。在传统数仓基于 Hive 表的实现，有几种方式可选，以下列举两个解决方案：流式构建T+1时刻的增量数据表，和离线表的T时刻分区数据做合并，生成离线表T+1分区。其中T表示粒度或业务快照。不难想象该方案每个分区保存了全量的数据，会造成大量的存储资源浪费；保存离线的基础表，每个业务时刻的增量数据独立保存，在查询数据时合并基础表和增量表。该方案会降低查询效率。通过对 DeltaLake 自身的升级，结合对 SparkSQL，Spark Streaming 的适配，我们实现了 SCD Type2 场景。架构如下：同样对接上游的 Kafka 的数据，在 Streaming 端按照配置的业务快照粒度将 Batch数据进行切分，分别 commit，并附带业务快照的值。DeltaLake 在接收到数据后，保存当前 snapshot 和业务快照的关系。并在下一个业务快照到达时，对前一个 snapshot 做 savepoint，永久保留该版本。用户查询时，通过指定的业务快照的具体值，识别到具体的 snapshot，然后通过 time-travel 的方式实现查询。G-SCD on DeltaLake 方案优势：流批一体：不需要增量表和基础表两张表；存储资源：借助 Delta Lake 本身的 data versioning 能力，实现增量变化维度的管理，不需要按时间粒度保留历史全量数据；查询性能：借助 Delta Lake 的元数据 checkpoint，数据的 Optimize、Zorder 及 DataSkipping 的能力，提升查询效率；保留原实现的 SQL 语句：用户依然可以像用分区实现快照的方式一样，使用类似的分区字段执行要查询的业务时间粒度内的快照数据。CDC 解决方案在当前的数仓架构下，我们往往将数据分层为 ODS，DWD，DWS，ADS 等方便管理。原始数据如存储在 Mysql 或者 RDS，我们可以消费其 binlog 数据实现对 ODS 表的增量更新。但，从 ODS 到 DWD，从 DWD 到 DWS 层数据呢？由于 Hive 表本身不具备生成类似 binlog 数据的能力，因此我们无法实现下游各链路的增量更新。而让湖表具备生成类似 binlog 数据的能力，又是构建实时增量数仓的关键。阿里云EMR 基于 DeltaLake 实现了将其作为 Streaming Source 的 CDC 能力。开启后，对所有的数据操作将同时生成 ChangeData 并持久化，以便下游 Streaming 读取；同时支持 SparkSQL 语法查询。如下图所示：ODS 层 Delta 表 user_city_table 接收 Source 数据执行 Merge 操作，同时将变更的数据持久化保存；DWS 层按 city 聚合的 city_cnt_table 表读取 user_city_table表的 ChangeData 数据，对 cnt 聚合字段实现更新。后续规划DeltaLake 作为 EMR 主推的湖格式，得到了很多客户的信任和选择，并落地到各自的实际生产环境，对接了多种场景。后续会继续加强在 DeltaLake 的投入，深度发掘和 DLF 的集成，丰富湖表运维管理能力，降低用户入湖成本；持续优化读写性能，完善与阿里云大数据体系的生态建设，推进客户湖仓一体架构的建设。欢迎钉钉扫码加入数据湖交流群一起参与讨论~
-
发表了文章 2022-05-06
技术揭秘 | 阿里云EMR StarRocks 线上发布会预约开启！
阿里云EMR-StarRocks 是 StarRocks 授权阿里云的一款新一代开源OLAP产品，致力于构建极速统一分析体验，满足企业用户的多种数据分析场景。本次发布会邀请到了来自阿里云、StarRocks、众安保险的产品技术专家，详细介绍 EMR StarRocks 的功能优势、应用场景以及落地实践，揭秘 StarRocks 极速数据湖分析能力背后的技术支撑和未来规划。点击【 EMR StarRocks 发布会】立即预约发布会信息：直播时间：2022年5月11日 14:00-15:30直播地址：https://yqh.aliyun.com/live/emr-starrocks2022发布会亮点：大咖云集：来自阿里云、StarRocks、众安保险的5位产品技术专家齐聚，在线畅聊实时OLAP 场景，以及新一代开源OLAP产品 EMR StarRocks 的功能优势、技术场景、落地实践。技术揭秘：StarRocks 作为新一代极速全场景MPP分析型数据库，在技术层面实现了亚秒级查询分析、点查询场景高并发低延迟、优异的复杂BI分析性能等等。作为国内第一家上架 StarRocks 产品的云厂商，阿里云如何理解和定义这个产品？它具备什么样的能力和功能？又有哪些适用场景？ 本次直播将为您一一揭晓，揭开 StarRocks 极速数据湖分析能力背后的技术内幕！直播福利：更有产品试用，产品资料下载等您来体验，5月11日锁定直播，精彩不容错过！ 产品专享试用：https://survey.aliyun.com/apps/zhiliao/Yns9d9Xxz发布会议程：欢迎钉钉扫描海报二维码，加入产品交流群一起参与讨论。我们会在钉钉群定期推送精彩文章，邀请技术大牛直播分享~合作伙伴
-
发表了文章 2022-04-21
阿里云RemoteShuffleService 新功能：AQE 和流控
阿里云RemoteShuffleService 新功能：AQE 和流控阿里云EMR 自2020年推出 Remote Shuffle Service(RSS) 以来，帮助了诸多客户解决 Spark 作业的性能、稳定性问题，并使得存算分离架构得以实施。为了更方便大家使用和扩展，RSS 在2022年初开源(https://github.com/alibaba/RemoteShuffleService)，欢迎各路开发者共建: ) RSS的整体架构请参考[1]，本文将介绍 RSS 最新的两个重要功能：支持 Adaptive Query Execution(AQE)，以及流控。RSS 支持 AQEAQE 简介自适应执行(Adaptive Query Execution， AQE)是 Spark3 的重要功能[2]，通过收集运行时 Stats，来动态调整后续的执行计划，从而解决由于 Optimizer 无法准确预估 Stats导致生成的执行计划不够好的问题。AQE 主要有三个优化场景: Partition 合并(Partition Coalescing), Join 策略切换(Switch Join Strategy)，以及倾斜 Join 优化(Optimize Skew Join)。这三个场景都对 Shuffle 框架的能力提出了新的需求。Partition 合并Partition 合并的目的是尽量让 reducer 处理的数据量适中且均匀，做法是首先 Mapper按较多的 Partition 数目进行 Shuffle Write，AQE 框架统计每个 Partition 的 Size，若连续多个 Partition 的数据量都比较小，则将这些 Partition 合并成一个，交由一个 Reducer 去处理。过程如下所示。由上图可知，优化后的 Reducer2 需读取原属于 Reducer2-4 的数据，对 Shuffle 框架的需求是 ShuffleReader 需要支持范围 Partition:def getReader[K, C]( handle: ShuffleHandle, startPartition: Int, endPartition: Int, context: TaskContext): ShuffleReader[K, C]Join 策略切换Join 策略切换的目的是修正由于 Stats 预估不准导致 Optimizer 把本应做的 Broadcast Join 错误的选择了 SortMerge Join 或 ShuffleHash Join。具体而言，在 Join 的两张表做完 Shuffle Write 之后，AQE 框架统计了实际大小，若发现小表符合 Broadcast Join 的条件，则将小表 Broadcast 出去，跟大表的本地 Shuffle 数据做 Join。流程如下：Join 策略切换有两个优化：1. 改写成 Broadcast Join; 2. 大表的数据通过LocalShuffleReader 直读本地。其中第2点对 Shuffle 框架提的新需求是支持 Local Read。倾斜Join优化倾斜Join优化的目的是让倾斜的 Partition 由更多的 Reducer 去处理，从而避免长尾。具体而言，在 Shuffle Write 结束之后，AQE 框架统计每个 Partition 的 Size，接着根据特定规则判断是否存在倾斜，若存在，则把该 Partition 分裂成多个 Split，每个 Split 跟另外一张表的对应 Partition 做 Join。如下所示。Partiton 分裂的做法是按照 MapId 的顺序累加他们 Shuffle Output 的 Size，累加值超过阈值时触发分裂。对 Shuffle 框架的新需求是 ShuffleReader 要能支持范围 MapId。综合 Partition 合并优化对范围 Partition 的需求，ShuffleReader 的接口演化为:def getReader[K, C]( handle: ShuffleHandle, startMapIndex: Int, endMapIndex: Int, startPartition: Int, endPartition: Int, context: TaskContext, metrics: ShuffleReadMetricsReporter): ShuffleReader[K, C]RSS 架构回顾RSS 的核心设计是 Push Shuffle + Partition 数据聚合，即不同的 Mapper 把属于同一个 Partition 的数据推给同一个 Worker 做聚合，Reducer 直读聚合后的文件。如下图所示。在核心设计之外，RSS 还实现了多副本，全链路容错，Master HA，磁盘容错，自适应Pusher，滚动升级等特性，详见[1]。RSS 支持 Partition 合并Partition 合并对 Shuffle 框架的需求是支持范围 Partition，在 RSS 中每个 Partition 对应着一个文件，因此天然支持，如下图所示。RSS 支持 Join 策略切换Join 策略切换对 Shuffle 框架的需求是能够支持 LocalShuffleReader。由于 RSS 的 Remote 属性，数据存放在 RSS 集群，仅当 RSS 和计算集群混部的场景下才会存在在本地，因此暂不支持 Local Read(将来会优化混部场景并加以支持)。需要注意的是，尽管不支持 Local Read，但并不影响 Join 的改写，RSS 支持 Join 改写优化如下图所示。RSS 支持 Join 倾斜优化在 AQE 的三个场景中，RSS 支持 Join 倾斜优化是最为困难的一点。RSS 的核心设计是 Partition 数据聚合，目的是把 Shuffle Read 的随机读转变为顺序读，从而提升性能和稳定性。多个 Mapper 同时推送给 RSS Worker，RSS 在内存聚合后刷盘，因此 Partition 文件中来自不同 Mapper 的数据是无序的，如下图所示。Join 倾斜优化需要读取范围 Map，例如读 Map1-2的数据，常规的做法有两种：读取完整文件，并丢弃范围之外的数据。引入索引文件，记录每个 Block 的位置及所属 MapId，仅读取范围内的数据。这两种做法的问题显而易见。方法1会导致大量冗余的磁盘读；方法2本质上回退成了随机读，丧失了 RSS 最核心的优势，并且创建索引文件成为通用的 Overhead，即使是针对非倾斜的数据( Shuffle Write 过程中难以准确预测是否存在倾斜)。为了解决以上两个问题，我们提出了新的设计：主动 Split + Sort On Read。主动Split倾斜的 Partition 大概率 Size 非常大，极端情况会直接打爆磁盘，即使在非倾斜场景出现大 Partition 的几率依然不小。因此，从磁盘负载均衡的角度，监控 Partition 文件的 Size 并做主动 Split (默认阈值256m)是非常必要的。Split 发生时，RSS 会为当前 Partition 重新分配一对 Worker(主副本)，后续数据将推给新的 Worker。为了避免 Split 对正在运行的 Mapper 产生影响，我们提出了 Soft Split 的方法，即当触发 Split 时，RSS 异步去准备新的 Worker，Ready 之后去热更新 Mapper 的 PartitionLocation 信息，因此不会对 Mapper 的 PushData 产生任何干扰。整体流程如下图所示。Sort On Read为了避免随机读的问题，RSS 采用了 Sort On Read 的策略。具体而言，File Split 的首次 Range 读会触发排序(非 Range 读不会触发)，排好序的文件连同其位置索引写回磁盘。后续的 Range 读即可保证是顺序读取。如下图所示。为了避免多个 Sub-Reducer 等待同一个 File Split 的排序，我们打散了各个 Sub-Reducer 读取 Split 的顺序，如下图所示。Sort 优化Sort On Read 可以有效避免冗余读和随机读，但需要对 Split File(256m)做排序，本节讨论排序的实现及开销。文件排序包括3个步骤：读文件，对 MapId 做排序，写文件。RSS 的 Block 默认256k，Block 的数量大概是1000，因此排序的过程非常快，主要开销在文件读写。整个排序过程大致有三种方案：预先分配文件大小的内存，文件整体读入，解析并排序 MapId，按 MapId 顺序把 Block 写回磁盘。不分配内存，Seek 到每个 Block 的位置，解析并排序 MapId，按 MapId 顺序把原文件的 Block transferTo 新文件。分配小块内存(如256k)，顺序读完整个文件并解析和排序MapId，按MapId顺序把原文件的Block transferTo新文件。从 IO 的视角，乍看之下，方案1通过使用足量内存，不存在顺序读写；方案2存在随机读和随机写；方案3存在随机写；直观上方案1性能更好。然而，由于 PageCache 的存在，方案3在写文件时原文件大概率缓存在 PageCache 中，因此实测下来方案3的性能更好，如下图所示。同时方案3无需占用进程额外内存，故 RSS 采用方案3的算法。我们同时还测试了 Sort On Read 跟上述的不排序、仅做索引的随机读方法的对比，如下图所示。整体流程RSS 支持 Join 倾斜优化的整体流程如下图所示。RSS流控流控的主要目的是防止 RSS Worker 内存被打爆。流控通常有两种方式：Client 在每次 PushData 前先向 Worker 预留内存，预留成功才触发 Push。Worker 端反压。由于 PushData 是非常高频且性能关键的操作，若每次推送都额外进行一次 RPC 交互，则开销太大，因此我们采用了反压的策略。以 Worker 的视角，流入数据有两个源：Client 推送的数据主副本发送的数据如下图所示，Worker2 既接收来自 Mapper 推送的 Partition3 的数据，也接收 Worker1发送的 Partition1 的副本数据，同时会把 Partition3 的数据发给对应的从副本。其中，来自 Mapper 推送的数据，当且仅当同时满足以下条件时才会释放内存：Replication 执行成功数据写盘成功来自主副本推送的数据，当且仅当满足以下条件时才会释放内存：数据写盘成功我们在设计流控策略时，不仅要考虑限流(降低流入的数据)，更要考虑泄流(内存能及时释放)。具体而言，高水位我们定义了两档内存阈值(分别对应85%和95%内存使用)，低水位只有一档(50%内存使用)。达到高水位一档阈值时，触发流控，暂停接收 Mapper 推送的数据，同时强制刷盘，从而达到泄流的目标。仅限制来自 Mapper 的流入并不能控制来自主副本的流量，因此我们定义了高水位第二档，达到此阈值时将同时暂停接收主副本发送的数据。当水位低于低水位后，恢复正常状态。整体流程如下图所示。性能测试我们对比了 RSS 和原生的 External Shufle Service(ESS) 在 Spark3.2.0 开启 AQE 的性能。RSS 采用混部的方式，没有额外占用任何机器资源。此外，RSS 所使用的内存为8g，仅占机器内存的2.3%(机器内存352g)。具体环境如下。测试环境硬件：header 机器组 1x ecs.g5.4xlargeworker 机器组 8x ecs.d2c.24xlarge，96 CPU，352 GB，12x 3700GB HDD。Spark AQE 相关配置:spark.sql.adaptive.enabled true spark.sql.adaptive.coalescePartitions.enabled true spark.sql.adaptive.coalescePartitions.initialPartitionNum 1000 spark.sql.adaptive.skewJoin.enabled true spark.sql.adaptive.localShuffleReader.enabled falseRSS 相关配置:RSS_MASTER_MEMORY=2g RSS_WORKER_MEMORY=1g RSS_WORKER_OFFHEAP_MEMORY=7gTPCDS 10T测试集我们测试了10T的 TPCDS，E2E 来看，ESS 耗时11734s，RSS 单副本/两副本分别耗时8971s/10110s，分别比 ESS 快了23.5%/13.8%，如下图所示。我们观察到 RSS 开启两副本时网络带宽达到上限，这也是两副本比单副本低的主要因素。具体每个 Query 的时间对比如下:相关链接欢迎各位开发者参与讨论和共建！github地址：https://github.com/alibaba/RemoteShuffleService钉钉群：微信群：Reference[1]阿里云EMR Remote Shuffle Service 在小米的实践，以及开源. https://developer.aliyun.com/article/857757[2]Adaptive Query Execution: Speeding Up Spark SQL at Runtime. https://databricks.com/blog/2020/05/29/adaptive-query-execution-speeding-up-spark-sql-at-runtime.html
-
发表了文章 2022-04-15
阿里云发布中国云原生数据湖应用洞察白皮书
在数字经济的背景下，互联网行业及传统企业加速云化转型，中国整体云服务市场的规模逐年扩增，云成为新一代IT基础设施已经成为不争的事实。其中，企业云化转型的深入以及用云思维的转变，驱动了PaaS市场份额的增长，基于云的能力创新已成为基础云发展新的增长引擎。云特有的“池化、弹性、成本、敏捷”等优势让数据层与应用层的很多设想得以实现，拥抱云原生成为数据湖乃至大数据的必然选择。白皮书核心摘要：概念界定：数据湖是面向大数据场景的创新解决方案，云原生是数据湖未来部署的必然形态，具有「建立统一数据资产、低成本使用基础资源、高性能计算体验升级和敏捷创新赋能」的核心价值。市场现状：2020年云原生数据湖市场规模（含生态）达124亿，预计未来三年将以39.7%的复合增长率快速扩张。竞争格局：中国云原生数据湖还处于发展的早期，能够提供整体解决方案的独立厂商还较少，市场较为集中，竞争主要围绕头部云厂商展开。应用现状：现阶段，云原生数据湖主要应用于泛互联网行业（40.7%）及传统行业的互联网场景（泛政务、金融、工业、医疗、汽车等），未来将向更多具有大数据和高价值属性的行业拓展。选型建议：企业在布局数字化转型时，面对多元且快速迭代的业务需求，一方面需建设统一的数据底座，另一方面需关注DT能力的开放性、敏捷性和创新性。在选型云原生数据湖时，除内部能力评估外，还需要考虑服务商的服务半径和发展路径。趋势展望：在云原生与大数据背景下，云原生数据湖成为企业智胜未来的新一代生产力工具，市场即将迎来爆发期。未来，云原生数据湖厂商需与开发者、ISV和SI共同努力，在企业级生产环境中不断探索，生态共赢驱动云原生数据湖解决方案日臻完善。
-
发表了文章 2022-03-22
EMR StarRocks 测试指南
日前，阿里云 E-MapReduce 与 StarRocks 社区合作，推出了首款 StarRocks 云上产品。同时，面向新老用户提供了99元指定机型（ecs.c6.xlarge）首月试用的优惠活动，欢迎感兴趣的用户前来测试。一、申请云服务器代金券第一步：点击填写 阿里云EMR StarRocks 99元测试申请表，申请云服务器代金券 https://survey.aliyun.com/apps/zhiliao/Yns9d9Xxz第二步：等待工作人员审核，发放代金券注意：代金券有效期为一个月，请在下发后尽快开始测试二、创建 EMR StarRocks 集群登录 EMR新版控制台，开始测试https://emr-next.console.aliyun.com/前提条件已在目标地域创建一个专有网络和交换机，详情请参见创建和管理专有网络和创建交换机。使用限制目前仅EMR-3.x系列的版本支持StarRocks，所以产品版本须选择EMR-3.x系列的最新版本（例如EMR-3.39.1）。操作步骤进入创建集群页面。登录EMR on ECS控制台。可选：在顶部菜单栏处，根据实际情况选择地域和资源组。地域：创建的集群将会在对应的地域内，一旦创建不能修改。资源组：默认显示账号全部资源。单击上方的创建集群，进行创建。配置集群信息。 创建集群时，您需要对集群进行软件配置、硬件配置和基础配置。i. 软件配置地域--创建的集群将会在对应的地域内，一旦创建不能修改。业务场景--选择数据分析场景产品版本--需要选择EMR-3.x系列版本服务高可用--关闭可选服务--StarRocks高级设置--不开启ii. 硬件配置付费类型--包年包月付费时长--1个月可用区--可用区为在同一地域下的不同物理区域，可用区之间内网互通。通常使用默认的可用区即可。专有网络--默认选择已有的专有网络。如需创建新的专有网络，请在专有网络控制台新创建一个，详情请参见创建和管理专有网络。交换机--选择在对应VPC下可用区的交换机，如果在这个可用区没有可用的交换机，则需要在专有网络控制台新创建一个，详情请参见创建交换机。安全组--默认选择已有的安全组。安全组详情请参见安全组概述。您也可以单击新建安全组，在ECS控制台新建一个安全组，详情请参见创建安全组。 注意 禁止使用ECS上创建的企业安全组。挂载公网--开启实例--Master、Core 各一台，ecs.c6.xlargeiii. 基础配置 在基础信息区域，配置如下参数。 注意 暂不支持高级配置区域的参数，因此请勿设置。确认配置，选中E-MapReduce服务条款复选框，确认订单。支付99元，开始创建集群。创建集群后可以通过刷新页面来查看进度，当集群状态显示为运行中时，表示集群创建成功。三、快速使用 StarRocks快速使用 EMR StarRocks，详见 https://help.aliyun.com/document_detail/411288.html四、测试答疑测试过程中有任何疑问，欢迎钉钉扫码加入用户交流群咨询~
-
发表了文章 2022-03-14
Delta Lake基础介绍（开源版）【Databricks 数据洞察公开课】
作者：王晓龙（筱龙），阿里云开源大数据平台技术专家一、Delta Lake背景回顾1. 大数据平台架构演进大数据平台经历了三种架构的演进：a.第一代：数仓架构支持的场景有限，不适用于高阶复杂的查询分析场景，比如data science和ML场景；scale-out扩展能力差。b.第二代：数据湖+数仓架构可支持多场景应用；多轮ETL，增加了延迟和出错概率，缺乏数据可靠性；支持的workload依然有限；数据冗余带来的存储开销更大。c.第三代：Lakehouse 架构支持所有结构的数据类型同时，也能针对各种分析场景提供支持；中间的元数据管理层尤为重要，它提供可靠的ACID事务，同时可以针对数据库操作提供性能优化。2. Delta Lake - 运行在数据湖之上的可靠存储层Delta Lake作为可靠的数据存储中间层，为构建Lakehouse提供了核心支撑。3. Delta Lake核心特性Delta Lake的核心特性是对ACID事务支持，并且基于事务日志机制，实现可串行化的隔离级别，提供ACID事务，保证读写数据的一致性。Delta Lake 围绕 ACID 底层事务日志，提供了以下能力：时间回溯；可扩展元数据处理；Upserts；Schema约束及演化；缓存及索引优化；数据布局优化；批流一体。二、详解事务日志及ACID事务实现机制1. 示例：Delta Lake表操作首先通过一个示例，来简单了解Delta Lake的基本语法。使用PySpark创建 Delta Lake表，并执行表读写操作。示例版本：PySpark 3.2.1Delta Lake 1.1.0a.Delta Lake Starter - 启动 PySpark启动PySpark并加载 Delta相关依赖：# Using Spark Packages ./bin/pyspark --packages io.delta:delta-core_2.12:1.1.0 --conf "spark.databricks.delta.retentionDurationCheck.enabled=false" --conf "spark.sql.extensions=io.delta.sql.DeltaSparkSessionExtension"b.Delta Lake Starter - DML准备创建表并执行若干 Update/Delete/Merge操作。通过PySpark Datafram API创建一张Delta 表，表的名称是random_num，表中只包含一列数字：>>> data = spark.range(0, 5) >>> data.write.format("delta").save("/tmp/delta_course/delta_table") >>> spark.sql("CREATE TABLE random_num USING DELTA location \"{}\"”.format('/tmp/delta_course/delta_table')接下来往表中执行几条简单的修改操作语句：>>> spark.sql("insert into random_num values(5)").show() >>> spark.sql("update random_num set id = '10' where id = 1").show() >>> spark.sql("delete from random_num where id = 3 ").show()c.Delta Lake文件系统目录结构Delta Lake 表的物理存储目录下, 既包括自身的表数据文件,也包括记录表Schema及表变化的 Delta Logs:Delta数据文件：Parquet文件；Delta事务日志 _delta_log：包含 Meta Data 以及事务操作历史；2. Transaction Log概念Transaction Log（事务日志，也称 Delta Log）是一种有序记录集，顺序记录了Delta Lake表从初始创建以来的所有事务操作。3. Transaction Log设计目标a.Transaction Log的整体设计目标,是实现单一信息源（Single Source of Truth），通过跟踪记录用户所有的表操作，从而为用户提供在任意时刻准确的数据视图。b.同时，因为Delta Lake是基于Apache Spark构建的，依托Spark来管理维护事务日志，所以相比通过Metastore使用单一的数据库管理元数据，Delta Lake具备高可扩展的元数据处理能力，能够支持上百PB的Delta表读写访问。c.除此之外，Delta Lake的事务日志也是其它重要数据管理特性实现的基础，比如数据版本回溯（Time Travel）等。4. Transaction Log实现机制a.Commit在Delta Lake中，Transaction被称为Commit。每个Commit代表一个事务操作，同时也代表了一个数据版本，对应_delta_log目录下的一个json文件。示例：一条Update语句关联的Commit内容>>> spark.sql("update random_num set id = '10' where id = 1").show()上图中的Update语句关联的事务日志中，会包含诸如remove/add这样的动作，后面包含了文件的路径，从路径看都是delta 表的parquet数据文件。事务日志的最后一行是关于commit的详细信息，包括了时间戳、操作名等元数据。在每个Commit里都包含若干更细粒度的动作（Action）。Delta Lake 当前定义的 Action 动作包括：涉及数据文件增加和删除（Add file/Remove file）、元数据更新语义（Update metadata）、事务及协议相关的变更操作（Set transaction、Change protocol）等。通过Spark获取到表的最新状态Delta Lake定义的Commit维护的是变更操作的过程记录，当针对Delta表执行查询语句时，可以通过Spark获取到表的最新状态。Spark会对事务日志做聚合，检查事务日志经历了哪些事务操作，并基于事务日志构建出可靠准确的Delta表状态。小文件问题在变更操作较多的场景，比如CDC，delta log下会生成大量json小文件，对处理性能会造成较大影响。b.Checkpoint为了解决上文提到的小文件问题，Delta Log引入Checkpoint机制。Checkpoints：保存了从 version 0开始到当前时刻所有变更记录（默认每 10 次 Commit创建一个Checkpoint文件）。Checkpoint文件给 Spark 提供了一种捷径来重构表状态，避免低效地处理可能上千条的json格式的小文件。示例：查看checkpoint文件内容>>> chkpt0 = spark.read.parquet( "/tmp/delta_course/delta_table/_delta_log/00000000000000000010.checkpoint.parquet") >>> chkpt0.select("*").show()图中包括从第一版本至今所有变更的历史借助checkpoint，Spark可以快速构建表的状态。Spark通过执行ListFrom 操作，查看所有事务日志文件，快速跳转到最新的checkpoint文件，因此只需处理checkpoint之后的commits即可。示例：ListForm的实现在这个示例中，假设Spark里维护了版本7时刻下表的状态。在版本7之后，Delta表又有若干次的提交。当要查看表的最新状态时，Spark 首先通过ListFrom接口获取版本7之后的所有变更文件，发现版本号10关联的checkpoint文件是最新的checkpoint , Spark只需要基于版本10及随后的11和12两次commit构建表的状态，从而大大提升了元数据操作的性能。因此，借助事物日志及spark，Delta Lake真正实现可扩展的元数据处理支持。c.乐观并发控制并发控制主要解决 ACID 中多个并发事务间的隔离性（Isolation）问题， 即：多个事务同一时间触发，系统应该如何决定事务之间的顺序。在传统数据库领域，有两种典型的实现机制：乐观并发控制和悲观并发控制。乐观并发控制 vs 悲观并发控制悲观并发控制（Pressimistic Concurrency Control，简称PCC），即用锁串行化执行事务；乐观并发控制（Optimistic Concurrency Control，简称OCC），即在只有当冲突发生的时候才采取措施；传统数据库的锁机制其实都是基于悲观并发控制的观点进行实现的；对比悲观并发控制，乐观并发控制可以提供更好的性能；由于大数据场景本身是典型的读多写少场景，因此更适合采用乐观并发控制方式。Delta Lake的设计者们选择了乐观并发控制，并且在发生冲突时采用排他锁实现。排他锁Delta Lake处理并发事务场景下的冲突问题时使用排他锁，包括以下五个步骤：Record the starting table version.Record reads/writes.Attempt a commit.If someone else wins, check whether anything you read has changed.Repeat.示例：并发写入事务示例 - 演示OCC协议实现方式示例中，用户A和用户B都拿到版本号为0的commit，排他锁（mutual exclusion）决定了只能有一个用户能够创建版本号为1的commit，假设接受了User A的commit，就要拒绝User B。Delta Lake为了更好的处理User B的commit，采取了乐观并发控制处理方式，基于操作语义，在版本1基础上完成User B的写入。5. Delta Lake ACID事务实现ACID事务具有四个特性：原子性、一致性、隔离性和持久性。a.原子性 Atomicity如上文介绍，Transaction Log将事务抽象成一个个Commit（文件），Commits里可以包含不同类型的Action，但是每个 Commit 是原子的。Martin Kleppman在DDIA书中对原子性的定义：“ACID atomicity describes what happens if a client wants to make several writes, but a fault occurs after some of the writes have been processed. If the writes are grouped together into an atomic transaction, and the transaction cannot be completed (committed) due to a fault, then the transaction is aborted and the database must discard or undo any writes it has made so far in that transaction. ” —— Martin Kleppmann - Designing Data-Intensive Applicationsb.隔离性 Isolation隔离性是针对并发事务的处理方式，并发事务不应该相互干扰。在Delta Lake中，隔离性是通过OCC+排他锁方式实现的，并且实现了读写的串行化。Martin Kleppman在DDIA书中对隔离性的定义：“Isolation in the sense of ACID means that concurrently executing transactions are isolated from each other: they cannot step on each other’s toes.”c.持久性 DurabilityTransaction Log写入分布式磁盘中，在事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。Martin Kleppman在DDIA书中对持久性的定义“Durability is the promise that once a transaction has committed successfully, any data it has written will not be forgotten, even if there is a hardware fault or the database crashes.”d.一致性 Consistency从Martin Kleppman在DDIA书中对一致性的定义可以看出，原子性、隔离性和持久性是数据库的属性，应用程序可能依赖数据库的原子性和隔离属性来实现一致性，但这并不取决于数据库本身，但一致性是由应用来决定的。Martin Kleppman在DDIA书中对一致性的定义“Atomicity, isolation, and durability are properties of the database, whereas consistency (in the ACID sense) is a property of the application. The application may rely on the database’s atomicity and isolation properties in order to achieve consistency, but it’s not up to the database alone. Thus, the letter C doesn’t really belong in ACID”三、Delta Lake核心特征总结如上文介绍，Delta Lake基于事务日志，具有能够实现Time Travel/Upserts以及支持可扩展的元数据处理等特性。除此之外，像Schema约束及演化等特性，在社区版本的Delta Lake里也都做了支持。在后面的公开课中还会针对基于Delta Lake构建批流一体Lake house架构做分享。除了社区版本的Detla Lake, Databricks商业版提供了商业版的Spark及 Delta Lake引擎，并有一些专有的企业级性能优化特性。下期Delta Lake公开课我们会介绍商业版 Delta Lake 的特性，敬请关注。参考资料Delta Lake Introduction： https://docs.delta.io/latest/delta-intro.htmlDiving Into Delta Lake: DML Internals (Update, Delete, Merge) ：https://databricks.com/blog/2020/09/29/diving-into-delta-lake-dml-internals-update-delete-merge.htmlDiving Into Delta Lake: Unpacking The Transaction Log： https://databricks.com/blog/2019/08/21/diving-into-delta-lake-unpacking-the-transaction-log.htmlDelta Transaction Log Protocol： https://github.com/delta-io/delta/blob/master/PROTOCOL.mdDelta Lake: The Definitive Guide by O’Reilly： https://databricks.com/p/ebook/delta-lake-the-definitive-guide-by-oreilly产品技术咨询https://survey.aliyun.com/apps/zhiliao/VArMPrZOR加入技术交流群
-
发表了文章 2022-03-09
EMR StarRocks 极速数据湖分析原理解析
StarRocks 是一个强大的数据分析系统，主要宗旨是为用户提供极速、统一并且易用的数据分析能力，以帮助用户通过更小的使用成本来更快的洞察数据的价值。通过精简的架构、高效的向量化引擎以及全新设计的基于成本的优化器（CBO），StarRocks 的分析性能（尤其是多表 JOIN 查询）得以远超同类产品。 为了能够满足更多用户对于极速分析数据的需求，同时让 StarRocks 强大的分析能力应用在更加广泛的数据集上，阿里云开源大数据 OLAP 团队联合社区一起增强 StarRocks的数据湖分析能力。使其不仅能够分析存储在 StarRocks 本地的数据，还能够以同样出色的表现分析存储在 Apache Hive、Apache Iceberg 和 Apache Hudi 等开源数据湖或数据仓库的数据。 本文将重点介绍 StarRocks 极速数据湖分析能力背后的技术内幕，性能表现以及未来的规划。 一、整体架构 在数据湖分析的场景中，StarRocks 主要负责数据的计算分析，而数据湖则主要负责数据的存储、组织和维护。上图描绘了由 StarRocks 和数据湖所构成的完成的技术栈。 StarRocks 的架构非常简洁，整个系统的核心只有 FE（Frontend）、BE（Backend）两类进程，不依赖任何外部组件，方便部署与维护。其中 FE 主要负责解析查询语句（SQL），优化查询以及查询的调度，而 BE 则主要负责从数据湖中读取数据，并完成一系列的 Filter 和 Aggregate 等操作。 数据湖本身是一类技术概念的集合，常见的数据湖通常包含 Table Format、File Format 和 Storage 三大模块。其中 Table Format 是数据湖的“UI”，其主要作用是组织结构化、半结构化，甚至是非结构化的数据，使其得以存储在像 HDFS 这样的分布式文件系统或者像 OSS 和 S3 这样的对象存储中，并且对外暴露表结构的相关语义。Table Format 包含两大流派，一种是将元数据组织成一系列文件，并同实际数据一同存储在分布式文件系统或对象存储中，例如 Apache Iceberg、Apache Hudi 和 Delta Lake 都属于这种方式；还有一种是使用定制的 metadata service 来单独存放元数据，例如 StarRocks 本地表，Snowflake 和 Apache Hive 都是这种方式。 File Format 的主要作用是给数据单元提供一种便于高效检索和高效压缩的表达方式，目前常见的开源文件格式有列式的 Apache Parquet 和 Apache ORC，行式的 Apache Avro 等。 Storage 是数据湖存储数据的模块，目前数据湖最常使用的 Storage 主要是分布式文件系统 HDFS，对象存储 OSS 和 S3 等。FE FE 的主要作用将 SQL 语句转换成 BE 能够认识的 Fragment，如果把 BE 集群当成一个分布式的线程池的话，那么 Fragment 就是线程池中的 Task。从 SQL 文本到分布式物理执行计划，FE 的主要工作需要经过以下几个步骤: SQL Parse： 将 SQL 文本转换成一个 AST(抽象语法树) SQL Analyze：基于 AST 进行语法和语义分析 SQL Logical Plan： 将 AST 转换成逻辑计划 SQL Optimize：基于关系代数，统计信息，Cost 模型对 逻辑计划进行重写，转换，选择出 Cost “最低” 的物理执行计划 生成 Plan Fragment：将 Optimizer 选择的物理执行计划转换为 BE 可以直接执行的 Plan Fragment。 执行计划的调度 BEBackend 是 StarRocks 的后端节点，负责数据存储以及 SQL 计算执行等工作。StarRocks 的 BE 节点都是完全对等的，FE 按照一定策略将数据分配到对应的 BE 节点。在数据导入时，数据会直接写入到 BE 节点，不会通过FE中转，BE 负责将导入数据写成对应的格式以及生成相关索引。在执行 SQL 计算时，一条 SQL 语句首先会按照具体的语义规划成逻辑执行单元，然后再按照数据的分布情况拆分成具体的物理执行单元。物理执行单元会在数据存储的节点上进行执行，这样可以避免数据的传输与拷贝，从而能够得到极致的查询性能。 二、技术细节 StarRocks 为什么这么快 CBO 优化器 一般 SQL 越复杂，Join 的表越多，数据量越大，查询优化器的意义就越大，因为不同执行方式的性能差别可能有成百上千倍。StarRocks 优化器主要基于 Cascades 和 ORCA 论文实现，并结合 StarRocks 执行器和调度器进行了深度定制，优化和创新。完整支持了 TPC-DS 99 条 SQL，实现了公共表达式复用，相关子查询重写，Lateral Join， CTE 复用，Join Rorder，Join 分布式执行策略选择，Runtime Filter 下推，低基数字典优化 等重要功能和优化。 CBO 优化器好坏的关键之一是 Cost 估计是否准确，而 Cost 估计是否准确的关键点之一是统计信息是否收集及时，准确。 StarRocks 目前支持表级别和列级别的统计信息，支持自动收集和手动收集两种方式，无论自动还是手动，都支持全量和抽样收集两种方式。 MPP 执行 MPP (massively parallel processing) 是大规模并行计算的简称，核心做法是将查询 Plan 拆分成很多可以在单个节点上执行的计算实例，然后多个节点并行执行。 每个节点不共享 CPU，内存, 磁盘资源。MPP 数据库的查询性能可以随着集群的水平扩展而不断提升。如上图所示，StarRocks 会将一个查询在逻辑上切分为多个 Query Fragment(查询片段)，每个 Query Fragment 可以有一个或者多个 Fragment 执行实例，每个Fragment 执行实例 会被调度到集群某个 BE 上执行。 如上图所示，一个 Fragment 可以包括 一个 或者多个 Operator（执行算子），图中的 Fragment 包括了 Scan, Filter, Aggregate。如上图所示，每个 Fragment 可以有不同的并行度。 如上图所示，多个 Fragment 之间会以 Pipeline 的方式在内存中并行执行，而不是像批处理引擎那样 Stage By Stage 执行。 如上图所示，Shuffle （数据重分布）操作是 MPP 数据库查询性能可以随着集群的水平扩展而不断提升的关键，也是实现高基数聚合和大表 Join 的关键。 向量化执行引擎 随着数据库执行的瓶颈逐渐从 IO 转移到 CPU，为了充分发挥 CPU 的执行性能，StarRocks 基于向量化技术重新实现了整个执行引擎。 算子和表达式向量化执行的核心是批量按列执行，批量执行，相比与单行执行，可以有更少的虚函数调用，更少的分支判断；按列执行，相比于按行执行，对 CPU Cache 更友好，更易于 SIMD 优化。 向量化执行不仅仅是数据库所有算子的向量化和表达式的向量化，而是一项巨大和复杂的性能优化工程，包括数据在磁盘，内存，网络中的按列组织，数据结构和算法的重新设计，内存管理的重新设计，SIMD 指令优化，CPU Cache 优化，C++优化等。向量化执行相比之前的按行执行，整体性能提升了5到10倍。 StarRocks 如何优化数据湖分析 大数据分析领域，数据除了存储在数仓之外，也会存储在数据湖当中，传统的数据湖实现方案包括 Hive/HDFS。近几年比较火热的是 LakeHouse 概念，常见的实现方案包括 Iceberg/Hudi/Delta。那么 StarRocks 能否帮助用户更好地挖掘数据湖中的数据价值呢？答案是肯定的。 在前面的内容中我们介绍了 StarRocks 如何实现极速分析，如果将这些能力用于数据湖肯定会带来更好地数据湖分析体验。在这部分内容中，我们会介绍 StarRocks 是如何实现极速数据湖分析的。 我们先看一下全局的架构，StarRocks 和数据湖分析相关的主要几个模块如下图所示。其中 Data Management 由数据湖提供，Data Storage 由对象存储 OSS/S3，或者是分布式文件系统 HDFS 提供。 目前，StarRocks 已经支持的数据湖分析能力可以归纳为下面几个部分： 支持 Iceberg v1 表查询 https://github.com/StarRocks/starrocks/issues/1030 支持 Hive 外表查询 外部表 @ External_table @ StarRocks Docs (dorisdb.com)支持 Hudi COW 表查询 https://github.com/StarRocks/starrocks/issues/2772 接下来我们从查询优化和查询执行这几个方面来看一下，StarRocks 是如何实现将极速分析的能力赋予数据湖的。 查询优化 查询优化这部分主要是利用前面介绍的 CBO 优化器来实现，数据湖模块需要给优化器统计信息。基于这些统计信息，优化器会利用一系列策略来实现查询执行计划的最优化。接下来我们通过例子看一下几个常见的策略。 统计信息 我们看下面这个例子，生成的执行计划中，HdfsScanNode 包含了 cardunality、avgRowSize 等统计信息的展示。MySQL [hive_test]> explain select l_quantity from lineitem; +-----------------------------+ | Explain String | +-----------------------------+ | PLAN FRAGMENT 0 | | OUTPUT EXPRS:5: l_quantity | | PARTITION: UNPARTITIONED | | | | RESULT SINK | | | | 1:EXCHANGE | | | | PLAN FRAGMENT 1 | | OUTPUT EXPRS: | | PARTITION: RANDOM | | | | STREAM DATA SINK | | EXCHANGE ID: 01 | | UNPARTITIONED | | | | 0:HdfsScanNode | | TABLE: lineitem | | partitions=1/1 | | cardinality=126059930 | | avgRowSize=8.0 | | numNodes=0 | +-----------------------------+ 在正式进入到 CBO 优化器之前，这些统计信息都会计算好。比如针对 Hive 我们有 MetaData Cache 来缓存这些信息，针对 Iceberg 我们通过 Iceberg 的 manifest 信息来计算这些统计信息。获取到这些统计信息之后，对于后续的优化策略的效果有很大地提升。 分区裁剪 分区裁剪是只有当目标表为分区表时，才可以进行的一种优化方式。分区裁剪通过分析查询语句中的过滤条件，只选择可能满足条件的分区，不扫描匹配不上的分区，进而显著地减少计算的数据量。比如下面的例子，我们创建了一个以 ss_sold_date_sk 为分区列的外表。 create external table store_sales( ss_sold_time_sk bigint , ss_item_sk bigint , ss_customer_sk bigint , ss_coupon_amt decimal(7,2) , ss_net_paid decimal(7,2) , ss_net_paid_inc_tax decimal(7,2) , ss_net_profit decimal(7,2) , ss_sold_date_sk bigint ) ENGINE=HIVE PROPERTIES ( "resource" = "hive_tpcds", "database" = "tpcds", "table" = "store_sales" ); 在执行如下查询的时候，分区2451911和2451941之间的数据才会被读取，其他分区的数据会被过滤掉，这可以节约很大一部分的网络 IO 的消耗。 select ss_sold_time_sk from store_sales where ss_sold_date_sk between 2451911 and 2451941 order ss_sold_time_sk; Join Reorder 多个表的 Join 的查询效率和各个表参与 Join 的顺序有很大关系。如 select * from T0, T1, T2 where T0.a=T1.a and T2.a=T1.a，这个 SQL 中可能的执行顺序有下面两种情况： T0 和 T1 先做 Join，然后再和 T2 做 Join T1 和 T2 先做 Join，然后再和 T0 做 Join 根据 T0 和 T2 的数据量及数据分布，这两种执行顺序会有不同的性能表现。针对这个情况，StarRocks 在优化器中实现了基于 DP 和贪心的 Join Reorder 机制。目前针对 Hive的数据分析，已经支持了 Join Reorder，其他的数据源的支持也正在开发中。下面是一个例子： MySQL [hive_test]> explain select * from T0, T1, T2 where T2.str=T0.str and T1.str=T0.str; +----------------------------------------------+ | Explain String | +----------------------------------------------+ | PLAN FRAGMENT 0 | | OUTPUT EXPRS:1: str | 2: str | 3: str | | PARTITION: UNPARTITIONED | | RESULT SINK | | 8:EXCHANGE | | PLAN FRAGMENT 1 | | OUTPUT EXPRS: | | PARTITION: HASH_PARTITIONED: 2: str | | STREAM DATA SINK | | EXCHANGE ID: 08 | | UNPARTITIONED | | 7:HASH JOIN | | | join op: INNER JOIN (BUCKET_SHUFFLE(S)) | | | hash predicates: | | | colocate: false, reason: | | | equal join conjunct: 1: str = 3: str | | |----6:EXCHANGE | | 4:HASH JOIN | | | join op: INNER JOIN (PARTITIONED) | | | hash predicates: | | | colocate: false, reason: | | | equal join conjunct: 2: str = 1: str | | |----3:EXCHANGE | | 1:EXCHANGE | | PLAN FRAGMENT 2 | | OUTPUT EXPRS: | | PARTITION: RANDOM | | STREAM DATA SINK | | EXCHANGE ID: 06 | | HASH_PARTITIONED: 3: str | | 5:HdfsScanNode | | TABLE: T2 | | partitions=1/1 | | cardinality=1 | | avgRowSize=16.0 | | numNodes=0 | | PLAN FRAGMENT 3 | | OUTPUT EXPRS: | | PARTITION: RANDOM | | STREAM DATA SINK | | EXCHANGE ID: 03 | | HASH_PARTITIONED: 1: str | | 2:HdfsScanNode | | TABLE: T0 | | partitions=1/1 | | cardinality=1 | | avgRowSize=16.0 | | numNodes=0 | | PLAN FRAGMENT 4 | | OUTPUT EXPRS: | | PARTITION: RANDOM | | STREAM DATA SINK | | EXCHANGE ID: 01 | | HASH_PARTITIONED: 2: str | | 0:HdfsScanNode | | TABLE: T1 | | partitions=1/1 | | cardinality=1 | | avgRowSize=16.0 | | numNodes=0 | +----------------------------------------------+ 谓词下推 谓词下推将查询语句中的过滤表达式计算尽可能下推到距离数据源最近的地方，从而减少数据传输或计算的开销。针对数据湖场景，我们实现了将 Min/Max 等过滤条件下推到 Parquet 中，在读取 Parquet 文件的时候，能够快速地过滤掉不用的 Row Group。 比如，对于下面的查询，l_discount=1对应条件会下推到 Parquet 侧。 MySQL [hive_test]> explain select l_quantity from lineitem where l_discount=1; +----------------------------------------------------+ | Explain String | +----------------------------------------------------+ | PLAN FRAGMENT 0 | | OUTPUT EXPRS:5: l_quantity | | PARTITION: UNPARTITIONED | | | | RESULT SINK | | | | 2:EXCHANGE | | | | PLAN FRAGMENT 1 | | OUTPUT EXPRS: | | PARTITION: RANDOM | | | | STREAM DATA SINK | | EXCHANGE ID: 02 | | UNPARTITIONED | | | | 1:Project | | | <slot 5> : 5: l_quantity | | | | | 0:HdfsScanNode | | TABLE: lineitem | | NON-PARTITION PREDICATES: 7: l_discount = 1.0 | | partitions=1/1 | | cardinality=63029965 | | avgRowSize=16.0 | | numNodes=0 | +----------------------------------------------------+ 其他策略 除了上面介绍的几种策略，针对数据湖分析，我们还适配了如 Limit 下推、TopN 下推、子查询优化等策略。能够进一步地优化查询性能。 查询执行 前面介绍了，StarRocks 的执行引擎是全向量化、MPP 架构的，这些无疑都会给我们分析数据湖的数据带来很大提升。接下来我们看一下 StarRocks 是如何调度和执行数据湖分析查询的。 查询调度 数据湖的数据一般都存储在如 HDFS、OSS 上，考虑到混部和非混部的情况。我们对 Fragment 的调度，实现了一套负载均衡的算法。 做完分区裁剪之后，得到要查询的所有 HDFS 文件 block 对每个 block 构造 THdfsScanRange，其中 hosts 包含 block 所有副本所在的 datanode 地址，最终得到 List Coordinator 维护一个所有 be 当前已经分配的 scan range 数目的 map，每个 datanode 上磁盘已分配的要读取 block 的数目的 map>，及每个 be 平均分配的 scan range 数目 numScanRangePerBe 如果 block 副本所在的 datanode 有be（混部） 每个 scan range 优先分配给副本所在的 be 中 scan range 数目最少的 be。如果 be 已经分配的 scan range 数目大于 numScanRangePerBe，则从远程 be 中选择 scan range 数目最小的 如果有多个 be 上 scan range 数目一样小，则考虑 be 上磁盘的情况，选择副本所在磁盘上已分配的要读取 block 数目小的 be 如果 block 副本所在的 datanode 机器没有 be（单独部署或者可以远程读） 选择 scan range 数目最小的 be 查询执行 在调度到 BE 端进行执行之后，整个执行过程都是向量化的。具体看下面 Iceberg 的例子，IcebergScanNode 对应的 BE 端目前是 HdfsScanNode 的向量化实现，其他算子也是类似，在 BE 端都是向量化的实现。 MySQL [external_db_snappy_yuzhou]> explain select c_customer_id customer_id -> ,c_first_name customer_first_name -> ,c_last_name customer_last_name -> ,c_preferred_cust_flag customer_preferred_cust_flag -> ,c_birth_country customer_birth_country -> ,c_login customer_login -> ,c_email_address customer_email_address -> ,d_year dyear -> ,'s' sale_type -> from customer, store_sales, date_dim -> where c_customer_sk = ss_customer_sk -> and ss_sold_date_sk = d_date_sk; +------------------------------------------------ | PLAN FRAGMENT 0 | OUTPUT EXPRS:2: c_customer_id | 9: c_first_name | 10: c_last_name | 11: c_preferred_cust_flag | 15: c_birth_country | 16: c_login | 17: c_email_address | 48: d_year | 70: expr | | PARTITION: UNPARTITIONED | RESULT SINK | 9:EXCHANGE | PLAN FRAGMENT 1 | OUTPUT EXPRS: | PARTITION: RANDOM | STREAM DATA SINK | EXCHANGE ID: 09 | UNPARTITIONED | 8:Project | | <slot 2> : 2: c_customer_id | | <slot 9> : 9: c_first_name | | <slot 10> : 10: c_last_name | | <slot 11> : 11: c_preferred_cust_flag | | <slot 15> : 15: c_birth_country | | <slot 16> : 16: c_login | | <slot 17> : 17: c_email_address | | <slot 48> : 48: d_year | | <slot 70> : 's' | 7:HASH JOIN | | join op: INNER JOIN (BROADCAST) | | hash predicates: | | colocate: false, reason: | | equal join conjunct: 21: ss_customer_sk = 1: c_customer_sk | 4:Project | | <slot 21> : 21: ss_customer_sk | | <slot 48> : 48: d_year | 3:HASH JOIN | | join op: INNER JOIN (BROADCAST) | | hash predicates: | | colocate: false, reason: | | equal join conjunct: 41: ss_sold_date_sk = 42: d_date_sk | 0:IcebergScanNode | TABLE: store_sales | cardinality=28800991 | avgRowSize=1.4884362 | numNodes=0 | PLAN FRAGMENT 2 | OUTPUT EXPRS: | PARTITION: RANDOM | STREAM DATA SINK | EXCHANGE ID: 06 | UNPARTITIONED | 5:IcebergScanNode | TABLE: customer | cardinality=500000 | avgRowSize=36.93911 | numNodes=0 | PLAN FRAGMENT 3 | OUTPUT EXPRS: | PARTITION: RANDOM | STREAM DATA SINK | EXCHANGE ID: 02 | UNPARTITIONED | 1:IcebergScanNode | TABLE: date_dim | cardinality=73049 | avgRowSize=4.026941 | numNodes=0 三、基准测试 TPC-H 是美国交易处理效能委员会TPC（Transaction Processing Performance Council）组织制定的用来模拟决策支持类应用的测试集。 It consists of a suite of business oriented ad-hoc queries and concurrent data modifications. TPC-H 根据真实的生产运行环境来建模，模拟了一套销售系统的数据仓库。该测试共包含8张表，数据量可设定从1 GB~3 TB不等。其基准测试共包含了22个查询，主要评价指标为各个查询的响应时间，即从提交查询到结果返回所需时间。 测试结论 在 TPCH 100G规模的数据集上进行对比测试，共22个查询，结果如下： StarRocks 使用本地存储查询和 Hive 外表查询两种方式进行测试。其中，StarRocks On Hive 和 Trino On Hive 查询的是同一份数据，数据采用 ORC 格式存储，采用 zlib 格式压缩。测试环境使用阿里云 EMR 进行构建。 最终，StarRocks 本地存储查询总耗时为21s，StarRocks Hive 外表查询总耗时92s。Trino 查询总耗时307s。可以看到 StarRocks On Hive 在查询性能方面远远超过 Trino，但是对比本地存储查询还有不小的距离，主要的原因是访问远端存储增加了网络开销，以及远端存储的延时和 IOPS 通常都不如本地存储，后面的计划是通过 Cache 等机制弥补问题，进一步缩短 StarRocks 本地表和 StarRocks On Hive 的差距。具体测试过程请参考：StarRocks vs Trino TPCH 性能测试对比报告四、未来规划 得益于全面向量化执行引擎，CBO 优化器以及 MPP 执行框架等核心技术，目前 StarRocks 已经实现了远超其他同类产品的极速数据湖分析能力。从长远来看， StarRocks 在数据湖分析方向的愿景是为用户提供极其简单、易用和高速的数据湖分析能力。为了能够实现这一目标，StarRocks 现在还有许多工作需要完成，其中包括： 集成 Pipeline 执行引擎，通过 Push Based 的流水线执行方式，进一步降低查询响应速度 自动的冷热数据分层存储，用户可以将频繁更新的热数据存储在 StarRocks 本地表上，StarRocks 会定期自动将冷数据从本地表迁移到数据湖 去掉显式建立外表的步骤，用户只需要建立数据湖对应的 resource 即可实现数据湖库表全自动同步 进一步完善 StarRocks 对于数据湖产品特性的支持，包括支持 Apache Hudi 的 MOR 表和 Apache Iceberg 的 v2 表；支持直接写数据湖；支持 Time Travel 查询，完善 Catalog 的支持度等 通过层级 Cache 来进一步提升数据湖分析的性能五、更多信息参考链接[1] https://help.aliyun.com/document_detail/404790.html[2] https://github.com/StarRocks/starrocks/issues/1030 [3] https://docs.dorisdb.com/zh-cn/main/using_starrocks/External_table#hive%E5%A4%96%E8%A1%A8[4] https://github.com/StarRocks/starrocks/issues/2772 [5] StarRocks vs Trino TPCH 性能测试对比报告产品活动阿里云 EMR StarRocks 数据湖极速分析体验，99元试用活动火热进行中!点击链接提交试用申请 -> https://survey.aliyun.com/apps/zhiliao/Yns9d9Xxz团队招聘阿里云智能计算平台事业部-开源大数据-OLAP 团队招聘实习生，重点参与 StarRocks、ClickHouse 等开源项目，和社区深度合作。有机会参与核心特性开发，触达海量客户场景。欢迎感兴趣的同学们通过如下二维码投递：我们会在钉钉群定期推送精彩文章，邀请技术大牛直播分享。欢迎钉钉扫码加入产品交流群一起参与讨论~
-
发表了文章 2022-03-08
【首月99元】EMR StarRocks 数据湖极速分析体验，试用活动火热进行中
背景: 随着数据分析需求的发展，数据湖成为大数据架构领域新趋势。阿里云携手 StarRocks 社区，致力于将 StarRocks 系统打造为全新的数据湖分析引擎，为用户提供极速的分析体验。一、产品活动日前，阿里云与 StarRocks 社区合作，推出了首款 StarRocks 云上产品。此外，面向新老用户还提供了99元指定机型（ecs.c6.xlarge）首月试用的优惠活动。申请方式如下：点击链接提交试用申请 -> https://survey.aliyun.com/apps/zhiliao/Yns9d9Xxz欢迎大家前来试用，有技术交流、产品咨询及使用相关讨论，钉钉扫码进群参与交流：二、产品介绍StarRocks 介绍StarRocks 充分吸收关系型 OLAP 数据库和分布式存储系统在大数据时代的优秀研究成果，在业界实践的基础上，进一步改进优化、升级架构，并增添了众多全新功能，形成了全新的企业级产品。StarRocks 致力于构建极速统一分析体验，满足企业用户的多种数据分析场景，支持多种数据模型（明细模型、聚合模型和更新模型等），多种导入方式（批量和实时），可整合和接入多种现有系统（Spark、Flink、Hive 和 Elasticsearch）。StarRocks 兼容 MySQL 协议，可使用 MySQL 客户端和常用 BI 工具对接 StarRocks 来分析数据。StarRocks 采用分布式架构，对数据表进行水平划分并以多副本存储。集群规模可以灵活伸缩，可以支持10 PB 级别的数据分析，支持 MPP 框架，并行加速计算，支持多副本，具有弹性容错能力。StarRocks 采用关系模型，使用严格的数据类型和列式存储引擎，通过编码和压缩技术，降低读写放大；使用向量化执行方式，充分挖掘多核 CPU 的并行计算能力，从而显著提升查询性能。三、应用场景StarRocks 可以满足企业级用户的多种分析需求，包括 OLAP 多维分析、定制报表、实时数据分析和 Ad-Hoc 数据分析等。具体的业务场景如下表所示：场景描述OLAP 多维分析OLAP 多维分析用户行为分析用户画像、标签分析、圈人高维业务指标报表自助式报表平台业务问题探查分析跨主题业务分析财务报表系统监控分析实时数据分析电商大促数据分析教育行业的直播质量分析物流行业的运单分析金融行业绩效分析、指标计算广告投放分析管理驾驶舱探针分析 APM（Application Performance Management）高并发查询广告主报表分析零售行业渠道人员分析SaaS 行业面向用户分析报表Dashbroad 多页面分析统一分析通过使用一套系统解决多维分析、高并发查询、预计算、实时分析和 Ad-Hoc 查询等场景，降低系统复杂度和多技术栈开发与维护成本。四、快速入门创建集群点击链接查看详细介绍：https://help.aliyun.com/document_detail/405471.html
2023年06月
-
06.06 16:02:06
发表了文章
2023-06-06 16:02:06
面向未来的开源 OLAP 技术架构探讨以及选型实践
本文详细介绍了开源大数据OLAP的演化过程和最佳实践。
-
06.02 17:44:32发表了文章
2023-06-02 17:44:32
开源大数据平台 E-MapReduce Serverless StarRocks 产品介绍
本文将分享阿里云与 StarRocks 社区合作打造的云上 StarRocks 极速湖仓的云原生产品实践。 主要包括四个部分，第一部分介绍 StarRocks 全托管形态，以及免运维服务的 OLAP 云产品；第二部 分介绍 StarRocksManager 的实例管理、诊断分析、元数据管理、安全中心等功能；第三部分介绍 在社交、在线教育、电商等场景的使用案例；最后是对产品的长短期规划。
2023年05月
-
05.24 18:34:10发表了文章
2023-05-24 18:34:10
企查查基于阿里云Elasticsearch 在复杂检索场景中的性能优化
本文分享企查查基于阿里云Elasticsearch 在复杂检索场景中的性能优化。
-
05.23 16:33:36发表了文章
2023-05-23 16:33:36
猿辅导基于 EMR StarRocks 的 OLAP 演进之路
猿辅导大数据平台团队负责人申阳分享了猿辅导基于EMR StarRocks 的 OLAP 演进之路。
-
05.10 18:16:44发表了文章
2023-05-10 18:16:44
阿里云E-MapReduce产品新动态及开源大数据前沿技术 2023-4月刊
开源大数据EMR产品技术月刊，涵盖本月技术速递、产品和功能发布、市场和客户应用实践等内容，帮助您快速了解开源大数据最新动态。
-
05.09 17:18:45发表了文章
2023-05-09 17:18:45
水滴筹基于阿里云 EMR StarRocks 实战分享
水滴筹大数据部门的数据开发工程师韩园园老师为大家分享水滴筹基于阿里云EMR StarRocks的实战经验。
-
05.04 13:50:54发表了文章
2023-05-04 13:50:54
阿里云智能数据湖入选第六届数字中国建设峰会“十大硬核科技”
阿里云首创并推动的智能数据湖解决方案因“引领业界技术上创新”入选第六届数字中国建设峰会的“十大硬核科技”，这也是历届峰会中首次有数据湖产品入选。智能数据湖是阿里云在大数据和 AI 融合的时代背景下推出，底层融合存储和计算全新技术体系，业务侧融合多元计算，对接数据科学计算引擎。支撑在线教育、互联网广告、新媒体、网络游戏等近万家行业用户在快速发展过程中的业务需求，为企业数字化转型提供源动力。
2023年04月
-
04.12 18:06:01发表了文章
2023-04-12 18:06:01
免费公测｜阿里云EMR Serverless StarRocks 公测正式开启！
阿里云EMR Serverless StarRocks 免费公测已开启，向所有用户开放！您可通过EMR控制台直接创建实例，轻松体验全托管、免运维的服务。
-
04.10 13:56:51发表了文章
2023-04-10 13:56:51
北京 Meetup 邀你来｜阿里云 × StarRocks 云上StarRocks极速湖仓
4月19日（周三）下午，水滴筹、猿辅导、阿里云 EMR 团队和 StarRocks 社区的技术专家，将针对开源 OLAP 技术架构、 StarRocks 产品硬核技术及 EMR StarRocks 实战经验等一系列超干货内容，为大家带来诚意满满的技术盛宴。
-
04.04 10:54:58发表了文章
2023-04-04 10:54:58
阿里云E-MapReduce产品新动态及开源大数据前沿技术 2023-3月刊
开源大数据EMR产品技术月刊，涵盖本月技术速递、产品和功能发布、市场和客户应用实践等内容，帮助您快速了解开源大数据最新动态。
2023年03月
-
03.28 11:17:48发表了文章
2023-03-28 11:17:48
阿里云EMR自定义日志投递与使用实践分享
EMR目前支持了日志管理，即日志客户SLS投递的功能，基于此功能，客户可以将需要的各种大数据组件日志收集到自身SLS中，做查询和分析。基于此功能，客户可以自定义日志路径、规则，对集群设备上的日志自行接收和消费。本文以采集指标文件为例，帮助您快速上手自定义日志投递与使用。
-
03.23 17:59:43发表了文章
2023-03-23 17:59:43
通过云监控CloudMonitor实时捕获EMR集群的状态变化
通过结合CloudMonitor以及FC，可以实时捕获EMR集群的生命周期变化，如集群的创建和停止，扩容和缩容以及其他类型的集群状态变更等。
-
03.09 18:12:09发表了文章
2023-03-09 18:12:09
数据湖存储的安全写入之道
本文以 Hadoop 社区中的 S3A Connector 的实现为切入，分析了数据湖写入路径的安全性。
-
03.07 14:25:07发表了文章
2023-03-07 14:25:07
基于阿里云 CloudMonitor云监控自定义监控大盘对 EMR 自定义监控实践
本文旨在分享 EMR 平台大数据服务基于阿里云 CloudMonitor 的监控实践，给客户提供除了 EMR 平台默认监控以外，自建监控方式，适用于统一多个阿里云服务的监控监控场景。
-
03.03 19:15:43发表了文章
2023-03-03 19:15:43
阿里云EMR 2.0：定义下一代云原生智能数据湖
本次分享主要介绍了阿里云云原生数据湖分析解决方案的三个核心要素：全托管，湖存储；一站式，湖管理；多模态，湖计算。
-
03.01 10:14:42发表了文章
2023-03-01 10:14:42
阿里云开源大数据平台E-MapReduce 产品新动态及开源大数据前沿技术分享 2023-2月刊
开源大数据平台 EMR 产品技术月刊，涵盖本月技术速递、产品和功能发布、市场和客户应用实践等内容，帮助您快速了解开源大数据最新动态。
2023年02月
-
02.22 16:46:20发表了文章
2023-02-22 16:46:20
开源大数据可观测性方案实践 - 助力集群运维智能化、便捷化
在本篇文章中，我们将介绍大数据集群领域所需的可观测性，实践大数据集群可观测所需要的条件和面临的挑战，以及阿里云EMR 产品如何通过 EMR Doctor 实现大数据可观测并向用户提供相关能力。
-
02.21 16:55:00发表了文章
2023-02-21 16:55:00
阿里云EMR 2.0：兼容开源，贡献开源，超越开源
本文整理自阿里云资深技术专家吴威(无谓)在 阿里云EMR2.0线上发布会 的分享。本文从开源的角度出发，分享了阿里云EMR团队的工作。
-
02.17 18:31:59发表了文章
2023-02-17 18:31:59
基于数据湖格式构建流式增量数仓—CDC
该文章内容源于 Apache Con ASIA 2022上的分享，整理归纳成文章。
-
02.15 18:14:49发表了文章
2023-02-15 18:14:49
阿里云EMR2.0平台：让大数据更简单
作为国内开源大数据领域的引领者，EMR2.0在平台体验、数据开发、产品形态及数据分析等方面做了全面突破与创新，重新定义了新一代开源大数据平台。本文介绍如何利用EMR新平台实现更加低成本、高效率、智能化的大数据集群管控和应用开发。
-
02.08 11:45:04发表了文章
2023-02-08 11:45:04
StarRocks 2.5 LTS 版本新特性介绍及阿里云EMR Serverless StarRocks火热邀测中
StarRocks 2.5 LTS 版本于近期发布，阿里云EMR Serverless StarRocks也在火热邀测中。本文将重点介绍StarRocks 2.5版本核心功能以及阿里云EMR Serverless StarRocks特性。
-
02.07 17:25:56发表了文章
2023-02-07 17:25:56
Spark+Celeborn：更快，更稳，更弹性
本文整理自阿里云 EMR Spark 团队的周克勇（一锤），在 Spark&DS Meetup 的分享。
-
02.03 11:06:41发表了文章
2023-02-03 11:06:41
阿里云EMR 2.0：重新定义新一代开源大数据平台
本次分享主要介绍了阿里云E-MapReduce的开发历程，EMR 2.0的新特性、产品架构，以及EMR 2.0在平台体验、数据开发、资源形态及分析场景等方面的全面突破与创新，重新定义新一代开源大数据平台。
2023年01月
-
01.10 17:52:40发表了文章
2023-01-10 17:52:40
直播预约｜Apache Spark + DolphinScheduler Meetup 1月11日正式上线
洞悉 Spark 任务调度新能力｜Apache Spark + DolphinScheduler Meetup 将于 1 月 11 日在线上举办
-
01.05 10:52:04发表了文章
2023-01-05 10:52:04
Apache Spark + 海豚调度：PB 级数据调度挑战，教你如何构建高效离线工作流
Apache Spark Meetup | 1 月线上直播报名通道已开启，赶快报名预约吧！
-
01.05 10:48:41发表了文章
2023-01-05 10:48:41
Apache Spark + 海豚调度：PB 级数据调度挑战，教你如何构建高效离线工作流
Apache Spark Meetup | 1 月线上直播报名通道已开启，赶快报名预约吧！
2022年12月
-
12.28 12:07:44发表了文章
2022-12-28 12:07:44
阿里云开源大数据平台EMR全面升级 性能最高可提升6倍
12月27日,阿里云正式发布云原生开源大数据平台EMR 2.0，升级后的开源大数据平台在成本持平的情况下，扩缩容性能最高可提升6倍。
-
12.19 11:52:46发表了文章
2022-12-19 11:52:46
直播预约｜阿里云EMR 2.0 重磅发布
面向未来，构建新一代开源大数据基础设施！阿里云EMR 2.0 发布会 将于12月27日14点在线上举办。
-
12.12 01:02:19发表了文章
2022-12-12 01:02:19
技术内幕 | 阿里云EMR StarRocks 极速数据湖分析
本文为作者在 StarRocks Summit Asia 2022 上的分享
-
12.07 10:39:02发表了文章
2022-12-07 10:39:02
直播预告｜数据仓库？数据湖？停止纠结，流批融合的极速 Lakehouse来了！
无需数据导入，即可体验性能堪比数仓的数据湖分析！2022年12月8日19点，StarRocks Lakehouse Meetup - 极速湖仓分析技术专场线上直播重磅开启，精彩不容错过！
2022年11月
-
11.24 01:06:34发表了文章
2022-11-24 01:06:34
EMR-StarRocks 与 Flink 在汇量实时写入场景的最佳实践
本文详细介绍了 EMR-StarRocks 与 Flink 在汇量实时写入场景的最佳实践。
2022年09月
-
09.23 12:01:49发表了文章
2022-09-23 12:01:49
基于EMR的新一代数据湖存储加速技术详解
本文整理自阿里云开源大数据平台数据湖存储团队孙大鹏在7月17日阿里云数据湖技术专场交流会的分享。
-
09.16 15:25:21发表了文章
2022-09-16 15:25:21
数据湖管理及优化
本文整理自阿里云开源大数据高级开发工程师杨庆苇在7月17日阿里云数据湖技术专场交流会的分享。
-
09.13 17:46:24发表了文章
2022-09-13 17:46:24
EMR重磅发布智能运维诊断系统(EMR Doctor)——开源大数据平台运维利器
E-MapReduce 推出面向开源大数据集群的智能运维诊断系统 E-MapReduce Doctor，有效提升大数据集群运维效率，辅助 EMR 用户完善集群监控体系。
-
09.06 17:25:26发表了文章
2022-09-06 17:25:26
数据湖统一元数据与权限
本文整理自阿里云数据湖构建与分析研发熊佳树在7月17日阿里云数据湖技术专场交流会的分享。
2022年08月
-
08.30 18:37:08发表了文章
2022-08-30 18:37:08
数据湖架构及概念简介
本文整理自阿里云开源大数据技术专家陈鑫伟在7月17日阿里云数据湖技术专场交流会的分享。
-
08.16 15:42:58发表了文章
2022-08-16 15:42:58
重磅发布！阿里云全链路数据湖开发治理解决方案
阿里云重磅发布全链路数据湖解决方案，主要包含开源大数据平台E-MapReduce(EMR) + 一站式大数据数据开发治理平台DataWorks + 数据湖构建DLF + 对象存储OSS等核心产品。
2022年06月
-
06.29 17:48:06发表了文章
2022-06-29 17:48:06
国内首批！阿里云云原生数据湖产品通过信通院评测认证
国内首批！得分排名第一！
-
06.01 15:52:17发表了文章
2022-06-01 15:52:17
关于 Data Lake 的概念、架构与应用场景介绍
本文详细介绍了 Data Lake 的概念、架构与应用场景介绍。
2022年05月
-
05.26 16:41:35发表了文章
2022-05-26 16:41:35
StarRocks X Flink CDC，打造端到端实时链路
作为一款全平台极速 MPP 架构，StarRocks 提供了多种性能优化手段与灵活的建模方式，在预聚合、宽表和星型/雪花等多种模型上，都可以获得极致的性能体验。通过 StarRocks 结合 Flink 构建开源实时数仓的方案，可以同时提供秒级数据同步和极速分析查询的能力。同时，通过 StarRocks 主键模型，也可以更好地支持实时和频繁更新等场景。
-
05.13 15:19:26发表了文章
2022-05-13 15:19:26
EMR-StarRocks 白皮书来啦！
EMR StarRocks 白皮书免费下载，架构、功能、解决方案，全方位解读！
-
05.13 11:21:57发表了文章
2022-05-13 11:21:57
数据湖构建—如何构建湖上统一的数据权限
阿里云数据湖构建产品（DLF）提供的统一元数据服务，通过完善各种引擎/表格式生态解决了数据湖场景下多引擎面临的数据孤岛和元数据一致性问题，实现了开源大数据引擎及数据湖格式元数据的统一视图，避免了各引擎访问湖上数据其中额外的ETL成本并降低了业务处理链路的延时。
-
05.10 18:23:55发表了文章
2022-05-10 18:23:55
Delta Lake基础介绍（开源版）【Databricks 数据洞察公开课】
针对社区版本Delta Lake提供的几大核心特性进行讲解，并通过示例演示如何使用这些特性。
-
05.10 18:23:02发表了文章
2022-05-10 18:23:02
深度解析数据湖存储方案Lakehouse架构【Databricks 数据洞察公开课】
从数据仓库、数据湖的优劣势，湖仓一体架构的应用和优势等多方面深度解析Lakehouse架构。
-
05.10 18:22:39发表了文章
2022-05-10 18:22:39
Databricks 企业版 Spark&Delta Lake 引擎助力 Lakehouse 高效访问
本文介绍了Databricks企业版Delta Lake的性能优势，借助这些特性能够大幅提升Spark SQL的查询性能，加快Delta表的查询速度。
-
05.10 18:22:21发表了文章
2022-05-10 18:22:21
Delta Lake的演进历史及现状【Databricks 数据洞察公开课】
从大数据平台架构的演进、Delta Lake关键特性、版本迭代、重要功能等多方面，介绍Delta Lake的演进和优势。
-
发表了文章
2023-06-06
面向未来的开源 OLAP 技术架构探讨以及选型实践
-
发表了文章
2023-06-02
开源大数据平台 E-MapReduce Serverless StarRocks 产品介绍
-
发表了文章
2023-05-24
企查查基于阿里云Elasticsearch 在复杂检索场景中的性能优化
-
发表了文章
2023-05-23
猿辅导基于 EMR StarRocks 的 OLAP 演进之路
-
发表了文章
2023-05-10
阿里云E-MapReduce产品新动态及开源大数据前沿技术 2023-4月刊
-
发表了文章
2023-05-09
水滴筹基于阿里云 EMR StarRocks 实战分享
-
发表了文章
2023-05-04
阿里云智能数据湖入选第六届数字中国建设峰会“十大硬核科技”
-
发表了文章
2023-04-12
免费公测｜阿里云EMR Serverless StarRocks 公测正式开启！
-
发表了文章
2023-04-10
北京 Meetup 邀你来｜阿里云 × StarRocks 云上StarRocks极速湖仓
-
发表了文章
2023-04-04
阿里云E-MapReduce产品新动态及开源大数据前沿技术 2023-3月刊
-
发表了文章
2023-03-28
阿里云EMR自定义日志投递与使用实践分享
-
发表了文章
2023-03-23
通过云监控CloudMonitor实时捕获EMR集群的状态变化
-
发表了文章
2023-03-09
数据湖存储的安全写入之道
-
发表了文章
2023-03-07
基于阿里云 CloudMonitor云监控自定义监控大盘对 EMR 自定义监控实践
-
发表了文章
2023-03-03
阿里云EMR 2.0：定义下一代云原生智能数据湖
-
发表了文章
2023-03-01
阿里云开源大数据平台E-MapReduce 产品新动态及开源大数据前沿技术分享 2023-2月刊
-
发表了文章
2023-02-22
开源大数据可观测性方案实践 - 助力集群运维智能化、便捷化
-
发表了文章
2023-02-21
阿里云EMR 2.0：兼容开源，贡献开源，超越开源
-
发表了文章
2023-02-17
基于数据湖格式构建流式增量数仓—CDC
-
发表了文章
2023-02-15
阿里云EMR2.0平台：让大数据更简单
滑动查看更多
暂无更多信息
暂无更多信息