读数据工程之道：设计和构建健壮的数据系统13无服务器

1. 无服务器 1.1. 云供应商的一个大趋势是无服务器，允许开发人员和数据工程师无须在后台管理服务器即可运行应用程序 1.1.1. 无服务器快速将价值投入到其正确的用例 1.2. 无服务器真正开始流行是在2014年AWS Lambda全面投入使用之后 1.2.1. 由于无须管理服务器，只需在无服务器的基础上执行小型所需的代码块，无服务器人气迅速提升 1.2.2. 它受欢迎的主要原因是低成本和便利性 1.3. 无服务器有很多种 1.3.1. 功能即服务(Function as a Service，FaaS)广受欢迎，并早于AWS Lambda的出现 1.3.2. Google Cloud的BigQuery是无服务器的，因为数据工程师无须管理后端基础设施结构，系统自动扩展以处理从小到大的查询 1.4. 你支付的金额取决于查询消耗的数据量和少量存储数据的成本 1.4.1. 其为消费和存储付费的模式正变得越来越普遍 1.5. 无服务器也有固有的开销低效的问题 1.5.1. 以高事件率处理每个函数调用一个事件会带来灾难性的成本，而更简单的方法（如多线程或多进程）是很好的选择 1.6. 监控确定真实环境中每个事件的成本和无服务器执行的最长时间，并对每个事件的成本建模以确定随着事件速率的增长的总体成本 1.6.1. 建模还应该包括最坏的情况 1.7. 当无服务器的使用和成本已经超过自己维护一个服务器的成本时，选择无服务器就意义不大了 1.7.1. 在一定规模上，无服务器的经济利益可能会减少，并且搭建服务器变得更有吸引力 1.7.2. 定制化、强大功能和易于控制是青睐于服务器的其他主要原因 1.8. 服务器故障将发生 1.8.1. 避免使用“特殊雪花”服务器，它们是高度定制化且脆弱的，这会在你的架构中引入一个明显的薄弱环节 1.8.2. 如果你的应用程序需要在服务器上安装特定代码，请使用启动脚本或者构建镜像，然后使用CI/CD管道将代码部署到服务器 1.9. 使用集群和自动扩展 1.9.1. 利用云能够根据需求的增长和缩减来计算资源的能力 1.10. 将你的基础设施当作代码 1.10.1. 自动化不仅仅适用于服务器，还应该尽可能扩展到你的基础设施中 1.11. 使用容器 1.11.1. 对于更复杂或更繁重的多依赖性工作，考虑在单个服务器上或Kubernetes上使用容器 1.12. 无服务器是否适合你 1.12.1. 工作负载大小和复杂性 1.12.1.1. 无服务器最适合简单、离散的任务和工作负载 1.12.1.2. 如果你有许多活动部件或需要大量计算、内存则不太合适 1.12.2. 执行频率和持续时间 1.12.3. 请求和网络 1.12.3.1. 无服务器平台通常使用某种简化的网络，而不是支持所有云虚拟网络功能 1.12.4. 语言 1.12.4.1. 如果它不是官方无服务器平台支持的语言之一，那么你反而应该考虑容器 1.12.5. 运行时限制 1.12.5.1. 无服务器平台不会为你提供完整的操作系统抽象 1.12.5.2. 相反，你会受限于特定的运行时 1.12.6. 成本 1.12.6.1. 无服务器功能非常方便，但可能很昂贵 1.12.7. 抽象往往更加好 1.13. 建议首先考虑使用无服务器，然后是服务器（如果可能配合容器和编排），如果规模较大成本较高，使用服务器 2. 容器 2.1. 将无服务器和微服务相结合，容器是最强的操作技术发展趋势之一 2.1.1. 容器能在无服务器和微服务中都发挥作用 2.2. 容器通常被称为轻量级虚拟机 2.2.1. 传统的VM包括了整个操作系统，而容器只包括了一个孤立的用户空间（例如文件系统和一些进程），许多这样的容器可以共同存在于单个主机操作系统上 2.2.1.1. 和完整VM相比，容器集群不提供同样的安全性和隔离性 > 2.2.1.1.1. 虽然Amazon EC2是一个真正的多租户的环境，许多客户的虚拟机托管在同一环境硬件中，但Kubernetes集群应该只存放在一个相互信任的环境中 2.2.1.2. 容器逃逸 > 2.2.1.2.1. 从广义上解释，指一类利用容器中的代码获得外部操作系统级别权限的漏洞 > 2.2.1.2.2. 是很常见的一种多租户的风险 2.2.1.3. 代码审查流程和漏洞扫描对于确保开发人员不引入安全漏洞也至关重要 2.2.2. 这样做的主要好处是虚拟化（即依赖和代码隔离），无须支付整个操作系统内核的开销 2.3. 单个硬件节点可以承载多个具有细粒度资源的容器 2.4. 容器上运行的就是一种无服务器环境 2.4.1. Kubernetes也是一种无服务器环境，因为它允许开发人员和运营团队部署微服务并且无须担心部署的细节 2.5. 容器为分布式单体问题提供了部分解决方案 2.6. 各种类型的容器平台为无服务器增加了新的功能 2.6.1. 功能容器化的平台由事件来触发容器而不是一直运行着容器 2.7. 抽象将继续在数据技术栈中发挥作用 3. 基准战争 3.1. 要么比较针对完全不同用例进行优化的数据库，要么使用与现实世界需求毫无相似之处的测试场景 3.2. 数据领域充满了无意义的基准 3.3. 20世纪90年代的大数据 3.3.1. 声称支持PB级“大数据”的产品通常会使用足够小的基准数据集，可以轻松放入智能手机的存储空间中 3.4. 无意义的成本比较 3.5. 非对称优化 3.5.1. 非对称优化的欺骗以多种形式出现 3.5.2. 标准化数据模型对于基于行的系统是最佳的，但列式系统在其他的框架下才能展示出全部潜力 3.5.3. 供应商通过额外的连接优化来增强它们的系统，而没有在竞争数据库中应用相匹配的调优 3.6. 买者自负 3.6.1. 与数据技术中的所有事物一样，买家要当心 3.6.2. 要先做功课去了解，以避免盲目依赖供应商基准来评估和选择技术 4. 底层设计及其对技术选择的影响 4.1. 无论你选择何种技术，一定要了解它如何支持数据工程生命周期里的底层设计 4.2. 数据管理是一个广泛的领域，就技术而言，一项技术是否将数据管理作为主要关注点并不总是很明显 4.2.1. 合规性、安全性、隐私、数据质量和治理 4.2.2. 你如何保护数据免受来自外部和内部的破坏？ 4.2.3. 你的产品是否符合GDPR、CCPA和其他数据隐私法规？ 4.2.4. 你是否允许我托管我的数据以遵守这些规定？ 4.2.5. 你如何确保数据质量以及我在你的解决方案中查看的数据是否正确？ 4.3. DataOps 4.3.1. 问题总是会出现 4.3.1.1. 服务器或数据库可能会死亡，云的区域可能会中断，你可能会部署错误代码，这可能将错误数据引入你的数据仓库，也可能会出现其他无法预料的问题 4.4. 数据架构 4.4.1. 良好的数据架构意味着评估权衡和选择最适合工作的工具，同时保持你的决定的可逆性 4.4.2. 数据格局以极快的速度变化着，现在最佳工具是一个移动目标 4.4.3. 主要目标是避免不必要的锁定，确保不同技术栈的互操作性，并产生高投资回报率 4.5. Airflow 4.5.1. 编排领域目前由一种开源技术Apache Airflow主导 4.6. 软件工程 4.6.1. 应该努力简化和抽象整个数据技术栈 4.6.2. 对金融科技平台提供支持的特定的算法 4.6.3. 通过抽象出大量冗余的工作流和过程，你可以继续削减、改进和定制那些推动业务发展的东西