Hive配置记录

hive.fetch.task.conversion:
hive 0.10.0为了执行效率考虑,简单的查询,就是只是select,不带count,sum,group by这样的,都不走map/reduce,直接读取hdfs文件进行filter过滤。
这样做的好处就是不新开mr任务,执行效率要提高不少,但是不好的地方就是用户界面不友好,有时候数据量大还是要等很长时间,但是又没有任何返回。
在hive-site.xml里面有个配置参数叫
hive.fetch.task.conversion
将这个参数设置为more,简单查询就不走map/reduce了,设置为minimal(默认),就任何简单select都会走map/reduce。

付:
hive的配置:

hive.ddl.output.format:hive的ddl语句的输出格式,默认是text,纯文本,还有json格式,这个是0.90以后才出的新配置;  
hive.exec.script.wrapper:hive调用脚本时的包装器,默认是null,如果设置为python的话,那么在做脚本调用操作时语句会变为python <script command>,null的话就是直接执行<script command>;  
hive.exec.plan:hive执行计划的文件路径,默认是null,会在运行时自动设置,形如hdfs://xxxx/xxx/xx;    
hive.exec.scratchdir:hive用来存储不同阶段的map/reduce的执行计划的目录,同时也存储中间输出结果,默认是/tmp/<user.name>/hive,我们实际一般会按组区分,然后组内自建一个tmp目录存储;  
hive.exec.submitviachild:在非local模式下,决定hive是否要在独立的jvm中执行map/reduce;默认是false,也就是说默认map/reduce的作业是在hive的jvm上去提交的;
hive.exec.script.maxerrsize:当用户调用transform或者map或者reduce执行脚本时,最大的序列化错误数,默认100000,一般也不用修改;
hive.exec.compress.output:一个查询的最后一个map/reduce任务输出是否被压缩的标志,默认为false,但是一般会开启为true,好处的话,节省空间不说,在不考虑cpu压力的时候会提高io;
hive.exec.compress.intermediate:类似上个,在一个查询的中间的map/reduce任务输出是否要被压缩,默认false,
hive.jar.path:当使用独立的jvm提交作业时,hive_cli.jar所在的位置,无默认值;
hive.aux.jars.path:当用户自定义了UDF或者SerDe,这些插件的jar都要放到这个目录下,无默认值;
hive.partition.pruning:在编译器发现一个query语句中使用分区表然而未提供任何分区谓词做查询时,抛出一个错误从而保护分区表,默认是nonstrict;(待读源码后细化,网上资料极少)
hive.map.aggr:map端聚合是否开启,默认开启;
hive.join.emit.interval:在发出join结果之前对join最右操作缓存多少行的设定,默认1000;hive jira里有个对该值设置太小的bugfix;
hive.map.aggr.hash.percentmemory:map端聚合时hash表所占用的内存比例,默认0.5,这个在map端聚合开启后使用,
hive.default.fileformat:CREATE TABLE语句的默认文件格式,默认TextFile,其他可选的有SequenceFile、RCFile还有Orc;
hive.merge.mapfiles:在只有map的作业结束时合并小文件,默认开启true;
hive.merge.mapredfiles:在一个map/reduce作业结束后合并小文件,默认不开启false;
<property>
  <name>hive.merge.mapredfiles</name>
  <value>true</value>
  <description>在一个map/reduce作业结束后合并小文件</description>
</property>

