列式存储测试
Ⅰ 如何检测一个内存条是否是正品
检测一个内存条是否是正品的方法：
内存颗粒
注意内存颗粒上威刚（V-DATA）的Logo，字体较粗，两条园弧的头尾宽窄并不均匀，下面一条与字母“D”没有相连 注意内存颗粒上假威刚（V-DATA）的Logo，字体较细，两条园弧头尾宽窄相同，下面一条与字母“D”相连。
SPD芯片及焊位
注意真品内存PCB板采用双SPD芯片设计，焊接有小型SPD芯片，大型SPD芯片位子没有焊接过的痕迹 注意假内存的PCB板虽然也采用双SPD芯片设计，并焊接有小型SPD芯片，但大型SPD芯片位子有焊接过的痕迹，存有少量焊锡。
代理标签
对比正品威刚（V-DATA）内存上有龙俊电子的标签，而假内存上有龙俊电子的标签是由不法商家将正品标签转贴的，有的能从细节上观察出破绽。
S/N码生产周期
生产周期对比产品标签上的S/N码：5XX代表05年，XX代表生产周期，这应与内存颗粒上的周期是相对应的 ，假威刚内存可能造成无法正常开机使用，主要因为其由正品威刚（V-DATA）内存PCB板焊接报废内存颗粒构成。由于内存条价格主要决定于颗粒价格，而其它PCB板、SPD芯片和滤波电容等的价格影响则相对较小，所以只能通过更换内存颗粒牟取暴利。
Ⅱ 扩充你的硬盘 塞恩斯双盘直连存储测试
【IT168评测中心】随着硬盘容量的提升和价格的不断下降，许多朋友已经将自己的电脑更换成了更大的容量。那之前的硬盘怎么处理呢？扔了有些可惜，重新组装电脑又觉得没必要。这里，改造成移动硬盘或许是个不错的办法。不过由于体积和容量的限制，大多数移动硬盘都是单磁盘设置，传输速度有限，硬盘本身的性能难以得到良好的发挥。今天，我们为大家介绍一款面向家庭用户的直连存储器，它来自厂商塞恩斯，型号为TR2UT-B。
塞恩斯TR2UT-B直连存储（点此查看大图
）
塞恩斯TR2UT-B是一款双盘设计的DAS，也就是直连存储器。相比我们常见的NAS（网络存储器）来说，我们可以将TR2UT-B看作是一款支持双磁盘的移动硬盘盒。当然，相比普通的移动硬盘盒来说，TR2UT-B还是有许多特点的，特别是对于RAID功能的支持也使它能够更好发挥双磁盘的性能。
TR2UT-B规格一览表
这是TR2UT-B的配置清单。从表格来看，它的体积为53*47*10CM，比一本字典的体积稍大。最重要的是，它能够支持JBOD、Spanning、RAID 0和RAID 1。相比前两种模式来说，RAID阵列才是消费者应该关注的重点，RAID 0的快速读写和RAID 1的镜像备份对于用户来说各有用处，我们下面也将就这个重点进行具体的测试。
TR2UT-B正面图（点此查看大图
）
塞恩斯TR2UT-B通身使用了黑色钢琴漆，除了美观之外，也很容易留下指纹。它的前面板设计有一个保护盖（无锁孔），面板下方有一排指示灯，表明产品的工作状态，整体来说设计比较简单。
TR2UT-B背面图（点此查看大图
）
塞恩斯TR2UT-B通身使用了黑色钢琴漆，除了美观之外，也很容易留下指纹。它的前面板设计有一个保护盖（无锁孔），面板下方有一排指示灯，表明产品的工作状态，整体来说设计比较简单。
（点此查看大图
）
背面RAID功能介绍（点此查看大图
）
为了便于用户更改阵列，TR2UT-B还特别在背面贴有简单的阵列适宜图，通过四个开关的不同排列方式，就可以实现磁盘RAID。着重提醒大家注意Striping和Mirroring两个模式，它们分别代表了RAID 0和RAID 1。
（点此查看大图
）
塞恩斯TR2UT-B侧面图（点此查看大图
）
作为一款2-Bay直连存储，TR2UT-B的内部设计比较简单。我们看到了在机箱产品中常见的卷边工艺，避免意外划伤。
内部RAID控制器（点此查看大图
）
这是TR2UT-B内部的电路板，右侧两个接口就是用来连接SATA硬盘的了。左侧的芯片是Silicon image公司的Sil5744 RAID控制器，这是许多外置存储设备中常用的芯片，能够支持RAID0和RAID1两种阵列模式，也是一种廉价的磁盘阵列解决方案。
（点此查看大图
）
内部配备的硬盘（点此查看大图
）
测试产品搭配了两块日立Ultrastar硬盘，型号为HUA721010KLA330。硬盘属于Ultrastar A7K1000系列，接口规范为SATA 3.0Gbps，缓存为32MB，转速为7200rpm，容量为1TB。
好了，基本上我们对于塞恩斯TR2UT-B的介绍就到这里，下面我们还是送上大家比较期待的测试成绩。当然，在公布成绩之前，我们要来看看本次测试使用的平台。
测试平台基本信息
处理器
Intel Core Duo2 E7200（2.53GHz)
内存
现代 2GB DDR2 1066*2
主板芯片组
华硕P5Q-E （Intel P45+ICH10）
硬盘
日立 HUA721010KLA330（1TB 7200RPM SATA）
主板驱动
Intel Chipset Device Software 9.1.0.1007
操作系统
Windows Vista Ultimate SP1 For English 64bit
测试软件
HD Tune 2.53、HD Tach 3.0.1、ATTO Disk、
SiSoftware Sandra Business v2009.1.15.40
本次我们搭建了一个主流Intel平台进行测试。测试的处理器选择了Intel酷睿2 E7200，它的主频为2.53Ghz。内存我们选择了两条DDR2 1066组建双通道，4GB容量也是目前的标准配置。
在操作系统的选择上，我们选择了Windows Vista Ultimate英文版64位操作系统。其实对于磁盘测试来说，众多软件之间的多少都会有些差异，在个别项目中的测试结果甚至差别明显。因此，我们对于每种接口都提供了4款软件的测试数据作为参考。
首先我们进行的是默认状态下（Standard）性能测试。测试表明，在USB2.0无阵列情况下，塞恩斯TR2UT-B的读取性能在26-30MB/s之间，写入性能约为26MB/s，这个成绩对于USB接口来说还算不错。
虽然RAID 0号称是最快的磁盘阵列，不过受到接口速度的影响，性能提升没有想象的那么明显。我们看到，在RAID 0模式下，塞恩斯TR2UT-B最高可以达到约32MB/s的读取速度，写入速度依然为26MB/s左右。
RAID 1阵列的测试成绩相比前两项来说差别也不大，读取速度最高可以接近30MB/s，写入速度接近22MB/s，并没有特别突出的表现。
事实上，由于USB2.0接口传输速度的限制，大多数外置存储产品都只能达到30MB/s以下的读写速度，对于用户来说USB2.0接口的确是太慢了。
目前，许多台式机、笔记本都提供了e-SATA接口，凭借着强大的性能优势和方便的连接方式，e-SATA接口已经能够成为我们目前外置存储产品的最好接口。
从测试的结果来看，在双磁盘无阵列情况下，塞恩斯TR2UT-B的测试成绩还不错，除了ATTO软件之外，另外三款主流软件都给出了70MB/s左右的读取速度。而在ATTO软件的测试中，塞恩斯TR2UT-B的读取速度可以达到147MB/s，写入速度也达到了62MB/s左右，看来ATTO还是更适合FLASH存储测试。
应用e-SATA接口之后，RAID 0的优势体现了出现，不再像USB2.0那样只有微弱的领先优势。在我们使用的测试软件中，有三款软件都给出了100MB/s以上的读取速度，相比标准模式下快了30%左右，写入速度倒是和之前差不多，接近60MB/s。
最后我们测试的是RAID 1阵列，从结果来看它的性能和无阵列情况下的性能差不多。除ATTO软件外，其他软件测试的读取成绩大概为70-80MB/s，写入速度大概为62MB/s，和标准模式下的结果接近。
由此看来，在e-SATA接口下，塞恩斯TR2UT-B的性能得到了较为充分的发挥，70-80MB/s读取速度和60MB/s左右的写入速度是平均水平，如果使用RAID 0阵列的话，写入速度可以达到100MB/s以上，性能提升非常明显。
塞恩斯TR2UT-B（点此查看大图
）
【IT168评测中心】至此，我们针对塞恩斯TR2UT-B进行了为期一周的测试。在我们测试的过程中，塞恩斯TR2UT-B表现不错，多阵列模式给消费者充分的选择余地。经过我们测试，塞恩斯TR2UT-B在USB2.0接口下可以实现约30MB/s的读取速度和22MB/s的写入速度，成绩受到了USB2.0接口传输速度的影响，也符合一般USB接口产品的水平。
随后我们使用e-SATA接口的测试中，塞恩斯TR2UT-B在Standard和RAID 1模式下的性能相近，读取速度在70-80MB/s，写入速度为60MB/s左右。而在RAID 0阵列下，塞恩斯TR2UT-B的读取速度可以达到100MB/s，相比其他阵列来说性能提升非常明显。
总体来看，塞恩斯TR2UT-B对于家庭消费者来说是个不错的选择，RAID 0模式下最大可以提供30%的读取性能提升，比较适合重视传输速度、而又没有什么重要数据的个人消费类用户选购。不过，如果厂商能够将背面的电源开关设置在正面，会使得用户的操作更为方便。
Ⅲ 技术解析Transwarp Inceptor是怎样炼成的
技术解析Transwarp Inceptor是怎样炼成的
当前Hadoop技术蓬勃发展，用于解决大数据的分析难题的技术平台开始涌现。Spark凭借性能强劲、高度容错、调度灵活等技术优势已渐渐成为主流技术，业界大部分厂商都提供了基于Spark的技术方案和产品。根据Databricks的统计，目前有11个商业的Spark版本。
在使用Spark作出计算平台的解决方案中，有两种主流编程模型，一类是基于SparkAPI或者衍生出来的语言，另一种是基于SQL语言。SQL作为数据库领域的事实标准语言，相比较用API(如MapReceAPI，SparkAPI等)来构建大数据分析的解决方案有着先天的优势：一是产业链完善，各种报表工具、ETL工具等可以很好的对接;二是用SQL开发有更低的技术门槛;三是能够降低原有系统的迁移成本等。因此，SQL语言也渐渐成为大数据分析的主流技术标准。本文将深入解析Inceptor的架构、编程模型和编译优化技术，并提供基准测试在多平台上的性能对比数据。
1.Inceptor架构
TranswarpInceptor是基于Spark的分析引擎，如图1所示，从下往上有三层架构：最下面是存储层，包含分布式内存列式存储(TranswarpHolodesk)，可建在内存或者SSD上;中间层是Spark计算引擎层，星环做了大量的改进保证引擎有超强的性能和高度的健壮性;最上层包括一个完整的SQL99和PL/SQL编译器、统计算法库和机器学习算法库，提供完整的R语言访问接口。
TranswarpInceptor可以分析存储在HDFS、HBase或者TranswarpHolodesk分布式缓存中的数据，可以处理的数据量从GB到数十TB，即使数据源或者中间结果的大小远大于内存容量也可高效处理。另外TranswarpInceptor通过改进Spark和YARN的组合，提高了Spark的可管理性。同时星环不仅仅是将Spark作为一个缺省计算引擎，也重写了SQL编译器，提供更加完整的SQL支持。
同时，TranswarpInceptor还通过改进Spark使之更好地与HBase融合，可以为HBase提供完整的SQL支持，包括批量SQL统计、OLAP分析以及高并发低延时的SQL查询能力，使得HBase的应用可以从简单的在线查询应用扩展到复杂分析和在线应用结合的混合应用中，大大拓展了HBase的应用范围。
2.编程模型
TranswarpInceptor提供两种编程模型：一是基于SQL的编程模型，用于常规的数据分析、数据仓库类应用市场;二是基于数据挖掘编程模型，可以利用R语言或者SparkMLlib来做一些深度学习、数据挖掘等业务模型。
2.1SQL模型
TranswarpInceptor实现了自己的SQL解析执行引擎，可以兼容SQL99和HiveQL，自动识别语法，因此可以兼容现有的基于Hive开发的应用。由于TranswarpInceptor完整支持标准的SQL 99标准，传统数据库上运行的业务可以非常方便的迁移到Transwarp Inceptor系统上。此外Transwarp Inceptor支持PL/SQL扩展，传统数据仓库的基于PL/SQL存储过程的应用(如ETL工具)可以非常方便的在Inceptor上并发执行。另外Transwarp Inceptor支持部分SQL 2003标准，如窗口统计功能、安全审计功能等，并对多个行业开发了专门的函数库，因此可以满足多个行业的特性需求。
2.2数据挖掘计算模型
TranswarpInceptor实现了机器学习算法库与统计算法库，支持常用机器学习算法并行化与统计算法并行化，并利用Spark在迭代计算和内存计算上的优势，将并行的机器学习算法与统计算法运行在Spark上。例如：机器学习算法库有包括逻辑回归、朴素贝叶斯、支持向量机、聚类、线性回归、关联挖掘、推荐算法等，统计算法库包括均值、方差、中位数、直方图、箱线图等。TranswarpInceptor可以支持用R语言或者SparkAPI在平台上搭建多种分析型应用，例如用户行为分析、精准营销、对用户贴标签、进行分类。
3.SQL编译与优化
TranswarpInceptor研发了一套完整的SQL编译器，包括HiveQL解析器、SQL标准解析器和PL/SQL解析器，将不同的SQL语言解析成中间级表示语言，然后经过优化器转换成物理执行计划。SQL语言解析后经过逻辑优化器生成中间级表示语言，而中间表示语言再经过物理优化器生成最终的物理执行计划。从架构上分，逻辑优化器和物理优化器都包含基于规则的优化模块和基于成本的优化模块。
为了和Hadoop生态更好的兼容，Inceptor为一个SQL查询生成MapRece上的执行计划和Spark上的执行计划，并且可以通过一个SET命令在两种执行引擎之间切换。
3.1SQL编译与解析
TranswarpInceptor的SQL编译器会根据输入的SQL查询的类型来自动选择不同的解析器，如PL/SQL存储过程会自动进入PL/SQL解析器并生成一个SparkRDD的DAG从而在Spark平台上并行计算，标准SQL查询会进入SQL标准解析器生成Spark或MapRece执行计划。由于HiveQL和标准的SQL有所出入，为了兼容HiveQL，Transwarp Inceptor保留了HiveQL解析器，并可以对非标准SQL的Hive查询生成Spark或者Map Rece执行计划。
3.1.1SQL标准解析器
TranswarpInceptor构建了自主研发的SQL标准解析器，用于解析SQL99& SQL 2003查询并生成Spark和Map Rece的执行计划。词法和语法分析层基于Antlr语法来构建词法范式，通过Antlr来生成抽象语义树，并会通过一些上下文的语义来消除冲突并生成正确的抽象语义树。语义分析层解析上层生成的抽象语义树，根据上下文来生成逻辑执行计划并传递给优化器。首先Transwarp Inceptor会将SQL解析成TABLE SCAN、SELECT、FILTER、JOIN、UNION、ORDER BY、GROUP BY等主要的逻辑块，接着会根据一些Meta信息进一步细化各个逻辑块的执行计划。如TABLE SCAN会分成块读取、块过滤、行级别过滤、序列化等多个执行计划。
3.1.2PL/SQL解析器
PL/SQL是Oracle对SQL语言的模块化扩展，已经在很多行业中有大规模的应用，是数据仓库领域的重要编程语言。
为了让存储过程在Spark上有较好的性能，PL/SQL解析器会根据存储过程中的上下文关系来生成SQLDAG，然后对各SQL的执行计划生成的RDD进行二次编译，通过物理优化器将一些没有依赖关系的RDD进行合并从而生成一个最终的RDDDAG。因此，一个存储过程被解析成一个大的DAG，从而stage之间可以大量并发执行，避免了多次执行SQL的启动开销并保证了系统的并发性能。
解析并生成SQL级别的执行计划
3.2SQL优化器
TranswarpInceptor使用Spark作为默认计算引擎，并且开发了完善的SQL优化器，因此在大量的客户案例性能测试中，TranswarpInceptor的性能领先MapRece 10-100倍，并超越部分开源MPP数据库。SQL优化器对平台性能的提升居功至伟。
3.2.1基于规则的优化器(RuleBasedOptimizer)
目前为止，TranswarpInceptor共实现了一百多个优化规则，并且在持续的添加新的规则。按照功能划分，这些规则主要分布在如下几个模块：
文件读取时过滤
在文件读取时过滤数据能够最大化的减少参与计算的数据量从而最为有效的提高性能，因此TranswarpInceptor提供了多个规则用于生成表的过滤条件。对于一些SQL中的显示条件，TranswarpInceptor会尽量将过滤前推到读取表中;而对于一些隐式的过滤条件，如可以根据joinkey生成的过滤规则，Inceptor会根据语义保证正确性的前提下进行规则生成。
过滤条件前置
TranswarpInceptor能够从复杂的组合过滤条件中筛选出针对特定表的过滤规则，然后通过SQL语义来确定是否能将过滤条件前推到尽量早的时候执行。如果有子查询，过滤条件可以递归前推入最低层的子查询中，从而保证所有的冗余数据被删除。
超宽表的读取过滤
对一些列超多的表进行处理的时候，TranswarpInceptor首先会根据SQL语义来确定要读取的列，并在读取表的时候进行跨列读取减少IO和内存消耗。而如果表有过滤条件，Inceptor会做进一步优化，首先只读取过滤条件相关的列来确定该行记录是否需要被选择，如果不是就跳过当前行的所有列，因此能够最大程度上的减少数据读取。在一些商业实施中，这些优化规则能够带来5x-10x的性能提升。
Shuffle Stage的优化与消除
Spark的shuffle实现的效率非常低，需要把结果写磁盘，然后通过HTTP传输。TranswarpInceptor添加了一些shuffle消除的优化规则，对SQL的DAG中不必要或者是可以合并的shufflestage进行消除或者合并。对于必须要做Shuffle的计算任务，Inceptor通过DAGScheler来提高shuffle的效率：MapTask会直接将结果返回给DAGScheler，然后DAGScheler将结果直接交给Rece Task而不是等待所有Map Task结束，这样能够非常明显的提升shuffle阶段的性能。
Partition消除
TranswarpInceptor提供单一值Partition和RangePartition，并且支持对Partition建Bucket来做多次分区。当Partition过多的时候，系统的性能会因为内存消耗和调度开销而损失。因此，Inceptor提供了多个规则用于消除不必要的Partition，如果上下文中有隐式的对Partition的过滤条件，Inceptor也会生成对partition的过滤规则。
3.2.2基于成本的优化器(CostBasedOptimizer)
基于规则的优化器都是根据一些静态的信息来产生的，因此很多和动态数据相关的特性是不能通过基于规则的优化来解决，因此TranswarpInceptor提供了基于成本的优化器来做二次优化。相关的原始数据主要来自Meta-store中的表统计信息、RDD的信息、SQL上下文中的统计信息等。依赖于这些动态的数据，CBO会计算执行计划的物理成本并选择最有效的执行计划。一些非常有效的优化规则包括如下几点：
JOIN顺序调优
在实际的案例中，join是消耗计算量最多的业务，因此对join的优化至关重要。在多表JOIN模型中，TranswarpInceptor会根据统计信息来预估join的中间结果大小，并选择产生中间数据量最小的join顺序作为执行计划。
JOIN类型的选择
TranswarpInceptor支持Left-mostJoinTree 和 Bush Join Tree，并且会根据统计信息来选择生成哪种Join模型有最佳性能。此外，Transwarp Inceptor会根据原始表或者中间数据的大小来选择是否开启针对数据倾斜模型下的特殊优化等。此外，针对HBase表是否有索引的情况，Transwarp Inceptor会在普通Join和Look-up Join间做个均衡的选择。
并发度的控制
Spark通过线程级并发来提高性能，但是大量的并发可能会带来不必要的调度开销，因此不同的案例在不同并发度下会有最佳性能。TranswarpInceptor通过对RDD的一些属性进行推算来选择最佳并发控制，对很多的案例有着2x-3x的性能提升。
4.TranswarpHolodesk内存计算引擎
为了有效的降低SQL分析的延时，减少磁盘IO对系统性能的影响，星环科技研发了基于内存或者SSD的存储计算引擎TranswarpHolodesk，通过将表数据直接建在内存或者SSD上以实现SQL查询全内存计算。另外TranswarpHolodesk增加了数据索引功能，支持对多个数据列建索引，从而更大程度的降低了SQL查询延时。
4.1存储格式
TranswarpHolodesk基于列式存储做了大量的原创性改进带来更高的性能和更低的数据膨胀率。首先数据被序列化后存储到内存或SSD上以节省者资源占用。如图3所示，每个表的数据被存储成若干个Segment，每个Segment被划分成若干个Block，每个Block按照列方式存储于SSD或内存中。另外每个Block的头部都加上Min-MaxFilter和BloomFilter用于过滤无用的数据块，减少不必要的数据进入计算阶段。
TranswarpHolodesk根据查询条件的谓词属性对每个数据块的对应列构建数据索引，索引列采用自己研发的Trie结构进行组织存储，非索引列采用字典编码的方式进行组织存储。Trie不仅能对具有公共前缀的字符串进行压缩，而且可以对输入的字符串排序，从而可以利用二分查找快速查询所需数据的位置，从而快速响应查询需求。
HDFS2.6支持StorageTier让应用程序可以选择存储层为磁盘或者SSD，但是没有专用的存储格式设计是无法有效利用SSD的读写吞吐量和低延，因此现有的Text以及行列混合(ORC/Parquet)都不能有效的利用SSD的高性能。为此验证存储结构对性能的影响，我们将HDFS构建在SSD上并选用某基准测试来做了进一步的性能对比，结果如图4所示：采用文本格式，PCI-ESSD带来的性能提升仅1.5倍;采用专为内存和SSD设计的Holodesk列式存储，其性能相比较SSD上的HDFS提升高达6倍。
4.2性能优势
某运营商客户在12台x86服务器上搭建了TranswarpInceptor，将TranswarpHolodesk配置在PCIE-SSD上，并与普通磁盘表以及DB2来做性能对比测试。最终测试数据如图5所示：
在纯粹的count测试一项，Holodesk性能相对于磁盘表最高领先32倍;对于join测试一项，TranswarpHolodesk最高领先磁盘表多达12倍;在单表聚合测试中，Holodesk提升倍数达10~30倍。另外TranswarpHolodesk在和DB2的对比中也表现优秀，两个复杂SQL查询在DB2数据库中需要运行1小时以上，但是在使用TranswarpHolodesk均是分钟级和秒级就返回结果。
内存的价格大约是同样容量SSD的十倍左右，为了给企业提供更高性价比的计算方案，TranswarpHolodesk针对SSD进行了大量的优化，使得应用在SSD上运行具有与在内存上比较接近的性能，从而为客户提供了性价比更高的计算平台。
在对TPC-DS的IO密集型查询的测试中，无论上构建在PCI-ESSD还是内存上，Holodesk对比磁盘表有一个数量级上的性能提升;而SSD上的Holodesk性能只比内存差10%左右。
5.稳定的Spark执行引擎
企业目前应用开源Spark的主要困难在稳定性、可管理性和功能不够丰富上。开源Spark在稳定性上还有比较多的问题，在处理大数据量时可能无法运行结束或出现Outofmemory，性能时快时慢，有时比Map/Rece更慢，无法应用到复杂数据分析业务中。
TranswarpInceptor针对各种出错场景设计了多种解决方法，如通过基于成本的优化器选择最合适的执行计划、加强对数据结构内存使用效率的有效管理、对常见的内存出错问题通过磁盘进行数据备份等方式，极大提高了Spark功能和性能的稳定性，上述问题都已经解决并经过商业案例的考验。TranswarpInceptor能稳定的运行7*24小时，并能在TB级规模数据上高效进行各种稳定的统计分析。
6.SQL引擎效能验证
TPC-DS是TPC组织为DecisionSupportSystem设计的一个测试集，包含对大数据集的统计/报表生成/联机查询/数据挖掘等复杂应用，测试用的数据有各种不同的分布与倾斜，与真实场景非常接近。随着国内外各代表性的Hadoop发行版厂商以TPC-DS为标准测评产品，TPC-DS也就逐渐成为了业界公认的Hadoop系统测试准则。
6.1验证对比的平台和配置
我们搭建了两个集群分别用于TranswarpInceptor与ClouderaDataHub/Impala的测试。
6.2TranswarpInceptorVS Cloudera Impala
TranswarpInceptor由于有完善的SQL支持，能够运行全部所有的99个SQL查询。而由于Cloudera官方发布的TPC-DS测试集只包含19个SQL案例，因此我们只能运行这19个SQL，实验证明这部分查询在Impala上全部正常运行完成。
6.3TranswarpInceptorVS Map Rece
我们使用了同样的硬件和软件配置完成和开源的Hive执行效率相比，TranswarpInceptor能够带来10x-100x的性能提升。图8是TPC-DS的部分SQL查询在Inceptor和CDH5.1Hive的性能提升倍数，其中最大的提升倍数竟可达到123倍。
7.结语
随着在大数据领域国内外开始处于同一起跑线，我们相信像星环科技这样国内具有代表性的Hadoop发行版厂商将在中国的广阔市场空间中获得长足发展，并且由于中国市场激烈的竞争与磨练，逐步打磨出超越国外先进厂商的技术与实力。
刘汪根。2013年加入星环，作为早期员工参与了星环大数据平台的构建，现担任数据平台部研发经理，主要负责与管理星环大数据平台数据平台的研发工作，如SQL编译器，Spark执行引擎等工作，产品涵括TranswarpInceptor/TranswarpStream等软件。
【编者按】星环科技从2013年6月开始研发基于Spark的SQL执行引擎，在2013年底推出TranswarpInceptor1.0，并落地了国内首个7x24小时的商用项目。经过1年多的持续创新与改进，星环已经在国内落地了数十个Inceptor的商用项目。这是一篇星环Spark解决方案的技术解析，也是Spark用户可以效仿的优化之道。
Ⅳ hudi流写入如何保证事务
方法如下：
1. 项目背景
传统数仓的组织架构是针对离线数据的OLAP（联机事务分析）需求设计的，常用的导入数据方式为采用sqoop或spark定时作业逐批将业务库数据导入数仓。随着数据分析对实时性要求的不断提高，按小时、甚至分钟级的数据同步越来越普遍。由此展开了基于spark/flink流处理机制的（准）实时同步系统的开发。
然而实时同步数仓从一开始就面临如下几个挑战：
小文件问题。不论是spark的microbatch模式，还是flink的逐条处理模式，每次写入HDFS时都是几M甚至几十KB的文件。长时间下来产生的大量小文件，会对HDFS namenode产生巨大的压力。
对update操作的支持。HDFS系统本身不支持数据的修改，无法实现同步过程中对记录进行修改。
事务性。不论是追加数据还是修改数据，如何保证事务性。即数据只在流处理程序commit操作时一次性写入HDFS，当程序rollback时，已写入或部分写入的数据能随之删除。
Hudi是针对以上问题的解决方案之一。以下是对Hudi的简单介绍，主要内容翻译自官网。
2. Hudi简介
2.1 时间线（Timeline）
Hudi内部按照操作时刻（instant）对表的所有操作维护了一条时间线，由此可以提供表在某一时刻的视图，还能够高效的提取出延后到达的数据。每一个时刻包含：
时刻行为：对表操作的类型，包含：
commit：提交，将批次的数据原子性的写入表；
clean： 清除，后台作业，不断清除不需要的旧得版本的数据；
delta_commit：delta 提交是将批次记录原子性的写入MergeOnRead表中，数据写入的目的地是delta日志文件；
compacttion：压缩，后台作业，将不同结构的数据，例如记录更新操作的行式存储的日志文件合并到列式存储的文件中。压缩本身是一个特殊的commit操作；
rollback：回滚，一些不成功时，删除所有部分写入的文件；
savepoint：保存点，标志某些文件组为“保存的“，这样cleaner就不会删除这些文件；
时刻时间：操作开始的时间戳；
状态：时刻的当前状态，包含：
requested 某个操作被安排执行，但尚未初始化
inflight 某个操作正在执行
completed 某一个操作在时间线上已经完成
Hudi保证按照时间线执行的操作按照时刻时间具有原子性及时间线一致性。
2.2 文件管理
Hudi表存在在DFS系统的 base path（用户写入Hudi时自定义） 目录下，在该目录下被分成不同的分区。每一个分区以 partition path 作为唯一的标识，组织形式与Hive相同。
每一个分区内，文件通过唯一的 FileId 文件id 划分到 FileGroup 文件组。每一个FileGroup包含多个 FileSlice 文件切片，每一个切片包含一个由commit或compaction操作形成的base file 基础文件（parquet文件），以及包含对基础文件进行inserts/update操作的log files 日志文件（log文件)。Hudi采用了MVCC设计，compaction操作会将日志文件和对应的基础文件合并成新的文件切片，clean操作则删除无效的或老版本的文件。
2.3 索引
Hudi通过映射Hoodie键（记录键+ 分区路径）到文件id，提供了高效的upsert操作。当第一个版本的记录写入文件时，这个记录键值和文件的映射关系就不会发生任何改变。换言之，映射的文件组始终包含一组记录的所有版本。
2.4 表类型&查询
Hudi表类型定义了数据是如何被索引、分布到DFS系统，以及以上基本属性和时间线事件如何施加在这个组织上。查询类型定义了底层数据如何暴露给查询。
| 表类型 | 支持的查询类型 | | :-------------------- | :----------------------------- | | Copy On Write写时复制 | 快照查询 + 增量查询 | | Merge On Read读时合并 | 快照查询 + 增量查询 + 读取优化 |
2.4.1 表类型
Copy On Write：仅采用列式存储文件（parquet）存储文件。更新数据时，在写入的同时同步合并文件，仅仅修改文件的版次并重写。
Merge On Read：采用列式存储文件（parquet）+行式存储文件（avro）存储数据。更新数据时，新数据被写入delta文件并随后以异步或同步的方式合并成新版本的列式存储文件。
| 取舍 | CopyOnWrite | MergeOnRead | | :----------------------------------- | :---------------------- | :-------------------- | | 数据延迟 | 高 | 低 | | Update cost (I/O)更新操作开销（I/O） | 高（重写整个parquet） | 低（追加到delta记录） | | Parquet文件大小 | 小（高更新（I/O）开销） | 大（低更新开销） | | 写入频率 | 高 | 低（取决于合并策略） |
2.4.2 查询类型
快照查询：查询会看到以后的提交操作和合并操作的最新的表快照。对于merge on read表，会将最新的基础文件和delta文件进行合并，从而会看到近实时的数据（几分钟的延迟）。对于 on write表，当存在更新/删除操作时或其他写操作时，会直接代替已有的parquet表。
增量查询：查询只会看到给定提交/合并操作之后新写入的数据。由此有效的提供了变更流，从而实现了增量数据管道。
读优化查询：查询会看到给定提交/合并操作之后表的最新快照。只会查看到最新的文件切片中的基础/列式存储文件，并且保证和非hudi列式存储表相同的查询效率。
| 取舍 | 快照 | 读取优化 | | :------- | :------------------------------------------------------ | :------------------------------------ | | 数据延迟 | 低 | 高 | | 查询延迟 | 高（合并基础/列式存储文件 + 行式存储delta / 日志 文件） | 低（原有的基础/列式存储文件查询性能） |
3. Spark结构化流写入Hudi
以下是整合spark结构化流+hudi的示意代码，由于Hudi OutputFormat目前只支持在spark rdd对象中调用，因此写入HDFS操作采用了spark structured streaming的forEachBatch算子。具体说明见注释。
4. 测试结果
受限于测试条件，这次测试没有考虑update操作，而仅仅是测试hudi对追加新数据的性能。
数据程序一共运行5天，期间未发生报错导致程序退出。
kafka每天读取数据约1500万条，被消费的topic共有9个分区。
几点说明如下
1 是否有数据丢失及重复
由于每条记录的分区+偏移量具有唯一性，通过检查同一分区下是否有偏移量重复及不连续的情况，可以断定数据不存丢失及重复消费的情况。
2 最小可支持的单日写入数据条数
数据写入效率，对于cow及mor表，不存在更新操作时，写入速率接近。这本次测试中，spark每秒处理约170条记录。单日可处理1500万条记录。
3 cow和mor表文件大小对比
每十分钟读取两种表同一分区小文件大小，单位M。结果如下图，mor表文件大小增加较大，占用磁盘资源较多。不存在更新操作时，尽可能使用cow表。
Ⅳ 大数据专业主要学什么啊
1、大数据专业，一般是指大数据采集与管理专业；
2、课程设置，大数据专业将从大数据应用的三个主要层面（即数据管理、系统开发、海量数据分析与挖掘）系统地帮助企业掌握大数据应用中的各种典型问题的解决办法，包括实现和分析协同过滤算法、运行和学习分类算法、分布式Hadoop集群的搭建和基准测试、分布式Hbase集群的搭建和基准测试、实现一个基于、Maprece的并行算法、部署Hive并实现一个的数据操作等等，实际提升企业解决实际问题的能力。
3、核心技术，
（1）大数据与Hadoop生态系统。详细介绍分析分布式文件系统HDFS、集群文件系统ClusterFS和NoSQL Database技术的原理与应用；分布式计算框架Maprece、分布式数据库HBase、分布式数据仓库Hive。
（2）关系型数据库技术。详细介绍关系型数据库的原理，掌握典型企业级数据库的构建、管理、开发及应用。
（3）分布式数据处理。详细介绍分析Map/Rece计算模型和Hadoop Map/Rece技术的原理与应用。
（4）海量数据分析与数据挖掘。详细介绍数据挖掘技术、数据挖掘算法–Minhash, Jaccard and Cosine similarity，TF-IDF数据挖掘算法–聚类算法；以及数据挖掘技术在行业中的具体应用。
（5）物联网与大数据。详细介绍物联网中的大数据应用、遥感图像的自动解译、时间序列数据的查询、分析和挖掘。
（6）文件系统（HDFS）。详细介绍HDFS部署，基于HDFS的高性能提供高吞吐量的数据访问。
（7）NoSQL。详细介绍NoSQL非关系型数据库系统的原理、架构及典型应用。
4、行业现状，
今天，越来越多的行业对大数据应用持乐观的态度，大数据或者相关数据分析解决方案的使用在互联网行业，比如网络、腾讯、淘宝、新浪等公司已经成为标准。而像电信、金融、能源这些传统行业，越来越多的用户开始尝试或者考虑怎么样使用大数据解决方案，来提升自己的业务水平。
在“大数据”背景之下，精通“大数据”的专业人才将成为企业最重要的业务角色，“大数据”从业人员薪酬持续增长，人才缺口巨大。
Ⅵ 内存测试卡怎么看
内存测试卡使用说明
本测试卡是居于PCI接口的内存测试卡,通过搭配专用主板,可以测试SDR,
DDR内存.内存频率包括66MHZ,100MHZ,133MHZ.本卡功能包括内存条IC
好坏测试,内存条短路测试,IC内部好坏测试,内存条兼容性稳定性测试.测
试速度快,能精确指出内存条上坏IC所在的位置.是内存生产,维修的好帮手.
一:系统主要组成部分及用法
二:系统测试环境
三:问题和解答
一:本系统主要组成部分为: 3个7段数码管(U4-U6),1个5X8显示阵列(U2),2
个开关(S1,S2)
1:7段数码管用来显示内存M数:
在内存测试过程中,每测完1M,数码管就会显示相对应的M数,测试完后,数码管会
显示出总容量的M数.比如:当你测试双面32M内存时,开始数码管显示000,表明正在
测试0到1M的地址范围.测完1M后,数码管显示001,表示正在测试1M到2M的范围.
测试完后,数码管显示032.
2:开关用来选择测试模式:
本系统提供了四种测试模式:S1,S2 = 00 , 01 , 10 , 11
a):S1,S2=00
此模式也叫快速测试.通过对内存跳跃式测试来判断内存好坏,主要针对IC内部
大部分损坏,金手指接触不良,或者IC假焊,连焊等由于加工造成的内存条损坏.对
于133M外频的内存条,每测试128M约需要5秒钟.
b):S1,S2=01
此模式也叫全面测试.通过对内存中每一单元进行多次读写来判断内存好坏,主要
针对IC内部局部损坏进行测试.对于133M外频的内存条,每测试1M约需要1秒
钟.
Ⅶ 测试对比：UFS与eMMC性能差距到底有多
手机闪存eMMc和UFS这两种不同标准，所表现出的性能也是天差地别。
需要注意的是，eMMc和UFS不是两种不同规格的存储芯片，它们都是在NAND存储芯片的基础上，再加上了控制芯片，接入标准接口，进行标准封装，形成一个高度集成的储存模块。
二者都是面向移动端闪存的一种技术标准。
eMMc最新标准已经发展到5.1。而理论最大传输速度可以达到600M/s，不过实际使用中差不多有250M/s。
而最新的UFS 2.X有两个版本，其中UFS 2.0 HS-G2的理论带宽为5.8Gbps，大约740MB/s，更快速的UFS 2.1 HS-G3的理论带宽更是达到了11.6Gbps，约1.5GB/s。实际使用中可达到600M/s以上。
两者之间如此大的差异是因为UFS使用高速串行接口替代了并行接口，改用了全双工方式，使收发数据可以同时进行，而eMMc则不行。
说了这么多，那么到底对我们使用手机有什么影响呢？首先，最直观的就是，打开程序变快，另外多任务执行响应速度快，低延迟载入快，连续拍照写入更快，预览文件加载更快。而在提升速度的同时功耗变低了。ufs相比eMMc有如此巨大的优势，也不怪“闪存门”受害用户会有如此大的反应了，大家以后购机可要多个心眼了。
数据资料来源于网络。
Ⅷ 内存卡检测工具怎么用
MyDiskTest检测工具 MyDiskTest是SD内存卡、U盘和手机TF卡等的专用检测工具，这个检测工具主要针对内存卡的存储容量还有对内存卡的扩容检测、读写速度测试和文件对比测试。在官方网站和正确途径下载下来之后，要将其与内存卡关联起来，然后点击确定，就可以进行检测。
chipgenius芯片精灵(USB检测工具) 这项检测工具主要是针对USB的，这是一个外用的检测工具，小巧方便，插入接口便能使用，是一个绿色软件。主要功能是可以自动的去查询读卡器、MP3/MP4、U盘、移动硬盘等。 chipgenius芯片精灵不同于其他检测工具的是它的方便和小巧，可以随时查询usb设备的信息、接口速度、序列号等等，是电子消费者、发烧友、数码消费者的最爱。
当然，这里有一个小提示，就是如果内存卡出现故障时，先不要着急，可以先尝试使用橡皮擦或者细腻的纸巾去擦拭内存卡金手指部位，就像电池没电了用牙齿咬一下又可以用一样。在急迫的时候，这个小方法可能会派上用场。