项目测评DIA：专注Defi生态领域的预言机系统

下面我对这个项目做个评测，让大家可以对DIA有个全面认识。

创新互联2013年开创至今，是专业互联网技术服务公司，拥有项目成都网站制作、成都网站建设网站策划，项目实施与项目整合能力。我们以让每一个梦想脱颖而出为使命，1280元射洪做网站,已为上家服务,为射洪各地企业和个人服务,联系电话:18980820575

一、立项分析（A）

区块链可以通过智能合约安全透明的进行链上交互。但区块链不是脱离现实的乌托邦，区块链终究需要和现实世界的数据进行交互。

区块链上的许多场景下，智能合约应用都必须要获取链外信息源，进行链内外数据交互，才能触发其逻辑判断。例如，区块链上的去中心化交易市场系统、去中心化的保险系统、各种预测市场系统、航班晚点的即时赔偿系统等等，都需要及时获取链外实时真实数据以触发执行智能合约。智能合约无法自行访问链下数据，所以引用来自外部的某个数据源。

我们把链上（区块链）与链下（现实世界）中的信息桥梁称之为预言机（Oracles），通过预言机能够把信息从链下传递到链上，传递现实世界的信息并与区块链进行交互。

如果没有预言机，那么将无法实现信息的传递，将无法实现区块链与现实世界的大规模结合和应用，阻碍了区块链落地。预言机是区块链领域必不可少的中间件，是大量区块链智能合约连接到现实世界的数据的“中介”，未来将有百亿美元的空间。

近年来大火的DeFI同样需要安全的中间软件才能连接到链上和链下数据。由于整个分布式生态系统依赖于预言机（Oracle)，并且其对数据的需求呈指数级增长，因此整个应用程序都面临预言机漏洞。

目前市场上份额最多和市值最高的预言机项目是 Chainlink，一度冲进了市值前十，LINK的去中心化主要依靠代币经济激励和信誉体系建立良性循环的生态系统，预言机的触发需要通过转账来实现，缺点在于所有投票都走链上导致 Gas 费用较高。

除了 Chainlink 以外，传统去中心化预言机项目还有 DOS、Tellor 和 Band 等，其技术逻辑大同小异，大多是走链下收集数据，链上验证的路径。这类预言机的核心问题是验证依赖第三方，抗攻击性较弱。前段时间，一家叫做Zeus Capital的公司发布了一篇长达60页的Chainlink做空报告，指出LINK节点存在中心化、不透明，代币的经济模型存在问题等。

当前市场上主要预言机产品在很大程度上不透明、不统一、不准确且难以扩展等问题，这与DeFI所代表的安全、透明等价值不相适应。一款真正适应DeFI领域能够为去中心化金融提供数据支撑的预言机项目迫在眉睫。

二、技术特点（BBB）

今天介绍的DIA正是能够解决现有预言机问题的项目。DIA的官网是这样介绍的：金融智能合约生态系统中开放金融数据的生态系统。

DIA的目标是让数据分析师，数据提供者和数据用户一起使用平台的功能。DIA在各种来源的链下数据与链上智能合约之间建立了可靠且可验证的桥梁，可用于构建各种金融dApp。简单理解就是DIA是专门为DeFi生态领域打造的预言机系统。

预言机的模式比较简单，核心有两方面，一方面是如何去中心化的对获取数据的真实度进行博弈，另一方面是对提交优质数据的用户提供激励。

前面说过现在的预言机龙头Chainlink，Chainlink 预言机是通过在链上合约与链下分布式节点之间进行工单分配协作，通过奖惩机制、声誉合约和聚合模型（聚合多数据源的数据）的方式，进行数据的请求和反馈。但是这种方式得到的数据没有很强的安全背书，核心是因为如果出现上传者合谋作恶，那么受到惩罚将会是有一定延迟的，并且数据已经投入使用，一切都晚了。

而DIA系统的运行步骤是这样的：

1、数据收集机制直接从交易所API和公共来源等各种来源获取收集数据。

2、数据host在DIA服务器上，在链上哈希加密。方法源代码和scraper代码都记录在Github上。推送可通过API和预言机获得。多方博弈设定强奖惩制度，从而使价格是在链上形成的，已经是矿工们通过博弈生成的事实。数据库层可以灵活地处理各种不同类型的数据流，从高频交易api到高性能键值存储中永不更改和可访问的数据。

