内容来源：2021 年 6 月 5 日，由 SegmentFault 思否主办的 2021 中国开发者生态峰会圆满落幕。会上，Apache 软件基金会董事，Tetrate.io 创始工程师，Apache SkyWalking 创始人吴晟发表了主题为《SkyWalking 与 Apache 软件基金会的那些事》的演讲。分享嘉宾：吴晟，Apache 软件基金会董事，Tetrate.io 创始工程师，Apache SkyWalking 创始人速记整理及发布：SegmentFault 思否编辑部我的内容会相对来说比较轻松一点，我们今天会讲一些 SkyWalking 整个项目从 2015 年到现在六七年的的时间里面所经历的一些事情，以及我们在过程中间做的选择。我来自于一家北美的公司 Tetrate，是一家做 Service mesh 的公司。我自己是 Apache 基金会的董事以及 Apache SkyWalking 的创始人。SkyWalking 实际上现在是 Apache 的顶级项目，应该是当前全球规模最大的开源 APM 系统。如果大家熟悉监控领域和应用性能管理领域的话，从 2000 年或者 98 年开始，这个领域从来没有一款软件是完全靠着开源生态或者以开源为背景的生态去构建起来，所有全球知名的 APM 软件都是商业化背景。所以 SkyWalking 最初并没有像今天看到的这么复杂，它其实只是为了解决很简单的问题，而开源和开源社区把它推到了今天这样的一个位置。今天的 SkyWalking 实际上已经非常非常的复杂，它涵盖了大家监控你所看到的日志、指标、分布式追踪、事件探查，以及所有的各种的日常常见的操作系统、容器，以及前端的一些架构。甚至有一些人还在做包括手机、微信小程序等等一系列技术栈的扩展，去探查各个平台的指标、性能数据以及前后观点式的性能表现，所以它会是非常非常庞大的状态。大家也会发现其中有大量的技术栈，包括像 Prometheus、OpenTelemetry、Zipkin、Filebeat、Fluentd，会有很多全球厂商的其他的生态系统。我们并不是从第一天开始自己来做所有东西，我们会和非常非常多的全球的厂家还有基金会的项目去做合作，这就是为什么项目能够走到今天。我们有很多的朋友，来自于全球其他厂商的朋友，去给我们相关的支持，去让事情对大家来说集成起来比较方便，使用起来也符合大家的习惯。这是我最近从系统上抓的一张图，项目是 15 年底的时候开源的，它有非常长的稳定期，没有多少人来参与项目，在 17 年 18 年的时候，项目贡献者的都是非常非常少。我们在 17 年底加入 Apache 基金会的时候，项目的贡献者加上我只有 20 多个。到今天，不算太完全的统计，将近有 500 个代码贡献者，而且不包含文档，不包含其他的宣传。SkyWalking 不管是哪家公司，从来没有过所谓的叫做社区运营的岗位，我们是靠着开发者自己，或者说靠着项目，靠着我们对开源生态的理解，去和大家去配合，去和全球的其他项目配合去完成项目的孵化和扩展。这是我们在SkyWalking 在 Apache 的官网去探到的全球的访问情况。不出意外的话，所有的 Apache 项目，包括 Apache 官网，中国绝对是统治级的访问量。不管在哪个基金会，中国一定是开源项目的最大的使用者，但是至少我们目前还不是这些项目最大的贡献者。对于 SkyWalking，对于整个 Apache 基金会、对于 CNCF 、Linux foundation，所有大家能想到的全球性的基金会，我们都还不是最主要的贡献者来源。但是大家会看到中国孵化的项目，是曾经连代码注释都是拿中文写的项目。如果你真的愿意去做全球化，你愿意以合理的方式去做全球化，那么你一样可以去收获全球的用户，这样你可以看到除了某一些断网的地区或者非洲几乎没有 IT 产业的地区之外，全球都有非常非常大的使用者。而且 SkyWalking 在中国、在北美、在印度、在东亚、东欧以及西欧地区都有不同的厂商，基于 SkyWalking 去从事他们的商业化的产品建设，比如说有英国的厂商、波兰的厂商，有在南美的开发者，他们都在做自己的商业化的事情，包括我自己在北美的公司。如果你用合理的方式运作开源，你再做一些适合于自己的思考，如果你的项目不是那种排他性的，你其实可以有的想象空间是非常非常大的，就像大家今天看到的，我们经常在说的 Linux 的操作系统，它的所有的经济利益不全是 Linux 的人去挣的，它得到的是更多的产业级别的支持，更多的企业，更多的不同的方向，但从事情中间得到正向的产业的循环，所以我希望分享这个给大家，大家会看见说每个月有 15000 个 session 在访问我们的系统，真正的访问量就更难去计算，因为所有的指标都是以 session 级别为标准去记。回到最初最早15年的时候，其实我们就在说开源项目到底怎么样，才是好的开源项目的起点。所有的开源项目，它如果只是为了开源，或者说你去做开源的想法，那事情往往是很难成功的。SkyWalking 也是一样，如果它只是为了解决问题，那它的问题是什么呢？在 10 年到 15 年期间，大家应该从最早的 Dubbo 的生态，从开始有 springcloud 的生态，从当年的 ESB SOA 开始，所有的应用从单体应用变成了合体应用。那么我们在当年遇到了样的问题呢？我们当年我还在给联通做项目，我们遇到问题是八个厂家做一个项目，你可以想象一下这个状态有多灾难，所有人都在指责说别人的系统不稳定造成整个分布系统不稳定，就像大家现在在组内去指责对方组的程序写的不好，这是一样的。但是当你变成八个厂家的时候，沟通会更难，因为公司内你还有老板可以拿出来拍板，现在你连拍板的机会都没有，所以当时在做 SkyWalking 的时候，开发者全都接受了一个训练，我们让大家知道，当你的分布系统出问题可能不是你的代码的问题，你的上游、下游、网络，中间的 esb 的组件都有成为任何一个短板。所以 SkyWalking 在最初只是为了解决这样很简单的问题。当时其实已经有两个在领域很有名的开源项目，Zipkin 和 Pinpoint，那么为什么我们决定要从头开始做？Zipkin 现在还在，大家可以去看，首先它功能很简单，它没有准备去做复杂的系统。它的设计是为了简单的功能准备的，这意味着它真的会变成我们现在正要做的事情，它只是 demo，不是可以大规模生产用的东西。而 Pinpoint 是韩国一家做搜索引擎的公司 NAVER 做的产品，而且它那时候用了当时很火的大数据。没有用的原因其实很简单，今天大家有很多的原因去对标 Pinpoint 和 SkyWalking，但是作为监控产品，如果你用了大数据，那么，你可能比目标业务系统更难稳定。因为 Hbase 是高度分布式的系统，请问你用了分布式系统来监控另外分布式体系到底谁先 crush，监控系统第一个就 crush 了。我们没有想着要去做世界级 apm，我们想至少我们能解决当前的问题，所以我们写了非常非常简单版本的 SkyWalking，大家现在在 GitHub 上面都可以去翻到最早的 1.0 的代码，非常非常简单，甚至那时候我们都尝试过使用 Hbase，我们看看它是怎么做的，我们用他们的模式来做会有多少问题？所以呢，Skywalking 在很长一段时间之内都是 testing project，我们在 GitHub 上挂着，没有任何的宣传活动，没有任何对外的接洽，仅仅是把代码弄在上面。甚至那时候 License 都是，那时候应该有一段时间是 GPLv3 的。我们的意识上来说，我们就没准备把它做为一个 community 去玩，我们更多的认为，反正我放了一个项目，并且有一定的保护作用，放了 GPLv3，大家发现从最早的 v1 到 3.2.6 花了两年半的时间。SkyWalking 在整个时间内都是 testing project。它没有任何的 kpi，它不完成任何指定的功能领域，它只是参加项目的人为了解决日常的问题，去贡献代码，能写就写点什么，能完成什么特性就完成什么特性，更多的是娱乐性的工作。或者说它是一个测试，它不是测试的技术，它是测试在大家脑子里面的一些想法，看它们是不是可以落地。3.2.6 为什么是 3.2.6，因为它是 3.0 的最后一个版本。以及 3.2.6 是我第一次站到台上去，在 GOPS 全球运维大会，我第一次站在台上去讲：有这样一个项目，它要完成什么样的功能，它能够帮大家解决什么样的问题，它是 Apache 2.0 开源的项目。这是第一次，我们把它作为真正的开源项目，让自己作为真正开源项目参加者去看项目。而开源出来之后，实际上大家会发现，比如说从初始适用的用户都开始快速提高，但是大家的反馈更多的是：哎呀，你还不完备，这个事情你做不到。因为做监控系统，上线是非常非常困难的。用户很难把他自己的身家性命压在不稳定的监控系统上，他所有的数据都是来自这个监控系统，虽然你不承载任何商业数据，但是你如果黑掉，等于用户的整个生产系统就黑掉了，这是非常危险的一件事情，SkyWalking 在非常长的一段时间之内是没有生产可用，包括 3.2.6，其实一直以来就没有在完整的生产环境运行，更多情况下是在准时产和测试环境下运行，或者在压缩环境下运行。更多的把它当做工具而不是 apm 平台在用。起步阶段我们希望去扩大社区，我们有两个选择，Apache 或是 CNCF。我那时候已经去了华为，所以从理论上来说 CNCF 这条道路是通着的，如果大家不熟悉 Foundation 的区别的话，其实 CNCF 会更像厂家驱动，商业的气息会更浓。他需要厂家的干预，他需要厂家出资或是出人力去保障。而项目会更多的挂着企业的 logo，而当年的 SkyWalking 是个人项目，它并诞生于华为，因为我们是在业余的时候做的。它从头到尾就没有把 ip 归属在任何公司名下，自然也没有办法很简单的转移给所谓的华为，让华为去走 CNCF 的道路。大家如果去搜 CNCF 新项目的 proposal，其实会找到 SkyWalking，因为我们曾经申请过，而且 CNCF 的 coo Kris 他其实也邀请过我们去做 presentation，但是我们最后没有选择去走很长线的流程，因为实在是太忙了。而且对于项目来说，在当时我们更关心的是项目能不能有更多人参与。至于是不是有那么多人宣传项目，对于我们来说并不是那么重要，因为自始至终，这也不是 KPI 项目，因为没有人考核。即使我们当年在华为，也不是考核制的，跟公司没有直接的关系，不是说你要有多少贡献者，你要多少 star 公司好像才考核你，今天才有奖金。这个事跟 SkyWalking 向来没有太大的关系，而且我们选择 Apache ，有一个很方便的原因是因为 Apache 需要的是 mentor，后面会讲到，刚好我周围的朋友，一个在澳大利亚，一个在华为，一个在上海。我们可以很快速的找到三位 Apache member 成为 SkyWalking 的导师进 Apache 孵化器，我们当时在进 Apache 孵化器之前就做了调整，从 GPLv3 改到了 Apache。改的原因其实有两点，这个原因并不是 Apache 触发的，原因来自于阿里，阿里的团队联系到我们，说他们想和我们去合作共建一部分功能。在当时很早期的时候，其实一个大事情能够出开发者已经是很少见的事情。但是他们说有顾虑你这个东西不能是 GPLv3 的，不然我在公司会报不过去，其实当时是很简单的原因，我们认为只要有更多人参与，无所谓它是不是 GLPv3，谁可以把它的商业化做得最好，谁可以拿它去挣钱，我们是站在公平的角度上去干这件事情的。我们当时很快速的在社区内做了决议，把 GPLv3 改成了 Apache v2。今天我们站在更严谨的层面上来看的话，其实 v2 给了大家的是，更好的做商业分发的机会，比如说更多的产品在包含 SkyWalking 做二次公放，大家今天去看到很多的私有云平台、很多的产品里面都会原生包含 SkyWalking 的全部或者二次的分发版本。这非常常见，可能大家在非常非常多的开源项目都会看见部分或者全部，这也为我们之后去做跨组织的协作做了很好的基础。但当我们真正去踏入 Foundation 的时候，我们会发现中间是有非常大的 gap。在很长一段时间，开源对于我来说是娱乐。但是当我把项目带进 Apache 之后，我更多的像职业的开源开发者。与此同时你会发现你自己需要处在不同的角色上，当我代表 Apache 来发言，当我在 Apache 里面说任何话的时候，不能是商业的，它是要追求软件项目本身的质量，安全和迭代性未来的发展，也许在我心中有一条怎么挣钱的路，但那不能放在项目层面上。所以你后来你会发现，你会受到各种约束，这也是 Foundation 带给大家的，它给你的非常好的名头，觉得你很有名，你是 Apache 基金会的项目，但同时也会给你更多的约束，你不能不限制的去使用在 Apache 基金会的 branding，你不能无限制无休止的没有编辑的去使用这个知名的商标权，因为从 Apache 基金会并不想处理。Apache 基金会有 350 个以上的点击项目。在全球，基本上大家所有用到的软件的前台，后台某些组件一定来自于 Apache 软件基金会。但是同时，Apache 软件基金会一年的运作成本只有不到 160 万美元，而且这些钱几乎没有一分钱是以工资的名义发给 Apache 软件基金会的成员，所有人都是在以某种逻辑干活，你做了某个项目，也许是因为爱好，或者是写书、做培训，你有自己的逻辑，这让你在基金会里面的活动是会有利益的。当然你们会不会有爱好？会。但是爱好的参与者他一定是相对来说低强度，比如说他每周的时间很难超过五个小时，因为超过五个小时就相当于他要浪费一天的时间，而这个对绝大多数人来说是不可能的，特别很多人本来就要上六天班，再来五个小时，这不太可能。而绝大多数我们看到的中国的志愿贡献者是什么样子呢？他虽然下班比较晚，但是他对这个事情有兴趣，他觉得要贡献点东西，所以在 SkyWalking 提交的邮件中，经常会发现有人凌晨两点钟凌晨三点钟提 pull request，这个叫爱好。如果你面临一个职业开发者，他绝对不会这样，SkyWalking 有很多的职业开发者，我们晚上看到的职业开发者一定是美国、南美、阿根廷、巴西的，因为他们的晚上是正常工作时间，这个是职业开发者。面临不同的人，要知道他们喜好是不一样的。大家知道基金会有 22 年历史，最早是 98 年 99 年，基金会是相对来说大家认为比较老古董的基金会，事情讨论的会很慢，因为它都是异步的，大家通过邮件所有事情都要等 72 个小时，因为它为了让全球所有的人能看见并且要绕过周末，就变成了要三天。任何的决议，任何很小的事情，只要上升到决议层面上，就是超长时间的等待。基金会也有好多东西大家觉得不习惯，我们一直在说 Apache 基金会，那么到底什么是Apache 基金会？这里其实是 Apache 官方的解释，对于这三句话每个人心里面都有自己的解释。有些人是商业逻辑的解释，有些人是对于知名度对利益的追逐视角下的解释，有些是对于软件开发，对于 coding 这件事情的热爱，有些人有帮助他人的想法，有些人是想减少他人的负担，很多很多，每个人的想法都不一样。基金会就是多元化的，出发点是不同的，不要用你自己的出发点去随意揣测对方为什么要干这件事情，他的解释很有可能完全出乎你的意料。因为有一些人真的是为了爱好在干活，比如说我们见过有些东欧的一些地方的很年轻的，16 岁 17 岁的工程师，他会为了自己 20 岁以后创业的理想去参加项目，去长年的开发一个可能在非常长的时间内都没有两个人在用的功能。SkyWalking 有个子项目是东欧人开发的，是把你所有的监控数据反向的导到 ide 里面，就当你看到代码的时候，它能告诉你这行代码在生产环境里面的系统指标是什么样子的，而这个东西目前没有任何商业场景，但是他已经在事情上面做了将近两年的时间，他很年轻，他可能在放长线，他认为这对他以后不管是拿这个事情创业，还是拿这种精力去为自己准备创业都有帮助。而这个对于像我职业开发者来说，我认为是很不划算的事情，我的时间不应该拿去做没有商业利益的、长期的、高复杂度的事情，它代码量非常大。这是一个简单的例子，是想告诉大家，你参与进去的时候，你要保持相对比较谦虚的心态，更多的是要去问。同时大家要知道在当别人问你的时候，他不一定是反对你，他更多的是希望你更加如实的描述这种情况。我们今年也看到了好几个中国本土的项目捐赠给 Apache 孵化器，这中间我们就发现了很多问题。疑问经常会被中文的环境理解成质疑，因为中国的习惯是我们所有的事情都是先讨论好的，当我发公开的事情出来的时候，就代表决议已经形成，没有人会在公开场合说到英文的一个词，就是 argue，argue 翻译成中文基本上就是吵架这个概念。在整个文化环境里面，你需要能够有一定的耐受力，当你去合作的人跟你不是一个文化的时候，你要怎么坚持住。所以刚才说的那些多元化的事情，它保证的同样也是多元化的状态，它要保证厂商都出力，比如说，你的项目里面不能是由单个厂家来进行控制，尤其是顶级项目，它毕竟是多元的，不管是从性别、地域、肤色、年龄，各方面都要是多元的，它的代码要值得信任，不能有恶意的程序故意被埋在里面。比如说，我们能在国内看到有一些项目居然在用户使用开源版本的时候，居然在收集用户的部署信息。他居然能够知道这个项目在客户线上开源用户部署了多少分，如果这是商业合同的副产品，我觉得没有问题，但是如果你对开源用户也在收取信息，那实际上是非常危险的举动，这种情况在有些国家，有些地域，它甚至涉嫌违法，因为你在盗取用户的隐私数据。安全更多的是既有代码本身可获取安全，也就是说，一旦代码交付给你，我是不可撤回的。另外也有安全 security 这个层面，因为他开放了源码，开放了所有的版权给你，你可以更快的去修复安全漏洞，甚至你自己打 patch ，这也是很常见的事情。那 community over code 其实早上俊平也说了，所有人在讲 Apache 文化的时候都会讲这事。这句话其实每个人会有不一样的理解，但是最后有一点大家一定是共识的：人是最重要的。所以你怎么样让项目做到真正的透明，让大家愿意花时间来参与这个项目，大家相信你或者相信项目都好。一个简单的结论：在 ASF 和 CNCF 之间，如果你要做厂家主力，要快速进行商业 marketing，这里不存在情绪色彩（因为我们公司自己也在 CNCF 里面做，比如我们公司很多人在做 Envoy，因为做 Service Mesh，使用 Envoy、istio 甚至单独厂商不够的开源项目），不是说 ASF 比 CNCF 好，至少从我个人角度，我不认为这两者有任何的可比性，这是完全不同的运作模型。你需要去做正常的选择，但是你要知道它的差别在哪，ASF 一定不是利益先行，它一定是开发者先行人先行，怎么能够团结起来是最主要的，而 CNCF 是厂家的利益高于一切。我要以 vendor 为背景，CNCF 的项目，它要求的 diversity，也要求diversity 的多元化，它要求至少有三个厂家在参与，它并不要求说你要来自于很多地方的开发者，它很在乎你是哪家公司，所以在和 CNCF 签 CLA 的时候，你要说你是哪家公司的，你签的的邮箱，基本上还是公司的邮箱，公司要附属的一起签 CCLA。在选完基金会之后，其实我们会有长期的运作项目的过程，里面当然有非常非常多的故事，非常非常多的痛苦也好或者是成功的经验也好，但是我们去比较了非常多，因为我自己也参加过中国的很多开源项目，从 Echarts、ShardingSphere、APISIX、DolphinScheduler 这些 Apache 项目，或者像 CNCF 的包括 OpenTracing、zipkin，我其实都有在这些项目里面。我们能看到的，不管是中国和国外，你作为项目的 leader 或者项目的核心团队的成员，你要去保证你能够做到这些事情，虽然做到不一定能成功，但是你没有做到，就会对你的项目、对你的社区伤害非常大。开放是很简单能够说出来的词，但是当你的其他核心人员都不来自你的公司，不和你共享商业利益的时候，你怎么能够相信他们的决策？以及怎么样选择那些你可以相信的人？相信是双向的。你越相信他，他给你带来的迭代速度，他给你带来的特性能力就会越强，他会逐步深入。而如果你所有东西都在自己手上掌握着，那恐怕你的时间投入，就是项目的极限。SkyWalking 现在应该有 80% 以上的代码都不是我写的，我不了解详细情况，更多的是别人问起来我都是照着文档来，因为我已经不知道他们把项目改成什么样子了。我知道大体是什么样，我知道数据流是什么样的，但这就是极限了，而且这是在我在作为职业开发者的情况下。如果你不是百分百全职，估计你理解的东西就更少。远程的模式其实变相的说就是异步的模式，这在中国很多工程师心里面也是永远的痛，你问了问题发现没人鸟你，别人回答你的时候，已经几个小时过去，中国工程师很喜欢问句子的时候问半句问一句，这个行不行，行又怎样，不行又怎样，下面有个人回不行，好，这一天就过去了。这不是废话吗，你要掌握一些最基本的远程工作的技巧。以及当大家像我这样工作的时候，因为我自己的公司在美国，我们的工程师从最东的新西兰日本市区到最西的梅西市区，几乎每市区都有超过五个工程师。我们公司的所有的产品都是在异步的情况下完成，我们几乎没有公司级别的同步型会议。这就是我们平常所面临的情况，你会想象在一家公司去 Run Open Source Community，这些东西你必须会，不然公司的工作都没法做。我们去做Google docs的评审，那人家就撇了一根Google docs给你，你有赞同的，有不赞同的，有想改进的，或者你觉得对方整个从头就想错了，那你怎么样把自己的意愿尽可能一次用文字表达清楚，这实际上才是 remote 模式的意义。去年疫情的时候，我们在中国看到了很多很搞笑的事情。所有人被迫在家上班，在不停的 check 进度，不停的同步进展，领导就想知道你到底有没有出去开小差。像我们这样的公司，我们领导会在早上十点钟，给你发个邮件申请说，我一小时后给你开个会行不行，我可以回答说不行，我现在下去带孩子玩一会，要么我们晚上的时候再开会，要么你给我发个邮件用文字跟我说，是不是很着急？很着急的话你等我两个小时，等到下午一点的时候我们再聊。整个文化是从上到下，我下面的工程师也可以这么跟我说话，他说我现在没有空闲，在带孩子或是在接媳妇，我经常下午四点钟给我们黑龙江同事发微信说你在吗？他回答说我在接我媳妇，我说那到时候再说，然后我去补一封邮件给他。如果你要去把 open source 做到那种状态，你必须要能接受这种工作模式，你要学会让大家能够高速运转。因为中国的微信文化、QQ 文化、实时通讯文化最大的问题就是被联系的人在频繁地被打断。大家觉得自己都在最高效的状态运行，但是结论并不高效，因为人在不停的被打断。这个模式，你要去理解，你要真的能接受，你要能活在状态里面，你才能和全球的社区集成。SkyWalking 有一个 Node.js 和 Python 的探针，这两个探针都来自于一个东欧公司在南美的工程师，我们和他们能进行实施通讯的时间只有一个小时，晚上九点到晚上十点，如果这件事情需要被实时沟通，必须在这一个小时之内做完，但是很有可能他不在线，或者我不在线，所有的事情都是在线上完成。我到现在都不知道那位工程师长什么样子，我没有做过一次视频会议，所有的东西都是文字。当你需要和别人写作，你要知道别人期望你的状态，因为他不希望被你拽着，因为你不是他领导，你又不给他发工资，干嘛你天天要拽着他，不就是贡献一行代码吗？犯得上吗？这就是你在做 remote 的时候，你要去解决的实质的问题。而下面更多的叫做什么？我们在社区里面很多时候叫做善意独裁，你尝试去理解所有东西，你所有的代码必须要符合你的习惯，你要去做自己的决策，或者里面有个小团体来做决策，或者是其他任何类似的事情，这是非常伤人的，当大家经历过一次之后，以后的决定再也不理你，因为反正你决策的时候也不带别人。这个事是有差别的，我举办了公共的会议，我举办了公共的邮件列表，但是你没有反馈，所以我才会这么做，这跟我在线下做了决议才通知你，给别人的感受是完全不同的。你可以不参加，你可以默认通过，你可以无视，你可以后面再来挑战，你至少给了人家追溯的机会，人家知道你当年为什么去做这个决策。往往大家反对的不是你的决策本身，而是反对了你的决策列条。你的事情没有开放，没有说我今天要干这个事情，是因为 abcd 等原因，这是大家要注意的。最后一条，中国人最难做的 be remote，就是别人不同意你，这是中国工程师最难解决的问题。英语文化里有句话叫 agree to disagree，你要同意一些不同的意见，大家可以以他的诉求去干活，有一些方向他可以先去探路。不一定在决策的时候，所有人举手表决必须全票通过，缺席投票的情况很常见。在做这件事情的时候，你能不能做到这一点，作为社区的 leader 能不能容忍这一点非常重要。而你的软件技术能不能在这种环境下活着，比如说有一波团体通过了相对来说不太好的方案，那它会不会对你整个生态系统造成毁灭性的打击，可能你下一个版本功能完全就废掉了，那你的软件质量我们能保证，不管是你的自动化测试、混乱测试、压力测试、全自动的测试能不能保证件事情不要发生，能不能在前期通过理论证明、数据证明、实验性的测试能够得到结论，说你不好，我反对你这件事情是有数据依据的。而不是说以我的经验就不好，你的经验不行，中国人最爱说的是：我们公司有这么大流量，你没有，所以这事不行。这样你在开源里面，就没人跟你再聊技术方案，因为你根本就没有把别人的话当回事。也许流量在1000万的情况下不好使是真的，但是在10万的情况下好使，很多系统都是这样，你要理解到底有多少人要面临1000万的流量。就好像我们之前，我们代表了很多双十一的方案在聊，但是有多少公司需要双十一？阿里那样的公司是很少的，你方案做的很复杂，但它有没有用？这是很严重的问题。这个是孵化的流程，我不细讲了，如果你对 Apache 孵化感兴趣，核心的点就是你要找到三个 mentor，说白了，孵化器、基金会，这些东西都是社交游戏，你能找到人，你能说服他们，用钱说服或是用人情说服，反正你自己想办法，不管什么都是社交能力。你能搞定，这事就能干。那么在 Apache 基金会，你会有非常非常多的 level ，但这只是所谓的 level，任何人在任何级别并不代表你比其他人有更多的权利，而往往是更多的义务，越往上走，你要干的活越多。其实权力都没什么，唯一的区别从 contributer 到 communitier，你的变化是可以直接向库里面提交代码。但是很多现在主流的开源软件，就比如说我自己，现在都不能向 SkyWalking 直接提交代码。如果我们没有经过其他 pmc 或者 review，我的代码也进不去。后面的内容是我们希望让大家知道，在中国的 Open Source 的环境里面，大家常见的几个问题。这是我这么些年，在两边都感受了开源社区之后我认为的最大的痛。中国开发者对于开源项目的 maintainer 提了无限高的要求，高到离谱，高到客户提的要求都没有我们提的离谱。比如说中国开发者说文档写的不好，源代码都给你了，你管我写的好不好？你想用就用，不想用就不用了，我没有收你钱。如果项目在很早期的时候，你想去找一些种子的开发者，这是你自己和对方对赌，你在赌对方的项目好用，对方在赌你会认他这个项目。但是随着项目的成熟，不会有这个过程。如果大家去翻所有中国原生的 Apache 的顶级项目，我可以很负责任的说，SkyWalking 一定是社区环境、回答问题的态度最不好的。因为最常见的那句话就是回去读文档，回去读代码，这是你问到的绝大部分问题的回答。为什么会出现这种情况？因为这是不对等的，我并没有为你提供商业服务，为什么我要提供对等的能力？换句话说 SkyWalking 看中的是那些能够自己动手的开发人员，他们才是社区的价值，你能为社区贡献一行代码，那我花十分钟和你聊是值得的。如果你是在现场部署的时候出了问题，那我一点都不想关心，因为我部署的时候没有问题。有很多人在社区说，这个事很着急，生产上出了问题，生产出了问题和我有什么关系？我为什么要花那么多精力在晚上九点钟帮你去看堆栈，我疯了吗？我看会电视不好吗？所以这是大家在逻辑里经常对中国的项目提出的一些不切实际的希望，中国的开源软件作者每天就会抱怨，我好累，因为你也惯着他，基本上就是一个想被惯着，一个愿意惯着。第二点，时间。所谓的我没时间，是我在 996 我在 997 或者更多。但如果大家平静下来想一下两件事：第一件事，有多少工人是真正能够 996、997 干活的？其实并没有。绝大部分晚上大家都在吃饭、玩手游、楼下健身房，到时间打卡走，或者说晚上在干活，早上十二点回来，其实一天还是只干了八个小时。因为正常来说，为什么西方的 it 公司，我们会说我跟你签的合同是八小时，我今天不想干活就不干，为什么？It 工程师是写程序，不是你要求加班他就能写得出来的。他脑子不好写程序，后面有三个程序员帮他填空，全是 bug ，还不如别写。基础设施软件更是如此，你的那些埋进去的隐藏的 bug 是毁灭性的的，你写了三分钟的程序，对方可能三个月都调不出 bug。如果他是一个这样的人，你可以认为，他不是开源软件的从业者，我并不是说这样的人不存在。开源文化并不是要说服所有的人，不是告诉所有人开源现在很热，所以你要去开源。不是所有的人都会为此买单。就像 Apache 经常说的一句话，Community Over Code，并不适合所有的开源项目，而且不适应这件事并不是错的，很多不遵守 Apache Way 的事情都成功了，Linux 操作系统就是典型中的典型，所以不要把它当绝对的标准。最后，你在做项目的时候，也要去连接所有你可以用的资源。工程师、生态系统、其他的项目的玩家，以及各种 Global 的 vendor。你需要从个人关系，社交能力到你的合作的项目，同一个基金会的、跨基金会的、别人公司的，或者职业的玩家们，这些职业的玩家们会在你的宣传、以后的推广里面起到举足轻重的作用，以及那样一些背靠着你做商业化的厂家，他们给你投入的职业开发者。哪一个在不同的阶段都会被需要，他们没有好与坏，钱是好事也不是好事，取决于你怎么样去用它，你怎么样去散发社区的结构，每一个社区、每一个套路，都有自己的减法。其实我们去回顾一下六年的时间，我们会说：耐心。大家很多时候看到今天的 SkyWalking，我可以只放前三页，我可以说 SkyWalking 多么厉害。我还可以做三十页的 ppt 告诉这项目多么厉害，有多大的部署、多大的环境，我可以讲一下午，但是你要知道的是，其实第一天它啥也没有，而你背靠的是全世界最大的开发者。SkyWalking 90% 以上的功能都有中国工程师的参与，而他的用户遍布全球，而大量的中国工程师在开源里写的代码，被西方的工程师认为是太复杂的功能，这是他们认为的在异步环境下不可能完成的事。而中国很多工程师是依靠自己的能力完成工作，所以我并不认为中国工程师缺少开源的能力，但是他缺少的是正确的协作方法。我们有大量的事情都很着急，比如说 SkyWalking有很多的功能，是在两三年前吹出去的牛，我们今天才能得到结果，不知道大家有没有注意到，我最早的一篇 ppt 上写的一句话，SkyWalking 在今天，在上个月发布的 8.5 的版本，才刚刚完成了我们在五年前吹的牛，才把那些功能真正的变成代码可用的状态，而这个过程用了六年的时间，用了 500 位工程师，以及无数的测试，我们都不知道全球有多少人测试过这个程序。所以要有耐心，同样，在完成了六年前的事情之后，我会发现，原来我们六年前想的事情是整个 landscape ，我们在今天能看到的 landscape 里面，我们只完成了 50%，我们甚至也许还需要一个六年才能把我们今天想到的东西做完，这就是开源，我们的 Landscape 会越来越大，东西会越做越深，SkyWalking 从一个 java 探针，做到了全语言探针，做到了 service mesh，现在要去接操作系统，我们要自己做 database，我们要去接其他的采集软件，我们要去接其他的协议，会发现事情会越来越多。最后，我们会在下个月和下下个月回 ApacheCon 的活动，当然今年因为疫情的原因，我们还是会在线上来做，最后一届 ApacheCon 在线下办是在拉斯维加斯，第 21 届的时候就开始疫情了，第 22 届的时候我们第一次把 ApacheCon Asia 带到了中国，因为通过 17 年到 21 年四年的努力，中国终于有了足够多的 Apache member，这能够让 Apache 基金会相信可以去办一场属于中国、属于亚洲的 ApacheCon。我们也希望明年，在疫情更好的情况下，我们能让 Apache 通过第一次把 ApacheCon Asia 带到中国的某座城市去举办一些线下活动的决议。当然今年其实已经很好了，因为我们的 ApacheCon Asia 70%-80% 的 section 都已经可以使用中文，这是 ApacheCon Asia 带给我们的好处，因为中国的 Apache member 几乎覆盖了整个会议所有的 track chair，他们有更多的话语权，我们能更好的通过 ApacheCon 的整个筛选，这是我们能够带来给大家的，以后我们希望更多的工程师能够从 ApacheCon Asia 走到全球的 ApacheCon。今年 ApacheCon 的全球也是北美时区的，像监控的主题，基本上不管是中国的工程师还是国外的工程师都会使用 SkyWalking 相关的主题，我们也希望更多中国的项目能够走出去，能够用英语去 share 更多的主题。因为我自己在国外网络的时间比较长，这个是我的 Twitter，我会在上面的时间会比国内的平台会多一些，希望大家去聊一些，开源、SkyWalking，或者是 foundation 的一些文化，大家可以通过 Twitter 来找到我。谢谢大家。

