阿里云高性价比应用服务存储

Apsara SA混合云存储阵列，助力企业数字化转型 随着云计算技术的普及，越来越多的企业开始选择了部署云计算方案，公共云的灵活性，易用性和可靠性也被大家广泛认可。但也有很多企业对传统存储阵列的依赖度很高，在短期内完全迁移到云端会有诸多的挑战，可能会涉及到系统的重新构建或者应用程序的开发，对客户来说改动量很大，也会面临不小的风险。同时还有很多客户对敏感数据的物理存放地有要求，所以越来越多的企业开始采用混合云来实现面向未来的数字化转型。 阿里云混合云存储阵列作为软硬一体的存储设备，集成了阿里云存储服务，融合了公共云存储和传统存储阵列的优点： 简单 客户无需更改原有的IT架构，就可以像使用本地存储设备一样使用阿里云混合云存储阵列，同时使用本地存储空间和云端存储空间，无需关注本地设备存储协议同云存储协议之间的兼容性。 灵活 与阿里云存储无缝结合，充分利用公共云存储的易于扩展，快速部署，按需付费的优势，快速响应客户业务需求的变化。 高效 自动云分层，热数据存放在本地存储空间，确保了数据的高速访问，冷数据放在云端，充分利用公共云存储的海量空间。云缓存功能确保当数据存放在云端的时候，也能利用本地存储空间的缓存功能，为应用提供快速响应。 可靠 阿里云混合云存储阵列采用了全冗余的硬件设计，支持数据加密，集成AD/LDAP，支持ACL，云端分布式存储提供多副本跨区域保护，11个9的数据高可靠性，完备的数据一致性校验，确保用户数据的安全和可靠。 阿里云混合云存储阵列专为对存储有高性能和稳定性要求，并且希望无缝上云的企业客户而设计： 数据能按照策略自动同步到云端，实现数据的云端备份容灾 支持自动云分层和云缓存功能，保证数据的高速访问和存储空间的有效利用 数据压缩和去重，提升数据在云端和本地存储无缝流动的效率 支持完备的主机端协议， FC/iSCSI/FCoE, NFS/CIFS, Cinder等 提供多版本快照，复制等丰富的企业数据服务 支持免网关阵列双活容灾，护驾企业关键应用 支持异构虚拟化，提高旧阵列利用率，降低总IT成本 存储阵列多控扩展，全面提升阵列性能和容量 全冗余设计，安全可靠，支持数据中心机架部署 克隆功能：支持卷克隆功能，可创建读写的卷克隆副本 故障恢复：支持故障切换和故障恢复功能，当控制器故障时，支持在线故障切换，业务连续性不受影响 阿里云混合云存储阵列将云存储的高性价比和可扩展性与本地数据中心架构相结合，帮助客户轻松实现数据在本地数据中心和公共云之间的无缝流动。 阿里云混合云存储阵列Apsara系列产品规格表

您可以通过阿里云RDS管理控制台或API创建RDS实例。本文介绍如何通过控制台创建RDS MySQL实例。 其他引擎创建实例请参见： 创建RDS SQL Server实例 创建RDS PostgreSQL实例 创建RDS PPAS实例 创建RDS MariaDB实例 除了新版本的创建实例页面，您也可以切换回旧版创建实例页面。操作详情请参见： 创建RDS实例（新版） 创建RDS实例（旧版） 优惠活动 首购折扣价：首次购买RDS MySQL享受折扣价。详情请参见优惠活动。 计费说明 关于实例计费说明，请参见计费方式。 前提条件 已注册阿里云账号。具体操作请参见注册阿里云账号。 若您要创建按量付费的实例，请确保您的阿里云账号的余额大于等于100元。 注意事项 包年包月实例无法转为按量付费实例。 按量付费实例可以转为包年包月实例，请参见按量付费转包年包月。 同一个主账号，最多可以创建30个按量付费的RDS实例。如需提高此限额，请提交工单申请。 创建RDS实例（新版） 进入RDS实例创建页面。 说明 您也可以在当前创建RDS实例页面上方单击返回旧版切换到旧版创建RDS实例页面。 设置以下参数。 类别 说明 计费方式 包年包月：属于预付费，即在新建实例时需要支付费用。适合长期需求，价格比按量付费更实惠，且购买时长越长，折扣越多。 按量付费：属于后付费，即按小时扣费。适合短期需求，用完可立即释放实例，节省费用。 地域 实例所在的地域，即实例所在的地理位置。 购买后无法更换地域。 请根据目标用户所在的地理位置就近选择地域，提升用户访问速度。 请确保RDS实例与需要连接的ECS实例创建于同一个地域，否则它们无法通过内网互通，只能通过外网互通，无法发挥最佳性能。 类型 数据库引擎的类型和版本，这里选择MySQL。 当前支持MySQL 5.5、5.6、5.7、8.0。 说明 不同地域支持的数据库类型不同，请以实际界面为准。 系列 基础版：单节点，计算与存储分离，性价比高。 高可用版：一个主节点和一个备节点，经典高可用架构。 三节点企业版（原金融版）：一个主节点和两个备节点，位于同一地域的三个不同的可用区，提供金融级可靠性。 说明 不同地域和数据库版本支持的系列不同，请以实际界面为准。关于各个系列的详细介绍，请参见产品系列概述。 存储类型 本地SSD盘：与数据库引擎位于同一节点的SSD盘。将数据存储于本地SSD盘，可以降低I/O延时。 ESSD云盘：增强型（Enhanced）SSD云盘，是阿里云全新推出的超高性能云盘产品。ESSD云盘基于新一代分布式块存储架构，结合25GE网络和RDMA技术，为您提供单盘高达100万的随机读写能力和更低的单路时延。ESSD云盘分为如下三类： ESSD云盘：PL1性能级别的ESSD云盘。 ESSD PL2云盘：相比PL1，PL2性能级别的ESSD云盘大约可提升2倍IOPS和吞吐量。 ESSD PL3云盘：相比PL1，PL3性能级别的ESSD云盘最高可提升20倍IOPS、11倍吞吐量，适合对极限并发I/O性能要求极高、读写时延极稳定的业务场景。 SSD云盘：基于分布式存储架构的弹性块存储设备。将数据存储于SSD云盘，即实现了计算与存储分离。 更多信息，请参见存储类型。 可用区 可用区是地域中的一个独立物理区域，主节点可用区指主实例所在可用区，备节点可用区指备实例所在可用区。 您可以设置实例为单可用区部署或多可用区部署： 单可用区部署指主节点可用区和备节点可用区都处于相同可用区。 多可用区部署指主节点可用区和备节点可用区处于不同可用区，此时您只需要选择主节点可用区，系统会自动选择备节点可用区。 相比单可用区部署，多可用区部署能提供可用区级别的容灾，建议您使用多可用区部署。 可用区 实例规格 入门级：通用型的实例规格，独享被分配的内存和I/O资源，与同一服务器上的其他通用型实例共享CPU和存储资源。 企业级：独享或独占型的实例规格。独享型指独享被分配的CPU、内存、存储和I/O资源。独占型是独享型的顶配，独占整台服务器的CPU、内存、存储和I/O资源。 说明 每种规格都有对应的CPU核数、内存、最大连接数和最大IOPS。详情请参见主实例规格列表。 存储空间 存储空间包括数据空间、系统文件空间、Binlog文件空间和事务文件空间。调整存储空间时最小单位为5GB。 说明 部分本地SSD盘的存储空间大小与实例规格绑定，ESSD/SSD云盘不受此限制。详情请参见主实例规格列表。 单击下一步：网络和资源组。 设置以下参数。 类别 说明 网络类型 经典网络：传统的网络类型。 专有网络：也称为VPC（Virtual Private Cloud）。VPC是一种隔离的网络环境，安全性和性能均高于传统的经典网络。选择专有网络时您需要选择对应的VPC和主节点交换机。 说明 请确保RDS实例与需要连接的ECS实例网络类型一致（如果选择专有网络，还需要保证VPC一致），否则它们无法通过内网互通。 存储引擎 设置实例的默认存储引擎。当前仅MySQL 8.0高可用版（本地SSD盘）实例支持此选项。 关于阿里自研的X-Engine引擎详情请参见X-Engine简介。 说明 X-Engine兼容InnoDB，而且拥有更好的性能表现，建议您使用X-Engine作为默认存储引擎。 参数模板 设置实例参数模板。当前仅高可用版（本地SSD盘）实例支持此选项。 说明 您可以选择系统参数模板或自定义参数模板，详情请参见使用参数模板。 时区 设置实例时区。当前仅本地SSD盘实例支持此选项。 表名大小写 设置实例表名是否区分大小写。当本地数据库区分大小时，您可以选择区分大小写，便于您迁移数据。当前仅本地SSD盘实例支持此选项。 资源组 实例所属的资源组。 单击下一步：确认订单。 确认参数配置，选择购买量和购买时长（仅包年包月实例），勾选服务协议，单击去支付完成支付。 创建RDS实例（旧版） 进入旧版RDS实例创建页面。 选择计费方式。 按量付费：属于后付费，即按小时扣费。适合短期需求，用完可立即释放实例，节省费用。 包年包月：属于预付费，即在新建实例时需要支付费用。适合长期需求，价格比按量付费更实惠，且购买时长越长，折扣越多。 设置以下参数。 参数 说明 地域 实例所在的地理位置。购买后无法更换地域。 请根据目标用户所在的地理位置就近选择地域，提升用户访问速度。 请确保RDS实例与需要连接的ECS实例创建于同一个地域，否则它们无法通过内网互通，只能通过外网互通，无法发挥最佳性能。 资源组 实例所属的资源组。 数据库类型 即数据库引擎的类型，这里选择MySQL。 说明 不同地域支持的数据库类型不同，请以实际界面为准。 版本 指MySQL的版本。当前支持MySQL 5.5、5.6、5.7、8.0。 说明 不同地域所支持的版本不同，请以实际界面为准。 系列 基础版：单节点，计算与存储分离，性价比高。 高可用版：一个主节点和一个备节点，经典高可用架构。 三节点企业版（原金融版）：一个主节点和两个备节点，位于同一地域的三个不同的可用区，提供金融级可靠性。仅4个地域提供三节点企业版实例：华东1、华东2、华南1、华北2。 说明 不同数据库版本支持的系列不同，请以实际界面为准。关于各个系列的详细介绍，请参见产品系列概述。 存储类型 本地SSD盘：与数据库引擎位于同一节点的SSD盘。将数据存储于本地SSD盘，可以降低I/O延时。 SSD云盘：基于分布式存储架构的弹性块存储设备。将数据存储于SSD云盘，即实现了计算与存储分离。 说明 SSD云盘支持云盘加密，能够最大限度保护您的数据安全，您的业务和应用程序无需做额外的改动。详情请参见云盘加密。 ESSD云盘：增强型（Enhanced）SSD云盘，是阿里云全新推出的超高性能云盘产品。ESSD云盘基于新一代分布式块存储架构，结合25GE网络和RDMA技术，为您提供单盘高达100万的随机读写能力和更低的单路时延。 更多信息，请参见存储类型。 密钥 云盘加密所使用的的密钥。密钥的创建请参见管理密钥。 可用区 可用区是地域中的一个独立物理区域，不同可用区之间没有实质性区别。您可以选择将RDS实例的主备节点创建在同一可用区或不同可用区。 相比单可用区，多可用区能提供可用区级别的容灾。 网络类型 经典网络：传统的网络类型。 专有网络（推荐）：也称为VPC（Virtual Private Cloud）。VPC是一种隔离的网络环境，安全性和性能均高于传统的经典网络。 说明 请确保RDS实例与需要连接的ECS实例网络类型一致，否则它们无法通过内网互通。 规格 每种规格都有对应的CPU核数、内存、最大连接数和最大IOPS。详情请参见主实例规格列表。 RDS实例有以下规格族： 通用型：独享被分配的内存和I/O资源，与同一服务器上的其他通用型实例共享CPU和存储资源。 独享型：独享被分配的CPU、内存、存储和I/O资源。 独占物理机型：是独享型的顶配，独占整台服务器的CPU、内存、存储和I/O资源。 例如，8核32GB是通用型实例规格，8核32GB（独享套餐）是独享型实例规格，30核220GB（独占主机）是独占物理机型实例规格。 存储空间 该存储空间包括数据空间、系统文件空间、Binlog文件空间和事务文件空间。 设置购买时长（仅针对包年包月实例）和实例数量，然后单击右侧的立即购买。 说明 购买包年包月实例时，可以勾选自动续费，系统将根据您的购买时长进行自动续费。例如，您购买3个月的实例并勾选自动续费，则每次自动续费时会缴纳3个月的费用。 对于包年包月实例，您也可以单击加入购物车将实例加入到购物车中，最后单击购物车进行结算。 在订单确认页面，勾选相关协议，根据提示完成支付。 下一步 在控制台左上角，选择实例所在的地域即可查看到刚刚创建的实例。选择地域 创建实例后，您需要设置白名单和创建账号，如果是通过外网连接，还需要申请外网地址。然后就可以连接实例。 如果连接实例失败，请参见解决无法连接实例问题。 常见问题 为什么创建实例后无反应，实例列表也看不到创建中的实例？ 看不到创建中的实例可能有如下两个原因： 地域错误 可能您所在地域和您创建实例时选择的地域不一致。您可以在页面左上角切换地域。 选择地域 可用区内资源不足 由于可用区资源是动态分配的，可能您下单后可用区内资源不足，所以会创建失败，建议您更换可用区重试。创建失败您可以在订单列表里看到退款。 如何授权子账号管理RDS实例？ 答：请参见云数据库 RDS 授权。 相关API API 描述 CreateDBInstance 创建RDS实例。 操作视频 RDS实例创建

