区块链咖啡豆斯里兰卡6000米区块链kafka

古泉财经 2023年01月30日 18:10 77 0

今天给大家聊到了区块链kafka，以及区块链咖啡豆斯里兰卡6000米相关的内容，在此希望可以让网友有所了解，最后记得收藏本站。

“根本就不需要 Kafka 这样的大型分布式系统！”

作者 | Normcore Tech

译者 | 弯月，责编 | 屠敏

出品 | CSDN（ID：CSDNnews）

以下为译文：

可能有人没有听说过Kafka，这是一个非常复杂的分布式软件，可协调多台计算机之间的数据传输。更具体地说，该软件的功能是“展平”数据，然后快速地将数据从一个地方移动到另一个地方。一般来讲，如果你有很多数据需要快速处理并发送到其他地方，那么就可以考虑一下Kafka。Kafka还可以在一定期限内保留数据，比如设置数据保存2天、3天或7天，如果你的下游流程失败，那么你还可以利用存储在Kafka中的数据重新处理。

许多处理汇总数据的公司（比如Facebook和Twitter等社交网络数据，以及每晚需要处理大量星体运动的天文学家，或需要快速了解车辆周围环境数据的自动驾驶车辆公司等）都在使用Kafka，将任意地方生产的数据（即用户通过键盘输入的数据，通过望远镜读取的数据，通过车辆遥测读取的数据等）移动至下游流程进行处理和分析。

最近，WeWork更为名The We Company，他们在共享工作间领域取得了成功，其官网宣称公司的使命为：

“提升世界的意识。”其核心业务是从房地产出租公司那里租下办公室，然后转租给无法按照传统流程租赁办公室的个人和小公司。

为了“提升世界的意识”，该公司致力于为世界各地的个人和公司的团队打造独特却又不完全相同的办公空间。最近，该公司还开始涉足教育。

最近，因为上市，WeWork曝光了一些财务信息：

从好的方面来看，根据A xi os的数据，2018年WeWork的入住率为90%，且会员总数在不断增加。

有人常常将WeWork视为硅谷地区的公司过高估值的完美例子。作为一家房地产企业，WeWork烧钱的速度非常快，毫无疑问他们必须努力让公众市场投资者相信公司有长远的发展，同时和还要维护其作为科技公司的地位。

这家公司再三强调说它不是一家房地产公司（毕竟它在不断烧钱对吧？），那么一家消息中介技术公司究竟能提供什么？WeWork曾宣布，它使用Kafka来实现“内部部署的物联网需求”。这是什么意思？

“我们的产品是物理空间，”WeWork的首席开发负责人David Fano说，他在会议期间穿着一件印有“bldgs = data”字样的T恤。

每个办公室都有10个环境传感器——小巧的壁挂式绿色盒子，这些传感器可跟踪室内温度、湿度、空气质量、气压和环境光线水平。还有20个白色的壁挂式信标，呈三角形分布在公共空间（开放式办公区和会议室），用于测量WeWork成员的室内位置（数据是匿名的）。顶部四分之一的传感器通过计算机视觉观察成员的活动。

换句话说，WeWork会跟踪WeWork的多个物理事件并记录所有这些数据。但是......他们真的有必要这样做吗？记录Keith Harring壁画周围开放区域的环境温度能给他们带来怎样的竞争优势？更重要的是，他们能否将这些信息用到重要的项目中？

对于公司而言，重要的是要了解办公室的“单位组合” ——私人办公室、会议空间和开放式办公桌——的比例，我们可以利用这些信息对下一个办公间作出调整。

我觉得这家新闻报道机构需要建立一种思考技术的心理模型。Ben Thompson为Stratechery提供了出色的服务，他建立了聚合理论（ .com /concepts/），我在努力为这些理论建立一个网站，如果必须从中选择一个的话，那便是：

大多数创业公司（以及大公司）现有的技术栈都没有必要。

在此，我想挑战一下那些自认为可以在一个周末期间独自建立Facebook的Hacker News上的开发人员，我认为WeWork的实际业务和架构问题在于：

WeWork需要的只不过是清点进出的人数，然后对容量规划做优化而已，追踪“气压”有什么用？只要你有WeWork的ID，那你肯定是个人或公司。那么，在大堂里安装一个登记系统，并要求会议系统发放名牌，不是更简单吗？

第一项要求根本就不需要Kafka：

