大数据生态构建203ab下午速记

会议：大数据生态构建专场会议时间：2016421日下午来自七牛的云技术总监，今天老师给我们讲讲作为新进崛起的时序数据库，InfluxDBInfluxDBInfluxDB不太习惯，InfluxDBQConInfluxDBInfluxDB不稳定或者集群也不稳定、效率的问题，实际上你用它的弄对了可以起到非常好的效果我们前两天在做一个亚测2000万个（英文InfluxDB里面搞，一会儿会介绍一下怎么解决这个方式。绍一下（英文，今天我们来看一下，为什么InfluxDB是这么一个演化过程，跟大家块全部迁到InfluxDB里面来，我们后面可能会把一些像（英文）迁到这里面来。这是刚刚写这张PPT时候搜了时序数据库的，大家可能以前关注那个整个数据库InfluxDB以非常直线的速度往上攀升呢？待会儿我们看一下，InfluxDB到底是InfluxDB怎么解决这个问题的？InfluxDB在关键问题上面都做得，儿跟大家详细讲一下。现在时序数据的场景分两种，一种是企业内部来做，这个系夸张，一个无人机在天上飞，过一段时间上报回去，行驶记录仪过段时间上报回去的手环、智能硬件过段时间上报什么地点的之类，全是时序数据，LOD成为时序数据最大的数，Go安装好以后启动一下进程就可以用了。第三点，它的API非常优雅，提供的全是（英文）服GoGo95%以上的系统都是Golang，所有的系统都是Golang写的。我们评估下来，InfluxDB是OK的，值得在上面投入人力InfluxDB。（InfluxDB它能默认精确到纳秒，我们对它这块非常满意。第一个，首先要跟大家讨论retention，实际上就是指定的数据过期时间，第二个副本数，这是集群方面的，就像这个语句，它就会告诉我间一个retention的数据存活opentsp（英文）都快疯了，你也知道序列化、反序列化，当这个单。这是一个非常大的大杀器，大家如果有关注，在Spark2.0出了一个（英文30分钟求一下平均值，把它文聚合以后的去查的查询效率很多的数据不停的算但有些人在这里提一个问题，5小时了，想起来还没有创建（英文，这时候可以指定（英文）InfluxDB你queryLanguage，非常熟悉，这边唯一的区别，可能就是这个，Time，十InfluxDB相当于小了很多心智负担，对你的要求少很多。同时提出一个，平台构建方，InfluxDBInfluxDB就是这些内容，所以如果1520个，我们看一下InfluxDB的引擎的演化，这个东西，讨论事情的不仅仅对InfluxDB本身来讨论，而是说如果我们不采用InfluxDB，我们自己来做一个引擎，我们该怎么设计，这个念头，暂时放弃这个念头，原因最后出了非常好的引擎，我们来看，首先要明确一点，在InfluxDB里面，除了之前讲的概念，另外这两个在内核级别的概念，在里面不给外部用户属于内核的概念，shardgropshardsharpgropshard数据是一样的，非常朴素的语言来得非常快著称，当时最出行的几个Hbase、LevelDB，LeveLDB最大的是谷歌出的，所以选择了LevelDB成为LSMTree的引擎，LSMTree它的结构大家比较清楚，由WAL+Memtable+SStable里面，它标准的路径就是这样的。LevelDB，我们的一个好处也是非常显而易见，它的吞吐量非常高，往里面写常的地方不支持热备（英文就可以解决这个问题，rockesDB被很多公司在采用。LSMTree对（英文）Hbase为例，我删除一条记录怎么做的？并不是立马删除这条记录，而是在这条记录上打一个删除，题也好解决，用一些策略性的东西也能扛过去，第三个扛不过去了，Toomanyopenfiles，原LevelDB，假设数LevelDBInfluxDB的这个时候他们又转向了BoBBoItDB的作者加入了InfluxDBBoB特别牛了事实上我们发现，它人不敢用InfluxDB，这个引擎老变来变去，用了这个东西以后一点安全感都没有。9都大了，还有什么好说的。InfluxDBCAPmetadataSystem，思路nodel最关键的问题就是它的效率，不停地往里写就行了，不要给我（英文）InfluxDB的写，它用了一个这样的策略，它有一致性要求，你可以是Any、one、All，发起一个请求然后发现这个（英文）2、3、4、上面，这个时候把数据转给它们Any1以后，就返回客户oneAll就全部程度，这个跟Kafka里面特别像，或者说相关的人都应该知道，它就是在这边在1里面存一个队文）2992上面的值。关键是这句话来了，想的话，它宣布从0.12开始不再开源，Cluster闭源了，如果用InfluxDB就用这个单机版，一是不稳定、二是代码不要了。如果说要用高可用，InfluxDB这个高可TSDB。非常，整段的代码都是帮他们写的，最后我们当时决定不太靠谱，InfluxDB的单机版靠谱的，但它这个玩意儿实在是Cluster不靠谱。所以我们决定自己动手干这个事情，保持最后，七牛的TSDB平台，首先抛弃InfluxDB的Cluster的方案，他们在宣布闭源代一直是开源，整个（英文）apple收购了，第二天告诉你（英文）闭源了，不给你用了，很多人很难接受。InfluxDB作为，少量的计算放在InfluxDB的上面，用它的。抽象出repo的概念，一个repo有很多的reries，我们以repo为单位调度，可repo抽到某个地方，但现在并没有生产环境使用这个策略。AAA快满了，它可以打到别的就行了。数据计算框架是基于InfluxDB做了一套（英文，可以分布式的从不同的模型上面取数据，不用他那套。高可用模块，没有非常傻的用InfluxDB块，我们借助了另外一样东西，KafkaKafka（英文）Kafka挪进来了，天KV的组件，我们也改造agent（agent来的，如果它挂了，我们的（英文）就文ScaleInfluxDB0.10以上的版本，在座的任何朋友想用的话，尽别用集群模式，你要保证数据高可用使用它的relayissue，记多那些人没有解决的issue，我们跟社区多沟通一下，我们很乐意这些代码的，七牛的有可以。我的到这里结束。谢谢大家

