千亿级数量下日志分析系统的技术架构选型



随着数据已经逐步成为一个公司宝贵的财富，大数据团队在公司每每会承担更加剧要的角色。大数据团队每每要承担数据平台维护、数据产品开发、从数据产品中挖掘业务价值等重要的职责。因此对于不少大数据工程师，如何根据业务需求去选择合适的大数据组件，作合适的大数据架构工做就是平常工做中最常遇到的问题。在这里根据七牛云在日增千亿级的日志分析工做，和你们分享一下大数据技术架构选型的一些经验。

大数据架构师在关注什么

在一个大数据团队中，大数据架构师主要关注的核心问题就是技术架构选型问题。架构选型问题通常会受到哪些因素的影响呢？在咱们的实践中，通常大数据领域架构选型最受如下几个因素影响：
 
 
 
   数据量级 这一点在大数据领域尤为是一个重要的因素。不过从根本上讲，数据量级自己也是一种业务场景的衡量。数据量级的不一样每每也就昭示着业务场景的不一样。 
   业务需求 经验丰富的大数据架构师可以从纷繁的业务需求中提炼出核心技术点，根据抽象的技术点选择合适的技术架构。主要的业务需求可能包括：应用实时性要求、查询的维度和灵活程度、多租户、安全审计需求等等。 
   维护成本 这一点上大数据架构师一方面要可以清楚的了解各类大数据技术栈的优劣势，在知足业务需求的要求下，可以充分的优化架构，合理的架构可以下降维护的成本，提高开发的效率。 
 另外一方面， 大数据架构师要能清楚的了解本身团队成员，能了解其余同窗的技术专长和品位，可以保证本身作的技术架构能够获得承认和理解，也能获得最好的维护和发展。 
 接下来咱们会围绕这几个方面去看看，作一个最适合本身团队业务的架构选型会如何受到这些因素的影响？

技术架构选型