目前WeWork有280个办公间。假设每个办公间平均每天有1000个（有这么多吗？）成员出入。那么每天会产生280,000个事务。我们假设每个人在早餐时间进来一次，在午餐时间出入各一次，然后离开。那么每个人会产生4个事务。那么每天大约是100万个事务，这点数据量存储在最常用的开源关系数据库Postgres中就可以了。保守地说，Postgres每秒可以提供10,000次写入（如果设置得当，其写入次数会更高）。每天100万个事件，也就是每秒11次。根本就不是问题。

至于第二项要求，受预订会议室人数的影响，产生的数据量可能更高，但你不需要实时传输数据。你完全可以等到一天结束时批量处理或收集，这同样可以利用司空见惯的关系数据库。

与大型Postgres（或者是BigQuery，或选择其他关系数据库连接到接收JSON传感器数据的Web服务）相比，Kafka的日常开销要高出很多，因为分布式系统非常非常复杂，比传统的系统复杂得多。

Kafka是一个非常优秀的强大的工具，但各个公司在采用该软件时，需要三思而后行。杀鸡焉用牛刀，WeWork用Kafka来记录开放办公间的气压，实属大材小用。

虽然很多时候我们都不需要Kafka，但开发人员很喜欢推荐这个工具，因为他们可以借机积攒经验和谈资。开发人员喜欢用最尖端的技术来完成工作，有时甚至他们自己都没意识到这一点。

过度架构真实存在。 Nemil在一篇文章中说：

在职业生涯的早期，你遇到的大量设计不良的软件系统都要归咎于那些传播错误观点的工程媒体。

在大学和培训班中，你对工程的了解主要来自工程媒体，例如 Hacker News、聚会、会议、Free Code Camp和Hacker Noon等。这些网站广泛讨论的技术（比如微服务、前端框架或区块链）自然会现在你的技术栈中，虽然不是很必要。

使用这些技术栈会导致各个公司承担不必要的债务，导致他们不得不在风险投资周期中寻求更多的资金，无法迈向精益或从别人的资金中解脱出来。

这种不幸的趋势只会持续下去，我们唯一能做的就是公之于众。

原文： .com /p/you-dont-need-kafka

【END】

区块链咖啡豆斯里兰卡6000米区块链kafka

区块链之联盟链（三）认识Fabric

Fabric 是超级账本联盟推出的核心区块链框架，它适合在复杂的企业内和企业间搭建联盟链。根据超级账本联盟的目标， Fabric 被建设为一个模块化的、支持可插拔组件的基础联盟链框架。；

与以太坊系的Quorum不同，Fabric从一开始就只考虑企业间的应用。其独有的channel概念，将企业根据业务目的不同以不同的子网连接起来，每一个子网对应一个channel，而每个channel有自己独立的区块链。而Quorum很显然是只有一个公网（所有企业节点都加入进去），企业与企业间的私有业务是通过Private Manager 完成的。

理解channel的最简单方法就是，将它类比为一个消息服务提供的Topic，实际上Fabic最早就是基于Kafka 的分布式消息服务来实现。

在Fabric网络中，一个企业可以有一个或多个节点加入整个联盟链；一个企业可以加入1个或者多个Channel（子网）；一个节点可以加入1个或者多个channel。每个channel构成一个子网，所以Fabric 是一种由子网组成的网络。

那么Fabric是怎么实现智能合约的执行和完成业务上链（将事务结果记录在区块链里）的呢？

与其它框架不同， Fabric 将整个过程分成了三个阶段：

业务背书阶段：客户的请求发送的背书节点，通过智能合约完成业务的计算（但不更新状态），并完成背书；将背书结果返回个客户端。

业务的排序阶段：客户端将背书结果通过Channel被发送到排序节点（orderer），在排序节点完成事务的排序，并打包到block里，最后下发给所有连接到channel的节点。

业务验证并写入账本阶段 : 通过Gossip 网络，所有Channel的节点都会接收到新的block，节点会验证block中的每一个事务，确定是否有效：有效地将会跟新world state，无效的将会标志为“无效”，不会更新World state，但整个block会被完整的加入到帐本中（包括无效的事务）。

根据以上的描述，Fabric 节点实际可以分为，普通节点和Order节点：

Peer, 普通节点, 完成背书（包括只能合约的执行）和验证.

orderer, 排序节点，完成排序。

加入orderer节点的Fabric网络可以被描述如下：