hive.merge.size.per.task:作业结束时合并文件的大小,默认256MB;
hive.merge.smallfiles.avgsize:在作业输出文件小于该值时,起一个额外的map/reduce作业将小文件合并为大文件,小文件的基本阈值,设置大点可以减少小文件个数,需要mapfiles和mapredfiles为true,默认值是16MB;
mapred.reduce.tasks:每个作业的reduce任务数,默认是hadoop client的配置1个;
hive.exec.reducers.bytes.per.reducer:每个reducer的大小,默认是1G,输入文件如果是10G,那么就会起10个reducer;
hive.exec.reducers.max:reducer的最大个数,如果在mapred.reduce.tasks设置为负值,那么hive将取该值作为reducers的最大可能值。当然还要依赖(输入文件大小/hive.exec.reducers.bytes.per.reducer)所得出的大小,取其小值作为reducer的个数,hive默认是999;
hive.fileformat.check:加载数据文件时是否校验文件格式,默认是true;
hive.groupby.skewindata:group by操作是否允许数据倾斜,默认是false,当设置为true时,执行计划会生成两个map/reduce作业,第一个MR中会将map的结果随机分布到reduce中,达到负载均衡的目的来解决数据倾斜,
hive.groupby.mapaggr.checkinterval:map端做聚合时,group by 的key所允许的数据行数,超过该值则进行分拆,默认是100000;
hive.mapred.local.mem:本地模式时,map/reduce的内存使用量,默认是0,就是无限制;
hive.mapjoin.followby.map.aggr.hash.percentmemory:map端聚合时hash表的内存占比,该设置约束group by在map join后进行,否则使用hive.map.aggr.hash.percentmemory来确认内存占比,默认值0.3;
hive.map.aggr.hash.force.flush.memeory.threshold:map端聚合时hash表的最大可用内存,如果超过该值则进行flush数据,默认是0.9;
hive.map.aggr.hash.min.reduction:如果hash表的容量与输入行数之比超过这个数,那么map端的hash聚合将被关闭,默认是0.5,设置为1可以保证hash聚合永不被关闭;
hive.optimize.groupby:在做分区和表查询时是否做分桶group by,默认开启true;
hive.multigroupby.singlemr:将多个group by产出为一个单一map/reduce任务计划,当然约束前提是group by有相同的key,默认是false;
hive.optimize.cp:列裁剪,默认开启true,在做查询时只读取用到的列,这个是个有用的优化;
hive.optimize.index.filter:自动使用索引,默认不开启false;
hive.optimize.index.groupby:是否使用聚集索引优化group-by查询,默认关闭false;
hive.optimize.ppd:是否支持谓词下推,默认开启;所谓谓词下推,将外层查询块的 WHERE 子句中的谓词移入所包含的较低层查询块(例如视图),从而能够提早进行数据过滤以及有可能更好地利用索引。
hive.optimize.ppd.storage:谓词下推开启时,谓词是否下推到存储handler,默认开启,在谓词下推关闭时不起作用;
hive.ppd.recognizetransivity:在等值join条件下是否产地重复的谓词过滤器,默认开启;
hive.join.cache.size:在做表join时缓存在内存中的行数,默认25000;
hive.mapjoin.bucket.cache.size:mapjoin时内存cache的每个key要存储多少个value,默认100;
hive.optimize.skewjoin:是否开启数据倾斜的join优化,默认不开启false;
hive.skewjoin.key:判断数据倾斜的阈值,如果在join中发现同样的key超过该值则认为是该key是倾斜的join key,默认是100000;
hive.skewjoin.mapjoin.map.tasks:在数据倾斜join时map join的map数控制,默认是10000;
hive.skewjoin.mapjoin.min.split:数据倾斜join时map join的map任务的最小split大小,默认是33554432,该参数要结合上面的参数共同使用来进行细粒度的控制;
hive.mapred.mode:hive操作执行时的模式,默认是nonstrict非严格模式,如果是strict模式,很多有风险的查询会被禁止运行,比如笛卡尔积的join和动态分区;
hive.exec.script.maxerrsize:一个map/reduce任务允许打印到标准错误里的最大字节数,为了防止脚本把分区日志填满,默认是100000;
hive.exec.script.allow.partial.consumption:hive是否允许脚本不从标准输入中读取任何内容就成功退出,默认关闭false;
hive.script.operator.id.env.var:在用户使用transform函数做自定义map/reduce时,存储唯一的脚本标识的环境变量的名字,默认HIVE_SCRIPT_OPERATOR_ID;
hive.exec.compress.output:控制hive的查询结果输出是否进行压缩,压缩方式在hadoop的mapred.output.compress中配置,默认不压缩false;
hive.exec.compress.intermediate:控制hive的查询中间结果是否进行压缩,同上条配置,默认不压缩false;
hive.exec.parallel:hive的执行job是否并行执行,默认不开启false,在很多操作如join时,子查询之间并无关联可独立运行,这种情况下开启并行运算可以大大加速;
hvie.exec.parallel.thread.number:并行运算开启时,允许多少作业同时计算,默认是8;
hive.exec.rowoffset:是否提供行偏移量的虚拟列,默认是false不提供,Hive有两个虚拟列:一个是INPUT__FILE__NAME,表示输入文件的路径,另外一个是BLOCK__OFFSET__INSIDE__FILE,表示记录在文件中的块偏移量,这对排查出现不符合预期或者null结果的查询是很有帮助的;
hive.task.progress:控制hive是否在执行过程中周期性的更新任务进度计数器,开启这个配置可以帮助job tracker更好的监控任务的执行情况,但是会带来一定的性能损耗,当动态分区标志hive.exec.dynamic.partition开启时,本配置自动开启;
hive.exec.pre.hooks:执行前置条件,一个用逗号分隔开的实现了org.apache.hadoop.hive.ql.hooks.ExecuteWithHookContext接口的java class列表,配置了该配置后,每个hive任务执行前都要执行这个执行前钩子,默认是空;
hive.exec.post.hooks:同上,执行后钩子,默认是空;
hive.exec.failure.hooks:同上,异常时钩子,在程序发生异常时执行,默认是空;
hive.mergejob.maponly:试图生成一个只有map的任务去做merge,前提是支持CombineHiveInputFormat,默认开启true;
hive.mapjoin.smalltable.filesize:输入表文件的mapjoin阈值,如果输入文件的大小小于该值,则试图将普通join转化为mapjoin,默认25MB;
hive.mapjoin.localtask.max.memory.usage:mapjoin本地任务执行时hash表容纳key/value的最大量,超过这个值的话本地任务会自动退出,默认是0.9;
hive.mapjoin.followby.gby.localtask.max.memory.usage:类似上面,只不过是如果mapjoin后有一个group by的话,该配置控制类似这样的query的本地内存容量上限,默认是0.55;
hive.mapjoin.check.memory.rows:在运算了多少行后执行内存使用量检查,默认100000;
hive.heartbeat.interval:发送心跳的时间间隔,在mapjoin和filter操作中使用,默认1000;
hive.auto.convert.join:根据输入文件的大小决定是否将普通join转换为mapjoin的一种优化,默认不开启false;
hive.script.auto.progress:hive的transform/map/reduce脚本执行时是否自动的将进度信息发送给TaskTracker来避免任务没有响应被误杀,本来是当脚本输出到标准错误时,发送进度信息,但是开启该项后,输出到标准错误也不会导致信息发送,因此有可能会造成脚本有死循环产生,但是TaskTracker却没有检查到从而一直循环下去;
hive.script.serde:用户脚本转换输入到输出时的SerDe约束,默认是org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe;
hive.script.recordreader:从脚本读数据的时候的默认reader,默认是org.apache.hadoop.hive.ql.exec.TextRecordReader;
hive.script.recordwriter:写数据到脚本时的默认writer,默认org.apache.hadoop.hive.ql.exec.TextRecordWriter;
hive.input.format:输入格式,默认是org.apache.hadoop.hive.ql.io.CombineHiveInputFormat,如果出现问题,可以改用org.apache.hadoop.hive.ql.io.HiveInputFormat;
hive.udtf.auto.progress:UDTF执行时hive是否发送进度信息到TaskTracker,默认是false;
hive.mapred.reduce.tasks.speculative.execution:reduce任务推测执行是否开启,默认是true;
hive.exec.counters.pull.interval:运行中job轮询JobTracker的时间间隔,设置小会影响JobTracker的load,设置大可能看不出运行任务的信息,要去平衡,默认是1000;
hive.enforce.bucketing:数据分桶是否被强制执行,默认false,如果开启,则写入table数据时会启动分桶,
hive.enforce.sorting:开启强制排序时,插数据到表中会进行强制排序,默认false;
hive.optimize.reducededuplication:如果数据已经根据相同的key做好聚合,那么去除掉多余的map/reduce作业,此配置是文档的推荐配置,建议打开,默认是true;
hive.exec.dynamic.partition:在DML/DDL中是否支持动态分区,默认false;


hive.exec.dynamic.partition.mode:默认strict,在strict模式下,动态分区的使用必须在一个静态分区确认的情况下,其他分区可以是动态;


hive.exec.max.dynamic.partitions:动态分区的上限,默认1000;


hive.exec.max.dynamic.partitions.pernode:每个mapper/reducer节点可以创建的最大动态分区数,默认100;


hive.exec.max.created.files:一个mapreduce作业能创建的HDFS文件最大数,默认是100000;