业务需求是五花八门的，每每影响咱们作技术选型的不是种种需求的细节，而是通过提炼后的一些具体的场景。就比如，业务需求提出咱们要作一个日志分析系统，或者要作一个用户行为分析系统，这些具体需求背后咱们要关注哪些具体的点？这是一个颇有趣的问题，咱们在作大数据的过程当中，常发现咱们对这些需求的疑问不少时候会落在如下几个问题上。
    
 其中数据量级做为一个重要的因素影响着咱们对于技术选型的决定，另外在数据量的变化以外各类业务场景的须要也会影响咱们对技术组件的选择。
 
   数据量级   如同咱们上文中提到的，数据量级这个指标是一个特殊的业务场景的衡量，也是在大数据应用中影响最大的一个因素。每每对应不一样的数据量级的业务，咱们会有不一样的考虑方式。 
 通常数据量级在 10GB 左右，数据总条数在千万量级的数据，这种数据每每是业务最核心的数据，如用户信息库等。这种数据量因为其核心的业务价值，每每要求强一致性和实时性。在这种量级上，传统关系型数据库如 MySQL 等都能很好的解决各类业务需求。固然若是面对关系型数据库难以解决的问题，好比全文索引等的时候，架构师仍是须要根据业务需求选择 Solr 或者 Elasticsearch 等搜索引擎解决此类问题。 
 若是数据量级增加到 1 亿到 10 亿级别的时候，通常来讲这个阶段就会面临一个选择，是采用传统的 RDBMS+ 合理的索引+分库分表等各类策略呢？仍是应该选择一些诸如 SQL On Hadoop 或者 HTAP、OLAP 组件呢？这时候灵活性其实仍是相对比较大的，通常咱们经验是，若是团队内有数据库及中间件方向的专家工程师，但愿保持架构简单性，能够选择继续使用传统关系型数据。可是若是为了对将来业务有更高的扩展性，可以在可见的时间内支撑起更普遍的业务需求，仍是建议选择使用大数据组件。 
 当数据量已经增加到 10 亿到百亿级别，特别是 10TB 以上了以后，每每咱们传统的关系型数据库基本就已经被咱们排除在可选的技术架构以外了。这时候经常要结合各类业务场景去选择具体的场景的技术组件，好比咱们要仔细审视，咱们的业务场景是不是须要大量的更新操做？是否须要随机读写能力？是否须要全文索引？   
 以上是一些主流的分析型引擎在各个数据量级下大体的表现结果，这个图表中的数据仅仅是在大部分场景下的通常表现状况（并不是精确测试结果，仅供参考）。不过值得注意的是，虽然看起来咱们老是但愿响应时间越少越好，数据量级越高越好，但要知道大数据领域并无银弹，可以解决全部的问题。每一个技术组件都是牺牲了部分场景，才能在本身的领域中保持优点。 
 实时性   实时性是一个如此重要的因素，因此咱们在一开始就必需要重点的考虑业务需求中对实时性的要求。业务中的实时性每每包含两方面的含义：
 
 一方面，实时性体如今数据摄入的实时性上，数据摄入的实时性指的是当业务数据发生变化时候，咱们的大数据应用能接受多少的延迟能看到这个数据？从理想状况上来讲，固然业务上不管如何都是但愿系统越实时越好，可是从成本和技术上两方面去考量这个问题，咱们通常分为实时系统（毫秒延迟）、近实时系统（秒级延迟）、准实时系统（分钟级延迟）和离线系统（小时级或者天延迟）。通常延迟时间和吞吐能力，和计算能力都是反比的，吞吐越强，计算越精确，延迟时间会更长。 
 另外一方面，实时性也体如今查询的延迟上面，这个延迟计算的是，用户发出查询请求以后，要等待多长时间，服务端可以返回计算结果。这个大部分状况下决定于产品的具体形态，若是这个产品是要给终端用户进行展现，好比风云榜、热搜榜、推荐商品等统计类产品，是要有很高的 QPS 需求的产品，必然会须要将延迟控制在亚秒级。在另外一种场景下，若是一个产品是给数据分析师，或者运营人员进行数据探索使用，每每这时候会通过大规模且不可控制的计算，这时候可能更适合于一种离线任务的模式，用户的忍耐程度也会更高，支持分钟级甚至小时级别的数据输出。    
 能够从这个图中看出，通常在实时领域会选择 HBase，Cassandra 这种能支持事务同时支持高更新吞吐量的技术组件，或者也能够选择 TiDB、Spanner、Kudu 等这种 HTAP 组件，同时支持事务和分析的分布式数据库。
 
 若是追求更高的分析性能，能够选择专业的 OLAP （ On-Line Analytical Processing ）组件，如 Kylin  或者 Druid，他们属于 MOLAP （ Multi-dimensional OLAP ），支持提早建立数据立方，对指标进行预聚合，虽然牺牲必定的查询灵活程度，可是保证了查询实时性。 
 而 Elastic Search 是相对最为灵活的一个 NoSQL 查询引擎，一方面它支持全文索引，这个是其余引擎所不具有的。另外它也支持少许的更新，支持聚合分析，也支持明细数据的搜索查询，在近实时领域适用场景很是的多。不过因为 ES 是基于 Lucene 的存储引擎，相对须要资源成本会更高，并且分析性能对比其余引擎不具有优点。 
 另外，若是咱们的数据是离线或者追加的方式进行归档，同时产品形态须要依赖大批量数据的运算。这种产品每每能够忍受较高的查询延迟，那么 Hadoop 生态的一系列产品会很是适合这个领域，好比新一代的 MapReduce 计算引擎 Spark，另一系列 SQL On Hadoop 的组件，Drill，Impala，Presto 等各有各自的优势，咱们能够结合其余业务需求来选型。 
  计算维度 /灵活度 
 计算维度和计算灵活度，这两个因素是对计算选型很重要的因素。试想一下，若是咱们的产品只产出固定的若干指标项，咱们彻底可使用 Spark 离线计算将数据结果导入到 MySQL 等业务数据库中，做为结果集提供展现服务。 
 但当若是咱们的查询是一个交互式的，若是用户可以本身选择维度进行数据聚合，咱们没法将全部维度的排列组合都预计算出来，那这时候咱们可能就须要的是一个 OLAP 组件，须要可以根据指定维度作指标预聚合，这种选型能加强结果展现的灵活度，也能大大下降查询的延迟。 
 更深一步，用户若是不只仅可以对数据指标进行计算，同时要可以查询到原始的明细数据，这时候可能 OLAP 组件再也不适用，那么可能就须要到 ES 或者 SQL On Hadoop 这样更加灵活的组件。这时候若是有全文搜索需求，那么就选择 ES，若是没有就选择 SQL On Hadoop。 
 多租户  
 多租户需求也是一个大数据架构师常常须要考虑到的问题，多租户的需求每每是来源于许多不一样的使用方，这种需求对于一个公司的基础架构部门很是常见。 
 多租户要考虑哪些呢？ 
 第一是资源的隔离性，从资源节省的角度来看，确定是不一样租户之间资源能够共享的话，资源能够充分的利用起来。这也是咱们通常作基础架构部门最但愿作的工做。不过对于不少租户来讲，可能业务级别更高，或者数据量更加的庞大，若是和普通的租户一块儿共享资源可能会形成资源争抢。这时候就要考虑物理资源的隔离。 
 第二，就要考虑用户安全。一方面是要作认证，须要杜绝恶意或者越权访问数据的事情发生。另外一方面要作好安全审计，每次敏感操做要记录审计日志，可以追溯到每次行为的来源 IP 和操做用户。 
 第三但也是最重要的一点，就是数据权限。多租户系统并不只仅意味着隔离，更加意味着资源可以更加合理有效的获得共享和利用。如今数据权限每每不能局限于一个文件、一个仓库的读写权限。更多的时候咱们可能要对某个数据子集，某些数据字段进行数据受权，这样每一个数据全部者可以将本身的资源更加安全的分发给须要的租户。将数据可以更加高效的利用起来，这也是一个数据平台 /应用重要的使命。 
  维护成本  
 对于架构师而言大数据平台的维护成本是一个相当重要的指标，经验丰富的架构师可以结合自身团队的特色选择合适的技术方案。
 
    从上图能够看出大数据平台能够根据服务依赖（是依赖云服务仍是自建大数据平台）和技术组件的复杂度分为四个象限。 
 • 使用成本和技术组件复杂度成正比，通常来讲组件复杂度越高，组件数量越多，多种组件配合使用成本会越高。 
 • 维护成本和服务供应商以及组件复杂度都有关系，通常来讲，单一的技术组件要比复杂的技术组件维护成本低，云服务提供的技术组件要比自建大数据组件维护成本要更低。 
 • 团队要求来讲，通常来讲与使用成本趋同，都是技术组件越复杂，团队要求越高。不过另外一方面团队要求与服务供应商也存在关系，若是云服务厂商可以承担起组件的运维工做，其实是能够帮助业务团队从运维工做中解放出更多的工程师，参与到大数据应用的工做中。
 
 因此通常来讲，架构师对于技术选型的偏好应该是，在知足业务需求和数据量需求的前提下，选择技术架构最简单的，由于每每这种选型是最容易使用和维护的。在这个基础上，若是有一支很是强大的技术开发和运维团队，能够选择自建大数据平台；若是缺少足够的运维、开发支撑，那么建议选择云服务平台来支撑业务。

