mod

极客时间专栏/大规模数据处理实战/模块六 | 大规模数据处理的挑战与未来/37 | 5G时代，如何处理超大规模物联网数据.md

@@ -0,0 +1,107 @@
+<audio id="audio" title="37 | 5G时代，如何处理超大规模物联网数据" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/53/01/53a07ba30bf88f14d76454de45a62901.mp3"></audio>
+
+你好，我是蔡元楠。
+
+时间过的真快，转眼间我们已经结束了前五个模块的学习，来到了最后一个模块“大规模数据的挑战和未来”。
+
+一门技术类课程的常见学习路线就是“过去→现在→未来”。这个专栏也是如此，我们首先研究了大数据处理技术的发展历程，从MapReduce出发，深入剖析了它的设计思路和优缺点。接下来结合具体的例子，一起学习了当下最流行的数据处理框架Spark和Apache Beam。
+
+在这个过程中，你不难发现，任何一门技术的出现都是为了解决实际问题，改进之前的技术所存在的缺陷，而贯穿整个课程的两大场景就是**批处理**和**流处理**。
+
+Spark在MapReduce的基础上不断改进，在批处理这方面有良好的性能，在流处理上也在不断提高。Apache Beam更是一个统一批处理和流处理的框架。
+
+正如我在开篇词中写到的，我理想中的专栏是一份与你一同成长的计划。虽然我们已经对当下流行的技术有了深入的了解，但是作为一名架构师，你的目光一定要放长远，要时刻对未来5～10年，乃至20年的新问题和技术发展方向保持了解，不能固步自封，只满足于现状。毕竟，我们的征途是星辰大海。
+
+在模块六中，我将列举三个大数据处理技术未来的方向，带你了解这些问题的挑战和难度，并学习现有的解决方案。希望通过这一模块的学习，你可以对大数据处理的未来有一些初步的认识，并强化自己学习新知识的能力。
+
+## 什么是物联网？
+
+物联网（Internet of Things）应该是一个你经常听说的名词，不过，你真的了解它吗？让我先来简要介绍一下什么是物联网吧。
+
+你可以将物联网的功能看作“使用嵌入在物理环境中的网络连接设备，来改进现有流程，或启用以前无法实现的新场景”。这些设备或事物连接到网络后，可以提供它们使用传感器从环境中收集的信息，或允许其他系统通过执行器连接，并作用于现实世界。
+
+<img src="https://static001.geekbang.org/resource/image/09/a1/09735e83c485dcdfd69c4a5c2d30d6a1.png" alt="unpreview">
+
+它们可以是我们个人拥有并随身携带的设备（比如手表、眼镜），或留在家中的设备（比如电视、空调、音响等智能硬件），也可能是联网的工厂设备或机器，还可能是城市中的公共设施（比如停车场、公交车）。
+
+想象一下，未来我们身边的所有物体，都有可能连入互联网，我们的生活将变得无比便捷。每个设备都能将来自现实世界的有价值信息转换为数字数据，从而有效改善人类与各类产品的交互方式。
+
+物联网可以被广泛应用在生活的各方各面，比如智能家居、智能交通、智能工厂、智能医院、智能物流等。
+
+- 智能家居：这可能是你对物联网应用了解最多的方面。家里的各种电器，乃至防盗门窗，都可以连入物联网，我们可以通过手机或者电脑远程操控所有电器。如果有异常情况，比如着火或者小偷进入，都可以及时发现并采取措施。
+- 智能交通：在公路和铁路的关键点设置传感器，可以监控交通基础设施的运作状况，以及监控特殊事件，比如交通流量的变化和道路拥堵的发生。这些物联网传感器发回到总部的信息，可以用来向每辆汽车通知拥堵点，并提供备用路线。在停车场设置传感器和摄像头，也可以向每个人提供车位信息。
+- 智能工厂：工厂的所有机器设备都可以连入网络，我们可以通过各类传感器来获得实时的机器设备数据与性能，并把它传入控制中心。通过对这些数据进行实时处理，我们可以自动预测设备何时需要维护、实时优化设备性能、预测停机时间、检测异常、跟踪设备状况和位置。工厂的自动化程度将大大提高。
+- 智能医院：病人可以在身上佩戴检测身体基本指标的手环，每时每刻把身体信息发回数据处理中心，医院就可以实时了解病人的身体情况。一旦有异常情况发生，还可以自动呼叫救护车。
+- 智能物流：卡车配备传感器之后，可以追踪一路上的运送情况，选择最佳运送路线，追踪时间等。在有些情况下，传感器还用于追踪驾驶员的速度、刹车习惯等，数据处理终端可以选择最安全、最环保的驾驶路线。
+
+物联网的世界充分体现了大规模数据的四个特点——多样性、大规模、高速率和真实性。
+
+1.多样性
+
+说数据是具备多样性的，你很容易理解。这是因为物联网涉及的应用范围很广，就如我刚才提到的智能家居、智能交通、智能工厂、智能医院等。
+
+从广义上讲，生活中的各方各面都可以应用物联网。而且，在不同的领域和行业，需要面对的应用数据的类型、格式也不尽相同，这些都是物联网多样性的体现。
+
+2.大规模
+
+之所以说物联网数据规模庞大，是因为它的节点是海量的，它不像互联网，局限于手机或者电脑。
+
+想象一下，你的眼镜、手表、音响、空调、冰箱、电视……这些全部都成为了物联网的节点。而且，这些设备是24小时不间断地提供数据的，数据的生成频率远高于互联网。所以，物联网的实时数据规模是非常大的。
+
+3.高速率
+
+物联网中的数据速率比常见的大数据处理场景要更高。由于前面数据“大规模”的特点，物联网要求数据处理中心能处理更多的数据。同时，为了满足物联网的实时响应，数据的传输速率也要更高才行。
+
+举个例子，如果速率不够高、不够实时，那么汽车的自动驾驶就会危险重重。因为它与真实物理世界直接相关，需要能实时访问、控制相应的节点和设备才能完成安全的驾驶。只有高数据传输速率才能支持它的实时性。
+
+这也是为什么物联网是最近十年才发展起来的原因，十几年前的通信和网速很难达到这样的要求。
+
+4.真实性
+
+我们都知道，物联网的数据来源于真实世界，而且要根据数据分析处理后的结果，对真实世界中的设备发送指令采取相应的操作，最终会作用于真实世界。所以，物联网对数据真实性要求很高。
+
+由此可见，在物联网的世界中，构建一个可靠的、处理速度快的大规模数据处理方案尤其重要。
+
+## 处理物联网数据的架构
+
+一个基本的物联网数据处理pipeline就如下图所示：
+
+<img src="https://static001.geekbang.org/resource/image/03/27/03b8920e39c1ef8f7683e3342324b027.png" alt="">
+
+你可以看到，在这个pipeline中，各个设备终端不断地向数据接收层发送数据。在这一层，数据被清洗，并且转换为统一的格式，然后发送到数据分析层进行分析。在分析过后，处理过的数据可以被存储下来。基于存储的数据，我们可以创建各种dashboard来展示，这也方便管理人员直观地观察数据。
+
+如果分析之后发现需要某些设备采取特定的操作，这些信息可以从数据分析层传送回设备控制层，从而向终端设备发送相应的指令。
+
+各大云服务厂商都提供物联网数据处理的解决方案。
+
+对于数据接收层，市场上有Google IoT Core、IoT Hub、Azure Event Hub等产品，它们可以接收各类设备发送的数据，并对它们进行管理。数据分析层就是我们进行数据处理的地方，可以用Spark、Hadoop、Azure DataBricks或者Google Cloud Dataflow等平台进行分析。数据存储层则是各类分布式存储系统如Google Cloud BigQuery、HBase、Amazon S3等。如果要基于数据创建dashboard，可以用Google Cloud Datalab等交互式分析工具。
+
+以Google Cloud Platform为例，它提供的物联网数据处理基本架构如下图所示：
+
+<img src="https://static001.geekbang.org/resource/image/f5/4a/f53e4f3754f8467285f1cf812d5e3a4a.png" alt="">
+
+终端数据经过Cloud IoT Core的清洗并转换成统一的格式之后，被发送到Cloud Pub/Sub这个消息队列中，我们可以配置不同的数据分析工具来订阅Pub/Sub中的消息。
+
+Cloud Functions是一个事件驱动的无服务器计算平台，利用它可以对数据进行实时处理，并无需配置服务器。Cloud DataFlow是Google Cloud提供的基于Apache Beam的批流数据统一处理平台，它可以将数据存入Big Query，还可以配置Google Cloud Machine Learning来对物联网数据进行训练，得到相应的数据模型。数据分析的结果可以传回Cloud IoT Core，通过它来对终端设备发送指令。
+
+在实际应用中，物联网的数据处理场景分不同的类型。
+
+有的场景数据量小、处理简单，但是对实时性要求高；有的场景数据量大，处理比较复杂，而且需要综合历史数据。
+
+基于这两种分类，有人提出了“Device-Edge-Cloud”（设备-边缘-云）的架构，即把简单的、需要实时计算和分析的过程放到离终端设备更近的地方，如设备本身、网关或者服务器，以保证数据数据处理的实时性，同时也减少数据传输的风险，即我们常听说的边缘计算；把复杂的、需要存储的数据处理放在Cloud上。这样可以大大加快简单操作的分析和响应速度。
+
+在上面的架构中，除了物联网设备以外的部分，都部署在Google Cloud上。结合边缘设备处理的特性之后，Google Cloud的物联网数据处理架构就如下图所示：
+
+<img src="https://static001.geekbang.org/resource/image/1c/2f/1cc5b49b4c2ca6b0b794912694e2fb2f.png" alt="">
+
+## 小结
+
+物联网是当今大规模数据处理的一大热点。今天我们初步了解了物联网的应用场景，产生数据的特性，以及基本的物联网数据处理架构，并以Google Cloud Platform为例，带你一起了解了一个成熟的物联网云服务平台都有怎样的特性。你可以去看看其他的云服务厂商所提供的物联网数据处理平台，比如微软的Azure IoT Hub，比较一下它们的异同。
+
+## 思考题
+
+都说在5G时代，边缘计算是一个非常重要的技术。你能去了解一下边缘计算，然后告诉我为什么可以这么说吗？
+
+欢迎你把自己的学习体会写在留言区，与我和其他同学一起讨论。如果你觉得有所收获，也欢迎把文章分享给你的朋友。
+
+