很开心在这么冷的天和大家相聚在熟悉的 3W 咖啡聊大数据，感谢北京小伙伴踩着冰渣子来参加本场大数据为主题的 D-Day 活动。此次沙龙由 SegmentFault 家 Adele 主持，这一次选择了一个相对陌生的主题，但仍然吸引了很多对大数据感兴趣的观众，不少业内人士也纷纷赶到现场向大咖提问。Adele 简单介绍了 SegmentFault 的成长历程、行业愿景，产品特性，以及我们举办 D-Day 线下技术沙龙的愿景——让当地的开发者，开发者和大牛之间有面对面的交流机会的愿景后，马上进入分享环节。现场回顾第一位分享嘉宾是个推技术总监袁凯，分享的议题是《个推 Spark 应用与实践》，主要内容包括 Spark 简介，为什么选择 Spark，以及 Spark 在个推的应用实践：个推数据处理架构Spark Streaming 部署情况应用 Spark 的业务举例Spark Streaming 实现热力图第二位嘉宾是 @蓝海讯通OneAPM 大数据架构师刘麒贇，刘老师分享的议题是《大数据实时分析利器 Druid 的应用》。不光讲了选择 Druid 的背景，Druid 的基本介绍，以及对 Durid 的展望，还举例说明了 OneAPM 目前基于 Druid 的应用：利用 Druid 存储查询 Saas 数据OneAPM Druid 集群概况、集群拓扑OneAPM 金字塔结构的 Druid DateSourcesOneAPM Druid 集群监控方案中场休息结束后，接下来为大家分享的嘉宾是 @友盟 数据平台架构师展一楠，议题为《友盟 Spark 和 Elasticsearch 实践》。简单介绍什么是 Elasticsearch，Es的优点，局限，友盟 Es 使用情况后，展老师还结合友盟实例进行分析，包括：友盟 Hadoop & Spark 使用情况友盟使用 Spark 的一点不太明显的原因：函数式编程Spark 与 Es 在技术上结合解决的问题使用搜索引擎后，可能是给自己挖坑本场最后一位分享的嘉宾是小米公司研发架构师，负责小米广告平台的架构和数据的欧阳辰，这一次分享议题是《小米大数据技术小实践》，关键词为小米、大数据、技术小实践，比如：小米大数据技术框架、大数据应用为何青睐 HBase，HBase 在小米的改进，如何从 MyAQL 平滑迁移到 HBase小米广告的实时统计圆桌环节四位嘉宾演讲结束后是圆桌环节，本次圆桌由小米公司研发架构师欧阳辰主持，现场来了很多专业的观众，就平台架构选型及个人使用过程的疑问和嘉宾们进行讨论交流。圆桌结束后有些听众意犹未尽，纷纷找嘉宾老师私聊。此次 D-Day 足以见开发者们对大数据这一前沿领域技术的兴趣。后期 SegmentFault D-Day 会对每年前沿技术保持关注，为大家带来更多有趣的技术交流活动。本场 D-Day 结束，马上就要 12 月了，希望大家带着 D-Day 上 get 的新知识，进入全新的一个月。干货已出↓↓↓现场干货整理嘉宾 Slides：袁凯《个推Spark应用实践》刘麒贇《大数据实时分析利器Druid的应用》展一楠《友盟Spark和Elasticsearch实践》欧阳辰《小米大数据的技术小实践》嘉宾现场速记：袁凯《个推Spark应用实践》刘麒贇《大数据实时分析利器Druid的应用》展一楠《友盟Spark和Elasticsearch实践》欧阳辰《小米大数据的技术小实践》

