从连接到智能
我们都说现在是移动互联网时代,移动互联网时代我们随时随地能够上网,面向连接的革命诞生了很多有意思的应用,包括滴滴打车、外卖,这些都是在连接的时效性基础上做的应用。在有关于连接的革命以后,下一个阶段就是面向智能的革命。滴滴打车这样的场景未来会越来越智能,当然百度外卖号称现在在怎么送外卖这个事情上已经有一些智能,但这些只是开始。每一个应用会沉淀越来越多的数据,它成为这些数据唯一的 Owner。大家应该意识到一点,围绕着数据的深度应用让 App 变得智能,这件事有非常大的空间,无论你在什么领域。在我看来,这个智能不是云计算厂商或者大厂玩智能,未来所有的 App 都会玩智能。
在十年前,大家听到「云计算」,大部分人觉得是不靠谱的,全球第一个云服务也就是 AWS 对象存储,07 年刚刚发布,国内没有人知道,那时候的「云计算」概念虽然已经产生了,但是大家对云计算的认知非常不清楚。当时很多人会把它和网格计算的概念关联起来,而网格计算的概念昙花一现,最后消失了,大家认为云计算是新瓶装旧酒,是网格计算。但在今天看来,云计算本质上是一个 IT 的革命,把 IT 的交付方式由软件变成了服务,这是一个非常巨大的变革。这个变革背后的推动力其实是与移动互联网的兴起有关的。移动互联网的兴起意味着大量新兴机会的涌现,大家拼命地都要跑得更快。这些新兴的公司选择合作伙伴更希望是服务的合作伙伴,而不是软件合作伙伴。软件外包失败的概率是很大的,但是云计算解决了底层基础的 IT 技术外包成功率的问题,这也是云计算兴起的根源。
今天我们听到很多公司谈智能,忽悠的成分可能多于实际。而大部分公司认为智能跟自己没有关系,但是我认为接下来十年智能是非常重要的事情。
智能为什么会兴起?大部分的公司接下来十年都会开始充分利用互联网这个生产力工具,把他们的业务从线下搬上了线上,这意味着他和客户的连接其实是越来越数字化的。所谓的数字化,是指所有的沟通过程都会被记录,这种被记录的过程其实是很可怕的,因为你对用户前所未有地了解。但是如果让这些数据躺在你的计算机里或者删掉,意味着你相比以前纯粹地把业务跑在线下没有本质的进步。将来各行各业的竞争一定是面向数据的竞争,数据累计得越多,你对用户越了解,你对用户行为的挖掘,通过智能的提取,你会让 App 越来越具有独特性。前面李玥介绍了 Linkedin 如何使用数据,那是非常好的一个案例。Linkedin 本质上来讲是一个猎头公司,虽然它比很多大家认知的猎头公司要牛多了。但在本质上来讲,它是颠覆猎头行业的,新的猎头和老的猎头效率差距无比巨大。Linkedin 仅数据产品相关的团队就有 150 人,这是很恐怖的数字,可以看出硅谷公司是怎样的重视数据。
企业面临的挑战
- 观念带来的挑战。我们作为一个云计算厂商来看,多数公司的数据都不愿意存,认为数据是负担、是成本。但是在未来十年面向智能的时候,你应该认为数据是资本、是财产。这个观念的转念是非常巨大的。中国公司数据仓库存数十 PB,会觉得每个月要花掉好多钱。多数公司认为数据是成本,这是观念的挑战,可能也是未来最大的挑战。
- 数据产生价值链条长。不知道数据怎么用,或者没有支撑的数据平台。对于很多公司来说,把数据变成数据产品的链条是非常长的。整个数据从埋点、采集、分析、形成一系列产品,整个链条涉及的部门和工种非常多。涉及到业务部门、数据平台部门、数据分析与数据产品部门,而后又回到业务部门作用到线上,这个周期非常长。这决定了要让数据产生价值很困难。
- 多元化的场景。不同的公司业务场景不同,导致我们的数据产品很难用统一的模式产生。这与七牛的非结构化数据相比非常明显。七牛的数据是图片、音频、视频,围绕这些富媒体为存储的核心对象来构建场景,它的应用场景非常集中。非常集中就是说可预测性非常强,虽然我未必知道你的 App 是做什么的,但是我很清楚你的图片是用来做什么、你的视频用来做什么,业务场景比较容易清晰地呈现。但是大数据产品的业务场景非常是多元化的,不同的数据产品,面向的场景很不一样。
七牛大数据平台 - Pandora
- Pandora 是什么
Pandora 是一套数据采集、存储和分析为一体的 PaaS 平台,围绕着富媒体的业务场景构建,用户的各种业务场景我们都能够直接找到对应的解决方案。我们对 Pandora 的定位是希望它是一站式的数据处理服务,能够开放性地为七牛的客户解决他希望的大数据相关的业务场景。
- Pandora 有什么
图 1
如图 1 所示,第一部分是 Pipeline,其他部分是围绕 Pipeline 协同的。另外,有很多和 Pipeline 相连的部分,包括前面演讲介绍的 Kylin 也可以是其中之一。我们现在内建支持的东西包括七牛自己的时序数据库 TSDB、日志搜索引擎 LogDB、对象存储服务、关系型数据库、离线计算服务等。
- Pandora 产品架构图
图 2
图 2 是 Pandora 的产品架构图。其中 Pipeline 是一个数据总线的概念,数据通过 Pipeline 进来,打造一个临时储存数据的空间,比如我可以定义 7 天,即原始数据点可以在 Pipeline 里面存 7 天,然后数据经过变换,比如聚合成 1 分钟或者 1 天的数据,对它变换以后进入到另外一个 Pipeline 的空间。为什么叫 Pipeline?它把建立数据和数据变换进行串联,这个串联可以是任意级别的。数据在 Pipeline 里流转以后,适当的时候会导入到分析引擎,这些分析引擎是多样化的,同时还可以导出到 Kodo + XSpark(七牛对象存储 + 离线分析引擎)、LogDB(类似ElasticSearch,日志搜索引擎)、TSDB(时间序列数据库),以及其他服务等。
- Pipeline——数据总线
什么是数据总线?企业内部的数据都经过数据总线,数据总线的数据想流动到哪里都可以。数据接入,数据来源可以多样化,可以来自业务,可以来自日志数据、监控数据、实时数据等。这些数据进来以后,最后会通过数据的变换,Pipeline 可以认为是一个实时计算,它可以定义一些数据的变换,再去把一个 Pipeline 或者多个 Pipeline 里面的东西去聚合。最后,这些数据导出到 TSDB、LogDB、Kodo、MySQL/MongoDB 等。分析引擎在我们看来是非常多样化的,会跟你的需求密切相关。我们认为,你要抽象一个大数据的产品,最重要的是要抽象出数据总线。
- Kodo+XSpark——离线计算
图 3
为什么是 Kodo (七牛对象存储)而不是 Hadoop HDFS?这是因为我们认为 Kodo 比 HDFS 做得更好。首先,Kodo 对元数据的支持比 HDFS 要好的多,七牛的 Kodo 对象存储支持那么多的客户,我们很多客户一天就是几亿个文件进来,Kodo 对象存储的规模绝对不是 HDFS 能够搞定的。另外,七牛的对象存储能够支持小到只有 1 个字节、大到单文件近 TB 级别的规模。其次,Kodo 比 HDFS 的成本低得多,HDFS 默认会有 3 份数据,而 Kodo 将存储冗余度从 3 副本降低至 1.14 副本。所以站在七牛的角度来讲,我们没有必要再去基于 HDFS,而是让 Spark 去支持七牛的 Kodo 对象存储。
XSpark 是七牛基于容器云打造的 Spark 服务,支持非常快速地创建集群,极其简单地维护集群,极为容易地对资源进行伸缩。
TSDB——时序数据库
图 4
TSDB 是我们自己的一套时序数据库,可以通过各种 SQL 查询,支持高速读写,十分符合实时监控的场景。值得一提的是,我们定制了 Grafana,使得 Grafana可以直接对接 TSDB,使用起来非常方便。
* LogDB——日志搜索引擎
LogoDB 除了能够提供海量日志的存储与搜索,同时还支持对日志索引进行时限的限制(retention)。LogDB 对运维人员定位问题是非常有好处的,如果没有这种数据平台的话,我们可能要用 awk 或者 grep 这样原始的指令来查找问题,但是用 LogDB 可以协助快速地定位和解决问题。 大部分日志数据的搜索场景,基本上是短期的目的,无论是出于运维的考虑还是客服的目的,基本上把日志索引建到一个星期左右就差不多了。但是开源的搜索引擎不是面向这种场景,它需要你自己去做一些日志索引的改造。
- Pandora 的基础逻辑
没有一个数据分析引擎可以解决所有的数据分析需求,能够统一实现的是数据总线(Pipeline),管理数据的流动过程。
每个数据分析系统做好它关注的一件事情(而不是做越来越多的事情),如果输出还需要进一步处理,尽可能让它再重新流入到 Pipeline。
每一个分析系统分析的场景不一样,它背后的分析结构是不一样的,我们需要每一个系统只关注一小块,这样可以足够的解耦。整个系统最核心的就是 Pipeline,把大数据的各种系统进行串联。
基于 Pandora 的应用场景
- 场景:视频直播的质量运营
我们关心的维度:直播质量的实时报表、日志搜索、各 CDN 厂商的质量评估、异常情况的告警。很多直播的平台都是请了主播,这些主播特别贵,一旦出问题就是大问题。大家可能会觉得这只是万分之一的概率,但是万分之一到他请的主播上就是大事,所以他会有很多面向个体分析的场景,所以需要日志搜索。站在更高的维度来讲,每个直播的需求方都会有多个 CDN 厂商同时提供服务,直播平台希望这个时候能对 CDN 厂商进行质量评估,也会有一些人提出更高级的需求,比如对异常情况预警、自动触发流量调度等。
- 直播质量的实时报告
图 5
直播特别关心用户看到的第一屏的时间,用户发起直播到看到第一屏的时间我们叫首开时间,这些我们会产生一些相关的报表,并且是实时的。如果出现问题了,我们会看到针对不同的直播 CDN 供应商的质量考量,如图 5 所示。
图 6
卡顿率也是直播质量考量的一个维度,如图 6 所示,我们可以看到关于卡顿率的热点图。站在全国的维度来看卡顿率,图中越红的地方表示卡顿率越高,质量越差。
- 日志搜索
图 7
日志搜索主要是面向客服的场景,比如说某一个主播有卡顿,我们需要找到这个主播相关的条件去搜索,最后把服务端甚至客户端即 SDK 端报上来的数据整合,来看问题到底发生在哪里。
我们用了什么
基本上把 Pandora 的服务都用了:
1. Pipeline: 数据总线、对数据做基础的聚合(1 min,1 day);
- TSDB:实时数据分析;
- LogDB:日志搜索;
- XSpark:高级离线数据分析(各厂商的质量评估)。
以上是我演讲的内容,整个 Pandora 的定位是一站式、开放式的大数据平台。谢谢!
Q:数据类型有很多种,我们公司目前仅仅是做日志分析。在收集数据的时候,可能会关注哪一部分的数据?
许式伟:这和需求有密切关系。你的分析一定是跟需求相关的,比如说游戏,你希望分析道具相关的,你就需要把道具相关的数据导到平台里面。
Q:数据来源可以是多方面?:
许式伟:对。埋点部分是没有办法解决的,这是要到业务系统中去做的事情。
Q:这个产品的定位,会考虑部署到企业内部?因为这个数据很多用户可能对数据比较敏感,希望用你这个产品功能,但是不需要把数据放到上面?
许式伟:这个我们私下聊吧。我们是可以支持部署到客户 IDC 的,但是是有条件的。我们认为云计算最大的变化是由软件变成服务,所以我们希望 Pandora 的发布形态不是个软件。在这个前提下更多细节可以再讨论。
技术交流,请加微信: jiagou6688 ,备注:Java,拉你进架构群