极客时间专栏/大规模数据处理实战/模块六 | 大规模数据处理的挑战与未来/38 | 大规模数据处理在深度学习中如何应用？.md

@@ -0,0 +1,117 @@
+<audio id="audio" title="38 | 大规模数据处理在深度学习中如何应用？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/c5/6f/c5f15d7ace5e126d6be0d007550e656f.mp3"></audio>
+
+你好，我是蔡元楠。
+
+今天我要与你分享的主题是“大规模数据处理在深度学习中如何应用？”。
+
+“深度学习”这个词，既是一个人工智能的研究领域，也概括了构建人工神经网络的技术方法。2012年的AlexNet，2015年的Google Inception V3级数式地打破ImageNet计算机视觉比赛的最高纪录，2017年亮相的AlphaGo更是掀起了全球的深度学习风暴。
+
+在Google，深度学习系统被应用在预测广告的点击率、推荐用户可能喜爱的视频、生成更接近人类的机器发声、自动生成邮件回复等几乎所有产品线。
+
+<img src="https://static001.geekbang.org/resource/image/61/94/61410804678a8525c75991e9fb6dc694.png" alt="">
+
+很多人并不理解深度学习技术，我经常见到这样几种误区：
+
+1. 觉得深度学习是最近几年才兴起的技术；
+1. 觉得深度学习只是一个技术时髦（就像今年流行Python，明年流行Go语言一样）；
+1. 觉得深度学习只是算法模型。
+
+要打破这些误区，我们必须深刻地理解超大规模数据在深度学习的发展中到底扮演了一个怎样的角色。
+
+## 大规模数据在深度学习发展中扮演的角色
+
+事实上，类似于模拟神经网络的计算机方法早在20世纪60年代就被提出来了。
+
+当时通信领域大神香农也在神经网络领域有所涉猎。但是在60年代到90年代的几十年间，深度学习虽然想法新颖、听起来很好，但是在实际上，人们发现以当时的计算能力根本没法训练神经网络。反而是像决策树，SVM等非神经网络的方法大放异彩。
+
+所以，从20世纪下半叶到2010年代究竟是什么让深度学习成了世界的焦点呢？一根火柴是点不着的，只有把一根火柴扔进汽油罐里里才会爆炸。想要知道这个答案，我们需要结合技术发展的背景来看最近的十年有哪些改变？
+
+芯片技术处在摩尔定律的末期，几乎每两年翻一番，云计算服务的兴起使得强大的计算能力变得容易获得。互联网的快速发展和以2007年发布iPhone为标志的移动互联网时代的到来，使得互联网用户的数量和使用时长都翻了好几倍，科技公司因此积累了比以往多得多的数据。
+
+讲到这里，你肯定明白了，正是因为强大的计算能力和大规模数据突然变得可获得，人们一下子发现曾经遥不可及的神经网络方法真的可以被计算了，才引发了深度学习的爆发性发展。
+
+即使是现在也是如此，在数据量并不充足的人工智能任务上，人们会发现还是传统方法表现更好，然而一旦数据量上来了，深度学习就会碾压式地击败所有传统方法。
+
+理解了大规模数据在深度学习发展中扮演的主要角色，我们再来看看为什么说，以大规模数据驱动的深度学习将是一次不可逆的影响深远的技术变革。
+
+这就得从最近十年哪些“没有变”说起。
+
+我们看到，计算机的发展从有一个房子那么大的巨型机，到个人电脑，再到智能手机。表面上看，计算机体积变得更小了，然而实际上是人们想要计算更个性化、更私密的需求没有改变。而只有深度学习才能满足更个性的计算需求，无论是给你推荐你喜欢的音乐，还是分析你的健康记录。
+
+工业生产的发展从人力，到蒸汽机，再到电能和计算机。人们想要解放繁重的重复劳动的需求从来没有改变。而只有深度学习才能满足下一波劳动力的解放，也就是重复的脑力劳动。这些影响力都是别的技术时髦远远不能相比的（比如今年流行这个前端框架，明年流行那个前端框架，今年流行这个语言，明年流行那个语言）。我们看一个技术的影响力，就是看这个技术能够解决哪些曾经不能解决的问题。而深度学习技术所能解决的新问题，几乎涵盖了人类社会发展的各个方面。
+
+在了解了深度学习的巨大影响力和大规模数据在深度学习技术中的重要角色后，我们结合案例来具体看看，在一个由深度学习驱动的技术产品或者技术系统周期中，大规模数据处理技术是怎样被应用的呢？
+
+最后你会发现，大规模数据处理技术几乎无处不在。你甚至可能会感叹，深度学习系统实际上就是一个复杂的大规模数据处理系统。事不宜迟，我们现在就来看看。
+
+一个深度学习驱动的产品周期一般按时间顺序分为这样几个阶段：
+
+1. 数据搜集整理；
+1. 深度学习模型开发；
+1. 部署和测试深度学习模型；
+1. 形成数据闭环反馈不断优化深度学习模型。
+
+## 数据搜集整理 (Data Curation)
+
+数据搜集整理就是针对你需要训练的深度学习问题收集所需要的数据。
+
+比如，你要研发在线广告点击率的预测模型，你可能需要搜集用户的网页点击行为历史，网页链接的属性等数据。
+
+如果你要研发之前提到的美团股价预测模型，你可能需要去搜集街上的美团外卖电动车图片。这种数据搜集整理的任务时间跨度可能很大，也可能涉及很多非技术的因素，比如需要去和合作公司谈判数据授权等等。
+
+数据的搜集整理是任何AI系统开发的第一步，可以说没有数据就没有AI。
+
+要注意，并不是只有监督学习需要高质量的数据，实际上无监督学习也需要高质量的数据。比如，在自然语言理解的无监督预训练步骤，你也需要根据训练任务选择高质量的文本库，比如中文文本库，或者医学文本库（如果你要针对医学病例训练模型）。
+
+抛开这些非技术因素不谈，数据搜集整理的技术复杂度也是非常高。我们往往用data massage——给数据按摩，来形容数据搜集整理技术工作是一份并不容易的，十分需要技巧和力量的工作。
+
+因为你的数据来源会非常多，每个数据源的格式可能都不一样，不同数据源提供的数据种类也会有不同，数据源直接甚至可能会相互矛盾。在实际应用中，数据搜集整理的技术部分经常是由很多个大规模数据处理流水线组成。
+
+<img src="https://static001.geekbang.org/resource/image/44/c7/449ebd6c5950f5b7691d34d13a781ac7.jpg" alt="">
+
+在我们在[第1讲](https://time.geekbang.org/column/article/90081)中介绍的美团外卖电动车搜集案例中，我们就介绍了数据搜集系统的复杂度。的确，一般来讲，你至少需要多个数据处理流水线去完成以下几项任务：
+
+1. 消化外面的数据；
+1. 对数据进行各种转换，变成你想要的结构和格式；
+1. 清理数据，比如不准确的数据要找出来，送给人工单独审核和处理；
+1. 如果由人工审核，你还需要数据处理流水线能够处理人工审核结果。
+
+这些数据处理的流水线可能用一整个专栏的篇幅都无法罗列完。你看在计算机视觉领域鼎鼎有名的ImageNet，到现在已经花了10多年整理收集，才取得现在这样非常干净、丰富、准确的状态。你就能明白，数据搜集整理本质上就是大规模的训练样本数据处理。
+
+## 深度学习模型开发 （Modeling）
+
+看到这，你可能会觉得：深度学习的模型开发阶段是不是总算没有数据处理什么事了？看起来都是算法啊，数学啊？完全不是的。
+
+当我们在实验深度学习模型时候，许多时间都花在了数据处理上。经常要做的事情是，先去分析一下拿到手上的样本数据。
+
+比如，在使用皮肤的照片分类良性的痣还是黑色素瘤时，肯定会先去看一下样本中良性和恶性的分布比例。如果分布很不均匀，比如黑色素瘤的样本只有1%时，很容易影响我们模型的表现。那就需要考虑别的方法，比如使用不同的损耗函数，过采样较少的分类样本等等。
+
+除了数据分析以外，许多深度学习模型的架构设计都需要大规模的数据处理能力。比如，在hard negative mining技术中，我们需要使用数据处理技术把检查点的深度模型在数据集上都跑一遍，来找出值得加入训练集的样本。
+
+## 部署和测试深度学习模型 （Deployment）
+
+部署和测试深度学习模型，其实就是把模型工程化为一个提供结果预测的服务。这样的服务，本质上就是一个数据处理的流水线，它可以是批处理流水线，也可以是流处理流水线。
+
+比如，我们部署广告点击率预测模型时，最终我们肯定是根据用户的浏览场景选择点击率高的广告，这样才能去展示点击率高和用户的网页浏览最相关的广告。然而可供选择的候选广告可能有几千万个。如何快速地把所有这样几千万个候选广告的点击率全部预测一遍，这就是一个大规模数据的批处理问题。
+
+具体提供深度学习模型推理服务的可能是TensorFlow Servo。但是真正用在生产环境时，我们都需要把Servo封装成一个大规模数据处理系统。
+
+## 形成数据闭环反馈不断优化深度学习模型（Feedback and improvement)
+
+你的深度学习产品上线后，依然需要大规模数据处理技术。比如你提供自动聊天回复功能，能够根据一个微信对话的上下文自动推荐一些合适的回复。如果别人说“明天一起吃饭好不好？”，你可以推荐回复“好”。
+
+那么，像这样的功能上线后，你怎样评估这个深度学习模型的效果呢？你需要去跟踪用户与这个功能的交互。
+
+比如，有多少用户会去选择你推荐的回复，又有多少用户会不选择你推荐的回复而自己打字呢？通过这些追踪的用户行为，你就能利用大规模的数据处理技术，不断地为你的深度学习模型提供更多现实的数据，去进一步训练改进模型。也能利用用户行为去评估当前模型的表现。
+
+## 小结
+
+这一讲，我们首先学习了大规模数据在深度学习几十年的发展中所扮演的至关重要的角色。然后我们一起看了在一个深度学习驱动的产品周期里的各个阶段，有哪些大规模数据处理的任务。相信通过这一讲，你一定能感受到大规模的数据处理技术就是深度学习系统的奠基石。
+
+## 思考题
+
+除了这一讲中提到的这些应用，你还能想到哪些大规模数据处理技术在深度学习系统中的应用呢？
+
+欢迎你把自己的学习体会写在留言区，与我和其他同学一起讨论。如果你觉得有所收获，也欢迎把文章分享给你的朋友。
+
+

极客时间专栏/大规模数据处理实战/模块六 | 大规模数据处理的挑战与未来/39 | 从SQL到Streaming SQL：突破静态数据查询的次元.md

@@ -0,0 +1,135 @@
+<audio id="audio" title="39 | 从SQL到Streaming SQL：突破静态数据查询的次元" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/6f/df/6f4cfd98f48cc11d8bff5989eae8d1df.mp3"></audio>
+
+你好，我是蔡元楠。
+
+今天我要与你分享的主题是“从SQL到Streaming SQL：突破静态数据查询的次元”。
+
+在前面的章节中，我们介绍了一些流数据处理相关的知识和技术，比如Apache Spark的流处理模块——Spark Streaming和Structured Streaming，以及Apache Beam中的窗口处理。相信你对流处理的重要性和一些基本手段都有所了解了。
+
+流处理之所以重要，是因为现在是个数据爆炸的时代，大部分数据源是每时每刻都在更新的，数据处理系统对时效性的要求都很高。作为当代和未来的数据处理架构师，我们势必要深刻掌握流数据处理的技能。
+
+“批”“流”两手抓，两手都要硬。
+
+你还记得，我在[第15讲](https://time.geekbang.org/column/article/96256)中介绍过的Spark SQL吗？它最大的优点就是DataFrame/DataSet是高级API，提供类似于SQL的query接口，方便熟悉关系型数据库的开发人员使用。
+
+当说到批处理的时候，我们第一个想到的工具就是SQL，因为基本上每个数据从业者都懂，而且它的语法简单易懂，方便使用。那么，你也能很自然地联想到，如果在流处理的世界中也可以用SQL，或者相似的语言，那真是太棒了。
+
+这样的思想在[第17讲](https://time.geekbang.org/column/article/97121)中我们曾经提到过。
+
+Spark的Structured Streaming就是用支持类SQL的DataFrame API去做流处理的。支持用类似于SQL处理流数据的平台还有很多，比如Flink、Storm等，但它们是把SQL做成API和其他的处理逻辑结合在一起，并没有把它单独分离成一种语言，为它定义语法。
+
+那么，到底有没有类似SQL语法来对流数据进行查询的语言呢？答案是肯定的。我们把这种语言统称为Streaming SQL。Siddhi Streaming SQL和Kafka KSQL就是两个典型的Streaming SQL语言，下文的例子我们主要用这两种语言来描述。
+
+不同于SQL，Streaming SQL并没有统一的语法规范，不同平台提供的Streaming SQL语法都有所不同。而且Streaming SQL作用的数据对象也不是有界的数据表，而是无边界的数据流，你可以把它设想为一个底部一直在增加新数据的表。
+
+SQL是一个强大的、对有结构数据进行查询的语言，它提供几个独立的操作，如数据映射（SELECT）、数据过滤（WHERE）、数据聚合（GROUP BY）和数据联结（JOIN）。将这些基本操作组合起来，可以实现很多复杂的查询。
+
+在Streaming SQL中，数据映射和数据过滤显然都是必备而且很容易理解的。数据映射就是从流中取出数据的一部分属性，并作为一个新的流输出，它定义了输出流的格式。数据过滤就是根据数据的某些属性，挑选出符合条件的。
+
+让我们来看一个简单的例子吧。假设，有一个锅炉温度的数据流BoilerStream，它包含的每个数据都有一个ID和一个摄氏温度（t），我们要拿出所有高于350摄氏度的数据，并且把温度转换为华氏度。
+
+```
+Select id, t*7/5 + 32 as tF from BoilerStream[t &gt; 350];  //Siddhi Streaming SQL
+
+Select id, t*7/5 + 32 as tF from BoilerStream Where t &gt; 350; //Kafka KSQL
+
+```
+
+你可以看出，这两种语言与SQL都极为类似，相信你都可以直接看懂它的意思。
+
+Streaming SQL允许我们用类似于SQL的命令形式去处理无边界的流数据，它有如下几个优点：
+
+- 简单易学，使用方便：SQL可以说是流传最广泛的数据处理语言，对大部分人来说，Streaming SQL的学习成本很低。
+- 效率高，速度快：SQL问世这么久，它的执行引擎已经被优化过很多次，很多SQL的优化准则被直接借鉴到Streaming SQL的执行引擎上。
+- 代码简洁，而且涵盖了大部分常用的数据操作。
+
+除了上面提到过的数据映射和数据过滤，Streaming SQL的GROUP BY也和SQL中的用法类似。接下来，让我们一起了解Streaming SQL的其他重要操作：窗口（Window）、联结（Join）和模式（Pattern）。
+
+## 窗口
+
+在之前Spark和Beam的流处理章节中，我们都学习过窗口的概念。所谓窗口，就是把流中的数据按照时间戳划分成一个个有限的集合。在此之上，我们可以统计各种聚合属性如平均值等。
+
+在现实世界中，大多数场景下我们只需要关心特定窗口，而不需要研究全局窗口内的所有数据，这是由数据的时效性决定的。
+
+应用最广的窗口类型是以当前时间为结束的滑动窗口，比如“最近5小时内的车流量“，或“最近50个成交的商品”。
+
+所有的Streaming SQL语法都支持声明窗口，让我们看下面的例子：
+
+```
+Select bid, avg(t) as T From BoilerStream#window.length(10) insert into BoilerStreamMovingAveage; // Siddhi Streaming SQL
+
+Select bid, avg(t) as T From BoilerStream WINDOW HOPPING (SIZE 10, ADVANCE BY 1); // Kafka KSQL
+
+```
+
+这个例子中，我们每接收到一个数据，就生成最近10个温度的平均值，插入到一个新的流中。
+
+在Beam Window中，我们介绍过固定窗口和滑动窗口的区别，而每种窗口都可以是基于时间或数量的，所以就有4种组合：
+
+- 滑动时间窗口：统计最近时间段T内的所有数据，每当经过某个时间段都会被触发一次。
+- 固定时间窗口：统计最近时间段T内的所有数据，每当经过T都会被触发一次
+- 滑动长度窗口：统计最近N个数据，每当接收到一个（或多个）数据都会被触发一次。
+- 固定长度窗口：统计最近N个数据，每当接收到N个数据都会被触发一次。
+
+再度细化，基于时间的窗口都可以选择不同的时间特性，例如处理时间和事件时间等。此外，还有会话（Session）窗口等针对其他场景的窗口。
+
+## 联结
+
+当我们要把两个不同流中的数据通过某个属性连接起来时，就要用到Join。
+
+由于在任一个时刻，流数据都不是完整的，第一个流中后面还没到的数据有可能要和第二个流中已经有的数据Join起来再输出。所以，对流的Join一般要对至少一个流附加窗口，这也和[第20讲](https://time.geekbang.org/column/article/98537)中提到的数据水印类似。
+
+让我们来看一个例子，流TempStream里的数据代表传感器测量的每个房间的温度，每分钟更新一次；流RegulatorStream里的数据代表每个房间空调的开关状态。我们想要得到所有温度高于30度但是空调没打开的的房间，从而把它们的空调打开降温：
+
+```
+from TempStream[temp &gt; 30.0]#window.time(1 min) as T
+  join RegulatorStream[isOn == false]#window.length(1) as R
+  on T.roomNo == R.roomNo
+select T.roomNo, R.deviceID, 'start' as action
+insert into RegulatorActionStream; // Siddhi Streaming SQL
+
+```
+
+在上面的代码中，我们首先对TempStream流施加了一个长度为1分钟的时间窗口，这是因为温度每分钟会更新一次，上一分钟的数据已然失效；然后把它和流RegulatorStream中的数据根据房间ID连接起来，并且只选出了大于30度的房间和关闭的空调，插入新的流RegulatorActionStream中，告诉你这些空调需要被打开。
+
+## 模式
+
+通过上面的介绍我们可以看出，Streaming SQL的数据模型继承自SQL的关系数据模型，唯一的不同就是每个数据都有一个时间戳，并且每个数据都是假设在这个特定的时间戳才被接收。
+
+那么我们很自然地就会想研究这些数据的顺序，比如，事件A是不是发生在事件B之后？
+
+这类先后顺序的问题在日常生活中很普遍。比如，炒股时，我们会计算某只股票有没有在过去20分钟内涨/跌超过20%；规划路线时，我们会看过去1小时内某段路的车流量有没有在下降。
+
+这里你不难看出，我们其实是在检测某个**模式**有没有在特定的时间段内发生。
+
+股票价格涨20%是一个模式，车流量下降也是一个模式。在流数据处理中，检测模式是一类重要的问题，我们会经常需要通过对最近数据的研究去总结发展的趋势，从而“预测”未来。
+
+在Siddhi Streaming SQL中，“-&gt;”这个操作符用于声明发生的先后关系。一起来看下面这个简单例子：
+
+```
+from every( e1=TempStream ) -&gt; e2=TempStream[ e1.roomNo == roomNo and (e1.temp + 5) &lt;= temp ]
+    within 10 min
+select e1.roomNo, e1.temp as initialTemp, e2.temp as finalTemp
+insert into AlertStream;
+
+```
+
+这个query检测的模式是10分钟内房间温度上升超过5度。对于每一个接收到的温度信号，把它和之前10分钟内收到的温度信号进行匹配。如果房间号码相同，并且温度上升超过5度，就插入到输出流。
+
+很多流处理平台同样支持模式匹配，比如Apache Flink就有专门的Pattern API，我建议你去了解一下。
+
+## 小结
+
+今天我们初步了解了Streaming SQL语言的基本功能。
+
+虽然没有统一的语法规范，但是各个Streaming SQL语言都支持相似的操作符，如数据映射、数据过滤、联结、窗口和模式等，大部分操作符都是继承自SQL，只有模式是独有的，这是由于流数据天生具有的时间性所导致。
+
+Streaming SQL大大降低了开发人员实现流处理的难度，让流处理变得就像写SQL查询语句一样简单。它现在还在高速发展，相信未来会变得越来越普遍。
+
+## 思考题
+
+你觉得Streaming SQL的发展前景如何？欢迎留言与我一起讨论。
+
+欢迎你把自己的学习体会写在留言区，与我和其他同学一起讨论。如果你觉得有所收获，也欢迎把文章分享给你的朋友。
+
+

极客时间专栏/大规模数据处理实战/模块六 | 大规模数据处理的挑战与未来/40 | 大规模数据处理未来之路.md

@@ -0,0 +1,91 @@
+<audio id="audio" title="40 | 大规模数据处理未来之路" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/c1/4e/c1b6397fed5e39c6fa7f7a66c72d0e4e.mp3"></audio>
+
+你好，我是蔡元楠。
+
+今天我要分享的内容是“大规模数据处理实战”专栏的最后一讲。
+
+我相信通过整个专栏的系统学习，你已经掌握了大规模数据处理的基础概念与设计模式。同时，我也相信，专栏中对现实世界中常见的大规模数据处理架构的深入探讨，可以在解决现实难题时为你提供一些思路。
+
+但我更希望的是，通过模块六中对大规模数据处理在未来的应用与展望讲解，让你吃下一颗定心丸，那就是，大规模数据处理技术是在放眼未来的几十年中都依然会是炙手可热的一项技术，不会被淘汰。
+
+你不难发现，我在专栏的后半部分，花了不少的篇幅来专门介绍Apache Beam的各种概念、底层思想以及实际应用的。我个人是十分认同Google所推崇的Dataflow Model的计算模型，也相信未来Apache Beam的发展前景是很好的。
+
+所以在专栏的最后一讲，我想和你讲讲我对数据处理框架和对Beam的一些看法和展望。
+
+## 技术迭代带来的烦恼
+
+在专栏的后半部分，我们不断深入探讨了Apache Beam。有同学曾经在留言中提过一个问题：“我已经掌握好Spark了，也觉得Spark的语法更简练，为什么还需要学习Beam呢？”
+
+对于这个问题，我相信在你刚刚接触Beam的时候，多多少少都会有相同的疑问。
+
+我来给你举个例子，带你穿越时间，去看看一个常见的大规模数据处理框架在面临迁移时会遇到的烦恼。
+
+在2006年，Hadoop刚刚发布，在选择数据处理框架的时候，你的首选肯定是Apache Hadoop。当时Hadoop在开源社区横空出世，让所有工程师们都可以利用这个框架来处理自己的数据，尤其是利用Hadoop自带的MapReduce计算模型，可以让整个数据处理的效率有质的飞跃。
+
+而在2009年，Spark这个计算框架在加州伯克利大学的AMPLab实验室中诞生。2010年，Spark正式开源了。“Spark的数据处理效率远在Hadoop之上”的结论经过了业界的验证。2014年，Spark更是成为了Apache的顶级项目。
+
+如果你是在这个时候进入IT行业的工程师，更加可能选择直接学习Spark，而只会把少量时间放在Hadoop的学习上。在2014年进行创业的小公司同样可能也会直接使用Spark来进行底层数据处理基础设施的搭建。
+
+那之前已经花了很多时间在搭建Hadoop MapReduce作为公司基础设施的公司，或者是已经很深入学习了Hadoop的工程师这个时候该怎么办呢？
+
+一种做法是放弃现有的技术框架，重新花费大量时间去学习新的数据处理框架。这太累了。对于工程师来说，平时本来就有着做不完的任务和业绩压力，还需要抽空学习新的技术和进行代码的迁移，这无疑让工程师们有着非常大的压力和负担。
+
+当然，还有一种做法是保持现有的技术框架，不断优化现有基础设施，并且寄希望于老框架可以有新的功能发布让其性能得以提高。
+
+那我们再把时间往后推一点，到了2014年，也就是Flink项目刚刚面世的时候。这时候的互联网应用场景已经有了极大的变化，批处理加上流处理同时存在的状况常常遇见。而Flink除了在处理大规模数据有着极高效率之外，它的批流统一功能也恰恰是满足了这种批流处理同时存在的场景。
+
+2018年初，阿里巴巴更是看好Flink的前景，收购了Apache Flink背后的商业母公司——德国的Data Artisans。
+
+讲到这里，你不难发现，当有新的技术框架出现的时候，工程师就会陷入一个选择的困难，纠结到底是抛弃原有的技术架构，还是花大量时间去做技术迁移。
+
+其实，如果一开始就有Beam模型存在的话，你可能就不必有这个烦恼了。
+
+因为我们完全不需要担心某一个Runner，也就是具体的数据处理技术框架过时之后所带来的技术迁移成本。如果你想要完成底层处理框架的迁移，只需要更改一些Runner的接口就可以了。
+
+## Apache Beam能带来什么？
+
+那么，我们来看看对应用它的工程师来说，Apache Beam能带来什么？
+
+因为Apache Beam是根据Dataflow Model倡导API的实现的，所以它完全能够胜任批流统一的任务。同时，因为Apache Beam有着中间的抽象转换层，工程师可以从API中解放出来，不需要学习新Runner的API语法。这也就是我说过多次的“编写一套程序就可以放在不同的Runner上面跑”。
+
+除了对工程师来说能够极大地减少新技术学习的时间成本，Apache Beam还能够推动大规模数据处理领域的最新技术发展。
+
+从上面我所举的例子中你可以看到，在一项新技术从诞生到流行的过程中，可能会有很多公司因为技术迁移成本太大而选择放弃采用最新的技术，这其实还影响了新技术的传播使用。因为当一部分工程师选择留守原本技术框架的时候，新技术框架也就相应地缺少了这部分的用户群体。
+
+那我们来想象一下，如果所有的工程师都在使用Beam来进行项目编写的话会有什么样的效果。
+
+因为有了Beam的抽象层，你可以非常轻松地更换不同的底层Runner。这就意味着我们可以先选择一个处理数据效率最高的一个RunnerA。如果有其他的Runner优化了自身，比如RunnerB，从而拥有更高效率的时候，工程师们又可以将底层Runner换成RunnerB。
+
+这些Runner其实就是大数据处理框架的本身，像Spark、Apex、Storm、Flink这些数据处理架构。这对整个技术行业都可以起到一种良性的竞争。如果Runner要想争取更多用户的话，就必须努力提升自身数据处理的效率来让用户选择自己。
+
+做底层数据处理框架的工程师则可以专心优化自身的效率和增加自身的功能，而不必担心迁移。
+
+且Apache Beam还有着自己的社区。所以，在实际工程中如果遇到一些特别的、没有在官方文档中解释的问题，你就可以到社区去求助了。有了社区交流之后，全世界的工程师们都可以对自己的工程提出问题，解决问题，实现解决问题的思路。
+
+## Beam Runner功能的迭代速度
+
+最后你可能会问，Apache Beam的一些功能现在还没有，那还是先观望观望吧。那我来以Flink支持整个Dataflow的功能来告诉你Beam Runner功能的迭代速度有多快。
+
+Kostas Tzoumas（Data Artisans的联合创始人以及Flink的作者）在Beam出现的时候就表达过自己的看法，他坚信Beam Model是批流数据处理的正确编程模型。所以，在Dataflow Model论文发布之初，他们就根据Dataflow Model的思想重写了Flink的0.10版本的DataStream API。
+
+这整个过程花费了多少时间呢？
+
+在2014年的12月，Google正式发布Google Cloud Dataflow SDK。在2015年的1月，Data Artisans紧随Google的脚步，根据Dataflow Model的概念，开始了DataStream API的重写工作。
+
+在2015年3月，Flink已经可以对批处理进行支持了。到了2015年的12月，Flink可以支持设置窗口和水印的流处理。其实这个时候DataStream API已经很接近Dataflow Model的概念了。所以在2016年3月，Data Artisans正式开始在Apache Beam的Runner代码库中贡献Flink的Runner代码。
+
+在2016年5月的时候，Flink对批处理也支持了窗口的概念，同时也对整个批处理完成了集成测试（Integration Test）。在2016年8月，Flink完成了对流处理的集成测试。自此，Flink DataStream API宣告完成了对Dataflow Model的支持。
+
+整个过程从无到有，一共只花费了近一年半的时间。所以你完全可以不必对功能不完整抱有太多的担心。
+
+## 小结
+
+今天，我给你阐述了我自己对于Beam的一些看法，同时也希望借助我所举出的一些例子，能够让你明白Beam对于未来数据处理发展的重要性。
+
+## 思考题
+
+你对Apache Beam还有什么疑问吗？欢迎提问与我探讨。
+
+欢迎你把自己的学习体会写在留言区，与我和其他同学一起讨论。如果你觉得有所收获，也欢迎把文章分享给你的朋友。
+
+