Büyük veri mimarisi stiliBig data architecture style

Büyük veri mimarisi, geleneksel veritabanı sistemleri için çok büyük veya karmaşık olan verilerin alımını, işlenmesini ve analizini yönetecek şekilde tasarlanmıştır.A big data architecture is designed to handle the ingestion, processing, and analysis of data that is too large or complex for traditional database systems.

Büyük veri mimarisi stili mantıksal diyagramı

Büyük veri çözümleri genellikle aşağıdaki iş yükü türlerinden bir veya daha fazlasını içerir:Big data solutions typically involve one or more of the following types of workload:

  • Bekleyen büyük veri kaynaklarının toplu işlenmesi.Batch processing of big data sources at rest.
  • Hareket halindeki büyük verilerin gerçek zamanlı işlenmesi.Real-time processing of big data in motion.
  • Büyük verilerin etkileşimli incelenmesi.Interactive exploration of big data.
  • Tahmine dayalı analiz ve makine öğrenimi.Predictive analytics and machine learning.

Büyük veri mimarilerinin çoğu, aşağıdaki bileşenlerin bazılarını veya tümünü içerir:Most big data architectures include some or all of the following components:

  • Veri kaynakları: Tüm büyük veri çözümleri bir veya daha fazla veri kaynağıyla başlar.Data sources: All big data solutions start with one or more data sources. Örneklere şunlar dahildir:Examples include:

    • İlişkisel veritabanları gibi uygulama verisi depoları.Application data stores, such as relational databases.
    • Uygulamalar tarafından üretilen web sunucusu günlük dosyaları gibi statik dosyalar.Static files produced by applications, such as web server log files.
    • IoT cihazları gibi gerçek zamanlı veri kaynakları.Real-time data sources, such as IoT devices.
  • Veri depolama: Toplu işleme yönelik veriler genellikle çeşitli biçimlerdeki büyük dosyaları yüksek miktarlarda tutabilen bir dağıtılmış dosya deposunda depolanır.Data storage: Data for batch processing operations is typically stored in a distributed file store that can hold high volumes of large files in various formats. Bu tür depolara genelde veri gölü adı verilir.This kind of store is often called a data lake. Bu depolamayı uygulamak seçenekleri arasında Azure Depolama'daki blob kapsayıcıları ve Azure Data Lake Store bulunur.Options for implementing this storage include Azure Data Lake Store or blob containers in Azure Storage.

  • Toplu işlem: Veri kümeleri çok büyük olduğundan büyük veri çözümleri genellikle uzun süre çalışan toplu işler aracılığıyla verileri filtreleyerek, toplayarak ve diğer yollardan analize hazırlayarak veri dosyalarını işlemelidir.Batch processing: Because the data sets are so large, often a big data solution must process data files using long-running batch jobs to filter, aggregate, and otherwise prepare the data for analysis. Bu işler, çoğu zaman kaynak dosyaların okunması, işlenmesi ve çıktının yeni dosyalara yazılmasını içerir.Usually these jobs involve reading source files, processing them, and writing the output to new files. Seçenekler arasında Azure Data Lake Analytics’te U-SQL işleri çalıştırma, bir HDInsight Hadoop kümesinde Hive, Pig veya özel Map/Reduce işleri kullanma veya bir HDInsight Spark kümesinde Java, Scala veya Python programları kullanma bulunur.Options include running U-SQL jobs in Azure Data Lake Analytics, using Hive, Pig, or custom Map/Reduce jobs in an HDInsight Hadoop cluster, or using Java, Scala, or Python programs in an HDInsight Spark cluster.

  • Gerçek zamanlı ileti alımı: Çözüm gerçek zamanlı kaynaklar içeriyorsa mimarinin akış işlemek için gerçek zamanlı iletileri yakalayıp depolayacak bir yol içermesi gerekir.Real-time message ingestion: If the solution includes real-time sources, the architecture must include a way to capture and store real-time messages for stream processing. Bu yol, gelen iletilerin işlenmek üzere bir klasöre bırakıldığı basit bir veri deposu olabilir.This might be a simple data store, where incoming messages are dropped into a folder for processing. Ancak, birçok çözüm ileti alım deposunun iletiler için bir arabellek görevi görmesini, ayrıca ölçeği genişletme işlemini, güvenilir teslimi ve diğer iletiyi kuyruğa alma semantiğini desteklemesini gerektirir.However, many solutions need a message ingestion store to act as a buffer for messages, and to support scale-out processing, reliable delivery, and other message queuing semantics. Seçenekler Azure Event Hubs, Azure IoT Hub ve Kafka’yı içerir.Options include Azure Event Hubs, Azure IoT Hubs, and Kafka.

  • Stream işleme: Çözümün, gerçek zamanlı iletileri yakaladıktan sonra filtreleme, toplama ve diğer verileri analize hazırlama işlemleriyle bu iletileri işlemesi gerekir.Stream processing: After capturing real-time messages, the solution must process them by filtering, aggregating, and otherwise preparing the data for analysis. İşlenen akış verileri daha sonra bir çıkış havuzuna yazılır.The processed stream data is then written to an output sink. Azure Stream Analytics, sınırsız akışlar üzerinde sürekli çalıştırılan SQL sorgularına dayalı yönetilen bir akış işleme hizmeti sağlar.Azure Stream Analytics provides a managed stream processing service based on perpetually running SQL queries that operate on unbounded streams. Ayrıca bir HDInsight kümesinde Storm ve Spark Streaming gibi açık kaynaklı Apache akış teknolojileri kullanabilirsiniz.You can also use open source Apache streaming technologies like Storm and Spark Streaming in an HDInsight cluster.

  • Analitik veri deposu: Büyük veri çözümlerinin çoğu, verileri analiz için hazırlar ve sonra işlenen verileri analiz araçları kullanılarak sorgulanabilecek yapılandırılmış bir biçimde sunar.Analytical data store: Many big data solutions prepare data for analysis and then serve the processed data in a structured format that can be queried using analytical tools. Bu sorgulara hizmet veren analitik veri deposu, birçok geleneksel iş zekası (BI) çözümünde görüldüğü gibi Kimball tarzında ilişkisel bir veri ambarı olabilir.The analytical data store used to serve these queries can be a Kimball-style relational data warehouse, as seen in most traditional business intelligence (BI) solutions. Alternatif olarak, veriler HBase gibi düşük gecikme süreli bir NoSQL teknolojisi veya dağıtılmış veri deposundaki veri dosyalarının meta verilerle özetini sağlayan etkileşimli bir Hive veritabanı aracılığıyla sunulabilir.Alternatively, the data could be presented through a low-latency NoSQL technology such as HBase, or an interactive Hive database that provides a metadata abstraction over data files in the distributed data store. Azure SQL Veri Ambarı, büyük ölçekli, bulut tabanlı veri ambarlamaya yönelik yönetilen bir hizmet sağlar.Azure SQL Data Warehouse provides a managed service for large-scale, cloud-based data warehousing. HDInsight; Interactive Hive, HBase ve analiz için verileri sunmak amacıyla da kullanılabilen Spark SQL’i destekler.HDInsight supports Interactive Hive, HBase, and Spark SQL, which can also be used to serve data for analysis.

  • Analiz ve Raporlama: Büyük veri çözümlerinin çoğunun amacı analiz ve raporlama aracılığıyla veriler hakkında öngörüler sağlamaktır.Analysis and reporting: The goal of most big data solutions is to provide insights into the data through analysis and reporting. Mimari, kullanıcılara veri analizi desteği sağlamak amacıyla Azure Analysis Services’te çok boyutlu OLAP küpü veya tablo verisi modeli gibi bir veri modelleme katmanı içerebilir.To empower users to analyze the data, the architecture may include a data modeling layer, such as a multidimensional OLAP cube or tabular data model in Azure Analysis Services. Ayrıca, Microsoft Power BI veya Microsoft Excel'deki modelleme ve görselleştirme teknolojilerini kullanarak self servis BI işlemlerini de destekleyebilir.It might also support self-service BI, using the modeling and visualization technologies in Microsoft Power BI or Microsoft Excel. Analiz ve raporlama, veri uzmanları veya veri analistlerinin etkileşimli veri incelemelerini de içerir.Analysis and reporting can also take the form of interactive data exploration by data scientists or data analysts. Azure hizmetlerinin çoğu bu senaryolar için Jupyter gibi analitik not defterlerini destekleyerek söz konusu kullanıcıların mevcut Python veya R becerilerinden yararlanmasına olanak sağlar. Büyük ölçekli veri incelemeleri için Microsoft R Server’ı tek başına veya Spark ile kullanabilirsiniz.For these scenarios, many Azure services support analytical notebooks, such as Jupyter, enabling these users to leverage their existing skills with Python or R. For large-scale data exploration, you can use Microsoft R Server, either standalone or with Spark.

  • Orchestration: Büyük veri çözümlerinin çoğu, iş akışlarıyla temsil edilen şekilde yinelenen veri işleme faaliyetlerinden oluşur. Bu iş akışları kaynak verileri dönüştürür, verileri çeşitli kaynaklar ve havuzlar arasında taşır, işlenen verileri bir analitik veri deposuna yükler ya da sonuçları doğrudan bir rapora veya panoya gönderir.Orchestration: Most big data solutions consist of repeated data processing operations, encapsulated in workflows, that transform source data, move data between multiple sources and sinks, load the processed data into an analytical data store, or push the results straight to a report or dashboard. Bu iş akışlarını otomatik hale getirmek için Azure Data Factory veya Apache Oozie ve Sqoop gibi bir düzenleme teknolojisi kullanabilirsiniz.To automate these workflows, you can use an orchestration technology such Azure Data Factory or Apache Oozie and Sqoop.

