首页 文章 精选 留言 我的

精选列表

搜索[稳定]，共10000篇文章
优秀的个人博客,低调大师

Flink Hudi 0.10.0 发布，多项重要更新，稳定性大幅提升

随着云数仓技术的不断成熟，数据湖俨然已成为当下最热门的技术之一，而 Apache Hudi 是当下最具竞争力的数据湖格式之一： 拥有最活跃的开源社区之一，周活跃 PR 一直维持在 50+ 水平； 拥有最活跃的国内用户群之一，目前的 Apache Hudi 钉钉群用户已超过 2200+，国内各大厂商都已经布局 Apache Hudi 生态。 Apache Hudi 的活跃度得益于其出色的 file format 设计和丰富的事物语义支持： 类 LSM 的 file format 布局很好的适配了近实时更新场景，解决了超大数据集更新的痛点； Hudi 的事物层语义在目前的湖存储中是极其成熟和丰富的，基本所有的数据治理都可以自动化完成：compaction、rollback、cleaning、clustering。 Flink On Hudi Apache Hudi 的 table format 对流计算友好的特性使得 Flink On Hudi 成为 Apache Hudi 项目最值得探索和挖掘的方向之一，Flink 不仅为 Hudi 解锁了超大数据流的实时更新能力、更添加了流式消费和计算的能力，让端到端近实时 ETL 得以在低成本的文件存储上轻松实现。 Flink On Hudi 项目在 2020 年 11 月立项，至今已迭代了三个版本，从第一个版本开始人气和活跃度就一直高涨。5 月份组建的 Apache Hudi 钉钉群截止目前半年的时间，已经有超过 2200+ 用户，并且活跃度一直排在 Flink 用户群的前列。 Flink On Hudi 已成为部署 Apache Hudi 项目的首选方案，国内主要云厂商：阿里云、华为云、腾讯云，国外的 AWS 都已集成 Flink On Hudi；国内的大型互联网公司：头条、快手、B站 以及传统企业：顺丰、海康等均有 Flink On Hudi 的生产实践，具钉钉群的跟踪回访等不完全统计，至少超过 50+ 国内公司在生产上使用 Flink On Hudi，Uber 公司更将 Flink On Hudi 作为 2022 年的重点方向在推进 ！ Flink On Hudi 的开发者生态也非常活跃，目前国内有阿里云、华为云、头条、B站的同学持续贡献，Uber 公司和 AWS 更专门投入人力来对接 Flink On Hudi。 版本 Highlights 0.10.0 版本经过社区用户的千锤百炼，贡献了多项重要的 fix，更有核心读写能力的大幅增强，解锁了多个新场景，Flink On Hudi 侧的更新重点梳理如下： Bug 修复 修复对象存储上极端 case 流读数据丢失的问题 [HUDI-2548]； 修复全量+增量同步偶发的数据重复 [HUDI-2686]； 修复 changelog 模式下无法正确处理 DELETE 消息 [HUDI-2798]； 修复在线压缩的内存泄漏问题 [HUDI-2715]。 新特性 支持增量读取； 支持 batch 更新； 新增 Append 模式写入，同时支持小文件合并； 支持 metadata table。 功能增强 写入性能大幅提升：优化写入内存、优化了小文件策略(更加均衡，无碎片文件)、优化了 write task 和 coordinator 的交互； 流读语义增强：新增参数 earliest，提升从最早消费性能、支持参数跳过压缩读取，解决读取重复问题； 在线压缩策略增强：新增 eager failover + rollback，压缩顺序改为从最早开始； 优化事件顺序语义：支持处理序，支持事件序自动推导。 下面挑一些重点内容为大家详细介绍： 小文件优化 Flink On Hudi 写入流程大致分为以下几个组件： row data to hoodie：负责将 table 的数据结构转成 HoodieRecord； bucket assigner：负责新的文件 bucket (file group) 分配； write task：负责将数据写入文件存储； coordinator：负责写 trasaction 的发起和 commit； cleaner：负责数据清理。 其中的 bucket assigner 负责了文件 file group 的分配，也是小文件分配策略的核心组件。0.10.0 版本的每个 bucket assign task 持有一个 bucket assigner，每个 bucket assigner 独立管理自己的一组 file group 分组： 在写入 INSERT 数据的时候，bucket assigner 会扫描文件视图，查看当前管理的 file group 中哪些属于小文件范畴，如果 file group 被判定为小文件，则会继续追加写入。比如上图中 task-1 会继续往 FG-1、FG-2 中追加 80MB 和 60MB 的数据。 为了避免过度的写放大，当可写入的 buffer 过小时会忽略，比如上图中 FG-3、FG-4、FG-5 虽然是小文件，但是不会往文件中追加写。task-2 会新开一个 file group 写入。 全局文件视图 0.10.0 版本将原本 write task 端的文件视图统一挪到 JobManager，JobManager 启动之后会使用 Javaline 本地启动一个 web server，提供全局文件视图的访问代理。Write task 通过发送 http 请求和 web server 交互，拿到当前写入的 file group 视图。 Web server 避免了重复的文件系统视图加载，极大的节省了内存开销。 流读能力增强 0.10.0 版本新增了从最早消费数据的参数，通过指定 read.start-commit 为 earliest 即可流读全量 + 增量数据，值得一提的是，当从 earliest 开始消费时，第一次的 file split 抓取会走直接扫描文件视图的方式，在开启 metadata table 功能后，文件的扫描效率会大幅度提升；之后的增量读取部分会扫描增量的 metadata，以便快速轻量地获取增量的文件讯息。 新增处理顺序 Apache Hudi 的消息合并大体分为两块：增量数据内部合并、历史数据和增量数据合并。消息之间合并通过write.precombine.field字段来判断版本新旧，如下图中标注蓝色方块的消息为合并后被选中的消息。 0.10.0 版本可以不指定write.precombine.field 字段，此时使用处理顺序：即后来的消息比较新，对应上图紫色部分被选中的消息。 Metadata Table Metadata table 是 0.7.0 Hudi 引入的功能，目的是在查询端减少 DFS 的访问，类似于文件 listings 和 partitions 信息直接通过 metadata table 查询获取。Metadata 在 0.10.0 版本得到大幅加强，Flink 端也支持了 该功能。 新版的 metadata table 为同步更新模型，当完成一次成功的数据写入之后，coordinator 会先同步抽取文件列表、partiiton 列表等信息写入 metadata table 然后再写 event log 到 timeline (即 metadata 文件)。 Metadata table 的基本文件格式为 avro log，avro log 中的文件编码区别于正常的 MOR data log 文件，是由高效的 HFile data block 构成，这样做的好处是自持更高效率的 kv 查找。同时 metadata table 的 avro log 支持直接压缩成 HFile 文件，进一步优化查询效率。 总结和展望 在短短的半年时间，Flink On Hudi 至今已积攒了数量庞大的用户群体。积极的用户反馈和丰富的用户场景不断打磨 Flink On Hudi 的易用性和成熟度，使得 Flink On Hudi 项目以非常高效的形式快速迭代。通过和头部公司如头条、B 站等共建的形式，Flink On Hudi 形成了非常良性的开发者用户群。 Flink On Hudi 是 Apache Hudi 社区接下来两个大版本主要的发力方向，在未来规划中，主要有三点： 完善端到端 streaming ETL 场景 支持原生的 change log、支持维表查询、支持更轻量的去重场景； Streaming 查询优化 record-level 索引，二级索引，独立的文件索引； Batch 查询优化 z-ordering、data skipping。 致谢 最后感谢 Flink Hudi 活跃的社区用户以及开发者，正是有你们一路相伴，Flink On Hudi 才能高效率地演化和迭代；也因为有你们，Flink On Hudi 在实时数据湖方向的探索和实践逐渐成为行业先驱，且越来越成熟 ~
2021-12-10
优秀的个人博客,低调大师

