读数据工程之道：设计和构建结实的数据系统10技术选择 ...

1.       选择技术

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.            直接成本可以直接来自于方案
  

1. >  5.3.2.1.1.             团队的工资
3. >  5.3.2.1.2.             AWS的服务消费

复制代码

• 5.3.2.2.            间接成本
  

1. >  5.3.2.2.1.             间接成本
3. >  5.3.2.2.2.             和该方案无关的
5.   >   5.3.2.2.2.1.              无论选择哪种方案都需要被花费的

复制代码

• 5.3.3.           费用分为两大类
  
• 5.3.3.1.            资本支出
  

1. >  5.3.3.1.1.             capital expenses
3.   >   5.3.3.1.1.1.              capex
5. >  5.3.3.1.2.             前期投资
7. >  5.3.3.1.3.             支付是需要今天完成的
9. >  5.3.3.1.4.             资产并会随着时间慢慢折旧
11. >  5.3.3.1.5.             资本支出，并需要制定长期计划以实现前期付出和费用的正投资回报率(R O I)
13. >  5.3.3.1.6.             资本支出注重长期的计划

复制代码

• 5.3.3.2.            运营支出
  

1. >  5.3.3.2.1.             operation

复制代码

expenses

1.   >   5.3.3.2.1.1.              opex
3. >  5.3.3.2.2.             运营支出是渐进的并且分散于各时间段的
5. >  5.3.3.2.3.             运营支出注重短期的计划
7. >  5.3.3.2.4.             运营支出几乎是即付即得的，且有更多灵活性
9.   >   5.3.3.2.4.1.              数据工程师需要切实地对待灵活性
11. >  5.3.3.2.5.             更像是直接成本，能更容易归因于数据项目
13. >  5.3.3.2.6.             随着云技术的出现而发生了改变，因为数据平台服务允许依据实际消费模型来付费
15.   >   5.3.3.2.6.1.              运营支出能更好地给予工程师团队选择软件和硬件的能力
17.   >   5.3.3.2.6.2.              云端服务使得数据工程师可以快速地迭代各种软件和技术配置，通常费用也不贵
19. >  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.           在不变的技术之上再使用暂时的技术
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。