Azure, büyük veri mimarisinde kullanılabilecek birçok hizmet içerir.Azure includes many services that can be used in a big data architecture. Bu hizmetler kabaca iki kategoriye ayrılır:They fall roughly into two categories:

  • Yönetilen hizmetler; Azure Data Lake Store, Azure Data Lake Analytics, Azure Veri Ambarı, Azure Stream Analytics, Azure Olay Hub’ı, Azure IoT Hub ve Azure Data Factory’yi içerir.Managed services, including Azure Data Lake Store, Azure Data Lake Analytics, Azure Data Warehouse, Azure Stream Analytics, Azure Event Hub, Azure IoT Hub, and Azure Data Factory.
  • Apache Hadoop platformunu temel alan açık kaynaklı teknolojiler HDFS, HBase, Hive, Pig, Spark, Storm, Oozie, Sqoop ve Kafka’yı içerir.Open source technologies based on the Apache Hadoop platform, including HDFS, HBase, Hive, Pig, Spark, Storm, Oozie, Sqoop, and Kafka. Bu teknolojiler, Azure’da Azure HDInsight hizmetinde kullanılabilir.These technologies are available on Azure in the Azure HDInsight service.

Bu seçenekler birbirini dışlamaz ve birçok çözüm, açık kaynaklı teknolojiler ile Azure hizmetlerini birleştirir.These options are not mutually exclusive, and many solutions combine open source technologies with Azure services.