每一个Channel，都定义了所有属于channel的节点，但是并不需要所有节点都连接到Orderer 节点（节点间可以通过gossip 协议通讯来传播私有数据或事务）.

在区块链中，共识是区块链的基础。与公有链不同，联盟链的共识要求所有加入账本的事务是确定的、最终的，也就是不可以有分叉，区块与区块间的顺序是一定的，只存在唯一条链。在Fabric 中，这个客观需求正是由排序实现的，所有的事务将被提交给orderer节点获得确定的顺序，并最终打包成block进入帐本。 Fabric 从1.4.1开始支持基于Raft实现排序服务, 可以认为基于Raft实现共识。

基于RAFT的排序服务相对于早期的Kafka 具有更好的分布性，配置更加简单，是联盟链里常用的一个常用的达成共识的算法，Quorum就默认使用RAFT作为共识层。简单的说，RAFT是一个leader和follower的模式，所有加入RAFT网络的节点，任意时候都有一个leader, 只有这个leader有权决定事务的顺序，并打包成Block，其它节点只能作为follower提交事务和同步block。

基于FAFT网络，每个企业可以有一个或多个节点参与到Orderer中去。在Frabric中企业间的网络连接可以变化成如下形式：

区块链的使用用户在以太网中被称作EOA（External of Account）, EOA的载体是钱包。我们沿用这个概念，来看看Fabric是如何实现用户和发起事务的。Fabric中EOA是一个CA中心发布的certificate（x.509），一个Certificate代表一个Identity（这与以太坊还是有很大区别的，以太坊中一个EOA其实是一个hash地址），EOA能够参与的channel以及被授权的操作是有channel的MSP（ Membership Service Provider）决定的（如下图）。

注：certificate 是一种密码学上验证身份的通用做法； certificate包含了个人的信息，公钥以及发布这个certificate的CA的签名。验证方只需要拥有这个CA的证书（包含CA的公钥），就可以验证这个签名是否正确，certificate的内容是否有篡改。简单的说，通过CA和Certificate，我们可以获得一个可验证的的身份和信任链。

如上图，fabric中通要使用Wallet作为EOA的载体，一个Wallet中可以包含多个Identity（x.509 certificate）。 Identity 通过 CA提供的信任链来验证正确性。

验证了身份之后， Fabric 通过MSP在区块链网络中解决该身份是否代表组织的成员和在组织内具有什么角色。例如，channel首先会验证当前用户Identity是否是有效地身份，然后通过MSP查看其所处的企业和具有的角色，最终确定该用户是否有权执行操作。

可以说，Fabric的访问控制是通过MSP来完成的。在每一个需要访问控制的地方都需要定义一个MSP。例如，每个channel都定义一个MSP，这个MSP规定了在channel范围内资源的访问权限。 MSP 是Fabric里一个晦涩难懂的概念，也是其赋予企业间安全访问的基础。

前文提到， Fabric 将业务处理和上网分成了三个部分，背书，排序，验证后加入账本。

其中背书是Fabric执行智能合约的阶段。以太坊中，智能合约是在EVM中执行的，有多种语言支持。在Fabric，智能合约被称为chaincode：一个chaincode 可以理解为是智能合约的容器，可以包含一个或多个智能合约，不用于EVM, chaincode是在 JVM 或NodeJS中执行。

客户应用程序通过智能合约来访问账本，每一个可访问的智能合约都被安装在客户端可以访问的节点上，并被定义在channel里。（有只能合约的节点被称为背书节点，没有只能合约的节点被称未提交节点，提交节点只维护账本）

客户应用提交一个交易请求，请求到达背书节点，背书节点首先会验证客户的签名，确保客户的身份有权执行本次交易，接着执行交易提及的智能合约（chaincode），并生成一个背书响应（或者叫做交易提案，tran-proposal）。这个背书响应中通常包含World state 的读集合，写集合，以及节点对本次交易的签名。这里与以太坊系联盟链最主要的不同是：背书阶段只模拟交易，并不真正更新交易结果。而真正更新交易在第三阶段完成。背书节点最后将生成的背书响应fanhui给客户端，智能合约部分的执行就结束了。

通常一个交易的执行需要多方的签名，所以客户端需要将一个交易发送给多个背书节点，这些背书节点的选择需要满足背书策略的要求。

下图是一个包含有客户、背书节点，提交节点的网络示意图。

根据Fabric官方的参考文档，客户交易的正果过程可使用下图描述。