一、hadoop下载，使用2.6.5版本http://hadoop.apache.org/releases.htmltar -zxvf hadoop-2.6.5.tar.gz笔者的路径是/root/Downloads/hadoop-2.6.5二、Hadoop的配置1、修改文件/root/Downloads/hadoop-2.6.5/etc/hadoop/hadoop-env.shexport JAVA_HOME=/root/Downloads/jdk1.8.0_1722、修改/etc/hadoop/core-site.xml 文件<configuration> <property> <name>hadoop.tmp.dir</name> <value>file:/usr/local/hadoop/tmp</value> <description>Abase for other temporary directories.</description> </property> <property> <name>fs.defaultFS</name> <value>hdfs://localhost:9000</value> <description>HDFS,URI</description> </property> </configuration>3、修改etc/hadoop/hdfs-site.xml文件<configuration> <property> <name>dfs.replication</name> <value>1</value> </property> <property> <name>dfs.namenode.name.dir</name> <value>file:/usr/local/hadoop/tmp/dfs/name</value> </property> <property> <name>dfs.datanode.data.dir</name> <value>file:/usr/local/hadoop/tmp/dfs/data</value> </property> </configuration>4、执行 NameNode 的格式化:[root@bogon ~]# ./bin/hdfs namenode -format成功的话，会看到 “successfully formatted” 和 “Exitting with status 0” 的提示，若为 “Exitting with status 1” 则是出错。18/04/27 15:45:59 INFO common.Storage: Storage directory /usr/local/hadoop/tmp/dfs/name has been successfully formatted.18/04/27 15:45:59 INFO namenode.FSImageFormatProtobuf: Saving image file /usr/local/hadoop/tmp/dfs/name/current/fsimage.ckpt_0000000000000000000 using no compression18/04/27 15:45:59 INFO namenode.FSImageFormatProtobuf: Image file /usr/local/hadoop/tmp/dfs/name/current/fsimage.ckpt_0000000000000000000 of size 321 bytes saved in 0 seconds.18/04/27 15:45:59 INFO namenode.NNStorageRetentionManager: Going to retain 1 images with txid >= 018/04/27 15:45:59 INFO util.ExitUtil: Exiting with status 018/04/27 15:45:59 INFO namenode.NameNode: SHUTDOWN_MSG: 5、SSH免密码登录（单机版不需要像某些教程提到的新建hadoop用户，即不新建用户）[root@bogon ~]# ssh-keygen -t dsa -P '' -f ~/.ssh/id_dsa  Generating public/private dsa key pair.Your identification has been saved in /root/.ssh/id_dsa.Your public key has been saved in /root/.ssh/id_dsa.pub.The key fingerprint is:a1:52:80:19:6c:48:57:44:2b:6d:68:f7:ee:36:88:d3 root@bogonThe key's randomart image is:+--[ DSA 1024]----+|.+.==+           ||. * o..          || . + =. .        ||  . +... .       ||    . ..S        ||     ..          ||    o ..         ||   o E.o         ||    . ...        |+-----------------+[root@bogon ~]# cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys[root@bogon ~]# chmod 0600 ~/.ssh/authorized_keys6、hdfs启动与停止[root@bogon hadoop-2.6.5]# ./sbin/start-dfs.shStarting namenodes on [localhost]localhost: starting namenode, logging to /root/Downloads/hadoop-2.6.5/logs/hadoop-root-namenode-bogon.outlocalhost: starting datanode, logging to /root/Downloads/hadoop-2.6.5/logs/hadoop-root-datanode-bogon.outStarting secondary namenodes [0.0.0.0]0.0.0.0: starting secondarynamenode, logging to /root/Downloads/hadoop-2.6.5/logs/hadoop-root-secondarynamenode-bogon.out[root@bogon hadoop-2.6.5]# jps9153 DataNode9298 SecondaryNameNode9413 Jps9036 NameNode[root@bogon hadoop-2.6.5]# ./sbin/stop-dfs.sh 启动完成后，可以通过命令 jps 来判断是否成功启动，若成功启动则会列出如下进程: “NameNode”、”DataNode”和SecondaryNameNode（如果 SecondaryNameNode 没有启动，请运行 sbin/stop-dfs.sh 关闭进程，然后再次尝试启动尝试）。如果没有 NameNode 或 DataNode ，那就是配置不成功，请仔细检查之前步骤，或通过查看启动日志排查原因。7、web监控，浏览器输入http://localhost:500708、配置yarn文件（非必须）配置/etc/hadoop/mapred-site.xml 。这里注意一下，hadoop里面默认是mapred-site.xml.template 文件，如果配置yarn，把mapred-site.xml.template 重命名为mapred-site.xml 。如果不启动yarn，把重命名还原。mapred-site.xml<configuration> <property> <name>mapreduce.framework.name</name> <value>yarn</value> </property> </configuration> yarn-site.xml <configuration> <property> <name>yarn.nodemanager.aux-services</name> <value>mapreduce_shuffle</value> </property> </configuration>YARN 是从 MapReduce 中分离出来的，负责资源管理与任务调度。YARN 运行于 MapReduce 之上，提供了高可用性、高扩展性，但 YARN 主要是为集群提供更好的资源管理与任务调度，然而这在单机上体现不出价值，反而会使程序跑得稍慢些。因此在单机上是否开启 YARN 就看实际情况了。启动和停止的终端命令是：[root@bogon hadoop-2.6.5]# ./sbin/start-yarn.sh starting yarn daemonsstarting resourcemanager, logging to /root/Downloads/hadoop-2.6.5/logs/yarn-root-resourcemanager-bogon.outlocalhost: starting nodemanager, logging to /root/Downloads/hadoop-2.6.5/logs/yarn-root-nodemanager-bogon.out[root@bogon hadoop-2.6.5]# jps9153 DataNode9298 SecondaryNameNode10180 Jps10056 ResourceManager9036 NameNode10142 NodeManager[root@bogon hadoop-2.6.5]# ./sbin/stop-yarn.sh启动 YARN 之后，运行实例的方法还是一样的，仅仅是资源管理方式、任务调度不同。观察日志信息可以发现，不启用 YARN 时，是 “mapred.LocalJobRunner” 在跑任务，启用 YARN 之后，是 “mapred.YARNRunner” 在跑任务。启动 YARN 有个好处是可以通过 Web 界面查看任务的运行情况：http://localhost:8088/cluster。 如果不想启动 YARN，务必把配置文件 mapred-site.xml 重命名，改成 mapred-site.xml.template，需要用时改回来就行。否则在该配置文件存在，而未开启 YARN 的情况下，运行程序会提示 “Retrying connect to server: 0.0.0.0/0.0.0.0:8032” 的错误，这也是为何该配置文件初始文件名为 mapred-site.xml.template。 三、Hase的配置先看姊妹篇的介绍：CentOS7使用HBase-1.2.6单机版，无hadoop再来修改配置文件/root/Downloads/hbase-1.2.6/conf/hbase-site.xml<configuration> <property> <name>hbase.tmp.dir</name> <value>/usr/local/hbase/hbaseData</value> </property> <property> <name>hbase.rootdir</name> <value>hdfs://localhost:9000/hbase</value> </property> <property> <name>hbase.zookeeper.quorum</name> <value>localhost</value> </property> </configuration>启动验证[root@bogon ~]# cd /root/Downloads/hbase-1.2.6/bin[root@bogon bin]# ./start-hbase.shstarting master, logging to /usr/local/hbase/logs/hbase-root-master-bogon.outJava HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=128m; support was removed in 8.0Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=128m; support was removed in 8.0[root@bogon bin]# jps9153 DataNode9298 SecondaryNameNode11379 Jps11339 HMaster9036 NameNode我们来检测一下HBase有没有连接上Hadoop[root@bogon ~]# cd /root/Downloads/hadoop-2.6.5/bin[root@bogon bin]# hdfs dfs -ls /Found 1 itemsdrwxr-xr-x   - root supergroup          0 2018-04-27 17:05 /hbase说明自动建立/hbase文件夹成功了，连接ok！