Bu mimarinin kullanılacağı durumlarWhen to use this architecture

Aşağıdakileri yapmanız gerektiğinde bu mimari stilini göz önünde bulundurun:Consider this architecture style when you need to:

  • Geleneksel bir veritabanı için çok büyük hacme sahip veri depolama ve işleme.Store and process data in volumes too large for a traditional database.
  • Yapılandırılmamış verileri analiz ve raporlama için dönüştürme.Transform unstructured data for analysis and reporting.
  • Sınırsız veri akışlarını gerçek zamanlı olarak veya düşük gecikme süresiyle yakalama, işleme ve analiz etme.Capture, process, and analyze unbounded streams of data in real time, or with low latency.
  • Azure Machine Learning veya Microsoft Bilişsel Hizmetler’i kullanma.Use Azure Machine Learning or Microsoft Cognitive Services.

AvantajlarBenefits

  • Teknoloji seçenekleri.Technology choices. HDInsight kümelerinde Azure yönetilen hizmetleri ile Apache teknolojilerini eşleştirip bir araya getirerek mevcut becerilerden veya teknoloji yatırımlarından yararlanabilirsiniz.You can mix and match Azure managed services and Apache technologies in HDInsight clusters, to capitalize on existing skills or technology investments.
  • Paralel çalışma aracılığıyla performans.Performance through parallelism. Büyük veri çözümleri paralel çalışmadan yararlanarak büyük miktarda veriye göre ölçeklendirilebilen yüksek performanslı çözümlere olanak sağlar.Big data solutions take advantage of parallelism, enabling high-performance solutions that scale to large volumes of data.
  • Esnek ölçek.Elastic scale. Büyük veri mimarisinin tüm bileşenleri, ölçek genişletme sağlanmasını destekler. Böylece çözümünüzü küçük veya büyük iş yüklerine göre ayarlayabilir ve yalnızca kullandığınız kaynaklar için ödeme yaparsınız.All of the components in the big data architecture support scale-out provisioning, so that you can adjust your solution to small or large workloads, and pay only for the resources that you use.
  • Mevcut çözümlerle birlikte çalışabilirlik.Interoperability with existing solutions. Büyük veri mimarisinin bileşenleri ayrıca IoT işleme ve kurumsal BI çözümleri için de kullanılır. Bu sayede tüm veri iş yüklerini kapsayan tümleşik bir çözüm oluşturabilirsiniz.The components of the big data architecture are also used for IoT processing and enterprise BI solutions, enabling you to create an integrated solution across data workloads.

