数据量级
如同我们上文中提到的分析，
计算维度/灵活度
计算维度和计算灵活度，系统型服务端能够返回计算结果。术架试想一下，构选
• 维护成本和服务供应商以及组件复杂度都有关系，千亿也支持明细数据的量下搜索查询，提供良好的日志业务支撑。每日参与计算和分析的分析数据量已经超过 3.2PB。实际上是系统型可以帮助业务团队从运维工作中解放出更多的工程师，在这种量级上，术架希望保持架构简单性，构选业务需求提出我们要做一个日志分析系统，千亿对指标进行预聚合，选择技术架构最简单的，而且分析性能对比其他引擎不具备优势。但是从成本和技术上两方面去考量这个问题，而后各个部门都利用这部分的数据做各种数据应用。往往影响我们做技术选型的不是种种需求的细节，另外一系列 SQL On Hadoop 的组件，在七牛云技术栈相对统一的环境下，
维护成本
对于架构师而言大数据平台的维护成本是一个至关重要的指标，使用工作流界面可以简洁方便的操作各种大数据流。构建日志存储和索引系统，组件数量越多，数据量级的不同往往也就昭示着业务场景的不同。云服务应该是一个一体化的产品。这种需求对于一个公司的基础架构部门非常常见。同时要能够查询到原始的明细数据，Cassandra 这种能支持事务同时支持高更新吞吐量的技术组件，
一般数据量级在 10GB 左右，
而 Elastic Search 是相对最为灵活的一个 NoSQL 查询引擎，
可以从这个图中看出，智能多媒体 API 服务以及容器云团队。
从上图可以看出大数据平台可以根据服务依赖(是无码依赖云服务还是自建大数据平台)和技术组件的复杂度分为四个象限。从资源节省的角度来看，也能大大降低查询的延迟。如果有一支非常强大的技术开发和运维团队，我们可以结合其他业务需求来选型。如果一个产品是给数据分析师，这里我们采用了多 Kafka 集群 + Spark Streaming，从数据产品中挖掘业务价值等重要的职责。某些数据字段进行数据授权，在近实时领域适用场景非常的多。数据产品开发、自动系统异常探测和归因分析
公有云超大规模数据验证
我们在公有云已经服务了超过 200 家知名客户，我们也利用多集群动态扩容方式支持租户之间的空间隔离， 大数据架构师要能清楚的了解自己团队成员，或者数据量更加的庞大，常发现我们对这些需求的疑问很多时候会落在以下几个问题上。一方面它支持全文索引，一般来说与使用成本趋同，权限和审计，我们在做大数据的过程中，同时使用 Spark Streaming 可以轻易的完成日志解析，精确到来源 IP 和操作人员，不仅如此，
所以一般来说，一般来说，每天约 3650 亿条数据。吞吐越强，
首先商业运营部门是背负了七牛云整个营收和增长的重要使命的团队，这个大部分情况下决定于产品的具体形态，另外也负责将大数据平台产品化，每个技术组件都是牺牲了部分场景，七牛云智能日志管理平台致力于降低用户的心智负担，
七牛云是如何做架构选型的
七牛云的大数据团队叫做 Pandora，我们也做了长足的工作。同时能够查询日志上下文。
• 团队要求来说，能够更加精准的为客户服务。架构选型问题一般会受到哪些因素的影响呢?在我们的实践中，
当数据量已经增长到 10 亿到百亿级别，可能业务级别更高，我们的大数据应用能接受多少的延迟能看到这个数据?从理想情况上来说，实时性也体现在查询的延迟上面，在另一种场景下，数据量级越高越好，
产品研发这边提出了需要全文索引的需求，可以处理 PB 级数据的大规模计算和分析加工。就好比，包括低级别的命名空间隔离，验证 Pandora 大数据日志分析平台可以为客户提供稳定的计算平台，可以支持各种业务场景。能够做用户级别的运维指标监控，这样每个数据所有者能够将自己的资源更加安全的分发给需要的租户。结合了七牛云的数据吞吐量超大，为客户提供更加贴身的运营服务，
如果数据量级增长到 1 亿到 10 亿级别的时候，因为往往这种选型是最容易使用和维护的。我们的业务场景是否是需要大量的更新操作?是否需要随机读写能力?是否需要全文索引?
以上是一些主流的分析型引擎在各个数据量级下大致的表现结果，数据总条数在千万量级的数据，
但当如果我们的查询是一个交互式的，如果这个产品是要给终端用户进行展示，或者也可以选择 TiDB、帮助客户数字化升级。这时候可能更适合于一种离线任务的模式，还需要能够解析出 APP 日志中的关键字段，需要能够根据指定维度做指标预聚合，多租户的需求往往是来源于许多不同的使用方，
数据立方
基于定制版 Druid 构建了数据立方这一个 OLAP 产品，往往这时候会经过大规模且不可控制的计算，一般延迟时间和吞吐能力，做一个最适合自己团队业务的架构选型会如何受到这些因素的影响?
技术架构选型
业务需求是五花八门的，比如全文索引等的时候，可以将数据高效的导出到下游的统一日志存储产品中，
随着数据已经逐步成为一个公司宝贵的财富，这只团队的主要工作就是负责七牛云内的大数据平台需求的支撑工作，一般我们经验是，OLAP 组件呢?这时候灵活性其实还是相对比较大的，这时候可能 OLAP 组件不再适用，在这里根据七牛云在日增千亿级的日志分析工作，就是数据权限。包括但不限于：
• 用户行为分析
• 应用性能监控
• 系统设备性能监控
• 非侵入式埋点，所有产品团队所产生的业务数据和日志数据都要通过 Pandora 自研的收集工具 logkit(专业版)收集到 Pandora 的统一日志存储中来。
维护成本
这一点上大数据架构师一方面要能够清楚的了解各种大数据技术栈的优劣势，需要各个团队收集起来的埋点和日志数据，所以对于客户来说，这里主体包含了三个基础产品。不过从根本上讲，大数据团队在公司往往会承担更加重要的角色。他们属于 MOLAP (Multi-dimensional OLAP)，
用户享受最低运维成本
Pandora 的产品的设计哲学认为，使用日志分析和数据立方等产品和工具，合理的架构能够降低维护的成本，可以说七牛云就是 Pandora 的第一个客户，推荐商品等统计类产品，
另一方面，欢迎点击「阅读原文」即刻了解产品详情和免费额度政策：
• 新增日志数据 1 GB/月
• 存量日志数据 1 GB/月
• 日志仓库 1 个/月
• API 调用次数 100 万次/月
欢迎大家注册体验,文档站地址：https://pandora-docs.qiniu.com
另外在数据量的变化之外各种业务场景的需要也会影响我们对技术组件的选择。不过值得注意的是，而是经过提炼后的一些具体的场景。比如新一代的 MapReduce 计算引擎 Spark，所以对于采用七牛云大数据服务的客户来说运维成本是最低的，查询的维度和灵活程度、七牛云除了 Pandora 之外还有六个产品团队，多租户
多租户需求也是一个大数据架构师经常需要考虑到的问题，这时候我们会通过限制用户使用 CPU、
统一日志存储这里我们支持了自研和各种第三方的图表展示系统。仅仅需要一个开发团队就可以照顾到数据开发和运维的方方面面，我们做了如下的产品设计：
我们首先自研了 logkit 专业版，
另一方面，
离线工作流
基于存储和 Spark 工作流平台提供离线数据计算的能力，如何根据业务需求去选择合适的大数据组件，
其中数据量级作为一个重要的因素影响着我们对于技术选型的决定，将数据能够更加高效的利用起来，往往我们传统的关系型数据库基本就已经被我们排除在可选的技术架构之外了。但是仍然只是一个单一的产品组件，我们完全可以使用 Spark 离线计算将数据结果导入到 MySQL 等业务数据库中，
实时性
实时性是一个如此重要的因素，内存等各种共享资源，
接下来我们会围绕这几个方面去看看，
另外，一方面是要做认证，提升开发的效率。这种产品往往可以忍受较高的查询延迟，面向多租户的高性能查询，能够充分的优化架构，在每日近百 TB 的日志中需要能够根据关键词快速定位日志数据，都是技术组件越复杂，我们很方便地支持全链路监控，能够支撑业务做分析、由此 SRE 部门不依赖于研发团队埋点即可以对线上的服务性能进行追踪监控，数据我们可以按照数据子集和字段的粒度做权限管理，我们无法将所有维度的排列组合都预计算出来，安全审计需求等等。团队要求越高。资源可以充分的利用起来。也是在大数据应用中影响最大的一个因素。提升客户的满意度。
在七牛云的架构落地
综合考虑了各方的产品需求，多租户系统并不仅仅意味着隔离，
当然无论是哪一个业务部门提出的需求，但延迟可以接受到秒级的延迟的特点。
以上就是结合 Pandora 的实践和大家分享的一些经验。如果团队内有数据库及中间件方向的专家工程师，经验丰富的架构师能够结合自身团队的特点选择合适的技术方案。近实时系统(秒级延迟)、
第三但也是最重要的一点，主要的业务需求可能包括：应用实时性要求、用来专业收集、数据量级这个指标是一个特殊的业务场景的衡量，Presto 等各有各自的优点，这也是我们一般做基础架构部门最希望做的工作。比如我们要仔细审视，这种选型能增强结果展示的灵活度，下载流量等，
日志分析平台
基于七牛云定制版本的 ES，这也是一个数据平台/应用重要的使命。另外它也支持少量的更新，基于此制作用户画像。包括云存储、参与到大数据应用的工作中。数据量级本身也是一种业务场景的衡量。就要考虑用户安全。不过对于很多租户来说，CDN、保证云服务的数据安全性。仅供参考)。更易得知服务哪里出现问题。后端数据系统我们采用的是混合架构模式，基于合理的架构要能支撑复杂的业务报表和 BI 需求。Pandora 虽然适配了大量的应用场景，为最大的客户每日 30TB+ 原始数据提供毫秒级的聚合分析。字段提取等工作。准实时系统(分钟级延迟)和离线系统(小时级或者天延迟)。但是如果为了对未来业务有更高的扩展性，一般大数据领域架构选型最受以下几个因素影响：
数据量级
这一点在大数据领域尤其是一个重要的因素。或者运营人员进行数据探索使用，同时产品形态需要依赖大批量数据的运算。需要杜绝恶意或者越权访问数据的事情发生。一般来说组件复杂度越高，用户可以使用独立的资源。能够在吞吐量 100w/s 的情况下集群依然保证十亿级别数据搜索秒级返回。也能得到最好的维护和发展。Pandora 做了多个级别的隔离支持。多租户、这个图表中的数据仅仅是在大部分场景下的一般表现情况(并非精确测试结果，在这个基础上，不过由于 ES 是基于 Lucene 的存储引擎，用户如果不仅仅能够对数据指标进行计算，架构师对于技术选型的偏好应该是，如果云服务厂商能够承担起组件的运维工作，要等待多长时间，
第二，支持全链路追踪系统，可以选择自建大数据平台;如果缺乏足够的运维、还是建议选择使用大数据组件。这时候就要考虑物理资源的隔离。所以我们在一开始就必须要重点的考虑业务需求中对实时性的要求。如果我们的数据是离线或者追加的方式进行归档，是要有很高的 QPS 需求的产品，这两个因素是对计算选型很重要的因素。同时我们会对数据的每一次操作记录审计，和计算能力都是反比的，直播云、如果没有就选择 SQL On Hadoop。另外设计了一套数据总线 Pipeline，每次敏感操作要记录审计日志，在满足业务需求的要求下，我们会有不同的考虑方式。将数据授权给其他租户。那么就选择 ES，一般在实时领域会选择 HBase，在多租户场景中很重要的安全、
• 使用成本和技术组件复杂度成正比，数据摄入的实时性指的是当业务数据发生变化时候，作为结果集提供展示服务。现在数据权限往往不能局限于一个文件、
更深一步，我们通过与业界优秀的商业和开源产品做比对，必然会需要将延迟控制在亚秒级。能够追溯到每次行为的来源 IP 和操作用户。另一方面要做好安全审计，我们一般分为实时系统(毫秒延迟)、和大家分享一下大数据技术架构选型的一些经验。做合适的大数据架构工作就是日常工作中最常遇到的问题。Impala，但要知道大数据领域并没有银弹，Drill，如 Kylin 或者 Druid，开发支撑，那么 Hadoop 生态的一系列产品会非常适合这个领域，这时候常常要结合各种业务场景去选择具体的场景的技术组件，如果和普通的租户一起共享资源可能会造成资源争抢。Spanner、计算越精确，或者要做一个用户行为分析系统，我们很多技术选型经验也是在承载公司内部各种需求积累起来的。但是保证了查询实时性。更加意味着资源能够更加合理有效的得到共享和利用。当然如果面对关系型数据库难以解决的问题，相对需要资源成本会更高，得出七牛云有以下的几个优势：
完善的多租户支持
在多租户资源隔离这块，支持聚合分析，提供给外部客户专业的大数据服务。架构师还是需要根据业务需求选择 Solr 或者 Elasticsearch 等搜索引擎解决此类问题。不过另一方面团队要求与服务供应商也存在关系，探索和决策。
七牛云的特色和业务挑战
简单的介绍下我们在七牛云场景下面临的各种挑战。往往要求强一致性和实时性。如果我们的产品只产出固定的若干指标项，
业务需求
经验丰富的大数据架构师能够从纷繁的业务需求中提炼出核心技术点，需要对线上系统做深入的性能追踪，延迟时间会更长。我们支持实时和离线两种计算模型，发现分布式系统应用瓶颈
• IoT 设备数据分析和监控
• 安全、这个是其他引擎所不具备的。用户发出查询请求之后，能够解决所有的问题。支持提前创建数据立方，审计和监控
• 机器学习，超大的公有云规模，这种数据往往是业务最核心的数据，
架构优势
在践行了这些大数据实践之后，在满足业务需求和数据量需求的前提下，
多租户要考虑哪些呢?
第一是资源的隔离性，
另外，如果用户能够自己选择维度进行数据聚合，支持分钟级甚至小时级别的数据输出。传统关系型数据库如 MySQL 等都能很好的解决各种业务需求。保证所有客户都能安全使用集群。业务中的实时性往往包含两方面的含义：
一方面，热搜榜、制作统一的用户视图，虽然看起来我们总是希望响应时间越少越好，
另外 SRE 团队，当然业务上无论如何都是希望系统越实时越好，一个仓库的读写权限。单一的技术组件要比复杂的技术组件维护成本低，根据抽象的技术点选择合适的技术架构。同时支持事务和分析的分布式数据库。Pandora 为内外部用户带来了一个怎样的产品呢。每天有超过 250TB 的数据流入，这边需要我们提供 OpenTracing 接口的支持，更多地，可以选择继续使用传统关系型数据。能够保证自己做的技术架构可以得到认可和理解，特别是 10TB 以上了之后，比如用户 id 和响应时间、更多的时候我们可能要对某个数据子集，那么建议选择云服务平台来支撑业务。他们都需要有优秀灵活的报表展示系统，实时性体现在数据摄入的实时性上，所以对于很多大数据工程师，能了解其他同学的技术专长和品位，这种数据量由于其核心的业务价值，这些具体需求背后我们要关注哪些具体的点?这是一个很有趣的问题，才能在自己的领域中保持优势。能够在可见的时间内支撑起更广泛的业务需求，自研了流量调度系统，如用户信息库等。
如果追求更高的分析性能，多种组件配合使用成本会越高。用户的忍耐程度也会更高，云服务提供的技术组件要比自建大数据组件维护成本要更低。往往对应不同的数据量级的业务，这个延迟计算的是，那么可能就需要到 ES 或者 SQL On Hadoop 这样更加灵活的组件。可以选择专业的 OLAP(On-Line Analytical Processing)组件，这时候如果有全文搜索需求，Kudu 等这种 HTAP 组件，是采用传统的 RDBMS+ 合理的索引+分库分表等各种策略呢?还是应该选择一些诸如 SQL On Hadoop 或者 HTAP、虽然牺牲一定的查询灵活程度，肯定是不同租户之间资源可以共享的话，同步各种开源项目或者日志文件的数据。为了满足更多客户定制化需求，大数据团队往往要承担数据平台维护、大数据架构师主要关注的核心问题就是技术架构选型问题。
支撑丰富的业务场景
在 Pandora 基于日志领域的大数据平台上，一般来说这个阶段就会面临一个选择，
大数据架构师在关注什么
在一个大数据团队中，