本教程介绍云服务器ECS的成本构成和优势，并提供成本管理的推荐方案，帮助您通过成本管理节约成本，在保障业务快速发展的同时按照预算支出费用，获得最大成本收益。 成本构成 使用云服务器ECS时，成本包括两个方面： 拥有成本：各类资源和资源包的成本。 运维成本：使用云服务器ECS过程中产生的人力成本。 ECS成本构成 上云的成本优势 自建数据中心时，除硬件、网络、电力、机房、人力运维成本等直接成本外，还需要考虑升级、扩容等带来的规模成本，以及备份数据、实现高可用等带来的风险成本。随着业务发展扩大数据中心规模时，单位资源成本和数据中心复杂度会不断增长，而且容错率低。如果在业务变化时选型失误，更会增加额外的支出。 相比自建数据中心，使用云上资源时无须投入硬件、物理环境人力等成本，单位资源成本相对线性，所有资源按需取用，交付便利。除资源成本的优势外，云上资源还支持多种付费模式，方便进一步优化成本。 成本优化建议 使用云服务器ECS时，推荐您从以下方面管理成本： 归集成本 优化资源 升级换代 具备节约意识 实现自动化运维 归集成本 在用户中心，您可以查看费用账单中的信息了解消费情况，从多个维度追踪成本并确定优化对象。 使用费用账单的账单总览功能，查看账号消费趋势、产品消费分布等信息，把握整体消费情况。 使用资源组、标签等功能，从业务、部门、项目的等维度分类资源，以便统计相应成本。 使用费用账单的账单明细功能，查看详细的资源消费情况。通过设置的资源组和标签，在更细粒度汇总各类资源的成本。 例如，创建标签部门:研发、部门:财务、部门:IT，并为ECS实例绑定标签。在查看账单明细时，通过标签筛选对应部门使用的资源，汇总成本用于确定优化对象。 优化资源 发现成本偏高的资源后，您可以从多个角度监控资源的情况，确定成本偏高的原因，然后采取针对性的优化措施。 监控资源的使用情况。 监控资源利用率，评估当前配置是否过高。例如CPU、内存、云盘、带宽等资源的利用率。 监控闲置的资源，避免浪费。例如升配但未重启的实例、未匹配实例的预留实例券、未挂载的云盘、未关联的EIP等。 监控资源使用周期。如果长期使用按量付费实例、云盘等资源，考虑以更实惠的方式购买，例如包年包月、资源包等。 监控资源生命周期，了解包年包月资源的到期日，及时续费。例如包年包月实例、预留实例券、存储容量单位包等。 选择合适的实例规格。 实例规格对云服务器ECS成本有较大影响，根据业务场景选择最佳性价比的实例规格，并调整合适的数量。在满足业务需求的同时追求高资源利用率，降低成本。 例如针对短视频场景，目前使用d1ne.14xlarge（60台），监控ECS实例发现内存使用率合理，但CPU相对空闲。因此可以采取以下方案： 适当降低CPU和内存比，满足业务需求的同时提高CPU利用率。查看实例规格详情发现d1ne实例为1:4，d2实例为1:5.5左右。使用d2s.8xlarge（85台）替换d1ne.14xlarge（60台），规格从14xlarge降为8xlarge，约节省23%的成本。 更多实例配置选型的介绍，请参见选型配置。 组合多种付费模式。 不同类型的业务对资源使用周期有不同要求。为每一类业务确定合适的付费模式，灵活组合达到最优效果。 针对稳定业务负载，使用包年包月、预留实例券。 针对有状态且动态变化的业务负载，使用按量付费。 针对无状态且可容错的业务负载，使用抢占式实例。 利用DDH复用ECS实例资源。 针对CPU绝对稳定性要求不严苛的场景，例如开发测试环境，使用超分型DDH部署更多同等规格的ECS实例，降低单位部署成本。 部署在DDH上的ECS实例停机时不占用资源，您也可以在生产环境业务流量的低峰期停止部分ECS实例，使用生产环境的空闲资源运行可预期周期的测试任务，例如离线计算、自动化测试等。 升级换代 处理器等硬件持续更新换代，提高性能的同时降低成本。云服务器ECS也会持续升级，为您提供性价比更高的产品。 新实例规格性价比优于老实例规格。例如，从g5.2xlarge升级到g6.2xlarge的性能和价格对比如下： 性能 价格 整形运算性能提升40% 浮点运算性能提升30% 内存带宽提升15% 内存空闲延迟降低40% 内网带宽提升220% 预付费包年成本降低6% 按量付费成本降低43% 为保证您可以及时使用新一代实例规格，建议您： 设计的应用具备鲁棒性，在不同实例规格上可以正常运行。 关注阿里云官网中实例规格的发布情况，及时评估是否需要更换。 升级换代示例 按照以下参考替换方案，保证CPU、内存配置相同的前提下，可以提升性能并至少节约15%的实例成本： 当前实例规格族 首选推荐 备选推荐 sn1、sn2 c6 g6 r6 c5、sn1ne g5、sn2ne r5、se1ne c4 hfc6、c6 hfc5、c5 ce4 r6 r5、se1ne cm4 hfc6 hfc5、g5 n1、n2、e3 c6 g6 r6 c5、sn1ne g5、sn2ne r5、se1ne t1 s1、s2、s3 m1、m2 c1、c2 c6 g6 r6 c5、sn1ne g5、sn2ne r5、se1ne 具备节约意识 云上资源的一个特点是按需取用，避免了自建数据中心所需的高昂一次性投入。针对按需取用的特点，您需要将成本优化融入到日常工作中，持续推进才能获得理想的优化成果。下面列举几个典型操作，您可以以此为模板进一步细化，形成贴合自身情况的方案。 定期召开成本会议。定期和成本相关方（例如财务、研发等团队）评审预算执行情况，评估优化成果，改进优化策略。 强制使用标签。利用标签按业务、环境、责任人等维度标记资源，便于日常成本追踪。 分类资源并定制合适的使用方式。例如针对短期项目的开发测试环境，优先选用按量付费实例部署，项目结束后及时释放实例。 避免资源闲置。定期盘点资源使用情况，明确闲置资源的通知和处置流程。 及时续费。对包年包月资源，提前申请预算，避免到期释放后重新购买部署增加额外成本。 实现自动化运维 阿里云也提供了丰富的运维类产品，帮助您提高运维效率，降低运维的人力成本。例如： 弹性伸缩：持续维护跨付费模式、跨可用区、跨实例规格的实例集群。适合业务负载存在峰谷波动的场景。 弹性供应：一键部署跨付费模式、跨可用区和跨实例规格的实例集群。适合需要快速交付稳定算力，同时使用抢占式实例降低成本的场景。 运维编排：以模板的方式定义一组运维操作，高效执行运维任务。适合事件驱动运维、定时运维、批量运维、跨地域运维等场景。 资源编排：一键部署并维护包含多种云资源和依赖关系的资源栈。适合交付整体系统、克隆环境等场景。

