この記事では、簡単に技術的な課題は、現在主流のビッグデータ・アーキテクチャ・モデルとその発展を議論するために、場面に対処する必要がある大規模なデータを分析します。最後に、私たちはより良いデータアーキテクチャに大きなコモンモードを達成するために、ストレージ・クラウド・コンピューティング・コンポーネントを組み合わせる方法を説明しますと、パターンは、典型的なデータ処理のシナリオをカバーすることができます。
データ処理の課題
さて、このような金融セクターなどの大規模なデータ解析システムの産業と技術のニーズが増えて、ビッグデータシステムを使用する必要があるのVaR（リスクでの値）または機械学習プログラム信用リスク管理、小売、食品・飲料業界は、大規模なデータシステムを必要と組み合わせます補助販売決定、IOTさまざまなシナリオを実現するには、大規模なデータ集計・分析システムはシーケンシャルなデータを持続必要で、大手テクノロジー企業は、それほどの大規模なデータ分析段階を構築し、する必要があります。
ビューの抽象的なポイント、シーンは、我々がほぼ同じ技術的な課題に直面している、これらの要件分析システムをサポートしています。
- リアルタイムのビジネス分析および履歴データの範囲にわたってリアルタイムデータは、両方の低レイテンシ分析の需要、履歴データはまた、PBレベルの探索データ解析のために要求されます。
- 信頼性とスケーラビリティの問題データの傾向の大きさは、成長するとコスト管理を確保しながら、信頼性とスケーラビリティのニーズを満たすために、分散ストレージシステムを導入する必要性を継続している間、ユーザーは、過去のデータの膨大な量を格納することができます。
- ディープスタック技術、コンポーネントストリーム、ストレージシステム、コンピューティングコンポーネントを合成する必要があります。
- 操作およびメンテナンス要件は、データアーキテクチャの制御を維持するために、高い大規模、複雑かつ困難であり得ます。
ビッグデータのインフラ開発の説明
ラムダアーキテクチャ
ラムダ・アーキテクチャは、フローおよびバッチシステムで別々に、その核となるアイデアは、バッチ、ストリーム処理システム内の追加の並列的に書き込まれる不変データであり、同じ計算ロジックビッグデータ処理アーキテクチャの最も深遠な影響であります実装と問い合わせ相流における統合とバッチの計算ビュー、ユーザに提示。ラムダは、比較的信頼性の低いストリーム処理ながら、バッチエラーに比較的単純で容易著者ネイサンマルツと仮定されるので、ストリームプロセッサは、近似アルゴリズム、すばやくビューを生成するためのおおよその更新、及び遅いバッチ処理システム内に使用することができます同じビューの修正バージョンを生成するために、正確なアルゴリズム。
（Https://intranetproxy.alipay.com/skylark/lark/0/2019/png/38653/1558863881987-4ef2cea5-8960-4270-9d60-03f2efe4e985.png#align=left&display=inline&height=800&name=lambda%E5%A4 ％A7％のE6％95％B0％以下のE6の％の8Dの％AE％のE6％9E％B6の％のE6％9E％84％20％281％の29.pngある＆originHeight = 800＆originWidth = 1757＆サイズ= 53964＆ステータス= DONE＆幅= 1757）
/>図1ラムダアーキテクチャ例
の典型的なデータフローのラムダアーキテクチャである（[[1]] http://lambda-architecture.net/） ：
- すべてのデータは、バッチ層と処理層の流れを記述する必要があります。
- バッチ層の二つの機能：（I）管理マスタデータセット（不変ストレージ、追加データの書き込みの合計量）、（II）事前計算バッチ図です。
- サービス層は、低遅延、アドホッククエリモードビューをサポートするために、バッチビュー索引を確立します。
- 層としては、流速は、リアルタイムでデータの近似リアルタイムビューを計算する計算され、クイックビューの高遅延補償バッチ図です。
- すべてのクエリは、バッチビューとリアルタイムビューを結合する必要があります。
ラムダアーキテクチャは不変生成されたイベントストリーム上のビューの原則を促進するために設計されており、必要なときに、需要の時間発展を超えるシステムの原理は、あなたが常に適切と会いするのは実用的で新しいビューを作成できることを保証するために、イベントを再処理することができます過去のデータとリアルタイムのデータ分析ニーズの変化。
四つの課題ラムダアーキテクチャ
ラムダアーキテクチャは非常に複雑であり、データの書き込み、記憶、ドッキング・コンピューティング・コンポーネントとプレゼンテーション層は、サブ最適なソリューションであるために複雑な問題です。
- 筆記層は、ラムダデータが抽象書き込まれませんが、データを書き込むための上位アプリケーションへの逆噴射のフローシステムのバッチの一貫性を倍増します。
- データの更新をサポートしていないマスターデータセットの代表としてHDFSへの格納は、常に更新されたデータソースのみデータ更新、データの待ち時間を維持するためにHDFSの途中に定期的なスナップショットで全額をコピーして、比較的大きな費用がかかります。
- それぞれ、必要な計算ロジックフローバッチフレームワークを実現し、実行、および同様のストーム・ストリーム・コンピューティング・フレームワークとバッチフレームワークでのHadoop MRは仕事の開発、デバッグを行うために、アンケートはより複雑です。
- 結果ビューが解析低レイテンシを必要とするサポート、通常、得られたデータは、列分析システムに維持する必要があり、制御の下でそのコストを確実にします。
フローバッチ統合ラムダアーキテクチャ
質問3は、実装し、フロー問題ラムダアーキテクチャ用のバッチ・フレームワークを実行するために必要なそれぞれ計算論理は、多くの計算エンジンは、スパーク及びFLINKとして、開発するための演算部ラムダアーキテクチャを簡素化するためにグラントの流れの方向を統一し始めています。リアルタイムイベントと歴史的なイベントの再生を処理するために、同じ処理エンジンには1、2障害が発生した場合は、まったく同じ結果を計算するかどうかを確認するためにセマンティクス一度正確にサポートしています。3イベントの時間をサポートするために：統一フローバッチを達成するために、通常のサポートが必要です。窓掛け処理は時間ではありません。
カッパアーキテクチャ
カッパアーキテクチャは、カッパは、算出された流量を計算することによってのみ、データリンク、ラムダも計算フロー計算を算出し、合わせたバッチのビューとは異なり、ジェイKrepsによって提案され、ビューを生成します。カッパは、イベントを再処理するために同じ原理を使用して、クラスのニーズのための履歴データ分析、カッパは、データの長期保存が必要なビュー過去のデータを再生成し、注文したログ・ストリームに再流入計算エンジンすることができます。
図3ビッグデータアーキテクチャカッパ
カッパリンク3と、書き込みデータ演算ロジックの複雑な問題を合理化することにより、ソリューション、それはまだ同様のメッセージ・キュー・ストレージ・カフカ、特にストレージで、ストレージおよびディスプレイの問題を解決しません長期ログデータは、データは、溶液をバイパスし、大規模なストレージ・コストを圧縮できないデータメッセージシステムサポートするために階層ストレージを使用することである（このようなパルサーのように、履歴メッセージをサポートするクラウドストレージシステムに格納されている）が、履歴データログのストレージを階層唯一のカッパ埋め戻し操作のために、データの利用率が低いままです。
ラムダとカッパシーン差：
- そのような様々なシナリオの時系列データ、天然に存在する時間ウィンドウとして追加のみのデータを、あるカッパラムダは、アーキテクチャに代わるものではありませんが、その簡易版は、カッパ自体がシーン書かれているビジネスのニーズを分析することで、より良い、バッチ処理のサポートを落としました直接補償と歴史的なミッション要求のリアルタイム計算を満たすために計算概念、ストリーミング。
- ラムダは、直接バッチ処理をサポートしているため、アドホックのニーズに適し多くは、このようなアナリストは、できるだけ早く履歴データの探索を分析するための条件のいずれかの組み合わせを押して、リアルタイムのニーズのいくつかを持って、期待する必要のあるデータとして、履歴データのシーンが照会されます得られた結果は、バッチは、より直接的かつ効率的な方法これらのニーズを満たすことができます。
カッパ+
カッパ+はユーバーストリーミングデータ処理アーキテクチャを提示する、その核となるアイデアは、バックフィル計算を計算するために一緒にリアルタイムおよび履歴データを、直接読み出しフロー計算フレームワークHDFSクラスデータ倉庫番号を作ることです。ステートレスタスクと時間窓の割り当てにカッパ+データタスクは、ステートレスタスクは比較的単純であり、時間窓タスクの原理データ妥当並行処理スループット速度の全量をスキャンする時間粒度に応じて格納されたデータを分割する位置の数、Windowsタスクであります時間のパーティションを計算するためのデータのシーケンスの後、パーティションの順番同時内戦、すべてのパーティションは、すべてのソース次のパーティションに入る前に、すべての文書を読み終え、消費者の透かしを更新します。実際には、ユーバーは、数、HUDIサポートの更新を保存する既存の寄木細工のデータを削除するためのフレームワークApacheのHUDIデータウェアハウスを開発しました、また、増分更新は、それによって全身の問題2のストレージの問題を解決し、データの一部を消費サポートしています。>スパーク- - >分析データ図4は、Hadoopのが特徴、完全ユーバー大型データ処理プラットフォームであり 、ユーザはカッパ+データ処理アーキテクチャをカバーします。
（Https://intranetproxy.alipay.com/skylark/lark/0/2019/png/38653/1558914948140-813f4a83-ea52-47b1-ad95-30721dd2af2d.png#align=left&display=inline&height=310&name=image.png&originHeight=482&originWidthサイズ= 1068＆137 167 =＆ステータス=幅= 686＆DONE）
スキーマに関するデータの/>図4ユーバー大Hadoopのデータセット
カッパアーキテクチャハイブリッド分析システム
Lambda和Kappa架构都还有展示层的困难点，结果视图如何支持ad-hoc查询分析，一个解决方案是在Kappa基础上衍生数据分析流程，如下图5，在基于使用Kafka + Flink构建Kappa流计算数据架构，针对Kappa架构分析能力不足的问题，再利用Kafka对接组合ElasticSearch实时分析引擎，部分弥补其数据分析能力。但是ElasticSearch也只适合对合理数据量级的热数据进行索引，无法覆盖所有批处理相关的分析需求，这种混合架构某种意义上属于Kappa和Lambda间的折中方案。
图5 Kafka + Flink + ElasticSearch的混合分析系统
Lambda plus：Tablestore + Blink流批一体处理框架
Lambda plus是基于Tablestore和Blink打造的云上存在可以复用、简化的大数据架构模式，架构方案全serverless即开即用，易搭建免运维。
表格存储（Tablestore）是阿里云自研的NoSQL多模型数据库，提供PB级结构化数据存储、千万TPS以及毫秒级延迟的服务能力，表格存储提供了通道服务（TunnelService）支持用户以按序、流式地方式消费写入表格存储的存量数据和实时数据，同时表格存储还提供了多元索引功能，支持用户对结果视图进行实时查询和分析。
Blink是阿里云在Apache Flink基础上深度改进的实时计算平台，Blink旨在将流处理和批处理统一，实现了全新的 Flink SQL 技术栈，在功能上，Blink支持现在标准 SQL 几乎所有的语法和语义，在性能上，Blink也比社区Flink更加强大。
在TableStore + blink的云上Lambda架构中，用户可以同时使用表格存储作为master dataset和batch&stream view，批处理引擎直读表格存储产生batch view，同时流计算引擎通过Tunnel Service流式处理实时数据，持续生成stream view。
(https://intranetproxy.alipay.com/skylark/lark/0/2019/png/38653/1558941898885-eca6ebb4-7a50-41b3-a82a-e832e7109819.png#align=left&display=inline&height=945&name=Tablestore%20%2B%20blink%20Lambda%E6%9E%B6%E6%9E%84%20%281%29.png&originHeight=945&originWidth=1880&size=56079&status=done&width=1880)
/>图6 Tablestore + Blink的Lambda plus大数据架构
如上图6，其具体组件分解：
-
Lambda batch层：
- Tablestore直接作为master dataset，支持用户直读，配合Tablestore多元索引，用户的线上服务直读、ad-hoc查询master dataset并将结果返回给用户；
- blink批处理任务向Tablestore下推SQL的查询条件，直读Tablestore master dataset，计算batch view，并将batch view重新写回Tablestore；
-
Streaming层:
- blink流处理任务通过表格存储TunnelService API直读master dataset中的实时数据，持续产生stream view；
- Kappa架构的backfill任务，可以通过建立全量类型数据通道，流式消费master dataset的存量数据，从新计算；
-
Serving层：
- 为存储batch view和stream view的Tablestore结果表建立全局二级索引和多元索引，业务可以低延迟、ad-hoc方式查询；
- 针对数据写入的问题，Lambda plus数据只需要写入表格存储，Blink流计算框架通过通道服务API直读表格存储的实时数据，不需要用户双写队列或者自己实现数据同步；
- 存储上，Lambda plus直接使用表格存储作为master dataset，表格存储支持用户tp系统低延迟读写更新，同时也提供了索引功能ad-hoc查询分析，数据利用率高，容量型表格存储实例也可以保证数据存储成本可控；
- 计算上，Lambda plus利用blink流批一体计算引擎，统一流批代码；
- 展示层，表格存储提供了多元索引和全局二级索引功能，用户可以根据解决视图的查询需求和存储体量，合理选择索引方式；
总结，表格存储实现了batch view、master dataset直接查询、stream view的功能全集，Blink实现流批统一，Tablestore加blink的Lambda plus模式可以明显简化Lambda架构的组件数量，降低搭建和运维难度，拓展用户数据价值。
表格存储是如何实现支持上述功能全集的
-
存储引擎的高并发、低延迟特性：
- 表格存储面向在线业务提供高并发、低延迟的访问，并且tps按分区水平扩展，可以有效支持批处理和Kappa backfill的高吞吐数据扫描和流计算按分区粒度并发实时处理；
-
使用通道服务精简架构：
- Tablestore数据通道支持用户以按序、流式地方式消费写入表格存储的存量数据和实时数据，避免Lambda架构引入消息队列系统以及master dataset和队列的数据一致性问题；
-
- 存储在表格存储的batch view和real-time view可以使用多元索引和二级索引实现ad-hoc查询，使用多元索引进行聚合分析计算；
- 同时展示层也可以利用二级索引和多元索引直接查询表格存储master dataset，不强依赖引擎计算结果；
Lambda plus的适用场景
基于Tablestore和Blink的Lambda plus架构，适用于基于分布式NoSQL数据库存储数据的大数据分析场景，如IOT、时序数据、爬虫数据、用户行为日志数据存储等，数据量以TB级为主。典型的业务场景如：
- 大数据舆情分析系统
拓展阅读
可以参考下列资源快速体验表格存储+blink的大数据架构、表格存储多元索引及其相关场景：
如果您对表格存储、Lambda plus感兴趣，欢迎加入【表格存储公开交流群】交流探讨，群号：11789671。
(https://intranetproxy.alipay.com/skylark/lark/0/2019/png/38653/1558944039986-12b9d01d-b82b-43fb-8ff8-25c2b343519d.png#align=left&display=inline&height=495&name=image.png&originHeight=990&originWidth=750&size=187700&status=done&width=375)
参考资料
[1].http://lambda-architecture.net/
[2].http://shop.oreilly.com/product/0636920032175.do, Martin Kleppmann
[3].https://www.oreilly.com/ideas/applying-the-kappa-architecture-in-the-telco-industry, Nicolas SeyvetIgnacio Mulas Viela
[4].https://www.oreilly.com/ideas/questioning-the-lambda-architecture, Jay Kreps
[5].http://milinda.pathirage.org/kappa-architecture.com/
[6].Moving from Lambda and Kappa Architectures to Kappa+ at Uber
[7].https://eng.uber.com/hoodie/, Prasanna Rajaperumal and Vinoth Chandar
[8].https://eng.uber.com/uber-big-data-platform/、レザShiftehfar