一、环境搭建使用CentOS7系统，先删除自带的JDK，自带的不好用（例如jps终端命令不能用等）。下载官网完整的JDK，并设置环境变量JAVA_HOME。详情见：https://blog.csdn.net/libaineu2004/article/details/80060812二、下载稳定版habse，1.2.6版本http://mirror.bit.edu.cn/apache/hbase/stable/解压 tar -xzvf hbase-1.2.6-bin.tar.gz ， 笔者的工作路径是/root/Downloads/hbase-1.2.6/三、配置1、 在单机模式中，ZooKeeper程序与HBase程序运行在同一个JVM进程中。Hbase依赖于zookeeper，所有的节点和客户端都必须能够访问zookeeper。 HBase的安装包里面有自带的ZooKeeper，conf/hbase-env.sh文件有环境变量定义：# export HBASE_MANAGES_ZK=true它用来设置HBase是使用默认自带的 Zookeeper还是使用独立的ZooKeeper。 HBASE_MANAGES_ZK为 false 时使用独立的. HBASE_MANAGES_ZK为 true 时表示使用默认自带的，即让Hbase启动的时候同时也启动自带的ZooKeeper。如果使用自带的zookeeper，去不去掉这行环境变量注释效果都一样，默认值就是true。也就是说conf/hbase-env.sh文件可以不需要修改。但是我个人还是建议去掉注释比较直观，同时把JAVA_HOME也再次明确一下较好。（非必须）export JAVA_HOME=/root/Downloads/jdk1.8.0_172export HBASE_LOG_DIR=/usr/local/hbase/logsexport HBASE_MANAGES_ZK=true2、在单机模式中，HBase并不使用 HDFS，仅使用本地文件系统。conf/hbase-env.sh文件不需要修改，仅仅修改conf/hbase-site.xml，指定数据文件的存放路径。<configuration>   <property>      <name>hbase.tmp.dir</name>      <value>/usr/local/hbase/hbaseData</value>   </property>    <property>        <name>hbase.rootdir</name>        <value>file:/usr/local/hbase</value>    </property></configuration>注意：（1）HBase可以不依赖Hadoop的HDFS来部署，在单机模式下直接使用普通文件系统来存储数据。说明HBase是可以离开HDFS的。（2）如果不修改conf/hbase-site.xml文件，默认情况下Hbase是写到/tmp的，在重启的时候/tmp会被清空，数据就会丢失。四、终端验证，进入/root/Downloads/hbase-1.2.6/bin[root@bogon bin]# echo $JAVA_HOME/root/Downloads/jdk1.8.0_172[root@bogon bin]# ./start-hbase.shstarting master, logging to /root/Downloads/hbase-1.2.6/bin/../logs/hbase-root-master-bogon.outJava HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=128m; support was removed in 8.0Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=128m; support was removed in 8.0[root@bogon bin]# jps98741 Jps98382 HMaster[root@bogon bin]# hbase shell2018-04-27 09:34:39,017 WARN  [main] util.NativeCodeLoader: Unable to load native-hadoop library for your platform... using builtin-java classes where applicableHBase Shell; enter 'help<RETURN>' for list of supported commands.Type "exit<RETURN>" to leave the HBase ShellVersion 1.2.6, rUnknown, Mon May 29 02:25:32 CDT 2017hbase(main):001:0> listTABLE                                                                                                  0 row(s) in 0.2190 seconds=> []hbase(main):002:0> create 'user' ,'personalinfo'0 row(s) in 1.3250 seconds=> Hbase::Table - userhbase(main):003:0> listTABLE                                                                                                  user                                                                                                   1 row(s) in 0.0460 seconds=> ["user"]hbase(main):004:0> hbase(main):001:0> exit五、因为ZooKeeper程序与HBase程序运行在同一个JVM进程中，通过jps命令只能看到HMaster，那怎么知道zookeeper启动了呢？[root@bogon bin]# netstat -tunlp|egrep 2181tcp6       0      0 :::2181                 :::*                    LISTEN      5804/java   六、web监控，打开浏览器http://localhost:16010/master-status或者http://192.168.83.128:16010/master-status参考文献：https://blog.csdn.net/lisonglisonglisong/article/details/46917961----关于jps终端命令：jps 是java提供的查看java进程的工具，比如我用jps命令查看，正常情况会列出如下信息：<进程号1111> …… <进程名A><进程号2222> …… <进程名B><进程号3333> …… <进程名C><进程号4444> …… <Jps>这时用kill -9 <进程号> 是可以杀掉进程的。