hive.exec.default.partition.name:当动态分区启用时,如果数据列里包含null或者空字符串的话,数据会被插入到这个分区,默认名字是__HIVE_DEFAULT_PARTITION__;


hive.fetch.output.serde:FetchTask序列化fetch输出时需要的SerDe,默认是org.apache.hadoop.hive.serde2.DelimitedJSONSerDe;


hive.exec.mode.local.auto:是否由hive决定自动在local模式下运行,默认是false,

hive.exec.drop.ignorenoneexistent:在drop表或者视图时如果发现表或视图不存在,是否报错,默认是true;


hive.exec.show.job.failure.debug.info:在作业失败时是否提供一个任务debug信息,默认true;


hive.auto.progress.timeout:运行自动progressor的时间间隔,默认是0等价于forever;


hive.table.parameters.default:新建表的属性字段默认值,默认是empty空;


hive.variable.substitute:是否支持变量替换,如果开启的话,支持语法如${var} ${system:var}和${env.var},默认是true;


hive.error.on.empty.partition:在遇到结果为空的动态分区时是否报错,默认是false;


hive.exim.uri.scheme.whitelist:在导入导出数据时提供的一个白名单列表,列表项之间由逗号分隔,默认hdfs,pfile;


hive.limit.row.max.size:字面意思理解就是在使用limit做数据的子集查询时保证的最小行数据量,默认是100000;


hive.limit.optimize.limit.file:使用简单limit查询数据子集时,可抽样的最大文件数,默认是10;


hive.limit.optimize.enable:使用简单limit抽样数据时是否开启优化选项,默认是false,关于limit的优化问题,在hive programming书中解释的是这个feature有drawback,对于抽样的不确定性给出了风险提示;


hive.limit.optimize.fetch.max:使用简单limit抽样数据允许的最大行数,默认50000,查询query受限,insert不受影响;


hive.rework.mapredwork:是否重做mapreduce,默认是false;


hive.sample.seednumber:用来区分抽样的数字,默认是0;


hive.io.exception.handlers:io异常处理handler类列表,默认是空,当record reader发生io异常时,由这些handler来处理异常;


hive.autogen.columnalias.prefix.label:当在执行中自动产生列别名的前缀,当类似count这样的聚合函数起作用时,如果不明确指出count(a) as xxx的话,那么默认会从列的位置的数字开始算起添加,比如第一个count的结果会冠以列名_c0,接下来依次类推,默认值是_c,数据开发过程中应该很多人都看到过这个别名;


hive.autogen.columnalias.prefix.includefuncname:在自动生成列别名时是否带函数的名字,默认是false;


hive.exec.perf.logger:负责记录客户端性能指标的日志类名,必须是org.apache.hadoop.hive.ql.log.PerfLogger的子类,默认是org.apache.hadoop.hive.ql.log.PerfLogger;


hive.start.cleanup.scratchdir:当启动hive服务时是否清空hive的scratch目录,默认是false;


hive.output.file.extension:输出文件扩展名,默认是空;


hive.insert.into.multilevel.dirs:是否插入到多级目录,默认是false;


hive.files.umask.value:hive创建文件夹时的dfs.umask值,默认是0002;

hive.metastore.local:控制hive是否连接一个远程metastore服务器还是开启一个本地客户端jvm,默认是true,Hive0.10已经取消了该配置项;


javax.jdo.option.ConnectionURL:JDBC连接字符串,默认jdbc:derby:;databaseName=metastore_db;create=true;


javax.jdo.option.ConnectionDriverName:JDBC的driver,默认org.apache.derby.jdbc.EmbeddedDriver;


javax.jdo.PersisteneManagerFactoryClass:实现JDO PersistenceManagerFactory的类名,默认org.datanucleus.jdo.JDOPersistenceManagerFactory;


javax.jdo.option.DetachAllOnCommit:事务提交后detach所有提交的对象,默认是true;


javax.jdo.option.NonTransactionalRead:是否允许非事务的读,默认是true;


javax.jdo.option.ConnectionUserName:username,默认APP;


javax.jdo.option.ConnectionPassword:password,默认mine;


javax.jdo.option.Multithreaded:是否支持并发访问metastore,默认是true;


datanucleus.connectionPoolingType:使用连接池来访问JDBC metastore,默认是DBCP;


datanucleus.validateTables:检查是否存在表的schema,默认是false;


datanucleus.validateColumns:检查是否存在列的schema,默认false;


datanucleus.validateConstraints:检查是否存在constraint的schema,默认false;


datanucleus.stroeManagerType:元数据存储类型,默认rdbms;


datanucleus.autoCreateSchema:在不存在时是否自动创建必要的schema,默认是true;


datanucleus.aotuStartMechanismMode:如果元数据表不正确,抛出异常,默认是checked;


datanucleus.transactionIsolation:默认的事务隔离级别,默认是read-committed;


datanucleus.cache.level2:使用二级缓存,默认是false;


datanucleus.cache.level2.type:二级缓存的类型,有两种,SOFT:软引用,WEAK:弱引用,默认是SOFT;


datanucleus.identifierFactory:id工厂生产表和列名的名字,默认是datanucleus;


datanucleus.plugin.pluginRegistryBundleCheck:当plugin被发现并且重复时的行为,默认是LOG;


hive.metastroe.warehouse.dir:数据仓库的位置,默认是/user/hive/warehouse;


hive.metastore.execute.setugi:非安全模式,设置为true会令metastore以客户端的用户和组权限执行DFS操作,默认是false,这个属性需要服务端和客户端同时设置;


hive.metastore.event.listeners:metastore的事件监听器列表,逗号隔开,默认是空;


hive.metastore.partition.inherit.table.properties:当新建分区时自动继承的key列表,默认是空;


hive.metastore.end.function.listeners:metastore函数执行结束时的监听器列表,默认是空;


hive.metastore.event.expiry.duration:事件表中事件的过期时间,默认是0;


hive.metastore.event.clean.freq:metastore中清理过期事件的定时器的运行周期,默认是0;


hive.metastore.connect.retries:创建metastore连接时的重试次数,默认是5;


hive.metastore.client.connect.retry.delay:客户端在连续的重试连接等待的时间,默认1;


hive.metastore.client.socket.timeout:客户端socket超时时间,默认20秒;


hive.metastore.rawstore.impl:原始metastore的存储实现类,默认是org.apache.hadoop.hive.metastore.ObjectStore;


hive.metastore.batch.retrieve.max:在一个batch获取中,能从metastore里取出的最大记录数,默认是300;