七牛云是如何作架构选型的

七牛云的大数据团队叫作 Pandora，这只团队的主要工做就是负责七牛云内的大数据平台需求的支撑工做，另外也负责将大数据平台产品化，提供给外部客户专业的大数据服务。能够说七牛云就是 Pandora 的第一个客户，咱们不少技术选型经验也是在承载公司内部各类需求积累起来的。
 
  七牛云的特点和业务挑战  
 简单的介绍下咱们在七牛云场景下面临的各类挑战。七牛云除了 Pandora 以外还有六个产品团队，包括云存储、直播云、CDN、智能多媒体 API 服务以及容器云团队。全部产品团队所产生的业务数据和日志数据都要经过 Pandora 自研的收集工具 logkit （专业版）收集到 Pandora 的统一日志存储中来。然后各个部门都利用这部分的数据作各类数据应用。    
 首先商业运营部门是背负了七牛云整个营收和增加的重要使命的团队，须要各个团队收集起来的埋点和日志数据，制做统一的用户视图，基于此制做用户画像。为客户提供更加贴身的运营服务，提高客户的满意度。 
 另外 SRE 团队，须要对线上系统作深刻的性能追踪，这边须要咱们提供 OpenTracing 接口的支持，在七牛云技术栈相对统一的环境下，咱们很方便地支持全链路监控，由此 SRE 部门不依赖于研发团队埋点便可以对线上的服务性能进行追踪监控，更易得知服务哪里出现问题。 
 产品研发这边提出了须要全文索引的需求，在每日近百 TB 的日志中须要可以根据关键词快速定位日志数据，同时可以查询日志上下文。不只如此，还须要可以解析出 APP 日志中的关键字段，好比用户 id 和响应时间、下载流量等，可以作用户级别的运维指标监控，可以更加精准的为客户服务。 
 
 固然不管是哪个业务部门提出的需求，他们都须要有优秀灵活的报表展现系统，可以支撑业务作分析、探索和决策。基于合理的架构要能支撑复杂的业务报表和 BI 需求。