ZorluklarChallenges

  • Karmaşıklık.Complexity. Büyük veri çözümleri çok karmaşık olabilir. Çeşitli veri kaynaklarından veri alımı gerçekleştirmek için çok sayıda bileşen vardır.Big data solutions can be extremely complex, with numerous components to handle data ingestion from multiple data sources. Büyük veri süreçleri oluşturmak, test etmek ve bu çözümlerin sorunlarını gidermek oldukça zor olabilir.It can be challenging to build, test, and troubleshoot big data processes. Ayrıca, performansı iyileştirmek için birden çok sistem üzerindeki çok sayıda yapılandırma ayarının kullanılması gerekebilir.Moreover, there may be a large number of configuration settings across multiple systems that must be used in order to optimize performance.
  • Beceriler.Skillset. Büyük veri teknolojilerinin çoğu yüksek ölçüde özelleştirilmiştir ve daha genel uygulama mimarilerinde pek rastlanmayan altyapılardan ve dillerden yararlanır.Many big data technologies are highly specialized, and use frameworks and languages that are not typical of more general application architectures. Öte yandan, büyük veri teknolojileri daha iyi bilinen dilleri temel alan yeni API’ler geliştirmektedir.On the other hand, big data technologies are evolving new APIs that build on more established languages. Örneğin, Azure Data Lake Analytics’teki U-SQL dili Transact-SQL ve C# dillerini temel alır.For example, the U-SQL language in Azure Data Lake Analytics is based on a combination of Transact-SQL and C#. Benzer şekilde Hive, HBase ve Spark için kullanılabilecek SQL tabanlı API’ler vardır.Similarly, SQL-based APIs are available for Hive, HBase, and Spark.
  • Teknolojik olgunluk.Technology maturity. Büyük veri için kullanılan teknolojilerin birçoğu gelişmektedir.Many of the technologies used in big data are evolving. Hive ve Pig gibi temel Hadoop teknolojileri istikrarlı bir hale gelmiş olsa da Spark gibi yeni teknolojiler her yeni sürümde kapsamlı değişiklikler ve iyileştirmeler sunmaktadır.While core Hadoop technologies such as Hive and Pig have stabilized, emerging technologies such as Spark introduce extensive changes and enhancements with each new release. Azure Data Lake Analytics ve Azure Data Factory gibi yönetilen hizmetler diğer Azure hizmetlerine göre daha yenidir ve büyük olasılıkla zaman içinde gelişecektir.Managed services such as Azure Data Lake Analytics and Azure Data Factory are relatively young, compared with other Azure services, and will likely evolve over time.
  • Güvenlik.Security. Büyük veri çözümleri, genellikle tüm statik verileri merkezi bir veri gölünde depolar.Big data solutions usually rely on storing all static data in a centralized data lake. Bu verilere güvenli bir şekilde erişmek, özellikle verilerin çok sayıda uygulama ve platform tarafından alınıp tüketilmesi gerektiğinde oldukça zorlu olabilir.Securing access to this data can be challenging, especially when the data must be ingested and consumed by multiple applications and platforms.