提问：我们也在用InfluxDB，看到你题的时候，我们用（英文）已经的时候非 ，小的客户，所以在他们整个架构来说暂时还接受不完全的高可用，所以我们还要活着，Kafka，把它再打一份到别的地方去。：，提问请教一下在什么应用场景下面用到时序数据库，能不能举一些应用的：，CDN的平台，一些质量控制都往我们这里打，我们内部现在承受的量，单位都是以亿：0.1开始英文闭源了如果给公司内部用的话可以按时间去（英文，下面请大数据架构师老师为我们大数据即席查询技术：首先非常荣幸有这个机会跟大家一些相关的技术，做一些技术交流。在开始之前，我先简单做自我介绍我是2009年毕业加入，当时做网络协议站相关的建设，还有开放云里面推一些大数据的相关产品。提到开放云，我先简单说几句，大家应该都听过云，但是云和开放云但是开放云它其实是一个面向企业的为企业提供多种领域的包括基础设施多、BigSQL首先要明确它的定位是什么？目前它的定位非常简单或者说非常施形态的产品，还不太一样，PAAS平台是它这个开箱机用的，用户不需要关注底层细节的BigSQL服务的时候，它的任务是运行具体来讲，BigSQL有什么特点？半结构化的数据，常用的格式，这些都是支持的。在使RestAPI、ConsolesparkSQL的实现，如果用户开通了这个服务的时候，如果不用，那其实是不用交任何钱的，不像一些层Ad-HocQuery，它就是面向人的查询，这个我相Qurey是面向人的，面向人的查询首先它要满足Qurey它的延迟需要能够满足与人交互的一个人的度范围内，如果一个Qurey运行一分钟才能运行完，它就不满足这个交互式。（Ad-HocQuery是不固定的，数据没有经BigSQL的示意图，主要让大家展示一下，BigSQL怎么用，有这么两个需要说明的地方，一个是我们数据是可以在不同的用户的WebServer，第二个，你可以做批量的导入，我们有一个BOS系统，把数据放到这个BOS里面做批量的导入，导入进来了之后用户于Hadoop或者spark来做查询引擎我这边列举了从不同维度很度比如说扩展性，SparkSQL的方法，还有其他的原因。总结一下，我认为的事情，有Session管理，还有就是认证，状态，任何一个（英文）过来之后要做持续化的，下面还有负责状态的这些（英文，它去做任务的进度管理等等这方面。还有账单和，再下面是调度和引擎了。Pk英文）过P（英文（英文下发到集群产生这么一个P（英文）不同英文）（英文当然有比较节的策略二点我们计算引擎引之间有个分布式sparkHadoop不管原理还是实现上几乎是地磁盘的（英文）指所有的Mapper，有一个结点的调度器，这个没有画出来，按照这2014年给大家介绍过一次，那里边有相关的，遇到什么问题以及具体的解决方案是什么。这个绿色的模块产出的数据其实和Mapp端产生的数据天壤之别了，而在这个（英文）产生IO就够了，如果读的话也是一个顺序的读，这样把刚才说的，拉取数果大家感可以搜那篇文章我列一个另外解决的方案，这是我们和英特尔的同事合作做shuffleSSD的设备里面，和写传CPU（英文）或者网络上资源消耗的对比图。ShuffleSSD和写传统的机51.51.7倍何一个瓶颈场景下测的，如果IO没有任何瓶颈，可能在现有的基础上会有一点多倍的性能我们还可以做另外一个数字如果有可以做一下我们当时也做了没有条件用SSD，SSD和纯内存文件的系统结果差别不大，IO完全没有瓶颈了，瓶颈已经被转移到CPU甚至网络上去了，这些数字大家可BigSQL它的第二个关键技术是我们构建了一个数据缓存层，刚才在分布式里面也提了，数据缓存层介于计算引擎和引擎之间的，为了方便大家理解，我直接写成了BigSQL，大cacheCache调用这个接口录入到内存里面去。QueryCachemiss，按照预先设定的策略，比如说，数据太大就Load了，不太大也不太旧，并且也有一定的热度，它就会异步的落入到这里面去，这是一个按需的Load策略。还有一个策略做数据的提前预取，两种情况，一Load一些相关的热点数据到缓存里面去，这个在实际应用当中可LoadQueryQuery所涉及到数据的热点情况，比如说看哪些数据量频次是最高的，这个时候也会做一些提前自动的Load，当然自动地域查询指的是很简单的场景，一个数据A放在了北方的一个集群或者因为可能出于某种BLoad直接，的场景不大可能遇到跨地域查询的场景的是一个租户或者一个用户我的数据可能会AB放一份，所以后ABCD，其实ABB的Query跑不起来了，不可能的，我们在公有云里面做一个针对用户的缓存系统，也就是说，，AQP的技术。BigSQL里面做的另外一个比较大的工作或者说可能是我们基础性的工作，我们做了大量的资源和安全相关的事情，出于性能方面的考虑，我们并没有选用虚拟机作为底层的方案，当然不是说虚拟机性能有多差，至少目前从测试的结果来看，尤其是IO层面的了资源，本身可以做（英文，关键系统、CTO的，对它本身做了一下加固，我们已经试用了我们跟凤巢合作了这么一件事情过滤的数据或者过滤的这（英文）BigSQL来做分析。TPP的样子。BigQL的Qy在0（3PBgQL（（英文PU这个候利用PU以有效提高这也一个比通用的宇。Spark，虽然目前只做了即席查询，我们目标基于spark构建一个通用的系统平台，逐渐的在开放云当中推出，有了这需求。比如说，从最开始要做数据收集，数据收集完了之后要去做ETL，做数据，这个数据之后，其实就可以做简单的查询了。提问：问一下，刚刚WebServer数据导入系统的时候是采用什么方式呢SDK调入接口导入吗？去的数据，你当然会配置这个（英文）抓取哪个 来。你也可以调用我们的API，把数据主动的推上来。BigSQL里面。Cache里头，这块您是怎么做的预测？：谢谢孙老师接下来我们掌声有请易观数据CTO 量非常大，来自于我们现在端各种APP，嵌入易观的SDK，设备数覆盖了7.5亿的设备1.5个亿，现在日活基本上过千万了，这些数据实时上传到云端，上传到云端的时候有大家。我们现在虽然不是QPS，我们其实是收数，平均现在80万次每秒，我们现在如100万次每秒，你会发现这个数据量非常大，其实我们在国内各种公有云上面，在做大数据的高性能、高并发、高IO计算的时候，我们用的混合云是唯一一个比较好的出，我们的免，可以很快的延伸，加上相关的产品，这样一些好处。所以我们最终实现了，我们把公有云做好了，用混合云的架构处理我们大数据，这个时候一个问题，我们怎么7.5亿了，月活1.5亿，过去易观做分析报告，现在易观的分析报告已经不用过去的抽样或者做访谈，仅仅不用这些了，而是加上了整个大数据易观SDK的数据，所有分析师出来的，易观TOP500，移动榜都是基于SDK的数据算出来的，易观了66万款APP的T，PBPB级的数据做IDC里边跨机器的迁移，EC2东西，原来在公有云应用端的WEB服务器没有变，大数据集生比较大的变化，同这个问题是我们一开始很大的，大家都是做技术的，这个大坑怎么跳进去，自己把，RabbitMQ，这里面会发现刚才提到性能的瓶颈，数据量这么大以后，资源的都会有一些问题比如说现在几个集群几十个结点同时并行跑一个任务的时候，40分钟，今天同样这个任务数据量差不多的时候，这个时间就无法预估了，因只做分析这一块都不想做，但是现在国内这一块还有点距离，没有办法变成了第二个KafkaDFSSpark，还有说的（英文这是所有的实体机做的。，（这些大家都知道，这是我们目标的一个结构。中间怎么迁呢？刚才说了几个难点，怎么搞定的，第一个，PB级的数据，因为我是要拷出一份做两件事儿，我们那时候遇到巨大的考量，这么大量的数据并发，怎么把它出NIX不行，在这里面可以开发一个服务，用它自己的代码，为什么不APP传给我们数据的时候，都SDK里面。我在什么地方，有一个像简单的（英文NIX反馈给（英文，会清空缓存。回到这个问题来讲，NIX什么时候返回（英文，如果NIXNIXNIX对大SDK说，这件事情我们收到了，那边数据NIX，虽然说它的转发效率很高，并行度很高，对于这个环境来来讲，没法麻烦我们的要求，NIX大家它的开发，能完全做我们的（英文）的方式做相关的请求转发，但没有办法返回兄弟们对（英文）又不太熟，干这件事儿看来不行，Kafka直接从这边把队列放上去，这件地方在大量传输的网络小包的转发请求。你发现我们后来自己还真写了一个Java多线程，你会发现大家同步的时候，要不这儿多，要不这儿多，而且这个积压情况，每百万次或者80万次的请求，不是说满足了五六十万次，它是十倍的Kafka的时候，从这边接收完了之后Kafka同步的TB级，它基本上是一个非常稳定IXaaJaJa（）做的，这两都是Ja的，传这个文的队列面，一个（文，然放过去，aa么时候好、什么时候坏，有的时候从到青岛，我们的两边百兆，有时候10兆很难线下Kafka里面去。下文件队列，把刚才说的接收变成相关的数据文件，为消费者能通过这么大数据的并发，我们想在十分钟到十，从原来的公有云在混合云传下来，儿其实是挺重要的事，如果多的话，文件服务器受不了，Kafka受不了，最后调了比较合适后面解决问题，就是把我们的消费通过多个线程放到Kafka里面去，只要进了线下的Kafka了，我们认为这个事儿基本上没有太大问题了，包括文件的管理细节，其实我们都是1015分钟，据过来追，隔天追，肯定不行，PBMR的数据，把原Kafka也好，NIX也好，Java相关程序也好，试了各种方案以后，发现简单的方法就是刚才说，样的问题来有时间可以再其他的话题，遇到各种各样的数据情况，我们怎么样，月活、日活，做你的用户，你的用户究竟是长的什么样，因为刚才我们说7.5亿相关设功能是免费的的告诉你你的客户什么样，应用也是给开发者来说过去易观都是做APP用户究竟后面也有一些相关的场景，运营分析、、用户分析，提高品牌，这些其实都属性、设备类型、使用的关联分析，APP或者你的应用用之前在哪里用，用之后到哪里去，APP有多么值钱，因为这是易观品牌给你做背书的，都是易观分析师的模型。通VC进行对接，这件事易观过去做分析报告，VC我今天的这么多有哪些技术讨论和问题大家可以随时和我们来做一些相关的讨论，原数据刚才也提到了它是易观SDK在源源不断的每个终端上面上传数据，SDK上传的时候我们加密打包，在转发的时候，原来那个包还没有解，提问：我是亚信数据的。如果是现在有一个企业里面有很多原始的数据用易观分，，，提问：这也一个问题，现在贵阳市也在做的数据开放，贵阳用的是底层平台是阿里云还是担心阿里云毕竟是商业公司，我了解情况，之前还有专线接到杭州为发展太快了我们也没有看到有一些公司在法律数据方面能够健全也需要跟进的一方，，合作伙伴都不会帮助你，我们那时候原来在其他地方，有公司卖数据，你看把号给你，提问：您好，人寿的，因为我们过去也做过类似的数据迁移或者数据库的转换，非常痛苦，因为像我们这种传统关系型数据库，即使数据中心以来传到，也是需要提问：从青岛迁到。Openstark。FTP也可以做这件事儿。FTP传，文件序列、中间的容错这些都不行，我忘易观这种给分析师做一些（英文）Hive上面或者（英的时候又有关联，拿其他的工具现在目前看都不太方便。所以我们用的GP实现刚才说的这种（英文）的查询，包括产品里面的用户，自定义这块的查询时限，通过GP来做模糊计算的事儿，其他里面有时间再交流，那个方法再加速这个计算。家网做大数据，在这边买房能打折吗？我们CTO鸟哥遇到了好几个，我从你这边买房看房地产的规模。首先来看一下大数据，68GMA，大家猜一下这个数据代表着什么？2015GDP，GDP6812GMV，估计应该能猜得出来，逻辑顺下来就是2015年中地产整个行业的GMV，大家可以看到，它大概是68万亿的五分之一，20%GMV2015GMV，有这几个数据可以看出来，，，其实人类社会，有城市这个概念以来，行业就存在了，从古到今，从中国到外国，从海外到内地行业一直都存在着一些行业的痛点，这些痛点会是什么呢？我们先来抛一个给大家看一下，叫演员方子鸽买房招骗393万，他说的是2012年的时候有一个叫的房源骗了人家393万，中介最后得到的惩罚，也是可以让它铭记的。抛出来这个的目的，只是说为了引出来从买房人的角度在行业存在的痛点，第一，虚假房源，在座有多少买房经验？买房的经验或者看过的房源，这个房子不错，打问这个，，在座各位要买房的候基本上会被骚扰有买房的时候经常骚扰也就是说，，第五个痛点比较复杂，其实在整个的过程中，有一处如果发生纰漏就有可能，房屋不仅仅只有买房人，还有卖房人，第一个，卖了如何再买，第二个是何时买，办？他如何才能更好的业主，如何更好的客源，这里边更好的就是说，应该在什么样的适当时机跟你联系，不要在晚上睡觉或者的时候联系你，遭里讨厌。所以这是如何这个事情。杂这些痛点刚才已经了自从人类有了城市这个概念以来其实行业一直存在着，，我们看一蜀道难，于上千年前出了这样一道慨，现在机也有了你如何证那些源没有？何一栋的确认呢第二如准确地述房屋人骑小摩带着到乱逛每次他时候拿着个本子翻过的需求描述其这样是个比较效的件事另后来我的不是这一家的跑到链家了存在个分流问题太容易很好的闭环第四行为实数据比较少在座各位有少已经了房的我概用举手该买房人相对不买房的人是数的每套子挂出到大概两个的时间期比较长们每个人绝大部分人，对房屋行为只一次，比外卖、东商城不一样。，O2O更顺畅。业务复杂，分析挖掘不2000多公里，经过万水业的，是因为它能够提供更好的房地产服务，使得房屋变得不那么难。富的维度是存在着91维，这些维度有经纪人的、、颜值、好评率，每次跟给别人319维描述一个房子，这个房子的朝向，房子是否有飘窗，10万经纪人的努PVMPV一千万左右。第二里面房屋的数量，230030%，打通线上线下以后，平均60O2O40天，它的效率提升在，过楼盘