2. 发展历史创始人Doug CuttingLucene称为apache基金会的子项目Lucene面临跟google一样的问题,海里数据存储问题,检索问题DougCutting学习模仿google,创造微型版Nutchhadoop的产生依赖于google在大数据方面的三篇论文GFS 产生了 HDFSMap-Reduce 产生了MRBigTable 产生了Hbase03-04年,google公开了部分GFS和MapReduce的细节,DougCutting用了两年业余时间实现了DFS和MapReduce机制,使Nutch性能飙升05年,hadoop作为Lucene的子项目Nutch的一部分正式引入Apache基金会06年3月份,Map-Reduce和Nutch Distributed File System(NDFS)分别被纳入hadoop中,Hadoop诞生名字来源于Doug Cutting儿子的玩具大象3.三大发行版本Apache 最基本的版本Cloudera 内部集成了很多大数据框架 对应产品CDHHortonworks 文档较好 对应产品HDP 已被Cloudera收购,推出产品CDP4.优势高可靠性 底层多个数据副本高扩展性 动态增加节点高效性 并行工作高容错性 5. 组成1.xCommon 辅助工具HDFS 数据存储MapReduce 计算+资源调度2.xCommon 辅助工具HDFS 数据存储Yarn 资源调度MapReduce 计算3.x无变化6. 各组成概述6.1 HDFS概述Hadoop Distributed File SystemNameNode 数据的存储情况DataNode 存储数据2NN 对NN进行备份6.2 YARN概述Yet Another Resource Negotiator 另一种资源协调者ResourceManager 整个集群资源的管理者NodeManager 单节点资源的管理者ApplicationMaster 单个任务运行的管理者Container 容器6.3 MapReduce概述分为Map Reduce两部分7. 生态体系

一、背景本人经历过校招和社招，通过校招进入网易，通过社招进入阿里（蚂蚁）。自己当过求职者也做过面试官。在我看来，面试是七分能力和三分运气。其中是否名校出身，是否名企背景都是非常重要的因素，但是把关键的图书看透，对面试会有较大的帮助作用。平时也会有些校招或者社招同学请求推荐一些资料。借着 1024 程序员节这个机会，分享一些对面试比较有帮助的图书、专栏（我自己都反复阅读过的），希望对大家求职有帮助。二、图书或专栏推荐《码出高效：Java开发手册》https://book.douban.com/subject/30333948/《阿里巴巴Java开发手册》https://book.douban.com/subject/27605355/这两本书是孤尽老师出的非常不错的书，涉及很多面试中可能会问到的 Java 基础知识，如集合源码、多线程等。这两本书我公司和家里各一份，经常翻阅。曾经也遇到过一些同学，认为书里内容似乎挺简单，但是问里面的问题答不上来，非常尴尬。解锁大厂思维：剖析《阿里巴巴 Java 开发手册》（专栏）https://90416.com/cQY这是我的技术专栏，如果感兴趣建议可以配套一起看。《Java并发编程的艺术》、《Java并发编程实战》、《实战Java高并发程序设计》《Java并发实现原理：JDK源码剖析》https://book.douban.com/subject/35013531/Java 并发类也是面试中的一个重点，该书从源码层面对这一块进行解析，值得一看。《深入理解Java虚拟机》https://book.douban.com/subject/34907497/说真的，现在 Java 求职竞争很激烈，如果你连这本书都没听说过，面试不通过一点都不冤。这本书可以说是国内介绍 虚拟机最权威的图书，找工作之前至少要读 3 遍以上，一定要吃透。《MySQL 45 讲》 (专栏)这个专栏对没系统学习过 MySQL 理论的人来说是非常不错的，值的多看几遍。如果你能把这个专栏读的很透，应付面试问题不大。如果你已经学的很透，觉得挑战性还不够大，还想继续进阶，想秒杀面试官，可以看 《MySQL 是怎样运行的》https://book.douban.com/subject/35231266/该书图文并茂，讲得非常底层，讲得很深。《Redis 深度历险：核心原理与应用实践》https://book.douban.com/subject/30386804/该书褒贬不一，但在我看来是一个非常不错的资料。很多人会认为这本书写的还不够深，但很多人连这本书都达不到理解非常透彻的程度。看透这本书再结合一些其他资料，足以应付面试中 Redis 相关问题。如果你看过上面的图书，觉得掌握的非常娴熟，想进一步提高，可以看《Redis 设计与实现》https://book.douban.com/subject/25900156/《从 0 开始深入学习 Spring》 （专栏）如果有需要，专栏链接自行百度。该专栏讲得比较通俗易懂，感兴趣可以读一读。《深入理解Apache Dubbo与实战》https://book.douban.com/subject/34455777/面试中 RPC 框架的原理也是一个常问的方面，可以看 Dubbo 官方文档，如果还想进一步了解或者手头随时翻阅，可以买这本书，写的还可以。这本书作者也是有赞前同事，现在也在阿里巴巴工作。《深入理解 Kafaka - 核心设计与实践原理》https://book.douban.com/subject/30437872/这本书对 Kafka 进行了比较全面的介绍，如果想了解 kafka 的设计原理可以看这本书。《HBase不睡觉书》https://book.douban.com/subject/30115996/这本书书名就很有意思。该书通俗易懂、图文并茂，读完可以对 HBase 架构有一个非常不错的了解，对 HBase 的核心原理，读写过程等都可以信手拈来。《Elasticsearch实战》https://book.douban.com/subject/30380439/这本书比较全面地介绍 ES ，是一个非常不错的参考资料。《剑指Offer》https://book.douban.com/subject/6966465/可以说这里包括国内程序员面试必刷的题目。这里的题目是必须会的，运气好，面试官出题比较简单，可能会碰到原题。如果这里的题目你已搞的很透，可以多刷刷 leetcodehttps://leetcode.com/《设计模式之禅》https://book.douban.com/subject/4260618/设计模式之禅对设计模式的讲解非常全面，可以结合菜鸟教程的设计模式教程一起学习，效果非常不错。《大型网站系统与Java中间件开发》https://book.douban.com/subject/25867042/《大型网站技术架构》https://book.douban.com/subject/25723064//《微服务架构设计模式》https://book.douban.com/subject/33425123/《领域驱动设计》、《领域驱动设计精粹》、《解构领域驱动设计》当然，很多不错的图书，这里就不一一列举了，如果有遗漏欢迎补充。三、网站3.1 搜狗微信搜索推荐使用搜狗微信搜索，输入常见的面试问题，通常会得到很多与之相关的高质量的公众号文章。综合这些文章，可以得到比较全面的答案，可以帮你节省很多时间。3.2 github 面试题库网上会有很多参加校招或者社招同学整理的面经，这些面经也具有很大参考价值。如果你没有时间去整理自己的面经库，可以参考一下。https://github.com/doocs/advanced-javahttps://github.com/PansonPanson/Java-Noteshttps://github.com/xbox1994/Java-Interviewhttps://github.com/frank-lam/fullstack-tutorialhttps://github.com/NotFound9/interviewGuide3.3 视频《Java 工程师面试突击》 中华石杉中华石杉的面试突击类系列视频课程质量挺不错，而且还是免费的。如果有需要可以自行下载，对面试有一定的帮助。四、总结本文结合自己的校招和社招经历，结合自己作为面试者和面试官的经历，推荐出一些 Java 面试中比较重要的图书，希望对大家有帮助。如果你有面试中能够用到的不错的图书资料，欢迎留言补充。如果你有问题想和我交流，也欢迎评论。如果你觉得文章对你有帮助，欢迎点赞、收藏加评论，你的支持是我创作最大的动力。————————————————版权声明：本文为CSDN博主「明明如月学长」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。原文链接：https://blog.csdn.net/w605283073/article/details/120931093