En iyi uygulamalarBest practices

  • Paralel çalışmadan yararlanma.Leverage parallelism. Büyük veri işleme teknolojilerinin çoğu, iş yükünü birden çok işleme birimi arasında dağıtır.Most big data processing technologies distribute the workload across multiple processing units. Bunun için statik veri dosyalarının bölünebilir bir biçimde oluşturulup depolanması gerekir.This requires that static data files are created and stored in a splittable format. HDFS gibi dağıtılmış dosya sistemleri okuma ve yazma performansını iyileştirebilir. Gerçek işleme birden çok küme düğümü tarafından paralel olarak gerçekleştirilir ve böylece toplam iş süresi kısalır.Distributed file systems such as HDFS can optimize read and write performance, and the actual processing is performed by multiple cluster nodes in parallel, which reduces overall job times.

  • Verileri bölümleme.Partition data. Toplu işlemler genellikle haftalık veya aylık gibi yinelenen bir zamanlamaya göre gerçekleşir.Batch processing usually happens on a recurring schedule — for example, weekly or monthly. Veri dosyalarını ve tablo gibi veri yapılarını işleme zamanlamasıyla uyumlu zaman dönemlerine göre bölümleyin.Partition data files, and data structures such as tables, based on temporal periods that match the processing schedule. Böylece veri alımı ve iş zamanlaması basitleşir ve hataların giderilmesi kolaylaşır.That simplifies data ingestion and job scheduling, and makes it easier to troubleshoot failures. Ayrıca Hive, U-SQL veya SQL sorgularında kullanılan tabloların bölümlenmesi sorgu performansını önemli ölçüde iyileştirebilir.Also, partitioning tables that are used in Hive, U-SQL, or SQL queries can significantly improve query performance.

  • Okuma sırasında şema belirleme semantiğini uygulama.Apply schema-on-read semantics. Veri gölü kullanılması yapılandırılmış, yarı yapılandırılmış veya yapılandırılmamış olan farklı biçimlerdeki dosyaların depolanmasını bir araya getirmenize olanak sağlar.Using a data lake lets you to combine storage for files in multiple formats, whether structured, semi-structured, or unstructured. Verilere depolanırken değil, işlenirken bir şema uygulayan okuma sırasında şema belirleme semantiğini kullanın.Use schema-on-read semantics, which project a schema onto the data when the data is processing, not when the data is stored. Böylece çözümün esnek olması sağlanır ve veri alımı sırasında veri doğrulama ve tür denetimi nedeniyle performans sorunları yaşanması önlenir.This builds flexibility into the solution, and prevents bottlenecks during data ingestion caused by data validation and type checking.

  • Verileri yerinde işleme.Process data in-place. Geleneksel BI çözümleri verileri bir veri ambarına taşımak için genellikle ayıklama, dönüştürme ve yükleme (ETL) sürecini kullanır.Traditional BI solutions often use an extract, transform, and load (ETL) process to move data into a data warehouse. Büyük veri çözümleri, daha yüksek miktarda ve daha farklı biçimlerdeki veriler için genellikle dönüştürme, ayıklama ve yükleme (TEL) gibi ETL’nin farklı çeşitlerini kullanır.With larger volumes data, and a greater variety of formats, big data solutions generally use variations of ETL, such as transform, extract, and load (TEL). Bu yaklaşımda veriler dağıtılmış veri deposunda işlenerek gerekli yapıya dönüştürülür ve ardından dönüştürülen veriler analitik veri deposuna taşınır.With this approach, the data is processed within the distributed data store, transforming it to the required structure, before moving the transformed data into an analytical data store.

  • Kullanım ve süre maliyetlerini dengeleme.Balance utilization and time costs. Toplu işleme işleri için iki faktörü göz önünde bulundurmak önemlidir: İşlem düğümlerinin birim başına maliyeti ve işi tamamlamak için bu düğümleri kullanmanın dakika başına maliyeti.For batch processing jobs, it's important to consider two factors: The per-unit cost of the compute nodes, and the per-minute cost of using those nodes to complete the job. Örneğin, bir toplu iş dört küme düğümüyle sekiz saat sürebilir.For example, a batch job may take eight hours with four cluster nodes. Ancak, iş dört düğümün hepsini yalnızca ilk iki saat boyunca kullanıyor ve bu noktadan sonra yalnızca iki düğüm gerekiyor olabilir.However, it might turn out that the job uses all four nodes only during the first two hours, and after that, only two nodes are required. Bu durumda, tüm işin iki düğüm üzerinde çalıştırılması toplam iş süresini artıracak ancak iki katına çıkarmayacaktır ve bu nedenle toplam maliyet daha az olacaktır.In that case, running the entire job on two nodes would increase the total job time, but would not double it, so the total cost would be less. Bazı iş senaryolarında, işleme süresinin daha uzun olması yeterince yararlanılmayan küme kaynakları kullanarak daha yüksek maliyet ödenmesine tercih edilebilir.In some business scenarios, a longer processing time may be preferable to the higher cost of using under-utilized cluster resources.

  • Küme kaynaklarını ayırma.Separate cluster resources. HDInsight kümeleri dağıtırken her iş yükü türü için ayrı küme kaynakları sağlarsanız normalde daha iyi performans elde edersiniz.When deploying HDInsight clusters, you will normally achieve better performance by provisioning separate cluster resources for each type of workload. Örneğin, Spark kümeleri Hive’ı içerse de hem Hive hem de Spark ile kapsamlı işleme gerçekleştirmeniz gerekiyorsa ayrı adanmış Spark ve Hadoop kümeleri dağıtmanız iyi bir fikir olabilir.For example, although Spark clusters include Hive, if you need to perform extensive processing with both Hive and Spark, you should consider deploying separate dedicated Spark and Hadoop clusters. Benzer şekilde, düşük gecikme süreli akış işlemesi için HBase ve Storm’u, toplu işlem için Hive’ı kullanıyorsanız ayrı Storm, HBase ve Hadoop kümeleri dağıtmak isteyebilirsiniz.Similarly, if you are using HBase and Storm for low latency stream processing and Hive for batch processing, consider separate clusters for Storm, HBase, and Hadoop.

  • Veri alımını düzenleme.Orchestrate data ingestion. Bazı durumlarda, mevcut iş uygulamaları toplu işlem yapılacak veri dosyalarını doğrudan Azure depolama blob kapsayıcılarına yazabilir. Dosyalar burada HDInsight veya Azure Data Lake Analytics tarafından kullanılabilir.In some cases, existing business applications may write data files for batch processing directly into Azure storage blob containers, where they can be consumed by HDInsight or Azure Data Lake Analytics. Ancak, genellikle verilerin şirket içi veya dış veri kaynaklarından veri gölüne alımını düzenlemeniz gerekir.However, you will often need to orchestrate the ingestion of data from on-premises or external data sources into the data lake. Bu süreci öngörülebilir ve merkezi olarak yönetilebilir bir şekilde yürütmek için Azure Data Factory veya Oozie tarafından desteklenenler gibi bir düzenleme iş akışı veya işlem hattı kullanın.Use an orchestration workflow or pipeline, such as those supported by Azure Data Factory or Oozie, to achieve this in a predictable and centrally manageable fashion.

  • Hassas verileri erken temizleme.Scrub sensitive data early. Veri alımı iş akışı, hassas verileri sürecin erken aşamalarında temizleyerek veri gölünde depolanmalarını önlemelidir.The data ingestion workflow should scrub sensitive data early in the process, to avoid storing it in the data lake.