如上图，从1到3，为背书阶段，4为排序阶段，4.1,4,2, 5为验证提交阶段。参考 Frabic的节点概念，可以了解更多在交易细节的概念。

总的来看， Fabric 更专注于企业间，通过上文，可以让大家对Fabric的基本构成与概念有一个总的了解。 Fabric本身并不神秘，都是使用的现有的企业间的技术。要更好的了解，建议参考阅读分布式消息系统和企业的安全基础设施（CA相关）的支持。与以太坊系联盟链实现比较， Fabric 的子网更概念对于复杂企业间应用适应更强，但是其复杂的安全考量，使得运营成本很高，另外，Fabric 使用Certificate做为用户身份，有很大的局限性，在新的2.0里，Fabric对于此处将有所改变。

下一篇，我们将来看看Sawtooth , 由Inter 提供的区块链框架。

区块链之联盟链(一) 认识以太坊

区块链之联盟链(二) 认识Quotum

区块链之联盟链(三) 认识Fabric

区块链之联盟链(四) 认识Sawtooth

如何检测区块链智能合约的风险等级高低

随着上海城市数字化转型脚步的加快，区块链技术在政务、金融、物流、司法等众多领域得到深入应用。在应用过程中，不仅催生了新的业务形态和商业模式，也产生了很多安全问题，因而安全监管显得尤为重要。安全测评作为监管重要手段之一，成为很多区块链研发厂商和应用企业的关注热点。本文就大家关心的区块链合规性安全测评谈谈我们做的一点探索和实践。

一、区块链技术测评

区块链技术测评一般分为功能测试、性能测试和安全测评。

1、功能测试

功能测试是对底层区块链系统支持的基础功能的测试，目的是衡量底层区块链系统的能力范围。

区块链功能测试主要依据GB/T 25000.10-2016《系统与软件质量要求和评价（SQuaRE）第10部分：系统与软件质量模型》、GB/T 25000.51-2016《系统与软件质量要求和评价（SQuaRE）第51部分：就绪可用软件产品（RUSP）的质量要求和测试细则》等标准，验证被测软件是否满足相关测试标准要求。

区块链功能测试具体包括组网方式和通信、数据存储和传输、加密模块可用性、共识功能和容错、智能合约功能、系统管理稳定性、链稳定性、隐私保护、互操作能力、账户和交易类型、私钥管理方案、审计管理等模块。

2、性能测试

性能测试是为描述测试对象与性能相关的特征并对其进行评价而实施和执行的一类测试，大多在项目验收测评中，用来验证既定的技术指标是否完成。

区块链性能测试具体包括高并发压力测试场景、尖峰冲击测试场景、长时间稳定运行测试场景、查询测试场景等模块。

3、安全测评

区块链安全测评主要是对账户数据、密码学机制、共识机制、智能合约等进行安全测试和评价。

区块链安全测评的主要依据是《DB31/T 1331-2021区块链技术安全通用要求》。也可根据实际测试需求参考《JR/T 0193-2020区块链技术金融应用评估规则》、《JR/T 0184—2020金融分布式账本技术安全规范》等标准。

区块链安全测评具体包括存储、网络、计算、共识机制、密码学机制、时序机制、个人信息保护、组网机制、智能合约、服务与访问等内容。

二、区块链合规性安全测评

区块链合规性安全测评一般包括“区块链信息服务安全评估”、 “网络安全等级保护测评”和“专项资金项目验收测评”三类。

1、区块链信息服务安全评估

区块链信息服务安全评估主要依据国家互联网信息办公室2019年1月10日发布的《区块链信息服务管理规定》（以下简称“《规定》”）和参考区块链国家标准《区块链信息服务安全规范（征求意见稿）》进行。

《规定》旨在明确区块链信息服务提供者的信息安全管理责任，规范和促进区块链技术及相关服务的健康发展，规避区块链信息服务安全风险，为区块链信息服务的提供、使用、管理等提供有效的法律依据。《规定》第九条指出：区块链信息服务提供者开发上线新产品、新应用、新功能的，应当按照有关规定报国家和省、自治区、直辖市互联网信息办公室进行安全评估。