Apache Hadoop的核心原则就是转移计算比转移数据代价更低。这就是我们尽可能地将计算转移到存储数据之处的原因。因此，HDFS通常使用大量的本地读取，也就是说，读取数据的客户端和要读取的数据在同一节点。起初，HDFS本地读取和远程读取使用同一种方式：客户端端通过TCP套接字连接DataNode，并通过DataTransferProtocol传输数据。这种方式很简单，但是有一些不好的地方。例如，DataNode需要为每个读取数据块的客户端维持一个线程和TCP套接字。内核中TCP协议是有开销的，DataTransferProtocol本身也有开销。因此这里有值得优化的地方。本文将介绍HDFS的一项新优化：安全短路本地读取（secure short-circuit local reads），该实现的好处，以及它是如何为你的应用提速的。HDFS-2246 和 Short-Circuit LocalReads在HDFS-2246中，Andrew Purtell、Suresh Srinivas、Jitendra Nath Pandey和Benoy Antony等人添加了一项“短路本地读取”优化。其核心思想如下：因为客户端和数据在同一个节点，所以没必要再牵涉DataNode，客户端自身直接从本地磁盘读取 数据。这个性能优化被加入了CDH。CHD是Cloudera的Hadoop及相关项目的分发。这个优化是在CDH3u3中被加入的。HDFS-2246实现的短路本地读取是一个很好的开始，但也带来了许多配置上的烦恼。系统管理员必须改变DataNode数据目录权限，以便允许客户端打开相关文件。还需要定义一个白名单，列出允许的用户。通常，这些用户被放在一个特殊的UNIX用户组里。不幸的是，这类权限改变带来了安全漏洞。有权限的用户就可以直接浏览所有数据了，不仅是他们需要的数据。这有点像把用户提升成超级用户！对包括HBase用户在内的一些用户而言，这是可以接受的。然而，一般而言，这会带来很多问题。因此，尽管有些专注的管理员启用了短路本地读取，然而这并不是一个常见的选择。HDFS-347：让短路本地读取安全HDFS-2246的主要问题就是它将DataNode的所有数据路径直接开放给了客户端。其实，只需要开放客户端关心的几个数据文件。好在UNIX提供了这样的机制，文件描述符。HDFS-347 使用该机制实现了安全的本地短路读取。客户端向DataNode请求数据时，DataNode打开块文件和元数据文件，将它们直接传给客户端，而不是将路径传给客户端。因为文件描述符是只读的，客户端不能修改接收到的文件。同时由于客户端自身无法访问块所在的目录，它也就不能访问其他不该访问的数据。Windows 有类似的在进程间传递文件描述符的机制。虽然Cloudera目前还没有在Hadoop内添加该特性的支持，indows用户可以将dfs.cient.use.legacy.blockreader.local 设置为true，以便使用legacy block reader。缓存文件描述符HDFS客户端经常多次读取相同的块文件（尤其是HBase）。为了加快这种场景下的本地读取，HDFS-2246实现的短路本地读取中包含了一个块路径的缓存。该缓存允许客户端重新打开最近读取的块文件，而不需要再去询问DataNode该块文件的路径信息。新的短路实现包含了一个FileInputStreamCache，用于取代路径缓存。缓存文件描述符。这比缓存路径要好，因为客户端不用重新打开文件才能重新读取块。我们发现这一实现提高了性能。缓存的大小可以通过 dfs.client.read.shortcircuit.stream.cache.size 调整，缓存超时时间通过 dfs.client.read.shortcircuit.streams.cache.expiry.ms 设定。设置缓存大小为0即可关闭缓存。大多数情况下，默认配置就可以了。如果你所处的情景是特殊的大规模工作集，文件描述符限制也很高，那么你可以试着提高参数值。HDFS-347配置HDFS-347引入的短路本地读取，使任何HDFS用户都可以使用短路本地读取，而不是局限于配置过的少量用户。也不需要修改Unix用户组来设定谁可以访问DataNodeN路径。然而，由于Java标准库并不包含支持文件描述符传递的库，所以该特性需要使用JNI组建。你需要安装 libhadoop.so 库才能使用。HDFS-347也要求设置一NUX域套接字路径，可通过 dfs.domain.socket.path 设置。该路径必须是安全的，以便阻止无特权的进程进行中间人攻击。套接字路径的每个组成目录的都必须是root或启动DataNode的用户所有，人人可写或者组成员可写的路径无法使用。如果你安装cloudera包，rpm或者deb，它会为你创建一个安全的UNIX域套接字路径。同时会将libhadoop.so 安装到正确路径下。可以参考 上游的文档 获取配置短路本地读取的信息。性能那么，新的实现有多快？我使用了一个名为hio_bench的程序获取到一些性能统计数据。hio_bench的代码可由此取得： https://github.com/cmccabe/hiotest测试运行在8核 intelXeon 2.13 CPU 、12块磁盘的服务器上。我使用CDH4.3.1，底层使用ext4文件系统。 下图每个值是运行三次的平均值。有误差线。在所有测试中，HDFS-347实现是最快的，这大概要归功于FileInputStreamCache.相反HDFS-2246实现会重复打开ext4 块文件多次，打开文件可是一个代价很高的操作。在随机读取的场景下，相对顺序读取，短路实现有更明显的优势。部分原因是短路读取还没有实现预读。可以参考HDFS-4697的讨论。结论短路本地读取是一个很好的例子，展示了Hadoop将计算带向数据的模型如何使优化成为可能。这个例子同时也展示了，在处理了规模不断增长的挑战之后，Cloudera正挑战提高集群中的每个节点的性能。如果你正使用CDH4.2 或以上版本，试下这个新实现吧！

Impala 项目主页在：https://github.com/cloudera/impala大数据处理是云计算中非常重要的问题，自Google公司提出MapReduce分布式处理框架以来，以Hadoop为代表的开源软件受到越来越多公司的重视和青睐。以Hadoop为基础，之后的HBase，Hive，Pig等系统如雨后春笋般的加入了Hadoop的生态系统中。今天我们就来谈谈Hadoop系统中的一个新成员 – Impala。Impala架构分析Impala是Cloudera公司主导开发的新型查询系统，它提供SQL语义，能够查询存储在Hadoop的HDFS和HBase中的PB级大数据。已有的Hive系统虽然也提供了SQL语义，但是由于Hive底层执行使用的是MapReduce引擎，仍然是一个批处理过程，难以满足查询的交互性；相比之下，Impala的最大特点也是最大卖点就是它的快速。那么Impala如何实现大数据的快速查询呢？在回答这个问题之前，我们需要先介绍Google的Dremel系统[1]，因为Impala最开始就是参照Dremel系统进行设计的。 Dremel是Google的交互式数据分析系统，它构建于Google的GFS（Google File System）等系统之上，支撑了Google的数据分析服务BigQuery等诸多服务。Dremel的技术亮点主要有两个：一个是实现了嵌套型数据的列存储；二是使用了多层查询树，使得任务可以在数千个节点上的并行执行和聚合结果。列存储在关系型数据库中并不陌生，它可以减少查询时处理的数据量，有效的提升查询效率。Dremel的列存储的不同之处在于它针对的并不是传统的关系数据，而是针对嵌套结构的数据。Dremel可以将一条条的嵌套结构的记录转换成列存储形式，查询时根据查询条件读取需要的列，然后进行条件过滤，输出时再将列组装成嵌套结构的记录输出，记录的正向和反向转换都通过高效的状态机实现。另一方面，Dremel的多层查询树则借鉴了分布式搜索引擎的设计，查询树的根节点负责接收查询，并将查询分发到下一层节点，底层节点负责具体的数据读取和查询执行，然后将结果返回上层节点。关于Dremel技术实现上的更多信息，读者可以参阅[9]。Impala其实就是Hadoop的Dremel，Impala使用的列存储格式是Parquet。Parquet实现了Dremel中的列存储，未来还将支持Hive并添加字典编码，游程编码等功能。Impala的系统架构如图一所示。Impala使用了Hive 的SQL接口（包括SELECT，INSERT，Join等操作），但目前只实现了Hive的SQL语义的子集（例如尚未对UDF提供支持），表的元数据信息存储在Hive的Metastore中。StateStore是Impala的一个子服务，用来监控集群中各个节点的健康状况，提供节点注册，错误检测等功能。Impala在每个节点运行了一个后台服务impalad，impalad用来响应外部请求，并完成实际的查询处理。Impalad主要包含Query Planner，Query Coordinator和Query Exec Engine三个模块。QueryPalnner接收来自SQL APP和 ODBC的查询，然后将查询转换为许多子查询，Query Coordinator将这些子查询分发到各个节点上，由各个节点上的Query Exec Engine负责子查询的执行，最后返回子查询的结果，这些中间结果经过聚集之后最终返回给用户。图1. Impala的系统架构图 [2]在Cloudera的测试中，Impala的查询效率相比Hive，有数量级的提升。从技术角度上来看，Impala之所以能有好的性能，主要有如下几方面的原因：Impala不需要把中间结果写入磁盘，省掉了大量的I/O开销。省掉了MapReduce作业启动的开销。MapReduce启动task的速度是很慢的（默认每个心跳间隔是3秒钟），Impala直接通过相应的服务进程来进行作业调度，速度快了很多。Impala完全抛弃了MapReduce这个不太适合做SQL查询的范式，而是像Dremel一样借鉴了MPP并行数据库的思想，从新另起炉灶，因此可以做更多的查询优化，从而能省掉不必要的shuffle，sort等开销；通过使用LLVM来统一编译运行时代码，避免了为支持通用编译而带来的不必要开销；用C++实现，做了很多有针对性的硬件优化，例如使用SSE指令；使用了支持Data locality的I/O调度机制，尽可能的将数据和计算分配在同一台机器上进行，减少了网络开销；虽然Impala是参照Dremel来实现，但是Impala也有一些自己的特色，例如Impala不仅仅支持Parquet格式，同时也可以直接处理文本，SequenceFile等Hadoop中常用的文件格式。另外一个更关键的地方在于，Impala是开源的，再加上Cloudera在Hadoop领域的领导地位，其生态圈有很大可能会在将来快速成长。可以预见在不久的未来，Impala很可能像之前的Hadoop和Hive一样在大数据处理领域大展拳脚。Cloudera自己也说期待未来Impala能完全取代Hive。当然，用户从Hive上迁移到Impala上来是需要时间的，而且Impala也只是刚刚发布1.0版，虽然号称已经可以稳定的在生产环境上运行，但相信仍然有很多可改进的空间[7]。需要说明的是，Impala并不是用来取代已有的MapReduce系统，而是作为MapReduce的一个强力补充，总的来说Impala适合用来处理输出数据适中或比较小的查询，而对于大数据量的批处理任务，MapReduce依然是更好的选择。另外一个花边消息是，Cloudera里负责Impala的架构师Marcel Komacker就曾在Google负责过F1系统的查询引擎开发，可见Google确实为大数据的流行出钱出力。Impala与Shark，Drill等的比较开源组织Apache也发起了名为Drill的项目来实现Hadoop上的Dremel，目前该项目正在开发当中，相关的文档和代码还不多，可以说暂时还未对Impala构成足够的威胁[10]。从Quora上的问答来看，Cloudera有7-8名工程师全职在Impala项目上，而相比之下Drill目前的动作稍显迟钝。具体来说，截止到2012年10月底，Drill的代码库里实现了query parser, plan parser，及能对JSON格式的数据进行扫描的plan evaluator；而Impala同期已经有了一个比较完毕的分布式query execution引擎，并对HDFS和HBase上的数据读入，错误检测，INSERT的数据修改，LLVM动态翻译等都提供了支持。当然，Drill作为Apache的项目，从一开始就避免了某个vendor的一家独大，而且对所有Hadoop流行的发行版都会做相应的支持，不像Impala只支持Cloudera自己的发行版CDH。从长远来看，谁会占据上风还真不一定[10]。除此之外，加州伯克利大学AMPLab也开发了名为Shark的大数据分析系统。在今天6月份的《程序员》上有一篇专门分析与Shark相关的Spark系统的文章，感兴趣的读者朋友可以参考。从长远目标来看，Shark想成为一个既支持大数据SQL查询，又能支持高级数据分析任务的一体化数据处理系统。从技术实现的角度上来看，Shark基于Scala语言的算子推导实现了良好的容错机制，因此对失败了的长任务和短任务都能从上一个“快照点”进行快速恢复。相比之下，Impala由于缺失足够强大的容错机制，其上运行的任务一旦失败就必须“从头来过”，这样的设计必然会在性能上有所缺失。而且Shark是把内存当作第一类的存储介质来做的系统设计，所以在处理速度上也会有一些优势[11]。实际上，AMPLab最近对Hive，Impala，Shark及Amazon采用的商业MPP数据库Redshift进行了一次对比试验，在Scan Query，Aggregation Query和Join Query三种类型的任务中对它们进行了比较。图2就是AMPLab报告中Aggregation Query的性能对比。在图中我们可以看到，商业版本的Redshift的性能是最好的， Impala和Shark则各有胜负，且两者都比Hive的性能高出了一大截。更多相关的实验结果读者朋友可以参考[12]。图2. Redshift，Impala，Shark与Hive的Aggregation Query性能对比 [12]以笔者愚见，其实对大数据分析的项目来说，技术往往不是最关键的。例如Hadoop中的MapReduce和HDFS都是源于Google，原创性较少。事实上，开源项目的生态圈，社区，发展速度等，往往在很大程度上会影响Impala和Shark等开源大数据分析系统的发展。就像Cloudera一开始就决定会把Impala开源，以期望利用开源社区的力量来推广这个产品；Shark也是一开始就开源了出来，更不用说Apache的Drill更是如此。说到底还是谁的生态系统更强的问题。技术上一时的领先并不足以保证项目的最终成功。虽然最后那一款产品会成为事实上的标准还很难说，但是，我们唯一可以确定并坚信的一点是，大数据分析将随着新技术的不断推陈出新而不断普及开来，这对用户永远都是一件幸事。举个例子，如果读者注意过下一代Hadoop（YARN）的发展的话就会发现，其实YARN已经支持MapReduce之外的计算范式（例如Shark，Impala等），因此将来Hadoop将可能作为一个兼容并包的大平台存在，在其上提供各种各样的数据处理技术，有应对秒量级查询的，有应对大数据批处理的，各种功能应有尽有，满足用户各方面的需求。未来展望其实除了Impala，Shark，Drill这样的开源方案外，像Oracle，EMC等传统厂商也没在坐以待毙等着自己的市场被开源软件侵吞。像EMC就推出了HAWQ系统，并号称其性能比之Impala快上十几倍，而前面提到的Amazon的Redshift也提供了比Impala更好的性能。虽然说开源软件因为其强大的成本优势而拥有极其强大的力量，但是传统数据库厂商仍会尝试推出性能、稳定性、维护服务等指标上更加强大的产品与之进行差异化竞争，并同时参与开源社区、借力开源软件来丰富自己的产品线、提升自己的竞争力，并通过更多的高附加值服务来满足某些消费者需求。毕竟，这些厂商往往已在并行数据库等传统领域积累了大量的技术和经验，这些底蕴还是非常深厚的。甚至现在还有像NuoDB（一个创业公司）这样号称既支持ACID，又有Scalability的NewSQL系统出来。总的来看，未来的大数据分析技术将会变得越来越成熟、越来越便宜、越来越易用；相应的，用户将会更容易更方便地从自己的大数据中挖掘出有价值的商业信息。参考资料http://research.google.com/pubs/pub36632.htmlhttp://blog.cloudera.com/blog/2012/10/cloudera-impala-real-time-queries-in-apache-hadoop-for-real/http://www.slideshare.net/cloudera/data-science-on-hadoopImpala重点问题列表：http://yuntai.1kapp.com/?p=1089Hive原理与不足：http://www.ccplat.com/?p=1035Impala/Hive现状分析与前景展望：http://yanbohappy.sinaapp.com/?p=220What’s next for Cloudera Impala: http://blog.cloudera.com/blog/2012/12/whats-next-for-cloudera-impala/MapReduce：一个巨大的倒退：http://t.cn/zQLFnWsGoogle Dremel 原理 — 如何能3秒分析1PB：http://www.yankay.com/google-dremel-rationale/Isn’t Cloudera Impala doing the same job as Apache Drill incubator project? http://www.quora.com/Cloudera-Impala/Isnt-Cloudera-Impala-doing-the-same-job-as-Apache-Drill-incubator-projectShark：https://github.com/amplab/shark/wikiBig Data Benchmark: https://amplab.cs.berkeley.edu/benchmark/Impala wiki：http://dirlt.com/impala.htmlHow does Impala compare to Shark: http://www.quora.com/Apache-Hadoop/How-does-Impala-compare-to-SharkEMC讲解Hawq SQL性能：左手Hive右手Impala: http://stor-age.zdnet.com.cn/stor-age/2013/0308/2147607.shtml作者简介耿益锋，清华大学计算机系博士研究生，主要研究方向包括大数据处理和云计算中新应用和新场景下分布式系统的设计和优化。陈冠诚，IBM中国研究院研究员，主要技术方向为大规模分布式系统中的软硬件协同设计。个人博客为并行实验室（www.parallellabs.com），新浪微博@冠诚。