3、分布式金融协议和指数供应方及他方可以直接接入数据流,使用DIA的restapi和Oracle系统来分发收集和聚合的数据。

DIA 的工作原理主要包括数据请求、数据提交、验证、数据存储和通过 Oracle 或 API 访问数据这五个方面。应用了这种模式的 DIA预言机具备更好的去中心化程度、更真实的数据、更强的稳定性，以及更高的攻击成本。

像MakerDao，Synthetix，Ampleforth之类的DeFI平台特别容易受到预言机漏洞的攻击。由于这些平台被设想为可满足各种金融需求的自主金融协议，因此它们严重依赖透明，准确的价格预言。

DIA 的数据来源是透明的，每个人都可以公开访问。市场参与者可以提供、分享和使用金融、数字资产数据，DIA 的使命是实现金融数据的民主化。直接通过API或预言机访问数据，将DIA直接连接到计算代理或任何其他分布式金融（分布式）应用程序。

DIA 平台利用加密货币的经济激励模式来获取和验证数据。DeFI平台将迁移到透明且可审核的第三方解决方案，以确保其核心产品的可持续性。

三、通证经济及Bonding curve(BBB)

在整个运行过程中，DIA作为治理代币能够发挥重要作用。DIA代币可用于为数据收集、数据验证 、对与协会有关的决定进行投票提供资金，也用于激励平台本身的开发，使分散的社区能够自主运行DIA平台。DIA独特地满足了这些需求。

DIA有四方面的作用，激励、验证、治理和value增值。

社区可以通过为数据清洗的公共奖励提供资金、有效算法的开发、系统漏洞的发现等获得奖励。

DIA目前没有上线交易所，马上要开始众筹。DIA的信息如下：

总发行量：2亿枚

官网：diadata.org

私募：1000万枚（5%）

公募：3000万枚（15%）

公募形式：Bonding curve

这里介绍一下什么是Bonding curve，这个参与模式任何人都可以参与“联合曲线分配”。联合曲线是公开发售设计的一种创新类型，精心设计的智能合约可以自动创建 DIA 市场，当从合约中购买代币时，每个代币的价格都会增加，而在售回时会降低。因此实际上，交易是由转让批次中每个代币的平均价格和市场上代币的数量决定的。通过联合曲线出售将在 Gnosis 协议 Mesa DEX 上提供流动性。

开始时间：2020年8月3日欧洲中部时间15点（北京时间21点）；

结束时间：2020年8月18日欧洲中部时间3点（北京时间9点）；

持续时间：约14天

支持货币：ETH，DAI，USDC

初始价格：0.05美元

初始供应：3000万

受限制的国家：美国，伊朗等

DIA团队将于欧洲中部时间8月3日星期一下午3点（北京时间晚上9点）发布DIA兑换页面。兑换链接将在DIA token网站()中发布。

可以通过IMTOKEN等钱包或MetaMask参与，在相应兑换界面中将ETH与USDT转换为锚定WETH或USDC，推荐去Balancer DEX兑换DIA。这一步骤相信大家都会，我就不啰嗦了。

四、团队分析（BB）

通过官网的消息可以查询到DIA的团队情况。

1、Michael Weber – Association Chairman 协会主席

Michael于2014年创立了Bonsum＆Goodcoin，这是一种由区块链驱动的用户忠诚度解决方案，是有史以来第一个定性的“ Good”数字货币，该货币在2016年成功出售。他是一位加密货币资深人士和连续创业者，他曾在野村兄弟，瑞士的InsureTech和德国的跨国公司Bertelsmann Michaels担任投资银行家，数据分析师和衍生品交易员，他的专业知识使他对德国的金融法律框架和数字化有了深刻的了解。Michael还是NGO Hostwriter.org的活跃董事会成员和bitEasy的联合创始人。

2、Paul Claudius – Association Board 协会董事

Paul也是一位连续企业家和加密货币投资者。他在各种战略事务和国际增长计划方面拥有超过10年的经验，在欧洲范围内扩展业务。在创立DIA之前，他曾是位于柏林的nu3集团欧洲总监，将数百万个电子商务业务转变为垂直整合的品牌。 Paul的职业生涯开始于纽约的BNP Paribas企业发展和美因河畔法兰克福的AXA私募股权。

