2020 年，是一个太魔幻的一年（什么？你不知道为什么会这么说？好吧，如果你来自未来，本文末尾有一期推荐的播客可以听一下），甚至很有可能还是「魔幻元年」。那句话怎么说的来着：今年是过去十年最差的一年，却可能是未来十年最好的一年。当然，认真地讲，我并不完全赞同。不过要是说世界的节奏和变化速度越来越快，我是要默然颔首的。
其实这一篇本质上有标题党的嫌疑，因为今年看的书实在太少太少，当然后面我也会解释今年看书少的借口原因。不过，看过我前几年「书单」的你肯定也知道了，我的书单系列只是用「书单」作为切入口，以此为契机来定期来聊聊我对这个世界的看法而已。虽然我也有要时常更新我的博客的想法，但事实就是总有一些手头上新奇的、或者我认为更重要的事情占据着我的时间，以致于目前这里几乎成了一个年更博客，这确实很不应该。但好在我依然还有年更「书单」这个保留节目。
Anyway，这依然首先还是一个「书单」，所以我们还是会从正题开始。
最近在看美剧《高堡奇人》（The Man in the High Castle）第四季，也是最终季。整个剧是基于 Philip K. Dick 的同名长篇小说改编的，也是这部作品创造了一种「架空历史」的新的科幻作品类型，剧情大致是基于纳粹德国和日本天皇打赢了二战，共同统治了世界之后的人类历史发展。值得一说的是，这部小说是 1962 年写的。作为 2020 的人类，我们早已习惯了第二次世界大战同盟国胜利之后的历史，但这部小说带给了我们这样一种思考，这种已经发生的历史是一种冥冥之中的「必然」吗？
当然，历史是经不起假设的，这个宇宙到底存不存在平行时空人类目前也不甚清楚。在这里，我并不是想讨论历史，也不是想讨论科幻，而是想讨论某个事件发生的必然性到底有多「必然」的问题。并不像大多数人以为的那样，人类的潜意识其实非常习惯于从某个结果来抽象总结出事情发生的原因，习惯于找出其中存在的一系列因果关系的逻辑链条而忽视次要因素，从而把事情化繁为简存储在自己的经验模型库之中。人性使然，已经获得成功的人也会不自觉的从自身的成功中总结经验并加以传授，告诉人们你们这样做也可以像我一样成功，这不禁也让人怀疑，成功学有必然性吗？
2019 年对很多人来说似乎是艰难的一年，在这个世界愈发趋于动荡和不信任的大背景下，越来越多的疑惑、迷茫和不确定性从上至下笼罩在每一个人可以感知到的日常生活中。或许只是一种周期，或许就是一种趋势，各种事物的分化与混乱变得越来越明显。如果从热力学第二定律的角度来看，维持事物不走向无序是需要额外付出很多努力的，那说明人类社会目前做的共同有效努力还不够；如果从唯物论的发展观来看，事物总是螺旋式向上发展的，周期中同时也蕴含着一些不可逆的改变。把 2019 年放在历史的长河中，我不知道它处在世界发展周期的哪个部分，但很可能不是在「好」（大部分人认为的世俗意义上的「好」）的那一半。这可能是前些年某些事件的发生导致了现在的局面，同时也可能是未来很长一段时间不同局面的开始。
我所感知到的 2019 年，不算好，但好过 2018 年，因为在 2019 年明显可以看到一些好的发展的希望。事情多不一定会让人感觉到累，但感受不到希望是一定会让人想要逃离的。不过，希望仅仅是一种未来往好的方向发展的可能，当变化越来越快的时候，希望也是越来越脆弱的，希望远不是必然。
Elixir 作为基于 Erlang/OTP 的年轻语言，拥有良好的并发模型设计，在 Web 场景下对于实现能承载高并发的服务毫无问题。有好事者对比过包括 Phoenix 在内不同的 Web Framework 的性能，可见如果采用 Phoenix/Plug 来实现 Web Server 在性能上不会有太大的问题（代码实现良好的情况下）。所以，本文不会讨论真正的工业生产环境下整个系统的性能状态，因为系统性能受到很多因素的影响，具体编程语言的运行时的执行效率往往不是真正的问题所在，与其考虑编程语言本身的运行时效率，不如探讨系统在具体架构和实现上如何能优化来承载更高的负载来得实际。在生产环境中，我们可以借助 APM 服务来监控系统状态和性能指标。
由于 Elixir 本身是基于 Erlang 的更高层次的抽象，所以直觉上我们会觉得 Elixir 在运行性能上应该比 Erlang 本身要差一些。实际情况是不是这样呢？Elixir 相比于 Erlang 而言，为我们提供了一些可以快速调用的高阶函数库，典型的有 Enum、Stream，提高了日常实现需求的开发效率，可以让代码实现得更清晰且更易维护。而更高的抽象又几乎必然意味着底层的实现逻辑需要更通用健壮，从而也会更复杂。更高的抽象程度似乎天然与更高的运行效率有着内在的矛盾。本文的焦点在 Elixir 代码的运行性能，即对于实现同样的功能，用哪样的 Elixir 实现方式会让代码在运行时跑得更快。
稳定高效的进行数据处理几乎是如今每一家互联网公司都要面临的课题，尤其是对于专注于气象数据研究的我司而言，做数据分析和 ETL 的工作是整个公司业务很重要的一部分。在脱离了原始的「刀耕火种」的时代之后，我们内部一直在使用 Airflow 作为数据处理流程的框架来管理日常的数据流任务。其实我们也调研了很多其他的方案，最后还是选定了看起来相对比较可靠也比较符合我们业务需求的开源项目 Airflow 来做这个事情，虽然在使用的过程中确实也遇到了不少坑。当时这个项目还在 Apache Incubator，目前已经顺利毕业了。
简单介绍一下 Airflow，一般由 WebServer（一套完整的 UI 界面用于随时查看任务的执行状态并可以手动执行一些操作）、Scheduler（用来做任务的调度和管理）、Worker（真正执行任务的部分，可能有很多个）组成。这是一个常见的分布式架构，你只需要把任务流的 DAG 用 Python 代码写好，然后配置好触发条件就可以让它长期运行下去。在实际生产环境中，我们大量使用了 Celery Executor 来把任务动态分布到多个 Worker 上执行。