hive.metastore.ds.connection.url.hook:查找JDO连接url时hook的名字,默认是javax.jdo.option.ConnectionURL;


hive.metastore.ds.retry.attempts:当出现连接错误时重试连接的次数,默认是1次;


hive.metastore.ds.retry.interval:metastore重试连接的间隔时间,默认1000毫秒;


hive.metastore.server.min.threads:在thrift服务池中最小的工作线程数,默认是200;


hive.metastore.server.max.threads:最大线程数,默认是100000;


hive.metastore.server.tcp.keepalive:metastore的server是否开启长连接,长连可以预防半连接的积累,默认是true;


hive.metastore.sasl.enabled:metastore thrift接口的安全策略,开启则用SASL加密接口,客户端必须要用Kerberos机制鉴权,默认是不开启false;


hive.metastore.kerberos.keytab.file:在开启sasl后kerberos的keytab文件存放路径,默认是空;


hive.metastore.kerberos.principal:kerberos的principal,_HOST部分会动态替换,默认是hive-metastore/_HOST@EXAMPLE.COM;


hive.metastore.cache.pinobjtypes:在cache中支持的metastore的对象类型,由逗号分隔,默认是Table,StorageDescriptor,SerDeInfo,Partition,Database,Type,FieldSchema,Order;


hive.metastore.authorization.storage.checks:在做类似drop partition操作时,metastore是否要认证权限,默认是false;


hive.metastore.schema.verification:强制metastore的schema一致性,开启的话会校验在metastore中存储的信息的版本和hive的jar包中的版本一致性,并且关闭自动schema迁移,用户必须手动的升级hive并且迁移schema,关闭的话只会在版本不一致时给出警告,默认是false不开启;



hive.index.compact.file.ignore.hdfs:在索引文件中存储的hdfs地址将在运行时被忽略,如果开启的话;如果数据被迁移,那么索引文件依然可用,默认是false;


hive.optimize.index.filter.compact.minsize:压缩索引自动应用的最小输入大小,默认是5368709120;


hive.optimize.index.filter.compact.maxsize:同上,相反含义,如果是负值代表正无穷,默认是-1;


hive.index.compact.query.max.size:一个使用压缩索引做的查询能取到的最大数据量,默认是10737418240 个byte;负值代表无穷大;


hive.index.compact.query.max.entries:使用压缩索引查询时能读到的最大索引项数,默认是10000000;负值代表无穷大;


hive.index.compact.binary.search:在索引表中是否开启二分搜索进行索引项查询,默认是true;


hive.exec.concatenate.check.index:如果设置为true,那么在做ALTER TABLE tbl_name CONCATENATE on a table/partition(有索引) 操作时,抛出错误;可以帮助用户避免index的删除和重建;


hive.stats.dbclass:存储hive临时统计信息的数据库,默认是jdbc:derby;


hive.stats.autogather:在insert overwrite命令时自动收集统计信息,默认开启true;


hive.stats.jdbcdriver:数据库临时存储hive统计信息的jdbc驱动;


hive.stats.dbconnectionstring:临时统计信息数据库连接串,默认jdbc:derby:databaseName=TempStatsStore;create=true;


hive.stats.defaults.publisher:如果dbclass不是jdbc或者hbase,那么使用这个作为默认发布,必须实现StatsPublisher接口,默认是空;


hive.stats.defaults.aggregator:如果dbclass不是jdbc或者hbase,那么使用该类做聚集,要求实现StatsAggregator接口,默认是空;


hive.stats.jdbc.timeout:jdbc连接超时配置,默认30秒;


hive.stats.retries.max:当统计发布合聚集在更新数据库时出现异常时最大的重试次数,默认是0,不重试;


hive.stats.retries.wait:重试次数之间的等待窗口,默认是3000毫秒;


hive.client.stats.publishers:做count的job的统计发布类列表,由逗号隔开,默认是空;必须实现org.apache.hadoop.hive.ql.stats.ClientStatsPublisher接口;


hive.client.stats.counters:没什么用~~~


hive.security.authorization.enabled:hive客户端是否认证,默认是false;


hive.security.authorization.manager:hive客户端认证的管理类,默认是org.apache.hadoop.hive.ql.security.authorization.DefaultHiveAuthorizationProvider;用户定义的要实现org.apache.hadoop.hive.ql.security.authorization.HiveAuthorizationProvider;


hive.security.authenticator.manager:hive客户端授权的管理类,默认是org.apache.hadoop.hive.ql.security.HadoopDefaultAuthenticator;用户定义的需要实现org.apache.hadoop.hive.ql.security.HiveAuthenticatorProvider;


hive.security.authorization.createtable.user.grants:当表创建时自动授权给用户,默认是空;


hive.security.authorization.createtable.group.grants:同上,自动授权给组,默认是空;


hive.security.authorization.createtable.role.grants:同上,自动授权给角色,默认是空;


hive.security.authorization.createtable.owner.grants:同上,自动授权给owner,默认是空;


hive.security.metastore.authorization.manager:metastore的认证管理类,默认是org.apache.hadoop.hive.ql.security.authorization.DefaultHiveMetastoreAuthorizationProvider;用户定义的必须实现org.apache.hadoop.hive.ql.security.authorization.HiveMetastoreAuthorizationProvider接口;接口参数要包含org.apache.hadoop.hive.ql.security.authorization.StorageBasedAuthorizationProvider接口;使用HDFS的权限控制认证而不是hive的基于grant的方式;


hive.security.metastore.authenticator.manager:metastore端的授权管理类,默认是org.apache.hadoop.hive.ql.security.HadoopDefaultMetastoreAuthenticator,自定义的必须实现org.apache.hadoop.hive.ql.security.HiveAuthenticatorProvider接口;


hive.metastore.pre.event.listeners:在metastore做数据库任何操作前执行的事件监听类列表;



fs.har.impl:访问Hadoop Archives的实现类,低于hadoop 0.20版本的都不兼容,默认是org.apache.hadoop.hive.shims.HiveHarFileSystem;


hive.archive.enabled:是否允许归档操作,默认是false;


hive.archive.har.parentdir.settable:在创建HAR文件时必须要有父目录,需要手动设置,在新的hadoop版本会支持,默认是false;


hive.support.concurrency:hive是否支持并发,默认是false,支持读写锁的话,必须要起zookeeper;


hive.lock.mapred.only.operation:控制是否在查询时加锁,默认是false;