揭秘：技术风险如何保障支付宝的稳定性？

就现在！蚂蚁「校招季」重磅来袭！除了介绍蚂蚁的技术大咖，我们还邀请了一些通过校招来到蚂蚁的过来人分享他们的通关经验和心得，这里随时可能有行业技术大咖和你的直系学长学姐出没哦～ 「校招季」栏目会持续输出有关“蚂蚁校招”的丰富内容，敬请期待！ 之前，我们介绍过支付宝有一个“疯起来连自己都打”的项目，现在，它要招募应届生了！ 这是一个什么样的项目？它需要什么样的应届生？别着急，让我一一道来。 “疯起来连自己的都打”的项目 如果一个技术团队不干别的，专门“搞破坏”，这是一种怎样的存在？这真的不是“天方夜谭”，在支付宝确实有这么一支队伍——技术蓝军。蓝军的任务就是不断地攻击和进攻，而防守方则是技术红军。 蓝军自诞生之日起就带有浓厚的神秘色彩，办公室大门总是紧闭，因为白板上不定时更新着每天攻击的红军队伍，以及发起攻击的时间，这是演习中需要严格保密的关键情报。 “像是以一己之力对抗整个蚂蚁金服的技术人员。”在蓝军眼中，故障必然会发生，只是时间早晚而已，所以只能想尽办法去触发这些故障，这样，在故障真实发生的时候，才有足够的应付能力。 技术攻防演练每周都在进行，除了每年6月初的“期中考试”周，12月第三个星期为年度技术“期末考试”周，技术蓝军随时都会组织突袭攻击“测验”，通过实战中发掘出来的脆弱点牵引红军进行能力升级。 蓝军正在研究突袭计划 在线、实时、随地、无差别、突袭……蓝军的攻击总让人防不胜防。 2018年年中，蓝军在周末发起突袭，刚好红军的一位同学正在举办婚礼，为了不影响新郎迎娶新娘，由红军组成的程序员伴郎团纷纷从包里掏出电脑，蹲坐在角落里，噼里啪啦敲着键盘进行修复。 作为报复，红军也祭出了“尖端武器”——自适应容灾、防抖（保证任何网络或基础设施抖动，用户都无感知）等系统，这让蓝军吃尽苦头，几乎每一记攻击都像打在棉花上，毫无作用。 除了设计缜密的防御措施防止蓝军的袭击，拜关公求庇佑也是红军的“习俗”。 为了确保挫败蓝军的突袭，红军除了在防御系统上下足功夫，还会在每年期中和期末的攻防演练前举办仪式——拜关公，除了叩拜，还得摆上旺仔牛奶、格子衬衫、键盘、香烟等贡品。 在支付宝，蓝军从属于蚂蚁金服技术风险部（SRE），而红军则包括SRE及各业务部门的技术团队。除了红蓝攻防，技术风险团队还做些什么呢？ 技术风险都做些什么 支付宝的线上系统极其复杂，每一笔交易背后是数亿行代码、成百上千个系统，经过无数的链路，再加上海量线上实时交易，谁也无法预测下一秒是否会出现什么样的问题。如何消除人们的焦虑呢？这时就轮到技术风险团队登场了。 技术风险工作就是使用技术手段，把各种软件、硬件、人为引入的可能出现业务受损的的风险降到最低。在支付宝，它服务于从基础设施到上层应用的所有系统，从写第一行代码到最终上线的整个研发流程。 目前，技术风险工作主要由SRE来承接，日常的工作包括变更风险防御、快速应急、红蓝攻防、资金安全等，同时像双11大促，春节红包等高并发高性能的场景是技术风险工作的大考。 SRE是 Site Risk Engineering 的缩写，主要工作是围绕线上风险问题，研发技术架构和解决方案，去解决各种各样的风险问题。 变更指的是代码上线到实际生产环境的过程，我们需要围绕变更建立各种技术手段，减少变更导致的故障，研发变更相应的平台。据统计，80%的系统生产故障都来自于代码变更，因此无论怎么重视也不为过。支付宝建立了一系列制度保证系统内的任何变更都符合可监控、可灰度、可回滚的“三板斧”要求。 而一旦线上真的出现了问题，就涉及到应急机制了。支付宝有一套完善的线上应急流程，包括怎么快速定位问题，以及一个数据智能化的监控系统，可以迅速从线上海量业务中找出风险异常点。一旦发现任何问题就发出告警通知相应的同学，进行相应的流程进行解决。 平时没有故障的时候做什么呢？就是开头提到的红蓝攻防了。蓝军从第三方角度发掘各类脆弱点，并通过红蓝军技术攻防演练，不断验证防御系统的可靠性。每年的大演练时刻，都会进行全公司的动员，两边排兵布阵，攻守异常激烈。 在“期末考试”中，每支红军在被攻击后，花费多长时间发现故障，又用了多长时间恢复等都会被视作评定指标，而结果会根据“无损”攻防体系相匹配的度量平台，对攻防结果进行排名。 去年“期末考试”冠军得主是红一支付宝军，支付宝资深技术专家兼军长李铮提到，去年12月21日的红蓝大军颁奖仪式上，第一名获得了一副金算盘，以及关公铜像一年所有权，而今年还给最后一名准备了特别“奖品”——一副烂算盘，“真的是很烂的算盘，也就淘宝上才能买到。” 除此之外，资金安全是专门保护支付宝里的资金的系统，在海量线上资金处理时，要保证一分钱资金都不出问题，需要的是海量数据计算和风险挖掘能力。 技术风险的未来：喝着红酒过大促 2018年杭州云栖大会ATEC峰会，时任蚂蚁金服副CTO胡喜在现场2000多人的注视下做了一场技术演示，杭州两个数据中心的服务器网线被人为剪断，在40%服务器突然无法工作的情况下，系统只用了26秒便恢复正常，这次演示展现了蚂蚁金服“三地五中心”架构的容灾能力，也是蚂蚁金融科技开放的技术解决方案之一。 这已经很了不起，不过，和技术风险团队对未来的畅想相比，还有不少距离。 当前，支付宝正在向云原生架构转型，作为守门员的技术风险团队面临着巨大的挑战。这些挑战包括：产品需求变更频繁、软件开发速度也越来越快，这个过程中带来风险的可能性和频率也越来越高；基础架构的迁移要求系统进行全面的测试，带来了巨大的测试工作量；原有的技术风险基础设施和中台部分系统不适应云原生架构，需要重新研发。 不过，李铮表示，挑战同时也意味着机遇，云原生化将给技术风险带来巨大的技术红利。 以双十一大促场景为例，双十一是支付宝创新技术的演练场，每年最先进的技术都会在双十一的舞台上亮相，在2019年双十一大促中，诸多云原生技术就第一次登上舞台。每年双十一的峰值越来越高，而我们的追求是保证效率进一步提升，成本进一步下降。利用云原生技术可以做到更快速的弹性伸缩，在几分钟之内就能完成扩容和拉起服务，这在以前是难以做到的。 随着云原生技术的进一步深化，我们可以畅想，未来双十一保障会变成一件非常轻松的事情。利用如Serverless等技术，做到快速和自动化调度，不需要人的参与，就可以扛住双十一的峰值，实现以前 “喝着红酒过大促” 的梦想。 而要实现这些，关键就是把技术风险能力云原生化，包含三个部分：从云自身看，要对云上技术和变更的完全可控；从技术风险角度看，需要统一技术的数据资产为技术风险服务；从云服务的业务角度看，技术风险功能需要内置，业务系统不用研发甚至不感知就能具备能力。 除了云原生之外，技术风险的另一个发展趋势就是数据化和智能化。 数据智能在技术风险领域可以起到非常大的作用，概括来谈，可以分为提升效率和扩展边界。一方面，通过历史日志和监控数据对模型进行训练，AI 可以自动化一些需要人工的作业流程，比如错误聚类，根因分析，还可以根据历史数据进行预测，比如智能容量评估；另一方面，AI 可以同时进行的任务远远超过人工，覆盖的业务范围更广，可以做到以前人工做不到的事情，比如故障自愈。 未来，技术风险防控体系将具备更多智能特性，尽量减少人工干预，最好的情况是实现无人值守，由智能化的风险系统来应对各种风险场景，完成全局最佳的风险决策。这将是整个团队的努力方向——让大促和所有变更无人值守。 寄语应届生：什么样的人适合做技术风险 技术风险团队正在面向广大高校招募应届生，李铮也分享了他认为一个优秀的候选人所需要具备的素质。 首先，要想在技术风险领域有所作为，需要对技术本身非常感兴趣，要灵活运用各种新技术手段去应对各种风险，而风险很多时候都涉及到技术深层次的原因，只有耐下心来掌握其中的原理才能快速解决。 其次是需要有解决问题的能力。因为线上发生的问题可能千奇百怪，你需要去定义问题，然后用创新思维去解决问题，需要思考如何定义风险架构，体系化系统化的把问题根治。 还有一点是主动性，很多人看到风险会有点抗拒，有点往后退，不太愿意面对风险，但技术风险团队的工作就是要直面风险，与风险同行。遇到问题要么自己解决，要么找到其他人配合一起解决，需要这种主动担当的能力，遇到风险能挺身而出，解决危机。 最后是快速学习、快速掌握技能的能力。像上面提到的云原生、数据智能等，如今技术风险领域新的技术层出不穷，像以前一样靠一项技术吃老本是不行的，必须拥抱变化，时刻准备着学习新的技能。 最后，祝愿大家都能找到自己理想的工作~
2020-10-16
优秀的个人博客,低调大师

