读数据工程之道：设计和构建健壮的数据系统11云经济学

1.       部署位置

1.1.         当公司在决择在何处搭建技术栈时会有数不清的选择

• 1.1.1.           除非有令人信服的理由，否则不要选择复杂的多云或混合云策略

1.2.         本地

• 1.2.1.           当越来越多的初创公司在云技术下诞生，本地系统仍是默认的公司创立地

• 1.2.2.           公司也需要管理软件系统每几年的升级换代

• 1.2.3.           负责本地系统的数据工程师需要购买足够大的系统来确保高峰期间仍有好的性能，但也不能过度花费开支

• 1.2.4.           成熟公司的硬件建立了好的运营系统来为它们服务

• 1.2.5.           成熟的公司也会观察到更年轻的、更敏捷的对手大量快速地利用云托管服务

• 1.2.6.           竞争中的公司通常不能停滞不前

• 1.2.6.1.            竞争是强制的，并且常有被更敏捷的竞争对手“扰乱”的威胁，它们通常有大量风投资金的支持

• 1.2.6.2.            所有公司都必须在保证现有的系统能高效运转的基础上再决定下一步应该往哪里发展

1.3.         云

• 1.3.1.           云的出现颠覆了本地部署的模型

• 1.3.2.           公司不再需要购买硬件，而是简单地租用硬件和使用由云提供商管理的服务

• 1.3.3.           在云环境里，工程师无须担心长远的硬件计划就可以快速部署一个项目和实验

• 1.3.4.           PaaS包括IaaS的产品理念但加入了更复杂的管理服务来支持应用程序

• 1.3.5.           PaaS允许工程师忽略每个设备运营和分布式地部署各框架的细节

• 1.3.5.1.            提供了仅需少量运营管理就可以达成复杂的、自动扩展的系统的多种方法

• 1.3.6.           SaaS通常提供功能齐全的操作平台，几乎不需要管理人员运营

• 1.3.7.           无服务器产品一般都会提供从零到特大集群的自动扩展部署

• 1.3.7.1.            采用即付即得的模式，允许工程师在不了解基础设施的情况下也可以直接操作

• 1.3.7.2.            无服务器通常意味着有许多看不见的服务器

• 1.3.8.           云服务对拥有现有数据中心和IT基础设施的老牌企业越来越有吸引力

• 1.3.8.1.            动态无缝地扩展对有季节性和流量峰谷期的企业（如需要应对黑色星期五的零售业）越来越有价值

1.4.         混合云

• 1.4.1.           几乎没有企业能在一夜之间将所有的工作负载迁移到云上

• 1.4.2.           混合云模式假定一个企业将无限期地在云外保持一些工作负载

• 1.4.2.1.            企业可能认为它们已经在某些领域实现了卓越的运营

• 1.4.2.2.            企业可能只迁移它们在云环境中看到直接好处的特定工作负载

• 1.4.3.           把分析放在云中的模式是很好的，因为数据主要流向一个方向，把数据出口成本降到最低

• 1.4.3.1.            本地应用程序产生的事件数据基本上可以免费推送到云端

• 1.4.3.2.            大量的数据留在云中，在那里进行分析，而少量的数据则被返回到本地，用于部署模型到应用程序、反向ETL等

• 1.4.4.           新一代的托管混合云服务产品还允许客户将云托管的服务器放在他们的数据中心

1.5.         多云

• 1.5.1.           多云是指将工作负载部署到多个公有云上

• 1.5.2.           SaaS平台通常希望其服务接近客户现有云工作负载

• 1.5.2.1.            snowflake和Databricks在多云中提供他们的SaaS产品

• 1.5.3.           采用多云方法的另一个常见动机是利用几个云中的最佳服务

• 1.5.3.1.            鉴于主要云提供商之间的激烈竞争，预计它们会提供更多的最佳服务，使多云服务更加引人注目

• 1.5.4.           数据出口成本和网络瓶颈是关键

• 1.5.5.           走多云路线会带来巨大的复杂性

• 1.5.5.1.            跨云整合和安全是一个相当大的挑战

• 1.5.5.2.            多云网络可能是非常复杂的

• 1.5.6.           “云中云”的技术正在迅速发展

1.6.         区块链和边缘

• 1.6.1.           去中心化的运算

1.7.         企业内部的服务正变得越来越像云和抽象化

• 1.7.1.           由于云计算行业的竞争和变化速度很快，决策空间在五到十年后会有很大的不同

• 1.7.2.           在决策时，很容易去考虑每一种可能未来架构的排列组合

1.8.         要为现在做计划

• 1.8.1.           为你当前的需求和近期的具体计划选择最佳技术

• 1.8.2.           根据真正的业务需求选择你的部署平台，同时关注简单性和灵活性

1.9.         逃生计划

• 1.9.1.           每一种技术——即使是开源软件——都会有一定程度的锁定性

• 1.9.2.           单云策略在简单性和集成性方面有很大的优势，但也有很大的锁定性

• 1.9.3.           分析现状并想象替代方案的灵活性

• 1.9.4.           理想情况下，你的逃生计划会一直藏在背后，但准备这个计划会帮助你在当前做出更好的决定，并在未来事情出错时给你一个出路

2.       云经济学

2.1.         信用违约互换是一种出售不同等级资产附带风险的机制

2.2.         云提供商不仅仅将硬件资产切割成虚拟化的小块，而且将这些小块依据技术特点和风险分门别类

2.3.         GCP公开承认，其归档类云对象存储与标准云对象存储在相同的集群上运行，但归档存储每月每GB的价格大约是标准云存储的1/17