hive.lock.numretries:获取锁时尝试的重试次数,默认是100;


hive.lock.sleep.between.retries:在重试间隔的睡眠时间,默认60秒;


hive.zookeeper.quorum:zk地址列表,默认是空;


hive.zookeeper.client.port:zk服务器的连接端口,默认是2181;


hive.zookeeper.session.timeout:zk客户端的session超时时间,默认是600000;


hive.zookeeper.namespace:在所有zk节点创建后的父节点,默认是hive_zookeeper_namespace;


hive.zookeeper.clean.extra.nodes:在session结束时清除所有额外node;


hive.cluster.delegation.token.store.class:代理token的存储实现类,默认是org.apache.hadoop.hive.thrift.MemoryTokenStore,可以设置为org.apache.hadoop.hive.thrift.ZooKeeperTokenStore来做负载均衡集群;


hive.cluster.delegation.token.store.zookeeper.connectString:zk的token存储连接串,默认是localhost:2181;


hive.cluster.delegation.token.store.zookeeper.znode:token存储的节点跟路径,默认是/hive/cluster/delegation;


hive.cluster.delegation.token.store.zookeeper.acl:token存储的ACL,默认是sasl:hive/host1@example.com:cdrwa,sasl:hive/host2@example.com:cdrwa;


hive.use.input.primary.region:从一张input表创建表时,创建这个表到input表的主region,默认是true;


hive.default.region.name:默认region的名字,默认是default;


hive.region.properties:region的默认的文件系统和jobtracker,默认是空;


hive.cli.print.header:查询输出时是否打印名字和列,默认是false;


hive.cli.print.current.db:hive的提示里是否包含当前的db,默认是false;


hive.hbase.wal.enabled:写入hbase时是否强制写wal日志,默认是true;


hive.hwi.war.file:hive在web接口是的war文件的路径,默认是lib/hive-hwi-xxxx(version).war;


hive.hwi.listen.host:hwi监听的host地址,默认是0.0.0.0;


hive.hwi.listen.port:hwi监听的端口,默认是9999;


hive.test.mode:hive是否运行在测试模式,默认是false;


hive.test.mode.prefix:在测试模式运行时,表的前缀字符串,默认是test_;


hive.test.mode.samplefreq:如果hive在测试模式运行,并且表未分桶,抽样频率是多少,默认是32;


hive.test.mode.nosamplelist:在测试模式运行时不进行抽样的表列表,默认是空;

HDFS 分层存储

Hadoop
众所周知,商用硬件可以组装起来创建拥有大数据存储和计算能力的Hadoop集群。将数据拆分成多个部分,分别存储在每个单独的机器上,数据处理逻辑也在同样的机器上执行。

例如:一个1000个节点组成的Hadoop集群,单节点容量有20TB,最多可以存储20PB的数据。因此,所有的这些机器拥有足够的计算能力来履行Hadoop的口号:“take compute to data”。
数据的温度
集群中通常存储着各种不同类型的数据集,不同的团队不同的业务通过该集群可以共享地处理他们不同类型的工作任务。通过数据管道,每个数据集每时每刻都会得到增长。
数据集有一个共同特点就是初始的使用量会很大。在此期间,数据集被认为是“热(HOT)”的。我们通过分析发现,随着时间的推移,使用率会有一定程度的下降,存储的数据每周仅仅就被访问几次,逐渐就变为“温(WARM)”数据。在此后90天中,当数据使用率跌至一个月几次时,它就被定义为“冷(COLD)”数据。
因此数据在最初几天被认为是“热”的,此后第一个月仍然保持为“温”的。在这期间,任务或应用会使用几次该数据。随着数据的使用率下降得更多,它就变“冷”了,在此后90天内或许只被使用寥寥几次。最终,当数据一年只有一两次使用频率、极少用到时,它的“温度”就是“冰冻”的了。

一般来讲,温度与每个数据集都紧密相关。在这个例子中,温度是与数据的年龄成反比的。一个特定数据集的温度也受其他因素影响的。你也可以通过算法决定数据集的温度。
HDFS的分层存储
HDFS从Hadoop2.3开始支持分层存储
它是如何工作的呢?
正常情况下,一台机器添加到集群后,将会有指定的本地文件系统目录来存储这块副本。用来指定本地存储目录的参数是dfs.datanode.dir。另一层中,比如归档(ARCHIVE)层,可以使用名为StorageType的枚举来添加。为了表明这个本地目录属于归档层,该本地目录配置中会带有[ARCHIVE]的前缀。理论上,hadoop集群管理员可以定义多个层级。
比如说:如果在一个已有1000个节点,其总存储容量为20PB的集群上,增加100个节点,其中每个节点有200TB的存储容量。相比已有的1000个节点,这些新增节点的计算能力就相对较差。接下来,我们在所有本地目录的配置中增加ARCHIVE的前缀。那么现在位于归档层的这100个节点将会有20PB的存储量。最后整个集群被划分为两层——磁盘(DISK)层和归档(ARCHIVE)层,每一层有20PB的容量,总容量为40PB。

基于温度将数据映射到存储层
在这个例子中,我们将在拥有更强计算能力节点的DISK层存储高频率使用的“热(HOT)”数据。
至于“温(WARM)”数据,我们将其大部分的副本存储在磁盘层。对于复制因子(replication factor)为3的数据,我们将在磁盘层存储其两个副本,在归档层存储一个副本。
如果数据已经变“冷(COLD)”,那么我们至少将在磁盘层存储其每个块的一个副本。余下的副本都放入归档层。