《区块链信息服务安全规范》是由中国科学院信息工程研究所牵头，浙江大学、中国电子技术标准化研究院、上海市信息安全测评认证中心等单位共同参与编写的一项建设和评估区块链信息服务安全能力的国家标准。《区块链信息服务安全规范》规定了联盟链和私有链的区块链信息服务提供者应满足的安全要求，包括安全技术要求和安全保障要求以及相应的测试评估方法，适用于指导区块链信息服务安全评估和区块链信息服务安全建设。标准提出的安全技术要求、保障要求框架如下：

图1 区块链信息服务安全要求模型

2、网络安全等级保护测评

网络安全等级保护测评的主要依据包括《GB/T 22239-2019网络安全等级保护基本要求》、《GB/T 28448-2019网络安全等级保护测评要求》。

区块链作为一种新兴信息技术，构建的应用系统同样属于等级保护对象，需要按照规定开展等级保护测评。等级保护安全测评通用要求适用于评估区块链的基础设施部分，但目前并没有提出区块链特有的安全要求。因此，区块链安全测评扩展要求还有待进一步探索和研究。

3、专项资金项目验收测评

根据市经信委有关规定，信息化专项资金项目在项目验收时需出具安全测评报告。区块链应用项目的验收测评将依据上海市最新发布的区块链地方标准《DB31/T 1331-2021 区块链技术安全通用要求》开展。

三、区块链安全测评探索与实践

1、标准编制

上海测评中心积极参与区块链标准编制工作。由上海测评中心牵头，苏州同济区块链研究院有限公司、上海七印信息科技有限公司、上海墨珩网络科技有限公司、电信科学技术第一研究所等单位参加编写的区块链地方标准《DB31/T 1331-2021 区块链技术安全通用要求》已于2021年12月正式发布，今年3月1日起正式实施。上海测评中心参与编写的区块链国标《区块链信息服务安全规范》正处于征求意见阶段。

同时，测评中心还参与编写了国家人力资源和社会保障部组织，同济大学牵头编写的区块链工程技术人员初级和中级教材，负责编制“测试区块链系统”章节内容。

2、项目实践

近年来，上海测评中心依据相关技术标准进行了大量的区块链安全测评实践，包括等级保护测评、信息服务安全评估、项目安全测评等。在测评实践中，发现的主要安全问题如下：

表1 区块链主要是安全问题

序号

测评项

问题描述

共识算法

共识算法采用Kafka或Raft共识，不支持拜占庭容错，不支持容忍节点恶意行为。

上链数据

上链敏感信息未进行加密处理，通过查询接口或区块链浏览器可访问链上所有数据。

密码算法

密码算法中使用的随机数不符合GB/T 32915-2016对随机性的要求。

节点防护

对于联盟链，未能对节点服务器所在区域配置安全防护措施。

通信传输

节点间通信、区块链与上层应用之间通信时，未建立安全的信息传输通道。

共识算法

系统部署节点数量较少，有时甚至没有达到共识算法要求的容错数量。

智能合约

未对智能合约的运行进行监测，无法及时发现、处置智能合约运行过程中出现的问题。

服务与访问

上层应用存在未授权、越权等访问控制缺陷，导致业务错乱、数据泄露。

智能合约

智能合约编码不规范，当智能合约出现错误时，不提供智能合约冻结功能。

智能合约

智能合约的运行环境没有与外部隔离，存在外部攻击的风险。

3、工具应用

测评中心在组织编制《DB31/T 1331-2021 区块链技术安全通用要求》时，已考虑与等级保护测评的衔接需求。DB31/T 1331中的“基础设施层”安全与等级保护的安全物理环境、安全通信网络、安全区域边界、安全计算环境、安全管理中心等相关要求保持一致，“协议层安全”、“扩展层安全”则更多体现区块链特有的安全保护要求。

测评中心依据DB31/T 1331相关安全要求，正在组织编写区块链测评扩展要求，相关成果将应用于网络安全等级保护测评工具——测评能手。届时，使用“测评能手”软件的测评机构就能准确、规范、高效地开展区块链安全测评，发现区块链安全风险，并提出对应的整改建议

Fabric上链流程

看看一笔交易的上链过程：

1. 应用提出交易，首先从客户端发起一笔交易提交到3个Endorsing Peer，该笔交易的背书政策P（E0,E1,E2必须签名），客户端应用程序为智能合约提交一个交易。它必须提交给所需的对等点{E0,E1,E2}

2. 背书节点执行提议，将签名数据，传回给客户端。E0、E1、E2将分别执行提出事务。这些执行都不会更新至账本，每次执行都将获一组读和写数据，称为读写集，交易可以签名与加密。

