带你了解，什么是大数据！（下）
元数据
存储数据后，下一步是保存其元数据（有关数据本身的信息）。最常见的元数据是架构。通过使用外部元数据存储库，数据湖或数据管道中的不同工具可以查询它以推断数据模式。
如果将Avro用作原始数据，则外部注册表是一个不错的选择。这样，您就可以轻松地将处理过程中的提取分离。
数据一旦被摄取，为了由OLAP引擎查询，通常会使用SQL DDL。Hadoop生态系统中最常用的数据湖/数据仓库工具是Apache Hive，它提供了元数据存储，因此您可以像定义了架构的数据仓库一样使用数据湖。您可以在Hive上运行SQL查询，并连接许多其他工具（例如Spark）以使用Spark SQL运行SQL查询。Hive是Hadoop生态系统内部的重要工具，可为您的分析查询提供集中的元数据库。其他工具如Apache Tajo都建立在Hive之上，以在您的数据湖中提供数据仓库功能。
Apache Impala是Hadoop的本地分析数据库，它提供元数据存储，您仍然可以使用Hcatalog连接到Hive以获取元数据。
Apache Phoenix还有一个metastore，可以与Hive一起使用。Phoenix致力于OLTP，从而启用对事务具有ACID属性的查询。它具有灵活性，并通过利用HBase作为其后备存储来提供NoSQL世界中的读取模式架构功能。Apache Druid或Pinot还提供元数据存储。
数据处理
此阶段的目标是使用单个架构清理，规范化，处理和保存数据。最终结果是具有良好定义的架构的可信数据集。
通常，您需要执行某种处理，例如：
· 验证：通过将数据存储在单独的存储中来验证数据并隔离不良数据。根据数据质量要求，在达到特定阈值时发送警报。
· 整理和清理：清理数据并将其存储为另一种格式，以便进一步处理，例如，用Avro替换低效的JSON。
· 值的标准化和标准化
· 重命名字段
· …
请记住，目标是创建一个可信的数据集，以后可用于下游系统。这是数据工程师的关键角色。这可以以流或批处理的方式完成。
在批处理的情况下，流水线处理可以分为三个阶段：
· 预处理阶段：如果原始数据不干净或格式不正确，则需要对其进行预处理。此阶段包括一些基本验证，但目标是准备要在下一步进行有效处理的数据。在此阶段，您应该尝试展平数据并将其保存为二进制格式（例如Avro）。这将加快进一步处理的速度。这个想法是，下一阶段将执行行级操作，并且嵌套查询非常昂贵，因此现在对数据进行平整将提高下一阶段的性能。
· 可信阶段：数据经过验证，清理，规范化并转换为Hive中存储的通用模式。目标是创建数据所有者理解的受信任的通用数据集。通常，将创建一个数据规范，数据工程师的职责是应用转换以匹配该规范。最终结果是以Parquet格式设置的数据集，可以轻松查询该数据集。选择正确的分区并优化数据以执行内部查询至关重要。您可能希望在此阶段部分地预先计算一些聚合，以提高查询性能。
· 报告阶段：此步骤是可选的，但通常是必需的。不幸的是，当使用数据湖时，单个模式不能满足所有用例。这是数据仓库和数据湖之间的区别。查询HDFS的效率不如数据库或数据仓库，因此需要进一步的优化。在此阶段，您可能需要对数据进行规范化处理，以使用不同的分区存储数据，以便不同的涉众可以更有效地查询数据。这个想法是创建针对不同下游系统（数据集市）优化的不同视图。在此阶段，如果您不使用OLAP引擎，则还可以计算聚合（请参阅下一节）。受信任的阶段对谁将查询数据一无所知，该阶段为使用者优化了数据。如果客户端是高度交互的，则您可能希望在此阶段引入快速存储层，例如用于快速查询的关系数据库。或者，您可以使用OLAP引擎，我们将在后面讨论。
对于流来说，逻辑是相同的，但是它将以流的方式在定义的DAG中运行。Spark允许您将流与历史数据一起加入，但存在一些限制。稍后我们将讨论OLAP引擎，该引擎更适合于将实时数据与历史数据合并。
处理框架
可用于处理的一些工具是：
· Apache Spark：这是最著名的批处理框架。它是Hadoop生态系统的一部分，是一个托管集群，可提供令人难以置信的并行性，监控和出色的UI。它还支持流处理（结构流）。基本上，Spark在内存中运行MapReduce作业，其性能是常规MapReduce性能的100倍。它与Hive集成在一起以支持SQL，并可用于创建Hive表，视图或查询数据。它具有很多集成，支持多种格式，并且拥有庞大的社区。所有云提供商都支持它。它可以作为Hadoop集群的一部分在YARN上运行，也可以在Kubernetes和其他平台上运行。它具有许多针对特定用例（例如SQL或机器学习）的库。
· Apache Flink：第一个统一批处理和流传输的引擎，但主要关注流传输。 它可以用作像Kafka这样的微服务的主干。 它可以作为Hadoop集群的一部分在YARN上运行，但自成立以来，它还针对其他平台（如Kubernetes或Mesos）进行了优化。 它非常快，并提供实时流传输，使其成为比Spark在低延迟流处理（尤其是有状态流）方面更好的选择。 它还具有用于SQL，机器学习等的库。
· Apache Storm：Apache Storm是一个免费的开源分布式实时计算系统，它专注于流传输，是Hadoop生态系统的托管解决方案部分。它具有可扩展性，容错性，可确保您的数据将得到处理，并且易于设置和操作。
· Apache Samza：另一个出色的有状态流处理引擎。Samza允许您构建有状态的应用程序，以从多个来源（包括Apache Kafka）实时处理数据。在YARN之上运行的Hadoop生态系统的托管解决方案部分。
· Apache Beam：Apache Beam本身不是引擎，而是将所有其他引擎结合在一起的统一编程模型的规范。它提供了可以与不同语言一起使用的编程模型，因此开发人员在处理大数据管道时不必学习新的语言。然后，它为可在云或本地运行的处理步骤插入了不同的后端。Beam支持前面提到的所有引擎，您可以在它们之间轻松切换并在任何平台上运行它们：云，YARN，Mesos，Kubernetes。如果您要开始一个新项目，我真的建议您从Beam开始，以确保您的数据管道可以用于将来。
在此处理阶段结束时，您已经烹饪了数据，现在可以使用了！但是，为了烹饪，厨师必须与团队合作…
编排
数据管道编排是一个交叉过程，它管理所有其他任务之间的依赖关系。如果使用流处理，则需要编排每个流应用程序的依赖关系，而对于批处理，则需要安排和编排作业。
任务和应用程序可能会失败，因此您需要一种以统一的方式计划，重新计划，重放，监视，重试和调试整个数据管道的方法。
诸如Dagster或Prefect之类的较新框架添加了更多功能，并允许您跟踪向管道添加语义的数据资产。
一些选项是：
· Apache Oozie：Oozie是Hadoop的调度程序，作业创建为DAG，并且可以由时间或数据可用性触发。它与Sqoop等提取工具和Spark等处理框架集成在一起。
· Apache Airflow：Airflow是一个平台，可用于计划，运行和监视工作流程。使用DAG创建复杂的工作流程。图中的每个节点都是一个任务，边定义了任务之间的依存关系。Airflow Scheduler在遵循您描述的指定依赖项的同时，在一组工作线程上执行您的任务。它为您生成DAG，以最大程度地提高并行度。DAG是用Python编写的，因此您可以在本地运行它们，对其进行单元测试并将其与开发工作流程集成。它还支持SLA和警报。Luigi是具有类似功能的Airflow的替代产品，但Airflow具有更多功能，并且比Luigi具有更好的扩展性。
· Dagster‘s 机器学习，分析和ETL的新型协调器。主要区别在于您可以跟踪数据的输入和输出，类似于Apache NiFi创建数据流解决方案。您还可以在任务中实现其他值。它还可以并行运行多个作业，易于添加参数，易于测试，提供简单的版本控制等等。它仍然有些不成熟，由于需要跟踪数据，因此可能难以扩展，这是NiFi面临的一个问题。
· Prefect与Dagster相似，提供本地测试，版本控制，参数管理等等。Prefect之所以与众不同，是为了克服Airflow执行引擎的局限性，例如改进的计划程序，参数化的工作流，动态工作流，版本控制和改进的测试。它具有一个核心的开源工作流管理系统以及一个完全不需要设置的云产品。
· Apache NiFi：NiFi还可以安排作业，监视，路由数据，警报等等。它专注于数据流，但您也可以处理批处理。它在Hadoop外部运行，但可以触发Spark作业并连接到HDFS / S3。
简而言之，如果您的需求只是编排不需要共享数据的独立任务，请使用Airflow或Ozzie。对于需要数据沿袭和跟踪的数据流应用程序，对于非开发人员请使用NiFi，对于开发人员请使用Dagster或Prefect。
数据质量
大数据中经常忽略的一个重要方面是数据质量和保证。由于数据质量问题，公司每年都会损失大量资金。问题在于，这仍然是数据科学领域中一个不成熟的领域，开发人员已经在这一领域工作了数十年，他们拥有出色的测试框架和方法，例如BDD或TDD，但是您如何测试管道？
该领域存在两个常见问题：
· 误解的要求：转换和编排逻辑经常会变得非常复杂。业务分析师可以使用他们的领域语言来编写需求，开发人员通常会犯错，并计划，开发，测试和部署技术上正确但有错误需求的解决方案。这些类型的错误非常昂贵。
· 数据验证：管道测试与代码完全不同。开发软件时，您要测试功能，这是确定性的黑盒测试。对于给定的输入，您始终会获得相同的输出。对于数据资产，测试更加复杂：您需要声明数据类型，值，约束等等。此外，您需要应用聚合来验证数据集，以确保行数或列数正确。例如，很难检测是否有一天您的数据量下降了10％，或者某些值是否正确填充。
公司在数据质量和测试方面仍处于起步阶段，这造成了巨大的技术负担。我真的建议查看这篇文章以获取更多信息。
为了缓解这些问题，请尝试遵循DDD原则，并确保设置了边界并使用了通用语言。使用支持数据谱系的框架，例如NiFi或Dagster。
一些关注数据质量的工具是：
· Apache Griffin：此工具是Hadoop生态系统的一部分，它提供了一个统一的过程，可以从不同角度衡量数据质量，从而帮助您构建可信任的数据资产。它提供了一个DSL，可用于为数据创建断言并将其验证为管道的一部分。它与Spark集成在一起。您可以为数据集添加规则和断言，然后将验证作为Spark作业运行。Griffin的问题在于DSL可能变得难以管理（JSON），并且非技术人员难以解释，这意味着它无法解决被误解的需求问题。
> Apache Griffin Processes
· Great Expectations ：这是一个用Python编写的更新工具，专注于数据质量，管道测试和质量保证。它可以轻松地与Airflow或其他编排工具集成，并提供自动数据验证。使该工具与众不同的是事实，它是人类可读的，并且可由数据分析师，BA和开发人员使用。它提供了直观的UI，还提供了完全自动化的功能，因此您可以将验证作为生产管道的一部分运行，并在漂亮的UI中查看结果。非技术人员可以使用笔记本编写断言，这些笔记本提供开发人员可以轻松理解，转换为代码并用于测试的文档和正式要求。BA或测试人员编写数据断言（期望），然后将其转换为UI中的人类可读测试，以便每个人都可以看到并验证它们。它还可以进行数据分析以为您生成一些断言。它可以直接连接到本地或云中的数据库或文件系统。它非常易于使用和管理。可以将期望值提交到源代码存储库，然后将其集成到管道中。伟大的期望为涉及数据质量的所有各方创建了一种通用的语言和框架，从而非常容易地以最小的努力来自动化和测试管道。
> Great expectations UI
数据查询
现在，您已经掌握了烹调方法，现在该从该方法中获得最大价值了。至此，您已经使用一些深层存储（如HDFS）以可查询的格式（例如Parquet或OLAP数据库）将数据存储在数据湖中。
有多种工具可用于查询数据，每种工具都有其优点和缺点。它们中的大多数都集中在OLAP上，但是也很少针对OLTP进行过优化。有些使用标准格式，仅专注于运行查询，而另一些使用自己的格式/存储将处理推送到源，以提高性能。有些使用星型或雪花模式针对数据仓库进行了优化，而另一些则更为灵活。总结这些是不同的注意事项：
· 数据仓库与数据湖
· Hadoop与独立
· OLAP与OLTP
· 查询引擎与OLAP引擎
我们还应该考虑具有查询功能的处理引擎。
处理引擎
我们在上一节中描述的大多数引擎都可以连接到元数据服务器，例如Hive并运行查询，创建视图等。这是创建精细报表层的常见用例。
Spark SQL提供了一种将SQL查询与Spark程序无缝混合的方法，因此您可以将DataFrame API与SQL混合。它具有Hive集成和通过JDBC或ODBC的标准连接；因此您可以通过Spark将Tableau，Looker或任何BI工具连接到数据。
Apache Flink还提供SQL API。 Flink的SQL支持基于实现SQL标准的Apache Calcite。 它还通过HiveCatalog与Hive集成。 例如，用户可以使用HiveCatalog将其Kafka或ElasticSearch表存储在Hive Metastore中，并稍后在SQL查询中重新使用它们。
查询引擎
这类工具专注于以统一的方式查询不同的数据源和格式。这个想法是使用SQL查询来查询您的数据湖，就像它是一个关系数据库一样，尽管它有一些限制。其中一些工具还可以查询NoSQL数据库等等。这些工具为外部工具（如Tableau或Looker）提供JDBC接口，以安全方式连接到您的数据湖。查询引擎是最慢的选择，但提供最大的灵活性。
· Apache Pig：它是与Hive一起使用的最早的查询语言之一。它有自己的语言，不同于SQL。Pig程序的显着特性是它们的结构适合于实质性的并行化，从而使它们能够处理非常大的数据集。现在，它越来越倾向于使用基于SQL的新引擎。
· Presto：由Facebook发布为开源，它是一个开源的分布式SQL查询引擎，用于对各种规模的数据源运行交互式分析查询。Presto允许查询数据所在的位置，包括Hive，Cassandra，关系数据库和文件系统。它可以在几秒钟内对大型数据集执行查询。它独立于Hadoop，但与大多数工具集成在一起，尤其是Hive以运行SQL查询。
· Apache Drill：为Hadoop，NoSQL甚至云存储提供无模式的SQL查询引擎。它独立于Hadoop，但与Hive等生态系统工具集成了许多功能。单个查询可以联接来自多个数据存储的数据，从而执行特定于每个数据存储的优化。即使分析人员在后台读取文件，它也非常擅长让分析人员将任何数据视为表。Drill支持完全标准的SQL。商业用户，分析师和数据科学家可以使用标准的BI /分析工具（例如Tableau，Qlik和Excel）来利用Drill的JDBC和ODBC驱动程序与非关系数据存储进行交互。此外，开发人员可以在其自定义应用程序中利用Drill的简单REST API来创建精美的可视化效果。
> Drill model
OLTP数据库
尽管Hadoop已针对OLAP进行了优化，但是如果您要为交互式应用程序执行OLTP查询，仍然有一些选择。
HBase在设计上具有非常有限的ACID属性，因为它是按比例扩展的，并且不提供现成的ACID功能，但是可以用于某些OLTP场景。
Apache Phoenix建立在HBase之上，并提供了一种在Hadoop生态系统中执行OTLP查询的方法。Apache Phoenix与其他Hadoop产品（例如Spark，Hive，Pig，Flume和Map Reduce）完全集成。它还可以存储元数据，并支持通过DDL命令创建表和版本化的增量更改。它非常快，比使用Drill或其他查询引擎要快。
您可以使用Hadoop生态系统以外的任何大规模数据库，例如Cassandra，YugaByteDB，SyllaDB for OTLP。
最后，在任何类型的快速数据库（例如MongoDB或MySQL）中拥有数据的子集（通常是最新数据）是很常见的。上面提到的查询引擎可以在单个查询中在慢速和快速数据存储之间加入数据。
分布式搜索索引
这些工具提供了一种存储和搜索非结构化文本数据的方法，并且由于它们需要特殊的结构来存储数据，因此它们位于Hadoop生态系统之外。这个想法是使用倒排索引来执行快速查找。除了文本搜索外，该技术还可以用于各种用例，例如存储日志，事件等。有两个主要选项：
· Solr：这是一个基于Apache Lucene的流行，快速，开放源代码的企业搜索平台。Solr是可靠的，可伸缩的和容错的，提供分布式索引，复制和负载平衡查询，自动故障转移和恢复，集中式配置等。它非常适合文本搜索，但与ElasticSearch相比，它的用例有限。
· ElasticSearch：它也是一种非常流行的分布式索引，但是已经发展成为自己的生态系统，涵盖了许多用例，例如APM，搜索，文本存储，分析，仪表板，机器学习等。它绝对是一种非常有用的工具，可用于DevOps或数据管道，因为它用途广泛。它还可以存储和搜索视频和图像。
ElasticSearch可用作数据湖的快速存储层，以提供高级搜索功能。如果将数据存储在键值型海量数据库中，例如HBase或Cassandra，由于缺少联接，它们提供的搜索功能非常有限；您可以将ElasticSearch放在前面以执行查询，返回ID，然后对数据库进行快速查找。
它也可以用于分析。您可以导出数据，对其进行索引，然后使用Kibana对其进行查询，创建仪表板，报告等等，还可以添加直方图，复杂的聚合甚至在数据之上运行机器学习算法。弹性生态系统非常庞大，值得探索。
OLAP数据库
在此类别中，我们有数据库，该数据库还可以提供用于模式和查询功能的元数据存储。与查询引擎相比，这些工具还提供存储，并且在数据仓库的情况下可以强制执行某些架构（星型架构）。这些工具使用SQL语法，Spark和其他框架可以与它们进行交互。
· Apache Hive：我们已经讨论过Hive作为Spark和其他工具的中央模式存储库，以便它们可以使用SQL，但是Hive也可以存储数据，因此您可以将其用作数据仓库。它可以访问HDFS或HBase。查询Hive时，它会利用Apache Tez，Apache Spark或MapReduce，而Tez或Spark的速度要快得多。它还具有一种称为HPL-SQL的过程语言。
· Apache Impala：这是Hadoop的本地分析数据库，您可以使用它来存储数据并以有效的方式查询它。它可以使用Hcatalog连接到Hive获取元数据。Impala为Hadoop上的BI /分析查询提供了低延迟和高并发性（不是由批处理框架（如Apache Hive）提供的）。即使在多租户环境中，Impala也会线性扩展，从而比Hive更好地替代查询。Impala与本机Hadoop安全性和Kerberos集成在一起以进行身份验证，因此您可以安全地管理数据访问。它使用HBase和HDFS进行数据存储。
· Apache Tajo：这是Hadoop的另一个数据仓库。Tajo专为针对HDFS和其他数据源上存储的大数据集的低延迟和可扩展的即席查询，在线聚合和ETL而设计。它与Hive Metastore集成在一起以访问通用模式。它具有许多查询优化功能，具有可伸缩性，容错能力，并提供JDBC接口。
· Apache Kylin：Apache Kylin是更新的分布式分析数据仓库。Kylin的运行速度非常快，因此对于仪表盘或交互式报表等性能很重要的用例，它可以用于补充Hive等其他一些数据库，它可能是最好的OLAP数据仓库，但使用起来比较困难。问题在于，由于维数高，您需要更多的存储空间。这个想法是，如果查询引擎或Hive不够快，您可以在Kylin中创建一个"多维数据集"，这是针对OLAP优化的多维表，具有可从仪表板或交互式报表中查询的预先计算的值。它可以直接从Spark生成多维数据集，甚至可以从Kafka实时生成多维数据集。
OLAP引擎
在此类别中，我包括较新的引擎，这些引擎是对以前的OLAP数据库的改进，这些数据库提供了创建多合一分析平台的更多功能。实际上，它们是前两种类别的混合，为您的OLAP数据库添加了索引。它们位于Hadoop平台之外，但紧密集成。在这种情况下，您通常会跳过处理阶段并直接使用这些工具进行提取。
他们试图解决以统一的方式查询实时和历史数据的问题，以便您可以在查询到实时数据以及低延迟的历史数据后立即立即查询实时数据，从而构建交互式应用程序和仪表板。这些工具在许多情况下允许以ELT方式进行几乎没有任何转换的原始数据查询，但性能却优于常规OLAP数据库。
它们的共同点是它们提供了数据的统一视图，实时和批处理数据的接收，分布式索引，其自身的数据格式，SQL支持，JDBC接口，热冷数据支持，多种集成和元数据存储。
· Apache Druid：这是最著名的实时OLAP引擎。它专注于时间序列数据，但可用于任何类型的数据。它使用自己的列式格式，可以大量压缩数据，并且具有很多内置的优化功能，例如倒排索引，文本编码，自动数据汇总等等。使用具有极低延迟的Tranquility或Kafka实时摄取数据，数据以针对写入而优化的行格式保存在内存中，但是一旦到达，就可以像以前摄取的数据一样查询。后台任务，负责将数据异步移动到深度存储系统（例如HDFS）。当数据移至深层存储时，它将转换为较小的块，这些块按时间段进行了划分，这些段针对低延迟查询进行了高度优化。每个段都有一个时间戳和几个维，您可以使用它们过滤和执行聚合。和指标是预先计算的汇总。对于批量提取，它将数据直接保存到细分中。它支持推拉式摄取。它与Hive，Spark甚至NiFi集成在一起。它可以使用Hive Metastore，并且支持Hive SQL查询，然后将其转换为Druid使用的JSON查询。Hive集成支持JDBC，因此您可以连接任何BI工具。它还有自己的元数据存储，通常是MySQL。它可以吸收大量数据并很好地扩展。主要问题是它具有许多组件，并且难以管理和部署。
> Druid architecture
· Apache Pinot：这是LinkedIn开源的Druid的更新替代品。与Druid相比，由于Startree索引提供了部分预先计算，因此它提供了更低的延迟，因此它可用于面向用户的应用程序（用于获取LinkedIn提要）。它使用排序索引而不是倒排索引，索引速度更快。它具有可扩展的插件架构，并且具有许多集成，但不支持Hive。它还统一了批处理和实时功能，提供快速接收，智能索引并将数据分段存储。与Druid相比，它更容易部署且速度更快，但目前还不成熟。
> Apache Pinot
ClickHouse：用C ++编写，此引擎为OLAP查询（尤其是聚合）提供了令人难以置信的性能。它看起来像一个关系数据库，因此您可以非常轻松地对数据建模。它非常容易设置，并且具有许多集成。
> ClickHouse
查看这篇文章，其中详细比较了3个引擎。同样，从小处着手并在做出决定之前了解您的数据，这些新引擎功能强大，但难以使用。如果您可以等待几个小时，则使用批处理和Hive或Tajo等数据库；然后使用Kylin加快OLAP查询的速度，使其更具交互性。如果这还不够，并且您需要更低的延迟和实时数据，请考虑使用OLAP引擎。德鲁伊更适合实时分析。麒麟更专注于OLAP案件。Druid与Kafka的实时流媒体集成良好。Kylin分批从Hive或Kafka获取数据；尽管计划在不久的将来进行实时摄取。
最后，Greenplum是另一个更专注于AI的OLAP引擎。
> Presto/Drill provide more flexibility, Kylin great latency, Druid and Pinot, the best of both worl
最后，对于可视化，您可以使用多种商业工具，例如Qlik，Looker或Tableau。对于开源，请检查SuperSet，这是一个了不起的工具，它支持我们提到的所有工具，具有出色的编辑器，而且速度非常快。Metabase或Falcon是其他不错的选择。
结论
我们讨论了很多数据：不同的形状，格式，如何处理，存储以及更多内容。切记：了解您的数据和业务模型。使用迭代过程，慢慢开始构建您的大数据平台；不是通过引入新框架而是通过提出正确的问题并寻找可以为您提供正确答案的最佳工具。
查看数据的不同注意事项，根据数据模型（SQL），查询（NoSQL），基础结构和预算选择合适的存储。请记住与您的云提供商合作并评估云产品的大数据（购买与构建）。从无服务器分析流水线开始，然后随着成本的增加而逐渐过渡到开源解决方案，这是很常见的。
由于对您控制范围之外的系统的依赖性，数据提取至关重要且复杂。尝试管理那些依赖关系并创建可靠的数据流以正确提取数据。如果可能，请其他团队负责数据提取。请记住添加指标，日志和跟踪以跟踪数据。启用架构演变，并确保已在平台中设置适当的安全性。
使用正确的工具完成工作，不要花费太多。诸如Cassandra，Druid或ElasticSearch之类的工具是令人赞叹的技术，但需要大量知识才能正确使用和管理。如果只需要对临时查询和报告进行OLAP批处理分析，请使用Hive或Tajo。如果需要更好的性能，请添加Kylin。如果还需要与其他数据源联接，请添加查询引擎，例如Drill或Presto。此外，如果您需要实时查询批次，请使用ClickHouse，Druid或Pinot。
详情请关注上篇内容
领取更多大数据免费资料QQ群：1127558097
猜你喜欢：