当一个数据集为认为是“冰冻(FROZEN)”的,这就意味着它几乎已经不被使用,将其存储在具有大量CPU、能执行众多任务节点或容器的节点上是不明智的。我们会把它存储到一个具有最小计算能力的节点上。因此,所有处于“冰冻(FROZEN)”状态块的全部副本都可以被移动到归档层。
跨层的数据流
当数据第一次添加到集群中,它将被存储到默认的磁盘层。基于数据的温度,它的一个或多个副本将被移动到归档层。移动器就是用来把数据从一个层移动到另一层的。移动器的工作原理类似平衡器,除了它可以跨层地移动块的副本。移动器可接受一条HDFS路径,一个副本数目和目的地层信息。然后它将基于所述层的信息识别将要被移动的副本,并调度数据在源数据节点到目的数据节点的移动。
Hadoop 2.6中支持分层存储的变化
Hadoop 2.6中有许多的改进使其能够进一步支持分层存储。你可以附加一个存储策略到某个目录来指明它是“热(HOT)”的,“温(WARM)”的,“冷(COLD)”的, 还是“冰冻(FROZEN)”的。存储策略定义了每一层可存储的副本数量。我可以改变目录的存储策略并启动该目录的移动器来使得策略生效。
使用数据的应用
基于数据的温度,数据的部分或者全部副本可能存储在任一层中。但对于通过HDFS来使用数据的应用而言,其位置是透明的。
虽然“冰冻”数据的所有副本都在归档层,应用依然可以像访问HDFS的任何数据一样来访问它。由于归档层中的节点并没有计算能力,运行在磁盘层的映射(map)任务将从归档层的节点上读取数据,但这会导致增加应用的网络流量消耗。如果这种情况频繁地发生,你可以指定该数据为“温/冷”,并让移动器移回一个或多个副本到磁盘层。
确定数据温度以及完成指定的副本移动至预先定义的分层存储可以全部自动化。
总结
无计算能力的存储比有计算能力的存储要便宜。我们可以依据数据的温度来确保具计算能力的存储能得到充分地使用。因为每一个分块的数据都会被复制多次(默认是3次),根据数据的温度,许多副本都会被移动到低成本的存储中。HDFS支持分层存储并提供必要的工具来进行跨层的数据移动。

多源ETL考虑

ETL解决问题:
1.数据分散问题
2.数据不清洁问题
3.对数据格式不统一

ETL 过程模型

  1. 元数据库
     元数据(metadata)是定义和描述其它数据的数据 关于数据内容、质量、状况和其他特性的信息,在整个数据抽取转换加载过程中起到基础的作用。元数据使用户可以掌握数据的历史情况,如数据从哪里来,流通时间多长,更新频率是多大,数据元素的含义是什么,对它已经进行了哪些计算、转换和筛选等等。
        元数据具有下列属性:
    (1)描述性,元数据是描述数据的数据,这是元数据的最本质的特征。
    (2)动态性,元数据不是静止不变的,它随着所描述对象的变化而变化。
    (3)多样性,元数据的类型多样。
    (4)复杂性,一方面元数据既可以是集合概念也可以是个体概念,元数据中还可以包括其它的元数据;另一方面对不同的描述对象,有些元数据项是必须有的,而有些却不一定强求,即强制性的元数据与选择性的元数据共存。
    (5)多层次性,这是由元数据所描述对象的多层次和元数据使用对象的多层次性决定的。
    (6)支撑性,元数据相对描述对象而言处于次要的地位,但又是必不可少的,起支撑的作用。
        元数据库是以一定的组织方式存储在一起的相关的元数据集合。

元数据可以应该包括下列7个组件。
    (1)环境状况组件。环境状况组件主要是用于监控网络和源数据的状况,它包括:网络状态,各种源数据状态,最佳抽取时间。网络状态和各种源数据状态的数据可以通过定时对网络状况和源数据状况探测自动获取。通过对这两组数据的历史记录分析可以生成最佳抽取时间。
    (2)基本组件。基本组件包括数据源数据库表结构、数据源数据库表属性、数据仓库表结构、数据仓库表属性,等等。基本构件和其它元数据最大的区别在于它是具有版本标识的数据,具有版本标识的数据在很长的一段时间内可以跟踪数据的变化情况。基本构件主要是对源数据的特征进行描述,它包括:可以提供源数据的数据库名,数据库编号,这些数据库的表,表的编号,表中的属性,属性的编号,以及可以提供源数据的文件系统的文件类型、分隔符、转换为数据库系统中目标表的表名等。
    (3)数据状态组件。数据状态组件用于标识数据仓库中的数据是“活性”的还是“惰性”的。由于数据仓库中的数据都是基于共享设计的,因而当将数据仓库中的数据作为源数据进行抽取和转换时,其中的某些数据可能包括一些误导信息,因而对于这些表就需要数据状态字段对它进行控制。
    (4)存取模式组件。存取模式组件是用于确定异构的源数据什么时候将什么数据迁移到数据仓库中,它包括:存取数据的类型、总数以及频率等。在并行环境下,它可以确定如何物理地分离数据,这样可以极大地提高数据传送的效率。
    (5)数据质量要求组件。数据质量规则定义了源数据中的质量要求,它包括了数据源的编号、错误类型编号、可能的修改规则编号等。
    (6)映射规则组件。映射规则定义了数据由数据源到数据仓库映射的规则,它包括:源字段的编号;简单的属性到属性的映射;字段类型的转换;多个源表到一个目标表之间复杂的转换;命名的改变;关键字的改变;等等。
    (7)抽取日志组件。抽取日志组件记录了对数据仓库中的数据进行的每次操作的时间、操作方式、操作过程以及结果。这些信息对于数据仓库的维护非常有用,拥有这些信息可以对ETL过程中的每一步进行监控。
 

  1. 数据预抽取
        按照元数据定义的内容、频率和规则,将保存在有关数据源中的数据抽取出来,存放到另外的数据库中,并将预抽取操作记录在元数据库中。

  2. 数据质量检验
        数据质量是数据使用的适合性。数据质量要求是关于数据明示的、通常隐含的或必须履行的需求或期望。     数据质量检验是依据元数据中定义的各数据质量要求,通过判断,对数据与质量要求的符合性进行评价,并将数据质量检验操作记录在元数据库中。     数据质量主要有两个方面的问题:一个是单数据源数据质量问题,另一个是多数据源的数据交互集成时的数据质量问题。

数据平台拓展

###一、数据的位置
数据存储数据存储,管理的就是数据的位置,在CPU的位置,数据相对其他数据的位置,CPU善于处理顺序性操作数据指令,即:数据预取。
随机读取操作即成为瓶颈,预取到缓存、前端总线的数据都是无效的。传统意义上说,磁盘的存取性能要弱于内存,但是要分随机存取及顺序存取不同的场景下讨论。
#####1、数据存储和更新
追加写可以让我们尽量保持顺序存储文件。但是当数据要进行更新的时候,有两种选择,一种是在数据原地进行更新操作,这样我们就有了随机IO操作。另一种是把更新都放到文件末尾,然后需要读取更新数据的时候进行替换。
#####2、读取数据
一下子读取整个文件,也是很耗费时间的事情,例如数据库中的全表扫描。当我们读取文件中某一个字段时候,我们需要索引。索引的方式有多种,我们可以用一种简单的固定数值大小的有序数组来做索引,数组里存的是当前数据在文件中的存储偏移量。其他索引技术,如hash索引,位图索引等。
索引相当于在数据之上又加了一层树状结构,可以迅速的读取数据。但是打破了我们前面讲的数据的追加写,这些数据都是根据索引随机写入的。在数据库上建立索引的时候都会遇到这个问题,在传统的机械式磁盘上,这个问题会造成千倍的性能差异。
有三种方法可以解决上述问题:
1)把索引放到内存中,可以随机存储和读取,把数据顺序存储到硬盘上。MongoDB,Cassandra都是采取这种方式。这种方式有一个弊端是存储的数据量受限于内存的大小,数据量一大,索引也增大,数据就饱和了。