其实从去年已经隐隐约约感觉到数据库的有变化，只是没有想到变得这么快。今年的一些事情实实在在地给了某些数据库重击，如果以前去某数据库还是喊喊，然后该用还用，今年从传统领域刮起的去某数据库的风，已经开始了，并且后面的乌云密布也看得见。 最近看一篇国外的开源产品提供厂商的一篇文字，主要是在询问了他的几百位客户后得出了下图中的2019年数据库的使用趋势。 从图中可以看出，MySQL以38.9%的使用率高居榜首，其次是MongoDB(24.6%)、PostgreSQL(17.4%)、Redis(8.4%)和Cassandra(3.0%)。在这些数据库中，Oracle仅占1.8%，而CouchDB、Berkeley DB、Microsoft SQL Server、Redshift、Firebase、Elasticsearch 整合后的影响力和用户的总和仅为2.4%。 但该调查报告却与DB-engine排名趋势流行度报告大相径庭，Oracle数据库在此报告中排名第一，不过笔者认为，任何文字都是可能是偏颇或有倾向性的，每个人看完后都可能有自己的想法，或认同或反对，就如同最近最热的一句话“人心中的成见是一座大山，任你怎么努力休想搬动”。 MySQL 仍然是排名第一的免费开源数据库，占开源数据库使用量的 30% 以上。这并不奇怪，根据 DB-Engines，MySQL 多年来一直保持在这个位置。根据笔者多年来的从业经验，我认为MySQL数据库确实配得上这个排名，原因如下。 1.完全开源 MySQL最强大的优势之一在于他的数据库管理系统（DBMS，Database Management System）是一个开源系统。当然，开源并不意味着免费，它还是有许多付费功能。但是开源的特点给予用户可以根据自己需要修改DBMS的自由。 MySQL采用了GPL（General Public License），这意味着授权给用户可以阅读，修改和优化源代码，这样即使是免费版的MySQL的功能也足够强大。这也是MySQL如此受欢迎的原因之 一。 2.快速更新和用户友好 在其他数据库（例如Orcale、MSSQL Sever）更新缓慢的时候，MySQL很少让他的用户等待。每当新的版本出来之后，MySQL都会成为大多数服务器的主要数据库。Linux web服务器已经成为现在web服务器的主流，MySQL在linux服务器上面也得到了广泛的应用。 3.WebsitePanel，phpMyAdmin 和MySQl的黄金组合 对于初学者来说，通过虚拟主机商提供的websitepanel控制面板学习MySQL是一个很不错的方法。用户不仅可以观看很多视频教程来学习使用 MySQL，还可以使用PhpMyAdmin通过web方式管理数据库。 PostgreSQL 以 13.4% 的开源数据库用户比例位居第二，紧随其后的是 MongoDB，占 12.2%，位列第三。 如果你经常光顾某些网站，或者大型公众号，你应该知道今年最热的事情有两个，postgresql和大数据，今年算是postgresql在中国的开始发展的元年，知道的人和使用的人也越来越多。 根据DB-engine数据库流行榜发布的数据显示，Oracle与MySQL与去年相比都产生了一定的退步，唯独postgresql呈现上升趋势，比去年同月份提高了85.18%，这进一步说明数据库领域正在涌现出更多的新生力量，与之前将所有鸡蛋都放在一个篮子里的传统策略相比，IT行业的工作者正在使用多种数据库来支持他们的产品，多数据库类型的使用在过去10年出现了爆炸式增长。 在我们的调查中，几乎有一半实际上使用不止一种类型的数据库来支持他们的应用程序，而不是单个数据库，使用多个数据库的比例为44.3%，使用一个数据库的比例为55.7%，他们喜欢的数据库组合如下。 现在，让我们仔细研究一下在单个应用程序中最常用的数据库类型。 在下面的图表中，左边列中的数据库表示该数据库类型的样本量，上面列出的数据库表示与该数据库类型组合的百分比。蓝色显示的单元格表示 100% 的部署组合，而黄色表示 0% 的组合。 因此，如下面的数据库组合热图所示，MySQL 是我们与其他数据库类型结合最频繁的数据库。但是，虽然其他数据库类型经常与 MySQL 一起使用，但这并不意味着 MySQL 部署总是使用另一种数据库类型。这可以在 MySQL 的第一行看到，其颜色为浅蓝到黄色，相比之下，MySQL 第一列的颜色要和表示 100% 组合的蓝色的匹配度高许多。 用黑色边框突出显示的单元格表示仅利用这一种数据库类型的部署，其中仅使用 MySQL 的单元格占部署总数的 23%。 其实，这些数据也比较精准的反映了国内的情况，从2005年开始，IT企业在数据库的发展方向上就已经有了一些变化。 2007年开始阿里巴巴的IT开销史无前例，一度成为IBM、Oracle中国的标杆客户，淘宝、阿里巴巴B2B和支付宝等公司，98%以上的软件系统和业务都是采用Oracle数据库提供数据服务。2009年淘宝更是上了全球排名前几位的大RAC集群，据说当年有16个节点。每天早上CPU还是跑到98%。换句话来说，三年几千万买Oracle产品+服务也没办法支撑阿里成长的速度，只能开启自研模式，于是就有了Oracle全面转向MySQL的进程。 拆分Oracle数据库+Hadoop其实也可以撑一撑，但是这样的话，还要向Oracle购买更多的License（再花几千万，不是没钱，是即便花钱也不能彻底解决问题）。因此，阿里巴巴B2B将中文站压力和数据容量最大的Offer数据库，成功从Oracle数据库+IBM小型机+EMC2存储设备，迁移到MySQL数据库+PC Server的模式，所以淘宝2013年下线了最后一个Oracle，2014年支付宝交易替换了Oracle，2016年支付宝总账全面用OceanBase替换Oracle。 发展趋势： 1.“去Oracle化”。一方面是Oracle采用scale up而不是scale out的方案；另外一个重要原因是价格。网易和阿里巴巴都曾经以Oracle作为主要的数据库解决方案，投资几千万来采购License。阿里巴巴曾经还自称是互联网企业中Oracle的最大用户。Oracle最大的优势是运维简单，应用开发方便，但是和昂贵的价格相比，这一点不再具备吸引力。 2.优化MySQL数据库。这些互联网企业采用了大量的MySQL服务器集群，最大集群在150台服务器左右。承载了包括博客、电子商务等应用。采用的优化包括： 传统的SQL优化，如减少某个查询涉及到的列，控制索引数量等 闪存介质（SSD或者Flash卡）。这是几乎所有互联网企业都采用的方法，由于测试场景各不相同，因此没法比较谁家的方案更好。大体上分成直接使用闪存介质作为存储系统；优化闪存介质访问方式进一步优化 设计MySQL存储引擎 3.NoSQL数据库。NoSQL对应用养发提出了较高的要求，在项目中不是那么容易推广，一致性要求被放松，但是“原子性”支持需要被保证。一般是为了满足高并发需要才引入。如盛大采用MongoDB，淘宝自研了Tair数据库（已经开源） 4.分布式数据库。众所周知，使用不同的SQL优化与执行方式，数据库的访问性能可能会存在上千上万倍的差距。计算存储分离的核心思想便是在数据存储层面进行一体化存储，而计算层面则有效利用每种执行引擎的特点，针对不同的业务场景进行选择和优化。 所以，如果具有超强的研发团队和运维团队，在云时代还是有机会替代Oracle的，我们也看到伴随着人口红利，在软件开发领域的我国实力已今非昔比，大部分企业的 “去IOE”的进程更多的是自发的因系统架构优化而进行，同时各种数据库技术与产品也蓬勃发展，所以，在技术上看Oracle并非不能取代，更多的是出于综合成本(改造与建设成本、分享)的考量，需要的是时间和意志。 一千个人眼里就有一千个哈姆雷特，在每个开发者和企业的眼中，只有适合自己的数据库才是最好的。

