この投稿は Claudia Chitu と協力して書かれています。 ACASTのSpyridon Dosis。
2014年に設立され、 Acasta は世界をリードする独立系ポッドキャスト会社で、ポッドキャスト クリエイターとポッドキャスト広告主を究極のリスニング体験に向けてサポートしています。 Acast は、ポッドキャスティングの独立したオープンなエコシステムを擁護することで、成功に必要なツールと収益化を提供してポッドキャスティングを促進することを目指しています。
同社は AWS クラウド サービスを使用して、データ駆動型の製品を構築し、エンジニアリングのベスト プラクティスを拡張しています。成長と収益性の段階において持続可能なデータ プラットフォームを確保するために、同社の技術チームは分散型データ プラットフォームを採用しました。 データメッシュアーキテクチャ.
この投稿では、Acast がデータ メッシュの概念を採用することで、大規模なデータを扱うチーム間の依存関係の結合という課題をどのように克服したかについて説明します。
問題
成長と拡大が加速する中、Acast は世界中に響く課題に直面しました。 Acast は、多様なビジネス ユニットを抱え、組織全体で膨大な量のデータが生成されていることに気づきました。既存のモノリスで集中化されたアーキテクチャは、データ利用者の増大する需要を満たすのに苦労していました。データ エンジニアは、データ インフラストラクチャの維持と拡張がますます困難になり、その結果、データ アクセス、データ サイロ化、データ管理の非効率化が生じていることに気づきました。主な目的は、ビジネス ニーズから始めて、エンドツーエンドのユーザー エクスペリエンスを向上させることでした。
Acast は、運用規模、つまり独立して運用して価値を提供できる人数の世界最大値を達成するために、これらの課題に対処する必要がありました。この場合、Acast は、このモノリス構造と、製品チーム、技術チーム、最終消費者にとって価値実現までの時間がかかるという課題に取り組もうとしました。 AWS アカウントを持たない、運用チームやビジネスチームを含む他の製品チームや技術チームもいることは言及する価値があります。
Acast にはさまざまな数の製品チームがあり、既存のチームを統合したり、分割したり、新しい人を追加したり、単に新しいチームを作成したりすることで継続的に進化しています。過去 2 年間で、それぞれ 10 ~ 20 人で構成される 4 ~ 10 のチームがありました。各チームは、所有権に応じて少なくとも 10 つ、最大 XNUMX 個の AWS アカウントを所有します。これらのアカウントによって生成されたデータの大部分は、ビジネス インテリジェンス (BI) の目的で下流で使用されます。 アマゾンアテナ、毎日何百人ものビジネス ユーザーによって利用されています。
Acast が実装したソリューションは、AWS 上に設計されたデータ メッシュです。このソリューションは、明示的なアーキテクチャ上の決定ではなく、組織構造を反映しています。に従って、 逆コンウェイマニューバ, Acast のテクノロジー アーキテクチャは、ビジネス アーキテクチャと同型性を示します。この場合、ビジネス ユーザーはデータ メッシュ アーキテクチャを通じて、洞察を得るまでの時間を短縮し、ドメイン固有の所有者が誰であるかを直接知ることができるため、コラボレーションが高速化されます。これについては、今後の議論の際にさらに詳しく説明します。 AWS IDおよびアクセス管理 (IAM) ロールが使用されます。これは、ロールの 1 つがビジネス グループ専用であるためです。
成功のパラメータ
Acast は、新しいチーム指向およびドメイン指向のデータ製品とそれに対応するインフラストラクチャとセットアップのブートストラップとスケーリングに成功し、その結果、洞察の収集における摩擦が軽減され、ユーザーと消費者の満足度が向上しました。
導入が成功するには、データ インフラストラクチャ、データ管理、ビジネスの成果のさまざまな側面を評価する必要がありました。彼らは、指標と指標を次のカテゴリに分類しました。
- データの使用 – 消費者と生産者のマッピングによって実現される、誰がどのデータ ソースを使用しているのかを明確に理解します。ユーザーとのディスカッションでは、よりシンプルな方法でデータに迅速にアクセスでき、より構造化されたデータ組織があり、作成者が誰であるかを明確にマッピングできる方が満足していることがわかりました。データドリブンの文化 (データ リテラシー、データ共有、ビジネス ユニット間のコラボレーション) を推進するために多くの進歩が見られました。
- データガバナンス – データ ソースがいつ利用可能になるか (他の詳細とともに) を示すサービス レベル オブジェクトを使用すると、チームは誰に通知すればよいかを把握できるため、データの受信が遅れたり、データに関するその他の問題が発生したりした場合に、より短時間で通知を行うことができます。データスチュワードの役割が設定されたことで、所有権が強化されました。
- データチームの生産性 – Acast は、エンジニアリングの振り返りを通じて、チームがデータ ドメインに関する意思決定の自律性を高く評価していることに気づきました。
- コストとリソース効率 – これは、Acast がスケーリングを有効にしながらアカウント間でデータを読み取ることで、データの重複が減少し、コストが削減されたことを観察した領域です (一部のアカウントでは、データのコピーが 100% 削除されます)。
データ メッシュの概要
データ メッシュは、ドメイン指向のセルフサービス設計 (ソフトウェア開発の観点から) を使用して分散データ アーキテクチャを構築するための社会技術的アプローチであり、エリック エヴァンスのドメイン駆動設計理論とマニュエル パイスとマシュー スケルトンの理論を借用しています。チームトポロジの理論。データ メッシュとは何かを理解するためのコンテキストを確立することが重要です。これにより、その後の技術的な詳細の準備が整い、この投稿で説明する概念がデータ メッシュのより広範なフレームワークにどのように適合するかを理解するのに役立ちます。
Acast の実装について詳しく説明する前に要約すると、データ メッシュの概念は次の原則に基づいています。
- パイプラインが第一の関心事であるのではなく、ドメイン主導型です
- データを製品として提供する
- ユーザーを喜ばせる優れた製品です (データは信頼でき、ドキュメントは入手可能で、簡単に利用できます)
- フェデレーテッド コンピューティング ガバナンスと分散型所有権、つまりセルフサービス データ プラットフォームを提供します。
ドメイン駆動型アーキテクチャ
運用および分析データセットを所有する Acast のアプローチでは、チームはドメインに基づいた所有権で構成され、API 経由で、または Amazon S3 ストレージからプログラムで、または Athena を SQL クエリ エンジンとして使用して、データのプロデューサーから直接読み取ります。 Acast のドメインの例を次の図に示します。
上の図に示されているように、一部のドメインは、異なる所有権を持つ他のドメインの運用エンドポイントまたは分析エンドポイントに疎結合されています。ビジネスへの依存が強い人もいるかもしれませんが、これは予想通りです(一部のポッドキャスターは広告主でもあり、スポンサーシップクリエイティブを作成して自分の番組のキャンペーンを実行したり、Acast のソフトウェアをサービスとして使用して広告を取引したりすることもあります)。
製品としてのデータ
データを製品として扱うには、データ自体、メタデータ、関連するコードとインフラストラクチャという 3 つの主要なコンポーネントが必要になります。このアプローチでは、データ生成を担当するチームを次のように呼びます。 プロデューサー。これらのプロデューサー チームは、消費者に関する深い知識を持ち、データ製品がどのように利用されるかを理解しています。データ作成者によって計画された変更はすべて、事前にすべての利用者に通知されます。この事前通知により、下流のプロセスが中断されないことが保証されます。消費者に事前通知を提供することで、今後の変更に備えて適応するための十分な時間を確保し、スムーズで中断のないワークフローを維持できます。プロデューサーは、初期データセットの新しいバージョンを並行して実行し、コンシューマーに個別に通知し、新しいバージョンの使用を開始するために必要な期間について話し合います。すべてのコンシューマが新しいバージョンを使用している場合、プロデューサは初期バージョンを使用不可にします。
データ スキーマは、チーム間でファイルを共有するために合意された共通の形式 (Acast の場合は Parquet) から推測されます。データはファイル、バッチ イベントまたはストリーム イベントなどで共有できます。各チームは独自の AWS アカウントを持ち、独自のインフラストラクチャを備えた独立した自律的なエンティティとして機能します。オーケストレーションには、 AWSクラウド開発キット (AWS CDK) コードとしてのインフラストラクチャ (IaC) および AWSグルー メタデータ管理のためのデータ カタログ。ユーザーは、より高いビジネス価値を生み出すために、データの表示方法を改善したり、新しいデータ ポイントでデータを充実させたりするよう、プロデューサーにリクエストを行うこともできます。
各チームが AWS アカウントと Athena のデータ カタログ ID を所有しているため、Amazon S3 上の分散データレイクのレンズを通してこれを簡単に確認できます。共通のカタログがすべてのアカウントのすべてのカタログをマッピングしています。
同時に、各チームは他のカタログを自分のアカウントにマッピングし、他のアカウントからのデータとともに生成した独自のデータを使用することもできます。機密データでない限り、データにはプログラムから、または AWSマネジメントコンソール データインフラストラクチャエンジニアに依存せず、セルフサービス方式で実現します。これは、ドメインに依存しないセルフサービス型のデータ共有方法です。製品の発見はカタログ登録を通じて行われます。 Acast は、相互運用性を目的として、全社で共通に合意され採用されているいくつかの標準のみを使用して、データの交換やドメインに依存しないデータの消費における断片化したサイロと摩擦に対処しました。
この原則により、チームはデータが安全で、信頼でき、正確であること、および適切なアクセス制御が各ドメイン レベルで管理されていることを保証できます。さらに、中央アカウントでは、さまざまなタイプの権限とアクセスに対してロールが定義されます。 AWS IAM アイデンティティ センター 権限。すべてのデータセットは、単一の中央アカウントから検出できます。次の図は、その実装方法を示しています。ここでは、2 つの IAM ロールが 2 種類のユーザー (コンシューマ) グループによって引き受けられます。1 つは制限されたデータセット (制限付きデータ) にアクセスできるグループ、もう 1 つは制限されていないデータにアクセスできるグループです。サービス アカウント (データ処理ジョブで使用されるものなど) に対して、これらのロールのいずれかを引き受ける方法もあります。 ApacheAirflowのAmazonマネージドワークフロー (Amazon MWAA) など。
Acast が高度な調整と疎結合アーキテクチャをどのように解決したか
次の図は、Acast のチームがデータを整理し、相互に連携する方法の概念アーキテクチャを示しています。
アキャストが使用したのは、 適切に設計されたフレームワーク 中央アカウントがクラウドで分析ワークロードを実行する方法を改善します。 Acast はツールのレンズを通じて、より優れたモニタリングに取り組むことができました。 コスト最適化、パフォーマンス、セキュリティ。これは、ワークロードを改善できる領域と、自動化されたソリューションを使用して一般的な問題に対処する方法、および成功を測定して KPI を定義する方法を理解するのに役立ちました。これにより、他の方法では見つけるのに時間がかかっていたであろう学習を得る時間が節約されました。 Acast の情報セキュリティ責任者である Spyridon Dosis 氏は次のように述べています。「AWS が常に、マルチアカウント設定の構成、評価、レビューを可能にするツールを先行してリリースしていることに満足しています。これは、分散型組織で働く私たちにとって大きなプラスです。」 Spyridon 氏はさらに、「私たちが大切にしている非常に重要な概念は、AWS セキュリティのデフォルト (S3 バケットのデフォルト暗号化など) です。」と付け加えています。
アーキテクチャ図では、中央データ プラットフォームとして機能する中央アカウントを所有するチームを除き、各チームがデータ プロデューサーになれることがわかり、ビジネス全体像を描くために複数のドメインからロジックをモデル化します。他のすべてのチームは、データ生成者またはデータ消費者になることができます。中央アカウントに接続し、クロスアカウント AWS Glue データカタログを介してデータセットを検出したり、Athena クエリエディターまたは Athena ノートブックで分析したり、カタログを自分の AWS アカウントにマッピングしたりできます。中央の Athena カタログへのアクセスは、オープン データと制限付きデータ アクセスのロールを持つ IAM Identity Center によって実装されます。
非機密データ (オープン データ) の場合、Acast は、次のコード スニペットに示すように、組織が割り当てた ID パラメーターを提供する条件を使用して、データセットがデフォルトで組織全体に読み取り可能なテンプレートを使用します。
財務などの機密データを扱う場合、チームは協力的なデータ スチュワード モデルを使用します。データ スチュワードはリクエスタと協力して、意図された使用例に対するアクセスの正当性を評価します。これらは連携して、セキュリティを維持しながらニーズを満たす適切なアクセス方法を決定します。これには、IAM ロール、サービス アカウント、または特定の AWS サービスが含まれる場合があります。このアプローチにより、技術組織外のビジネス ユーザー (つまり、AWS アカウントを持っていないユーザー) が、必要な情報に独立してアクセスして分析できるようになります。 Acast は、AWS Glue リソースと S3 バケットに対する IAM ポリシーを通じてアクセスを許可することで、セルフサービス機能を提供しながら、人間によるレビューを通じてデリケートなデータを管理します。データ スチュワードの役割は、ユースケースを理解し、セキュリティ リスクを評価し、最終的には分析的な洞察を通じてビジネスを加速するアクセスを促進する上で貴重です。
Acast の使用例では、行レベルまたは列レベルの詳細なアクセス制御は必要なかったため、このアプローチで十分でした。ただし、他の組織では、機密データ フィールドに対してよりきめ細かいガバナンスが必要になる場合があります。そのような場合、次のような解決策が考えられます。 AWSレイクフォーメーション セルフサービスのデータ アクセス モデルを提供しながら、必要な権限を実装できます。詳細については、以下を参照してください。 AWS Lake Formation と AWS Glue を使用してデータ メッシュ アーキテクチャを設計する.
同時に、チームは他のプロデューサーから直接、Amazon S3 から、または API 経由で読み取ることができるため、依存関係が最小限に抑えられ、開発と配信の速度が向上します。したがって、アカウントは同時にプロデューサーとコンシューマーになることができます。各チームは自律しており、独自の技術スタックに対して責任を負います。
追加の学習
アキャストは何を学びましたか?これまで、アーキテクチャ設計が組織構造の影響であることを説明してきました。テクノロジー組織は複数の部門横断的なチームで構成されており、データ メッシュの共通原則に従って新しいチームを立ち上げるのは簡単であるため、Acast はこれが毎回シームレスに進むわけではないことを学びました。 AWS で完全に新しいアカウントを設定するには、チームは同じ手順をたどりますが、独自の特殊性を考慮して、少し異なります。
これにより特定の摩擦が生じる可能性があり、すべてのデータ生成チームがデータ生成者として高い成熟度に達するようにすることは困難です。これは、専門のデータ チームではなく、部門横断的なチームのデータ コンピテンシーが異なることで説明できます。
Acast は、分散型ソリューションを実装することで、進化するビジネス ニーズに合わせてチームを適応させることで、スケーラビリティの課題に効果的に取り組みました。このアプローチにより、高度なデカップリングとアライメントが保証されます。さらに、上流のソースがすぐにわかり、指定された SLA に従って簡単にアクセスできるため、所有権が強化され、問題の特定と解決に必要な時間が大幅に短縮されました。ビジネス ユーザーがより迅速に洞察を得ることができるようになったため、データ サポートに関する問い合わせの量は 50% 以上削減されました。特に、以前はダウンストリーム要求を満たすためだけにコピーされていた数十テラバイトの冗長ストレージを排除することに成功しました。この成果は、クロスアカウント読み取りの実装によって可能になり、これらのパイプラインに関連する開発コストとメンテナンスコストの削減につながりました。
まとめ
Acast は、Inverse Conway Maneuver の法則を使用し、各部門横断的な製品チームが独自の AWS アカウントを持つ AWS サービスを採用して、スケーラビリティ、高い所有権、セルフサービスのデータ消費を可能にするデータ メッシュ アーキテクチャを構築しました。これは、エンジニアリング原則を満たすためにデータの所有権と運用にどのようにアプローチするかという点で、同社にとってはうまく機能しており、その結果、意図的な意図ではなく結果としてデータをメッシュ化することができました。他の組織にとっては、必要なデータ メッシュは異なる可能性があり、アプローチには他の知見がある可能性があります。
結論として、 AWS 上の最新のデータ アーキテクチャ パフォーマンスを犠牲にすることなく、データ製品とデータ メッシュ インフラストラクチャを低コストで効率的に構築できます。
以下は、AWS 上で目的のデータ メッシュを設計するために使用できる AWS サービスの例です。
著者について
クラウディア・チトゥ データ ストラテジストであり、分析分野の影響力のあるリーダーです。彼女は、データへの取り組みを組織の全体的な戦略目標と整合させることに重点を置き、長期計画と持続可能な成長のための指導力としてデータを採用しています。
スピリドン投与量 Acast の情報セキュリティ専門家です。 Spyridon は、企業とユーザーのデータを保護する安全な方法でサービスを設計、実装、運用する組織をサポートします。
スリカント・ダス アマゾン ウェブ サービスの Acceleration Lab ソリューション アーキテクトです。彼はビッグ データ分析とデータ エンジニアリングで 13 年以上の経験があり、信頼性が高く、スケーラブルで効率的なソリューションの構築に取り組んでいます。仕事以外では、旅行を楽しんだり、その経験をソーシャル メディアにブログに書いたりするのが趣味です。
- SEO を活用したコンテンツと PR 配信。 今日増幅されます。
- PlatoData.Network 垂直生成 Ai。 自分自身に力を与えましょう。 こちらからアクセスしてください。
- プラトアイストリーム。 Web3 インテリジェンス。 知識増幅。 こちらからアクセスしてください。
- プラトンESG。 カーボン、 クリーンテック、 エネルギー、 環境、 太陽、 廃棄物管理。 こちらからアクセスしてください。
- プラトンヘルス。 バイオテクノロジーと臨床試験のインテリジェンス。 こちらからアクセスしてください。
- 情報源: https://aws.amazon.com/blogs/big-data/design-a-data-mesh-on-aws-that-reflects-the-envisioned-organization/
- :持っている
- :は
- :not
- :どこ
- $UP
- 10
- 100
- 120
- 13
- 2014
- 2020
- a
- できる
- 私たちについて
- 加速された
- 加速する
- 加速
- アクセス
- データへのアクセス
- アクセス
- アクセス可能な
- 責任がある
- アカウント
- 正確な
- 達成
- 越えて
- 演技
- Action
- 適応する
- 追加
- 住所
- 対処する
- 追加
- 採択
- 広告
- 進める
- 広告業者
- 同意して
- 先んじて
- 目指して
- 整列する
- 整列
- アラインメント
- すべて
- 許す
- ことができます
- 沿って
- また
- 常に
- Amazon
- Amazon Webサービス
- の中で
- 間で
- 量
- an
- 分析的
- 分析論
- 分析します
- および
- とインフラ
- どれか
- アパッチ
- API
- 認める
- アプローチ
- 適切な
- 建築の
- 建築
- です
- AREA
- エリア
- AS
- 側面
- 評価中
- 評価
- 関連する
- 引き受けます
- 想定される
- 保証
- At
- 自動化
- 自律的
- 自治
- 利用できます
- AWS
- AWSグルー
- AWSレイクフォーメーション
- ベース
- BE
- なぜなら
- き
- さ
- BEST
- ベストプラクティス
- より良いです
- の間に
- ビッグ
- ビッグデータ
- ブログ
- ブートストラップ
- より広い
- ビルド
- 建物
- ビジネス
- ビジネス・インテリジェンス
- 焙煎が極度に未発達や過発達のコーヒーにて、クロロゲン酸の味わいへの影響は強くなり、金属を思わせる味わいと乾いたマウスフィールを感じさせます。
- by
- キャンペーン
- 缶
- 機能
- 場合
- 例
- カタログ
- カタログ
- カテゴリ
- センター
- 中央の
- 集中型の
- 一定
- 挑戦する
- 課題
- 挑戦
- チャンピオン
- 変更
- 分類された
- クリア
- クラウド
- クラウドサービス
- コード
- 協業
- 環境、テクノロジーを推奨
- 共同
- 到来
- コマンドと
- 一般に
- 伝えた
- 会社
- コンポーネント
- 妥協する
- 計算的
- コンセプト
- コンセプト
- 概念の
- 結論
- 条件
- お問合せ
- 考えると
- からなる
- からなる
- 構築する
- 消費する
- consumer
- 消費者
- 消費
- コンテキスト
- 連続的に
- controls
- 対応する
- 費用
- コスト削減
- コスト
- 可能性
- 結合しました
- 作ります
- 作成
- クリエイティブ
- クリエイター
- クロスファンクショナルチーム
- 文化
- データ
- データアクセス
- データ分析
- データインフラストラクチャ
- データレイク
- データ管理
- データポイント
- データ処理
- データ共有
- データ駆動型の
- データセット
- 中
- 分権化された
- 決定
- 決定
- 専用の
- より深い
- デフォルト
- デフォルト
- 定義済みの
- 定義
- 配信する
- 配達
- 需要
- 依存関係
- 依存関係
- 依存
- によっては
- 設計
- 設計
- 希望
- 詳細な
- 細部
- 決定する
- 開発
- DID
- 異なります
- 難しい
- 直接に
- 発見する
- 発見
- 話し合います
- 議論する
- 議論
- ディスプレイ
- 配布
- 異なる
- ダイビング
- do
- ドキュメント
- そうではありません
- ドメイン
- ドメイン
- ドント
- ドリブン
- e
- 各
- 簡単に
- エコシステム
- エディタ
- 効果
- 効果的に
- 効率的な
- 効率良く
- 昇降する
- 除去された
- 採用
- 採用
- 従業員
- 権限を与え
- enable
- 使用可能
- 可能
- 有効にする
- 暗号化
- end
- 端から端まで
- エンドポイント
- エンジン
- エンジニアリング
- エンジニア
- 高めます
- 強化
- 豊かにする
- 確保
- 確実に
- 全体
- エンティティ
- 構想された
- エリック
- 確立する
- エーテル(ETH)
- 評価する
- イベント
- あらゆる
- 毎日
- 進化
- 例
- 例
- 除く
- 交換
- 既存の
- 拡大
- 予想される
- 体験
- エクスペリエンス
- 説明
- 容易化する
- 遠く
- 速いです
- 少数の
- フィールズ
- フィギュア
- 財務
- もう完成させ、ワークスペースに掲示しましたか?
- 発見
- フィット
- 焦点を当て
- フォロー中
- 強
- 形式でアーカイブしたプロジェクトを保存します.
- 形成
- 発見
- 断片化して
- フレームワーク
- 摩擦
- から
- ガソリンタンク
- 満たす
- フル
- 完全に
- さらに
- さらに
- 利得
- 集まり
- 生成された
- 生成
- 取得する
- グローバル
- グローバルに
- Go
- 目標
- 良い
- ガバナンス
- 統治
- 付与
- 粒状
- グループ
- グループの
- 成長
- 成長性
- 案内
- 持っていました
- ハンドリング
- 起こります
- もっと幸せ
- ハッピー
- 持ってる
- 持って
- he
- 助けます
- 助けました
- ハイ
- より高い
- 彼の
- 認定条件
- How To
- しかしながら
- HTTP
- HTTPS
- 人間
- 何百
- IAC
- IAM
- ID
- 識別する
- アイデンティティ
- 説明する
- 実装する
- 実装
- 実装
- 実装
- 重要
- 改善します
- in
- 綿密な
- include
- 含めて
- ますます
- 独立しました
- 単独で
- インジケータ
- 個別に
- 非効率
- 影響力のある
- 情報
- 情報セキュリティー
- インフラ
- 初期
- イニシアチブ
- お問い合わせ
- 洞察
- インテリジェンス
- 意図された
- 意図
- 相互運用性(インターオペラビリティ)
- に
- 問題
- IT
- ITS
- 自体
- Jobs > Create New Job
- 旅
- JPG
- 保管
- キー
- 知っている
- 知識
- 既知の
- ラボ
- 湖
- 姓
- 遅く
- 法律
- リーダー
- 主要な
- LEARN
- 学んだ
- 最低
- レンズをセットすることで
- less
- レベル
- ような
- 限定的
- 耳を傾ける
- リテラシー
- ロジック
- 長期的
- より長いです
- 見て
- たくさん
- ロー
- 製
- 維持する
- 保守
- メンテナンス
- 大多数
- make
- マネージド
- 管理
- 方法
- 地図
- マッピング
- マシュー
- 満期
- 五月..
- 意味
- 手段
- 意味した
- だけど
- メディア
- 大会
- マージ
- メッシュ
- メソッド
- メトリック
- かもしれない
- 最小
- モデリング
- 収益化
- モニタリング
- 他には?
- さらに
- の試合に
- 必要
- 必要
- 必要とされる
- ニーズ
- 新作
- 特に
- ノートPC
- 知らせ..
- 通知
- 数
- オブジェクト
- 客観
- 観測された
- of
- オファー
- 役員
- on
- ONE
- もの
- の
- 開いた
- 開いているデータ
- 操作する
- オペレーティング
- オペレーショナル
- 業務執行統括
- 反対した
- or
- 編成
- 注文
- 組織
- 組織の
- 組織
- 整理する
- その他
- その他
- さもないと
- 成果
- 外側
- が
- 全体
- 自分の
- 所有者
- 所有権
- 所有しています
- 所有する
- ペイント
- 並列シミュレーションの設定
- パラメーター
- のワークプ
- 以下のために
- パフォーマンス
- パーミッション
- 視点
- フェーズ
- 画像
- 場所
- 計画されました
- 計画
- プラットフォーム
- プラトン
- プラトンデータインテリジェンス
- プラトデータ
- さらに
- ポッドキャスト
- ポッドキャスティング
- ポイント
- ポリシー
- 所有する
- 可能
- ポスト
- 練習
- プラクティス
- 先行
- 準備
- PLM platform.
- 前に
- 校長
- 原則
- 原則
- 先を見越した
- ラボレーション
- 処理
- 作り出す
- 生産された
- プロデューサー
- 生産者
- 作成
- プロダクト
- 製品
- プロ
- 収益性
- 進捗
- 保護
- 提供します
- は、大阪で
- 提供
- 目的
- 目的
- 上げる
- むしろ
- リーチ
- 読む
- すぐに
- リーディング
- 再生タイヤ
- 縮小
- 削減
- 参照する
- 言及
- 反映
- に対する
- 参加申し込み
- 解放
- 信頼性のある
- 除去
- 除去
- リクエスト
- 必要とする
- 解決する
- 共鳴する
- リソースを追加する。
- リソース
- 責任
- 制限されました
- 結果として
- レビュー
- リスク
- 職種
- 役割
- ラン
- ランニング
- 同じ
- 保存されました
- スケーラビリティ
- ド電源のデ
- 規模
- スケーリング
- シームレス
- 安全に
- セキュリティ
- セキュリティリスク
- 見て
- セルフサービス
- 敏感な
- 仕える
- サービス
- サービス
- セッションに
- セット
- シェアする
- shared
- 株式
- シェアリング
- 彼女
- 示されました
- 示す
- 作品
- 著しく
- サイロ
- 簡単な
- 単に
- わずかに異なる
- スムーズ
- スニペット
- So
- これまでのところ
- 社会
- ソーシャルメディア
- ソフトウェア
- サービスとしてのソフトウェア
- ソフトウェア開発
- もっぱら
- 溶液
- ソリューション
- 解決します
- 一部
- ソース
- ソース
- スペース
- 特定の
- 指定の
- 主催
- SQL
- スタック
- ステージ
- 規格
- start
- 起動
- ステートメント
- 知らせる
- まだ
- ストレージ利用料
- 簡単な
- 戦略的
- 戦略家
- 流れ
- 強化された
- 強い
- 構造
- 構造化された
- 苦労して
- 成功
- 首尾よく
- そのような
- 十分な
- サポート
- サポート
- 持続可能な
- 継続的な成長
- タックル
- 取得
- チーム
- チーム
- テク
- 技術的
- テクノロジー
- template
- 十
- より
- それ
- 情報
- アプリ環境に合わせて
- それら
- 理論
- そこ。
- したがって、
- ボーマン
- 彼ら
- この
- それらの
- 三
- 繁栄する
- 介して
- 時間
- 時間枠
- 〜へ
- 一緒に
- ツール
- 豊富なツール群
- top
- 取引
- 旅行
- 試み
- 信頼できる
- 2
- 究極の
- 最終的に
- わかる
- 理解する
- 中断されない
- ユニット
- 今後の
- に
- us
- つかいます
- 使用事例
- 中古
- ユーザー
- 操作方法
- users
- 使用されます
- 利用された
- 貴重な
- 値
- 変数
- さまざまな
- 広大な
- 速度
- バージョン
- 非常に
- 、
- ボリューム
- ました
- 仕方..
- we
- ウェブ
- Webサービス
- WELL
- した
- この試験は
- いつ
- which
- while
- 誰
- 誰
- 意志
- 無し
- 仕事
- ワークフロー
- ワークフロー
- ワーキング
- 作品
- 世界の
- 価値
- でしょう
- 書かれた
- 年
- 貴社
- あなたの
- ゼファーネット