2)第二种方式是把大的索引结构,拆成很多小的索引来存储。在内存中批量进来的数据,当积累到一个预定的量,就排序然后顺序写到磁盘上,本身就是一个小的索引,数据存储完,最后加一块小的全局索引数据即可。这样读取数据的时候,要遍历一些小的索引,会有随机读取。本质是用部分小的随机读换取了整体的数据顺序存储。我们通过在内存中保存一个元索引或者Bloom filter来实现处理那些小索引的低延迟。
日志结构的归并树(log structed merge tree)是一种典型的实现, 有三个特征:
a)一组小的、不变的索引集。
b)只能追加写 ,合并重复的文件。
c)少量的内存索引消耗换来读取的性能提升。这是一种写优化索引结构。HBase、Cassandra、Bigtable都是通过这种比较小的内存开销来实现读取和存储的平衡。

3)列式存储或者面向列的存储。纯列式存储和谷歌bigtable那种列式存储还是有所不同的,,虽然占用了同一个名字。列式存储很好理解,就是把数据按照列顺序存储到文件中,读取的时候只读需要的列。列式存储需要保持每一列数据都有相同的顺序,即行N在每一列都有相同的偏移。这很重要,因为同一查询中可能要返回多个列的数据,同时可能我们要对多列直接进行连接。每一列保持同样的顺序我们可以用非常简单的循环实现上述操作,且都是高效的CPU和缓存操作。
列式存储的缺点是更新数据的时候需要更新每一个列文件中的相应数据,一个常用的方法就是类似LSM那种批量内存写的方式。当查询只是返回某几列数据,列式存储可以大规模减少磁盘IO。除此之外,列式存储的数据往往属于同一类型,可以进行高效的压缩,一些低延迟,高压缩率的扫描宽度、位填充算法都试用。即使对于未压缩的数据流,同时可以进行针对其编码格式的预取。
列式存储尤其适用于大表扫描,求均值、最大最小值、分组等聚合查询场景。列式存储天然的保持了一列中数据的顺序性,方便两列数据进行关联,而heap-file index结构关联时候,一份数据可以按顺序读取,则另一份数据就会有随机读取了。
典型优势总结:
1)列式压缩,低IO
2)列中每行数据保持顺序,可以按照行id进行关联合并
3)压缩后的数据依然可以进行预取
4)数据延迟序列化
通过heap-file结构把索引存储在内存,是很多NoSQL数据库及一些关系型数据库的首选,例如Riak,CouchBase和MongoDB,模型简单并且运行良好。
要处理更大量的数据,LSM技术应用更为广泛,提供了同时满足高效存储和读取效率的基于磁盘的存取结构。HBase、Cassandra、RocksDB, LevelDB,甚至MongoDB最新版也支持这种技术。

列式存储在MPP数据库里面应用广泛,例如RedShift、Vertica及hadoop上的Parquet等。这种结构适合需要大表扫描的数据处理问题,数据聚合类操作(最大最小值)更是他的主战场。

###二、并行化
把数据放到分布式集群中运算,有两点最为重要:分区(partition)和副本(replication)。 分区又被称为sharding,在随机访问和暴力扫描任务下都表现不错。通过hash函数把数据分布到多个机器上,很像单机上使用的hashtable,只不过这儿每一个桶都被放到了不同的机器上。这样可以通过hash函数直接去存储数据的机器上把数据取出来,这种模式有很强的扩展性,也是唯一可以根据客户端请求数线性扩展的模式。请求会被独立分发到某一机器上单独处理。
我们通过分区可以实现批量任务的并行化,例如聚合函数或者更复杂的聚类或者其他机器学习算法,我们通过广播的方式在所有机器上使任务同时执行。我们还可以运行分治策略来使得高计算的任务在一个更短的时间内解决。批处理系统处理大型的计算问题有不错的效果,但是它的并发性不好,因为执行任务的时候会非常消耗集群的资源。所以分区方式在两个极端情况非常简单:1)直接hash访问 2)广播,然后分而治之,在这两种情况之间还有中间地带,那就是在NoSQL数据库中常用的二级索引技术。

二级索引是指不是构建在主键上的索引,意味着数据不会因为索引的值而进行分区。不能直接通过hash函数去路由到数据本身。我们必须把请求广播到所有节点上,这样会限制了并发性,每一个请求都会卷入所有的节点。因此好多基于key-value的数据库拒绝引入二级索引,虽然它很有价值,例如Hbase和Voldemort。也有些数据库系统包含它了,因为它有用,例如Cassandra、MongoDB、Riak等。重要的是我们要理解好他的效益及他对并发性所造成的影响。
解决上述并发性瓶颈的一个途径是数据副本,例如异步从数据库和Cassandra、MongoDB中的数据副本。实际上副本数据可以是透明的(只是数据恢复时候使用)、只读的(增加读的并发性),可读写的(增加分区容错性)。这些选择都会对系统的一致性造成影响。

这些对一致性的折中,给我们带来一个值得思考的问题?一致性到底有什么用?实现一致性的代价非常昂贵。在数据库中是用串行化来保证ACID的。他的基本保证是所有操作都是顺序排列的。这样实现起来的代价非常昂贵,所以好多关系型数据库也不把他当成默认选项。所以说要想在包含分布式写操作的系统上实现强一致性,如同坠入深渊。 解决一致性问题的方案也很简单,避免他。假如不能避免它把他隔离到尽可能少的写入和尽可能少的机器上。
当然有些业务场景是必须要保证数据一致性的,例如银行转账时候。有些业务场景感觉上是必须保持一致性的,但实际上不是,例如标记一个交易是否有潜在的欺诈,我们可以先把它更新到一个新的字段里面,另外再用一条单独的记录数据去关联最开始的那个交易。所以对一个数据平台来说有效的方式是去避免或者孤立需要一致性的请求,一种孤立的方法是采取单一写入者的策略,Datamic就是典型的例子。另一种物理隔离的方法就是去区分请求中可变和不可变的字段,分别查询。Bloom/CALM把这种理念走的更远,默认的配置选项就是无序执行的策略,只有在必要的时候才启用顺序执行读写语句。