X-Engine是阿里云数据库产品事业部自研的联机事务处理OLTP（On-Line Transaction Processing）数据库存储引擎。作为自研数据库POLARDB的存储引擎之一，已经广泛应用在阿里集团内部诸多业务系统中，包括交易历史库、钉钉历史库等核心应用，大幅缩减了业务成本，同时也作为双十一大促的关键数据库技术，挺过了数百倍平时流量的冲击。 为什么设计一个新的存储引擎 X-Engine的诞生是为了应对阿里内部业务的挑战，早在2010年，阿里内部就大规模部署了MySQL数据库，但是业务量的逐年爆炸式增长，数据库面临着极大的挑战： 极高的并发事务处理能力（尤其是双十一的流量突发式暴增）。 超大规模的数据存储。 这两个问题虽然可以通过扩展数据库节点的分布式方案解决，但是堆机器不是一个高效的手段，我们更想用技术的手段将数据库性价比提升到极致，实现以少量资源换取性能大幅提高的目的。 传统数据库架构的性能已经被仔细的研究过，数据库领域的泰斗，图灵奖得主Michael Stonebreaker就此写过一篇论文 《OLTP Through the Looking Glass, and What We Found There》 ，指出传统关系型数据库，仅有不到10%的时间是在做真正有效的数据处理工作，剩下的时间都浪费在其它工作上，例如加锁等待、缓冲管理、日志同步等。 造成这种现象的原因是因为近年来我们所依赖的硬件体系发生了巨大的变化，例如多核（众核）CPU、新的处理器架构（Cache/NUMA）、各种异构计算设备（GPU/FPGA）等，而架构在这些硬件之上的数据库软件却没有太大的改变，例如使用B-Tree索引的固定大小的数据页（Page）、使用ARIES算法的事务处理与数据恢复机制、基于独立锁管理器的并发控制等，这些都是为了慢速磁盘而设计，很难发挥出现有硬件体系应有的性能。 基于以上原因，阿里开发了适合当前硬件体系的存储引擎，即X-Engine。 X-Engine架构 全新架构的X-Engine存储引擎不仅可以无缝对接兼容MySQL（得益于MySQL Pluginable Storage Engine特性），同时X-Engine使用分层存储架构。 因为目标是面向大规模的海量数据存储，提供高并发事务处理能力和降低存储成本，在大部分大数据量场景下，数据被访问的机会是不均等的，访问频繁的热数据实际上占比很少，X-Engine根据数据访问频度的不同将数据划分为多个层次，针对每个层次数据的访问特点，设计对应的存储结构，写入合适的存储设备。 X-Engine使用了LSM-Tree作为分层存储的架构基础，并进行了重新设计： 热数据层和数据更新使用内存存储，通过内存数据库技术（Lock-Free index structure/append only）提高事务处理的性能。 流水线事务处理机制，把事务处理的几个阶段并行起来，极大提升了吞吐。 访问频度低的数据逐渐淘汰或是合并到持久化的存储层次中，并结合多层次的存储设备（NVM/SSD/HDD）进行存储。 对性能影响比较大的Compaction过程做了大量优化： 拆分数据存储粒度，利用数据更新热点较为集中的特征，尽可能的在合并过程中复用数据。 精细化控制LSM的形状，减少I/O和计算代价，有效缓解了合并过程中的空间增大。 同时使用更细粒度的访问控制和缓存机制，优化读的性能。 技术特点 利用FPGA硬件加速Compaction过程，使得系统上限进一步提升。这个技术属首次将硬件加速技术应用到在线事务处理数据库存储引擎中，相关论文 《FPGA-Accelerated Compactions for LSM-based Key Value Store》 已经被2020年的顶级会议FAST'20接收。 通过数据复用技术减少数据合并代价，同时减少缓存淘汰带来的性能抖动。 使用多事务处理队列和流水线处理技术，减少线程上下文切换代价，并计算每个阶段任务量配比，使整个流水线充分流转，极大提升事务处理性能。相对于其他类似架构的存储引擎（例如RocksDB），X-Engine的事务处理性能有10倍以上提升。 X-Engine使用的Copy-on-write技术，避免原地更新数据页，从而对只读数据页面进行编码压缩，相对于传统存储引擎（例如InnoDB），使用X-Engine可以将存储空间降低至10%~50%。 Bloom Filter快速判定数据是否存在，Surf Filter判断范围数据是否存在，Row Cache缓存热点行，加速读取性能。 LSM基本逻辑 LSM的本质是所有写入操作直接以追加的方式写入内存。每次写到一定程度，即冻结为一层（Level），并写入持久化存储。所有写入的行，都以主键（Key）排序好后存放，无论是在内存中，还是持久化存储中。在内存中即为一个排序的内存数据结构（Skiplist、B-Tree、etc），在持久化存储也作为一个只读的全排序持久化存储结构。 普通的存储系统若要支持事务处理，需要加入一个时间维度，为每个事务构造出一个不受并发干扰的独立视域。例如存储引擎会对每个事务定序并赋予一个全局单调递增的事务版本号（SN），每个事务中的记录会存储这个SN以判断独立事务之间的可见性，从而实现事务的隔离机制。 如果LSM存储结构持续写入，不做其他的动作，那么最终会成为如下结构。 这种结构对于写入是非常友好的，只要追加到最新的内存表中即完成，为实现故障恢复，只需记录Redo Log，因为新数据不会覆盖旧版本，追加记录会形成天然的多版本结构。 但是如此累积，冻结的持久化层次越来越多，会对查询会产生不利的影响。例如对同一个key，不同事务提交产生的多版本记录会散落在各个层次中；不同的key也会散落在不同层次中。读操作需要查找各个层并合并才能得到最终结果。 因此LSM引入了Compaction操作解决这个问题，Compaction操作有2种作用： 控制LSM层次形状 一般的LSM形状都是层次越低，数据量越大（倍数关系），目的是为了提升读性能。 通常存储系统的数据访问都有局部性，大量的访问都集中在少部分数据上，这也是缓存系统能有效工作的基本前提。在LSM存储结构中，如果把访问频率高的数据尽可能放在较高的层次上，存放在快速存储设备中（例如NVM、DRAM），而把访问频率低的数据放在较低层次中，存放在廉价慢速存储设备中。这就是X-Engine的冷热分层概念。 合并数据 Compaction操作不断的把相邻层次的数据合并，并写入更低层次。合并的过程实际上是把要合并的相邻两层或多层的数据读出来，按key排序，相同的key如果有多个版本，只保留新的版本（比当前正在执行的活跃事务中最小版本号新），丢掉旧版本数据，然后写入新的层，这个操作非常耗费资源。 合并数据除了考虑冷热分层以外，还需要考虑其他维度，例如数据的更新频率，大量的多版本数据在查询的时候会浪费更多的I/O和CPU，因此需要优先进行合并以减少记录的版本数量。X-Engine综合考虑了各种策略形成自己的Compaction调度机制。 高度优化的LSM X-Engine的memory tables使用了无锁跳表（Locked-free SkipList），并发读写的性能较高。在持久化层如何实现高效，就需要讨论每层的细微结构。 数据组织 X-Engine的每层都划分成固定大小的Extent，存放每个层次中的数据的一个连续片段（Key Range）。为了快速定位Extent，为每层Extents建立了一套索引（Meta Index），所有这些索引，加上所有的memory tables（active/immutable）一起组成了一个元数据树（Metadata Tree），root节点为Metadata Snapshot，这个树结构类似于B-Tree。 X-Engine中除了当前的正在写入的active memory tables以外，其他结构都是只读的，不会被修改。给定某个时间点，例如LSN=1000，上图中的Metadata Snapshot 1引用到的结构即包含了LSN=1000时的所有的数据的快照，因此这个结构被称为Snapshot。 即便是Metadata结构本身，也是一旦生成就不会被修改。所有的读请求都是以Snapshot为入口，这是X-Engine实现Snapshot级别隔离的基础。前文说过随着数据写入，累积数据越多，会执行Compaction操作、冻结memory tables等，这些操作都是用Copy-on-write实现，即每次都将修改产生的结果写入新的Extent，然后生成新的Meta Index结构，最终生成新的Metadata Snapshot。 例如执行一次Compaction操作会生成新的Metadata Snapshot，如下图所示。 可以看到Metadata Snapshot 2相对于Metadata Snapshot 1并没有太多的变化，仅仅修改了发生变更的一些叶子节点和索引节点。 事务处理 得益于LSM的轻量化写机制，写入操作固然是其明显的优势，但是事务处理不只是把更新的数据写入系统那么简单，还要保证ACID（原子性、一致性、隔离性、持久性），涉及到一整套复杂的流程。X-Engine将整个事务处理过程分为两个阶段： 读写阶段 校验事务的冲突（写写冲突、读写冲突），判断事务是否可以执行、回滚重试或者等锁。如果事务冲突校验通过，则把修改的所有数据写入Transaction Buffer。 提交阶段 写WAL、写内存表，以及提交并返回用户结果，这里面既有I/O操作（写日志、返回消息），也有CPU操作（拷贝日志、写内存表）。 为了提高事务处理吞吐，系统内会有大量事务并发执行，单个I/O操作比较昂贵，大部分存储引擎会倾向于聚集一批事务一起提交，称为Group Commit，能够合并I/O操作。但是一组事务提交的过程中，还是有大量等待过程的，例如写入日志到磁盘过程中，除了等待落盘无所事事。 X-Engine为了进一步提升事务处理的吞吐，使用流水线技术，把提交阶段分为4个独立的更精细的阶段： 拷贝日志到缓冲区（Log Buffer） 日志落盘（Log Flush） 写内存表（Write memory table） 提交返回（Commit） 事务到了提交阶段，可以自由选择执行流水线中任意一个阶段，只要流水线任务的大小划分得当，就能充分并行起来，流水线处于接近满载状态。另外这里利用的是事务处理的线程，而非后台线程，每个线程在执行的时候，选择流水线中的一个阶段执行任务，或者空闲后处理其他请求，没有等待，也无需切换，充分利用了每个线程的能力。 读操作 LSM处理多版本数据的方式是新版本数据记录会追加在老版本数据后面，从物理上看，一条记录不同的版本可能存放在不同的层，在查询的时候需要找到合适的版本（根据事务隔离级别定义的可见性规则），一般查询都是查找最新的数据，总是由最高的层次往低层次找。 对于单条记录的查找而言，一旦找到便可以终止，如果记录在比较高的层次，例如memory tables，很快便可以返回；如果记录已经落入了很低的层次，那就得逐层查找，也许Bloom Filter可以跳过某些层次加快这个旅程，但毕竟还是有很多的I/O操作。X-Engine针对单记录查询引入了Row Cache，在所有持久化的层次的数据之上做了一个缓存，在memory tables中没有命中的单行查询，在Row Cache之中也会被捕获。Row Cache需要保证缓存了所有持久化层次中最新版本的记录，而这个记录是可能发生变化的，例如每次flush将只读的memory tables写入持久化层次时，就需要恰当的更新Row Cache中的缓存记录，这个操作比较微妙，需要精心的设计。 对于范围扫描而言，因为没法确定一个范围的key在哪个层次中有数据，只能扫描所有的层次做合并之后才能返回最终的结果。X-Engine采用了一系列的手段，例如SuRF（SIGMOD'18 best paper）提供range scan filter减少扫描层数、异步I/O与预取。 读操作中最核心的是缓存设计，Row Cache负责单行查询，Block Cache负责Row Cache的漏网之鱼，也用来进行范围扫描。由于LSM的Compaction操作会一次更新大量的Data Block，导致Block Cache中大量数据短时间内失效，导致性能的急剧抖动，因此X-Engine做了很多的优化： 减少Compaction的粒度。 减少Compaction过程中改动的数据。 Compaction过程中针对已有的缓存数据做定点更新。 Compaction Compaction操作是比较重要的，需要把相邻层次交叉的Key Range数据读取合并，然后写到新的位置。这是为前面简单的写入操作付出的代价。X-Engine为优化这个操作重新设计了存储结构。 如前文所述，X-Engine将每一层的数据划分为固定大小的Extent，一个Extent相当于一个小而完整的排序字符串表（SSTable），存储了一个层次中的一个连续片段，连续片段又进一步划分为一个个连续的更小的片段Data Block，相当于传统数据库中的Page，只不过Data Block是只读而且不定长的。 回看并对比Metadata Snapshot 1和Metadata Snapshot 2，可以发现Extent的设计意图。每次修改只需要修改少部分有交叠的数据，以及涉及到的Meta Index节点。两个Metadata Snapshot结构实际上共用了大量的数据结构，这被称为数据复用技术（Data Reuse），而Extent大小正是影响数据复用率的关键，Extent作为一个完整的被复用的物理结构，需要尽可能的小，这样与其他Extent数据交叉点会变少，但又不能非常小，否则需要索引过多，管理成本太大。 X-Engine中Compaction的数据复用是非常彻底的，假设选取两个相邻层次（Level1, Level2）中的交叉的Key Range所涵盖的Extents进行合并，合并算法会逐行进行扫描，只要发现任意的物理结构（包括Data Block和Extent）与其他层中的数据没有交叠，则可以进行复用。只不过Extent的复用可以修改Meta Index，而Data Block的复用只能拷贝，即便如此也可以节省大量的CPU。 一个典型的数据复用在Compaction中的过程可以参考下图。 可以看出数据复用的过程是在逐行迭代的过程中完成的，不过这种精细的数据复用带来另一个副作用，即数据的碎片化，所以在实际操作的过程中也需要根据实际情况进行分析。 数据复用不仅给Compaction操作本身带来好处，降低操作过程中的I/O与CPU消耗，更对系统的综合性能产生一系列的影响。例如c、Compaction过程中数据不用完全重写，大大降低了写入时空间的增大；大部分数据保持原样，数据缓存不会因为数据更新而失效，减少合并过程中因缓存失效带来的读性能抖动。 实际上，优化Compaction的过程只是X-Engine工作的一部分，更重要的是优化Compaction调度的策略，选什么样的Extent、定义compaction任务的粒度、执行的优先级等，都会对整个系统性能产生影响，可惜并不存在什么完美的策略，X-Engine积累了一些经验，定义了很多规则，而探索更合理的调度策略是未来一个重要方向。 适用场景 请参见X-Engine最佳实践。 如何使用X-Engine 请参见使用X-Engine引擎。 后续发展 作为MySQL的存储引擎，持续地提升MySQL系统的兼容能力是一个重要目标，后续会根据需求的迫切程度逐步加强原本取消的一些功能，例如外键，以及对一些数据结构、索引类型的支持。 X-Engine作为存储引擎，核心的价值还在于性价比，持续提升性能降低成本，是一个长期的根本目标，X-Engine还在Compaction调度、缓存管理与优化、数据压缩、事务处理等方向上进行深层次的探索。 X-Engine不仅仅局限为一个单机的数据库存储引擎，未来还将作为自研分布式数据库POLARDB分布式版本的核心，提供企业级数据库服务。

