它如何满足您的业务需求？选择的困境。
现在很容易通过市场上可用的大量数据工具而迷失。互联网上充满了有关使用哪些数据工具以及如何使我们的数据堆栈 现代的现代数据工具（通常是推测）。。。
那么什么是“现代数据堆”，它的现代性如何？
简单地说，它是用于与数据一起使用的工具的集合。根据我们将要处理数据的内容，这些工具可能包括以下内容：
- 托管的ETL/ELT数据管道服务
- 基于云的托管数据仓库/数据湖作为数据目的地
- 数据转换工具
- 商业智能或数据可视化平台
- 机器学习和数据科学能力
有时它的现代性无关紧要。
的确，如果我们的BI工具是超现代的，则具有定制的OLAP立方体用于数据建模和GIT集成，但不能将报告渲染到电子邮件中。
通常这些小事很重要。业务需求和数据管道要求是最重要的。
在下面的图中，我们可以在数据管道的每个步骤中看到数据旅程和相关工具的选择。
红移，Postgres，Google Bigquery，Snowflake，Databricks，Hadoop，DataProc，Spark或弹性地图减少？
为您的数据平台选择哪种产品？
这取决于每日任务您打算使用数据，数据处理和数据存储架构最适合这些任务。
数据平台体系结构类型
我记得几年前，互联网与“ Hasdoop is Dead”类型的故事沸腾。朝着数据仓库架构进行了明显的转变。在2023年，每个人似乎都沉迷于实时数据流和可扩展性，暗示Spark和Kafka很快成为公共基准领导者。
那么哪一个是最好的？谁是领导者，可以选择哪些工具？
我理解的是，这些基准判断非常主观，应该用少许盐考虑。重要的是，如果我们希望构建数据平台，这些工具与我们的业务需求保持一致。
数据仓库
无服务器，分布式SQL引擎（ BigQuery，Snowflake，Redshift，Microsoft Azure Synapse，Teradata 。）。它是 sql-first 数据架构，其中数据存储在a 数据仓库中，您可以自由地使用使用<<的所有优点strong>不规范化的星模架数据集。当然，我们可以这样做，因为大多数现代数据仓库都是分发的，并且比例很好，这意味着您不必担心表键和索引。它非常适合使用大数据的临时分析。
大多数现代数据仓库解决方案都可以处理结构化和非结构化数据，如果您的大多数用户是数据分析师具有良好的SQL技能。现代数据仓库可以轻松地与 Looker，Tableau，Sisense或Mode 等商业智能解决方案集成，这些解决方案也依赖于 ANSI-SQL 。它不是设计来存储图像，视频或文档的设计。但是，使用SQL，您几乎可以完成所有操作，甚至可以在某些供应商解决方案中训练机器学习模型。
https://medium.com/towards-data-science/advanced-sql-techniques-for-beginners-211851a28488
数据湖（Databricks，DataProc，EMR）
一种架构类型，其中数据存储在云存储中，即AWS S3，Google Cloud Storage，ABS。当然，很自然地将其用于图像，视频或文档以及任何其他文件类型（JSON，CSV，Parquet，Avro等），但是要分析它，您的用户必须编写一些代码。
最常见的编程语言对于此任务， python 有很多可用的库。 java，scala或pyspark 将是此任务的另一个流行选择。
代码带来了惊人的好处。
这是数据处理中最高的灵活性。我们的用户只需要知道如何做。
湖景房
数据仓库和数据湖体系结构的组合。它拥有两个世界中最好的，并为程序员和普通业务用户（例如数据分析师）提供服务。它使您的业务能够运行交互式SQL查询，同时在自定义方面保持非常灵活。大多数现代数据仓库解决方案都可以在数据湖中存储的数据（即外部表）上运行交互式查询。例如，一个数据管道看起来像这样：
我之前写过它。
数据网格
数据网格体系结构是一种分散的方法，使您的公司能够自行管理数据并运行跨团队 /跨域数据分析并共享数据。< / p>
每个业务部门可能具有不同的编程技能，即 sql或Python 以及各种数据工作负载要求（灵活的数据处理与交互SQL查询）。话虽如此，每个业务部门都可以自由选择自己的数据仓库/数据湖解决方案，但仍然可以与没有数据移动的其他单位共享数据。
关系和非关联数据库管理系统
关系数据库管理系统（RDS）将数据存储在基于行的表中，并使用连接相关数据元素的列。它旨在记录和优化以快速获取当前数据。流行的关系数据库是 PostgreSQL，MySQL，Microsoft SQL Server和Oracle。 nosql 数据库不仅支持简单的交易，而关系数据库还支持与JONINS的复杂交易。 NOSQL数据库用于处理以高速度的数据。流行的NOSQL数据库是：
-
文档数据库：mongodb和couchdb
-
键值数据库：redis和dynamodb
数据仓库具有相似的柱状结构，与RDS相同。数据也被组织成表，行和列。但是，数据库数据由行组织和存储的方式不同，而数据仓库数据是由列存储的，以促进在线分析处理（OLAP），而数据库则使用在线交易处理（OLTP）。例如， aws红移支持数据仓库和数据湖方法，使其能够访问和分析大量数据。
数据仓库设计用于数据分析，包括大量历史数据。使用数据仓库要求用户预先创建预定的，固定的模式，这有助于数据分析。表必须简单（规范化）才能计算大量数据。
rds数据库表和连接很复杂，因为它们是归一化。因此，A 传统数据库与数据仓库之间的主要区别在于，尽管传统数据库设计和优化为 Record 数据，但Data Warehouse的设计和优化是为了响应 Analytics 。运行应用程序时，您需要使用数据库，并且需要快速获取一些当前数据。 RDS存储为应用程序供电所需的当前数据。
您必须决定哪一个适合您。
商业智能堆栈
现代数据堆栈应包括有助于数据建模和可视化的BI工具。可以在下面找到一些高级概述。 当然不是广泛的列表，但是这些是2023年市场上最受欢迎的BI工具：
Looker Data Studio（Google Looker Studio）
关键特征：
-
免费版本以前称为Google Data Studio。这是BI提供基于社区支持的BI的绝佳免费工具。
-
大量的小部件和图表
-
大量基于社区的数据连接器
-
免费的电子邮件调度和交付。完美地渲染到电子邮件中。
-
免费数据治理功能
-
因为它是一个免费的社区工具，它具有一些未开发的API
Looker（付费版本）
关键特征：
-
强大的数据建模功能和自我服务功能。非常适合中型和大型公司。
-
API功能
Tableau
关键特征：
-
出色的视觉效果
-
合理的定价
-
获得专利的VIZQL引擎推动其直观分析经验
-
与许多数据源的连接，例如Hadoop，SAP和DB技术，提高了数据分析质量。
-
与Slack，Salesforce和其他许多其他集成。
aws Quicksight
关键特征：
-
自定义品牌的电子邮件报告
-
无服务器且易于管理
-
强大的API
-
无服务器自动缩放
-
付费每次使用定价
Power BI
关键特征：
-
Excel Integration
-
强大的数据摄入和连接功能
-
从轻松制作的Excel数据共享仪表板
-
一系列视觉和图形很容易获得
sisense（前潜望镜）
sisense是一个端到端数据分析平台，可通过可嵌入，可扩展的架构访问客户和员工的数据发现和分析。
关键特征：
-
提供几乎每个主要服务和数据源的数据连接器
-
为非技术用户提供无代码体验，尽管该平台还支持Python，R和SQL
-
git集成和自定义数据集
-
可能有点贵，因为它基于每个用户模型的每个许可证
-
某些功能仍在建设中，即报告电子邮件交付和报告渲染
思想点
关键特征：
- 查询的自然语言
模式
关键特征：
-
CSS设计仪表板
-
协作功能以允许在进行高级计划之前快速原型
-
笔记本支持
-
git支持
metabase
关键特征：
-
非常适合初学者和非常灵活的
-
有一个docker映像，因此我们可以立即运行
-
自助服务分析
redash
关键特征：
-
api
-
在其自然语法中写查询并探索模式
-
使用查询结果作为数据源来加入不同的数据库
其中一些工具具有免费版本。例如，Looker Data Studio免费提供了基本的仪表板功能，例如电子邮件，即拖放小部件构建器和大量图表。其他人已经付费功能，即数据建模，警报，笔记本和GIT集成。
它们都是具有优缺点的好工具。其中一些更易于用户友好，有些可以提供更强大的API，CI/CD功能和GIT集成。对于某些工具，这些功能仅在付费版本中可用。
结论
现代数据驱动的应用程序将需要一个数据库来存储当前的应用程序数据。因此，如果您有运行的应用程序，请考虑OLTP和RDS架构。
数据湖泊，仓库，湖泊房屋和数据库都有其好处并服务于每个目的。
想要执行大数据分析运行复杂SQL查询的大数据分析的公司可能会选择使用数据仓库（或湖泊房屋）补充其数据库。它使数据堆栈灵活而现代。
通常，答案总是相同的：
选择最便宜的一个或最适合与Dev stack一起使用的
尝试一下，您会看到可以轻松地集成到数据平台中的关系数据库。无论是数据湖还是数据仓库都没关系。各种数据连接器将启用简单且无缝的数据提取。您甚至可以尝试定制的一个：
但是，有几件事要考虑。
这里的关键是尝试数据工具，以查看它们与我们的业务需求有多一致。
例如，某些BI工具只能提供付费按用户定价，如果我们需要与外部用户共享仪表板，这将是不错的选择。
如果有任何节省成本的好处，最好将数据工具与您的开发堆栈相同的云供应商保留。
我们可能想检查工具之间功能之间是否存在重叠，即，当我们已经在数据仓库中进行操作时，我们真的需要一个BI解决方案，该解决方案可以在其自己的OLAP Cube中执行数据建模？
数据建模很重要
的确，它定义了我们处理数据的频率，这些数据将不可避免地反映在处理成本中。
转移到湖泊或数据仓库的转变将主要取决于用户的技能。数据仓库解决方案将使更多的交互作用，并将我们的选择缩小到SQL-First产品（Snowflake，BigQuery等）。
。数据湖泊适用于具有编程技能的用户，我们希望购买python-First产品，例如Databricks，Galaxy，DataProc，Emr。