论坛1 | 数据时代的技术与应用 孔淼 「诸葛io提高企业数据分析效率的大数据实践」



  • 时间: 2016年7月28日
    发言人: 诸葛io CEO 孔淼
    主题: 诸葛io提高企业数据分析效率的大数据实践


    大家好,诸葛io是一家数据公司,很多人可能会问为什么要做数据平台呢?所以先给大家看看数据平台的发展,从1990年到2016年,数据平台经历了几个阶段的发展,我们诸葛io处在什么样的位置以及我们为什么要做这件事。

    我们认为1990年到2016年的大数据平台经历了三次浪潮。第一波浪潮,在座很多人都没出生,那个时候软件都不是消费级的,而是企业级的,很少人见过DOS下的财务系统,当时就已经出现了数据分析的概念。企业级更多的是以KPI的角度,抽取少量结构化的数据。集中式的软件时代,当时的存储非常贵。比尔盖茨说,32M就能存储整个世界。当时的代表企业就是SYBASE、ORACLE,处理非常稀少的结构化数据。

    0_1470379084397_2016-8-5-19.png

    第一波浪潮发生到一定阶段时,也代表着互联网诞生到爆发的过程。从PC消费级,到网站很火的2000年左右,再到Web2.0、移动互联网、各种移动设备、智能硬件、VR、AR、五年后的智能汽车等等更多的智能设备。互联网渐渐地从信息化变成服务化。如果认为2010年是一个门槛的话,2010年前主要是四大门户,垂直网站、IM、社交网络、内容平台,视频直播。2010年以后基本上就是外卖、打车这样的服务。信息化变成服务化以后,产生的数据量越来越大,传统服务行业的数据都会传到平台上来。

    0_1470379125331_2016-8-5-20.png

    第一波浪潮面临的问题是数据量越来越大,原来的架构会面临很大问题。同时出现的机遇就是存储成本越来越低,计算能力越来越高,产生的数据量越来越大。这个时候就带来了第二波浪潮,以Hadoop为代表的大数据,还有最近很火的Spark。这是一个典型的架构,我们叫数据的Agent,不管是用Pull或Push的架构方式,把数据集中到一个平台上。

    在数据爆发的时代,第一要素是把它采集整合存储起来。因为数据量很大,传统的关系型数据库就面临很多问题,这个时候就流行NoSQL、FPP、SVS等分布式的存储方式。问题在于数据采集上来以后,它们其实是孤岛,并没有打通。这个时候的时代特点是存储很便宜,随处可见的大数据。典型的就是Hadoop、KafKa这样的平台,类似Adobe、Oracle,还有百度、友盟等一系列统计类的平台,背后都是这样的平台在做处理。

    这个时候遇到一个问题,在2012年以后,中国的人口红利在下降。过去人口红利上升并且中国的GDP增长率非常高,迅速成为第二大,意味着不用做很多数据分析,只要随波逐流就可以享受到互联网及经济增长的红利。是一个流量的时代。但是,随着中国经济增长的下滑,包括2012年流量开始收紧。这个时候就变成了一个存量的时代,你需要通过数据分析。因为你已经没办法买流量获取更多用户,而是要洞察数据,维护现有用户。

    第二个问题,是信息化到服务化带来的。用户的要求越来越高,就需要进行分析。过去不做分析的时候,把数据采集起来放在那里就可以,偶尔进行分析。现在真的要分析数据,就要排着队找BI团队进行分析,业务的人要把它变成脚本,或者写一段SQL。你就不断要去提需求,催结果。有些程序员一个小时能做完的事情,可能晚上才能给你。你一次性需求提得不够,可能还要一两天才能搞完。这样一来,分析效率就非常低下。

    0_1470379170016_2016-8-5-21.png

    这个时候就带来了第三波浪潮,数据不仅要存下来,还要做决策和洞察。在国外,DOMO和Looker这样的公司就带来了第三代的概念,即DI(Data Intelligence)。DI和BI区别在哪?BI是基于企业的业务模型,采集数据,构建一套架构,支持团队分析。而DI对整个业务架构都不透明,是端对端的,可以让不同业务人员直接参加决策,DOMO就是如此。参与决策很重要的一点,不同的人比如CEO、市场销售,不同的行业如电商、网络社交,大家关心的指标都是不一样的。电商关注的是复购留存,阅读类的是阅读留存,工具类的关心的是使用情况,CEO关注的是工作核心指标。大家关注的东西都不一样。这样的平台要求更高的是如何形成行业洞察。但第二波浪潮诞生的这些工具,比如友盟等提供的都是一样,都是DAU留存。

    LOOKER公司就认为,到第三波浪潮的时候,要把数据变成基础技能。在做任何事情的时候,应该是data agreement。讲了这么多过去的历史发展,本质上就想表明一点,诸葛就是第三代的。诸葛io不是纯粹的tools,而是可以帮大家做很多业务上的洞察。

    0_1470379206815_2016-8-5-22.png

    简单来讲诸葛io是一个客户中心化和分析去中心化的数据智能平台。分析什么数据呢?首先,可以对安卓、iOS、网站、server API等SDK进行采集数据,进行一些独立的用户行为跟踪,并且我们有非常灵活的事件模型,可以把这些行为用户标签化。这是什么意思呢?传统的BI大部分都只是做一些agregation,比如像主流的BI服务都是做一些统计。诸葛io可以根据用户体系进行独立行为跟踪。比如你是一个APP、网站,你有账户体系,那我可以给你一些接口。因为我们是灵活的事件分析,我们不只记录用户登陆多少次,可以允许传输ID和字段。这样进行分析的时候可以帮你找到背后的人是谁,而且可以对业务的字段进行整合的交叉分析。

    灵活的事件模型是什么样的呢?一个按钮,如果用过去的包括企业内部的统计平台,这个按纽可能就是几个名字、发生人数、触发次数等等。但在诸葛io上,因为我要对业务人员进行分析,所以我要灌输业务的概念。举个我们的用户例子,火辣健身。上面有查看课程,包括分类、器械、部位等。诸葛io的灵活事件模型可以做出很多细分的条件。实际上我们是用户信息和用户行为属性交叉的多维分析平台。

    0_1470379251124_2016-8-5-23.png

    0_1470379276672_2016-8-5-24.png

    什么是客户中心化?我们来看看这张图。在过去的互联网时代,从流量到用户到收入,我关注的是流量带来多少用户数,并不关注用户是什么状态。我可以自豪地说我有几千个、几万个甚至几亿的用户。但是我们把地球看成一个APP,有多少用户就像地球上有多少人一样。地球上每年出生1.4亿人,目前70亿人活在世界上,已经累计死去1080亿人。其中出生意味着新增,70亿人意味着活跃,累计死去的人意味着流失,人活七十古来稀则意味着留存。那么传播就是进行繁衍。这样可以对应一些概念,用户数、活跃用户数、留存率、病毒系数及传播周期等。我们常很自豪地说我有几百万用户、几千万用户,其实没有太大的意义。

    0_1470379304248_2016-8-5-25.png

    当我们把新增用户的概念变得更加细微一些,可以清晰地看到用户的生命周期,从获取新的用户,到有多大的留存、传播,最后带来多少收入,这个过程应该数据化和清晰化。这个就是我们去年提出的AARRR模型。诸葛io是最早的一家把growth hacking引入业务的数据平台,并在15年3月份上线。所谓的客户中心化分析就是从用户来到你这里开始,再到最后的生命周期,可以用数据跟踪好。这是数据平台很大的特点。

    诸葛io的平台上,用户历史访问的行踪、做的所有事、数据的字段、环境信息,都可以整合起来。任何一个过去的统计指标,比如友盟,你只能看到用户数是上升的。但诸葛io可以看到是上升的数据是哪一部分人带来的指标上升,下降的数据是哪一部分人带来的,通过一个页面每个人做了什么事。通过筛选即可看到。

    分析去中心化是什么概念呢?刚刚讲的是把一个用户能够神秘化地采集他在你的数据库的字段,采集他在app、网站包括JS、日志里的行为都能够整合在一起。那接下来要做分析。怎么做分析?我刚刚讲过诸葛io是第三代,第三代意味着我们要懂业务人员要做什么。第一层就是要引导你取出个性化的指标看板。这些不是固定指标,而是根据每一家进行个性化配置,非常灵活。每个行业会有一个通用指标,所以我们会给一个基础部分,再进行修改。

    0_1470379370777_2016-8-5-26.png

    0_1470379390986_2016-8-5-27.png

    0_1470379404684_2016-8-5-28.png

    0_1470379425919_2016-8-5-29.png

    0_1470379451014_2016-8-5-30.png

    比如阅读类的应用,关注阅读留存、阅读分布、阅读转化率。电商关注新订单数量、人均订单数、重复购买率。这只是一个示例,真实情况会比这个复杂得多。产品部门会关注功能活跃比、新功能留存率、注册转化率、购买转化率、人均访问时长等等。对于运营端关注SKU是什么,最热门的SKU是什么、不同商品的转化率。对于市场部门,反映的就是广告投放转化率、不同渠道新增转化。所以企业内部各部门的需求是不一样的,过去的方式是去找程序员,找分析师,效率非常低下,不能提前洞察数据。另外一方面是只给看结果还没有意义,还需要可以做分析。所以需要找一些分析师或者coder,但coder是怎么做的呢?比如滴滴的业务人员想查看抢红包打车的人,其实是把逻辑转述成一些脚本的逻辑。但背后这些逻辑是固定的,无非是进行漏斗分析、留存分析、事件分析、用户群分析、多维交叉分析。用户群分析就是记录用户什么时候来的,做什么事,没做什么事,有什么特征等等。诸葛io把它变成一个交互式的,用户一点击就变成一个SQL的查询。事件分析就是找最热门的SKU、最热门的分类,过去也是要写SQL跑查询。现在的核心是找两个纬度进行交叉,特别是我想看特定人群的时候,再跟用户群进行交叉。诸葛io的本质就是这样。漏斗是什么?漏斗就是看过程的转化率,代码逻辑变成几步简单的操作就可以看到。

    0_1470379490060_2016-8-5-31.png

    举个例子,这是用户群分析,我想把用户分成观光游客和常用游客。和火辣健身一样,有一个训练打卡。这些逻辑就变成简单行为的触发条件交叉。

    还有漏斗分析。电商哪个分类的功能转化率是最高的,在诸葛io上几次点击就可以。不管你想要的是来源、分类、SKU等各方面都可以。而且,这些漏斗还可以随意配置,极大的解放了业务人员的分析能力。

    0_1470379515599_2016-8-5-32.png

    业务大家都已经理解,就是客户中心化和去中心化,那么架构实践是什么样子的呢?先看我们的业务架构。诸葛io最重要的是分析平台,什么叫分析平台?分析为中,左边是data source,你可以分析任何数据,微信数据、app数据、网站数据、加密数据、买来的数据、甚至是一个excel。那么右侧是进行价值分析。价值无非是从四个维度进行交叉。第一个是行业,有互联网行业、能源行业、医疗行业、CT等。互联网行业又有具体细分电商、社交等。第二个是不同角色,比如CEO、销售等。不同的角色分析的内容也不一样。比如可以思考一下美团的黄鑫关注哪些指标?淘宝的每个部门关注哪些指标?其实每个人的OKR不一样,KPI不一样,职责不一样,所以关注的指标也不一样。第三个维度是部门,市场肯定是关注市场活动投放,转化率带来的用户。运营关注的是现有客户的黏性、参与度。产品部门关心的是这些功能的留存、使用情况,而现在大多数产品都是拍着脑门决定事情。技术关注有没有出Bug、可用性怎么样。不同部门关注的指标不一样。最后还要确定分析目的,是要做客户的挽回,还是要做线上营销推广。这四个维度相加起来,就组成一个大家看到的指标,所以数据分析很复杂吗?本质上就是这样的过程。这个分析的背后又复杂起来了,方法论不一样。我们讲到用户收入是一个方法论,我们讲AARRR系统背后构建的时候,如何去利于业务分析模型,是非常灵活的。再往后,分析性过程还可能做一些应用场景。比如个性化推荐、数据挖掘。从数据源到分析的整个架构是非常灵活的。

    诸葛io最底层的数据源来自于安卓、iOS、JS、Server,中间这一层是负载均衡和数据接受服务器。诸葛io是SaaS服务商,所以我们对数据上传的要求非常高,包括可用性,我们现在平均是在10ms,可用性基本在99.99%-99.999%之间。上传完数据后,我们用标准的Lambda架构。Lambda架构的核心是把实时查询,分为Batch Layer和Speed Layer,其实是历史数据,它会做一些agregation,用一些格式的存储查历史,每天新增的数据通过Speed Layer,到 Query Layer,也就是查询这一层,把查询的结果做一个merge,这就是标准的Lambda架构。它最重要的是对消息队列的分析和查询。所以Lambda最通用的就是Kafka即消息队列,从底层收集的各种数据源进行处理。这时候你上传的并不是最终数据,可能是格式化的数据,要把它统一经过ETL处理,ETL是Extractor-Transform-Load,转化清洗,把脏数据去掉,剩下的数据会有一些格式,再进行简单的查询merge。ETL过程后把数据扔到消息队列里。消息队列Kafka是一个典型的多组消费者的模型,就是有不同的消费组,能做不同的处理。所以其实很适合多应用子系统。所以你看上一层,workload有做实时统计的,因为实时的数据做查询的话要求非常高,所以肯定不可能,所以我们用Redis做一些实时的计数,得到访问的人数多少、总量是怎样的。还有数据仓库datahouse,这层用Hadoop的东西肯定也不行,因为Hadoop是高延时的,这个时候要实时快速得出结果。第三个是数据索引,用户快速查询的时候要做索引。这个地方我们用的是Elasticsearch。那第四个数据备份也很重要,因为对于SaaS来说,数据安全非常重要,包括数据的可用性。所以要做备份防止数据出问题,计算出问题的时候要回溯。数据处理完以后要进行应用,我们有统一的数据访问层,不管是内部人员做内部分析调用,还是外部客户访问做查询。数据访问层就是诸葛io网站、内部服务、数据挖掘、开放API。诸葛io认为所有的数据都是客户的,客户可以通过API拿到所有的数据。

    所以总结一下技术,负载均衡这一块用Nginx+Lua,消息队列用到Apache Kafka,我们用Lamdba、用Spark、用来做实时统计和分析,这会涉及到另外一个团队主要还是基于Spark的那个Samza,然后Elastic Search会做一些索引,快速地进行检索。Hadoop、HBase会做持续化的存储。再往上走就是实际的应用,就是hashdata简总(简丽荣)他们所做的工具。

    0_1470379578363_2016-8-5-33.png

    我们第一次上线的架构,数据分析平台最大的门槛在于它的复杂度。创业的时候会面临很多门槛,比如O2O的核心门槛在资源上。社交类的虽然技术复杂度不是那么高,但做直播对streaming流式处理的要求很高。都有不同的技术壁垒。那么数据平台的技术壁垒在哪儿?核心在于它的技术复杂度。我们做好一个数据平台需要哪些人?你首先需要安卓、iOS、JS、Server几个平台,Python脚本,能写SDK和采集器的人,姑且只算一个人。还需要有人做服务端接收这些数据的。需要做有人能做ETL。需要有人负责数据仓库做一些逻辑设计的。还需要后端的工程师可以写J2E的网站。你能够Access这些网站的数据。接到数据之后,还有数据访问层。还需要做可视化。还需要前端的设计师资源。还需要有人做分析模型。这个时候如果还有数据挖掘团队。这样就需要9个人,诸葛的整个团队构造就是按照这样的一个结构区分的。但是,我们第一次上线的时候只有5个人,怎么做的呢?没有JS、安卓工程师,都是我写的。几个人凑起来的第一段架构是非常简单的。是一个Nginx+HttpServer,为什么不是Nginx+Lua,是因为我们服务端的负责人还挺厉害的,原来上大的,写过很多代码。Kafka是我们一个在美团和阿里呆过的工程师,我们一起写的ETL,当时还没有引入Lambda,还没有引入Spark Streaming的处理平台。就是通过一个个JAVA进程去读一个topic,然后写入数据库。这堆Java有做实时处理的、做数据库load、做数据清洗的,做数据备份的。还有python脚本,因为Java工程师真的写不过来了。数据处理就是一堆人写出的代码。存储就是快速的拿Redis。要想做数据公司创业,还得有钱。因为你得买一堆服务器。当然你可以用青云,可以按秒计费。我们当时很穷,Redis内存不够了,从网上发现一个做SSDB的,跟Redis的协议一模一样,但它是基于磁盘的。我们就赶紧用SSDB顶上去了。数据的查询性能,当时纠结要不要做仓库选型。当时还没有那么大的项目。大多数企业的DAU,上千万的DAU,上百万的DAU,基本上都是一个公司加起来的,接近一百万DAU的公司是很少的。一百万这个量级,像HashData是PB级的。但很多公司都还只是TB级别的。使用的还是社区版,当时我们还不能update,很麻烦。当时用户量不大,load的速度只有30M/s。一想还是先顶上,让程序能够先跑起来,因为是创业,因为我之前也用过ES,有些索引的东西可以马上上手。

    结果问题出来了。诸葛io爆发了,暴走漫画、易车、优信二手车、斑马骑士、Enjoy都相继接进来,爆发量直线增长。然后系统一直报警,一直处理问题。数据接收的非常缓慢,用户数据打点上传不上来,这是致命的问题。第二个问题是这一堆东西真不好管理,一个工程师离职了,维护起来就特别麻烦。还有这五个关键点都要保证可用性。这是简单的流式架构,还可以画一个DAG架构。这么多公司进来之后,真正有百万级别的DAU公司进来了,有一个视频的客户特别厉害,是海外的客户,有上亿的数据量。第一天就达到800万的DAU,我们就挂掉了。我就把它的海外系统停掉了。接进来以后,我们处理不过来,这些都是当时踩过的坑。

    最大的就是三个坑。一是数据上传延时很高,当时用的就是https,在查端口的时候,它的连接能力是很有限的。这个时候就需要再加Nginx服务器的,因为Nginx背后是load-balance,Nginx是在握手前,前面就要加LVS。所以我们又升级了http/2。当时连接超时非常严重,平均的请求是过百毫秒,我们又换了Nginx+Lua。早期工程师设计的时候稍微有一点问题,每一次请求都需要进行一次返回。实际上客户作为一端,上传数据的时候只要保证上传完之后这个count是200,不应该等待写一个response的结果。我们当时就觉得不应该等这个状态,所以我们就换了Nginx+Lua,应该是无状态的。我们就把httpserver去掉,接收到核心数据以后往Kafka里扔,这个时候是可以返回的,不用写返回等待处理。当时我们的SQL server,我们还做解密,加密。我们的客户端传上来之后,网络上传成功,不用担心解密后还要把字段取出来,不仅如此,用Nginx+Lua就很简单,接收数据以后就扔到Kafka,当时我们的并发连接不到一万,现在压测上十万都没有问题。

    第二个问题就是数据处理Java进程不宜管理。Hadoop的本质是一套Yarn平台,是HDFS存储框架加一套计算框架,SAMZA就是把HDFS替换成Kafka。其实是因为我们的核心是做数据处理。当时有人问我们是不是支持Spark。Spark虽然支持Java,但主要还是用Scala。首先我作为企业管理者,还是要考虑到后续招人的难易度。如果这个语言是普适性的,对公司扩展会更好。其次因为我们是在ETL做一次处理,Spark是在HBASE做持续的数据处理,所以我觉得SAMZA还是很适合我们的。第三是因为SAMZA和Storm、Spark对比起来是真正实时的,Spark还是micro batch,即有微小批量的。但SAMZA还有一个缺点,至少一次,spark是exactly once,Storm是最多一次。什么意思呢?ETL处理的时候,会有一些异常。Samza意味着会重复,Spark会准确,不会有问题,而Storm最后可能会丢失。综合考虑,我们对数据的稍微重复的要求不是特别高,可以用来分析用户的转化率。

    第三个问题就是Infobright,刚才讲过数据越来越大,这个时候其实我们加了多路控制路由。但你会发现当用户的数量太大的时候,你的本质是要把它的数据进行分布式的分配。其实像hashdata就很不错。大家可以尝试一下这样的PaaS,我自己作为数据公司,这几层结构都玩儿过。但我相信未来我一定不会关心这些底层。数据公司更核心的是关注数据上的价值,我的运维工程师不应该每天维护集群、Hadoop这些东西。所以你可以看到类似hashdata他们都在国外有个产品叫reshift。SQL Server在DAU50万查询太慢的时候,同时可扩展性太差了,我们换了Green Plum。诸葛其实写了中间一个模块叫诸葛presentation,这是为了降低计算复杂度,还有提高一些PB级别计算的channel维度,做一些相关优化。

    0_1470379665224_2016-8-5-34.png

    架构V2的时候也很简单,但会比刚刚的更合理。第二层是LVS+Nginx+Lua,诸葛遇到的问题永远都是带宽不够。带宽要花钱。我们现在在这么大处理量的情况下一共只需要两台机器。所以Nginx+Lua还是很厉害的。消息队列、数据处理Samza,这个时候我们的团队已经成长起来了,大家会做很多。因为我以前做过ODA的分析,所以对这个有些了解。一开始我就很注重在data mining这块。我相信未来的数据尤其在人工智能上一定是自动化分析的。所以我们一直有数据分析技术团队在做这件事,而且已经有一些产出,比如自动化的分析报告,大家可以尝试一下。最后就是数据存储,我们换了一些Codis。尽可能保证每一个组件的可扩展性都是比较强的。然后换Green plum,最后我们把MongoDB拿掉,因为最开始我在做诸葛io的时候还想以免费的姿态想去收集一些用户数据,然后进行用户分析。后来我觉得应该把分析做透彻,而不应该放数据上。当时MongoDB存的是应用列表、标签类的东西,但是我不做这块了,所以我拿掉了。我只做核心的第一方的多维的数据分析。ES还是会用来撑起索引。HDFS支持Spark的,它是两套架构。我们也用HDFS,但我现在还是用S3。

    大数据架构没有那么复杂,核心还是那套东西。我相信在某个时机切入某些业务去了解这些问题的时候,或者某一天所有人都知道诸葛io的时候,你就很了解它的业务。如果我一开始就讲得太深,你都不知道我是干什么的。大家可以了解一下诸葛io是做什么的,诸葛在用什么样的技术,是不是很low的技术,你可以持续观察我们架构V3、V4的发展,也许可以看到诸葛io的成长。

    谢谢大家!


登录后回复
 

与 青云QingCloud 社区 的连接断开,我们正在尝试重连,请耐心等待