1723378470
2024-08-11 10:24:06
コンサルタントとして、私は、未完成、放棄、そして時には忘れ去られた数十のデータ インフラストラクチャ プロジェクトをレビューし、多くの場合、置き換えるよう依頼されてきました。
いくつかのケースでは、データ インフラストラクチャを少し調整するだけで効果的に動作する可能性がありますが、プロジェクトが不完全であったり、中心的な設計が欠如していたりして、古いシステムを置き換えるのが最善の方法である場合もあります。
信じてください。プロジェクトに参加して、コードを数行変更するだけで、すべてがうまく機能するのであれば、最高です。しかし、多くのプロジェクトは、明確な設計上の決定や、適切な計画に基づかない履歴書主導の開発で満ち溢れています。
もちろん、ビジネス関係者も、物事を早く終わらせるよう圧力をかけているかもしれません。データ チームに、決して解決されない技術的負債を負わせることになります。誤解しないでください。物事を終わらせてプロジェクトを前進させたいのです。しかし、技術的負債を負うかどうかは、意図的に決定する必要があります。そうしないと、履歴書主導の開発のように、データ インフラストラクチャが消滅してしまう可能性があります。
これは疑問を投げかけます。
将来、自分が退職した直後に、構築中のデータ インフラストラクチャが置き換えられないようにするにはどうすればよいでしょうか。
この記事では、現在のデータ インフラストラクチャを置き換える必要が生じるよくある問題と、それを回避する方法について詳しく説明します。
それでは早速始めましょう。
新しいシステムを設計するときは、 ベンダー またはあなたの 再開する誤解しないでください。もしあなたがあなたのためにしっかりした信頼できる基盤を持っているなら、 データインフラストラクチャ新しいツールを使って時々 POC をテストしてみるのも悪くありません。
私が見つけた問題は、多くのデータ チームが、実際にデータ インフラストラクチャを設定した経験がほとんどないまま、データ インフラストラクチャの設計を強いられることです。誤解しないでください。私たちは全員、経験なしからスタートします。しかし、さまざまなツールや設計の微妙な違いをすべて評価するのは難しい場合があります。
すると、多くの開発者は、大手テクノロジー企業が何をしているのか、ベンダーは何を推奨しているのかを調べるために記事を検索します。その結果、自分のユースケースに合わないような設計が選択される可能性もあります。
先ほど話していた分析部門の元マネージャーが指摘した素晴らしい点は、ETLや データパイプライン 紙の上では良さそうなツール。アカウント エグゼクティブとセールス エンジニアが完璧な提案と POC をまとめます。
しかし、プロジェクト開始から 8 か月が経過した時点で、ツールが明らかにしなかったか、経験によってのみ発見できる重要な障害が見つかりました。正直なところ、ベンダー自身もその制限を知らなかった可能性があります。
全体的なアーキテクチャを設計しようとするときにも、同様のことが言えます。大手テクノロジー企業のやり方に従おうとすると、それが自社に合わない可能性があります。
コアデザインには細心の注意を払う必要があります。
-
ベンダーを利用したことがある人に話を聞く – ほとんどのデータ エンジニアは、さまざまなツールに関する意見を喜んで共有します。したがって、さまざまなデータ エンジニアやアーキテクトを見つけて、ツールの使用経験について尋ねてみましょう。中には、そのツールは使用すべきではないとはっきり言う人もいれば、特定のツールを絶賛する人もいます。
多くの企業、特に中小企業が常に直面している問題の一つは、 キーパーソンの依存関係の問題これは、単一の主要な開発者、またはおそらくは小規模なチームが全員でデータ インフラストラクチャの開発を決定し、将来のチームが維持したり、何が起こっているかを把握したりすることが困難になるという形で現れます。
これは、以前のチームが設計を文書化していなかったか、自分たちのためにのみ文書化していたことが原因である可能性があります。
確かに、彼らは機能するデータ インフラストラクチャを構築し、企業の現在の問題を解決しました。彼らはそれを維持しており、誰も質問しません。
おそらく、チーム メンバーの 1 人が毎朝 6 時に起きて、すべてのレポートとテーブルが作成されているかどうかを確認する必要があることに気付いている人はいないでしょう。
それは彼らが去る日まですべてうまくいきます。
その後、データインフラストラクチャはしばらくは持ちこたえるかもしれませんが、最終的には問題が発生します。おそらく会社は代わりの人を雇ったのでしょう データチーム しかし、最終的には実際にサポートできる限界に達する可能性があります。
これは私の過去の顧客の多くにとって大きな問題でした。過去数年間で約 3 分の 1 が、この理由で私のサービスを求めてきました。
ある例では、私がやって来て、使われていないデータ ボールト プロジェクトを見つけました。実際には、かなり良いドキュメントがありました。しかし、チームは時間がかかりすぎてプロジェクトを完全に完了できなかったため、解雇されました。さらに悪いことに、プロジェクトが完了しなかったため、数人のアナリストが週末に働いて、取締役会向けの重要なレポートを作成しなければなりませんでした。
この特定のケースでは、私たちは彼らが構築したものを大幅に簡素化し、より小規模なチームでも維持できる、よりシンプルなデータ ウェアハウスを構築しました。
そしてもちろん、レポートが自動化され、アナリストが週末に働かなくて済むようにしました。
-
ドキュメント – 作成するドキュメントは、自分だけのために書かれたものではなく、これまであなたのコードを見たこともない人のために書かれたものであることを確認してください。特に、特定のツールを選択した理由や、特定の場所にロジックを実装した理由など、重要な決定ポイントを強調します。
-
クロストレーニング（適切な場合） – 大規模なチームの場合は、クロストレーニングを検討してください。これには、他のチームの半技術系の従業員も含まれます。彼らがエンジニアに取って代わる、または取って代わるべきだと言っているのではありません。しかし、私の観点からすると、 コンサルタントシステムがなぜそのように開発されたのかについて何らかの関係があるマーケティングアナリストや運用アナリストと直接話をすることができて、とても良かったです。
私が関わったいくつかのプロジェクトでは、ステークホルダーと データチーム 故障したか、あるいは存在しなかったかのどちらかです。
データ チームは数か月間、ビジネス部門がレビューできる成果物をまったく提供せずに活動を続けていました。そして、関係者が結果を見たときには、彼らが求めていたものとはまったく異なっていました。
構築しているものにステークホルダーを関与させる必要があります。例を挙げてみましょう。私が仕事で関わったクライアントの 1 社にはデータ ウェアハウスがありました。技術的には機能していました。
しかし、数日のうちに、サポートされていた2～3のダッシュボードを誰も使っていないことに気付きました。 データ ウェアハウス。
なぜ？
まあ、理由はいくつかありますが、その一つは、実際には利害関係者と一緒に構築されたことがなかったことです。
そのため、彼らは最終結果が役に立たないと判断しました。
このセクションのトピックは、おそらくこの記事を書くきっかけとなったものです。ビジネスに結び付けられずにサイロ内に構築されたデータ インフラストラクチャが数多く存在します。これらはすべて、最終的にプロジェクトの失敗やデータ インフラストラクチャの持続不能につながります。
-
ビジネス成果から始める – 上でも似たようなことを言いましたが、繰り返しておく価値はあります。インフラストラクチャのためにインフラストラクチャを構築したくはありません。したがって、プロジェクトを開始する前に、ビジネスの改善という観点から何をしようとしているのかを明確にしてください。
-
ビジネスを常に最新の状態に保つ – ダッシュボードを確認したり、指標を分析したりする会議を開かないのは非常に魅力的です。結局、仕事を終わらせなければなりません。問題は、3 ～ 6 か月の開発期間の終わりに、最終製品を披露したときに、それが関係者の希望にまったく近づいていない場合に発生します。
データ インフラストラクチャは、いわば混乱している必要はありません。あるいは、将来の開発者にとって、内部で何が起こっているかを理解するのが難しくなる必要はない、とだけ言ったほうがよいでしょう。プログラミングの学習における私の最高の経験は、ある会社で働いていて、コード ベースを開いて、何が起こっているかを理解したときでした。
抽象化は追跡できないほど深くはなく、命名規則には明確な標準が実装されていました。
正直に言うと、たくさんの小さなことがうまくいっただけです。
よく考えられたシンプルなシステム。
誰もが理解できる名前をつける。
頭字語や仮定で満たされていないドキュメント。
これにより、今後何年もデータ インフラストラクチャが維持されることが保証されます。
それでは、読んでいただきありがとうございました！
データ エンジニアリング、データ サイエンス、初めての仕事への参入、同じ考えを持つ他のデータ スペシャリストを見つけることについてさらに話し合いたい場合は、Seattle Data Guy の discord に参加してください。
現在、会員数は7000人を超えています。
データ コンサルタントであるか、データ コンサルタントになることを検討している場合は、テクニカル フリーランサー コミュニティに参加してください。メンバー数は約 700 人です。
テクニカル コンサルタントとしてのキャリアを加速させるのに役立つ無料リソースが豊富に用意されているほか、疑問点について他のコンサルタントに相談することもできます。
Medium には毎日 20,000 件の新しい記事が投稿されています。これは Medium だけです。私はこれらの記事や >、企業の技術ブログを時間をかけて精査し、お気に入りの記事をいくつか紹介したいと思います。
Uberのクラウド化の一環として、オンプレミスの Apache Hadoop® ベースのデータレイク GCP™インフラストラクチャプラットフォームに分析および機械学習ワークロードを追加します。 戦略 ストレージ レイヤーの HDFS を GCS オブジェクト ストレージ (PaaS) に置き換え、残りの技術スタック (YARN、Apache Hive™、Apache Spark™、Presto® など) を GCP Compute Engine (IaaS) で実行します。
一般的なクラウド導入戦略では、クラウドネイティブ コンポーネントを使用し、既存の IAM をクラウド IAM (フェデレーション、ID 同期など) と統合します (図 1.ii)。当社の戦略はややユニークで、既存のスタックの一部をそのまま活用し (HDFS を除く)、GCS と統合します…
私たちのコミュニティをご覧いただきありがとうございます。私たちはデータ、テクノロジー、スタートアップについて議論するニュースレターを週に 3 ～ 4 回発行しています。
#データスタックが長持ちしない理由