3. 应用接受回复，读写集将异步返回给应用程序，读写集由每个背书节点签名，并且每个都记录了版本号(这些信息将在后面的共识过程中进行核对)。

4，交易排序，Ordering Node对交易进行排序，应用程序将背书节点的响应作为交易提交给排序节点，排序与应用程序的提交并行发生在fabric上。

5. Orderer交付给记账节点，order service将所有交易打包到区块中，然后分发给提记账节点，记账节点可以交付给同层中的其他记账节点。目前支持的排序算法:Solo(单节点，开发)，Kafka(崩溃容错)，RAFT。

6. 记账节点验证交易，每个记账节点会根据背书政策进行验证。还要检查读写集对于当前世界状态是否仍然有效。验证有效的交易，将适用于世界状态（world state）并保留在区块链账本上，无效的交易也保留在区块链账上，但不更新世界状态。

7. 记账节点通知应用程序，当交易成功或失败时，以及当区块被添加到分类账时，应用程序将收到连接的记账节点的通知(事件触发器)。

当下大数据发展的 8 个要点

作者 | 章剑锋

笔者从 2008 年开始工作到现在也有 11 个年头了，一路走来都在和数据打交道，做过大数据底层框架内核的开发（Hadoop，Pig，Tez，Spark，Livy），也做过上层大数据应用开发（写 MapReduce Job 做 ETL ，用 Hive 做 Ad hocquery，用 Tableau 做数据可视化，用 R 做数据分析）。今天我想借此机会和大家聊聊我所理解的大数据现状和未来。

首先让我们来聊聊什么是大数据。大数据这个概念已经出来很多年了（超过10年），但一直没有一个准确的定义（也许也并不需要）。数据工程师（DataEngineer）对大数据的理解会更多从技术和系统的角度去理解，而数据分析人员（Data Analyst）对大数据理解会从产品的角度去理解，所以数据工程师（Data Engineer) 和数据分析人员（Data Analyst）所理解的大数据肯定是有差异的。我所理解的大数据是这样的，大数据不是单一的一种技术或者产品，它是所有与数据相关的综合学科。看大数据我会从 2 个维度来看，一个是数据流的维度（下图的水平轴），另外一个是技术栈的维度（下图的纵轴）。

其实我一直不太喜欢张口闭口讲“大数据”，我更喜欢说“数据”。因为大数据的本质在于“数据”，而不是“大”。由于媒体一直重点宣扬大数据的“大”，所以有时候我们往往会忽然大数据的本质在“数据”，而不是“大”，“大”只是你看到的表相，本质还是数据自身。

在我们讲清楚大数据的含义之后，我们来聊聊大数据目前到底处在一个什么样的位置。从历史发展的角度来看，每一项新技术都会经历下面这样一个技术成熟度曲线。

当一项新技术刚出来的时候人们会非常乐观，常常以为这项技术会给人类带来巨大的变革，对此持有过高的期望，所以这项技术一开始会以非常快的速度受到大家追捧，然后到达一个顶峰，之后人们开始认识到这项新技术并没有当初预想的那么具有革命性，然后会过于悲观，之后就会经历泡沫阶段。等沉寂一定阶段之后，人们开始回归理性，正视这项技术的价值，然后开始正确的应用这项技术，从此这项技术开始走向稳步向前发展的道路。（题外话，笔者在看这幅图的时候也联想到了一个男人对婚姻看法的曲线图，大家自己脑补）。

1、从大数据的历史来看，大数据已经经历了 2 个重要阶段

两个重要阶段是指过高期望的峰值和泡沫化的底谷期。现在正处于稳步向前发展的阶段。我们可以从 googletrend 上 big data 的曲线就能印证。大数据大约从 2009 年开始走向人们的视野，在 2015 年左右走向了顶峰，然后慢慢走向下降通道（当然这张曲线并不会和上面这张技术成熟度曲线完全拟合，比如技术曲线处在下降通道有可能会使讨论这项技术的搜索量增加）。

接下来我想讲一下我对大数据领域未来趋势的几个判断。

2、数据规模会继续扩大，大数据将继续发扬光

前面已经提到过，大数据已经度过了过高期望的峰值和泡沫化的底谷期，现在正在稳步向前发展。做这样判断主要有以下 2 个原因：

