当下，数据在全球经济运转中的价值日益凸显，与传统的土地、劳动力、资本、技术等并列，成为重要生产要素。
数据最终的价值来源于治理。只有经过采集、清洗、分析和处理后的数据，才能在流通中更顺畅地使用，其价值才能得到更充分地挖掘。同时，随着区块链技术的蓬勃发展，区块链渐趋规模化应用，链上数据总量呈指数级增长，其中蕴藏的巨大价值，也需要通过高效、规范的数据治理，才能得到充分彰显。
在区块链数据治理方面，微众银行区块链基于多年技术研究和应用实践经验，研发了一套数据治理通用组件（WeBankBlockchain-Data），多维提升开发、运营、运维效率，实现数据从要素到资源的转化。
目前，该套组件由数据仓库组件(Data-Stash)、数据导出组件(Data-Export)、数据对账组件(Data-Reconcile)三个相互独立、可插拔、可灵活组装的子组件构成，所有代码和文档均于2020年12月正式对外开源。详情可参考开源公告。
三个子组件面向不同角色解决相应的数据治理需求，业务、运营、开发、运维等不同角色，如何快速上手使用？我们将通过系列文章，抽丝剥茧解析每一个子组件的关键特性和使用方式。本文介绍数据仓库组件Data-Stash，欢迎大家积极体验并将使用诉求或优化建议反馈给我们。
认识Data-Stash
随着区块链业务不断运行，累积的海量链上数据会对区块链节点乃至网络的运维带来挑战。
从磁盘容量来看，由于节点容量有限，持续膨胀的数据要求磁盘不断扩容。
从交易性能来看，过多的数据会带来交易执行性能的衰减。
从节点同步来看，大量的数据同步会引出网络带宽被侵占、同步速度缓慢等问题。
数据仓库组件Data-Stash为上述难题提供解决方案，通过为节点在外部生成全量数据备份，实现海量数据高效治理。
具体而言，节点通过数据裁剪实现冷热数据分离，链上仅保留热数据，冷数据则通过全量备份获取，以此节省节点空间。冷热数据分离后，交易的验证、执行仅依赖于链上热数据，从而提升交易执行性能。
对于新节点加入网络后数据的同步，只需要从全量备份拉取数据，实现数据高效同步，其间不占用区块链网络带宽，免去冗长的同步过程，减少节点数据同步的等待时间，使得节点可以快速加入区块链网络并正常工作。
目前该组件支持区块链底层平台FISCO BCOS v2.7.1及以上版本。
Data-Stash关键特性一览
作为一个数据治理工具，Data-Stash可为区块链底层平台提供节点数据扩容、备份、裁剪和高效同步的能力，具有断点续传、可信验证、易于使用等优点。用户可基于Binlog协议同步区块链底层节点全量数据，进而实现全量数据备份、冷热数据分离、节点快速同步，适合节点有海量数据等运维场景。
1）节点账本全量备份
Data-Stash通过解析节点生成的Binlog，可以在节点外生成链上数据的全量备份。随后，节点运维人员可对链上数据进行裁剪，达到节省空间、提升性能的效果。对于裁剪后缺失的冷数据，节点会通过amdb从全量备份读取。节点还可以通过fisco-sync工具，将数据重新导回到节点，恢复完整的节点，而不必从区块链网络拉取数据。
2）多维度账本校验
数据仓库组件在读取某节点日志后，会进行多重校验，以防出现节点账本信息被损害、被篡改、共识系统异常等情况。
校验是多维度的，整体可分为对比校验和区块链校验。对比校验是指Data-Stash会拉取多个节点的账本进行对比，确认账本内容一致后才可以入库；区块链校验是指验证区块链本身，包括哈希检查、签名检查、状态根检查等。
3）备份数据可信存储
Data-Stash每处理完一个区块，都会为此时的全量备份生成一个哈希值作为检查点。该检查点会为存储增信，适用于全量备份库之间的校验等场景。
例如，不同机构生成了各自的全量备份，现在想比对各自备份数据是否一致，各机构只需要提取出最新区块高度的检查点进行比对，如一致，则表示备份内容完全相同。
4）断点续传
在实际运行中，FISCO BCOS会生成许多Binlog，这些Binlog无论是体积、数目，都具有相当规模，如果每一次运行都重复下载、解析，会造成性能浪费。为此，我们设计了断点续传机制，组件会持续记录解析的进度，每次运行时都会从上一次断点处运行，而不会重新开始。
5）易于使用
Data-Stash以jar包的形式提供服务，用户可通过jar包或bash脚本运行。开发者只需要做最少化配置，默认情况下，只需要配置nginx地址、全量数据库地址，程序即可运行。
此外，Data-Stash还允许用户进行更高级的配置设置，例如修改批插入次数、轮询间隔等。
Data-Stash如何进行数据治理？
Data-Stash是助力海量数据治理的第一环，通过生成节点全量备份，以满足冷热分离、高效同步、监管审计等需求。
1）实现冷热数据分离
随着时间推移，节点会积累越来越多的账本数据，如果节点体积不受控制的增长，最终会将节点服务器侵蚀殆尽，造成不良影响。对此，开发者可以使用数据仓库服务来实现冷热数据分离。
确保节点已经开启Binlog，如果节点未开启Binlog并已在运行，可先停止节点，删除群组数据、开启Binlog后再重启节点，节点即可重新同步并生成Binlog。
准备好一个第三方数据库，启动Data-Stash服务，将节点Binlog持续导入到该数据库中，实现全量备份。
开发者可对链上数据做一定划分，可将节点上不常用数据删除，特别是对于存证这样关联性较弱的业务，保留近期数据即可。
为了让节点运行不受影响，用户需要保证启用amdb，这样缺失的冷数据会自动从数据仓库读取，完成节点瘦身。
启用amdb请参考：
https://fisco-bcos-documentation.readthedocs.io/zh_CN/latest/docs/manual/data_governance.html#amdb-proxy
2）实现节点高效同步
在区块链业务运行时，经常有节点同步或升级的需求。例如，服务器因为某些故障需要被下线回收，或者需要更换磁盘，此时需要对服务器或磁盘数据进行同步，重新运行节点需要从区块链网络里同步数据，若待同步数据很大，例如几十G、几百G，就会使得数据恢复时间冗长，而且还会占满区块链的网络带宽，使得整个系统长时间停滞。
开发者可通过Data-Stash实现节点同步：
开发者需要通过Data-Stash生成全量数据备份。
当需要节点同步时，开发者可以通过FISCO BCOS项目下的fisco sync数据同步工具，将数据仓库导回到节点。这一过程不依赖于任何其他节点，所以同步不会占用区块链的网络资源。
fisco sync数据同步工具参考链接：
https://fisco-bcos-documentation.readthedocs.io/zh_CN/latest/docs/manual/data_governance.html#fisco-sync
3）监管、审计、追溯
对于监管方而言，要求账本数据完整、可查询，但区块链自身的账本数据库不一定满足该需求。例如出于节点瘦身、数据分片等需求，节点上可能仅存储部分账本数据；出于写性能的需要，区块链会选择rocksdb等数据库，但这类数据库在读性能上不具备优势。
此时，监管方可以对某个节点运行数据仓库服务导出完整的全量备份，由于关系型数据库的采用，查询也十分便捷。同时，在全量备份过程中，我们采用的多维度校验机制具有易于验证的优势，可防止节点运维恶意修改账本信息欺骗监管方，更好地满足监管需求。
Data-Stash整体架构
FISCO BCOS节点在共识过程中持续获取新的区块，并更新自己的账本状态，此外还会生成Binlog日志，以记录该区块对应的状态变动，外界可以通过nginx访问到这些Binlog日志。
与此同时，Data-Stash会不断轮询nginx以下载最新的Binlog日志到本地，并进行解析，解析出区块变动信息后会进行校验，防止错误的Binlog被导入。校验通过后，区块变动数据会存储到指定的持久化系统中，这样该系统就成为了节点账本的全量备份。
Data-Stash还会为每一个区块生成对应的检查点，为全量备份增信。本地被处理完的Binlog也会被清理掉。
Data-Stash的整体运行模式如下：
其中，节点服务器需要用户手动配置，配置好后即可调用Data-Stash进行解析。
节点服务器
节点服务器相关的组件包括：
1）FISCO BCOS节点
FISCO BCOS节点的账本按照mysql存储，每新增加一个区块，都会为mysql里添加一些数据，mysql表的变化会被记录到Binlog中，Binlog目录被放在data/groupX/BinaryLogs目录下，x表示群组号：
2）Nginx
FISCO BCOS节点本身并不会暴露Binlog，如果希望外界读取到Binlog，需要借助nginx。通过在nginx中配置端口和Binlog目录的映射，外界就可以通过该端口访问到Binlogs。
认识Binlog：
Binlog记录账本的变化。在FISCO BCOS中，每得到一个新的区块后，该区块都会被存储到账本中，同时Binlog会记录账本的变动，并按区块来进行组织。每个Binlog日志会包含多个区块对应的变化，Binlog会以记录的第一个区块高度作为文件名，例如3.binlog表示该文件中的区块以3作为起始。
下图是Binlog的结构：
数据仓库组件
数据仓库组件由如下几个部分构成：
1）下载服务Fetcher Server
下载服务会持续轮询nginx端口，下载最新Binlog日志到本地目录中。
2）解析服务Binlog Parser
解析服务持续读取Binlog日志，并对Binlog中的区块信息进行解析。
3）校验服务Binlog verifier
校验服务用于保证数据的可信性。校验服务会从其他节点拉取Binlog进行对比，保证内容的一致性，并对数据本身进行校验，例如对于区块哈希校验、区块签名校验、交易根校验等。
4）存储服务Data Storage
存储服务按照Binlog的变动，会将其内容应用到数据库中，该数据库会包含系统表、合约表等，结构上与节点保持一致，数据量上则包含节点运行至今的所有区块链数据。表结构可分为如下几类：
类型 |
表前缀 |
说明 |
系统表 |
_sys_ |
包含区块链信息，例如区块数据(_sys_hash_2_block_)、共识状态(_sys_consensus_)、cns(_sys_cns_)等 |
合约表 |
c_或cp_ |
记录合约信息，包括nonce值、合约代码、代码哈希等 |
用户表 |
_u_ |
调用CRUD合约创建的表 |
5）检查点服务Checkpoint Handler
每一个区块数据的入库存储，都会生成一个检查点数据，该检查点包含了前置所有区块数据的哈希，用于额外对存储进行增信。
即刻使用
上述功能所涉及的最新代码和技术文档已同步更新，欢迎体验和 star 支持。如需咨询技术问题，欢迎关注本公众号，对话框回复【小助手】进技术交流群。
Data-Stash github代码库地址码仓库：
https://github.com/WeBankBlockchain/Data-Stash
Data-Stash gitee代码库地址：
https://gitee.com/WeBankBlockchain/Data-Stash
Data-Stash 技术文档：
https://data-doc.readthedocs.io/zh_CN/latest/docs/WeBankBlockchain-Data-Stash/index.html
首次体验Data-Stash，可参考快速部署文档：
https://data-doc.readthedocs.io/zh_CN/latest/docs/WeBankBlockchain-Data-Stash/quickstart.html
向我们报告问题，欢迎提交issue：
https://github.com/WeBankBlockchain/Data-Stash/issues