Master

平台

采纳?

    试验?

    • 我们许多使用AWS的团队中发现,AWS云开发工具包(AWS CDK)是一个合理的 AWS 默认工具,以实现基础设施的整备工作。其特别之处在于,他们喜欢使用主流编程语言而不是配置文件来进行开发,从而可以使用现有的工具、测试方法和技能。但与类似的工具一样,此时也仍需要谨慎地确保部署易于理解和维护。这个开发工具包目前支持TypeScript、JavaScript、Python、Java、C# 和 .NET。新语言的支持正在被添加到 CDK 中。此外,我们使用了 AWS 云开发工具包和 HashiCorp 的Terraform 云开发工具包来生成 Terraform 配置,并成功实现了与Terraform平台的整备。

      历史信息
    • 随着组织在寻求支持和简化其开发环境时,开始采用开发者门户,我们看到人们对Backstage的兴趣和使用量在不断增长。随着工具和技术数量的增加,采用某种形式的标准化,对于保持开发的一致性变得越来越重要。因为一旦实现了一致性,开发人员就可以专注于创新和产品开发,而不是陷入重复发明轮子的泥淖。Backstage 是由 Spotify 创建的开源开发者门户平台。它由软件模板、统一的基础设施工具和一致且集中的技术文档所构成。插件式架构为组织的基础设施生态系统,提供了可扩展性和适应性。

      历史信息
    • Delta Lake是由Databricks实现的开源存储层,旨在将ACID事务处理引入到大数据处理中。在使用了Databricks的data lakedata mesh的项目中,我们的团队更喜欢使用Delta lake存储,而不是直接使用S3ADLS等文件存储类型。当然,这仅限于那些使用了支持Delta Lake的存储平台的项目,并且使用了Parquet文件格式。当需要实现文件级事务完整性时,Delta Lake 能实现并发数据读写。尽管还存在一些限制,但Delta Lake 与 Apache Spark batch以及micro-batch接口的无缝集成,对我们非常有用。尤其有用的是诸如时间旅行(在特定时间点访问数据或进行提交回滚)和对写操作的schema演进的支持。

      历史信息
    • Materialize 是一种流数据库。在无需复杂的数据管道的情况下,只须用标准SQL视图描述计算,然后将 Materialize 连接到数据流,就能实现增量计算。底层的差分数据流引擎能够运行增量计算,从而以最小的延迟,提供一致且准确的结果。与传统数据库不同,定义 Materialize 视图不存在任何限制,并且计算可以实时执行。我们将 Materialize 与 Spring Cloud Stream 以及 Kafka 配合使用,从而在分布式事件驱动的系统中,查询事件流并分析结果。其效果令人满意。

      历史信息
    • 自从上次在雷达上提到 Snowflake 以来,对于它的使用,以及作为数据仓库和数据湖的替代方案的data mesh,我们都获得了更多经验。 Snowflake 在时间旅行、零拷贝克隆、数据共享及其应用市场等功能方面,继续给人留下深刻印象。Snowflake 至今还没出现任何令我们不喜欢的地方,所以相较于其他选择来说,我们的顾问会更偏爱使用它。亚马逊的数据仓库产品 Redshift 正在朝着将存储和计算进行分离的方向发展,而这一直都是 Snowflake 的强项。如果使用 Redshift 产品中的 Spectrum 特性进行数据分析,就会感觉它并非那么方便和灵活,部分原因是它受到了 Postgres 的约束(虽然我们也喜欢用Postgres。而进行联合查询(federated queries)可能是使用 Redshift 的原因。在操作方面,Snowflake 的操作会更简单。 虽然BigQuery是另一种选择,且非常易于操作,但在多云的场景下,Snowflake是更好的选择。我们已经在GCPAWS和AzureAzure上成功地使用了 Snowflake。

      历史信息
    • 可变字体 能避免查找和引用多个具有不同字重和样式的字体文件。这种方法使得所有变体样式都保存在一个字体文件中,并且可以使用属性来选择所需的样式和字重。尽管这不是新技术,但我们仍然看到网站和项目因使用这种简单方法而受益。如果页面中包含相同字体的不同变体,建议尝试使用可变字体。

      历史信息

    评估?

    • Apache Pinot是分布式 OLAP 数据存储系统,旨在提供低延迟的实时分析。它可以从批处理数据源(例如 Hadoop HDFS、Amazon S3、Azure ADLS或Google Cloud Storage)以及流式数据源(例如 Apache Kafka )中提取数据。如果需要进行面向用户的低延迟数据分析,则 Hadoop SQL 方案不能保证所需的低延迟。诸如 Apache Pinot(或Apache DruidClickhouse等)现代 OLAP 引擎,可以实现低得多的延迟,特别适合针对不可变数据(如聚合)进行快速分析的场景(或许需要进行实时数据提取)。 Apache Pinot 最初由 LinkedIn 构建,并于2018年底进入Apache孵化阶段。此后,该系统又增加了插件架构和SQL支持等关键特性。 Apache Pinot 的操作相当复杂,并且具有许多需要控制的部件,但是如果需要分析的数据量足够大,并且对查询要求低延迟,则建议评估一下 Apache Pinot。

      历史信息
    • Bit.dev 是一个云托管平台,用于通过 Bit 抽取、模块化并重用UI组件。虽然 Web components 已经存在一段时间了,但通过组装从其它项目抽取出来的独立小组件,来构建现代前端应用,仍然很困难。而 Bit 要解决的,就是这个问题。它是一个简洁的命令行工具,可以从已有的库或项目当中抽取组件。要进行组件协作,既可以在 Bit 的基础上自行构建相关服务,也可以直接使用 Bit.dev。

      历史信息
    • 自从我们第一次在技术雷达中提及 data discoverability 以来,LinkedIn 已经将 WhereHows 进化为 DataHub,一个通过可扩展的元数据系统实现数据可发现性的下一代平台。与爬取和拉取元数据不同,DataHub 采用了基于推送的模式。数据生态系统中各个组件,都可以通过 API 或者流(stream)向中心化的平台上发布元数据。这种基于推送的数据集成,将数据发现所有权从中心实体转移到各个团队,使他们对自己的元数据负责。随着越来越多的公司试图成为数据驱动型企业,拥有一个有助于数据发现和理解数据质量与渊源的系统,是至关重要的。我们建议评估 DataHub 在这方面的能力。

      历史信息
    • Feature Store 是一个服务于机器学习的数据平台,可以解决当前我们在特征工程中所遇到的一些关键问题。它提供了三个基本功能:(1)使用托管的数据管道,以消除新数据与数据管道之间的冲突;(2)对特征数据进行编目和存储,从而促进跨模型的特征的可发现性和协同性;(3)在模型的训练和干扰过程中,持续提供特征数据。

      自从 Uber 公开了 Michelangelo 平台 以来,许多组织和初创企业都建立了自己的特征库;例如 HopsworksFeastTecton。 我们看到了 Feature Store 的潜力,并建议仔细对其进行评估。

      历史信息
    • JuiceFS 是基于Redis 和对象存储而构建的开源分布式 POSIX 文件系统。如果要构建新的应用程序,那么我们建议始终与对象存储进行直接交互,而无需经过另一个抽象层。另外,如果要将依赖于传统 POSIX 文件系统的遗留系统迁移到云上,也可以考虑使用JuiceFS。

      历史信息
    • 随着越来越多的企业开始运用事件在微服务之间共享数据、收集分析数据或传输数据到数据湖,Apache Kafka已经成为支撑事件驱动架构的最受欢迎的平台。尽管 Kafka 的可伸缩的消息持久化概念是革命性的,但要使其正常工作,还是需要依赖众多的活动部件,包括 Zookeeper、代理、分区和镜像。虽然实现和维护这些组件会很棘手,但是它们确实在需要的时候,尤其是在企业规模的应用中,提供了极大的灵活性和强大功能。因为采用 Kafka 完整生态系统的门槛较高,所以我们乐于见到一些平台在最近的爆发式增长。这些平台提供 用Kafka API而非Kafka 的功能。最近涌现出的Kafka on PulsarRedpanda,就是属于这类平台。而Azure Event Hubs for Kafka则提供了对 Kafka 生产者和消费者 API 的兼容。但由于 Kafka 的某些功能(例如数据流客户端库)与这些替代代理不兼容,因此仍然有理由选择 Kafka 而不是这些替代代理。然而究竟开发者是否会采用“用Kafka API而非Kafka”的策略,抑或这只是 Kafka 的竞争对手试图将用户引诱到 Kafka平台之外,还有待观察。最终,也许Kafka最持久的影响力,就是其提供给客户的易用协议和API。

      历史信息
    • NATS是一种快速和安全的消息队列系统,具有异常广泛的功能和潜在的市场。有人会问,为什么还需要另一个消息队列系统?自从企业开始使用计算机以来,各种形式的消息队列系统已经存在了很长时间了,并且针对各种任务,经历了多年的改进和优化。但是,NATS 的确具有几个有趣的特征,并且其独特的伸缩性,既能用于嵌入式控制器,又能用于全球范围云托管的超级集群。 NATS 旨在支持来自移动设备或 IoT 并通过互连系统的网络所传递的连续数据流,对此我们特别感兴趣。但是,该系统也需要解决一些棘手的问题,其中最重要的,是确保消费者仅看到他们被允许访问的消息和主题,尤其是当网络跨越组织边界时。 NATS 2.0 引入了一个安全和访问控制框架。该框架支持多租户群集。在该群集中,帐户限制了用户对消息队列和主题的访问。 NATS 是 Go 语言编写的,最初主要被Go语言社区所接受。尽管该系统针对几乎所有广泛使用的编程语言都提供客户端,但是 Go 语言所实现的客户端是迄今为止最受欢迎的。我们的一些开发人员发现,所有编程语言的客户端库,都倾向于要提供 Go 语言客户端所具备的特性。小型无线设备的带宽和处理能力的提高,意味着企业必须实时处理的数据量只会增大。可以评估 NATS 作为在企业内部和企业之间,以流的形式传输数据的可行性。

      历史信息
    • Opstrace是一个用于实现系统可观测性的开源平台,旨在部署于用户自己的网络中。如果不使用像 Datadog 这样的商业解决方案(例如,由于成本或数据驻留地点的考虑),那么唯一的解决方案就是构建由开源工具组成的自己的平台。这需要投入很大的工作量,而 Opstrace 就是来解决这个问题的。它使用开源 api 和接口,如PrometheusGrafana,并在上面添加了额外的特性,如TLS和身份验证。Opstrace 的核心运行了一个Cortex集群,提供可伸缩的 Prometheus API 和 Loki日志集群。与 Datadog 或 SignalFX 等解决方案相比,它是崭新的平台,所以仍然缺少一些特性。尽管如此,它所解决的上述问题,使其在该领域仍然很有前景,值得关注。

      历史信息
    • 我们已经看到人们对 Pulumi 的兴趣正在缓慢且稳步地上升。虽然Terraform 在基础设施编程世界中地位稳固,但 Pulumi 却填补了其中的一个空白。尽管 Terraform 是一个久经考验的常备选项,但其声明式编程特质,深受抽象机制不足和可测试性有限的困扰。如果基础设施完全是静态的,那么 Terraform 就够用了。但是动态基础设施但定义,要求使用真正的编程语言。Pulumi 允许以 TypeScript/ JavaScript、PythonGo语言(无需标记语言或模板)编写配置信息,这使其脱颖而出。Pulumi 专注于原生云架构,包括容器、无服务器函数和数据服务,并为Kubernetes 提供了良好的支持。最近,AWS CDK 的推出对其形成了挑战,但 Pulumi 仍然是该领域唯一的能独立于任何云平台厂商的工具。我们期望将来人们能更广泛地采用 Pulumi,并期待出现能对其提供支持的可行的工具和知识生态系统。

      历史信息
    • Redpanda是一个数据流处理平台。由于具备与Kafka兼容的API,使得开发人员不必像 Kafka 那样进行复杂的安装,就能从 Kafka 生态系统中受益。例如,Redpanda 可以通过下述方法来简化操作,即仅发布一个二进制文件就可进行安装,同时无须诸如 ZooKeeper 这样的外部依赖。为了做到这一点,它实现了 Raft 协议,并进行了全面的测试,以验证其对该协议的实现是正确的。Redpanda 的一项功能(仅对企业客户可用)是使用嵌入式WASM引擎,来实现WebAssembly (WASM)的内联转换。这允许开发人员使用他们所选择的编程语言,并将其编译为WASM,来创建事件转换器。在完成了一系列优化之后,Redpanda 还大大减少了尾部延迟,并提高了吞吐量。Redpanda 是一个令人兴奋的 Kafka 的替代品,值得评估。

      历史信息

    暂缓?

    • 我们之前已经观察到,云供应商会将越来越多的服务推向市场。同时雷达还记录了我们担忧的一些问题,即有些服务还没有完全准备就绪,就被推向市场供人使用。不幸的是,以我们的经验来说,Azure Machine Learning 就属于这类服务。作为 限界低代码平台 领域的 新产品 ,Azure ML 承诺为数据科学家提供更多的便利。但是,最终它没有实现诺言。实际上,我们的数据科学家仍然认为,使用 Python 会更为容易。尽管我们付出了巨大的努力,但仍难以使其规模化。此外缺少足够的文档也是它的另一个问题。所以我们将其移动至暂缓环。

      历史信息
    • 那些由公司或社区所支持的(至少在业界引起关注的)产品,正在不断发展。但有时组织会倾向于在现有的外部产品之上,构建框架或抽象,来满足组织内非常特定的需求,并认为这种适配会比其现有的外部产品具备更多好处。我们发现一些组织试图基于现有外部产品,创建自研基础设施即代码 (IaC) 产品。他们低估了根据其需求不断演进这些自研解决方案而所需投入的工作量。很快他们就会意识到,所基于的外部产品的原始版本要比他们自己的产品好得多。在有些情况下,构建在外部产品之上的抽象,甚至削弱了外部产品的原始功能。虽然目睹过组织自研产品的一些成功案例,但是我们仍然建议要审慎地考虑这种方式。因为这会带来不可忽视的工作量,并且需要确立长期的产品愿景,才能达到预期的结果。

      历史信息
    无法找到需要的信息?

    每期技术雷达中的条目都在试图反映我们在过去六个月中的技术洞见,或许你所搜索的内容已经在前几期中出现过。由于我们有太多想要谈论的内容,有时候不得不剔除一些长期没有发生变化的条目。技术雷达来自于我们的主观经验,而非全面的市场分析,所以你可能会找不到自己最在意的技术条目。

    新的,移进/移出 ,没有变化