随着数据已经逐步成为一个公司宝贵的财富，大数据团队在公司往往会承担更加重要的角色。大数据团队往往要承担数据平台维护、数据产品开发、从数据产品中挖掘业务价值等重要的职责。所以对于很多大数据工程师，如何根据业务需求去选择合适的大数据组件，做合适的大数据架构工作就是日常工作中最常遇到的问题。在这里根据七牛云在日增千亿级的日志分析工作，和大家分享一下大数据技术架构选型的一些经验。
大数据架构师在关注什么
在一个大数据团队中，大数据架构师主要关注的核心问题就是技术架构选型问题。架构选型问题一般会受到哪些因素的影响呢？在我们的实践中，一般大数据领域架构选型最受以下几个因素影响：
数据量级
这一点在大数据领域尤其是一个重要的因素。不过从根本上讲，数据量级本身也是一种业务场景的衡量。数据量级的不同往往也就昭示着业务场景的不同。
业务需求
经验丰富的大数据架构师能够从纷繁的业务需求中提炼出核心技术点，根据抽象的技术点选择合适的技术架构。主要的业务需求可能包括：应用实时性要求、查询的维度和灵活程度、多租户、安全审计需求等等。
维护成本
这一点上大数据架构师一方面要能够清楚的了解各种大数据技术栈的优劣势，在满足业务需求的要求下，能够充分的优化架构，合理的架构能够降低维护的成本，提升开发的效率。
另一方面， 大数据架构师要能清楚的了解自己团队成员，能了解其他同学的技术专长和品位，能够保证自己做的技术架构可以得到认可和理解，也能得到最好的维护和发展。
接下来我们会围绕这几个方面去看看，做一个最适合自己团队业务的架构选型会如何受到这些因素的影响？
技术架构选型
业务需求是五花八门的，往往影响我们做技术选型的不是种种需求的细节，而是经过提炼后的一些具体的场景。就好比，业务需求提出我们要做一个日志分析系统，或者要做一个用户行为分析系统，这些具体需求背后我们要关注哪些具体的点？这是一个很有趣的问题，我们在做大数据的过程中，常发现我们对这些需求的疑问很多时候会落在以下几个问题上。

其中数据量级作为一个重要的因素影响着我们对于技术选型的决定，另外在数据量的变化之外各种业务场景的需要也会影响我们对技术组件的选择。
数据量级
如同我们上文中提到的，数据量级这个指标是一个特殊的业务场景的衡量，也是在大数据应用中影响最大的一个因素。往往对应不同的数据量级的业务，我们会有不同的考虑方式。
一般数据量级在 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
牛人说
「牛人说」专栏致力于技术人思想的发现，其中包括技术实践、技术干货、技术见解、成长心得，还有一切值得被发现的内容。我们希望集合最优秀的技术人，挖掘独到、犀利、具有时代感的声音。
投稿邮箱： [email protected]




点击「阅读原文」
免费开通七牛云智能日志管理平台
Select Language