作为今年峰会的一大特色，主办方DOIT邀请了整个科技产业圈的“明星教头”–武汉光电国家研究中心谢长生教授、先智数据中国区总经理董唯元、TalkingData研发副总裁阎志涛、VMware大中华区高级技术总监李刚、北京创意云智CTO郁红海、SNIA固态硬盘技术工作组主席Eden Kim、华澜微CEO骆建军、华中科技大学副教授吴非博士和九存联合创始人兼CEO叶毓睿等组成的明星出品人团队，各自带队亮相，在12月12日全天围绕存储新风口–第二存储；HPC、Big data、AI 三大引擎交相辉映；软件定义，全栈软件赋能从核心到边缘；流式大数据和即时交互式分析技术；区块链技术与应用；闪存产业国际合作等12个热点话题展开分享，成为了解最新存储技术、数据创新知识的最佳场所。
大数据应用论坛以“流式大数据和即时交互分析技术”为主题，邀请阎志涛 （TalkingData研发副总裁）担任论坛出品人，
网易资深数据研发工程师黄祥为、苏宁易购IT总部大数据平台高级技术经理陈丰、中东新媒体首席架构师王成光、武汉光电国家研究中心谢长生教授等嘉宾发言探讨。
以下内容根据演讲整理，未经本人审定。
TalkingData研发副总裁阎志涛
主持人：首先自我介绍一下，我叫阎志涛，来自Talking Data，Talking Data负责技术相关的研发工作，我也是分会场的出品人。
非常高兴来主持这个大会。2018中国存储与数据峰会（DATA & STORAGE SUMMIT 2018）基本上偏向于硬件和存储相关，今年增加了大数据叫做DT，我非常有幸参与到这里来。
前面我先讲讲自己的一些观察，因为我自己是从2012年从事大数据相关的工作，基本上见证了中国大数据行业从起步到现在整个这个阶段的发展。
大数据已经不是很前卫的词了，有一段时间大数据是非常前卫的。现在大数据在国家战略里还是很重要的一块，大家听说什么ABCD、AI、区块链、大数据等等都在这里，还有云计算。
首先讲几个概念，流式计算和交互式分析，它跟现在大数据的关系。
流式计算，这个词本身不是特别新的词，它是基于数据流的计算，大家过去经常性面对的计算，数据库里提一个东西出一个结果，但是现在随着互联网场景的发生，数据在无时无刻的产生，比方说现在新的一个热门的话题叫IOT、边缘计算，实际上数据无时无刻不在产生，进到这里面就开始进行计算，数据流的计算，因为是流式计算，数据流的时候就有时间流的处理，正常是数据进来会有event，所以叫做响应式编程。这几个关键的词，还有后面就是并行计算，数据量大的时候需要并行计算，这个构成了流式计算的定义。
流式计算数据是流动的，原来我做大数据的时候是在做很多的IT业务系统，那时候的数据是怎么做的，一般的情况下ROTB是数据入库，是为了保障交易的一致性，同时会有LOG产生，LOG到磁盘，LOG到磁盘之后是为了做事后分析，所以那个时候一般的有什么数仓，也就是说先有ROT就有了RVP，RVP是为了做报告，运行时的数据产生存到磁盘，为日后的消费去做业务洞察去做准备，这是过去一种方式。
随着大数据时代的到来，越来越多的企业发现数据要能够及时的去反映业务场景，这时候也就是数据在流动，写到磁盘，过几天再去算会带来更多的好处。
另外，数据进来的时候是并行的，正常来讲，流式出来有个问题，你要大规模的把数据计算出来的话，原来大家可能都知道并行计算，所有的流式计算都是并行计算的一种实现场景，就是说它一定是对进来的数据流进行并行的计算。
再一个是持续计算，数据流完之后，原来最典型的非流式计算之前，计算到数据那儿做，数据存在哪儿在哪儿做计算，持续计算是这样的，数据在这个地方流动的时候开始做计算，里面有很大的区别，这是整个流式计算我个人抽象出来的几个构成点。
流式计算意味着什么呢？第一个它一定是快速的，就是说现在大家都讲究Fast DATA，另外一个要快速的去用才能产生高价值，所以必须快速处理低延时，你的数据一直在流动，流动的东西如果不能低延时处理的话，整个系统的健壮性就出现很大的问题。
为什么选择流式计算？流式计算的产生跟所有的技术演进一样，都跟业务有关系，是业务驱动的结果。最早大数据就是所谓的小项，也就是在YAHOO、Google做实现的时候那些开源的东西基本上都是流式计算。能做什么呢？一般流式计算能做的第一个是看前一个小时发生了什么错误，一般的系统会用来统计上一个小时日值有多少错误，这个是离线计算的结果。原来在离线的时候，广告投放之后都会看广告效果，一般是把广告日志点击存下来，推广的话把应用安装日志拿过来，第二天算归因转化的计算，形成昨天多少个渠道、每个渠道带来了多少从点击到激活的统计，这是对于广告而言。欺诈也是，把用户所有的行为日值存到磁盘进行离线分析，发现昨天有多少有可能是欺诈的，这在运营过程中是非常有价值的。对于数据来讲，大家并不希望仅仅看到一个报告做分析，而是希望在数据使用过程中让数据产生真正的价值，及时发现问题、及时去做问题的响应，流式处理就产生了价值。
越来越多的企业会把自己的IT运维监控变成流式的，可以实时统计系统的运行状况有很多的公司，IT部门有一个大屏，大屏里面实时的看自己的信息，比方说网络流量，对每一个业务系统进行错误的分析，如果达到阈值它会处罚警告，处罚警告有时候出现几种情况，有时候自动的做处理，比如单列出现错误特别多，它会自动把这个点shut down，新的技术点去增加它的容量，更好的响应IT系统的响应状况，这是实时带来的非常大的好处。对于广告更有价值，广告行为，是广告主掏钱获取自己用户的典型的用钱购买用户的场景，原来离线统计是第二天做业务调整，比方说觉得某个渠道效果不好，只能第二天去做调配，而如果用事实的东西，比方说我们现在公司里做的东西，实时点击到安装的归因，点击日志和归因日志来当场出结果，这样对于广告主和广告运营团队可以实时盯着自己多个渠道转化的效果，动态调整自己的投放策略，将资源投放到更好的渠道，这是对于广告带来的好处。
在欺诈方面，前两年P2P金融非常火，但很多出了爆仓等问题，很大的原因就是这里面有很多欺诈。如果做离线分析，损失造成了再追是非常难受的，通过实时的预测模式，比方说看到某个人的行为，一般实时预测会把他过去的画像带过来，把历史的行为带进来，如果基于分析发现行为有异常，可以不给他放贷，不给他放款，这样的话，可以非常显著的提高金融公司运营的效率，降低运营成本和风险。对于电信也一样，诈骗电话基本上实时识别，降低诈骗的风险。这是流式处理带来的显著好处。
因此，大部分企业越来越倾向于把自己的数据，尤其是核心的业务做流式处理。
那么交互式分析是什么？为什么这两个放在一起谈？
流式处理的优点是非常快速的能够产生响应，但是流式处理有一个问题，所有的流式处理一般的是预先跑的模型或者计算，计算已经先预定下来，流式处理一定要非常快速，数据过的时候就要完成计算，这个时候很难完成交互式流式计算。
这个情况下，流式计算预定规则，可更好的发现异常情况，及时响应，基于生成的日志做分析（因为很多情况下并不是预定的计算规则，数据已经产生，流式已经过来），如何在存储里面去做这种更多维度的分析，与原来看到经典的离线计算的时候确定好的模式，离线去做统计分析形成报表相比，如何据能够及时的响应，深入的分析，希望要多次迭代式，可能要看一看数据，最典型的这个字段或者这个方式跟我有关系，做统计分析，然后发现这里面跟我的关系没这么大，我多拎几个，这个时候变成再一个大规模尺度上。
现在这种流式分析都是基于日志类型，所有用户行为的日志、操作日志一天是几个G，加上历史行为，可能多少个T甚至上P，用户能在这上面完成类似于数据库的交互式分析，这是现在越来越迫切的需求，它实质上是希望用户对于自己对数据的理解，利用提供给他的类cico，有可能是更简洁的界面上，在海量的数据上多维度的分析，甚至建模，他还希望尽量延时低，达到更好的用户体验，因为越延时低，越能尽早的发现问题的根本原因。
前面的流式计算是及时的响应，但是想做根本原因调查的时候，希望基于更多的数据和自己的理解，但是不希望等待。传统的这种提交一个需求要等五六个小时，对用户来讲很难接受的，希望在大数据的场景下，实现一个低延时的交互式分析。它的优点一个是快，二是灵活，这样才能帮助用户更好的去洞察数据蕴藏的价值，方便进一步迭代，出来新的流式的固定的模型，交给流式去做。
前面讲了两个概念，为什么选择流式计算和交互式分析，后面我会带一些技术进来，再就是技术选型的推荐。
应该说，从2013年2014年开始，关于流式处理，或者说这种流式计算的框架越来越多，是这几年在大数据里特别热点的方向，是价值驱动，有价值驱动就有技术的发展。
目前流域流式计算有主要的几个内容，一个就是消息总线，数据进来再处理的时候，它一般会有一个event das，实际上在传统的企业市场里也有消息总线的概念，大数据时代首先支持大量数据存储，然后高吞吐率，因为高吞吐率意味着数据大量的进来，还会延时，会有低消费的消息总线的需求。
这里有两个主要的产品：一个是Kafka，互联网企业里它是标配的产品，基本上所有的公司都会用到Kafka存储自己的日志，不管是流式处理也好，还是永久存储也好，这个是是实时必备的消息总线。另外一个是Pulsor，如果2016年2017年的时候大家毋庸置疑会选择Kafka，但是Kafka出来这么多年之后，有一些限制，比如说Kafka是典型的计算和存储绑在一起的设计，对于Kafka的每一个节点，数据和它的计算节点是在一起。对于一个快速成长的企业来讲，它经常会存在，我一开始设计了一个Kafka的集群，规模比较小，随着时间增加，数据规模变大，业务规模变大，数据增长，这个是Kafka节点增加就会存在一个重新blance数据的问题，这里有可能增长Kafka数据性能的问题。另外一个说现在越来越多的企业会把自己的数据团队当做核心的服务型团队给别人提供服务，企业内部会多组互化或者云化，这个时候Kafka天然的弱点出来了，因为Kafka最早设计的时候不是为多组户设计的，会有一些限制，正是因为这些限制，新的一个消息总线的产品Kafka，这个是Yahoo而开发的产品，Kafka是TP link的产品。
另外就是计算框架，在2012年我们刚开始创业的时候，没有成熟的流式计算的框架。流式计算的框架就是希望基于非常简洁的编程模式实现对数据流动，也就是说在数据上做流动的计算，而不是传统的这种基于离线的文件在那儿，数据在那儿我有一个计算框架，那个时候我们只能自己写自己的流式的引擎。随着业务的演进就会发现，大家可能很多企业都有一种诉求，于是有的公司把公司内部实现的东西开源，第一个想到的就是storm，这个是最早的流式计算的引擎，大概2013年前后在不同的企业里面从twitter出来之后在不同的企业里被大家使用，它是比如说我做一些流式数据的统计，用它非常方便的可以做。随着技术的发展，越来越多的流式计算出来，比如说在大数据行业里非常非常热的一个技术spark，它出来就有streaming，但是不是核心点，从2.0之后越来越重视streaming，现在叫spark streaming。
还有一个大家不所知的越来越热的技术Flink，它在一开始大家基于离线计算的时候，Flink默默无闻。从2016年开始，流式计算越来越多的变成趋势的时候，Flink变成了炙手可热的计算框架，据我了解本来是想把阿里的人请来，因为国内的话大数据的公司无非几类，一类是BAT，然后一些是搞数据的公司，BAT里面阿里就是基于Flink做了自己的开源，把Flink进行深度的定制，针对阿里的业务做了Flink。另外一个在国内游一定影响力的Apex。消息总线两个主要的，但是计算框架我列了四个，实际上现在不仅仅四个。
我做一下技术比较，如果大家有技术选型的话可以参考一下这个东西。首先看Kafka和Pulsor的比较，Kafka消息的特定侧重于高性能流式的消费，Pulsor相对Kafka有一点就是说，因为Kafka的消费类似于set的方式，但是Pulsor支持高性能流式消费以及传统队列式消费。如果大家做传统的企业软件都知道，有Q和topx，topx一对多，Q是一对一，只有一个消费者消费完了就完了，但是Kafka是topx的方式，Pulsor可以支持topx可以支持Q。另外一个Kafka存储在Broker节点上，Pulsor存储和服务分离，方便扩充存储时扩充存储，扩充计算时扩充计算。ACK也不一样，Kafka的ACK我用了这么多年，它offset有它的好处，也有不好处，不好的就是它灵活性不好，Pulsor是用的Cursor的机制，可以灵活的做消息的控制，这里面比方说就是回到下面。对于Kafka来讲，它是没有办法去做单个消息进行控制，TTL没有办法做单个消息的控制，对于Pulsor来讲，它可以做单消息的生命周期的控制，这样某些场景里就非常有意义，比如我的存储里放的数据消费掉之后，我判断它有问题，我不希望后面进行设计，我就设一个TTL被消亡掉，其它的数据保留更长的时间，这个是Pulsor的优点。再就是多租户的支持，想用Kafka做多租户，我是一个公司希望提供云化的能力，对于Kafka只能用多个Topic来弄，但是Pulsor天然支持多租户模型，它可以设置很多相关东西，所以这个好很多。从普及性来讲，差别也蛮大的，Kafka可以变成实时的行业的标准产品了，所以说基本上所有的公司都有Kafka，但是Pulsor现在还在大力发展过程当中，所以说很多企业现在有的在尝试，但是在国内的我了解到的Pulsor真正落地的企业还没有那么多，我们自己也在看这个产品。
流式计算的比较。
我是国内最早做spark的人之一。Apex号称比较高，因为Apex我没有做过深入的调研，和他们的团队沟通过，他们吞吐率也是比较高的。延时上讲，sparkstreaming到目前来讲虽然叫做持续计算，它的latency还不是最低延时，因为spark的技术模型设计基于HPV4的，再怎么着里面也得凑够一批才做处理，它的延时相对高。Flink和 storm延时很低，是流式计算开源的产品了。另外就是一次性，消息产品这个还是很关键的，我不希望重复消费，或者没有被消费到的，这里面这几个产品都支持。再就是社区活跃度，社区活跃度高，意味着大家做计算机属性的风险就低，因为用的人多，你出了问题找人更容易找到。国内的工程师还存在一个问题，就是英文沟通并不是特别好，国外做技术选型的设计活跃度会参照，但是他们更喜欢观察这个东西跟他自己的场景的完全的适配度，所以说在国外会有些技术会比较小众的被选择的。国内的话，大家可能倾向于选择人越多，越多的人选，是这样的正反馈。现在来讲spark毋庸置疑是活跃度最高的，也是选择性最多的。Flink在国内越来越多，下面会有一个嘉宾讲到他们用Flink做流式计算的，他们在电商领域里，会详细的介绍这个技术怎么用。Storm本身的社区活跃度一直比较高，因为它在传统上很多迅速的拿storm做东西，只不过它很多的限制，在很多企业大数据规模上，规模大的storm有很多不适合的地方，所以越来越多的公司用spark或者 spark streaming来做。Apex影响力很低，就不说了。
交互式形式很多，可以说现在很多的新的计算框架都期望解决交互式式的性能问题。spark一出来就火，替代传统，就是因为它提交性能处理更快。还有更适合做交互式的，像国内的京东，还有好几家公司都在做，京东在Presto上做了很多的改善的工作。还有Impala，它是一个开源的事件。当然Hive也能做，它的新的版本性能优很大的提高，最早期的版本Hive是慢性的交互式分析。一个华人在美国开源的东西叫Druid，这个是计算引擎。这里面还有很多的设备保障它的低延时，就是存储，怎么保障高校的交互式分析，一个非常重要的场景就是列存储，列存储可以精准的把我需要进行分析的列提出来，列里面很多的元素是重复性的，它存储的代价很小，能够保障高IO的把东西拉出来。列存储很多，Praquet，传统的Hive的Orcfile，小米投入很大精力的Kudu，它不仅仅是存储还是分析殷勤。还有解决分布式异构存储的，以及内存加速的华人公司做的Alluxo，也是最近这两年非常火的。
还有一个就是更经典的在企业时代就存在的，然后逐渐的开始进一步往前走的MPP数据库，像Greenplum，像惠普的Vertica，包括国内一倍出来的团队发展非常不错的Kyligence。还有俄国人最近做的非常有特点的做MPP的交互式分析数据库就是Clickhouse，国内很多的在尝试。
下面是一个常见的架构。这应该是大部分公司里采用的类似的架构，前面是不同的数据来源，中间一定会有一个消息总线或者选Kafka或者选Pulsor，左侧你可以根据自己的选择，低延时用Flink，如果没有特别在意延时，可以选择spark streaming。或者延时再高一些，能接受10分钟级别的可以用spark，这个时候你的数据流式把它存在列存储里，Presto，也可以存到MPP数据库里，也可以放到云上S3上，紧接着用交互式分析的框架，做交互式分析，这样企业大数据站能够保证既实现流式实时统计的结果或者预警，也能够支持你交互式的深入的洞察和分析。
趋势是什么。人的欲望无穷的，总是想要的更多。这么多数据产生，希望这些数据更快的产生价值。现在的趋势是越来越实时，能够更快速的处理，前面是分析的，现在的实时的机器学习越来越多，更快，还有就是更智能，期望更多的去把预测能力加到实时里去，帮助做决策，这样的话人就可以真真正正的利用大数据带来的价值去支撑自己的业务发展。
今天我这儿就差不多分享这么多，因为这里面很多细节的东西我没有过，很多实践的东西也没有讲，后面几个嘉宾，网易的，苏宁的，还有一个老朋友在网易梧桐待过做实时推荐的，他们对针对自己的业务场景来讲怎么用流式计算和交互式分析解决业务的问题。我们公司也在做相关的东西，但是我希望让嘉宾讲的更透一些，我就没有牵扯太多的细节。
我这么多年一直做技术，喜欢技术交流的，所以做这个出品人，也是希望有更多的同仁来去就技术进行交流，看看整个大数据行业里面发展的趋势，以及我们自己怎么能够在这个里面去跟上时代，贡献自己的东西。
.png)