“求知若饥，虚心若愚”——这个原本出自《全球概览》的俳句，因为乔布斯在斯坦福大学毕业演讲中的引用而备受推崇，流传成为 IT 界的至理名言之一。在编程界，亦有“代码胜于雄辩”、“Done is better than perfect”等警句，寥寥数语将编程工作者的形象特质描摹到了极致。程序员，就是技术至上、唯代码是瞻且必须不断武装自己的群体。 21 世纪，高薪、高端、高技术范儿已成为程序员的固有标签，在这个新的元年，CSDN 将基于一年一度的开发者大调查数据，以全新的视角深入发掘中国开发者群体的整体现状、应用开发技术以及开发工具/平台的发展趋势，呈现更真实、更全面且更有学习价值的开发者画像。 30 岁以下开发者人数占比超八成，全国有 19.6% 开发者月薪超过 1.7 万元； 六成开发者在使用 Java 语言，近五成开发者近期最想学 Python 语言； Spark、Redis 和 Kafka 正在成为企业大数据平台通用技术组件； 区块链技术近两年是热点，比特币和以太坊是两种主流的区块链开发平台； 人工智能技术日益受到企业和市场的关注，但 64% 企业尚未实现智能化，机器学习/深度学习算法工程师最为急缺； 近七成开发者认为未来 5G 网络的传输速率能达到 4G 网络的 10 倍以上； Apache 项目和 Linux 是开发者较为喜欢的开源项目； 半数开发者很少参与开源项目的开发、维护、运营和社区发展等。 软件开发准入门槛持续降低，近 2 成开发者月薪超过 1.7 万 30 岁以下开发者人数占比超八成，软件开发从业门槛持续降低 从 2015 年到 2019 年的调研数据来看：30 岁及以下的开发者人群占比在 8 成以上，一直是软件开发领域的主力军；全国近半数的开发者工作在一线城市（北京、上海、广州、深圳、天津）；物联网、软件、IT 制造三个技术领域涵盖了国内 84% 以上的开发者；本科及以上学历占 8 成；92% 的开发者是男性。 和国外开发者年龄分布趋势大概一致，国内的软件开发群体一直呈现出越来越年轻化的特点。这是因为，一方面软件开发行业蓬勃发展，各行各业都需要软件开发相关人才，也有越来越多的毕业生选择从事该行业；另一方面，是因为编程语言、框架、云服务等基础设施的持续完善，从事软件开发的门槛在持续降低，更容易接纳新鲜血液，报告统计发现，本科学历是开发者的主力军，66% 的开发者拥有本科学历，而硕士研究生、博士研究生仅占 11%、1%。 八成以上开发者月薪在 5 千~3 万元之间，19.6% 开发者月薪超过 1.7 万元 通过结合受教育程度和薪资水平的数据特点来看，学历越高的人群中，月薪 1.7 万元以上的高收入比例越高。在一线城市（北京、上海、广州、深圳、天津）中，月薪超过 1.7 万元的开发者占比为 30%，该比例远高于国内其它城市。 开发者属于相对高薪的职业，尤其是在一线城市中，但不同开发者之间收入差距较大。软件开发是一个智力密集型的工作，不同开发者能够提供的价值差别很大，这就使得一个优秀开发者的收入远高于普通开发者：硕士和博士毕业的高收入者比率要远高于本科及以下的；金融和互联网行业的高收入比率最高。 自学是开发者持续学习的主要路径 软件开发行业日新月异，只有保持持续学习才能跟上技术变化的脚步，终身学习是现代人保持竞争力甚至是维持生存的必要手段。 从调研中可以看到，53% 的开发者会通过在未参加正式课程的情况下，自学一门新语言、框架或工具。但同时，也有半数的人参加过在职培训或者线下课程，相对于自学的灵活性而言，这类培训会更为系统和完整，对于长期的个人提升有所裨益，开发者可以适当选择。但与之相悖的是，只有不到 40% 的开发者，愿意为学习付费，这可能会导致参与的课程质量不够高。 Java 雄踞语言榜，Visual Studio 受开发者欢迎 Java 长盛：使用最多，开发者最想学 从编程语言来看，Java 是最多人使用的语言，而 JavaScript 和 SQL 分别是第二第三位。这三门语言，使用场景都很广泛，Java 一方面后端开发最常使用，生态成熟度无人可比；另一方面，Java 依然是 Android 上最重要的开发语言，与之相比 ，新兴的 Kotlin 只有 2% 的开发者在使用。而 JavaScript 不仅是前端开发的必备语言，还用在 Web 开发、小程序开发等场景下。 Java 和 Python 依然是开发者最希望学习的语言之一，只是相比之下，Python 的热度有所降低，这可能和机器学习没有去年那么火热有所关联。变化比较大的是 Go 语言，与去年相比，今年的调研中想学 Go 语言的开发者降低到了 4%，与之相似，Kotlin、R 的学习意愿也大幅降低。 从这个趋势也可以看到，如今的开发者更意愿去学习一些相对成熟度、用途更为广泛的语言，对一些代表新模式的语言乐衷程度有所降低。 七成以上在使用 Windows 操作系统，83% 在使用 MySQL 数据库 72% 开发者在使用 Windows 操作系统，18% 在使用 Linux 系列操作系统。在存储服务的使用上，MySQL 继续扩大其使用率到达了 83%，几乎是开发者必备的技能。和去年相比，Elasticsearch 出现在数据库使用的调研中，在大数据时代，Elasticsearch 作为提供搜索服务的第一选型，也必然会被越来越多的开发者学习和使用 Node.js 是相对使用普遍的技术框架 在 Web 开发上，前端使用 Vue.js 后端使用 Spring 是最常见的选型方案，与之相对应，Node.js 是最多被用到的框架，这和当今多端开发的趋势密不可分。后端用微服务架构，中间用 Node.js 粘合出适合 Web、Android、iOS 等不同端和场景使用的 APIs，是当下主流的部署方案之一，既可以前后端分离提高开发效率，又可以在保障服务稳定性的同时提升灵活性。而TensorFlow 成为开发者最期望学习的框架，这说明开发者依然对机器学习保持关注和热情。 Visual Studio 是最为普遍使用的开发环境 在开发环境的选择上，Visual Studio 是最为普遍使用的开发环境，这和微软对开发者的投入密不可分。微软投入了大量的研发力量，使得 Visual Studio 可以在各种操作系统进行各种编程语言的开发，其强大且完善的插件系统可以满足开发者的各种需求，使其可以超过 IntelliJ。 大数据平台以私有云部署为主，Spark 使用率高达 44% 私有云部署解决方案是企业构建大数据平台的主要方式 随着分布式计算和云平台的逐步成熟，目前大部分公司都有能力搭建自己的大数据平台。调研数据显示，81% 企业在进行大数据相关的开发和应用，50% 的企业选择私有云解决方案来部署大数据应用，28% 的企业选择自主研发。 仅 19% 企业使用商业发行版 Hadoop 版本搭建数据平台 调查报告发现，有 30% 以上的企业并没有使用相对成熟的 Hadoop 技术搭建数据平台，这些企业的算法性能会很大程度上受限于低效的平台，更不可能开发出更高效的数据分析算法。但幸运的是大部分企业都基于商业版或者社区版 Hadoop 搭建了数据平台，这些公司的侧重点主要在应用发现和算法的设计层面，更有可能在不久的将来实现大数据的价值。 Spark 是企业大数据平台最普遍的组件 Apache Spark 是一个处理大规模数据的快速通用引擎，它可以独立运行，也可以在 Hadoop、Mesos、云端运行，它可以访问各种数据源包括 HDFS、Cassandra、HBase 和 S3，可以提升 Hadoop 集群中的应用在内存和磁盘上的运行速度。Spark 生态系统中除了核心 API 之外，还包括其他附加库，可以为大数据分析和机器学习领域提供更多的能力。本次调研中，Spark 是使用最普遍的大数据平台组件，使用率达到44%，而MapReduce使用率仅为21%。 分布式文件系统 HDFS 作为核心组件之一，使用率也达到了 39%。企业对大数据平台应用最多的场景是统计分析、报表生成及数据可视化，38% 企业使用ELK（ElasticSearch + Logstash + Kibana）实时日志分析平台。 综上所述，目前大数据的发展热潮令人欢欣鼓舞。一个优秀的大数据团队，需要有对产品开发具有高敏感性同时对技术有一定理解的人才，同时需要理论基础极其扎实，能对实际问题进行抽象建模和算法设计的人才。只有双管齐下，在产品和技术方面进行深层次探索，才能真正实现大数据产业的繁荣。 区块链质变，比特币逆袭以太坊成 TOP 1 开发平台 22% 的开发者正在用或者准备用区块链技术解决技术问题 区块链技术的发展，是一个量变到质变的过程。相比于 2018 年，对区块链和加密货币了解的人从 22% 增长到 32%，准备尝试用区块链技术解决一些问题的人数从 14% 增长到 16%，仅有 4% 的人对区块链完全不了解。 43% 的受访者在从事公有链（比特币、以太坊等）的开发 本次调研中，43% 的受访者在从事公有链（比特币、以太坊等）的开发。目前行业侧重发展的方向为解决方案、公链及联盟链，公有链由于其自带激励机制，对于普通开发者有直接的回馈，所以上面开发者占比高也比较合情理。行业解决方案从去年的 27% 增加到今年的 36%，说明传统行业开发者对区块链的认可度在增加。 区块链本质上是技术，落地场景及实际应用才是连接社会效益的关键。 比特币和以太坊是当前两种主流的区块链开发平台 在行业开发者的印象中，以太坊一直是开发平台领域的头号玩家。但今年数据显示，以太坊从 2018 年的 44% 占比第一，降到 24%；比特币从 2018 年的 28%，上升到 35%，占比第一。比特币在行业内外仍然拥有最强共识，在闪电网络的加持下，大家也似乎感受到比特币离商用也不再遥远了。 金融是普遍认为的行业应用方向 金融行业是普遍认为的行业应用方向，占 36%。区块链本身具备的防篡改、可追溯的特点，能大大降低金融行业监管成本，不过金融的进入门槛相对也较高，需要各方面技术的配合。其次，智能硬件和物联网也被认为是主流应用方向，占 14%。不过相比其他众多已经很成熟的技术，依托区块链的解决方案在实际使用中，往往面临必要性缺失的问题，因此区块链应用发展仍任重道远。 在区块链结合行业之前，更加要重视与其他新技术的结合和协同：物联网设备能够提供大量数据，5G 能够提供高速传输，存储可以解决区块存放的问题等。 算法工程师最急缺，TensorFlow 占据 AI 深度学习框架榜首 64% 的企业尚未实现智能化 在经历了 2019 年的行业低谷期之后，无论是行业巨头还是新兴独角兽，都开始审视 AI 能够切实落地的场景。调研数据显示，14% 的企业尚无信息化基础，27% 的企业实现了事务处理数字化，22％ 的企业具备商业智能基础设施，实现描述性分析。使用机器学习实现预测性分析和决策优化的企业占 16%，而在业务中全面使用 机器学习/深度学习算法工程师最急缺 在岗位分布上，由于深度学习是以大数据为基础的，而感知智能中的计算机视觉又是目前深度学习较为成熟的应用，所以，机器学习和深度学习工程师，以及数据工程师、计算机视觉工程师排行在前三位。当前最急缺的岗位也是机器学习/深度学习算法工程师、数据科学家/数据分析师/数据挖掘工程师岗位。 53% 的开发者表示其团队急缺机器学习/深度学习算法工程师，37% 表示急缺数据科学家/数据分析师/数据挖掘工程师。 TensorFlow是人工智能领域主流深度学习框架 此次调研中，TensorFlow 使用普及率达到 48%。从技术本身的角度来看，较为成熟的 TensorFlow 成为 AI 工程师的首选深度学习框架，Torch/PyTorch由于其开发效率较高，也得到了较多支持。 35% 开发者选用国产 AI 芯片应用于自己的 AI 开发 在 AI 芯片领域，国内厂商也开始弯道超车，越来越多的开发者也开始关注国内 AI 芯片的进展。调查数据显示，选用国产 AI 芯片应用于自己的 AI 开发时最看重的因素方面，对主流 AI 框架的支持能力是最普遍的因素，占 35%。 物联网云平台三足鼎立：阿里物联、华为云、百度 IoT 69% 的开发者认为未来 5G 网络的传输速率能达到 4G 的 10 倍以上 每一代新型的通信系统总是能带来更大的带宽。据报告显示，近七成开发者认为未来 5G 网络的传输速率能够达到 4G 网络的 10 倍以上。 影响 5G 普及的三大因素：5G 套餐价格未定、运营商的开发程度、需要更换手机 由于目前 5G 网络使用者较少，费用较低廉的套餐还没有推出，第一代 5G 终端不太成熟等原因，目前 87% 的开发者认为 5G 套餐费用过高，并且大部分开发者认为 5G 网络目前覆盖范围有限，因此将近 40% 的开发者正处于观望阶段。 值得一提的是，本次调查中 62% 的开发者认为，5G 时代应该加强对个人隐私的保护，这反映出目前社会对数据隐私越来越重视的整体趋势。 阿里物联和华为云是应用相对普遍的 IoT 云平台 根据调查，2019 年物联网云平台呈现三足鼎立的趋势：阿里物联、华为云、百度 IoT 成为用户最多的三种物联网平台，并且和第四名中移物联远远拉开了差距，这和我们的实际使用体验一致。 未来的基础物联网平台可能会继续呈现以偏硬件实现为主的华为云和以偏软件体验为主的阿里、百度物联平台的三足鼎立局面。 物联网技术开发：Linux 和 Windows 是使用较多的操作系统 Linux 和 Windows 是较普遍的操作系统，使用率分别为 51%、44%。目前在物联网设备开发过程中，Linux、Windows 和 Android 较为普遍，依然延续了 PC 平台的开发者操作系统份额。虽然华为、阿里等公司在 2019 年均发布了自己的物联网专用操作系统，但还并未得到开发者的大规模认可，大公司的物联网操作系统发展之路依然任重而道远。 Wi-Fi 是应用最普遍的物联网通信技术 在本次调研中，近距离通信（比如 Wi-Fi 和蓝牙）是现存物联网开发者最主要的通信方式。然而这种比重可能会随着未来 3~4 年内车联网的大规模商业化产生变化，汽车、工业物联、智能电网这类高移动性、高可靠和低延迟物联网场景会更适合需要整体规划的运营商网络。 六成开源开发者无收入，Apache 项目最受喜欢 77% 开发者每周在开源上投入时间不超过 5 小时 无论是大数据、区块链、人工智能还是物联网领域，其中最为重要的、最受欢迎的技术都是开源的。但是报告统计发现，有超过一半的开发者很少参与开源项目，每周在开源上投入不超过 5 小时的占 77%，其中，1 小时以内的占 31%。此外，65% 的开发者不曾在开源上获得收入，获得不错收入的仅占一成。 开发者最喜欢的开源项目是 Apache 25% 开发者最喜欢 Apache，24% 开发者最喜欢 Linux。作为全球最大的软件基金会，开发者用过的诸多项目，例如 Dubbo、Log4j、Maven、RocketMQ 和 Tomcat 等，均孵化自 Apache。 国内开源的现状虽然近年来已经有了很大的发展，但是一个残酷的事实是，老兵正在离开这个行业，离开一线开发的队伍：报告数据显示，30 岁以下的开发者人数超过 82%，接触开源的时间在 5 年以内的开发者超过 83%。随着那些经验丰富的老兵转行或是进入管理层，不再写代码、也不再参与开源的事实也就凸显出来.....未来开源的建设，依然任重而道远。 在数据中寻找共性，《2019 - 2020 中国开发者调查报告》全面且真实地展现中国开发者及技术现状，希望对您的学习或工作有所帮助。 ———————————————— 版权声明：本文为CSDN博主「CSDN资讯」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。 原文链接：https://blog.csdn.net/csdnnews/article/details/104538091

