‘壹’ 各大巨头纷纷布局IPFS分布式存储
近年来，大部分投资者都曾有过一个疑问：“为什么华为、阿里、亚马逊不使用IPFS&Filecoin，IPFS&Filecoin发展前景如何，到底能否取代传统的数据中心”，其实，传统的云存储和分布式存储之间并不是非此即彼的选择题，双方是可以求同存异、共生互补的，同时，由于IPFS&Filecoin分布式存储顺应时代需求，具有足够的创新性和广阔的应用场景，因此，阿里、华为、亚马逊等巨头早已纷纷布局IPFS&Filecoin，接下来，我们就来看看他们是如何将IPFS&Filecoin与自身业务相结合的。
京东智联云无线宝引入IPFS
京东智联云事业部无线宝业务总经理张晓东在杭州IPFS生态与分布式存储产业峰会上，发表了以《基于京东云无线宝智能终端及其价值共享理念，构建IPFS基础设施》为主题的演讲，其中张晓东谈到，京东也好，阿里也好，拼多多也好，其实我们都有很大的电商生态，当其所产生的价值和消费生态结合在一起，就将是未来整个币圈和消费生态结合在一起的很重要的方向。
京东云会成为京东的底层基础设施，把京东的技术体系的积累以云为出口输出给行业或者企业的客户。而路由器将会成为一个家庭的入口，但是路由器加上存储有可能会成为家庭的网络连接和数据管理的终端平台，因此，京东的路由器无线宝就是京东在云存储领域王炸品牌，而无线宝需要使用到IPFS。
路由器市场每年有1亿台，京东则会做出更漂亮、更有特色、能赚钱的无线宝路由器，使路由器不再被放置在家里的角落，而像摆件一样放置在明显的桌上，会赚钱其实是指赚金豆，一个金豆等于一分钱，每一个金豆都可以在京东平台做消费，也就是说，京东通过路由器随着植入，把资源做一个变现。
无线宝有一个技术变现体系，是基于P2P的变现，这就需要结合到IPFS。
无线宝将会通过用户闲散的带宽资源做一些变现，因为这个产品部署在用户的家里面，千家万户完全分散就意味着是分散的、分布式的，未来区块链也好，IPFS也好，完全可以植入到这样一个产品里面。
无线宝有闲置的存储和带宽资源，用户可以把一些有价值的文件、数据分布式缓存在无线宝上面，做一些有价值的产品变现，结合到IPFS技术，总的存储成本是非常低的，但是数据的价值是非常的高，无线宝上结合IPFS，或许还能创造一些新的场景的应用，并实现节点与节点之间的价值的转移。
沧州华为云计算大数据中心引入IPFS
2020年6月13日，沧州云智大数据产业园签约仪式启动，此次仪式就沧州华为云在数据中心IDC业务、云计算及分布式存储等方面达成框架合作协议，共同建设服务器集群基础设施。
沧州华为云计算大数据中心由市政府与华为技术有限公司合作建立，位于沧州市高新技术开发区，总投资超4亿元，数据机房规划3000个可用IT机柜模块，是沧州市打造的大数据产业发展基地。
据沧州政府官网以及相关媒体报道，此次沧州华为云服务器集群将引入IPFS分布式存储技术共同搭建，通过IPFS技术，文件在上传时会瞬间打碎成N个加密碎片，分散存储于不同的服务器中，在下载时再自动合成为完整的源文件，具有高安全性和隐私性更高效、更便宜、数据永久性等四大优势，IPFS分布式存储技术将成为沧州市大数据产业发展基地的新亮点。
亚马逊云布局IPFS存储市场
7月3日，亚马逊云解决方案架构师华东区经理吴鹏程在2020 IPFS生态与分布式存储产业峰会上发表主题演讲《快速构建全球化IPFS及区块链平台》。
首先，吴鹏程对IPFS分布式存储技术给予了认同，由于IPFS具有7X24极高稳定性、全球布局能力、海量存储能力、无限公网宽带和IP、高性能的CPU/GPU，因此IPFS天然地和公有云契合，以打造更快的“高速公路”。
亚马逊云充分看到了IPFS所蕴含的庞大存储市场，因此从硬件、软件、金融层面多方面布局IPFS产业生态链，正如吴鹏程所说：“亚马逊作为服务商，我们可以和造铁路的有很好的合作，比如说挖矿、交易所上面我们都可以有非常紧密的一些合作，挖矿可以提供各种GPU、CPU，还有各种类型的存储，实现低成本，快速使用的场景，交易所场景下5大需求快速因上落地，有很好的架构实现。”
此外，根据IPFS第144期周报，在AWS S3已经可以将文件转移到IPFS上。
阿里云布局IPFS存储市场
8月3日，在“星际漫游指南·逐鹿中原·IPFS技术与应用研讨论坛”上，阿里云高级解决方案架构师西城进行了以《云端分布式存储的发展》为题的演讲。
西城认为，从云的业务角度看来，阿里已经在很多层面做了相当多的技术积累，特别是在计算节点调度和存储节点方面。企业们如果希望云产品能具有特点，就不要把所有精力投入在云端分布式存储和整个管理部署架构上，而应该更多的提高其算力，并做一些可以提升存力的技术开发并进行相应的业务拓展。
BaaS，是阿里云旗下的云平台之上的区块链平台服务，提供区块链系统的部署、运维、治理能力，提供区块链应用运行和管理的能力，它是云上的区块链应用；BaaS也是云计算与区块链是一个完美的结合，能够助力用户在IPFS领域实现落地应用。
功能丰富，涉及到存证、智能合约和BaaS，这几块都是区块链的典型商用模式，全球接入、成本弹性、性能可控、安全防护是区块链云上部署未来所需要关注和努力的方向。
IPFS不仅是分布式存储，更蕴含了庞大的分布式存储的生态，阿里云积极研究和布局IPFS，积极为IPFS生态应用的构建提供一个良好的孵化平台，让区块链和IPFS从业者能够更好的致力于创新和更高效地成长。
巨头加持，分布式存储势不可挡
IPFS是一项被诸多媒体纷纷报道的对标HTTP的新一代互联网技术，而无论是阿里、华为还是亚马逊，巨头之所以成为巨头，就是因为他们有更敏锐的市场嗅觉、更广泛的商业布局、更开放的商业心态。当我们在纠结IPFS到底是否有发展前景的时候，这些巨头们已经在你看不见的地方展开了宏大的布局，或数据存储、或生态应用、或技术研发，同样，这些巨头们也用实际行动告诉我们，分布式存储的未来，势不可。
学着用开放的、积极的心态去拥抱新事物，或许，真的能遇到一个属于你的风口。
‘贰’ 区块链分布式存储：生态大数据的存储新模式
区块链，当之无愧的2019最靓的词，在 科技 领域闪闪发亮，在实体行业星光熠熠。
2019年的1024讲话，让区块链这个词焕然一新，以前它总是和传销和诈骗联系在一起，“区块链”这个词总是蒙上一层灰色。但是如今，区块链则是和实体经济融合紧密相连，成为国家的战略技术， 这个词瞬间闪耀着热情的红色和生意盎然的绿色 。
“产业区块链”在这个时代背景下应运而生， 是继“互联网”后的又一大热门词汇，核心就是区块链必须和实体产业融合，脱虚向实，让区块链技术找到更多业务场景才是正道。
区块链的本质就是一个数据库，而且是采用的分布式存储的方式。作为一名区块链从业者，今天就来讲讲 区块链的分布式存储和生态大数据 结合后，碰撞产生的火花。
当前的存储大多为中心化存储，存储在传统的中心化服务器。如果服务器出现宕机或者故障，或者服务器停止运营，则很多数据就会丢失。
比如我们在微信朋友圈发的图片，在抖音上传的视频等等，都是中心化存储。很多朋友会把东西存储在网上，但是某天打开后，网页呈现404，则表示存储的东西已经不见了。
区块链，作为一个分布式的数据库，则能很好解决这方面的问题。这是由区块链的技术特征决定了的。 区块链上的数字记录，不可篡改、不可伪造，智能合约让大家更高效地协同起来，从而建立可信的数字经济秩序，能够提高数据流转效率，打破数据孤岛，打造全新的存储模式。
生态大数据，其实和我们每天的生活息息相关，比如每天的天气预报，所吃的农产品的溯源数据等等，都是生态大数据的一部分。要来谈这个结合，首先咱们来看看生态大数据存储的特点。
伴随着互联网的发展，当前，生态大数据在存储方面有具有如下特点：
从数据规模来看，生态数据体量很大，数据已经从TB级跃升到了PB级别。
随着各类传感器技术、卫星遥感、雷达和视频感知等技术的发展，数据不仅来源于传统人工监测数据，还包括航空、航天和地面数据，他们一起产生了海量生态环境数据。近10年以来，生态数据以每年数百个TB的数据在增长。
生态环境大数据需要动态新数据和 历史 数据相结合来处理，实时连续观测尤为重要。只有实时处理分析这些动态新数据，并与已有 历史 数据结合起来分析，才能挖掘出有用信息，为解决有关生态环境问题提供科学决策。
比如在当前城市建设中，提倡的生态环境修复、生态模型建设中，需要大量调用生态大数据进行分析、建模和制定方案。但是目前很多 历史 数据因为存储不当而消失，造成了数据的价值的流失。
既然生态大数据有这些特点，那么它有哪些存储需求呢？
当前，生态大数据面临严重安全隐患，强安全的存储对于生态大数据而言势在必行。
大数据的安全主要包括大数据自身安全和大数据技术安全，比如在大数据的数据存储中，由于黑客外部网络攻击和人为操作不当造成数据信息泄露。外部攻击包括对静态数据和动态数据的数据传输攻击、数据内容攻击、数据管理和网络物理攻击等。
例如，很多野外生态环境监测的海量数据需要网络传输，这就加大了网络攻击的风险。如果涉及到军用的一些生态环境数据，如果被黑客获得这些数据，就可能推测到我国军方的一些信息，或者获取敏感的生态环境数据，后果不堪设想。
生态大数据的商业化应用需要整合集成政府、企业、科研院所等 社会 多来源的数据。只有不同类型的生态环境大数据相互连接、碰撞和共享，才能释放生态环境大数据的价值。
以当前的智慧城市建设为例，很多城市都在全方位、多维度建立知识产权、种质资源、农资、农产品、病虫害疫情等农业信息大数据中心，为农业产供销提供全程信息服务。建设此类大数据中心，离不开各部门生态大数据的共享。
但是，生态大数据共享面临着巨大挑战。首先，我国生态环境大数据包括气象、水利、生态、国土、农业、林业、交通、 社会 经济等其他部门的大数据，涉及多领域多部门和多源数据。虽然目前这些部门已经建立了自己的数据平台，但这些平台之间互不连通，只是一个个的数据孤岛。
其次，相关部门因为无法追踪数据的轨迹，担心数据的利益归属问题，便无法实现数据的共享。因此，要想挖掘隐藏在生态大数据背后的潜在价值，实现安全的数据共享是关键，也是生态大数据产生价值的前提和基础。
生态大数据来之不易，是研究院所、企业、个人等 社会 来源的集体智慧。
其中，很多生态大数据涉及到了知识产权的保护。但是目前的中心化存储无法保证知识产权的保护，无法对数据的使用进行溯源管理，容易造成知识产权的侵犯和隐私数据的泄露。
这些就是生态大数据在存储方面的需求。在当前产业区块链快速发展的今天，区块链的分布式存储是可以为生态大数据存储提供全新的存储方式的。 这个核心前提就是区块链的分布式存储、不可篡改和数据追踪特性 。
把区块链作为底层技术，搭建此类平台，专门存储生态大数据，可以设置节点管理、存储管理、用户管理、许可管理、业务通道管理等。针对上层业务应用提供高可用和动态扩展的区块链网络底层服务的实现。在这个平台的应用层，可以搭建API接口，让整个平台的使用灵活可扩展。区块链分布式存储有如下特点：
利用区块链的分布式存储，能够实现真正的生态大数据安全存储。
首先，数据永不丢失。这点对于生态大数据的 历史 数据特别友好，方便新老数据的调用和对比。
其次，数据不易被泄露或者攻击。因为数据采取的是分布式存储，如果遭遇攻击，也只能得到存储在部分节点里的数据碎片，无法完全获得完整的数据信息或者数据段。
区块链能够实现生态数据的存储即确权，这样就能够避免知识产权被侵害，实现安全共享。毕竟生态大数据的获取，是需要生态工作者常年在野外驻守，提取数据的。
生态大数据来之不易，是很多生态工作者的工作心血和结晶，需要得到产权的保护，让数据体现出应用价值和商业价值，保护生态工作者的工作动力，让他们能够深入一线，采集出更多优质的大数据。
同时，利用区块链的数据安全共享机制，也能够打破气象、林业、湿地等部门的数据壁垒，构建安全可靠的数据共享机制，让数据流转更具价值。
现在有部分生态工作者，为了牟取私利，会将生态数据篡改。如果利用区块链技术，则没有那么容易了。
利用加密技术，把存储的数据放在分布式存储平台进行加密处理。如果生态大数据发生变更，平台就可以记录其不同版本，便于事后追溯和核查。
这个保护机制主要是利用了数据的不可篡改，满足在使用生态大数据的各类业务过程中对数据的安全性的要求。
区块链能够对数据提供安全监控，记录应用系统的操作日志、数据库的操作日志数据，并加密存储在系统上，提供日志预警功能，对于异常情况通过区块链浏览器展示出来，便于及时发现违规的操作和提供证据。
以上就是区块链的分布式存储能够在生态大数据方面所起的作用。未来，肯定会出现很多针对生态大数据存储的平台诞生。
生态大数据是智慧城市建设的重要基础资料 ，引用区块链技术，打造相关的生态大数据存储和管理平台，能够保证生态大数据的安全存储和有效共享，为智慧城市建设添砖加瓦，推动产业区块链的发展。
作者：Justina，微信公众号：妙译生花，从事于区块链运营，擅长内容运营、海外媒体运营。
题图来自Unsplash, 基于CC0协议。
‘叁’ 如何实现企业数据 大数据平台 分布式存放
Hadoop在可伸缩性、健壮性、计算性能和成本上具有无可替代的优势，事实上已成为当前互联网企业主流的大数据分析平台。本文主要介绍一种基于Hadoop平台的多维分析和数据挖掘平台架构。作为一家互联网数据分析公司，我们在海量数据的分析领域那真是被“逼上梁山”。多年来在严苛的业务需求和数据压力下，我们几乎尝试了所有可能的大数据分析方法，最终落地于Hadoop平台之上。
1. 大数据分析大分类
Hadoop平台对业务的针对性较强，为了让你明确它是否符合你的业务，现粗略地从几个角度将大数据分析的业务需求分类，针对不同的具体需求，应采用不同的数据分析架构。
按照数据分析的实时性，分为实时数据分析和离线数据分析两种。
实时数据分析一般用于金融、移动和互联网B2C等产品，往往要求在数秒内返回上亿行数据的分析，从而达到不影响用户体验的目的。要满足这样的需求，可以采用精心设计的传统关系型数据库组成并行处理集群，或者采用一些内存计算平台，或者采用HDD的架构，这些无疑都需要比较高的软硬件成本。目前比较新的海量数据实时分析工具有EMC的Greenplum、SAP的HANA等。
对于大多数反馈时间要求不是那么严苛的应用，比如离线统计分析、机器学习、搜索引擎的反向索引计算、推荐引擎的计算等，应采用离线分析的方式，通过数据采集工具将日志数据导入专用的分析平台。但面对海量数据，传统的ETL工具往往彻底失效，主要原因是数据格式转换的开销太大，在性能上无法满足海量数据的采集需求。互联网企业的海量数据采集工具，有Facebook开源的Scribe、LinkedIn开源的Kafka、淘宝开源的Timetunnel、Hadoop的Chukwa等，均可以满足每秒数百MB的日志数据采集和传输需求，并将这些数据上载到Hadoop中央系统上。
按照大数据的数据量，分为内存级别、BI级别、海量级别三种。
这里的内存级别指的是数据量不超过集群的内存最大值。不要小看今天内存的容量，Facebook缓存在内存的Memcached中的数据高达320TB，而目前的PC服务器，内存也可以超过百GB。因此可以采用一些内存数据库，将热点数据常驻内存之中，从而取得非常快速的分析能力，非常适合实时分析业务。图1是一种实际可行的MongoDB分析架构。
图1 用于实时分析的MongoDB架构
MongoDB大集群目前存在一些稳定性问题，会发生周期性的写堵塞和主从同步失效，但仍不失为一种潜力十足的可以用于高速数据分析的NoSQL。
此外，目前大多数服务厂商都已经推出了带4GB以上SSD的解决方案，利用内存+SSD，也可以轻易达到内存分析的性能。随着SSD的发展，内存数据分析必然能得到更加广泛的应用。
BI级别指的是那些对于内存来说太大的数据量，但一般可以将其放入传统的BI产品和专门设计的BI数据库之中进行分析。目前主流的BI产品都有支持TB级以上的数据分析方案。种类繁多，就不具体列举了。
海量级别指的是对于数据库和BI产品已经完全失效或者成本过高的数据量。海量数据级别的优秀企业级产品也有很多，但基于软硬件的成本原因，目前大多数互联网企业采用Hadoop的HDFS分布式文件系统来存储数据，并使用MapRece进行分析。本文稍后将主要介绍Hadoop上基于MapRece的一个多维数据分析平台。
数据分析的算法复杂度
根据不同的业务需求，数据分析的算法也差异巨大，而数据分析的算法复杂度和架构是紧密关联的。举个例子，Redis是一个性能非常高的内存Key-Value NoSQL，它支持List和Set、SortedSet等简单集合，如果你的数据分析需求简单地通过排序，链表就可以解决，同时总的数据量不大于内存（准确地说是内存加上虚拟内存再除以2），那么无疑使用Redis会达到非常惊人的分析性能。
还有很多易并行问题（Embarrassingly Parallel），计算可以分解成完全独立的部分，或者很简单地就能改造出分布式算法，比如大规模脸部识别、图形渲染等，这样的问题自然是使用并行处理集群比较适合。
而大多数统计分析，机器学习问题可以用MapRece算法改写。MapRece目前最擅长的计算领域有流量统计、推荐引擎、趋势分析、用户行为分析、数据挖掘分类器、分布式索引等。
2. 面对大数据OLAP大一些问题
OLAP分析需要进行大量的数据分组和表间关联，而这些显然不是NoSQL和传统数据库的强项，往往必须使用特定的针对BI优化的数据库。比如绝大多数针对BI优化的数据库采用了列存储或混合存储、压缩、延迟加载、对存储数据块的预统计、分片索引等技术。
Hadoop平台上的OLAP分析，同样存在这个问题，Facebook针对Hive开发的RCFile数据格式，就是采用了上述的一些优化技术，从而达到了较好的数据分析性能。如图2所示。
然而，对于Hadoop平台来说，单单通过使用Hive模仿出SQL，对于数据分析来说远远不够，首先Hive虽然将HiveQL翻译MapRece的时候进行了优化，但依然效率低下。多维分析时依然要做事实表和维度表的关联，维度一多性能必然大幅下降。其次，RCFile的行列混合存储模式，事实上限制死了数据格式，也就是说数据格式是针对特定分析预先设计好的，一旦分析的业务模型有所改动，海量数据转换格式的代价是极其巨大的。最后，HiveQL对OLAP业务分析人员依然是非常不友善的，维度和度量才是直接针对业务人员的分析语言。
而且目前OLAP存在的最大问题是：业务灵活多变，必然导致业务模型随之经常发生变化，而业务维度和度量一旦发生变化，技术人员需要把整个Cube（多维立方体）重新定义并重新生成，业务人员只能在此Cube上进行多维分析，这样就限制了业务人员快速改变问题分析的角度，从而使所谓的BI系统成为死板的日常报表系统。
使用Hadoop进行多维分析，首先能解决上述维度难以改变的问题，利用Hadoop中数据非结构化的特征，采集来的数据本身就是包含大量冗余信息的。同时也可以将大量冗余的维度信息整合到事实表中，这样可以在冗余维度下灵活地改变问题分析的角度。其次利用Hadoop MapRece强大的并行化处理能力，无论OLAP分析中的维度增加多少，开销并不显着增长。换言之，Hadoop可以支持一个巨大无比的Cube，包含了无数你想到或者想不到的维度，而且每次多维分析，都可以支持成千上百个维度，并不会显着影响分析的性能。
而且目前OLAP存在的最大问题是：业务灵活多变，必然导致业务模型随之经常发生变化，而业务维度和度量一旦发生变化，技术人员需要把整个Cube（多维立方体）重新定义并重新生成，业务人员只能在此Cube上进行多维分析，这样就限制了业务人员快速改变问题分析的角度，从而使所谓的BI系统成为死板的日常报表系统。
3. 一种Hadoop多维分析平台的架构
整个架构由四大部分组成：数据采集模块、数据冗余模块、维度定义模块、并行分 析模块。
数据采集模块采用了Cloudera的Flume，将海量的小日志文件进行高速传输和合并，并能够确保数据的传输安全性。单个collector宕机之后，数据也不会丢失，并能将agent数据自动转移到其他的colllecter处理，不会影响整个采集系统的运行。如图5所示。
数据冗余模块不是必须的，但如果日志数据中没有足够的维度信息，或者需要比较频繁地增加维度，则需要定义数据冗余模块。通过冗余维度定义器定义需要冗余的维度信息和来源（数据库、文件、内存等），并指定扩展方式，将信息写入数据日志中。在海量数据下，数据冗余模块往往成为整个系统的瓶颈，建议使用一些比较快的内存NoSQL来冗余原始数据，并采用尽可能多的节点进行并行冗余；或者也完全可以在Hadoop中执行批量Map，进行数据格式的转化。
维度定义模块是面向业务用户的前端模块，用户通过可视化的定义器从数据日志中定义维度和度量，并能自动生成一种多维分析语言，同时可以使用可视化的分析器通过GUI执行刚刚定义好的多维分析命令。
并行分析模块接受用户提交的多维分析命令，并将通过核心模块将该命令解析为Map-Rece，提交给Hadoop集群之后，生成报表供报表中心展示。
核心模块是将多维分析语言转化为MapRece的解析器，读取用户定义的维度和度量，将用户的多维分析命令翻译成MapRece程序。核心模块的具体逻辑如图6所示。
图6中根据JobConf参数进行Map和Rece类的拼装并不复杂，难点是很多实际问题很难通过一个MapRece Job解决，必须通过多个MapRece Job组成工作流（WorkFlow），这里是最需要根据业务进行定制的部分。图7是一个简单的MapRece工作流的例子。
MapRece的输出一般是统计分析的结果，数据量相较于输入的海量数据会小很多，这样就可以导入传统的数据报表产品中进行展现。