保罗是bitEasy的创始人，曾为多家医疗技术，物联网和电子商务初创企业提供咨询和投资。

3、Martin Hobler – Association Board 协会董事

Martin是一位成功的互联网企业家，在营销，销售和策略方面拥有多年的专业知识。Martin此前曾在一级方程式和ATP网球运动中担任 体育 经理，曾与拉科斯特，沃斯坦纳和其他国际品牌合作。作为互联网先驱，马丁还帮助建立了柏林移动导航公司Gate 5，该公司后来被成功出售给了诺基亚。

整体来看，DIA团队的主要成员都长期从业于区块链领域，对区块链技术有着深厚的见解。团队目前能查到有12名成员，所有成员都在领英上可查，真实性较高。

核心成员更是区块链领域里的连续创业者，还有金融行业的背景。DIA团队是一个技术扎实、区块链和金融行业资源较丰富的团队。

五、社区社群（B）

Dia官网列示的官方用户社区渠道主要有telegram、Medium 主页、和 Twitter。

1.telegram

电报群有3430名支持者，人数一般，发言比较积极，主要是针对项目ICO的情况进行讨论。

2.Medium

有155个支持者，人数虽然不多，但最新的发布内容是7月29日，信息更新比较及时，最新一篇文章主要内容是如何获得DIA。

3.Twitter

4.Google 趋势

选取「DIADATA」词条进行查询，没有足够的搜索量。

预言机在区块链领域占据着枢纽的地位。尤其是当前市场上主要预言机产品在很大程度上不透明、不统一、不准确且难以扩展等问题，这与DeFI所代表的安全、透明等价值不相适应。

DIA的目标是让数据分析师，数据提供者和数据用户一起使用平台的功能。DIA在各种来源的链下数据与链上智能合约之间建立了可靠且可验证的桥梁，可用于构建各种金融dApp。任何旨在提供有关数字资产或金融市场的准确信息的人都可以从DIA平台获取高度可靠的数据。DIA核心团队都是区块链领域里的连续创业者，一个技术扎实、区块链和金融行业资源较丰富的团队。这些都将成为DIADATA的发展提供巨大的支持。

DIA的解决方案是通过创建分布式 Oracle 网络来解决这个问题。虽然预言机领域前景很好，但实现难度也较高。DIA还存在宣传不够、社区活跃度较低等问题,有待进一步加强。

问个问题，怎么预测一下，Oracle数据库能承受多少连接数

你写个脚本，脚本里主要是一个循环，循环里做的事情包括：

1、连接数据库

2、数据库里面sleep一段时间。

然后把循环的数量不断增加。直到报错。类似不能连接之类的，这个时候就表示不能再连接了。

当然实际情况会比这个连接数小很多。因为这个测试的连接毕竟没有做什么事情。

但是可以在此过程中，测试一下cpu的利用以及内存的利用。

ORACLE使用expdp导出库时，预估的大小和实际导出的大小相差很大是什么原因？

你有大量的空BLOCKS所致，数据库无数据。

expdp有压缩模式、不压缩模式两种：

不压缩模式就是数据有多少，文件就有多大，速度快，这是以空间换时间。

压缩模式导出文件会比不压缩模式小1/3～2/3，但是导出速度会慢些，这是以时间换空间。

如何进行大数据分析及处理？