链接2、峰会技术关键词词云3、技术会议主题吴斌老师（Elastic中文社区副主席）：基于流式计算平台搭建实时分析应用李猛老师（力萌科技数据专家）：Elasticsearch 基于 Pipeline 窗口函数实现实时聚合计算白凡老师（尚德机构资深工程师）：基于 Elasticsearch 的容器化编排实践刘征老师（Elastic社区布道师）：如何规划和执行威胁狩猎魏子珺老师（阿里巴巴技术专家）：Elasticsearch云原生内核建设之路4、基于流式计算平台搭建实时分析应用（吴斌）4.1 为什么要面向开源进行架构设计？轻松定制化、业务专注、低学习成本。由于代码公开，所以安全、合规、透明。高度灵活性，无平台绑定。4.2 流式计算平台架构剖析如图所示，流式计算平台主要由分布式消息队列、分布式计算引擎、数据引擎三部分构成。4.2.1 分布式消息队列数据采集，支持消息分发、消息缓存高可用，削峰填谷4.2.2 分布式计算引擎早期：MapReduce、Storm当下主流：Flink、Storm2.0支持热更新 / 弹性伸缩计算引擎核心任务：数据校验（数据格式、合法性、脏数据等）数据清洗（数据 ETL 转换）数据丰富（多维数据Join，以辅助数据分析）4.2.3 数据引擎热数据存储在 Elasticsearch、HBase。其中 HBase 存储热数据非完全必要，除非高 IO 存储需要引入。一般情况下，数据的分析：Elasticsearch 就能搞定。温数据（超过 7天的数据）存储选型：1）MPP2）Hive，GreenPlum4.2.4 分布式存储云端的对象存储文件输出、明细错误数据落地快照 snapshot 等1）数据来源（server Application）：服务器日志、监控、业务数据采集（如用户行为、购买记录、社交记录）。2）数据发送到消息队列 （MSG G）。3）消息队列数据写入 Beam Streaming 开源驱动引擎框架。批流一体引擎。Beam 能驱动：Flink、Spark Stream、 Strom 去做流式数据、batch 数据处理。4）拉取RDB业务维表与实时数据Join。5）对有问题数据输出到 Object 对象 / File 文件系统备份。6）实时数据注入 Elasticsearch。7）高 IO 数据写入 HBase（KV引擎）。8）Beam Batch 批量处理。核心Tips: HBase  +  Elasticsearch 组合使用，以打车场景为例：当打车订单未完成时候，明细数据（实时高 IO）录入HBase：Session （订单）结束后，一个打车订单归拢为一条数据，放到 Elasticsearch，在 ES 中做实时订单分析、轨迹查询、客服查询等处理。4.3 Elasticsearch 在流式平台中的角色功能（1）文本检索日志场景：运维、开发、测试、客服。（2）已知数据计算已知数据定义：Mapping是我们自定义的。实时指标计算。场景：固定报表、大屏展示。（3）未知线索探索指标计算复杂过滤条件adhoc 查询关联性、归因等4.4 云原生与k8s集群管理经验分享（核心）lass / On-prem：自己部署（实体机、虚拟机）大集群：维护升级麻烦，出错恢复周期非常长。Sass：运维简单，具备弹性；缺点：细节不透明，网络拓扑受限，入口/网关性能、灵活性差，升级麻烦。Pass (平台服务) / K8s（1）优点：运维简单、yaml文件决定部署、弹性好、独享资源、官方operator。（2）缺点：受限于K8s、开源版本，官方未来会推出商业版本。推荐：基于云托管K8s搭建ES集群。为 Elasticsearch 量身定制的网关产品——极限网关极限网关特性：转发性能好。支持多集群之间数据分流、同步。支持网关级限流。4.5 相关资源Elasticsearch  on K8s（Elastic 中文社区维护）https://github.com/elasticsearch-cn/elastic-on-gke/流式分析平台框架（Beam）https://github.com/cloudymoma/raycom极限网关（持续完善中）http://gateway.infini.sh/https://github.com/medcl/infini-gateway

