1.1. 架构第一，技术第二
1.2. 现如今数据工程师因技术种类过于繁杂丰富而感到选择困难
1.3. 许多完整并可立即使用的数据技术触手可得
1.3.1. 开源代码
1.3.2. 托管开源
1.3.3. 软件专利
1.3.4. 服务专利
1.4. 数据工程核心：设计出可靠稳定的系统来承载数据全周期的流动，并满足不同终端用户的需求
1.4.1. 数据工程师的也需要选择合适的数据技术来引导数据在整个生命周期里为应用程序和用户服务
1.5. 判断数据技术好坏的标准是很简单的：选择这个技术有没有增加产品的商业价值
1.5.1. 数据工程师必须选择好的技术来尽可能实现最佳的数据产品
1.6. 数据架构是一种战略，而数据工具是一种战术
1.6.1. 数据架构是数据系统的高层设计、框架和蓝图，以使数据系统实现它的商业战略
1.6.1.1. 回答了“是什么？”“为什么？”“什么时候？”这三个问题
1.6.2. 数据工具是将架构落到实处的方法
1.6.2.1. 数据工具是将架构落到实处的方法
1.7. 脱离轨道
1.7.1. 在设计出数据架构之前就选择了技术
1.7.1.1. 提前选择技术会导致最终产出的是技术的胡乱拼凑而不是真正的数据架构
1.7.2. 原因
1.7.2.1. 新奇事物综合症(shiny
object syndrome)
1.7.2.2. 简历驱动开发(resume-driven
development)
1.7.2.3. 对架构缺乏经验
1.8. 选择正确的技术并非易事，尤其是当新技术和模式每天都在出现时
1.8.1. 现在可能是历史上评估和选择技术最混乱的时期
1.8.2. 选择技术是用例、成本、构建与购买以及模块化之间的平衡
1.8.3. 始终以与架构相同的方式来处理技术的选择：评估权衡并以可逆决策为目标
2. 团队大小和能力2.1. 需要评估的第一件事就是团队的大小和团队成员的技术能力
2.1.1. 你的团队的大小会直接影响选择的技术类型
2.1.2. 小团队
2.1.2.1. 也许只有一个人
2.1.2.2. 成员需要同时扮演各种角色
2.1.3. 大团队
2.1.3.1. 每个成员都有特定的角色
2.2. 简单和复杂的技术的共性是：团队的大小会基本上决定你的团队有多少精力和时间可以投入研究复杂问题的解决方案
2.3. 货物崇拜主义软件工程(cargo-cult engineering)
2.3.1. 小的数据团队在阅读大公司的科技前沿博文，并且尝试在自己的团队复现相应的技术与实践
2.3.2. 一种会耗费大量时间和金钱的错误选择，通常能得到的回报很少
2.4. 推荐保持使用团队熟悉的技术和工作流
2.5. 学习新的技术、语言或者工具需要大量的时间投入，所以需要明智地去规划这方面的投入
3. 加速市场化3.1. 对于技术而言，快速地投入市场是必胜之道
3.1.1. 需要选择能让数据需求开发得更快速的技术，同时能保持高质量标准和高安全性
3.1.2. 需要开发者在发布、学习、迭代中不断反馈和改进
3.2. 追求完美是保持优秀的敌人
3.2.1. 犹豫不决和少有产出是数据团队的死亡前兆
3.3. 团队需要尽早实现价值交付并且保持阶段性地交付频率
3.3.1. 你的团队成员会更熟练地使用他们已知的工具
3.3.2. 为了避免无差别的繁重工作让你的团队少有价值产出
3.3.3. 选择能帮助团队快速、可靠、安全地进行开发的工具
4. 互操作性4.1. 互操作性描述了多种技术和系统之间是如何连接、互换信息和交互的
4.2. 标准化是实现互操作性的前提
4.2.1. 几乎所有的数据库都会允许使用Java数据库连接(Java
Database Connectivity，JDBC)或开放式数据库连接(Open Database Connectivity，ODBC)，这样用户就可以通过标准接口轻松连接数据库
4.3. 互操作性无须事先定义好标准
4.3.1. 描述性状态迁移(Representational State Transfer，REST)并不完全是标准化的API，每个REST
API有自己的定义
4.3.2. 供应商或者开源软件(Open Source Software，OSS)项目负责保证与其他技术和系统的顺利集成
4.4. 在整个数据工程生命周期中，要时刻注意到连接你所选择的不同技术的困难程度
5. 成本优化和商业价值5.1. 在完美世界里，你可以无须考虑成本、时间、商业价值就可以尝试使用最新最前沿的技术
5.2. 在现实世界中，预算和时间都是有限的，并且成本是数据架构和技术选择的最主要限制
5.3. 总拥有成本
5.3.1. Total Cost of Ownership，TCO
5.3.2. 一个方案的总估计成本，包括使用的产品和服务的直接成本与间接成本
5.3.2.1. 直接成本可以直接来自于方案
5.3.2.1.1. 团队的工资
5.3.2.1.2. AWS的服务消费
5.3.2.2. 间接成本
5.3.2.2.1. 间接成本
5.3.2.2.2. 和该方案无关的
5.3.2.2.2.1. 无论选择哪种方案都需要被花费的
5.3.3. 费用分为两大类
5.3.3.1. 资本支出
5.3.3.1.1. capital expenses
5.3.3.1.1.1. capex
5.3.3.1.2. 前期投资
5.3.3.1.3. 支付是需要今天完成的
5.3.3.1.4. 资产并会随着时间慢慢折旧
5.3.3.1.5. 资本支出，并需要制定长期计划以实现前期付出和费用的正投资回报率(R O I)
5.3.3.1.6. 资本支出注重长期的计划
5.3.3.2. 运营支出
5.3.3.2.1. operation
expenses
> 5.3.3.2.1.1. opex> 5.3.3.2.2. 运营支出是渐进的并且分散于各时间段的> 5.3.3.2.3. 运营支出注重短期的计划> 5.3.3.2.4. 运营支出几乎是即付即得的，且有更多灵活性 > 5.3.3.2.4.1. 数据工程师需要切实地对待灵活性> 5.3.3.2.5. 更像是直接成本，能更容易归因于数据项目> 5.3.3.2.6. 随着云技术的出现而发生了改变，因为数据平台服务允许依据实际消费模型来付费 > 5.3.3.2.6.1. 运营支出能更好地给予工程师团队选择软件和硬件的能力 > 5.3.3.2.6.2. 云端服务使得数据工程师可以快速地迭代各种软件和技术配置，通常费用也不贵> 5.3.3.2.7. 鉴于运营支出在灵活性和低初始成本上的优势，我们建议数据工程师优先考虑运营支出，将技术集中在云上并且使用灵活的即付即得技术
5.4. 总拥有机会成本
5.4.1. Total Opportunity Cost of Ownership，TOCO
5.4.2. 在选择技术、架构或流程后所损失的机会的成本
5.4.3. 就算在云环境中，一旦将个技术、栈，或者管道变成生产数据流程的核心部分，就很难改变了
5.4.4. 减少机会成本的第一步是睁大眼睛仔细进行评估
5.4.4.1. 不灵活的数据技术就像是为熊准备的陷阱，很进入，却很难摆脱
5.5. FinOps
5.5.1. 典型的云端消费本质上是一种运营支出：公司为运行重要数据流程的服务付费，而不是前期投资和长期的固定投资
5.5.2. FinOps的目标就是通过应用类似DevOps的实践来监控和动态调整系统，以全面实现账户财务管理和创造商业价值
5.5.3. FinOps是创造价值
5.5.3.1. 云可以创造更多的收入、促进用户的大量增加、增快产品的发布速度，甚至帮助关闭数据中心
5.5.3.2. 快速迭代和动态扩展是创造商业价值的无价之宝
6. 不变的与暂时的技术6.1. 创建更好的未来的出发点是难能可贵的，但这经常导致过度设计和过度工程
6.1.1. 现在为未来选择的工具也许在未来真正到来时已经陈旧过时
6.1.2. 未来通常和我们几年前所设想的不同
6.2. 专注于现在
6.2.1. 选择对于现在或者不远的将来最好的工具
6.2.2. 也要支持未来的未知和变化
6.3. 不变的技术可能是支撑云的基础组件或者经受住了时间考验的编程语言基础
6.3.1. 在云技术中，不变的技术如对象存储、网络、服务器和安全
6.3.2. 选择对象存储保存数据是明智之举
6.3.3. 对象存储会继续以各种方式去提升并且一直提供新的选择，但你的数据在对象存储中会很安全并且保持可用，无论整个技术如何快速进化
6.3.4. SQL和bash会存在好几十年，并且我们不会看见它们很快就消失
6.4. 林迪效应
6.4.1. 这个技术创建得越久，它就越可能长期存在
6.4.2. 建议使用林迪效益作为试金石去测试一个技术是不是可能长期不变的
6.4.3. 电力网络、关系数据库、C语言或者X86的处理器架构
6.5. 有大量资金支持的新技术和各种开源项目每天都在数据领域出现
6.5.1. 大多数这样的公司和项目不会有长期的引领力，会渐渐淡出人们的视线
6.5.2. 顶级风投在押注巨额的赌注，因为多数的数据工具投资都会失败
6.5.3. 工程师被Hive激发但想优化其缺点，开发了新的如Presto等新技术
6.5.3.1. 现在Hive几乎只出现在遗留的部署之中
6.6. 几乎所有的技术都无法避免衰落的命运
6.6.1. 每两年就评估使用中的工具
6.7. 不论何时，找到在数据工程生命周期中不变的技术，并且将它们作为你的基石
6.7.1. 在不变的技术之上再使用暂时的技术