IoT mimarisiIoT architecture

Nesnelerin interneti (IOT), büyük veri çözümleri, özelleştirilmiş bir alt kümesidir.Internet of Things (IoT) is a specialized subset of big data solutions. Aşağıdaki diyagramda IoT’ye yönelik olası bir mantıksal mimari gösterilmektedir.The following diagram shows a possible logical architecture for IoT. Diyagramda mimarinin olay akışı bileşenleri vurgulanmaktadır.The diagram emphasizes the event-streaming components of the architecture.

IOT mimarisi diyagramı

Bulut ağ geçidi, düşük gecikmeli güvenilir bir mesajlaşma sistemi kullanarak bulut sınırındaki cihaz olaylarını alır.The cloud gateway ingests device events at the cloud boundary, using a reliable, low latency messaging system.

Cihazlar olayları bulut ağ geçidine doğrudan veya bir alan ağ geçidi üzerinden gönderebilir.Devices might send events directly to the cloud gateway, or through a field gateway. Alan ağ geçidi genellikle cihazlarla aynı konumda olan ve olayları alıp bulut ağ geçidine ileten özel bir cihaz veya yazılımdır.A field gateway is a specialized device or software, usually colocated with the devices, that receives events and forwards them to the cloud gateway. Alan ağ geçidi aynı zamanda ham cihaz olaylarını yeniden işleyerek filtreleme, toplama veya protokol dönüştürme gibi işlevler de gerçekleştirebilir.The field gateway might also preprocess the raw device events, performing functions such as filtering, aggregation, or protocol transformation.