上游数据规模会继续增长，特别是由于 IOT 技术的发展和成熟，以及未来 5G 技术的铺开。在可预测的未来，数据规模仍将继续快速增长，这是能够带动大数据持续稳定向前发展的基本动力。下游数据产业还有很多发展的空间，还有很多数据的价值我们没有挖掘出来。

虽然现在人工智能，区块链抢去了大数据的风口位置，也许大数据成不了未来的主角，但大数据也绝对不是跑龙套的，大数据仍将扮演一个重要而基础的角色。可以这么说，只要有数据在，大数据就永远不会过时。我想在大部分人的有生之年，我们都会见证大数据的持续向上发展。

3、数据的实时性需求将更加突出

之前大数据遇到的最大挑战在于数据规模大（所以大家会称之为“大数据”），经过工业界多年的努力和实践，规模大这个问题基本已经解决了。接下来几年，更大的挑战在于速度，也就是实时性。而大数据的实时性并不是指简单的传输数据或者处理数据的实时性，而是从端到端的实时，任何一个步骤速度慢了，就影响整个大数据系统的实时性。所以大数据的实时性，包括以下几个方面：

快速获取和传输数据快速计算处理数据实时可视化数据在线机器学习，实时更新机器学习模型

目前以 Kafka，Flink 为代表的流处理计算引擎已经为实时计算提供了坚实的底层技术支持，相信未来在实时可视化数据以及在线机器学习方面会有更多优秀的产品涌现出来。当大数据的实时性增强之后，在数据消费端会产生更多有价值的数据，从而形成一个更高效的数据闭环，促进整个数据流的良性发展。

4、大数据基础设施往云上迁移势不可挡

目前IT基础设施往云上迁移不再是一个大家还需要争论的问题，这是大势所趋。当然我这边说的云并不单单指公有云，也包括私有云，混合云。因为由于每个企业的业务属性不同，对数据安全性的要求不同，不可能把所有的大数据设施都部署在公有云上，但向云上迁移这是一个未来注定的选择。目前各大云厂商都提供了各种各样的大数据产品以满足各种用户需求，包括平台型（PAAS) 的 EMR ，服务型 (SAAS) 的数据可视化产品等等。大数据基础设施的云化对大数据技术和产品产生也有相应的影响。大数据领域的框架和产品将更加 Cloud Native 。

计算和存储的分离。我们知道每个公有云都有自己对应的分布式存储，比如 AWS 的 S3 。 S3 在一些场合可以替换我们所熟知的 HDFS ，而且成本更低。而 S3 的物理存储并不是在 EC2 上面，对 EC2 来说， S3 是 remote storage 。所以如果你要是 AWS 上面做大数据开发和应用，而且你的数据是在 S3 上，那么你就自然而然用到了计算和存储的分离。拥抱容器，与 Kubernate 的整合大势所趋，我们知道在云环境中 Kuberneate 基本上已经是容器资源调度的标准。更具有弹性（Elastic）。与云上其他产品和服务整合更加紧密。

5、大数据产品全链路化

全链路化是指提供端到端的全链路解决方案，而不是简单的堆积一些大数据产品组件。以 Hadoop 为代表的大数据产品一直被人诟病的主要问题就是用户使用门槛过高，二次开发成本太高。全链路化就是为了解决这一问题，用户需要的并不是 Hadoop，Spark，Flink 等这些技术，而是要以这些技术为基础的能解决业务问题的产品。 Cloudera 的从 Edge 到 AI 是我比较认同的方案。大数据的价值并不是数据本身，而是数据背后所隐藏的对业务有影响的信息和知识。下面是一张摘自 wikipedia 的经典数据金字塔的图。

大数据技术就是对最原始的数据进行不断处理加工提炼，金字塔每上去一层，对应的数据量会越小，同时对业务的影响价值会更大更快。而要从数据（Data) 最终提炼出智慧（Wisdom），数据要经过一条很长的数据流链路，没有一套完整的系统保证整条链路的高效运转是很难保证最终从数据中提炼出来有价值的东西的，所以大数据未来产品全链路化是另外一个大的趋势。

6、大数据技术往下游数据消费和应用端转移

上面讲到了大数据的全链路发展趋势，那么这条长长的数据链路目前的状况是如何，未来又会有什么样的趋势呢？