基于Hadoop生态的企业数据中心考虑

一.面临的问题
如今的大数据已经炒得妇孺皆知但实际上真正在企业实践中能够发挥其优点并从中获益的很少。大数据的挑战与机遇并存,大数据的发展将从预期膨胀、炒作阶段转入将逐渐理性发展、落地应用阶段,不可否认大数据是必然趋势,未来的大数据发展依然存在诸多挑战。
目前大数据的发展依然存在诸多挑战,如:
1.各业务部门没有清晰的大数据需求导致数据资产流失;
2.内部数据孤岛严重,数据价值不能充分挖掘;
3.数据可用性低,质量差,利用效率低;
4.数据管理技术和架构无法满足大数据要求;
5.没有明确的大数据构想;
大数据现阶段仍在起步阶段,存在诸多挑战,但未来的发展依然非常乐观。大数据的发展呈现的趋势也逐渐清晰:
1.数据资源化,将成为企业主要资产;
2.将全面落地于企业业务各个方面;
3.与传统数据分析融合,定制分析方案;
4.数据安全的重要性更加明显;
二. 为何选择Hadoop生态
1.成本低;
2.生态圈成熟,社区活跃;
3.能解决大多数大数据需求。

三.实施步骤
1.讨论确定数据分析的应用方向
A.数据支持的业务优化(如:根据用户行为热点调整用户界面)
B.独立数据分析应用(如:投资组合推荐TOP100)
C.大数据精准运营(如:用户流失预警模型)
D.决策支持(如:用户来源细分)
E.。。。
2.统计各产品现有统计需求
明确当前公司的数据分析环境。。。
3.召集各部门产品负责人讨论,协助明确大数据需求
明确大数据能做什么不能做什么
4.确定分析数据源
A.业务数据
B.SDK收集数据
C.日志文件
D.网络爬虫
5.选择确定技术方案
以Hadoop为基础,利用Hive/HBase/Sqoop/Flume/MR/Mahout/Spark/Storm/MQ/Mysql/ 技术整体实现
6.设计实施技术架构
A.数据收集(ETL)
以Sqoop/MR 从业务数据库拉取数据到数据中心(定期)
SDK收集数据直接推送至数据消息队列随后持久化到数据中心(统一开发各平台数据收集SDK,保证收集数据一致性)
爬虫数据保存至数据中心()
各种数据融合消除数据孤岛()
B.数据中心设计
数据中心以HDFS为基础
Hive构建历史数据仓库
Hive数据存储设计:
数据只添加不更新/删除,数据以大表的形式存储? Hive数据仓库设计?
HBase存储近期数据满足准实时分析需求
分析数据以MySQL形式形成满足不同业务部需求的数据集市
C.数据分析处理
以自定义Map/Reduce作为主要数据处理工具,对数据仓库数据进行分析处理,结果推送至MySQL,形成数据集市。
以Spark/Storm 流式计算处理近实时分析需求
以Mahout作为主要数据挖掘分析工具,对数据进行进一步的分析利用
D.结果数据存储(数据集市)
以MySQL为数据库构建数据集市,面向不同业务方向提供不同主题的数据。各集市数据规模控制在千万级以内
E.数据深度处理
基于Mahout/?实现数据的深度挖掘。
F.。。。
7.开发具体分析
整体架构:

大数据的能力可以分为四层:
第一层是骨骼,硬件和存储的计算能力.
第二层是血液,数据建模和管理能力,包括数据如何进行采集、如何进行建模,以及如何最快的计算和最高效的存储等等;
第三层是思想,业务理解和算法能力,很多算法工程师、科学家用大数据的时候可以作出很多关于用户的标签画像,其实这一部分正是他们对于业务的理解和算法能力的体现,但是仅仅这样还不够,大数据应用过 程中需要一个系统、体系完整的解决方案。
第四层是大脑,告诉你今天的数据表现是什么样,问题是什么,未来你可以做一些什么,做完之后的效果会是怎么样,因为这个效果可以 做什么样的改善,这本身就是一个非常复杂完整的体系,产品设计和服务能力,大脑进行产品的设计以及很好的服务能力。 
这四者结合起来,分别表示着大数据的基础建设能力和数据产品能力。  
大数据能力背后意味着非常巨大的挑战,大数据挑战本身也是一个非常完整的闭环。  

基础建设方面,包括如何进行很好的数据采 集,如果你的数据只有几百个T或1PB左右,采集起来不那么难,如果面临几百个PB的数据如何采集,在无线时代已经到来的时候,无线的采集应该如何做?采 集之后非常重要的是计算,如果把数据采集、计算都做得很好,可是上面的应用根本没有很好的方法,快速和有效拿到这些数据来使用,其实前面所有的工作都是白费的。  

关于采集、计算、服务是大数据基础建设方面的挑战,所有这些工作最终都要在上面浮现出来,就是我们所理解的数据产品,我们希望数据产品给到大家真的不只是一个报表,而是希望我们真的用数据产品去理解 商业,理解它的目标,并且把数据不是枯燥的以一个表格的方式呈现给用户,而是告诉你这个数据的含义是什么,如何解读它,在这个过程中去追求数据价值的最大化。关于基础建设和数据产品价值两大块挑战的关键词就是质量、效率和价值。  

关于大数据的能力看起来非常具有想象空间,挑战也是巨大的,这是非常复杂的事情,复杂的事情一定要用复杂的方法去解决,所以我们需要有简单、清晰、明确的顶层设计。过去两年,阿里巴巴大数据实战过程 中的一个顶层设计,下面我们做好数据的基础建设,包括数据采集计算以及服务,上面我们面临的客户数据方面首先是阿里自己的小二,要有能力用好数据做数据化营运,第二块是我们非常紧密的伙伴,即商家。我们在做这件事情顶层设计时,同步考虑阿里的小二和商家如何同时用好数据。数据基础建设方面做好one data和one service,数据上面一块做好对内和对外能够共享的one Platform。解决的是关于大数据本身背后的挑战,基础建设和价值两块的挑战。