原版英文链接：点击这里 作者 | Md Kamaruzzaman 译者 | 无明 策划 | 小智 基础设施：条条道路通云端 对于云厂商来说，2019 年是硕果累累的一年。不仅初创公司在使用云计算，那些很注重安全的“保守派”公司（如政府机构、医疗保健机构、银行、保险公司，甚至是美国五角大楼）也在迁移到云端。这种趋势在 2020 年将会继续，大大小小的公司都将（或者至少有计划）迁移到云端。Gartner 公司最近发布了一个数字： 如果你是一个还在考虑要不要迁移到云端的决策者，不妨重新审视一下你的策略。如果你是一个独立开发者，并且还没使用过云基础设施，那么完全可以在 2020 年尝试一下。很多大型的云厂商（如亚马逊、微软、谷歌）都提供了免费的体验机会。谷歌在这方面做得特别大方，它提供了价值 300 美元的一年免费服务。 策划注：阿里、腾讯、华为等国内云厂商同样有免费云服务试用产品。 云平台：亚马逊领头，其他跟上 作为第一大云厂商，亚马逊在 2019 年可谓风生水起。凭借其丰富的产品组合，亚马逊将把它的优势延续到 2020 年。Canalys 发布的 2019 年第三季度报告指出，大型云厂商（AWS、Azure、GCP）占据 56% 的市场份额，其中 AWS 独享 32.6%。 其他云厂商也在努力缩短与 AWS 之间的差距。微软把主要目标转向了大型企业。最近，微软打败了亚马逊，从美国五角大楼拿到了一个 100 亿美元的大单子。这个单子将提升 Azure 的声誉，同时削弱 AWS 的士气。 谷歌一直在推动 CNCF，实现云计算运维的标准化。谷歌的长期目标是让云迁移变得更容易，方便企业从 AWS 迁移到 GCP。IBM 之前斥资 360 亿美元收购了 RedHat，也想要在云计算市场占有一席之地。 在亚太地区，阿里云市场规模超过了 AWS、Azure 的总和，全球排名第三。中国国内腾讯云等企业的增长势头也十分迅猛。 2020 年将出现更多的并购。当然，很多初创公司将会带来新的想法和创新，例如多云服务。因为竞争激烈，这些公司只能从降价和推出更多的创新产品来获取利润。 容器化：Kubernetes 将会更酷 在容器编排领域，虽然一度出现了“三足鼎立”（Kubernetes、Docker Swarm 和 Mesos），但 Kubernetes 最终脱颖而出，成为绝对的赢家。云是一个分布式系统，而 Kubernetes 是它的 OS（分布式的 Linux）。2019 年北美 KubeCon+CloudNativeCon 大会的参会者达到了 12000 名，比 2018 年增长了 50%。以下是过去 4 年参会人数的增长情况。 在 2020 年，Kubernetes 不仅不会后退，只会变得越来越强，你完全可以把赌注压在 Kubernetes 身上。另外值得一提的是，Migrantis 最近收购了 Docker Enterprise，不过收购数额不详。 几年前，人们张口闭口说的都是 Docker，而现在换成了 Kubernetes。Docker 在它的全盛时期未能盈利，反而在优势渐退几年之后才尝试变现。这再次说明，在现代技术世界，时机就是一切。 软件架构：微服务将成为主流 谷歌趋势表明，微服务架构范式在 2019 年持续增长了一整年。 随着软件行业整体逐步迁移到云端，微服务也将成为占主导地位的架构范式。微服务架构崛起的一个主要原因是它与云原生完美契合，可以实现快速的软件开发。我在之前的一篇博文中解释了微服务架构的基本原则及其优势和劣势。 https://towardsdatascience.com/microservice-architecture-a-brief-overview-and-why-you-should-use-it-in-your-next-project-a17b6e19adfd 我假设现在也存在一种回归到单体架构的趋势，因为在很多情况下，微服务架构有点过头了，而且做好微服务架构设计其实很难。微服务架构有哪些好的实践？在之前的另一篇博文中，我也给出了一些大概，希望对读者有用。 https://towardsdatascience.com/effective-microservices-10-best-practices-c6e4ba0c6ee2 编程语言（整体）：Python 将吞噬世界 机器学习、数据分析、数据处理、Web 开发、企业软件开发，甚至是拼接黑洞照片，Python 的影子无处不在。 在著名的编程语言排行榜网站 TIOBE 上，Python 位居最流行编程语言第三位，仅次于 Java 和 C 语言。 更有意思的是，在 2019 年，Python 的流行度翻了一番（从 5% 到 10%）。 Python 的崛起将在 2020 年延续，并缩短与 Java 和 C 语言之间的差距。另一门无所不在的编程语言 JavaScript 正面临下行的风险。为什么 Python 的势头会如此强劲？因为它的入手门槛低，有一个优秀的社区在支持，并受到数据科学家和新生代开发者的喜爱。 编程语言（企业方面）：Java 将占主导 之前的 TIOBE 网站截图显示，Java 仍然是一门占主导地位的编程语言，并将在 2020 年继续保持这种地位。JVM 是 Java 的基石，其他编程语言（如 Kotlin、Scala、Clojure、Groovy）也将 JVM 作为运行时。最近，Oracle 修改了 JVM 的许可协议。 新的许可协议意味着使用 Java、Kotlin、Scala 或其他 JVM 编程语言的公司需要向 Oracle 支付大额费用。所幸的是，OpenJDK 让 JVM 继续免费。另外，还有其他一些公司为 JVM 提供企业支持。 因为体积和速度方面的问题，基于 JVM 的编程语言并不适合用在今天的无服务器环境中。Oracle 正在推动 GraalVM 计划，旨在让 Java 变得更加敏捷和快速，让它更适合用在无服务器环境中。因为除了 Java，没有其他编程语言可以提供企业级的稳定性和可靠性，所以 Java 将在 2020 年继续占主导地位。 企业版 Java：Spring 继续发力 曾几何时，在企业开发领域，Spring 和 JavaEE 之间存在着白热化的竞争。但因为 Oracle 在 JavaEE 方面没有作为，在竞争中惨败，这导致了“MicroProfile”计划的形成，并最终促成了 JakartaEE。 虽然所有的政策和活动都是围绕 JavaEE 展开，但 Spring 事实上已经赢得了这场企业 JVM 之争。2020 年，Spring 将成为 JVM 生态系统的头牌。 有两个正在进展中的项目，它们旨在减小 Java 的体积，让它更适合用在无服务器环境中。 其中一个是 Micronaut（https://micronaut.io/）。 另一个是 Quarkus（https://quarkus.io/）。 这两个项目都使用了 GraalVM，它们在 2020 年将会得到 Java 社区更多的关注。 编程语言：后起之秀的突破 2000 年代，编程语言的发展出现了停滞。大多数人认为没有必要再去开发新的编程语言，Java、C 语言、C++、JavaScript 和 Python 已经可以满足所有的需求。但是，谷歌的 Go 语言为新编程语言大门打开了一扇大门。在过去十年出现了很多有趣的编程语言，比如 Rust、Swift、Kotlin、TypeScript。导致这种情况的一个主要原因是已有的编程语言无法充分利用硬件优势（例如多核、更快的网络、云）。另一个原因是现代编程语言更加关注开发者经济，即实现更快速更容易的开发。在 Stackoverflow 提供的一份开发者报告中，排名靠前的现代编程语言如下所示（Rust 连续 4 年名列第一）。 在之前的一篇博文中，我深入探讨了现代编程语言，对比 Rust 和 Go 语言，并说明了为什么现在是采用这些语言的好时机。 https://towardsdatascience.com/back-to-the-metal-top-3-programming-language-to-develop-big-data-frameworks-in-2019-69a44a36a842 最近，微软宣布他们在探索使用 Rust 来开发更安全的软件。 亚马逊最近也宣布要赞助 Rust。 谷歌宣布将 Kotlin 作为 Android 官方开发语言，所以，在 JVM 领域，Kotlin 成了 Java 的主要竞争对手。 Angular 使用 TypeScript 代替 JavaScript，将其作为主要的编程语言，其他 JavaScript 框架（如 React 和 Vue）也开始为 TypeScript 提供更多的支持。 这种趋势将在 2020 年延续下去，很多巨头公司将会深入了解新一代编程语言（如 Rust、Swift、TypeScript、Kotlin），它们会站出来公开表示支持。 Web：JavaScript 继续占主导地位 曾几何时，JavaScript 并不被认为是一门强大的编程语言。在当时，前端内容主要通过后端框架在服务器端进行渲染。2014 年，AngularJS 的出现改变了这种局面。从那个时候开始，更多的 JavaScript 框架开始涌现（Angular 2+、React、Vue、Meteor），JavaScript 已然成为主流的 Web 开发语言。随着 JavaScript 框架不断创新以及微服务架构的崛起，JavaScript 框架在 2020 年将继续主导前端开发。 JavaScript 框架：React 闪耀 虽然 React 是在 AngularJS 之后出现的，但在过去十年对 Web 开发产生了巨大的影响，这也让 Facebook 在与 Google+ 的竞争中打了一场胜战。React 为前端开发带来了一些新的想法，比如事件溯源、虚拟 DOM、单向数据绑定、基于组件的开发，等等。它对开发者社区产生了重大影响，以至于谷歌放弃了 AngularJS，并借鉴 React 的想法推出了彻底重写的 Angular 2+。React 是目前为止最为流行的 JavaScript 框架，下图显示了相关的 NPM 下载统计信息。 为了获得更好的并发和用户体验，Facebook 宣布完全重写 React 的核心算法，推出了 React-Fiber 项目。 2020 年，React 仍然是你开发新项目的首选 Web 框架。其他框架（如 Angular/Angular 2+ 或 Vue）呢？Angular 仍然是一个不错的 Web 开发框架，特别适合企业开发。我敢肯定谷歌在未来几年会在 Angular 上加大投入。Vue 是另一个非常流行的 Web 框架，由中国的巨头公司阿里巴巴提供支持。如果你已经在使用 Angular 或 Vue，就没必要再迁移到 React 了。 App 开发：原生应用 在移动 App 开发方面，有关混合应用开发的炒作有所消停。混合开发提供了更快的开发速度，因为只需要一个开发团队，而不是多个。但原生应用提供了更好的用户体验和性能。另外，混合应用需要经过调整才能使用一些高级特性。对于企业来说，原生应用仍然是首选的解决方案，这种趋势将在 2020 年延续。Airbnb 在一篇博文中非常详细地说明了为什么他们要放弃混合应用开发平台 React Native。 https://medium.com/airbnb-engineering/sunsetting-react-native-1868ba28e30a 尽管 Facebook 尝试改进 React Native，谷歌也非常努力地推动混合 App 开发平台 Flutter，但它们仍然只适合用于原型、POC、MVP 或轻量级应用的开发。所以，原生应用在 2020 年仍将继续占主导地位。 在原生应用开发方面，谷歌和苹果分别将 Kotlin 和 Swift 作为各自平台主要的编程语言。谷歌最近再次重申了对 Kotlin 的支持，这对于 Kotlin 用户来说无疑是个好消息。 混合应用开发：React Native 在很多情况下，混合应用是个不错的选择。在这方面也有很多选择：Xamarin、Inoic、React Native 和 Flutter。Facebook 基于成熟的 React 框架推出了 React Native。就像 React 在 Web 框架领域占据主导地位一样，React Native 在混合应用领域也占据着主导地位，如下图所示。 React Native 和 React 有共同的基因，都提供了高度的代码重用性以及“一次开发，到处运行”的能力。React Native 的另一个优势是 Facebook 本身也用它来开发移动应用。谷歌在这个领域起步较晚，但在去年，谷歌的混合应用开发框架 Flutter 获得了不少关注。Flutter 提供了更好的性能，但需要使用另一门不是那么流行的编程语言 Dart。React Native 在 2020 年将继续占主导地位。 API：REST 将占主导地位 REST 是 API 领域事实上的标准，被广泛用在基于 API 的服务间通信上。当然，除了 REST，我们还有其他选择，比如来自谷歌的 gRPC 和来自 Facebook 的 GraphQL。 它们提供了不同的能力。谷歌开发的 gRPC 作为远程过程调用（如 SOAP）的化身，使用 Protobuf 代替 JSON 作为消息格式。Facebook 开发的 GraphQL 作为一个集成层，避免频繁的 REST 调用。gRPC 和 GraphQL 都在各自的领域取得了成功。2020 年，REST 仍然是占主导地位的 API 技术，而 GraphQL 和 gRPC 将作为补充技术。 人工智能：Tensorflow 2.0 将占主导地位 谷歌和 Facebook 也是深度学习 / 神经网络领域的主要玩家。谷歌基于深度学习框架 Theano 推出了 TensorFlow，它很快就成为深度学习 / 神经网络的主要开发库。谷歌还推出了特别设计的 GPU（TPU）来加速 TensorFlow 的计算。 Facebook 在深度学习领域也不甘落后，他们拥有世界上最大的图像和视频数据集合。Facebook 基于另一个深度学习库 Torch 推出了深度学习库 PyTorch。TensorFlow 和 PyTorch 之间有一些区别，前者使用的是静态图进行计算，而 PyTorch 使用的是动态图。使用动态图的好处是可以在运行时纠正自己。另外，PyTorch 对 Python 支持更好，而 Python 是数据科学领域的一门主要编程语言。 随着 PyTorch 变得越来越流行，谷歌也赶紧在 2019 年 10 月推出了 TensorFlow 2.0，也使用了动态图，对 Python 的支持也更好。 2020 年，TensorFlow 2.0 和 PyTorch 将齐头并进。考虑到 TensorFlow 拥有更大的社区，我估计 TensorFlow 2.0 将成为占主导地位的深度学习库。 数据库：SQL是王者,分布式SQL是王后 在炒作 NoSQL 的日子里，人们嘲笑 SQL，还指出了 SQL 的种种不足。有很多文章说 NoSQL 有多么的好，并将要取代 SQL。但等到炒作的潮水褪去，人们很快就意识到，我们的世界不能没有 SQL。以下是最流行的数据库的排名。 可以看到，SQL 数据库占据了前四名。SQL 之所以占主导地位，是因为它提供了 ACID 事务保证，而 ACID 是业务系统最潜在的需求。NoSQL 数据库提供了横向伸缩能力，但代价是不提供 ACID 保证。 互联网公司一直在寻找“大师级数据库”，也就是既能提供 ACID 保证又能像 NoSQL 那样可横向伸缩的数据库。目前有两个解决方案可以部分满足对“大师级数据库”的要求，一个是亚马逊的 Aurora，一个是谷歌的 Spanner。Aurora 提供了几乎所有的 SQL 功能，但不支持横向写伸缩，而 Spanner 提供了横向写伸缩能力，但对 SQL 支持得不好。 2020 年，但愿这两个数据库能够越走越近，或者有人会带来一个“分布式 SQL”数据库。如果真有人做到了，那一定要给他颁发图灵奖。 数据湖：MinIO 将要崛起 现代数据平台非常的复杂。企业一般都会有支持 ACID 事务的 OLTP 数据库（SQL），也会有用于数据分析的 OLAP 数据库（NoSQL）。除此之外，它们还有其他各种数据存储系统，比如用于搜索的 Solr、ElasticSearch，用于计算的 Spark。企业基于数据库构建自己的数据平台，将 OLTP 数据库的数据拷贝到数据湖中。各种类型的数据应用程序（比如 OLAP、搜索）将数据湖作为它们的事实来源。 HDFS 原本是事实上的数据湖，直到亚马逊推出了对象存储 S3。S3 可伸缩，价格便宜，很快就成为很多公司事实上的数据湖。使用 S3 唯一的问题是数据平台被紧紧地绑定在亚马逊的 AWS 云平台上。虽然微软 Azure 推出了 Blob Storage，谷歌也有类似的对象存储，但都不是 S3 的对手。 对于很多公司来说，MinIO 或许是它们的救星。MinIO 是一个开源的对象存储，与 S3 兼容，提供了企业级的支持，并专门为云原生环境而构建，提供了与云无关的数据湖。 微软在 Azure Marketplace 是这么描述 MinIO 的：“为 Azure Blog Storage 服务提供与亚马逊 S3 API 兼容的数据访问”。如果谷歌 GCP 和其他云厂商也提供 MinIO，那么我们将会向多云迈出一大步。 大数据批处理：Spark 将继续闪耀 现如今，企业通常需要基于大规模数据执行计算，所以需要分布式的批处理作业。Hadoop 的 Map-Reduce 是第一个分布式批处理平台，后来 Spark 取代了 Hadoop 的地位，成为真正的批处理之王。Spark 是怎样提供了比 Hadoop 更好的性能的？我之前写了另一篇文章，对现代数据平台进行了深入分析。 https://towardsdatascience.com/programming-language-that-rules-the-data-intensive-big-data-fast-data-frameworks-6cd7d5f754b0 Spark 解决了 Hadoop Map-Reduce 的痛点，它将所有东西放在内存中，而不是在完成每一个昂贵的操作之后把数据保存在存储系统中。尽管 Spark 重度使用 CPU 和 JVM 来执行批处理作业，但这并不妨碍它成为 2020 年批处理框架之王。我希望有人能够使用 Rust 开发出一个更加高效的批处理框架，取代 Spark，并为企业省下大量的云资源费用。 大数据流式处理：Flink 是未来 几年前，实现实时的流式处理几乎是不可能的事情。一些微批次处理框架（比如 Spark Streaming）可以提供“几近”实时的流式处理能力。不过，Flink 改变了这一状况，它提供了实时的流式处理能力。 2019 年之前，Flink 未能得到足够的关注，因为它无法撼动 Spark。直到 2019 年 1 月份，中国巨头公司阿里巴巴收购了 Data Artisan（Flink 背后的公司）。 在 2020 年，企业如果想要进行实时流式处理，Flink 应该是不二之选。不过，跟 Spark 一样，Flink 同样重度依赖 CPU 和 JVM，并且需要使用大量的云资源。 字节码：WebAssembly将被广泛采用 我从 JavaScript 作者 Brandon Eich 的一次访谈中知道了 WebAssembly 这个东西。现代 JavaScript（ES5 之后的版本）是一门优秀的编程语言，但与其他编程语言一样，都有自己的局限性。最大的局限性是 JavaScript 引擎在执行 JavaScript 时需要读取、解析和处理“抽象语法树”。另一个问题是 JavaScript 的单线程模型无法充分利用现代硬件（如多核 CPU 或 GPU）。正因为这些原因，很多计算密集型的应用程序（如游戏、3D 图像）无法运行在浏览器中。 一些公司（由 Mozilla 带领）开发了 WebAssembly，一种底层字节码格式，让任何一门编程语言都可以在浏览器中运行。目前发布的 WebAssembly 版本可以支持 C++、Rust 等。 WebAssembly 让计算密集型应用程序（比如游戏和 AutoCAD）可以在浏览器中运行。不过，WebAssembly 的目标不仅限于此，它还要让应用程序可以在浏览器之外运行。WebAssembly 可以被用在以下这些“浏览器外”的场景中。 移动设备上的混合原生应用。没有冷启动问题的无服务器计算。在服务器端执行不受信任的代码。 我预测，2020 年将是 WebAssembly 取得突破的一年，很多巨头公司（包括云厂商）和社区将会拥抱 WebAssembly。 代码：低代码 / 无代码将更进一步 快速的数字化和工业 4.0 革命意味着软件开发者的供需缺口巨大。由于缺乏开发人员，很多企业无法实现它们的想法。为了降低进入软件开发的门槛，可以尝试无代码（No Code）或低代码（Low Code）软件开发，也就是所谓的 LCNC（Low-Code No-Code)。它已经在 2019 年取得了一些成功。 LCNC 的目标是让没有编程经验的人也能开发软件，只要他们想要实现自己的想法。 虽然我对在正式环境中使用 LCNC 框架仍然心存疑虑，但它为其他公司奠定了良好的基础，像亚马逊和谷歌这样的公司可以基于这个基础构建出有用的产品，就像 AWS Lambda 的蓬勃发展是以谷歌 App Engine 为基础。 2020 年，LCNC 将会获得更多关注。