面向数据智能时代的大数据架构实践



  • 面向数据智能时代的大数据架构实践

    诸葛io 在上线的不到 20 个月里,经历了客户量从 0 到 10,000 的突破,月有效行为数据处理量超过了 100 亿。这期间,其研发团队面临过许多难题与挑战,同时,对于大数据平台的发展与架构也有许多的思考与沉淀。这些思考与实践,正是本文中要与大家分享的内容。

    第一部分:大数据平台的三次浪潮

    在正文开始之前,我们回顾一下 1990 年到 2016 年间,大数据平台经历的三次浪潮。

    第一波浪潮

    第一波浪潮起源于 90 年代,当时从计算机到软件大多还是企业级的,而数据分析就已经开始。

    这个时代还是集中式软件时代,存储数据的成本非常昂贵,所以大部分企业以 KPI 角度,抽取少量结构化数据进行数据分析。代表企业如 MicroStrategy、Microsoft、Oracle,代表产品也诸如 Sybase、Congos,这个时代能产生的数据有限,能处理数据的能力有限。

    第二波浪潮

    发展到 2000 年左右,互联网的兴起带动计算机和软件走向消费级,并且互联网成为基础设施,从以下三点带来数据的爆发式增长。

    • 网络带宽的升级优化,从 2G 到 4G,从拨号上网到光纤入户;
    • 围绕互联网信息化带来大量的数据产生,例如门户网站、社交平台、内容和视频平台等等;
    • 科技发展,从 PC 到移动设备到各种智能设备,都可以采集、传输数据。

    数据的存储成本越来越低,数据的产生速度越来越快,数据量越来越大,第一波浪潮时的技术体系已经满足不了需求,并且由于摩尔定律基础硬件设备和条件也在优化,处理数据的能力越来越强,这个时候带来了大数据平台第二波浪潮的发展。

    面临这样的环境趋势,第二波浪潮的需要解决的核心技术问题包括三方面:

    1. 越来越分散的数据需要集中采集处理

    数据采集集中大多是"Pull"和"Push"两种方式,但是收集方式、可扩展性、收集效率、消息队列等等都需要一些突破。

    2. 计算的可扩展性

    机器资源已经不是瓶颈了,所以如何能分布式计算,把计算的复杂度分散拆解是要解决的核心问题,比如算法上的"多项式拆分"到计算框架上的"批处理"

    3. 存储的可扩展性

    越来越大量的数据,导致效率越来越底下,所以为了保障访问和利用效率,可灵活扩展存储数据也是要解决的问题。

    这个阶段的大数据技术,陆续诞生了从 Facebook 早期开源的 Scribe、Cloudera 的 Flume、Linkedin 的 Kafka,还有后来的 Flink 等数据流处理框架,熟知的还有 Spark/Storm/Samza 等实时处理技术。

    在这个阶段似乎无人不提大数据,人人都喊 Hadoop,但是我们做到的是数据流处理和实时处理以及存储方式的突破和革新,而分析主体还是老的分析中心化方式,由 BI 团队或者数据团队驱动,集中式的制定 KPI,数据采集集中之后会按照 KPI 进行处理展现,如果遇到多样化或者探索性的业务分析需求,还需要 On-Demand(按需)去编写程序或者 SQL 来基于这些大数据平台获取结果。

    第三波浪潮

    发展到 2010 左右,互联网发展也从信息化走向服务化,创业方向也从之前的"门户时代"、“社交时代”、“垂直化门户时代”、"内容视频时代"走向了电商、出行、外卖、O2O 等本地服务升级。

    如果说面向信息化的时代更多的是基于流量广告的商业模式,面向服务化的时代更多的是直接面对客户价值变现的商业模式,或者说消费者服务,所以从行业发展来看,服务类对分析的需求也要旺盛更多,自古以来,电商游戏行业分析都做得比较好,不是吗?

    我们用破木桶蓄水过程来类比,到处都是水源的时候,并且外部水源流入率大于自身流失率的时候,更多思考的是抓紧圈水源而不是找短板,从 2000 年到 2014 年,流量势头猛进,到处都是用户,对于企业而言更多的思考是如何圈用户,而不是如何留住用户,分析流失原因。

    当外部没有更多水源进入,并且四处的水源有限时,企业需要的是尽可能修复木桶,并且找到木桶的短板。在 2014 到 2015 年左右,互联网流量红利也初现消尽之势,国内的经济下行压力也逐渐增大,就好比水源有限一样,企业需要更多的分析自身原因,提高各种转化率,增加用户的忠诚度和黏性,减少用户流失。所以分析需求开始逐步提升,各个业务部门都需要自我分析优化成本,提高利润和产出。

    过去企业更多面临的是由上而下的 KPI 中心化式分析,所以形成的是分析中心化的体系,基本上整个公司有统一关注的指标和数据看板,但是各业务部门的分析就需要单独处理了。

    数据分析其实从行业、角色、部门以及从场景而言,都是差异化的。

    行业上:

    • 电商关注的是购买相关;
    • 内容关注的是阅读相关;
    • 社交关注的是参与度相关;
    • 工具关注的是使用情况。

    角色上:

    • CEO 肯定关注的是整体、财务各部门的 KPI;
    • 市场 VP 肯定是营销相关的子项目 KPI;
    • 销售 VP 关注的是销售阶段状态和结果相关的指标。

    部门上:

    • 市场关注的是投放转化率等指标;
    • 产品关注的是功能留存率等指标。

    所以要更充分的满足分析需求,就需要从 KPI 中心化分析转向分析去中心化,也就面临着又一次大数据平台的技术革新,这也推动了大数据平台第三波浪潮的变革。

    第一、第二波浪潮更多解决的还是技术问题,第三波浪潮最重要的是要解决分析问题,但是分析的问题主要有三点:

    • 分析其实是行业经验的积累和行业经验的信息不对称;
    • 大多数公司缺少专业分析经验的人和能构建数据分析平台的团队;
    • 依赖数据分析团队集中分析的方式效率低下,需求会排队。

    这也就意味着第三波浪潮可能带来的更多不是通用的技术平台,而是更多深入的行业分析应用,所以在数据模型和数据仓库这一层的变革会更大,当然少不了的还是 Google 这样大鳄的弄潮,开源了 BigTable 带来的是以 Hadoop 为核心的第二波浪潮兴起,而 Google 的 BigQuery 其实也是代表了第三波浪潮的趋势。

    第三波分析浪潮带来了一个 DI 的概念,就是数据智能,不同于 BI 的是,BI 更关注基于业务收集数据、处理数据的过程,而 DI 更多关注的是数据对各个业务部门的决策驱动和应用。

    第三波浪潮下的大数据平台,会从分析看板开始,有各个行业下各个业务部门所关注的指标,并且业务人员可以灵活的配置,同时对于复杂分析下钻和数据探索过程而言,业务人员也无需 SQL 或者代码就可以直接通过交互式的查询组件进行自助式分析和配置。

    大数据分析的基础技术已经逐渐成熟,而挑战就是基于行业理解下构建合理的数据模型,以及多维下复杂查询的效率。

    第二部分:诸葛io 的业务架构实践

    先自下而上再来看一下我们当前诸葛主要的业务架构:

    1. 数据采集端

    诸葛io 现在提供了 Android、iOS、JS 等 SDK 和 REST 的 HTTP 接口来采集数据,SDK 和接口都提供一些面向用户的方法或者数据规范,其分析的数据主要来于此。

    2. 数据接收服务

    SDK 和接口采集到的数据会发给网关服务, 通过 API 对数据进行简单加工,添加一些环境信息的字段之后,发给消息队列。

    3. 消息队列

    消息队列会成为数据的集中处理中心,同时会对消息进行统一的加工转换和清洗,比如过滤垃圾数据,关联用户的 ID,加工用户的状态和标签,加工行为数据等等。

    4. 多业务处理

    数据进行统一的加工和处理完成后,会有多个服务器同时消耗和处理基础数据。主要包括以下部分:

    • 实时统计
      为了减少对数据仓库的压力以及提高数据处理的效率,对于一些基础指标,比如新增、活跃、触发各种行为的人数等等进行实时统计,写入到内存数据库中。
    • 数据仓库
      数据仓库是提供深入的用户行为、多维交叉分析以及行业分析模型的核心,所以底层的数据模型和加工的中间数据层主要是在这一步完成,完成后会写入到数据仓库底层的数据库中。
    • 数据索引
      为了提高数据查询和检索的效率,需要对一些维度数据生成索引,会写入到索引数据库中。
    • 数据备份
      原始上传数据以及中间清洗后的数据会做多重备份,达到一定程度的灾难恢复保障,会写入到文件中。

    5. 数据访问层

    由统一的数据访问层来输出数据,给应用层进行调用,这一层会封装一些分析模型和业务逻辑。数据访问层会分为内部接口和外部接口进行分发。

    6. 数据应用系统

    数据应用主要包括以下:

    • 诸葛io 网站
      网站就是 zhugeio.com 提供给企业客户交互式自助分析的平台,包括了丰富的功能。
    • 内部服务
      主要是 DevOps 和业务监控平台需要调用一些接口进行状态监控和跟踪,保障服务质量和稳定性。
    • 数据挖掘
      诸葛io 有算法组和分析组两支队伍会对数据进行一些复杂的挖掘和分析,包括:
      • 流失与预测分析
        • 行业模型和看板
        • 自动化的分析报告
        • 用户行为路径挖掘
    • 开放 API
      把一些查询封装成 API ,允许客户进行二次开发或者调用。

    诸葛io 的架构经历了两次迭代,目前正在进行第三次的重构,重构的目的包含两方面,第一次重构主要是技术方案的瓶颈突破,第二次重构主要是业务领域问题的延伸和拓展。

    架构永远是贴合业务的,从 2014 年 10 月开始研发,15 年 3 月份上线。当时需要让产品快速上线,验证想法,所以架构搭的比较简单粗暴。6 个工程师,完成了整套从数据采集到数据处理到网站到前端可视化的大数据架构。所以当时画的比较简单的架构如下:


    诸葛io 第一次上线的架构实践

    初次上线的架构在刚开始的一段时间内没有碰到什么问题。但是随着业务发展,诸葛io 的客户量逐步增加,甚至像暴走漫画、小影、墨迹天气等大体量的客户也陆续接入平台,这个时候考验就来了。

    下图是我们当时数据处理流的架构图,标出了三个问题点:

    诸葛io 第一次上线的数据处理流

    1. 数据上传延时很高。

    上传延时很高主要在两方面:

    • HTTPS 建立连接和加密验证的耗时。
      HTTPS 比普通的 HTTP 的三次握手还要多一个 SSL 验证的过程,我们上线时使用的是比较老的 Nginx,并且只有单 Nginx 的支撑,所以握手压力就会很大,所以虽然在系统参数调优上做了很多尝试,但是本质还是需要一次架构优化,所以选择了在 Nginx 前加了一个 LVS,把 Nginx 升级到最新版,并且支持了 HTTP2 的协议,并且扩展了 Nginx 的服务器数量。
    • 数据上传模块的设计缺陷。
      诸葛io 之前的数据上传模块逻辑是:客户端上传数据,服务端接收后会解压并且加入一些上传 IP、上传时间等字段,然后写入到 Kafka 消息队列中,然后返回给客户处理结果。

    其实这个过程是没必要客户端等待处理过程的,所以优化后的逻辑就是客户端上传成功后即返回。诸葛io 之前的服务端是 C++ 编写,优化后直接参考一些秒杀的高并发架构,选择了 Nginx+Lua,在无数据丢失情况下,单节点每秒并发处理完成数提高了 5 倍多。

    2. 数据处理流使用的是多JAVA进程方式

    诸葛io 在第一次架构过程中,对于各个子业务处理的都是独立的 JAVA 程序进行数据消费和处理,显然这种方式不利于后续的业务扩展和运维管理,有很大的隐患,所以改成了通过 Samza 平台的处理过程,选择 Samza 的主要原因是,处理的输入输出都是 Kafka,并且 Samza 的实时性也有保证。

    3. 数据仓库不具有可伸缩性

    诸葛io 的数据库选型一开始用的是 Infobright 的社区版,国内之前使用 Infobright 作为数据仓库的比较有名的公司是豆瓣,虽然 Infobright 不是分布式的,考虑到大多数 App 或者网站的 DAU 不会超过百万,并且 Infobright 的压缩和性能都不错,对于 SaaS 的早期创业公司而言,成本也会有保障。当数据越来越大的时候,加了控制路由,会分发不同应用到不同的 Infobright 中。

    但是随着业务发展的逐步突破越来越多的百万甚至千万 DAU 的产品开始使用时,自身还是要解决查询性能和数据扩展的问题 。

    从数据存储可扩展性和计算资源的分布式调用来综合考虑,诸葛io 选择了 Greenplum 平台。

    同时诸葛io 在数据处理上也做了一些技巧,包含两部分:

    1. 预计算

    对于互联网用户分析,大多数是分析特定行为,特定类型(新增/活跃),特定平台(Android/iOS/JS),特定渠道的用户,所以这里其实有一些集合计算法则和技巧可以利用,诸葛io 基于这个写了一个数据预处理的服务诸葛 PreAg。

    2. 模型优化–业务维度分层

    很多人在设计模型是过于去找逻辑对等以及对象关系,但是其实从应用场景来看,比如同是环境的维度或者同是业务的维度,其实在查询场景上并不是同频率的,有的时候为了一些极少数出现的复杂查询做了过度的抽象设计,这一点做了很多的优化。

    结合上面的问题进行了第一次架构调整。

    架构 V2 比第一次架构更合理。除了上面提到的,把中间不易扩展的部分都替换成了一些支持分布式的技术组件和框架,比如 Redis 和 SSDB 都换成了 Codis,比如文件换成了 S3/HDFS 。

    写在最后

    上面是前两次架构的经验分享,诸葛io 现在也在第三次架构优化的过程中,这一次更多是业务领域的突破和延伸。

    在过去一年中,作为一个 SaaS 公司,诸葛io 面临着各种挑战,不同于私有部署的资源分散,SaaS 公司满足业务的同时也需要保障服务质量,任何一个小的更新和优化都需要多方面的检查和合适。上面提到的只是一些能结合业务有共性的优化的问题,团队其实遇到的问题要远远不止于此。

    底层技术上,从一开始底层硬盘的存储优化,到系统参数调优,包括上传服务器、数据仓库等底层涉及到的系统参数,如连接优化,UDP/TCP 连接优化等等,再到开源平台的参数和配置测试和调优,例如 Kafka 的分区调整/参数配置,Greenplum 的资源队列,内存资源参数,查询参数的测试优化等等。这些也希望大家在自己的架构设计和实践中不要忽视,要多去结合自有的机器类型(IDC 或者云机器),机器配置,业务需要进行调整。

    • FIN-


登录后回复
 

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