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