Alım sonrasında olaylar, verileri (örneğin, depolamaya) yönlendirebilen ya da analiz ve diğer işlemleri gerçekleştirebilen bir veya birden çok akış işlemcisinden geçer.After ingestion, events go through one or more stream processors that can route the data (for example, to storage) or perform analytics and other processing.

Aşağıda sık kullanılan bazı işleme türleri verilmiştir.The following are some common types of processing. (Bu liste tam kapsamlı değildir.)(This list is certainly not exhaustive.)

  • Arşivleme veya toplu analiz amacıyla olay verilerini soğuk depolamaya yazma.Writing event data to cold storage, for archiving or batch analytics.

  • Etkin yol analizi: anormallikleri algılamak, toplanan zaman pencereleri üzerinden düzenleri tanımak veya akışta belirli bir koşul oluştuğunda uyarıları tetiklemek için olay akışını gerçek zamanlıya yakın olarak analiz etme.Hot path analytics, analyzing the event stream in (near) real time, to detect anomalies, recognize patterns over rolling time windows, or trigger alerts when a specific condition occurs in the stream.

  • Cihazlardan alınan, bildirim ve alarm gibi telemetri dışı özel ileti türlerini işleme.Handling special types of non-telemetry messages from devices, such as notifications and alarms.

  • Makine öğrenimi.Machine learning.

Gri gölgeli kutular bir IoT sisteminin, doğrudan olay akışıyla bağlantılı olmayan ancak bütünlük açısından buraya dahil edilen bileşenlerini gösterir.The boxes that are shaded gray show components of an IoT system that are not directly related to event streaming, but are included here for completeness.

  • Cihaz kayıt defteri, cihaz kimlikleri ve genellikle konum gibi cihaz meta verileri de dahil olmak üzere sağlanan cihazlardan oluşan bir veritabanıdır.The device registry is a database of the provisioned devices, including the device IDs and usually device metadata, such as location.

  • Sağlama API’si, yeni cihazların sağlanmasına ve kaydedilmesine yönelik olarak sık kullanılan bir dış arabirimdir.The provisioning API is a common external interface for provisioning and registering new devices.

  • Bazı IoT çözümleri komut ve denetim iletilerinin cihazlara gönderilmesini sağlar.Some IoT solutions allow command and control messages to be sent to devices.

Bu bölümde IoT’nin son derece yüksek düzey bir görünümü sunulmaktadır ve dikkate alınması gereken çok sayıda ince fark ve zorluk söz konusudur.This section has presented a very high-level view of IoT, and there are many subtleties and challenges to consider. Daha ayrıntılı bir başvuru mimarisi ve tartışma için bkz. Microsoft Azure IoT Reference Architecture (Microsoft Azure IoT Başvuru Mimarisi) (indirilebilir PDF).For a more detailed reference architecture and discussion, see the Microsoft Azure IoT Reference Architecture (PDF download).

Sonraki adımlarNext steps