在七牛云的架构落地

综合考虑了各方的产品需求，咱们作了以下的产品设计： 
 
 咱们首先自研了 logkit 专业版，用来专业收集、同步各类开源项目或者日志文件的数据。另外设计了一套数据总线 Pipeline，结合了七牛云的数据吞吐量超大，但延迟能够接受到秒级的延迟的特色。这里咱们采用了多 Kafka 集群 + Spark Streaming，自研了流量调度系统，能够将数据高效的导出到下游的统一日志存储产品中，同时使用 Spark Streaming 能够轻易的完成日志解析，字段提取等工做。 
 统一日志存储这里咱们支持了自研和各类第三方的图表展现系统。后端数据系统咱们采用的是混合架构模式，这里主体包含了三个基础产品。 
   日志分析平台 基于七牛云定制版本的 ES，构建日志存储和索引系统，可以在吞吐量 100w/s  的状况下集群依然保证十亿级别数据搜索秒级返回。
 
   数据立方 基于定制版 Druid 构建了数据立方这一个 OLAP 产品，面向多租户的高性能查询，为最大的客户每日 30TB+ 原始数据提供毫秒级的聚合分析。 
   离线工做流 基于存储和 Spark 工做流平台提供离线数据计算的能力，能够处理 PB 级数据的大规模计算和分析加工。 
   架构优点   
 在践行了这些大数据实践以后，Pandora 为内外部用户带来了一个怎样的产品呢。咱们经过与业界优秀的商业和开源产品作比对，得出七牛云有如下的几个优点：

完善的多租户支持 
 在多租户资源隔离这块，Pandora 作了多个级别的隔离支持。包括低级别的命名空间隔离，这时候咱们会经过限制用户使用 CPU、内存等各类共享资源，保证全部客户都能安全使用集群。更多地，为了知足更多客户定制化需求，咱们也利用多集群动态扩容方式支持租户之间的空间隔离，用户可使用独立的资源。 
 另外，在多租户场景中很重要的安全、权限和审计，咱们也作了长足的工做。数据咱们能够按照数据子集和字段的粒度作权限管理，将数据受权给其余租户。同时咱们会对数据的每一次操做记录审计，精确到来源 IP 和操做人员，保证云服务的数据安全性。

支撑丰富的业务场景 
 在 Pandora 基于日志领域的大数据平台上，咱们支持实时和离线两种计算模型，使用工做流界面能够简洁方便的操做各类大数据流。使用日志分析和数据立方等产品和工具，能够支持各类业务场景。包括但不限于： 
 • 用户行为分析 • 应用性能监控 • 系统设备性能监控 • 非侵入式埋点，支持全链路追踪系统，发现分布式系统应用瓶颈 • IoT 设备数据分析和监控 • 安全、审计和监控 • 机器学习，自动系统异常探测和归因分析

公有云超大规模数据验证 
 咱们在公有云已经服务了超过 200 家指名客户，天天有超过 250TB 的数据流入，天天约 3650 亿条数据。每日参与计算和分析的数据量已经超过 3.2PB 。超大的公有云规模，验证 Pandora 大数据日志分析平台能够为客户提供稳定的计算平台，提供良好的业务支撑。

用户享受最低运维成本 
 Pandora 的产品的设计哲学认为，云服务应该是一个一体化的产品。因此对于客户来讲，Pandora 虽然适配了大量的应用场景，可是仍然只是一个单一的产品组件，因此对于采用七牛云大数据服务的客户来讲运维成本是最低的，仅仅须要一个开发团队就能够照顾到数据开发和运维的方方面面，对于快速的业务迭代和增加来讲提供了巨大的便利性。 
 以上就是结合 Pandora 的实践和你们分享的一些经验。七牛云智能日志管理平台致力于下降用户的心智负担，帮助客户数字化升级。欢迎点击「阅读原文」即刻了解产品详情和免费额度政策： 
 • 新增日志数据 1 GB/月 
 • 存量日志数据 1 GB/月 
 • 日志仓库 1 个 /月 
 • API 调用次数 100 万次 /月 
 欢迎你们注册体验。
  文档站地址： https://pandora-docs.qiniu.com

 

From: https://www.v2ex.com/t/482269