• 2.3.1.           在归档存储方面，供应商销售的是一种保险，这种保险在发生灾难时，赔付对象为保险人而不是保单的购买者

• 2.3.1.1.            每月的数据存储费用非常便宜，但如果我需要检索数据，则可能支付高昂的费用

• 2.3.1.2.            在紧急情况下，消费者会愿意支付高昂的费用

2.4.         存储集群中的每个磁盘有三个资产给云提供商和消费者使用

• 2.4.1.           有一定的存储容量

• 2.4.2.           支持一定数量的每秒输入/输出操作(Input/Output

Operation，IOP)

• 2.4.3.           磁盘支持一定的最大带宽，即最佳组织文件的最大读取速度

2.5.         在不出售IOP的情况下出售空的空间

• 2.5.1.           出售廉价的存储空间和昂贵的IOP来减少读取

2.6.         云供应商不只是对CPU核心、内存和功能收费，还对耐用性、可靠性、寿命和可预测性等特征进行货币化

2.7.         各种计算平台对短暂的或者在其他地方需要容量时可以随时中断的这一类工作进行折扣

2.8.         云≠本地

• 2.8.1.           许多新的技术产品被有意设计为看起来很熟悉的东西，以方便使用和加速采用

• 2.8.2.           任何新的技术产品都有一些微妙的地方，用户必须学会识别、适应和优化

• 2.8.3.           简单提升和转移是将企业内部的服务器一个一个地转移到云中的虚拟机上

• 2.8.4.           对于云迁移的初始阶段是一个完全合理的策略，特别是当公司面临紧急财务账单时，比如说如果现有的硬件没有关闭，就需要签署一份重要的新租赁或硬件合同

• 2.8.5.           让云资产处于这种初始状态的公司会在将来受到冲击

• 2.8.6.           在云中长期运行的服务器要比对应的本地服务器贵得多

2.9.         在云中寻找价值的关键是理解和优化云的定价模式

• 2.9.1.           与其部署一套能够处理全部峰值负载的长期运行的服务器，不如使用自动扩展功能，让工作负载在负荷较轻时缩减到最小的基础设施，而在高峰期则扩展到大规模集群

• 2.9.2.           可以促使成本降低，但我们也应该努力通过利用云的动态特性来提高商业价值

2.10.     数据引力

• 2.10.1.      数据工程师还需要注意云定价和折扣激励措施等其他方面

• 2.10.2.      将数据输入平台是很便宜或免费的，但将数据取出来可能是非常昂贵的

• 2.10.3.      数据引力是真实存在的：一旦数据落入云端，提取数据和迁移流程的成本就会非常高

3.       逆云而回

3.1.         公司在控制云计算支出上会花费大量的资源，并应该考虑将返回本地作为一个可能的选择

3.2.         Dropbox

• 3.2.1.           Dropbox的核心竞争力是一个差异化的文件更新系统，可以有效地在用户之间主动同步编辑的文件，同时最大限度地减少网络和CPU的使用

• 3.2.2.           Dropbox可以专注于其在云存储和数据同步方面的核心竞争力，同时将数据分析等领域的软件和硬件管理的工作分担到云上

3.3.         Backblaze

• 3.3.1.           Backblaze开始时是个人云数据备份产品，但后来开始提供B2

3.4.         Cloudflare

3.5.         Netflix

• 3.5.1.           没有使用AWS的内容分发网络，而是与互联网服务提供商合作建立了一个定制的CDN

• 3.5.2.           对于一家在所有互联网流量中占有相当大比例的公司来说，建立这种关键的基础设施，使其能低成本地向巨大的客户群提供高质量的视频

3.6.         在特殊情况下，公司管理自己的硬件和网络连接是有意义的

3.7.         如果你存储的数据量达到艾字节，或者每秒处理去向和来自互联网的流量达到太位，那么你可能已经达到了云规模

3.8.         如果数据出口成本是你的业务的主要因素，则考虑拥有自己的服务器

4.       构建与购买

4.1.         构建与购买是技术领域一个久远的辩论

• 4.1.1.           支持构建的论点是，你可以对解决方案进行端到端的控制，不受供应商或开源社区的限制

• 4.1.2.           支持购买的论点归结为资源限制和专业知识，你是否有专业知识来建立一个比现有供应的更好的解决方案？

4.2.         建议在构建和定制方面进行投资

4.3.         站在巨人的肩膀上，使用市场上已有的东西

4.4.         公司采用软件的方式正在发生变化

• 4.4.1.           现在的趋势是在公司内自底向上地采用软件，由开发人员、数据工程师、数据科学家和其他技术角色驱动

• 4.4.2.           公司内部的技术的采用正在成为一个有组织的、可持续的过程

4.5.         回答构建还是购买这个问题，需要了解你的竞争优势以及定制化资源投入在哪些地方是有意义的

• 4.5.1.           更喜欢开源软件和商业开源软件，这使你可以专注于改进这些领域的不足之处

• 4.5.2.           构建一些东西会显著增加价值或大幅减少竞争

4.6.         不要将内部运营培训开销视为沉没成本

• 4.6.1.           提高现有数据团队的技能，可以让团队在托管的平台上构建复杂的系统，而不是照看本地服务器，这是一件物超所值的规划

4.7.         最不希望发生的就是你对技术的选择因等待预算批准而陷入困境

• 4.7.1.           时间扼杀交易

• 4.7.2.           花费更多的时间意味着你的预算批准更有可能失败

• 4.7.3.           事先要知道谁控制预算以及如何才能够成功获得批准可以帮助你更快获得预算批准