Subscribe
Share
Share
Embed
KQL Databaseは既定で10年分のホットSSDキャッシュを有効にしています。Fabricに時系列専用エンジンが必要な理由、コストと性能を左右する2つのポリシー、そして効率的なストアを高額なストアに変えてしまう設定ミスを掘り下げます。
Episode 16 • 2026-04-17 Duration: 11:57
すべてのKQL Databaseには、既定で10年分のホットSSDキャッシュが有効になっています。Fabricに時系列データ専用エンジンが必要な理由を掘り下げ、コストとパフォーマンスを制御する2つのポリシーを解きほぐし、効率的なストアを高額にしてしまう設定ミスを解説します。
The Fabric Friday video on this topic: https://youtu.be/z57H_Zqvbkc
AI-generated voices. Matthias — cloned voice. Fabia — designed AI co-host. See Matthias live on YouTube (Fabric Friday), at his meetups, and at conferences like FabCon.
Hosted by Matthias Falland — Microsoft Data Platform MVP and community architect behind the Fabric Periodic Table. New episodes every Friday.
Have an architecture decision you are wrestling with? DM Matthias on LinkedIn — find him as Matthias Falland. Three to five sentences about the decision, your team size, and your current stack. We anonymize before airing.
このポッドキャストは AI によって生成されています。どちらの音声も合成です。Matthias はクローン音声、Fabia は設計された AI 共同ホストです。
Brand design based on fabricperiodictable.com.
Microsoft Fabric のア���キテクチャ意思決定。匿名化された実際の顧客シナリオ、コストのリアリズム、反論を含む。Fabric Friday の録画に合わせた週刊エピソード。AIにより生成。
誰も触れなかった10年キャッシュ
Episode 16 | 2026-04-17
Fabric Architecture Podcast | Hosted by Matthias Falland with AI co-host Fabia
---
[00:08] Fabia: 3650日。これがFabricのKQL Databaseに既定で設定されているホットキャッシュ期間です。データベースを作った瞬間から、10年分の時系列データがSSDに保持されます。
[00:14] Matthias: で、その中で実際に10年分のセンサーデータをクエリしているチームって、どれくらいいますか。
[00:17] Fabia: ほぼゼロです。
[00:17] Matthias: 今日はKQL Databaseを分解していきます。Fabricになぜ時系列専用のエンジンが必要なのか、そして既定の設定がダッシュボードを眺めている間にストレージコストを静かに膨らませている話です。
[00:24] Fabia: KQL Databaseの中で動いているKustoエンジンは、WarehouseやSQL Databaseを支えるSQLエンジンとは根本的に別物です。カラム型で、追記に最適化されていて、取り込み時刻で自動的にパーティションを切ります。時間フィルタ付きのクエリが来ると、エンジンは関連するデータシャードだけを読み、残りは完全にスキップします。テレメトリ10億行のクエリがミリ秒で返ってくるのは、そういう仕組みです。
[00:38] Matthias: Sparkを知っているからという理由でIoTデータをLakehouseに入れるチーム、何度も見てきました。技術的には動きます。Deltaテーブルは書き込みを受け付けます。ただ、7日間のトレンドに異常検知をかけたいという話が出た瞬間、200ミリ秒だったものが40秒になって、チームが原因を探し回ることになります。
[00:48] Fabia: Spark SQLにはネイティブの時系列演算子がないからです。make-seriesもseries_decompose_anomaliesもありません。カレンダーテーブルを用意して、セルフジョインして、手動で集計して、さらに異常検知にはPythonライブラリを後付けする必要があります。KQLなら1つの関数呼び出しで済みます。
[00:59] Matthias: 関数1つか、誰もメンテしたくないノートブックか。
[01:01] Fabia: 構造の話をしましょう。KQL Databaseは単独では存在しません。必ずEventhouseの中に置かれます。Eventhouseが共有コンピュート層で、エンジンは1つ、モニタリングも統合、CUも共有です。テーブルや関数、ポリシーが実際に置かれるのがKQL Databaseです。1つのEventhouseに5つ、10のデータベースを入れて、同じCUプールから引くことができます。
[01:13] Matthias: え、同じCUプールを共有しているなら、1つのデータベースにノイジーなワークロードが来たらどうなりますか。他のデータベースのCUを食いますか。
[01:18] Fabia: はい。それが統合のトレードオフです。クロスデータベースクエリ、統合モニタリング、管理コストの低減は得られます。ワークロード分離は手放します。1つのデータベースが取り込みレートを突然倍にすれば、他のデータベースのクエリレイテンシに影響が出ます。
[01:26] Matthias: その会話、何度もしてきました。分析チームがダッシュボードの遅延に気づく。でもIoTチームが前の晩にセンサー周波数を3倍にしたことは知らない。自分たちの側では何も変えていないのに、クエリが3倍遅くなっている。原因がまったく見えないんです。
[01:34] Fabia: まさにこの核心を突く質問が届いています。 「KQL Databaseの保持期間を30日に設定したら、先週のデータへのクエリが遅くなりました。何を間違えたのでしょうか」
[01:41] Matthias: ああ……典型的な混同ですね。回すべきつまみを間違えています。
[01:43] Fabia: 2つのポリシーがあって、名前が似ているので経験豊富なチームでも混同します。保持ポリシーはデータが存在する期間を決めます。保持期間を過ぎたデータは削除されます。永久にです。キャッシュポリシーはそのデータのうちどれだけを高速なSSDに置くか、それともOneLake標準ストレージに置くかを決めます。この方は保持期間を30日にしてしまった。つまり30日を超えたデータは完全に消えます。でも訴えているのは先週のデータが遅いという話で、これはキャッシュの問題であって保持の問題ではありません。
[01:59] Matthias: つまり本当にやりたかったのは、キャッシュ期間を30日に絞ること。直近1か月分をホットSSDに置いて、古いデータは安いストレージに落とす。ところが実際にやったのは、データの30日削除タイマーの設定だったと。
[02:06] Fabia: しかも、状況を悪化させる制約があります。キャッシュ期間は保持期間を超えられません。Fabricがそれを強制します。あとからキャッシュを30日より長く延ばそうとしても、保持期間を先に直さない限りエラーになります。つまみを1つ間違えたことで、2つ目の問題が生まれるわけです。
[02:15] Matthias: でも引っかかるのはここなんです。どちらのポリシーも既定値が3650日。つまりすべてのKQL Databaseが、最初からプレミアムSSD上にすべてをキャッシュしています。クエリが速いから誰も文句を言わず、設定に触れない。半年後にストレージの請求書を見て初めて気づくわけです。
[02:24] Fabia: OneLakeキャッシュストレージ、つまりホット層はCUとは別に課金されます。メーターが2つ回っています。コンピュートのCUと、SSDキャッシュに置かれたギガバイトごとの別の明細です。ほとんどのチームはCU使用率を見ていて、ストレージはまったく別の課金明細に出るため気づきません。
[02:33] Matthias: 結局、アーキテクチャ上の判断は意図的に設定する3つの値に集約されます。キャッシュ期間は実際のクエリパターンに合わせる。ダッシュボードが7日分を表示するなら、キャッシュも7日。保持期間はコンプライアンス要件に合わせる。規制が1年なら365日。そしてCapacity Plannerモードは利用パターンに合わせる。チームと3つの会話をすれば済む話です。
[02:45] Fabia: Capacity Plannerモードはもう少し掘り下げる価値があります。有効にすると、キャッシュストレージのコストがCU消費に吸収されます。OneLakeキャッシュストレージの別料金がなくなります。さらにコールドスタートレイテンシも解消されます。Eventhouseがアイドルから復帰した朝一番のクエリが遅い、あの現象です。トラフィックが安定している本番ワークロードなら、総合的に安くなることが多いモデルです。ただし夜間に放置する開発テスト環境だと、午前3時にもエンジンの費用を払うことになります。
[03:02] Matthias: 逆の話もしましょう。KQL Databaseがまったく合わないのはどういう場合ですか。
[03:05] Fabia: 更新が必要なワークロードです。KQL Databaseは設計上、追記専用です。UPDATE文もマルチテーブルトランザクションも外部キーもありません。受注管理システム、顧客レコードストア、行レベルの変更が頻繁に発生するもの。それはSQL DatabaseかWarehouseの領域です。KQLでやろうとすると、あらゆる場面でぶつかります。
[03:16] Matthias: もう一歩踏み込みます。T-SQLを何年も書いてきた10人のチームがいて、ユースケースがタイムスタンプ付きデータの中程度の分析、異常検知も予測も不要だとします。Warehouseで十分対応できます。クエリはミリ秒ではなく秒単位ですが、新しい言語を誰も覚えなくていいので1週間で出荷できる。多くの状況で、それは合理的な判断です。
[03:27] Fabia: 補足すると、KQL Databaseは読み取り専用のT-SQLサブセットに対応しています。SELECT、WHERE、GROUP BY、基本的なJOINは動きます。ただしmake-seriesやseries_decompose_anomaliesが必要になった瞬間、KQL専用です。時系列演算子にT-SQL相当はありません。そのワークロードがいずれ必要とするかどうか、そこが分岐点です。
[03:40] Matthias: 「いずれ必要とするか」。アーキテクチャでいちばん危険な言葉ですね。
[03:42] Fabia: 注意すべきリスクは、学習曲線と運用面のギャップが掛け合わさることです。KQLの構文自体は読みやすい。パイプベースで左から右に読める。SQLに慣れた開発者なら1日で書き始められます。ただ運用面、つまりキャッシュポリシー、保持期間、Capacity Plannerモード、どのストレージメーターで実際に課金されているのか。チームが驚くのはそこです。エンジンは洗練されています。課金モデルには層があります。
[03:55] Matthias: これから始める人へのアドバイスはこうです。Eventhouseを立てて、組み込みのStormEventsサンプルデータを読み込む。そして本番データを入れる前に2つだけ覚えてください。make-seriesとseries_decompose_anomalies。Warehouseではなくここにいる理由はその2つです。それからキャッシュポリシーを本番データの取り込み前に意図的に設定する。ホットキャッシュの価格を請求書で知るのはやめましょう。
[04:10] Fabia: クエリパターンを見せてください。すべてはそこから始まります。キャッシュ期間はクエリの範囲に、保持期間はコンプライアンス要件に、Capacity Plannerモードはトラフィックの形に合わせる。
[04:17] Matthias: 設定は3つ。そしてすべての既定値が、いちばん高い方に振れています。
[04:19] Fabia: 静かに。10年間。
[04:20] Matthias: KQL Databaseについて質問があれば、LinkedInでDMしてください。Matthias Fallandで見つかります。
[04:24] Fabia: また来週の金曜日に。
---
End of episode. ~04:25 estimated.