· 「名人堂」开源项目核心贡献者 高洪涛 ·
本期名人堂很荣幸邀请到 Apache SkyWalking 和 Apache ShardingSphere 的核心贡献者高洪涛老师来分享自己的开源历程。
问题 1：您好，高洪涛老师！很荣幸有机会采访到您，先简单介绍一下您自己？
大家好，我从业近15年的时间了，目前在湾区的一家创业公司，Tetrate。公司主要的业务方向是为用户提供企业级的ServiceMesh服务，产品核心包含了Istio，Envoy和SkyWalking这三个主要的开源项目。
加入Tetreate之前是华为软件开发云技术专家，对云原生产品有丰富的设计、研发与实施经验。对分布式数据库、容器调度、微服务、ServicMesh等技术有深入的了解。
在开源领域，我目前是Apache SkyWalking和Apache ShardingShpere的PMC成员，也是这两个项目的早期参与者。对开源项目的管理、推广和社区运营有丰富的经验。
我不仅深入参与开源项目，同时也积极参与技术分享，曾在多个技术大会中做过交流，包括DTCC，ArchSummit, Top100，Oracle嘉年华等。在InfoQ，OSChina等多个媒体发表过文章。同时是《Apache SkyWalking实战》和《深入理解Istio》的联合作者。
问题 2：您之前在互联网与云计算行业10年以上的时间，为何考虑创业，创业后主要负责的工作是？
我是Apache SkyWalking社区的PMC成员，加入Tetrate主要是将SkyWalking引入公司的产品中。经过三年的时间，已经完美解决SkyWalking和Istio之间的结合。近年做了一系列相关的分享，包括服务指标，拓扑图和ondemand日志等有趣的功能。
近期主导 SkyWalking自研数据库-BanyanDB的研发和社区运营工作。BanyanDB是SkyWalking一个子项目。SkyWalking曾在存储层选型有很多抉择。最早选用HBase，这是一种传统的选择。众多以Dapper论文为基础的trace系统都会选择HBase或类似的存储引擎。之后我们全面转向了Elasticsearch，这是目前使用最为广泛的搜索引擎。SkyWalking利用现代搜索引擎的高扩展性来接受并存储大量可观测性数据，并利用它强大的搜索功能来实现快速的数据检索。
展开全文
BanyanDB的目标是在实现较高查询性能的基础上，竭尽所能提高数据的存储密度和吞吐量，达到较高的性价比。SkyWalking使用Elasticsearch所面临的最大问题是其性价比非常低，它需要大量的存储空间来获得较高的查询性能。我们希望BanyanDB在保持所需查询性能的基础上，能够最大程度的压缩数据。未来希望利用像S3等对象存储，来进一步提高数据的价值密度。
问题 3：是什么契机促使您加入Tetrate呢？
我之前在华为，主要的方向就是云平台，在可观测云领域中深耕了多年，对云原生可观测性有深入理解。同时是Apache SkyWalking社区早期的联合创始成员之一。我们社区是首款面向于企业级用户使用的开源可观测性平台，而且是首个由国人以纯社区的运营模式为基础，加入Apache 基金会的开源项目。也是在SkyWalking加入Apache 后，整个的基金会的中国项目呈现了蓬勃发展的态势。所以SkyWalking对于整个中国开源和Apache 基金会都是有重要意义的项目。
在要加入Tetrate的时候， Istio和ServiceMesh相关领域还处在萌芽的阶段。但我敏锐地观测到ServiceMesh是将会成为未来云计算的重要基础设施，就像当年的dubbo和nginx。近年发展，不仅互联网企业，甚至传统的企业用户也越来越喜欢ServiceMesh，希望采用ServiceMesh来实现系统现代化。
我们将SkyWalking和Istio进行了完美的融合。提供了不同层次的产品线。同时，这种融合也向用户展示了利用于开源社区为内核是可以提供有效商业化服务的。从而帮助企业用户解决他们所面临的服务管理、安全和观测性难题。
问题 4：在自研工作中曾遇到过哪些问题？又是如何解决的？
从0到1研发一款数据库，单纯从它的目标就知道挑战是非常巨大的。
首先，数据库系统经过多年的发展，特别是近15年NoSQL和NewSQL井喷式的发展。数据库领域必然会产生各种各样的新思想和观念。它们与旧的传统和理念激烈碰撞，导致质疑、反对，甚至愤怒弥漫在整个数据库领域内。
首先遇到的挑战就是质疑为何要构建一个自己的数据库，不直接采用目前市面上已有的数据库产品？为何不在前人基础上去构建？因为BanyanDB数据模型从分类上看，属于时序数据库，目前有众多类似数据库，那么BanyanDB独特之处是什么？
回应这个质疑其实非常简单：就是不合适。在以往多次演讲中，我都会分享RUM假说。其基本概念是用三角形约束来定义数据库的访问模式：写入、读取和存储空间。每种数据库都需要在三者之间取得平衡。目前市面上大部分的数据库都是在优化读取。但在APM领域，SkyWalking所面临的可观测性场景中，写入和存储空间的重要性比读取高得多。metrics的热读取一般是在近期，比如最近半个小时到三个小时之间。其历史数据往往逐步变冷而失去价值。logs和traces更是如此，甚至并不会实时的读取logs和traces。当然这里有一个假设是排除了离线日志分析场景，单纯是从运维角度看问题。大部分日志是不会被读取的，甚至是包含错误信息的日志。只有用户真正发现系统有问题，需要做debugging和profiling，才会去看logs和traces。他们才会希望从中发现更有价值的信息，进而定位致命故障和性能异常。所以如何更好的将数据存到磁盘上，提高单位空间内数据量，进而提高单位存储空间之中数据的价值，这是BanyanDB所考虑的。放眼整个APM和数据库领域，很难找到满足类似条件的数据库。这就是BanyanDB存在的价值。
另一个就是技术问题。并不是进行理论创新，而是对各种已有理论的可实现性进行合理评估。数据库发展多年，近年来新思想也异常活跃。如何从众多的技术中选择适合BanyanDB的，就成为面临的主要问题了。我们的设计目标非常简单：就是要化繁去简，把多余的东西从核心逻辑中去掉。我们需要研究候选技术的产生背景，判断该背景是不是要去面对的，这是非常有挑战的。另一个挑战点就是进行场景验证。SkyWalking的场景非常丰富。依托于强大的开源社区，可以接触到各种各样的 APM场景，这是研发通用数据库难以获取的优势。大部分新数据库的研发都是基于一种理论，在实践中慢慢磨合。而BanyanDB在研发过程中就积极与SkyWalking整个生态进行整合。虽然延长了研发周期，但可以更从容的解决数据库在真实环境中产生的问题。
所有开源社区，特别是纯社区运营的，最大难点在于贡献者的时间安排。目前有非常多的技术人员对开源、可观测性技术、数据库感兴趣，也很愿意参与进来。这就存在两个巨大的挑战：第一就是时间问题。贡献者都是有自己本职工作，如何利用有限的时间参与开源社区，是非常有挑战的。同时，项目管理者如何安排和规划任务难度也很大。第二，像SkyWalking落脚于比较小众的领域—APM。如何理解该领域的数据特点，是需要开发者耐心的。最后，就是数据库本身难度也比较高。了解数据库内部运行机制原理的潜在贡献者实际上并不多，这也限制了贡献者的数量。好在 SkyWalking和BanyanDB是开源的国际化社区。在国内和国际上都获得了很多反馈，包括北美、欧洲和印度的小伙伴也共同做建设。虽然时间跨度很大，但经过持续的累积，最终也能得到希望的结果。
问题 5：BanyanDB的核心产品以及产品特性是什么？为何能获得业内广泛关注和用户的高度好评？
BanyanDB作为SkyWalking的原生数据库，目前还处于高速研发的阶段。BanyanDB从理念上与目前主流数据库是有明显区别的。它不仅创新了存储结构，优化了分布式的拓扑方式，同时结合现代组件，共同构建了完整的针对于APM领域的数据库。
BanyanDB一直受到数据库APM领域的广泛关注。它不仅提供了完美解决可观性数据的模式和趋势，诞生过程也引人注目。我们社区人员主要擅长应用级的服务，鲜有触及数据库核心。之所以进入到数据库领域，主要有两个原因：
第一是我们对于数据层是非常的关注。项目早期使用HBase，因为Daper本身是基于Google的BigTable。当时可观测性开源领域项目还相对稚嫩，HBase被广泛使用。但它的吞吐量和响应时间不理想，运维难度高，消耗资源巨大，性价比低。SkyWalking也尝试过传统的关系型数据库，但随着以Lucene为底色的ElasticSearch诞生。在很长一段时间中，我们都在使用它来作为SkyWalking的核心存储。ElasticSearch第一解决Lucene写入困难更新慢的缺憾，适用于可观测性领域这种需要大量数据吞吐的场景。第二是其可靠的响应时间。它的索引结构对于即席查询非常友好，可以有效支撑logs，trace和metrics的查询。即使一些复杂的查询结构，如拓扑图，也可以凭借其索引快速响应查询请求。
随着ElasticSearch逐步在企业中的应用，会发现一些性能问题。它的消耗是非常巨大的，每天产生TB级，甚至于PB级的数据。这在一些大型企业中是非常常见的，而且ElasticSearch的维护非常困难。特别是众多公司将ElasticSearch定位在大数据或BI产品线，所使用ES的模式往往进行批量性的导入，然后半离线查询。这与SkyWalking实时写入查询模式存在一定冲突，使SkyWalking不能发挥ES的最佳性能。同时SkyWalking是运维工具，运维组在国内话语权一向比较低，获得可用资源会更少，更无法负担高配置的ES集群。虽然从功能角度看，ES是相对完美的方案，但是从性价比和实际落地效果看，ES面临的挑战依然巨大。
那能不能在此基础上做改变呢？其实是很困难的，一来ES内部是通过大内存结构把数据缓存起来，加速查询，且集群中只有leader节点可以进行写入。故其写入会有热点，且查询消耗很多内存资源。实际上，APM领域的应用只使用ES一少部分功能，促使我们去构建一个适用于SkyWalking的数据库。我在ShardingShpere项目中研究分布式数据库已有多年经验，并且开设了分布式领域的在线课程，但该课程主要面向于NewSQL，即关系型数据库在分布式领域的应用。我备课时无意中发现了 RUM假说。它实际是一种三角结构，角的顶端分别代表数据的写入、读取和存储占用。这种假说认为三个点之中如果优化其中两个点，必然对第三个点带来影响。比如在传统数据库中，往往会优化读取，然后在存储空间和写入吞吐中做一些平衡。有些高吞吐的数据库，可能会占用大量额外的存储空间。而空间利用率很高的数据库，它写入就会受影响。
APM价值是很低的。有时数据写入直到被删除，根本就不会被读取。可见这些数据的单位空间价值很低。如果利用假说中的三角关系，就可以将读取必要条件变成可选条件。从而使优化集中在写入和空间利用率上。这就是BanyanDB构建整个产品形态的底层逻辑。正因为其逻辑的特殊性，数据库行业很少有人去实践此类数据库。它的应用领域很明显是针对于APM的，这与数据库产品化的思路相违背。而APM领域很少有意愿去构建一款自用的数据库，因为目前该领域没有发展到深耕状态，所以BanyanDB是首创，它的关注度和参与热情较普通数据库高。
问题 6：BanyanDB可以解决哪些问题？什么场景适用于使用BanyanDB？
BanyanDB脱胎于SkyWalking社区，主要面向APM领域。RUM假说的哲学思想，就是利用RUM三角构造面向于特定领域的数据库。为什么很难使用通用数据库来达到同样的目的呢？
传统的应用领域很狭窄，基本围绕着关系模型来解决问题。过去的40年涌现出多种数据库模型。除了关系模型以外，也曾经出现过对象模型等。但关系型可以相对完美地去替代它们，达到一统江山的地位。目前大数据和AI时代产生的数据量是呈几何形增长的。硬件发展速度已经无法与这种趋势相匹配了，必须从数据库的底层逻辑去重新优化和构建。
除了BanyanDB，越来越多的数据库涌现出来。他们产生的背景来自不同领域。比如图数据库，其脱胎于我们的社交网络和web3.0发展。时序数据库是云原生可观测性的需求发展而来的。同样如此，BanyanDB的驱动就是SkyWalking APM。
适用的领域单一不代表它的功能也简单。其实上BanyanDB是一种多模的数据库。它除了支持时序数据存储以外，同时也支持键值对（Key-Value）这种无模式的数据存储。虽然BanyanDB主要处理的数据是一些时序和日志数据，但APM领域需要对元数据进行管理。这些数据如果用时序模型存储是不合适的，因为数据本身与时间并不相关。且在分布式下，数据的一致性要求比时序数据要高。面对这种需求，BanyanDB引入了基于Raft算法的数据存储。
如果使用BanyanDB在APM领域构建应用，无需使用额外的数据存储支持。它同时可以覆盖用户在该领域内对存储的全部需求。甚至相关的一些业务功能也可以使用BanyanDB实现。比如SkyWalking的定制化UI就是用BanyanDB来进行存储。这些数据会被很好地融合在一个库内，这是大部分数据库所不具备的。因为市面上混合多模数据库没有针对APM领域的优化，而APM领域却又是一个典型的需要混合多模的场景。BanyanDB在此场景下具有很大的优势。
问题 7：BanyanDB的下一步规划是什么？
BanyanDB还处于高速成长的阶段。虽然完成了单机节点的实现，但是离真正面向生产级的应用还有很长的路要走，未来主要在两个方向并行：
首先要推动它的分布式模式的设计与落地。分布式架构已经完成了很多的预研和测试，主要的一些方向已经确定。
BanyanDB不仅在集群内部可以做到数据的负载均衡和高可用。同时支持跨数据中心的数据复制。当然主要支持的方向是将一些叶子节点的数据汇集到中心节点，提供一个低延迟度的数据查询服务。是一种中心化只读数据报告的模式。
其次，同时推进BanyanDB的性能和稳定性测试。计划利用混动工程来快速验证数据库架构。同时，需要确认BanyanDB的吞吐量是否达到了设计目标。最后，我们最感兴趣的是进行对比测试。这些预计会在今年上半年逐步推出。
问题 8：如何理解国内开源生态链，有什么关于开源方向的意见和建议吗？
在聊国内的开源领域之前，作为Apache基金会项目的管理者，我先跟大家分享一下Apache基金会的创始理念。
最早，Apache基金会资金基础来自Apache服务器产生的可观收入。早期的项目来源主要是一些个人项目和被大公司淘汰的技术。原开发者认为这些技术还是比较有价值的，将它转移到开源基金会中。可以说开源社区所包含的大部分项目实际上在商业领域并不具备特别大的价值。只是随着时间延续，逐步进行了迭代，慢慢被更多人采用。从本质上来讲，不必支付费用，只要遵循开源项目的规则就可以使用它，甚至把它集成在商业产品中。免费和开放产生了相互叠加作用，这是如今开源的影响力达到繁荣状态的本质原因。
但是开源社区和其运营模式发展到今天，特别在我国已经产生了比较大的异化。很多开源项目背后都有商业公司的强力支持。从他们的开源贡献者和提交发布节奏上看，好多都是将公司内部已经完成交付产品，甚至在开发生命周期的产品暴露到开源领域。很明显他们希望在多个方面获得收益。
首先是打造技术影响力，吸引更多的开发者使用其产品。另外由于是开源的，从安全审批上可以做相关的规避。最后会产生一些附加利益，利于招聘和销售。开源产品可以提高团队和公司的声誉。好多公司都是利用开源来提高自己的声量，进行一些商业化的尝试。这是现在开源生态繁荣背后的底层逻辑。
这样的状态好吗？我觉得完全没有问题。一个领域，能有这么多人参与，必定能带来很多不一样的想法和思路。虽然最早的开源项目本身商业价值不高，但是随着其不断发展和开放逐渐带来了商业价值。同时开源项目带有知识共享属性。知识的碰撞与共享会产生非常积极的作用。这也是开源社区蓬勃发展的另一个原因。
唯一需要注意或者避免的是不应将所谓的开源项目紧紧的抓在自己手上。很多开源项目仅将公司一些产品进行了代码的开源，对一些设计的反馈和改进意见反应比较缓慢。甚至管理者大多数情况下都会置之不理，使这些“开源”项目成为他公司产品的镜像备份。或者项目管理者将公司内部人员充实在开源相关的核心位置，从而控制整体的走向和思路。这些并不符合开源的精神内核。在社区文化构建上，我们国内开源领域还有提升的空间。随着开源项目和参与者的增多，终究能够体会到开放才是整个开源的核心价值。目前越来越的项目，特别是新项目更注重开放性和社区生态的多样性。
现在谈论一下开源选题的问题。
许多想做开源的朋友都会问我关于开源选题的建议，那就是找一个你最感兴趣的选题。兴趣是一种内驱力。只有在这种内驱力的作用下，你才能全心全意的参与开源项目。因为做开源，需要投入很多的精力。如果没有内在支撑，开源项目的生命周期会非常短，一个成功的项目必须具备较强的生命力。
项目启动后，常见的问题是：前期没有人来贡献，也没有热度。这就是开源项目积累阶段。此时首先需要的就是降低项目的可参与门槛。项目的新手引导、原理解析、路线图和实际案例都是降低门槛的手段。潜在贡献者就可以理解项目脉络，逐步会参与进来。
关于社区交流语言的选择也是很重要的。整个Apache基金会的工作语言是英文，虽然SkyWalking大部分参与者都是中国人，但是也以英文交流为主。我们希望去拥抱整个世界，去集合全球资源共同打造最顶级的开源项目。如果你的目标也是如此，那么以英文作为工作语言就很必要了。
当项目有一定增长后，就要在社区内部协商和构建各种流程。包括新手引导、常见问题指引和发版流程等。要形成操作文档和手册，方便不同的贡献者来操作。要避免把固定的事情交给固定的人，人员贡献热情会随着时间有很大的变化。人员变化往往是不可预知的，有时也很难有工作交接。故文档化流程是非常必要的。
最后，谈一谈人员招募。我们一直在吸引新人来参与项目，特别是在校生。因为他们的热情比较高。虽然能力有限，但乐于学习。每年有各种夏令营活动，开源社区多参与有助于吸收更多的新人。人员永远是开源社区最重要的资产，而不是技术本身。技术是可以积累的，但热情只会被消耗。我们要持续吸收新人，永远对新知识抱有开放的心态，这也是做开源所必要的素质。
