jiacai2050 commented on code in PR #161: URL: https://github.com/apache/horaedb-docs/pull/161#discussion_r1865170206
########## content/cn/blog/2024/review-coc-na.md: ########## @@ -0,0 +1,134 @@ +--- +title: 2024 年 ApacheCon 北美之旅的收获与感悟 +date: 2024-11-22 +tags: + - community +--- + +[Apache HoraeDB](https://horaedb.apache.org/) 是 2023-12-11 加入 Apache 孵化器，由此拉开了我在 Apache 社区的成长探索之旅。作为一个历史悠久的基金会，Apache 旗下的软件可谓家喻户晓：Hadoop、Spark、Kafka 等等。 在这次 2024 年的 ApacheCon [北美大会](https://www.apachecon.com/)上，我有幸代表 HoraeDB 社区参加，终于有机会来近距离和来自世界各地的 Apache 项目的 PMC 们交流。这次经历不仅让我深入理解了 Apache 项目的核心价值与贡献，还深刻认识到开源社区如何驱动技术创新、促进开发者之间的协作与分享。 + +这次大会在丹佛的君悦大酒店举行，为期四天（2024-10-07 ~ 10），讨论涉及搜索、大数据、物联网、社区等多个方面，从现场来看，讲师比嘉宾还要多，除了 Keynote 分享是在一个大会场进行，其他的场子均在一个小房间里，每个房间外会有一个电子屏展示今日的议题。 + + + +# 文化差异 + +在介绍具体议题之前，我想先简单介绍下与会过程中感受到的中美间的文化差异，以飨读者。 + +和国内会议类似，第一天议程结束后有个晚宴（event reception），但这个晚宴可不“简单”，不是传统的晚宴，社交属性更重些。场地内会有几个比较高的圆桌，大家在旁边拿完东西后就可以找感兴趣的人开聊。对于第一次参见这种会议的我来说，其实有是些蒙的，和一同去的同事默默站在一角观望可以插入的场子，但看着周边人群在慷慨激昂的谈论时，发现根本无法加入：一是语言听不太懂；二是不知道聊啥。 + +来之前在国内英语也练了很久，在会场上交流技术问题还能凑合，但这种场合就捉襟见肘了。在转了几圈后，发现几个国人面孔的一桌，大着胆子上去打了个招呼：Hi, can I join you？刚要磕磕绊绊的介绍自己时，问了句：Can you speak Chinese? 对方笑道：肯定可以了！ + +后来发现他们都来自苹果公司，苹果是这次的大赞助商，所以他们大概来了四五十人！只不过组比较多，所以很多人也是第一次见面。听他们说这种聚会形式在美国挺常见的，他们虽然在美已经多年，语言早已不再是什么问题，但碍于文化差异，他们也不能很轻松的融入进去。 + +也是通过和他们聊才发现，苹果公司内很多基建都是基于 Apache 的项目构建，而且最近几年他们在开源上的力度也越来越大，印象较深的就是 Swift 语言，其中一个女士貌似是 Swift 的 team member，她看到我穿的是带有 Rust logo 的衣服，就说我应该尝试下 Swift，这两个语言设计理念类似，但 Swift 更简单，而且为了避免苹果一家独大，他们已经把 Swift 迁移到独立的 [GitHub 组织](https://github.com/swiftlang/)上去了，此外，Swift 也不仅仅是苹果平台的特定语言，他们在也花了很多时间来保证 Swift 也可以在 Linux/Windows 上完美的运行。 + +可以想到，苹果把 Swift 定位为通用语言，既可以为苹果生态服务，也是更长远的战略布局。通过通用化，苹果能够扩大 Swift 的生态影响力，吸引更多开发者进入其体系，同时为跨平台的未来做好准备。现在想想，华为的[仓颉语言](https://cangjie-lang.cn/) 也类似的思路吧！打造生态前期投入肯定是巨大的，需要长期投入和耐心的过程，但对苹果、华为这种体量的公司，这种投入实际上是一种战略性资源配置，目的就是建立长期的技术竞争力。 + +# 演讲介绍 + +接下来就介绍几个笔者印象比较深的演讲，由于存在语言问题，加上没有演讲的 PPT，因此下面的介绍是我根据关键词去搜索整理得到，仅供大家参考。 + +## Optimizing Apache HoraeDB for High-Cardinality Metrics at AntGroup + +这是我带来的演进，讲的就是 HoraeDB 重点解决的问题，以及对应思路和方法。核心一点就是通过 AP 领域的思路（剪枝、[BRIN](https://en.wikipedia.org/wiki/Block_Range_Index)）来解决高基数时间线的问题，细节可以参考本次分享的[PPT](https://downloads.apache.org/incubator/horaedb/slides/20241010-Optimizing%20Apache%20HoraeDB%20for%20High-Cardinality%20Metrics%20at%20AntGroup.pdf)。 + +目前的版本在实际运行中，我们也遇到了些新问题。目前的引擎在以时序分析为主的场景来说运行的会比较好，但在传统的时序告警领域工作的并不是很好，主要在于两点： + +1. 一次查询的代价太大，在查询引擎中采用了通用的 Arrow 格式，反而导致丢失了针对时序特点的优化 +2. 采用表作为基本数据组织方式过于严格，时序本来是一种弱 Schema 的场景，而提前定义好固定模式的表显然是一种“退步”，另外表作为资源管理单位，也限制了单机能够承载的表数量。 + +因此在后续的版本中，我们吸取了现在引擎（即目前的 Analytic Engine）的教训，打算重新设计一种引擎（称为：Metric Engine）来解决高基数的问题。 + +新引擎正在紧锣密鼓的开发中，感兴趣的读者可以参考[这里的 rfc](https://github.com/apache/horaedb/blob/main/docs/rfcs/20240827-metric-engine.md) 来了解设计思路。在后续的版本发布时，我们也会重点强调新引擎的开发进度。 + +## Blazingly-Fast: Introduction to Apache Fury Serialization + +演讲者是 Fury 项目的发起者 Shawn Yang，也是我的同事（哈哈）。如标题所说，Fury 定位的就是高效的序列化，已经在诸多 系统中被使用（参加 [Who is Using Apache Fury?](https://github.com/apache/fury/issues/1766)），并取得显著提升。 + +一直以为序列化是个已经解决的问题，了解了 Fury 后才了解到这个领域的问题。举个简单的例子，对于常见的 Protobuf 来说， 在序列化一个数组的 Message 时，在序列化时 Message 的元数据会序列化多次，但如果应用层能够保证每个字段都不会缺失，那么这样就是有些浪费的，在 Fury 中就可以 [schema consistent](https://fury.apache.org/docs/specification/fury_xlang_serialization_spec/#schema-consistent) 这种模式来避免这种冗余。 + +## [Making Apache Kafka even faster and more scalable](https://www.slideshare.net/slideshow/making-apache-kafka-even-faster-and-more-scalable/272645669#2) + +Kafka 是一种高吞吐量的分布式流处理平台，尽管十分流行，但近些年随着使用场景的复杂，挑战者也不少，比如： + +- 主打云原生的 Pulsar +- 金融级可靠性的 RocketMQ +- 强调低延迟的 RabbitMQ + +这个议题的嘉宾来自 [Instaclustr](https://www.instaclustr.com/)，提供托管的 Kafka 服务。他主要从两方面来讲述了对 Kafka 的改进： + +1. 使用 KRaft 替换 ZooKeeper，这个主要是为扩大分区数考虑，分区是 Kafka 里很重要一概念，是进行并发读写的基本单位，在嘉宾的测试中，基于 ZK 的版本最高可以达到八万个分区，而基于 KRaft 的版本可以达到近两百万的分区。细节可以参考：[Kafka Control Plane: ZooKeeper, KRaft, and Managing Data](https://developer.confluent.io/courses/architecture/control-plane/)。 +2. 分层存储（Tiered storage），冷热数据分离的标配，通过将访问低频的数据移动到 S3 上可以显著降低成本。[KIP-405](https://cwiki.apache.org/confluence/display/KAFKA/KIP-405%3A+Kafka+Tiered+Storage) 最早在 2020 年就提出来了，3.6.1(2023) 发布到期访问版，3.8.0(2024) 发布 V1 正式版。 + +## Tomcat 11 and Jakarta EE 11 + +虽然不写 Java 很多年了，但是谁能不喜欢这只 Tom 猫呢？ + + Review Comment: 必须在本地预览才行 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
