baojinri commented on code in PR #161: URL: https://github.com/apache/horaedb-docs/pull/161#discussion_r1870968103
########## content/cn/blog/2024/review-coc-na.md: ########## @@ -0,0 +1,136 @@ +--- +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），但这个晚宴可不“简单”，不是传统的晚宴，社交属性更重些。场地内会有几个比较高的圆桌，大家在旁边拿完东西后就可以找感兴趣的人开聊。对于第一次参见这种会议的我来说，其实有是些蒙的，和一同去的同事默默站在一角观望可以插入的场子，但看着周边人群在慷慨激昂的谈论时，发现自己不能很轻松地加入：一是语言问题；二就是文化差异。 + +在转了几圈后，发现几个国人面孔，通过沟通知道了他们都来自苹果公司，苹果是这次的大赞助商，所以他们大概来了四五十人！只不过组比较多，所以很多人也是第一次见面。听他们说这种聚会形式在美国挺常见的，他们虽然在美已经多年，语言早已不再是什么问题，但碍于文化差异，他们也不能很轻松的融入进去。 + +通过交流，了解到苹果公司内很多基建都是基于 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/) 也类似的思路吧！打造生态前期投入肯定是巨大的，需要长期投入和耐心的过程，但对苹果、华为这种体量的公司，这种投入实际上是一种战略性资源配置，目的就是建立长期的技术竞争力。 Review Comment: 也是类似 ########## content/cn/blog/2024/review-coc-na.md: ########## @@ -0,0 +1,136 @@ +--- +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），但这个晚宴可不“简单”，不是传统的晚宴，社交属性更重些。场地内会有几个比较高的圆桌，大家在旁边拿完东西后就可以找感兴趣的人开聊。对于第一次参见这种会议的我来说，其实有是些蒙的，和一同去的同事默默站在一角观望可以插入的场子，但看着周边人群在慷慨激昂的谈论时，发现自己不能很轻松地加入：一是语言问题；二就是文化差异。 + +在转了几圈后，发现几个国人面孔，通过沟通知道了他们都来自苹果公司，苹果是这次的大赞助商，所以他们大概来了四五十人！只不过组比较多，所以很多人也是第一次见面。听他们说这种聚会形式在美国挺常见的，他们虽然在美已经多年，语言早已不再是什么问题，但碍于文化差异，他们也不能很轻松的融入进去。 + +通过交流，了解到苹果公司内很多基建都是基于 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/) 也类似的思路吧！打造生态前期投入肯定是巨大的，需要长期投入和耐心的过程，但对苹果、华为这种体量的公司，这种投入实际上是一种战略性资源配置，目的就是建立长期的技术竞争力。 + +在会场中，我也有幸见到了 [Database Internals](https://www.databass.dev/) 一书的作者 Alex Petrov（目前在苹果工作），给他简单介绍了下 HoraeDB，他的本能反应就是 Very cool！在国内我还真没遇到类似回答。 + +# 演讲介绍 + +接下来就介绍几个笔者印象比较深的演讲，由于没有演讲时的 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)），并取得显著提升。 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]