我的判断是未来大数据技术的创新和发力会更多的转移到下游数据消费和应用端。之前十多年大数据的发展主要集中在底层的框架，比如最开始引领大数据风潮的 Hadoop ，后来的计算引擎佼佼者 Spark，Flink 以及消息中间件 Kafka ，资源调度器 Kubernetes 等等，每个细分领域都涌现出了一系列优秀的产品。总的来说，在底层技术框架这块，大数据领域已经基本打好了基础，接下来要做的是如何利用这些技术为企业提供最佳用户体验的产品，以解决用户的实际业务问题，或者说未来大数据的侧重点将从底层走向上层。之前的大数据创新更偏向于 IAAS 和 PAAS ，未来你将看到更多 SAAS 类型的大数据产品和创新。从近期一些国外厂商的收购案例，我们可以略微看出一些端倪。1、2019 年 6 月 7 日，谷歌宣布以 26 亿美元收购了数据分析公司 Looker，并将该公司并入 Google Cloud。2、2019 年 6 月 10 日，Salesforce 宣布以 157 亿美元的全股票交易收购 Tableau ，旨在夯实在数据可视化以及帮助企业解读所使用和所积累的海量数据的其他工具方面的工作。3、2019 年 9 月初，Cloudera 宣布收购 Arcadia Data 。 Arcadia Data 是一家云原生 AI 驱动的商业智能实时分析厂商。面对最终用户的大数据产品将是未来大数据竞争的重点，我相信会未来大数据领域的创新也将来源于此，未来 5 年内大概率至少还会再出一个类似 Looker 这样的公司，但是很难再出一个类似 Spark 的计算引擎。

7、底层技术的集中化和上层应用的全面开花

学习过大数据的人都会感叹大数据领域的东西真是多，特别是底层技术，感觉学都学不来。经过多年的厮杀和竞争，很多优秀的产品已经脱颖而出，也有很多产品慢慢走向消亡。比如批处理领域的 Spark 引擎基本上已经成为批处理领域的佼佼者，传统的 MapReduce 除了一些旧有的系统，基本不太可能会开发新的 MapReduce 应用。 Flink 也基本上成为低延迟流处理领域的不二选择，原有的 Storm 系统也开始慢慢退出历史舞台。同样 Kafka 也在消息中间件领域基本上占据了垄断地位。未来的底层大数据生态圈中将不再有那么多的新的技术和框架，每个细分领域都将优胜劣汰，走向成熟，更加集中化。未来更大的创新将更多来来自上层应用或者全链路的整合方面。在大数据的上层应用方面未来将会迎来有更多的创新和发展，比如基于大数据上的BI产品， AI 产品等等，某个垂直领域的大数据应用等等，我相信未来我们会看到更多这方面的创新和发展。

8、开源闭源并驾齐驱

大数据领域并不是只有 Hadoop，Spark，Flink 等这类大家耳熟能详的开源产品，还有很多优秀的闭源产品，比如 AWS 上的 Redshift ，阿里的 MaxCompute 等等。这些产品虽然没有开源产品那么受开发者欢迎，但是他们对于很多非互联网企业来说是非常受欢迎的。因为对于一个企业来说，采用哪种大数据产品有很多因素需要考虑，否开源并不是唯一标准。产品是否稳定，是否有商业公司支持，是否足够安全，是否能和现有系统整合等等往往是某些企业更需要考虑的东西，而闭源产品往往在这类企业级产品特性上具有优势。

最近几年开源产品受公有云的影响非常大，公有云可以无偿享受开源的成果，抢走了开源产品背后的商业公司很多市场份额，所以最近很多开源产品背后的商业公司开始改变策略，有些甚至修改了 Licence 。不过我觉得公有云厂商不会杀死那些开源产品背后的商业公司，否则就是杀鸡取卵，杀死开源产品背后的商业公司，其实就是杀死开源产品的最大技术创新者，也就是杀死开源产品本身。我相信开源界和公有云厂商最终会取得一个平衡，开源仍然会是一个主流，仍然会是创新的主力，一些优秀的闭源产品同样也会占据一定的市场空间。

最后我想再次总结下本文的几个要点：

1、目前大数据已经度过了最火的峰值期和泡沫化的底谷期，现在正处于稳步向前发展的阶段。2、数据规模会继续扩大，大数据将继续发扬光大3、数据的实时性需求将更加突出4、大数据基础设施往云上迁移势不可挡5、大数据产品全链路化6、大数据技术往下游数据消费和应用端转移7、底层技术的集中化和上层应用的全面开花8、开源闭源并驾齐驱