大数据的分析从所周知，大数据已经不简简单单是数据大的事实了，而最重要的现实是对大数据进行分析，只有通过分析才能获取很多智能的，深入的，有价值的信息。那么越来越多的应用涉及到大数据，而这些大数据的属性，包括数量，速度，多样性等等都是呈现了大数据不断增长的复杂性，所以大数据的分析方法在大数据领域就显得尤为重要，可以说是决定最终信息是否有价值的决定性因素。基于如此的认识，大数据分析普遍存在的方法理论有哪些呢？1. 可视化分析。大数据分析的使用者有大数据分析专家，同时还有普通用户，但是他们二者对于大数据分析最基本的要求就是可视化分析，因为可视化分析能够直观的呈现大数据特点，同时能够非常容易被读者所接受，就如同看图说话一样简单明了。2. 数据挖掘算法。大数据分析的理论核心就是数据挖掘算法，各种数据挖掘的算法基于不同的数据类型和格式才能更加科学的呈现出数据本身具备的特点，也正是因为这些被全世界统计学家所公认的各种统计方法（可以称之为真理）才能深入数据内部，挖掘出公认的价值。另外一个方面也是因为有这些数据挖掘的算法才能更快速的处理大数据，如果一个算法得花上好几年才能得出结论，那大数据的价值也就无从说起了。3. 预测性分析。大数据分析最终要的应用领域之一就是预测性分析，从大数据中挖掘出特点，通过科学的建立模型，之后便可以通过模型带入新的数据，从而预测未来的数据。4. 语义引擎。非结构化数据的多元化给数据分析带来新的挑战，我们需要一套工具系统的去分析，提炼数据。语义引擎需要设计到有足够的人工智能以足以从数据中主动地提取信息。5.数据质量和数据管理。大数据分析离不开数据质量和数据管理，高质量的数据和有效的数据管理，无论是在学术研究还是在商业应用领域，都能够保证分析结果的真实和有价值。大数据分析的基础就是以上五个方面，当然更加深入大数据分析的话，还有很多很多更加有特点的、更加深入的、更加专业的大数据分析方法。大数据的技术数据采集：ETL工具负责将分布的、异构数据源中的数据如关系数据、平面数据文件等抽取到临时中间层后进行清洗、转换、集成，最后加载到数据仓库或数据集市中，成为联机分析处理、数据挖掘的基础。数据存取：关系数据库、NOSQL、SQL等。基础架构：云存储、分布式文件存储等。数据处理：自然语言处理(NLP，Natural Language Processing)是研究人与计算机交互的语言问题的一门学科。处理自然语言的关键是要让计算机”理解”自然语言，所以自然语言处理又叫做自然语言理解(NLU，Natural Language Understanding)，也称为计算语言学(Computational Linguistics。一方面它是语言信息处理的一个分支，另一方面它是人工智能(AI, Artificial Intelligence)的核心课题之一。统计分析：假设检验、显著性检验、差异分析、相关分析、T检验、方差分析、卡方分析、偏相关分析、距离分析、回归分析、简单回归分析、多元回归分析、逐步回归、回归预测与残差分析、岭回归、logistic回归分析、曲线估计、因子分析、聚类分析、主成分分析、因子分析、快速聚类法与聚类法、判别分析、对应分析、多元对应分析（最优尺度分析）、bootstrap技术等等。数据挖掘：分类（Classification）、估计（Estimation）、预测（Prediction）、相关性分组或关联规则（Affinity grouping or association rules）、聚类（Clustering）、描述和可视化、Description and Visualization）、复杂数据类型挖掘(Text, Web ,图形图像，视频，音频等)模型预测：预测模型、机器学习、建模仿真。结果呈现：云计算、标签云、关系图等。大数据的处理1. 大数据处理之一：采集大数据的采集是指利用多个数据库来接收发自客户端（Web、App或者传感器形式等）的数据，并且用户可以通过这些数据库来进行简单的查询和处理工作。比如，电商会使用传统的关系型数据库MySQL和Oracle等来存储每一笔事务数据，除此之外，Redis和MongoDB这样的NoSQL数据库也常用于数据的采集。在大数据的采集过程中，其主要特点和挑战是并发数高，因为同时有可能会有成千上万的用户来进行访问和操作，比如火车票售票网站和淘宝，它们并发的访问量在峰值时达到上百万，所以需要在采集端部署大量数据库才能支撑。并且如何在这些数据库之间进行负载均衡和分片的确是需要深入的思考和设计。2. 大数据处理之二：导入/预处理虽然采集端本身会有很多数据库，但是如果要对这些海量数据进行有效的分析，还是应该将这些来自前端的数据导入到一个集中的大型分布式数据库，或者分布式存储集群，并且可以在导入基础上做一些简单的清洗和预处理工作。也有一些用户会在导入时使用来自Twitter的Storm来对数据进行流式计算，来满足部分业务的实时计算需求。导入与预处理过程的特点和挑战主要是导入的数据量大，每秒钟的导入量经常会达到百兆，甚至千兆级别。3. 大数据处理之三：统计/分析统计与分析主要利用分布式数据库，或者分布式计算集群来对存储于其内的海量数据进行普通的分析和分类汇总等，以满足大多数常见的分析需求，在这方面，一些实时性需求会用到EMC的GreenPlum、Oracle的Exadata，以及基于MySQL的列式存储Infobright等，而一些批处理，或者基于半结构化数据的需求可以使用Hadoop。统计与分析这部分的主要特点和挑战是分析涉及的数据量大，其对系统资源，特别是I/O会有极大的占用。4. 大数据处理之四：挖掘与前面统计和分析过程不同的是，数据挖掘一般没有什么预先设定好的主题，主要是在现有数据上面进行基于各种算法的计算，从而起到预测（Predict）的效果，从而实现一些高级别数据分析的需求。比较典型算法有用于聚类的Kmeans、用于统计学习的SVM和用于分类的NaiveBayes，主要使用的工具有Hadoop的Mahout等。该过程的特点和挑战主要是用于挖掘的算法很复杂，并且计算涉及的数据量和计算量都很大，常用数据挖掘算法都以单线程为主。整个大数据处理的普遍流程至少应该满足这四个方面的步骤，才能算得上是一个比较完整的大数据处理。End.

如何提高Oracle数据库数据查询的命中率

影响命中率的因素有四种：字典表活动、临时段活动、回滚段活动、表扫描， 应用DBA可以对这四种因素进行分析，找出数据库命中率低的症结所在。 1)字典表活动 当一个SQL语句第一次到达Oracle内核时数据库对SQL语句进行分析，包含在查询中的数据字典对象被分解，产生SQL执行路径。如果SQL语句指向一个不在SGA中的对象?表或视图，Oracle执行SQL语句到数据典中查询有关对象的信息。数据块从数据字典表被读取到SGA的数据缓存中。由于每个数据字典都很小，因此，我们可缓存这些表以提高对这些表的命中率。但是由于数据字典表的数据块在SGA中占据空间，当增加全部的命中率时，它们会降低表数据块的可用空间， 所以若查询所需的时间字典信息已经在SGA缓存中，那么就没有必要递归调用。 2)临时段的活动 当用户执行一个需要排序的查询时，Oracle设法对内存中排序区内的所有行进行排序，排序区的大小由数据库的init.ora文件的数确定。如果排序区域不够大，数据库就会在排序操作期间开辟临时段。临时段会人为地降低OLTP(online transaction processing）应用命中率,也会降低查询进行排序的性能。如果能在内存中完成全部排序操作，就可以消除向临时段写数据的开销。所以应将SORT_AREA_SIZE设置得足够大，以避免对临时段的需要。这个参数的具体调整方法是:查询相关数据，以确定这个参数的调整。 select * from v$sysstat where name='sorts(disk)'or name='sorts(memory); 大部分排序是在内存中进行的，但还有小部分发生在临时段， 需要调整 值，查看init.ora文件的 SORT_AREA_SIZE值，参数为：SORT_AREA_SIZE＝65536;将其调整到SORT_AREA_SIZE＝131072、这个值调整后，重启ORACLE数据库即可生效。 3)回滚段的活动 回滚段活动分为回滚活动和回滚段头活动。对回滚段头块的访问会降低应用的命中率， 对OLTP系统命中率的影响最大。为确认是否因为回滚段影响了命中率，可以查看监控输出报表中的“数据块相容性读一重写记录应用” 的统计值，这些统计值是用来确定用户从回滚段中访问数据的发生次数。 4)表扫描 通过大扫描读得的块在数据块缓存中不会保持很长时间， 因此表扫描会降低命中率。为了避免不必要的全表扫描，首先是根据需要建立索引，合理的索引设计要建立人对各种查询的分析和预测上，笔者会在SQL优化中详细谈及；其次是将经常用到的表放在内存中，以降低磁盘读写次数。

Oracle表空间容量评估

1. 推荐一个使用平均值估算表空间的脚本：

--不适用windows

with t1 as (

select ss.run_time,ts.name,

decode((round(su.tablespace_usedsize*dt.block_size/1024/1024,2)),null,0,(round(su.tablespace_usedsize*dt.block_size/1024/1024,2))) used_size_mb

from

dba_hist_tbspc_space_usage su,

(select trunc(BEGIN_INTERVAL_TIME) run_time,max(snap_id) snap_id from dba_hist_snapshot

group by trunc(BEGIN_INTERVAL_TIME) ) ss,

v$tablespace ts,

dba_tablespaces dt

where su.snap_id = ss.snap_id

and su.tablespace_id = ts.ts#

and ts.name NOT LIKE '%TEMP%'

and ts.name NOT LIKE '%UNDO%'

and ts.name = dt.tablespace_name order by 2,1),

t2 as (

select e.run_time,e.name,e.used_size_mb,e.used_size_mb - b.used_size_mb growth

from t1 e, t1 b

where e.name = b.name and e.run_time = b.run_time +1),

t5 as (select a.TABLESPACE_NAME,

        a.FILE_NAME,

        a.FILE_ID,

        a.BYTES,

        a.AUTOEXTENSIBLE,

        a.ONLINE_STATUS,

        a.MAXBYTES,

        case

          when a.AUTOEXTENSIBLE = 'YES' and

                a.ONLINE_STATUS not in ('OFFLINE', 'SYSOFF') then

            nvl(a.MAXBYTES, 0)

          else

            nvl(a.BYTES, 0)

        end file_max_size

    from dba_data_files a

    where a.tablespace_name NOT LIKE '%TEMP%'

    and a.tablespace_name NOT LIKE '%UNDO%'

    ),

t3 as (

select tsz.tablespace_name,

tsz.alloc_size_mb,ave.avg_growth_per_day_mb,ave.avg_growth_per_day_mb*90 projected_growth_for_3mths_mb

from

(select tablespace_name, round(sum(file_max_size)/1024/1024,2) alloc_size_mb  from t5 group by tablespace_name) tsz,

(select name,decode(round(avg(growth),2),null,0.11,0,0.11, round(avg(growth),2)) avg_growth_per_day_mb from t2 group by name) ave

where tsz.tablespace_name = ave.name),

t6 as (select

d.tablespace_name tablespace_name,

round((d.sumbytes/1024/1024),2) total_g ,

round(decode(f.sumbytes,null,0,f.sumbytes)/1024/1024,2) free,

round(((d.sumbytes-f.sumbytes)/1024/1024),6) size_could_be_used,

round((d.sumbytes-decode(f.sumbytes,null,0,f.sumbytes))*100/d.sumbytes,2) used_pct,

(100-round((d.sumbytes-decode(f.sumbytes,null,0,f.sumbytes))*100/d.sumbytes,2))*round((d.sumbytes/1024/1024),2) real_free

from

(select

  tablespace_name,  sum(bytes) sumbytes

from dba_free_space  group by tablespace_name) f,

(select tablespace_name,      sum(bytes) sumbytes   

  from dba_data_files    group by tablespace_name) d

where f.tablespace_name(+) = d.tablespace_name)

select t4.tablespace_name,decode(t3.alloc_size_mb,null,0,t3.alloc_size_mb) alloc_sz_mb,

--t6.real_free/round(decode(avg_growth_per_day_mb,null,365,0,365,(t3.avg_growth_per_day_mb)),2) Days_To_Be_Used,

((100-decode(round(t6.size_could_be_used*100/t3.alloc_size_mb,2),null,0,round(t6.size_could_be_used*100/t3.alloc_size_mb,2)))/100*t3.alloc_size_mb)/avg_growth_per_day_mb  Days_To_Be_Used,

round(t6.size_could_be_used*100/t3.alloc_size_mb,4) used_pct_auto,

t6.used_pct used_pct_real

from t3,t6,

(select a.tablespace_name,

round(a.bytes/1024/1024/1024,2) alloc,

round(c.bytes/1024/1024/1024,2) free

from sys.sm$ts_avail a,

sys.sm$ts_free c

where a.tablespace_name = c.tablespace_name(+)

and a.tablespace_name NOT LIKE '%TEMP%'

and a.tablespace_name NOT LIKE '%UNDO%'

) t4

where t4.tablespace_name = t3.tablespace_name(+)

and t4.tablespace_name = t6.tablespace_name(+)

--and ((100-decode(round(t6.size_could_be_used*100/t3.alloc_size_mb,2),null,0,round(t6.size_could_be_used*100/t3.alloc_size_mb,2)))/100*t3.alloc_size_mb)/avg_growth_per_day_mb =30

and ((100-decode(round(t6.size_could_be_used*100/t3.alloc_size_mb,2),null,0,round(t6.size_could_be_used*100/t3.alloc_size_mb,2)))/100*t3.alloc_size_mb)/avg_growth_per_day_mb=0

order by 1;

2. 通过线性回归参数预测未来使用量（待补充）：