GitHub 地址 https://github.com/apache/flink欢迎大家给 Flink 点赞送 star~12 月 4-5 日，北京国家会议中心，Flink Forward Asia 2021 重磅开启，全球 40+ 多行业一线厂商，80+ 干货议题，带来专属于开发者的技术盛宴。其中，行业实践专场由字节跳动、网易、蔚来、中原银行、建信金融科技、中信建投等多行业实时计算领域专家详细解读 Flink 在业内的应用与落地，围绕业务场景、业务痛点、面临挑战、如何破局等宝贵实践经验倾囊相授。点击链接了解完整大会议程：https://Flink-forward.org.cn/中原银行实时风控体系建设实践陈玉强｜中原银行数据平台中心开发工程师本次演讲将分享中原银行在实时风控领域中自主化探索与实践，包括以下方面：介绍风控发展方向；实时数据处理技术选型 - Flink；整体技术架构：Flink + 智策 + 天机 + 数据服务的技术融合方案；实施场景 1：申请与交易反欺诈；实施场景 2：授信审批场景；实时风控体系建设成效；业务效果。Flink 在国有大型银行智能运营场景下的应用周耀｜建信金融科技开发工程师，Apache Superset Contributor，Apache Kylin Contributor现代的应用大都以前后端分离的模式开发，在建设银行新一代系统中每笔交易对应三条消息：前端的埋点信息，发送的 HTTP 请求，返回的 HTTP 响应。建设银行在全球有大量的网点和业务员，每天产生大量的金融业务交易，包含海量的消息报文，其中包含：运营配送，现金配送，信用卡审批等几百种应用场景。而金融业务以复杂，稳定，要求高为特性，在银行业尤其如此。本次 proposal 将根据集约化运营团队使用流计算框架 Flink 的经验，围绕如何引入有状态流计算稳定，及时，高效的将埋点，请求，响应三条消息进行业务加工，合并，向后传递给应用消费，最终产生业务价值。向大家展示流计算架构在银行运营大数据中的演化过程，应对方案，及走过的弯路。希望能对金融企业使用流计算提供参考和借鉴。Flink 流处理在中信建投证券的实践与应用刘成龙｜中信建投证券金融实时数仓项目负责人，大数据研发工程师蔡跃｜中信建投证券金融资讯数据研发工程师证券行业实时计算意义；实时流处理平台整体建设方案。元数据管理、数据采集、数据实时开发、数据网关、数据运营；现阶段应用场景介绍。助力基金投顾、实时零售业务；实时交易流水、资讯数据查询；内部链路实时 ETL；场景：金融资讯数据多源实时校验。针对金融业内特有且普遍遇到的多来源资讯数据缺乏一致性校验问题，介绍中信建投实时校验解决方案；基于 Hologres 的流批一体实践。Flink 在众安保险金融业务的应用郭育波｜众安保险大数据平台开发高级专家随着众安金融业务的快速发展，Flink 在金融业务中得到了广泛的使用。这次我主要介绍下我们团队服务的两个业务场景，智能营销和智能风控。在营销场景中，我们使用 Flink SQL 实现了实时数仓，支撑了各类的实时标签，实时大盘，实时报表的业务场景。使用 Flink 提供实时标签和实时客群的能力，使用 Hologres 作为离线标签的存储加速引擎，实现了快速的用户分群的能力，结合 AB 实验室和智能触达实现了用户的精准化营销，同时还使用流量 AB 实验实现了千人千面的动态客群功能。最后也是使用 Flink 提供了实时的实验效果分析的能力，赋能精准和快速的营销策略。众安金融的风控体系有风控反欺诈、风控决策引擎、风控特征工程，征信数据中心等平台组成，总所周知，金融风控的能力决定了公司的盈利水平，而风控的能力依赖于数据的能力，特征工程为风控的决策提供了核心的数据支撑，我们的特征工程提供三方数据特征，信贷数据特征，征信数据特征，反欺诈数据特征，再这些基础特征之上还有机器学习模型特征，居于用户全方位的数据为风控提供决策依据。我们使用 Flink 的实时计算能力和 Hbase 的高速查询能力满足了风控对于数据的实时性，准确性，稳定性的要求，也取得了很好的业务效果，通过 Flink 的实时计算能力保证了特征的实时性和稳定性，之后为了我们把 Hbase 升级为了阿里云的 Tablestore，减少了 Hbase 运维的风险，进一步提高了稳定性。最近我们结合 Flink 和 Nebula Graph 实现了实时关系图谱，通过 Flink 接入用户的各种数据构建用户数据关系图谱，建立了用户，联系人，手机，设备指纹的用户关系图谱网络，居于图数据计算的相邻边关系、社群发现算法加工出了相关的数据特征，为金融反欺诈提供了实时的数据支持。Flink 在能源建设的实践姚远｜中南电力设计院工程师、注册测绘师全文从三个方面进行介绍：建设背景，实现落地以及未来规划。建设背景： EPC 项目建设的电厂，变电站等工地的传感器，人员数据等不断累计，希望分析安全隐患，预防事故发生。在矿山资源开采过程中，希望结合车辆定位，过磅等数据优化运营分析，提高开采及运输效率。基于以上场景，考虑到数据量及分析的需求，决定采用大数据的方案进行处理。作为非互联网的传统工业企业，没有大数据积累，分析对比之后选择 Flink 作为大数据处理平台。实施落地：例 1，在公司的矿山开采过程中，如何合理设置矿山的磅站位置，每天到场多少辆车进行运输合适，结合车辆定位和磅站数据进行实时分析，监督矿石的开采运输及现场实际情况的维护，保证开采、运输及过站正常运作。例 2，电厂现场安置在线监测设备，包括倾角、光纤光栅、GPS 等传感器，利用监测设备对现场变形情况进行监测，防患安全事故发生。未来规划： 建立整体分析模型，对工地实时数据进行处理；将 GPS 解算过程在 Flink 流上重写，提高反应时间。针对历史数据，挖掘分析价值。Apache Flink 在蔚来汽车的应用吴江｜蔚来汽车大数据部门数据开发，OLAP 平台 tech lead流式计算在蔚来的发展。最开始基于 Spark Streaming 做一些简单的实时处理 -> 开始引入 Flink -> 采用命令行式的 Flink 任务部署和管理 -> 开发实时数据开发平台 1.0 版本 (支持基于 Flink jar 的任务提交与管理) -> 正在开发实时数据开发平台 2.0 版本 (在 1.0 的基础上，增加 Flink SQL 以及 UDF 管理，并且支持 kerberos 认证等)；Flink 的具体应用场景实时数仓及 OLAP 平台：目前我们构建实时数仓还处在比较初始的阶段，正在逐步构建过程中。我们已经在一些项目比如 nio app 的埋点分析中，对流式的数据做了分层，来逐渐沉淀经常使用的公共数据，增加数据的复用。实时数仓还要提供 OLAP 的能力，为了充分发挥实时的能力，会将 Flink 和 Doris 结合，从而能够提供更加灵活完善的平台化的 OLAP 能力；电池安全：由于蔚来的可换电模式，电池数量是大于车的数量，电池状态数据的实时获取/处理，对电池安全至关重要。这块主要讲 Flink 怎么助力提升电池安全；实时看板：看板展示包括实时和离线数据，主要统计和展示用户相关的触点和行为信息。实时和离线数据底层统一用 Apache Doris 进行数据摄入/存储和查询。其中各种实时指标还会直接推给前端，对于复杂的实时指标计算 (比如前端动态选择计算多个城市下的实时 UV)，采取了一种新颖的解决方案，会以 Flink 计算引擎为核心驱动，结合前端一起参与计算，实现从端到端 (Kafka -> Flink -> 前端) 的全链路流式计算；cdp (客户数据平台)：用户画像 & 圈人：依托 Flink 的实时计算和处理，以及 Apache Doris 的实时摄入和快速查询的能力，提供用户标签/用户分群数据的实时获取能力；运营平台：运营平台对选定的人群发送 IM 消息，短信，发放积分卡券等，对于系统的可靠性和数据一致性要求很高 (发送消息要尽量做到不丢不重)。在这个典型的属于后台服务的场景下，Flink 依旧发挥了至关重要的作用。由于发送 im 消息和短信，本身不具备 rollback 能力，我们参照传统的两阶段提交协议，设计了特殊的分布式事务恢复机制，利用 Flink 实时回放 redo log，保证各个 task 之间的状态最终一致性；跨业务系统数据实时聚合：连接，打通，和汇聚不同业务的数据；实时监控和告警：利用训练好的机器学习模型，实时提供指标的异常检测和告警。未来的计划。继续平台化建设，对于问题解决的方案，回馈社区。Flink 在字节跳动数据流的实践刘石伟｜字节跳动数据平台数据流技术负责人数据流是字节跳动所有流量数据的入口，承担着流量数据的接入、ETL、分发、治理等重要职责。Flink 作为当下最流行的流式计算框架被广泛应用于数据流的各个环节，本次分享将介绍字节跳动数据流在 Flink 应用实践中遇到的挑战以及相关优化。业务场景和遇到的问题整体架构；遇到的挑战 / 问题；流量大，下游多，稳定性要求高；业务变化快，业务逻辑修改频率高；部分场景要求更低的端到端延时；批流两套处理链路。基于动态规则的 Flink ETL推荐场景；ETL 分流场景。数据治理 & SLA 指标建设稳定性治理；拆分任务；链路分级，埋点管控；数据延迟/丢失率/重复率 SLA 指标。未来展望流批一体；规则引擎性能优化。网易游戏基于 Flink 的支付环境全关联分析实践林佳｜网易互娱技术中心计费实时平台与 SDK 技术负责人，Apache Flink Contributor本次演讲将介绍网易游戏技术中心使用 Flink 的历程、分享使用现状与实践经验。以技术中心的核心业务 “计费支付” 为实例，讨论如何基于 Flink 这一高效可靠的引擎，通过 SDK 化加平台化的模块式封装，实现出异构数据聚合分析、微观支付链路串联跟踪、用户指标湖等实时数据服务，全方位关联起整个支付环境上的实时数据，进而迅速发现支付环境中的风险与机遇、指导优化方向、提升支付环境的服务质量，并挖掘出前所未有的高时效性数据价值。Apache Flink 在斗鱼的应用与实践夏畅｜斗鱼实时计算负责人公司背景介绍；实时场景分析；实时平台化建设整体架构设计；作业引擎实现；HIVE 元数据 & UDF 注入；实时调试；SLA 保障；实时元数据 & 全链路血缘；实时数仓探索。特来电云平台智能运维应用实践刘桂海｜特来电平台智能保障团队技术负责人特来电云平台简介：新能源充电行业海量高并发互联网网技术架构；特来电云平台智能运维简介：基于 AIOps 的智能监控、智能分析、智能控制；Flink 在特来电云平台智能运维的应用场景指标分析：基于 Flink 的海量高并发的监控引擎；链路分析：基于 Flink 及图数据库的服务链路调用知识图谱、用户行为分析知识图谱；日志分析：基于 Flink 及自然语言处理的异常信息聚类分析、异常日志突变分析；Flink 在特来电云平台智能运维的未来计划：机器学习迁移到 Alink、基于 K8s 运行 Flink。作业帮基于 Flink 的实时计算平台实践张迎｜作业帮实时计算平台负责人业务背景；发展历程；解决方案；总结展望。Flink 在易车落地应用与实践王林红｜易车数据平台负责人Flink 在易车实时数仓、实时数据集成、湖仓一体等方面有很广泛的应用实践，尤其是满足实时大屏、实时流量分析及实时大促等应用场景。本次分享主要介绍 Flink 在易车相关应用的落地实践及经验分享Flink 实时计算平台建设：数据集成、元数据管理、数据血缘、数据实时开发、监控优化等；Flink 在实时数仓、批流一体方面的应用实践；Flink + Hudi 应用实践。如何设计信息安全领域的实时安全基线引擎覃永靖｜奇安信集团技术委员会委员、高级技术专家、NGSOC 事业部安全引擎团队架构师在互联网时代，安全已经成为企业的命脉。奇安信集团作为国内网络安全领军企业，需要与业界同步，使用各种先进技术来保障客户业务安全。 本演讲主要介绍了奇安信集团在打造自研的基于 Flink 的实时安全分析引擎 Sabre 的过程中，对于安全基线的设计和实现过程中遇到的挑战以及对应的解决方案，并分享了很多踩过的坑，同时还有一些思考和总结。希望对从事安全领域相关工作的同学能够有所启发或者帮助。 内容包括：什么是安全基线，介绍安全基线中基于特征和基于行为的两种检测模型，介绍相关安全场景，以及安全领域的四个主要约束，异常检测，受限的资源状态，实时分析和非实时的区别，快速响应的必要性；实时框架的选择，为何采用 Flink 框架而不是 Spark 框架；实时安全基线的设计和实现。以上为 Flink Forward Asia 2021 行业实践专场内容节选，了解更多大会详情可点击下方链接：https://Flink-forward.org.cn/Flink Forward Asia 2021 赞助与合作首届 Flink Forward Asia Hackathon 正式启动，10W 奖金等你来！欢迎进入赛事官网了解详情：https://www.aliyun.com/page-source//tianchi/promotion/FlinkForwardAsiaHackathon更多 Flink 相关技术问题，可扫码加入社区钉钉交流群第一时间获取最新技术文章和社区动态，请关注公众号～活动推荐阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启活动：99 元试用 实时计算Flink版（包年包月、10CU）即有机会获得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！了解活动详情：https://www.aliyun.com/product/bigdata/sc