Jboot v3.2.1 发布，优化细节、完善文档、提高稳定

Jboot 是一个基于 JFinal、JFinal-Undertow、Dubbo 等开发的微服务框架，帮助开发者降低微服务开发门槛。同时完美支持在 idea、eclipse 下多 maven 模块，对 java 代码、html、css、js 等资源文件进行热加载。爽爽开发，快乐生活。 Jboot 3.1.x 主要更新如下： 一：RPC 完全重构 Jboot 3.1.x对 RPC 进行了完全重构，在配置方便需要变更才能正常使用，API 没有变，所有可以平滑升级到 Jboot 3.1.x，虽然 API 没有改变，但是实现发送了彻底的改变。 对于 Dubbo，在 2.7.x 下新增了很多功能，比如元数据中心、配置中心等功能，Jboot 进行重构后，支持对 Dubbo 的所有内容进行配置，同时支持单个 Application 下有多注册中心、多服务协议等支持。配置上更加灵活。 二：新增门户网关 Jboot v3.1.0 还新增了门户网关，网关支持了 host、path、query等不同的条件配置，性能极高，同时支持基于 Sentinel 下的分布式限流、自定义网关拦截器等等功能。 三：分布式缓存运维支持 在很多二次缓存的分布式缓存中，比如 J2Cache、EHRedis 等，由于其一级缓存可能是内存缓存，其更新是需要依赖 MQ 或者 redis 的 Pub/Sub 来进行通知的，但是在某些极端情况下，依然会出现 MQ 通知不到导致某些节点 一级缓存无法更新的问题，Jboot 提供了可以获取所有 cacheName，并可以对其进行刷新（refresh）的功能，在某些特别极端的情况下，可以通过运维手动刷新缓存，让所有分布式缓存节点进行缓存同步。 Jboot v3.1.9 更新内容如下： 新增：JbootController 新增 getParaToBigInteger()、getParaToBigDecimal() 等方法 新增：门户网关新增 hasException() 方法，用于判断目标地址是否可以正常访问 优化：升级 JFinal、jackson、HikariCP、Dubbo 等相关依赖到最新版本 优化：完善支持更多关于 druid 的数据源配置 优化：当未配置任何第三方日志组件的时候，自动使用 JDK 日志进行输出 优化：添加 JbootRedirectRender，防止 nginx -> jboot 跳转时的错误问题 优化：移除 @ValidatePara 注解 和 UrlParaValidate 验证拦截器 优化：移除 Jboot 的 @EnableCORS 注解，使用 JFinal 自带的来替代 优化：修改某些变量命名不直观的问题 优化：默认情况下完全禁用 Fastjson 的 autoType 功能 文档：添加 dubbo rpc 下的 restful 配置文档 文档：配置相关文档添加动态配置的相关描述 文档：数据库配置相关添加多数据源的相关描述 maven 依赖： <dependency> <groupId>io.jboot</groupId> <artifactId>jboot</artifactId> <version>3.2.1</version> </dependency> Hello World： @RequestMapping("/") public class HelloworldController extends JbootController { public void index(){ renderText("hello world"); } public static void main(String[] args){ JbootApplication.run(args); } }
2020-05-29

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

时间: 2025-12-12 大小: 211.28KB 下载: 54次
Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

时间: 2025-12-21 大小: 189MB 下载: 2次
Spring

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

时间: 2025-12-17 大小: 5MB 下载: 1次
Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能，例如代码缩略图，Python的插件，代码段等。还可自定义键绑定，菜单和工具栏。Sublime Text 的主要功能包括：拼写检查，书签，完整的 Python API ， Goto 功能，即时项目切换，多选择，多窗口等等。Sublime Text 是一个跨平台的编辑器，同时支持Windows、Linux、Mac OS X等操作系统。

时间: 2025-12-03 大小: 9.84MB 下载: 39次
热门标签
Kubernetes DeepSeek SpringBoot4 Nacos3 Service Mesh SpringCloud Gemini3 Jdk25 Docker OpenAi Redis HarmonyOS6 Rocky

欢迎您来访！

登录后，您将获得更多功能！
热门文章
联系我们

有任何问题或合作意向欢迎联系我们

Email: 99873273@qq.com

QQ: 99873273